I'd be a big fan of letting it go.. if needed for old ARB shader stuff we can give entire IN/OUT file ArrayID==1.. if someone points me in the right direction I don't mind going and poking at it since the whole assuming-the-worst thing if ArrayID==0 is not so nice for register allocation..
BR, -R On Wed, Jun 24, 2015 at 10:38 PM, Roland Scheidegger <srol...@vmware.com> wrote: > 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
