On Wed, Jan 23, 2013 at 9:44 AM, Vadim Girlin <vadimgir...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
