On Mon, Jan 11, 2016 at 1:52 PM, Marek Olšák <mar...@gmail.com> wrote:
> On Mon, Jan 11, 2016 at 6:07 PM, Rob Clark <robdcl...@gmail.com> wrote:
>> Quite possibly I am.. although wouldn't I still have the same issue
>> with other state trackers? So in that case I'd have to detect
>> indirect access, but without ArrayID's, and still set this flag.
>
> Yes, PIPE_SHADER_CAP_TGSI_ANY_INOUT_DECL_RANGE adds array support for
> TGSI inputs and outputs. If ArrayID > 0, there is an array
> declaration. If ArrayID == 0, the entire file is an array. This
> applies to all files.(input, output, temp)
The question is whether there would be any ArrayID==0 case that we
actually care about. I suppose wine/nine-st isn't worth caring about
on arm (vc4/freedreno). Unsure about other state trackers (or ARB
shader or other cases coming from mesa-st)?
(fwiw, I would fail pretty hard for TEMP w/ ArrayID==0, that just
kills any hope of register allocation.. but I think that is a stupid
enough case that no one should expect it to work.)
BR,
-R
> Marek
>
>>
>> BR,
>> -R
>>
>> On Mon, Jan 11, 2016 at 11:47 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>>> Are you looking for PIPE_SHADER_CAP_TGSI_ANY_INOUT_DECL_RANGE perchance?
>>>
>>> On Mon, Jan 11, 2016 at 11:44 AM, Rob Clark <robdcl...@gmail.com> wrote:
>>>> From: Rob Clark <robcl...@freedesktop.org>
>>>>
>>>> TGSI doesn't know about array input (or output[*]) variables. If the
>>>> INPUT file is addressed indirectly, we must treat the entire INPUT
>>>> "register file" as one contiguous array. However tgsi_to_nir cannot
>>>> declare all the inputs as a single array var, as this would loose
>>>> varying slot and interpolation info.
>>>>
>>>> This hack provides the extra information that the compiler backend
>>>> needs so that all the N inputs can be organized as a single array for
>>>> direct and indirect access.
>>>>
>>>> [*] tgsi_to_nir does not generate indirect output stores, otherwise we
>>>> would need a similar hack for outputs
>>>>
>>>> Signed-off-by: Rob Clark <robcl...@freedesktop.org>
>>>> ---
>>>> Yes, sorry, I know, TGSI is horrible. But I don't really have any
>>>> better ideas about how to handle this.
>>>>
>>>> src/gallium/auxiliary/nir/tgsi_to_nir.c | 3 +++
>>>> src/glsl/nir/nir.h | 14 ++++++++++++++
>>>> 2 files changed, 17 insertions(+)
>>>>
>>>> diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
>>>> b/src/gallium/auxiliary/nir/tgsi_to_nir.c
>>>> index 94d992b..4a57f9e 100644
>>>> --- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
>>>> +++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
>>>> @@ -1973,6 +1973,9 @@ tgsi_to_nir(const void *tgsi_tokens,
>>>> options);
>>>> s = c->build.shader;
>>>>
>>>> + if (c->scan->indirect_files & (1 << TGSI_FILE_INPUT))
>>>> + s->info.tgsi_hack_indirect_inputs = true;
>>>> +
>>>> s->num_inputs = scan.file_max[TGSI_FILE_INPUT] + 1;
>>>> s->num_uniforms = scan.const_file_max[0] + 1;
>>>> s->num_outputs = scan.file_max[TGSI_FILE_OUTPUT] + 1;
>>>> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
>>>> index bedcc0d..629c32f 100644
>>>> --- a/src/glsl/nir/nir.h
>>>> +++ b/src/glsl/nir/nir.h
>>>> @@ -1510,6 +1510,20 @@ typedef struct nir_shader_info {
>>>> /** Was this shader linked with any transform feedback varyings? */
>>>> bool has_transform_feedback_varyings;
>>>>
>>>> + /**
>>>> + * Special hack for tgsi_to_nir. Due to limitations in TGSI, when
>>>> + * there is indirect addressing of the input file, we don't actually
>>>> + * know which inputs are part of an array and which are not. We
>>>> + * cannot convert all the inputs to a single array (which maps to
>>>> + * TGSI's IN[ADDR[0].x+n] semantics), since we need the varying-slot
>>>> + * and interpolation information still.
>>>> + *
>>>> + * NOTE that tgsi_to_nir doesn't generate indirect output_store's,
>>>> + * otherwise we would need a similar flag to indicate indirect
>>>> + * output file addressing.
>>>> + */
>>>> + bool tgsi_hack_indirect_inputs;
>>>> +
>>>> union {
>>>> struct {
>>>> /** The number of vertices recieves per input primitive */
>>>> --
>>>> 2.5.0
>>>>
>>>> _______________________________________________
>>>> 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
