On 23.08.2017 15:49, Ilia Mirkin wrote:
On Wed, Aug 23, 2017 at 9:20 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
On 22.08.2017 16:56, Ilia Mirkin wrote:
On Tue, Aug 22, 2017 at 10:51 AM, Roland Scheidegger <srol...@vmware.com>
wrote:
I am probably missing something here, but why do you need a new register
file? Since you couldn't use LOAD with TGSI_FILE_CONSTANT before, can't
you just allow LOAD with TGSI_FILE_CONSTANT and achieve the same thing?
Or do you need to know how it's going to be accessed in advance?
With bindless, LOAD can take a CONST I believe [which contains the
value of the bindless id]. I think it's nice to keep those concepts
separate... having CONST sometimes mean the value and other times mean
the address is a bit weird. This way CONSTBUF[0] is the address of the
0th constbuf.
I'm still not quite convinced. The levels of indirection should clarify the
meaning, shouldn't they?
You get
LOAD dst, CONST[0][0], IMM[0]
when loading from offset IMM[0] of a bindless buffer whose handle is at the
beginning of the buffer CONST[0].
You get
LOAD dst, CONST[0], IMM[0]
when loading from offset IMM[0] of non-bindless buffer 0.
Is there ever really a situation where the two could be confused?
I always considered CONST[0] == CONST[0][0]. Technically they're not,
since once has the second dimension in the TGSI encoding while the
other doesn't. But practically,
MOV TEMP[0], CONST[0]
and
MOV TEMP[0], CONST[0][0]
are in every way identical. Currently st/mesa will just use CONST[0]
everywhere, never adding the 2nd dimension. As such, I don't think we
should start having behavioural differences for those on some
instructions.
Oh, you're right, CONST[n] and CONST[0][n] are treated the same. That's
pretty inconsistent and unfortunate :/
I suppose the CONSTBUF thing is fine, then.
Cheers,
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
