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
