When I try running any software in wine that uses direct3D, I get the following message and an app crash:
Mesa 18.2.8 implementation error: Invalid GLSL version in shading_language_version()
Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
wine: Unhandled page fault on read access to 0x00000000 at address 0xb7bf1440 (thread 0009), starting debugger...
I'm using an R100 GPU. The problem wasn't present in some earlier versions of Mesa, I believe it still worked in some 17.x version.
Such a nice post you shared with the audience. http://www.onedollarwebhostings.com/rs-99-web-hosting-domain-godaddy-india.html is the great to visit.
I have had the same problem in Mesa 19.0.0 with the Nouveau driver. It seems that any card without hardware shaders is failing. This was tested with NV05 and NV11.
Connected to this bug report on WineHQ: https://bugs.winehq.org/show_bug.cgi?id=47389
Confirmed for Mesa 18.3.6. R100-class GPU too (ATI Mobility Radeon 7000 IGP).
R100 class Radeon GPUs only support OpenGL up to 1.3, while GLSL has only become a thing as an extension for 1.4 and finally an integral feature in 2.0. Does that mean OpenGL Shading Language support is nowadays necessary for Mesa?
Other applications using OpenGL (and so mesa, I guess?) still seem to work
NV05 and NV11 don't support GLSL at all. Some entry point must not be preventing it properly... perhaps something internal.
Is there like a wine test or something of the sort that can be used to reproduce this? I have such a GPU plugged in I can test with, but I need a repro.
(In reply to Ilia Mirkin from comment #5)
> Is there like a wine test or something of the sort that can be used to
> reproduce this? I have such a GPU plugged in I can test with, but I need a
You can try this console emulator, it will crash on my old machine with the affected GPU:
This patch should avoid the error being printed:
However I suspect that the calling code will continue to crash -- we return a NULL pointer, and I suspect that the caller expects this to be non-null.
Doing a little more digging, we enabled GL_ARB_shading_language_100 unconditionally in 2013:
Author: Ian Romanick <email@example.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
3737 if (gl_info->supported[ARB_SHADING_LANGUAGE_100])
3739 const char *str = (const char *)gl_info->gl_ops.gl.p_glGetString(GL_SHADING_LANGUAGE_VERSION_ARB);
3740 unsigned int major, minor;
3742 TRACE("GLSL version string: %s.\n", debugstr_a(str));
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).
Note that the following patch makes the t2k thing that was attached work fine. However I need to check with Ian as to what's up.
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 332a75e6c73..ec376e497df 100644
@@ -135,7 +135,7 @@ EXT(ARB_shader_subroutine , dummy_true
EXT(ARB_shader_texture_image_samples , ARB_shader_texture_image_samples , GLL, GLC, x , x , 2014)
EXT(ARB_shader_texture_lod , ARB_shader_texture_lod , GLL, GLC, x , x , 2009)
EXT(ARB_shader_viewport_layer_array , ARB_shader_viewport_layer_array , GLL, GLC, x , x , 2015)
-EXT(ARB_shading_language_100 , dummy_true , GLL, x , x , x , 2003)
+EXT(ARB_shading_language_100 , dummy_true , 15, x , x , x , 2003)
EXT(ARB_shading_language_420pack , ARB_shading_language_420pack , GLL, GLC, x , x , 2011)
EXT(ARB_shading_language_packing , ARB_shading_language_packing , GLL, GLC, x , x , 2011)
EXT(ARB_shadow , ARB_shadow , GLL, x , x , x , 2001)
A better patch from Ian: https://patchwork.freedesktop.org/patch/315771/
(In reply to Ilia Mirkin from comment #10)
> A better patch from Ian: https://patchwork.freedesktop.org/patch/315771/
Thanks, this patch works on my machine.
On Debian Testing I still have Mesa 18.3.6; so do I have to build Mesa from source code in order to get the patch?
The patch landed in Mesa 19.1.5.
(In reply to Juan A. Suarez from comment #13)
> The patch landed in Mesa 19.1.5.
I meant 19.1.4. Sorry.
Thanks! I’ll wait until it gets committed to Debian repositories.