On Sat, Jun 27, 2015 at 12:57 PM, Connor Abbott <cwabbo...@gmail.com> wrote: > On Sat, Jun 27, 2015 at 6:48 AM, Rob Clark <robdcl...@gmail.com> wrote: >> I had a quick look at enabling this for freedreno.. although looks >> like it is going to take some work in tgsi_to_nir and/or nir.. the >> problem is we end up w/ a register array (rather than variable array >> like we do for TEMP arrays).. ie. for something copying from a TEMP >> array to an OUT array, we end up like: >> >> vec4 ssa_35 = intrinsic load_var () (arr_2[0]) () >> vec4 ssa_36 = fmov ssa_35 >> r1[0] = fmov ssa_36 >> vec4 ssa_37 = intrinsic load_var () (arr_2[1]) () >> vec4 ssa_38 = fmov ssa_37 >> r1[1] = fmov ssa_38 >> vec4 ssa_39 = intrinsic load_var () (arr_2[2]) () >> vec4 ssa_40 = fmov ssa_39 >> r1[2] = fmov ssa_40 >> vec4 ssa_41 = intrinsic load_var () (arr_2[3]) () >> vec4 ssa_42 = fmov ssa_41 >> r1[3] = fmov ssa_42 >> vec4 ssa_43 = fmov r2 >> r0 = fmov ssa_43 >> intrinsic store_output (r0) () (0) >> intrinsic store_output (r1[0]) () (1) >> intrinsic store_output (r1[1]) () (2) >> intrinsic store_output (r1[2]) () (3) >> intrinsic store_output (r1[3]) () (4) >> >> the r1[] array ends up not getting converted into SSA and hitting an >> assert when we try to lower to scalar.. I'm not really sure the best >> way to handle this > > Well, the frontend shouldn't really be generating register arrays... > they're for backends, not frontends, and it's curently impossible to > eliminate them without extra information about the stride that I've > been hesitant to add, and even then they're more of a pain for > optimization passes. I'm not sure the exact place where ttn is > emitting a register array, but if you fix it to use a variable > instead, vars_to_ssa should clean it up.
I was thinking about this, since I'd already done the same for TEMP file arrays.. How should that end up looking, though, from the perspective of store_output? Can store_output reference a variable, or do I have to do a move into ssa and then pass the ssa src to store_output (effectively duplicating the lowering IN/OUT arrays that tgsi currently does in ttn) BR, -R >> >> BR, >> -R >> >> 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. >>> >>> 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 >>> >>> 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
