[Mesa-dev] [PATCH] nir: special hack for TGSI vs indirect inputs

Marek Olšák maraeo at gmail.com
Mon Jan 11 10:52:24 PST 2016


On Mon, Jan 11, 2016 at 6:07 PM, Rob Clark <robdclark at 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)

Marek

>
> BR,
> -R
>
> On Mon, Jan 11, 2016 at 11:47 AM, Ilia Mirkin <imirkin at 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 <robdclark at gmail.com> wrote:
>>> From: Rob Clark <robclark at 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 <robclark at 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 at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list