Commen=
t # 8
on bug 10952=
4
from Ilia Mirkin
Doing a little more digging, we enabled GL_ARB_shading_languag=
e_100
unconditionally in 2013:
commit 70966570f3e4275dc15b5a94c70698f6aef64150
Author: Ian Romanick <ia=
n.d.romanick@intel.com>
Date: Thu Jun 27 18:20:31 2013 -0700
mesa: GL_ARB_shading_language_100 is not optional
However it appears that wine code has something like
https://source.wineh=
q.org/git/wine.git/blob/201d13a3c31131f204f89d61be37bf75d58dc6dd:/dlls/wine=
d3d/adapter_gl.c#l3737
3737 if (gl_info->supported[ARB_SHADING_LANGUAGE_100])
3738 {
3739 const char *str =3D (const char
*)gl_info->gl_ops.gl.p_glGetString(GL_SHADING_LANGUAGE_VERSION_ARB);
3740 unsigned int major, minor;
3741=20
3742 TRACE("GLSL version string: %s.\n", debugstr_a(str));
3743=20
3744 /* The format of the GLSL version string is "major.minor[=
.release]
[vendor info]". */
3745 sscanf(str, "%u.%u", &major, &minor);
3746 gl_info->glsl_version =3D MAKEDWORD_VERSION(major, minor);
I think the debugstr_a(NULL) is giving problems, but if it's not, sscanf
probably will.
I'm not 100% sure who's right here. Certainly the GL_ARB_shading_language_1=
00
spec talks about GL_SHADING_LANGUAGE_VERSION_ARB not being available due to=
it
not existing in early extension specs.=20
However the current behavior is a bit questionable on the mesa side. I don't
know what the rationale was for always exposing the ext (as given, it's bec=
ause
one ought to check for ARB_vertex_program/etc, but that seems weak).