Am Freitag, den 02.02.2018, 09:04 +0100 schrieb Roland Scheidegger:
>
>
> Yes, the _GL spec_ says it is an array.
> But in gallium it can't be. Therefore I think it's incorrect if we
> end up with array accesses there (albeit I was too lazy to actually
> look at the tgsi, but I'm pretty sure it isn't declard as an array).
the TGSI for the relevant shader in the piglit looks like this:
FRAG
DCL SV[0], SAMPLEMASK
DCL OUT[0], COLOR
DCL CONST[0][0]
DCL TEMP[0..1], LOCAL
DCL ADDR[0]
IMM[0] FLT32 { 1.0000, 0.0000, 0.0000, 0.0000}
IMM[1] INT32 {1, 0, 0, 0}
0: MOV TEMP[0], IMM[0].xyyx
1: UARL ADDR[0].x, CONST[0][0].xxxx
2: USEQ TEMP[1].x, SV[ADDR[0].x].xxxx, IMM[1].xxxx
3: UIF TEMP[1].xxxx
4: MOV TEMP[0].xy, IMM[0].yxyy
5: ENDIF
6: MOV OUT[0], TEMP[0]
7: END
So it is kind of declared as an array of one element, and it is
accessed indirectly using the ADDR register, even though this must
currently be be zero on all supported hardware.
In tgsi_scan.c:246 the indirect flag is set based on
src->Register.File if an indirect access is recorded, and given in the
TGSI it is an indirect access, the flag is, of course, set.
This flag is then simply copied in r600_shader_from_tgsi and the only
time when TGSI_FILE_SYSTEM_VALUE becomes relevant is in r600/sb where
this patch would be applied.
I haven't looked at how other drivers deal with this, but I think since
the way sb handles this is a regression compared to running without sb
it should be fixed there.
Best,
Gert
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
