Comment # 8
on bug 109524
from Ilia Mirkin
Doing a little more digging, we enabled GL_ARB_shading_language_100 unconditionally in 2013: commit 70966570f3e4275dc15b5a94c70698f6aef64150 Author: Ian Romanick <ian.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.winehq.org/git/wine.git/blob/201d13a3c31131f204f89d61be37bf75d58dc6dd:/dlls/wined3d/adapter_gl.c#l3737 3737 if (gl_info->supported[ARB_SHADING_LANGUAGE_100]) 3738 { 3739 const char *str = (const char *)gl_info->gl_ops.gl.p_glGetString(GL_SHADING_LANGUAGE_VERSION_ARB); 3740 unsigned int major, minor; 3741 3742 TRACE("GLSL version string: %s.\n", debugstr_a(str)); 3743 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 = 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_100 spec talks about GL_SHADING_LANGUAGE_VERSION_ARB not being available due to it not existing in early extension specs. 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 because one ought to check for ARB_vertex_program/etc, but that seems weak).
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
