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 <airl...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
