[Mesa-dev] [PATCH] glsl/ast: don't allow subroutine uniform comparisons

[Ian Romanick]

On 07/19/2016 06:54 AM, Andres Gomez wrote:
> Hi,
> 
> Just dropped:
> https://lists.freedesktop.org/archives/mesa-dev/2016-July/123485.html
> 
> I didn't realize there was already this thread open.
> 
> On Tue, 2016-06-07 at 09:59 -0700, Ian Romanick wrote:
>> On 06/06/2016 10:20 PM, Dave Airlie wrote:
>>> From: Dave Airlie <airlied at redhat.com>
>>>
>>> This fixes:
>>> GL45-CTS.shader_subroutine.subroutines_cannot_be_assigned_float_int_values_or_be_compared
>>>
>>> though I'm not 100% sure why this is illegal from the spec,
>>> but it makes us pass the test, and I really can't see a use case for this.
>>
>> I think the test is wrong.  Section 5.9 (Expressions) of the GLSL 4.5
>> spec clearly says:
>>
>>     The equality operators equal (==), and not equal (!=) operate on
>>     all types (except aggregates that contain opaque types).
> 
> In my opinion, the specs are somehow contradictory or not completely
> clear.
> 
> AFAIU, subroutine variables are to be used just in the way functions
> are called. Although the spec doesn't say it explicitly, this means
> that these variables are not to be used in any other way than those
> left for function calls. Therefore, a comparison between 2 subroutine
> variables should also cause a compilation error.
> 
> From The OpenGL® Shading Language 4.40, page 117:
> 
>   "  To use subroutines, a subroutine type is declared, one or more
>      functions are associated with that subroutine type, and a
>      subroutine variable of that type is declared. The function
>      currently assigned to the variable function is then called by
>      using function calling syntax replacing a function name with the
>      name of the subroutine variable. Subroutine variables are
>      uniforms, and are assigned to specific functions only through
>      commands (UniformSubroutinesuiv) in the OpenGL API."
> 
> From The OpenGL® Shading Language 4.40, page 118:
> 
>   "  Subroutine uniform variables are called the same way functions
>      are called. When a subroutine variable (or an element of a
>      subroutine variable array) is associated with a particular
>      function, all function calls through that variable will call that
>      particular function."
> 
>> As much as anyone would use subroutines, you could imagine this being
>> used like:
>>
>>     value = foo(param1, param2);
>>     if (foo != bar)
>>         value += bar(param1, param2);
> 
> If that would be the case, and we agree that subroutines can be
> compared, then we have, at least, some other bug to correct.
> 
> I've made some piglit tests with the following scenarios:
>  * == comparison result:
>     * foo and bar point to the same subroutine function -> false
>     * foo and bar point to different subroutine functions -> false
>  * != comparison result:
>     * foo and bar point to the same subroutine function -> false
>     * foo and bar point to different subroutine functions -> false
> 
> So, what would be the conclusion? Do we allow subroutine variables comparison?

There is no conclusion yet.  I opened a Khronos gitlab tracker (right
after Dave sent his original patch) for the CTS.  I'll try to get it on
the conference call agenda for this week.

> FTR, I passed this patch through an "all" piglit run and through GL44 CTS and it doesn't cause any regression.