I thought this was needed by something in the gl state tracker. relative addressing with ARB_vp maybe, can't remember... I dunno if all places where this is used are fixed up it can go.
Roland Am 25.06.2015 um 01:31 schrieb Rob Clark: > tgsi.rst currently says: > > ---- > If no ArrayID is specified with an indirect addressing operand the whole > register file might be accessed by this operand. This is strongly discouraged > and will prevent packing of scalar/vec2 arrays and effective alias analysis. > ---- > > I'd be pretty happy to remove it and replace it w/ something to the > effect of indirect addressing where no ArrayID is specified is > undefined :-) > > BR, > -R > > On Wed, Jun 24, 2015 at 6:17 PM, Marek Olšák <mar...@gmail.com> wrote: >> 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 <robdcl...@gmail.com> wrote: >>> On Wed, Jun 24, 2015 at 12:31 PM, Marek Olšák <mar...@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 <robdcl...@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 <mar...@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 <robdcl...@gmail.com> wrote: >>>>>>> From: Rob Clark <robcl...@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@lists.freedesktop.org >>>>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
