Summary: | "Invalid glsl version in shading_language_version()" when trying to run directX games using wine | ||
---|---|---|---|
Product: | Mesa | Reporter: | laszlo.erdoes |
Component: | Drivers/DRI/R100 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | Default DRI bug account <dri-devel> |
Severity: | normal | ||
Priority: | medium | ||
Version: | 18.2 | ||
Hardware: | x86 (IA32) | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
laszlo.erdoes
2019-01-31 20:50:10 UTC
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 > repro. You can try this console emulator, it will crash on my old machine with the affected GPU: http://fileland.square7.ch/t2k.zip This patch should avoid the error being printed: https://patchwork.freedesktop.org/patch/315751/ 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: 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). 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 --- a/src/mesa/main/extensions_table.h +++ b/src/mesa/main/extensions_table.h @@ -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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.