[Mesa-dev] [PATCH] glsl_to_tgsi: indirect array information
airlied at gmail.com
Tue Jan 22 16:07:20 PST 2013
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,
>>> information is passed as an additional data in the pipe_shader_state, so
>>> drivers can use it as a hint for optimization.
>>> It's far from being an ideal solution, but I saw the discussions about
>>> problem starting from 2009 IIRC, and we still have no solution (neither
>>> nor bad) despite the years passed. I hope we can use this not very
>>> 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
> Array accessed by any indirect operand can be identified by the immediate
> offset, e.g. TEMP[ADDR.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.
More information about the mesa-dev