Commit 16631ca3 authored by Iago Toral's avatar Iago Toral
Browse files

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's avatarKenneth Graunke <kenneth@whitecape.org>
parent b7c655f7
......@@ -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
}
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment