On 11/30/2015 03:51 PM, Ilia Mirkin wrote:
> On Mon, Nov 30, 2015 at 6:38 PM, Matt Turner <matts...@gmail.com> wrote:
>> On Mon, Nov 30, 2015 at 3:34 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>>> On Mon, Nov 30, 2015 at 6:32 PM, Matt Turner <matts...@gmail.com> wrote:
>>>> ---
>>>> src/glsl/builtin_functions.cpp | 15 ++++++++++++++-
>>>> 1 file changed, 14 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/src/glsl/builtin_functions.cpp
>>>> b/src/glsl/builtin_functions.cpp
>>>> index 88f9a71..2f21ffc 100644
>>>> --- a/src/glsl/builtin_functions.cpp
>>>> +++ b/src/glsl/builtin_functions.cpp
>>>> @@ -538,6 +538,7 @@ private:
>>>> ir_variable *in_var(const glsl_type *type, const char *name);
>>>> ir_variable *out_var(const glsl_type *type, const char *name);
>>>> ir_constant *imm(float f, unsigned vector_elements=1);
>>>> + ir_constant *imm(bool b, unsigned vector_elements=1);
>>>> ir_constant *imm(int i, unsigned vector_elements=1);
>>>> ir_constant *imm(unsigned u, unsigned vector_elements=1);
>>>> ir_constant *imm(double d, unsigned vector_elements=1);
>>>> @@ -3000,6 +3001,12 @@ builtin_builder::out_var(const glsl_type *type,
>>>> const char *name)
>>>> }
>>>>
>>>> ir_constant *
>>>> +builtin_builder::imm(bool b, unsigned vector_elements)
>>>> +{
>>>> + return new(mem_ctx) ir_constant(b, vector_elements);
>>>> +}
>>>> +
>>>> +ir_constant *
>>>> builtin_builder::imm(float f, unsigned vector_elements)
>>>> {
>>>> return new(mem_ctx) ir_constant(f, vector_elements);
>>>> @@ -4358,7 +4365,13 @@
>>>> builtin_builder::_notEqual(builtin_available_predicate avail,
>>>> ir_function_signature *
>>>> builtin_builder::_any(const glsl_type *type)
>>>> {
>>>> - return unop(always_available, ir_unop_any, glsl_type::bool_type, type);
>>>> + ir_variable *v = in_var(type, "v");
>>>> + MAKE_SIG(glsl_type::bool_type, always_available, 1, v);
>>>> +
>>>> + const unsigned vec_elem = v->type->vector_elements;
>>>> + body.emit(ret(expr(ir_binop_any_nequal, v, imm(false, vec_elem))));
>>>
>>> This results in an extra comparison generated by the st_glsl_to_tgsi
>>> code, which can be annoying to get rid of... Why do you need to do
>>> this?
>>
>> Couldn't we fix the st_glsl_to_tgsi to handle that better? I wouldn't
>> be surprised to find such a thing in the wild.
>
> I guess it could special-case the exact IR generated there? The thing
> is that it just OR's everything together (when you have native integer
> support... which everything does outside of r300/nv30), which you can
> only do in a few select cases. If you'd like to implement that, I
> wouldn't object. As-is, it's a pessimization though.
That's weird. On a scalar architecture, the backend optimizer should be
able to easily optimize (x != 0) || (y != 0) || (z != 0) || (w != 0) to
(x | y | z | w) != 0. As Matt says, we've observed a LOT of
applications open-code this, so optimizing this sequence is generally
helpful. I wonder if NIR has an opt-algebraic pattern for this...
On vector architectures, you should have been generating a dot-product
for ir_unop_any to begin with, and that shouldn't change for this either.
> -ilia
> _______________________________________________
> 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
