[Mesa-dev] [RFC] gallium/hud: fix issue w/ tgsi_to_nir

[Marek Olšák]

Indirect addressing without the ArrayID is undefined in the general
case. You need the ArrayID to be able to tell where the array
declaration starts and what its semantic name is.

Marek

On Wed, Jun 24, 2015 at 8:35 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Wed, Jun 24, 2015 at 12:31 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> Yes, ArrayID != 0 means it's an array, otherwise it's just a compact
>> way to add declarations.
>
> ok.. hmm, I guess tgsi.rst needs an update then..
>
>> I recently added the array support for inputs and outputs, we just
>> need to enable it on non-radeon non-swrast drivers:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=b6ebe7eabf54936a02acc0968e718e0c264a73f5
>
> ok, in principle (after fixing ttn based on the assumption that we
> won't get indirect access if ArrayID==0, and now that tgsi f/e is
> dropped) freedreno should be ok for array in/out's..  I'll enable the
> cap and see what happens after fixing ttn and debugging some indirect
> issues (seems either there is something I don't understand about the
> hw yet, or maybe an a4xx bug.. right now shaders that I think should
> work aren't and I'm in android hell trying to get some more traces
> from blob :-/)
>
> BR,
> -R
>
>> It would be nice to enable the arrays on all drivers instead of
>> working around it indefinitely.
>>
>> Marek
>>
>> On Wed, Jun 24, 2015 at 1:31 PM, Rob Clark <robdclark at gmail.com> wrote:
>>> Ok, I *thought* we didn't get ArrayID on IN/OUT, but only TEMP?  If it
>>> is safe to assume that we always get ArrayID that makes it much
>>> easier.
>>>
>>> BR,
>>> -R
>>>
>>> On Wed, Jun 24, 2015 at 5:39 AM, Marek Olšák <maraeo at gmail.com> wrote:
>>>> It's not an array, because the ArrayID is 0. It's a valid non-array
>>>> declaration. If any TGSI user doesn't understand it, that user should
>>>> be fixed.
>>>>
>>>> Marek
>>>>
>>>> On Tue, Jun 23, 2015 at 3:20 PM, Rob Clark <robdclark at gmail.com> wrote:
>>>>> From: Rob Clark <robclark at freedesktop.org>
>>>>>
>>>>> Ok, so actually there is a ttn issue here to fix as well.. but it
>>>>> brought up a question in my mind.  When ttn sees something like
>>>>>
>>>>>   DCL IN[0..1]
>>>>>
>>>>> it will treat that as an array (which in the end will result in
>>>>> constraints about where the registers get allocated.  Which is not
>>>>> really ideal.
>>>>>
>>>>> With glsl we don't actually get input arrays (but instead a bunch
>>>>> of MOV's to a TEMP array) currently.  So I'm not quite sure how
>>>>> an actual input array should look.  (But my preference would be
>>>>> IN[a..b] for arrays and IN[c] otherwise)
>>>>> ---
>>>>>  src/gallium/auxiliary/hud/hud_context.c | 3 ++-
>>>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/src/gallium/auxiliary/hud/hud_context.c b/src/gallium/auxiliary/hud/hud_context.c
>>>>> index 6a124f7..2b6d3a7 100644
>>>>> --- a/src/gallium/auxiliary/hud/hud_context.c
>>>>> +++ b/src/gallium/auxiliary/hud/hud_context.c
>>>>> @@ -1163,7 +1163,8 @@ hud_create(struct pipe_context *pipe, struct cso_context *cso)
>>>>>     {
>>>>>        static const char *vertex_shader_text = {
>>>>>           "VERT\n"
>>>>> -         "DCL IN[0..1]\n"
>>>>> +         "DCL IN[0]\n"
>>>>> +         "DCL IN[1]\n"
>>>>>           "DCL OUT[0], POSITION\n"
>>>>>           "DCL OUT[1], COLOR[0]\n" /* color */
>>>>>           "DCL OUT[2], GENERIC[0]\n" /* texcoord */
>>>>> --
>>>>> 2.4.3
>>>>>
>>>>> _______________________________________________
>>>>> mesa-dev mailing list
>>>>> mesa-dev at lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev