| 2bae2fa09446ef3168c82e492223b66a05a85b21 |
|
29-Nov-2016 |
Kenneth Graunke <kenneth@whitecape.org> |
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>
/external/mesa3d/src/mesa/drivers/dri/i965/brw_vue_map.c
|
| 09ffc5c84f8067e3b8d0ee89a1771e0a38595036 |
|
06-Dec-2016 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Initialize "separate" flag in VUE maps.
This was uninitialized, which resulted in weird looking printouts where
it appeared that the TCS output and TES input patch URB entries differed
in SSO/non-SSO layout. There is no "separable" layout for both, as
they're tied together.
It should have no other actual effect.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
/external/mesa3d/src/mesa/drivers/dri/i965/brw_vue_map.c
|
| ec1f159ac81ed964415d102eed4a0a29be8e7937 |
|
17-Aug-2016 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Always reserve clip distance VUE slots in SSO mode.
This fixes rendering in Dolphin on Vulkan since we enabled clip
distances. (Dolphin on GL has a similar bug because the linker
fails to eliminate unused clip distance built-in arrays, but it
isn't using SSO...so that needs more fixing.)
Also fixes a Piglit test:
spec/glsl-1.50/execution/geometry.clip-distance-vs-gs-out-sso
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
/external/mesa3d/src/mesa/drivers/dri/i965/brw_vue_map.c
|
| 527f37199929932300acc1688d8160e1f3b1d753 |
|
23-Aug-2016 |
Jason Ekstrand <jason.ekstrand@intel.com> |
intel: s/brw_device_info/gen_device_info/
Generated by:
sed -i -e 's/brw_device_info/gen_device_info/g' src/intel/**/*.c
sed -i -e 's/brw_device_info/gen_device_info/g' src/intel/**/*.h
sed -i -e 's/brw_device_info/gen_device_info/g' **/i965/*.c
sed -i -e 's/brw_device_info/gen_device_info/g' **/i965/*.cpp
sed -i -e 's/brw_device_info/gen_device_info/g' **/i965/*.h
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
/external/mesa3d/src/mesa/drivers/dri/i965/brw_vue_map.c
|
| e734fb0326e61470d4341cc7bda52a25c96e1a72 |
|
15-Jan-2016 |
Matt Turner <mattst88@gmail.com> |
i965: Inform compiler of variable range to silence warning.
Extends commit 6531ccb70 to silence the warning in release builds as
well.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
/external/mesa3d/src/mesa/drivers/dri/i965/brw_vue_map.c
|
| 6531ccb7056f80c32a29e07fe05381b0fd6557dc |
|
05-Jan-2016 |
Ilia Mirkin <imirkin@alum.mit.edu> |
i965: quieten compiler warning about out-of-bounds access
gcc 4.9.3 shows the following error:
brw_vue_map.c:260:20: warning: array subscript is above array bounds
[-Warray-bounds]
return brw_names[slot - VARYING_SLOT_MAX];
This is because BRW_VARYING_SLOT_COUNT is a valid value for the enum
type. Adding an assert will generate no additional code but will teach
the compiler to not complain.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
/external/mesa3d/src/mesa/drivers/dri/i965/brw_vue_map.c
|
| 1f46163acb4853b3e159e4a0cb91d61c8a348553 |
|
10-Nov-2015 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Add tessellation shader VUE map code.
Based on a patch by Chris Forbes, but largely rewritten by Ken.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
/external/mesa3d/src/mesa/drivers/dri/i965/brw_vue_map.c
|
| f36993b46962eab4446bc1964eb47149751aee26 |
|
23-Nov-2015 |
Matt Turner <mattst88@gmail.com> |
i965: Clean up #includes in the compiler.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
/external/mesa3d/src/mesa/drivers/dri/i965/brw_vue_map.c
|
| a4ba476c30ebcb99694c6167ac9b8af9414cb656 |
|
10-Nov-2015 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Print input/output VUE maps on INTEL_DEBUG=vs, gs.
I've been carrying around a patch to do this for the last few months,
and it's been exceedingly useful for debugging GS and tessellation
problems. I've caught lots of bugs by inspecting the interface
expectations of two adjacent stages.
It's not that much spam, so I figure we may as well just print it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Matt Turner <mattst88@gmail.com>
/external/mesa3d/src/mesa/drivers/dri/i965/brw_vue_map.c
|
| 99df02ca26f6127c8fa24d38a8a069ac6159356a |
|
10-Sep-2015 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Don't re-layout varyings for separate shader programs.
Previously, our VUE map code always assigned slots to varyings
sequentially, in one contiguous block.
This was a bad fit for separate shaders - the GS input layout depended
or the VS output layout, so if we swapped out vertex shaders, we might
have to recompile the GS on the fly - which rather defeats the point of
using separate shader objects. (Tessellation would suffer from this
as well - we could have to recompile the HS, DS, and GS.)
Instead, this patch makes the VUE map for separate shaders use a fixed
layout, based on the input/output variable's location field. (This is
either specified by layout(location = ...) or assigned by the linker.)
Corresponding inputs/outputs will match up by location; if there's a
mismatch, we're allowed to have undefined behavior.
This may be less efficient - depending what locations were chosen, we
may have empty padding slots in the VUE. But applications presumably
use small consecutive integers for locations, so it hopefully won't be
much worse in practice.
3% of Dota 2 Reborn shaders are hurt, but only by 2 instructions.
This seems like a small price to pay for avoiding recompiles.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
/external/mesa3d/src/mesa/drivers/dri/i965/brw_vue_map.c
|
| 1e5180316cd62c8c8aa46399ab6a17ad9604d48f |
|
10-Sep-2015 |
Kenneth Graunke <kenneth@whitecape.org> |
i965/vue: Make assign_vue_map() take an explicit slot.
Our plan of assigning consecutive slots doesn't work properly for
separate shader objects - at least, if we want to avoid recompiling them
whenever the interface changes.
As a first step, make assign_vue_map take an explicit slot parameter,
rather than implicitly incrementing it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
/external/mesa3d/src/mesa/drivers/dri/i965/brw_vue_map.c
|
| 268008f98c3810b9f276df985dc93efc0c49f33e |
|
10-Sep-2015 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Initialize unused VUE map slots to BRW_VARYING_SLOT_PAD.
Nothing actually relies on unused slots being initialized to
BRW_VARYING_SLOT_COUNT. Soon, we're going to have VUE maps with holes
in them, at which point pre-filling with BRW_VARYING_SLOT_PAD make a lot
more sense.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
/external/mesa3d/src/mesa/drivers/dri/i965/brw_vue_map.c
|
| 94e3864707e48d4b1d5fb5f88a01370a73ddb0cb |
|
15-May-2015 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Add and fix comments in brw_vue_map.c.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
/external/mesa3d/src/mesa/drivers/dri/i965/brw_vue_map.c
|
| 38eb9015e3be9b93248e64b6befce16872107a7c |
|
15-May-2015 |
Kenneth Graunke <kenneth@whitecape.org> |
i965: Split VUE map handling out of brw_vs.c into brw_vue_map.c.
This was originally only used by the vertex shader, but it's now used by
the geometry shader as well, and will also eventually be used for
tessellation control and evaluation shaders.
I suspect it will be easier to find in a file named after the concept.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
/external/mesa3d/src/mesa/drivers/dri/i965/brw_vue_map.c
|