On 07/19/2016 01:45 PM, Ian Romanick wrote: > 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.
It is decided... the test will stand as-is, and the GLSL spec will be updated to explicitly say that subroutine uniforms cannot be compared using == or !=. So... I think I like Andres's patch slightly better than Dave's, but I don't care too much. Either patch can have my Reviewed-by: Ian Romanick <ian.d.roman...@intel.com> >> 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev