2015-07-07 16:58 GMT+02:00 Henri Verbeet hverbeet@gmail.com:
On 6 July 2015 at 22:20, Matteo Bruni mbruni@codeweavers.com wrote:
static const char *shader_glsl_get_version(const struct wined3d_gl_info *gl_info, const struct wined3d_shader_version *version) {
- if (gl_info->glsl_version >= MAKEDWORD_VERSION(1, 30) && version->major >= 4)
- if (!gl_info->supported[WINED3D_GL_LEGACY_CONTEXT])
return "#version 150";- else if (gl_info->glsl_version >= MAKEDWORD_VERSION(1, 30) && version && version->major >= 4) return "#version 130"; else return "#version 120";
Is GLSL 1.20 unavailable in core contexts? I only glanced over the spec, but didn't immediately see anything that explicitly makes earlier versions unavailable.
Yes. The 3.2 spec mentions "OpenGL 3.2 implementations are guaranteed to support versions 1.40 and 1.50 of the OpenGL Shading Language." and then, under the "Removed Features" section: "OpenGL Shading Language versions 1.10 and 1.20. These versions of the shading language depend on many API features that have also been deprecated."
That said, I hacked something and it looks like GLSL 1.20 shaders work on a core profile context on Mesa, at least to some degree. It sounds like that's more of a Mesa bug than something we could rely on though. FWIW I'm pretty sure OS X requires GLSL 1.50 (because in practice it only supports forward-compatible contexts).
What's a bit unfortunate about this is that drivers may decide to use different floating point rules (in particular wrt. multiplications by zero) depending on the GLSL version. IIRC at least r600g considered doing that at some point, although I'd have to check if that's currently the case.
Yeah, there might be some "surprise" issues in that regard. FWIW the fp_special_test() gives the same results here on r600g with core vs legacy contexts but I'm not sure it exercises the relevant codepath. But maybe that was radeonsi instead?