From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 109524] "Invalid glsl version in shading_language_version()"
when trying to run directX games using wine
Date: Thu, 31 Jan 2019 20:50:10 +0000
Message-ID:
Bug ID
109524
Summary
"Invalid glsl version in shading_language_version()"=
; when trying to run directX games using wine
Product
Mesa
Version
18.2
Hardware
x86 (IA32)
OS
All
Status
NEW
Severity
normal
Priority
medium
Component
Drivers/DRI/R100
Assignee
dri-devel@lists.freedesktop.org
Reporter
laszlo.erdoes@freenet.de
QA Contact
dri-devel@lists.freedesktop.org
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=3DMesa
wine: Unhandled page fault on read access to 0x00000000 at address 0xb7bf14=
40
(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.
| What | Removed | Added |
|---|---|---|
| URL | http://www.onedollarwebhostings.com/rs-99-web-hosting-domain= -godaddy-india.html |
Such a nice post you shared with the audience. http://www.onedollarwebhostings.com/rs-99-web-hosting-doma= in-godaddy-india.html is the great to visit.
I have had the same problem in Mesa 19.0.0 with the Nouveau dr= iver. It seems that any card without hardware shaders is failing. This was tested with NV= 05 and NV11.
Connected to this bug report on WineHQ: https://bugs.wi= nehq.org/show_bug.cgi?id=3D47389 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 Me= sa?
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 so= rt that can be used to > reproduce this? I have such a GPU plugged in I can test with, but I ne= ed a > repro. You can try this console emulator, it will crash on my old machine with the affected GPU: http://fileland.square7.ch/t= 2k.zip
This patch should avoid the error being printed: https://patchwo= rk.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_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).
| What | Removed | Added |
|---|---|---|
| URL | http://www.onedollarwebhostings.com/rs-99-web-hosting-domain= -godaddy-india.html |
Note that the following patch makes the t2k thing that was att=
ached 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_sam=
ples
, GLL, GLC, x , x , 2014)
EXT(ARB_shader_texture_lod , ARB_shader_texture_lod=20=20=
=20=20=20=20=20=20=20=20
, GLL, GLC, x , x , 2009)
EXT(ARB_shader_viewport_layer_array , ARB_shader_viewport_layer_ar=
ray=20
, GLL, GLC, x , x , 2015)
-EXT(ARB_shading_language_100 , dummy_true=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
, GLL, x , x , x , 2003)
+EXT(ARB_shading_language_100 , dummy_true=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
, 15, x , x , x , 2003)
EXT(ARB_shading_language_420pack , ARB_shading_language_420pack=
=20=20=20=20
, GLL, GLC, x , x , 2011)
EXT(ARB_shading_language_packing , ARB_shading_language_packing=
=20=20=20=20
, GLL, GLC, x , x , 2011)
EXT(ARB_shadow , ARB_shadow=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
, GLL, x , x , x , 2001)
A better patch from Ian: https://patchwork.freedesktop.org/patch/315771/<= /pre>
(In reply to Ilia Mirkin from comment #10) > A better patch from Ian: https://patchwork.freedesktop.org/patc= h/315771/ Thanks, this patch works on my machine.
On Debian Testing I still have Mesa 18.3.6; so do I have to bu= ild Mesa from source code in order to get the patch?
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |
(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=E2=80=99ll wait until it gets committed to Debian re= positories.