[Mesa-dev] [PATCH 1/2] nir: Add a function to determine if a source is dynamically uniform
Francisco Jerez
currojerez at riseup.net
Fri Oct 2 09:34:48 PDT 2015
Matt Turner <mattst88 at gmail.com> writes:
> On Fri, Oct 2, 2015 at 2:52 AM, Francisco Jerez <currojerez at riseup.net> wrote:
>> Jason Ekstrand <jason at jlekstrand.net> writes:
>>
>>> On Oct 1, 2015 12:18 PM, "Matt Turner" <mattst88 at gmail.com> wrote:
>>>>
>>>> On Fri, Aug 7, 2015 at 9:31 AM, Neil Roberts <neil at linux.intel.com> wrote:
>>>> > Adds nir_src_is_dynamically_uniform which returns true if the source
>>>> > is known to be dynamically uniform. This will be used in a later patch
>>>> > to add a workaround for cases that only work with dynamically uniform
>>>> > sources. Note that the function is not definitive, it can return false
>>>> > negatives (but not false positives). Currently it only detects
>>>> > constants and uniform accesses. It could easily be extended to include
>>>> > more cases.
>>>> > ---
>>>> > src/glsl/nir/nir.c | 29 +++++++++++++++++++++++++++++
>>>> > src/glsl/nir/nir.h | 1 +
>>>> > 2 files changed, 30 insertions(+)
>>>> >
>>>> > diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
>>>> > index 78ff886..242f0b4 100644
>>>> > --- a/src/glsl/nir/nir.c
>>>> > +++ b/src/glsl/nir/nir.c
>>>> > @@ -1784,6 +1784,35 @@ nir_src_as_const_value(nir_src src)
>>>> > return &load->value;
>>>> > }
>>>> >
>>>> > +/**
>>>> > + * Returns true if the source is known to be dynamically uniform.
>>> Otherwise it
>>>> > + * returns false which means it may or may not be dynamically uniform
>>> but it
>>>> > + * can't be determined.
>>>> > + */
>>>> > +bool
>>>> > +nir_src_is_dynamically_uniform(nir_src src)
>>>> > +{
>>>> > + if (!src.is_ssa)
>>>> > + return false;
>>>> > +
>>>> > + /* Constants are trivially dynamically uniform */
>>>> > + if (src.ssa->parent_instr->type == nir_instr_type_load_const)
>>>> > + return true;
>>>> > +
>>>> > + /* As are uniform variables */
>>>> > + if (src.ssa->parent_instr->type == nir_instr_type_intrinsic) {
>>>> > + nir_intrinsic_instr *intr =
>>> nir_instr_as_intrinsic(src.ssa->parent_instr);
>>>> > +
>>>> > + if (intr->intrinsic == nir_intrinsic_load_uniform)
>>>> > + return true;
>>>> > + }
>>>> > +
>>>> > + /* XXX: this could have many more tests, such as when a sampler
>>> function is
>>>> > + * called with dynamically uniform arguments.
>>>> > + */
>>>> > + return false;
>>>> > +}
>>>>
>>>> This functions seems correct as-is, so it gets a
>>>>
>>>> Reviewed-by: Matt Turner <mattst88 at gmail.com>
>>>>
>>>> On top of being useful for fixing the nonconst/nonuniform piglit
>>>> tests, knowing which values are uniform can allow better optimization
>>>> and knowing which branches are uniform would allow us to enable Single
>>>> Program Flow.
>>>>
>>>> Cc'ing Jason for a discussion about how we'd like to handle this kind
>>>> of information in NIR. Add a bool is_uniform or something to
>>>> nir_ssa_def and hook into the metadata system?
>>>
>>> That was more-or-less my plan. We should probably have a proper pass that
>>> handles things like phi nodes and ALU operations.
>>>
>>
>> Heh, I hadn't noticed this series until now and happen to have started
>> to sketch such an analysis pass just this week, with a completely
>> unrelated purpose in mind (enable a restricted form of GCM for texturing
>> ops with implicit derivatives). Any volunteers to write it (Neil?) or
>> shall I go ahead with it?
>
> Interesting. In case you haven't seen it, Connor added nir_opt_gcm()
> some time ago, but it's not enabled because it hurts many things.
> Presumably you can reuse its code to implement your idea.
>
Yeah, I had seen Connor's pass and it seems like a good starting point,
thanks.
> I suspect you should go ahead and write the uniform analysis pass.
>
> Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151002/cb87f308/attachment.sig>
More information about the mesa-dev
mailing list