i965: Fix number of slots in SSO mode when there are no user varyings.
authorKenneth Graunke <kenneth@whitecape.org>
Tue, 29 Nov 2016 00:59:45 +0000 (16:59 -0800)
committerKenneth Graunke <kenneth@whitecape.org>
Tue, 10 Jan 2017 00:52:16 +0000 (16:52 -0800)
commit2bae2fa09446ef3168c82e492223b66a05a85b21
treedf70b93a1393b9283f962da5040cee0a0e04e487
parent203c1287816f2a73475a48dd72a9a2ed03a42ac1
i965: Fix number of slots in SSO mode when there are no user varyings.

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>
src/mesa/drivers/dri/i965/brw_vue_map.c