[Mesa-dev] [PATCH] glsl_to_tgsi: indirect array information

[Dave Airlie]

On Wed, Jan 23, 2013 at 9:44 AM, Vadim Girlin <vadimgirlin at gmail.com> wrote:
> On 01/22/2013 10:59 PM, Christoph Bumiller wrote:
>>
>> On 21.01.2013 21:10, Vadim Girlin wrote:
>>>
>>> Provide the information about indirectly addressable arrays (ranges of
>>> temps) in
>>> the shader to the drivers. TGSI representation itself isn't modified,
>>> array
>>> information is passed as an additional data in the pipe_shader_state, so
>>> the
>>> drivers can use it as a hint for optimization.
>>> ---
>>>
>>> It's far from being an ideal solution, but I saw the discussions about
>>> that
>>> problem starting from 2009 IIRC, and we still have no solution (neither
>>> good
>>> nor bad) despite the years passed. I hope we can use this not very
>>> intrusive
>>> approach until we get something better.
>>>
>>
>> I'd rather not have any hacks in the interface, let alone ones that
>> solve the problem only partially (you still won't know which array is
>> accessed by a particular instruction, which is important for
>> optimization and essential in some cases for making INPUT/OUTPUT arrays
>> work), and not just because it reduces the pressure on people to
>> implement a proper solution.
>>
>> With this, you just get to know which range of TEMPs are indirectly
>> addressed and which ones are not, and you can do the same by simply
>> creating multiple declarations of TEMPs, one for each array, and adding
>> a single bit of info to tgsi_declaration (which has 7 bits of padding
>> anyway, so ample space), which is a lot less ugly, and doesn't suffer
>> from an arbitrary limit, and doesn't require any modification of drivers
>> either.
>>
>
> Array accessed by any indirect operand can be identified by the immediate
> offset, e.g. TEMP[ADDR[0].x+1] implies the array starting from 1, thus we
> can find it's entry in the information provided by this patch to get the
> addressable range for every indirect operand. If I'm not missing something,
> glsl_to_tgsi accumulates all other parts of the offset in the address
> register before the indirect access. If I'm wrong, we can fix it to ensure
> such behavior.
>
> I'll be perfectly OK with any other solution, as long as it's a really
> working (already implemented) solution that I can use today, not just some
> abstract ideas in the discussions. This patch isn't perfect and can be
> improved, but it already works for me. I'll be very happy to use any other
> solution from you or anyone else.
>

It doesn't work like that, this patch isn't what I'd like either, it
hacks around the interface,

If what calim suggests works, then someone should be implementing that.

i prefer the idea that the TGSI shader is self contained.

Dave.