We want vue_map->num_slots to be one more than the final slot.
When assigning fixed slots, built-in slots, and non-SSO user varyings,
we do slot++. This leaves "slot" as one past the most recently assigned
slot. But for SSO user varyings, we computed slot based on the varying
location value...and left it at that slot value.
To work around this inconsistency, I made num_slots be "slot + 1" if
separate and "slot" otherwise. The problem is...if there are no user
varyings in SSO mode...then we would have done slot++ when assigning
built-ins, so it would be off by one. This resulted in loops from 0
to vue_map->num_slots hitting a bonus BRW_VARYING_SLOT_PAD at the end.
This used to break the SIMD8 VS/TES backends, but I fixed that in
commit
480d6c1653713dcae617ac523b2ca5deee01c845. It's probably safe
at this point, but we should fix it anyway.
To fix this, do slot++ in all cases. For SSO mode, we overwrite slot
for every varying, so this increment only matters on the last varying.
Because we process varyings in order, this will set slot to 1 more
than the highest assigned slot.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
const int varying = ffsll(generics) - 1;
if (separate) {
slot = first_generic_slot + varying - VARYING_SLOT_VAR0;
- assign_vue_slot(vue_map, varying, slot);
- } else {
- assign_vue_slot(vue_map, varying, slot++);
}
+ assign_vue_slot(vue_map, varying, slot++);
generics &= ~BITFIELD64_BIT(varying);
}
- vue_map->num_slots = separate ? slot + 1 : slot;
+ vue_map->num_slots = slot;
vue_map->num_per_vertex_slots = 0;
vue_map->num_per_patch_slots = 0;
}