i965/sbe: fix active components for SSO programs with over 16 inputs

When we have up to 16 FS inputs, the SF unit will reorder our inputs
to be consecutive, however, when we have more than 16 we need to
to read our inputs from the URB exactly as they have been
output from the previous stage. This means that for SSO we have to
consider if we have URB padding due to unused input locations.

Specifically, this affects gen9 active components programming, since
for things to work in scenarios with over 16 inputs that have padded
regions we need to ensure that we program active components for the
padded regions too. If we don't do this the hardware won't read
the URB properly for inputs located after padded regions.

Found empirically.

Fixes (these also require a patch in CTS):
KHR-GL45.enhanced_layouts.varying_locations
KHR-GL45.enhanced_layouts.varying_array_locations

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This commit is contained in:
Iago Toral Quiroga 2017-10-13 09:22:54 +02:00
parent b7c655f700
commit 16631ca30e
1 changed files with 2 additions and 8 deletions

View File

@ -3452,15 +3452,9 @@ genX(upload_sbe)(struct brw_context *brw)
#if GEN_GEN >= 9
/* prepare the active component dwords */
int input_index = 0;
for (int attr = 0; attr < VARYING_SLOT_MAX; attr++) {
if (!(fp->info.inputs_read & BITFIELD64_BIT(attr)))
continue;
assert(input_index < 32);
const int num_inputs = urb_entry_read_length * 2;
for (int input_index = 0; input_index < num_inputs; input_index++) {
sbe.AttributeActiveComponentFormat[input_index] = ACTIVE_COMPONENT_XYZW;
++input_index;
}
#endif
}