<div dir="ltr">On 16 October 2013 22:30, Kenneth Graunke <<a href="mailto:kenneth@whitecape.org" target="_blank">kenneth@whitecape.org</a>> wrote: <div class="gmail_extra"><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 10/16/2013 04:56 PM, Ian Romanick wrote: > On 10/16/2013 10:29 AM, Paul Berry wrote: >> --- >> >> I'm not 100% sure this is the right way to go, and here's why: >> >> Taken together, all the GLSL specs except GLSL 4.30 and GLSL 4.40 tell >> a consistent story: desktop shader versions 1.10 and 1.20 may be >> linked together, and desktop shader versions 1.40 and above may be >> linked together. No other cross-version linking is allowed. >> >> However, cross-version linking restrictions were explicitly removed in >> GLSL 4.30 (the change is listed under "Summary of Changes from Version >> 4.20 as "Remove cross-version linking restrictions."). GLSL 4.30 and >> 4.40 state that *any* version of desktop GLSL may be linked with any >> other version of desktop GLSL. (Note that cross-version linking is >> still prohibited for ES shaders). > > This came from a Khronos bug that I submitted. The problem is that no > other driver enforces the spec mandated restriction. On top of that, > you can't fully enforce the restriction (without draw-time errors) with > separate shader objects. I *thought* the change in 4.3 was to allow > mixed versions between stages, but mixing versions within a stage is > still forbidden. > >> This leads to a conundrum. Normally when the GLSL spec changes from >> one version to the next, we implement different rules depending on the >> user-supplied "#version" directive. But we can't do that for >> cross-version linking rules since it's not clear which version of GLSL >> should apply. Should we: >> >> (a) always follow pre-GLSL 4.30 linking rules, since we don't support >> GLSL 4.30 yet? (that's what this patch implements). >> >> (b) always follow post-GLSL 4.30 linking rules, since they're probably >> the clearest reflection of the Khronos board's intent? >> >> (c) make some kind of dynamic determination of which set of rules to >> follow? >> >> FWIW, the NVIDIA proprietary driver for Linux (version 313.18) appears >> to implement (b). > > There are different cases: intrastage and interstage. I assume they > allow mixing interstage. What about intrastage? </div></div>I ran a quick test on my AMD Radeon 6870, using Catalyst 13.10 (which supports 4.30). It allowed both kinds of linking. Here's my test: [require] GL >= 2.1 GLSL >= 1.10 [vertex shader] #version 400 compatibility void main() { gl_Position = gl_Vertex; } [fragment shader] #version 330 core uniform vec4 color; vec4 get_color() { return color; } [fragment shader] #version 110 vec4 get_color(); void main() { gl_FragColor = get_color(); } [test] uniform vec4 color 0 1 0 1 draw rect -1 -1 2 2 relative probe rgba (0.5, 0.5) (0.0, 1.0, 0.0, 1.0) </blockquote></div> </div><div class="gmail_extra">Ok, thanks Ken. Based on the NVIDIA results, and further discussion with Ian this morning, I'm going to NAK this patch and follow up with a patch that allows all desktop GLSL versions to be inter-linked. </div><div class="gmail_extra">(BTW, for any Khronos members, the Khronos bug that led to this change is bug 8463) </div></div>