http://bugs.winehq.org/show_bug.cgi?id=34238
Bug #: 34238 Summary: Wine 1.6 Fails To Initialize Direct X in old Intel cards Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: shatteredlites@gmail.com Classification: Unclassified
In wine 1.4 all programs run fine with direct X but in 1.6 nothing runs unless there is a GL backend My specs are and all runs well in 1.4 but not in 1.6 Ubuntu 13.04 Memory 1.5 GiB Processor Intel® Pentium(R) 4 CPU 2.80GHz × 2 Graphics Intel® 915G x86/MMX/SSE2
err:d3d:wined3d_adapter_init_gl_caps Received a NULL GL_RENDERER. err:d3d:wined3d_adapter_init Failed to initialize GL caps for adapter 0x1437d8.
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #1 from Henri Verbeet hverbeet@gmail.com 2013-08-09 01:12:48 CDT --- Could you attach a WINEDEBUG="+wgl,+d3d" log?
http://bugs.winehq.org/show_bug.cgi?id=34238
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Version|unspecified |1.6
--- Comment #2 from Austin English austinenglish@gmail.com 2013-08-09 13:01:49 CDT --- Please run a regression test: http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #3 from shatteredlites@gmail.com 2013-08-10 02:00:28 CDT --- wine client error:0: version mismatch 431/440. Your wineserver binary was not upgraded correctly, or you have an older one somewhere in your PATH. Or maybe the wrong wineserver is still running?
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #4 from shatteredlites@gmail.com 2013-08-10 02:44:50 CDT --- Created attachment 45566 --> http://bugs.winehq.org/attachment.cgi?id=45566 Debug
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #5 from Lex lexleogryfon@mail.by 2013-08-11 03:57:57 CDT --- Created attachment 45575 --> http://bugs.winehq.org/attachment.cgi?id=45575 945 GL_RENDERER null
Linux archbang 3.10.5-1-ARCH #1 SMP PREEMPT Mon Aug 5 08:04:22 CEST 2013 x86_64 GNU/Linux wine 1.7
trace:d3d:wined3d_adapter_init_gl_caps GL_RENDERER: (null) err:d3d:wined3d_adapter_init_gl_caps Received a NULL GL_RENDERER.
Tried to test built in wined3d with passmark.
wgl and d3d debug are enabled, please see report1.txt
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #6 from Lex lexleogryfon@mail.by 2013-08-11 04:00:27 CDT --- Created attachment 45576 --> http://bugs.winehq.org/attachment.cgi?id=45576 glxinfo
Here is glxinfo
OpenGL renderer string: Mesa DRI Intel(R) G33 OpenGL version string: 1.4 Mesa 9.1.6
All native 3d apps works fine.
Please fix.
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #7 from shatteredlites@gmail.com 2013-08-11 04:48:21 CDT --- so what seems to be the problem im very new to this so I dont understand code
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #8 from Henri Verbeet hverbeet@gmail.com 2013-08-12 08:12:15 CDT --- Something seems to go wrong when creating a GL context through glXCreateContextAttribsARB(), although context creation doesn't actually fail. Does it make any difference if you run with WINEDEBUG="-all"? Unfortunately I don't have an X server that's new enough to reproduce this with.
http://bugs.winehq.org/show_bug.cgi?id=34238
shatteredlites@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |critical
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #9 from Rico kgbricola@web.de 2013-08-13 03:28:08 CDT --- Changing the Severity won't fix the bug. ;-)
Where is the result of the regression test?
You may have a look at bug 21708 (comment 37 and below - http://bugs.winehq.org/show_bug.cgi?id=21708#c37 ). Does patch http://bugs.winehq.org/attachment.cgi?id=45080 make any difference?
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #10 from shatteredlites@gmail.com 2013-08-13 03:39:22 CDT --- how do I apply this patch?
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #11 from shatteredlites@gmail.com 2013-08-13 03:50:45 CDT --- is there a way to do a regression without updating to 1.7 because the new stuff 1.7 requires hinders me doing a regression test the way you want me to
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #12 from Rico kgbricola@web.de 2013-08-13 04:20:18 CDT --- Just download the patch and follow http://wiki.winehq.org/Patching .
I don't see how the regression test has something to do with wine 1.7. Sure you could also start with 1.6 or 1.5.30 or what ever is the first one which builds and shows the issue.
Apparently, why does it hinder you? If it is the output from comment 3, just kill the wine server before you start your self build version.
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #13 from Henri Verbeet hverbeet@gmail.com 2013-08-13 04:29:51 CDT --- It's probably 5115f55eebe5cb91f13896862275e236a4954744, but that wouldn't really tell us anything new. I suspect it's some kind of driver issue, but it's not a generic Mesa bug, this works with r600g for example.
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #14 from shatteredlites@gmail.com 2013-08-13 05:03:41 CDT --- Created attachment 45599 --> http://bugs.winehq.org/attachment.cgi?id=45599 when compiling wine i get this error
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #15 from shatteredlites@gmail.com 2013-08-13 06:49:51 CDT --- nvm that i found the files i needed and im compiling wine with the patch now but idk if it will fix it so ill tell when it gets done
http://bugs.winehq.org/show_bug.cgi?id=34238
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |major
--- Comment #16 from Rosanne DiMesio dimesio@earthlink.net 2013-08-13 06:58:59 CDT --- Not critical. http://bugs.winehq.org/page.cgi?id=fields.html#importance
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #17 from Rico kgbricola@web.de 2013-08-13 08:26:57 CDT --- Created attachment 45602 --> http://bugs.winehq.org/attachment.cgi?id=45602 testcase for the opengl information
What do you get when running the attached test case ( wine main.exe )?
Apparently the glxtest ( ./main_linux ) produces something similar to your observations. But this could also mean, that my test is broken.
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #18 from shatteredlites@gmail.com 2013-08-13 08:44:59 CDT --- ok I did as you said and applied the patch but nothing seems to have changed and it says im still using 1.6 so either the patch did not work or it did not install do I need to remove the current wine I have in order for the git to work?
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #19 from Rico kgbricola@web.de 2013-08-13 09:03:38 CDT --- No, you don't need to remove the current wine, neither do you have to install wine.
Make sure you are running the just build version with "./wine --version" (from the build directory) instead of "wine --version" (the installed one).
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #20 from shatteredlites@gmail.com 2013-08-13 09:04:36 CDT --- ok I did it and the patch does not work
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #21 from Rico kgbricola@web.de 2013-08-13 09:15:48 CDT --- Then you need to run the full regression test between 1.4 and 1.6.
Also what does my test ( ./wine main.exe ) case show?
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #22 from shatteredlites@gmail.com 2013-08-13 22:00:42 CDT --- ok im confused the regresion thing is all mumbo jumbo to me
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #23 from Henri Verbeet hverbeet@gmail.com 2013-09-01 08:28:25 CDT --- (In reply to comment #17)
Created attachment 45602 [details] testcase for the opengl information
What do you get when running the attached test case ( wine main.exe )?
From bug 21708: So, after being informed about bug 34238, I've tried the testcase.
The results: ./main_linux 1: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" 2: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.1.5" 3: renderer="(null)" vendor="(null)" version="(null)"
(different version entry comes likely from the fact that I've updated mesa today)
./main.exe 1: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" 2: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.1.5" 3: renderer="(null)" vendor="(null)" version="(null)"
LIBGL_ALWAYS_SOFTWARE=1 ./main_linux 1: renderer="Software Rasterizer" vendor="Mesa Project" version="2.1 Mesa 9.2.0" 2: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.1.5" 3: renderer="(null)" vendor="(null)" version="(null)"
LIBGL_ALWAYS_SOFTWARE=1 ./main.exe err:winediag:X11DRV_WineGL_InitOpenglInfo The Mesa OpenGL driver is using software rendering, most likely your 32-bit OpenGL drivers haven't been installed correctly (using GL renderer "Software Rasterizer", version "2.1 Mesa 9.2.0"). 1: renderer="Software Rasterizer" vendor="Mesa Project" version="2.1 Mesa 9.2.0" 2: renderer="Software Rasterizer" vendor="Mesa Project" version="2.1 Mesa 9.2.0" 3: renderer="Software Rasterizer" vendor="Mesa Project" version="2.1 Mesa 9.2.0"
So it looks like something indeed breaks when the old context is destroyed.
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #24 from Rafał Mużyło galtgendo@o2.pl 2013-09-01 08:44:22 CDT --- Results from the updated testcase (see attachment 45801): ./main_linux 1: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" direct 2: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.1.5" indirect 3: renderer="(null)" vendor="(null)" version="(null)" indirect 4: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.1.5" indirect 5: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.1.5" indirect
./main.exe 1: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" 2: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.1.5" 3: renderer="(null)" vendor="(null)" version="(null)"
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #25 from Rico kgbricola@web.de 2013-09-01 11:11:17 CDT --- I think there are two issues.
1. Why does mesa return an indirect context when we request a direct one in glXCreateContextAttribsARB? The spec says that's correct.
Imho mesa defaults to version 2.1 (see mesa: src/glx/dri2_glx.c) and these cards fail, because they are not capable of running this opengl version, thus we likely get indirect rendering. Maybe we should pass in the highest available version like 1.3 if it is below 2.1? Or mesa should be fixed to take the max version supported by default, as reporting an indirect context over a direct one is a bad default I think.
reproduce able by: "MESA_GL_VERSION_OVERRIDE=1.3 ./main_linux"
2. Mesa could not switch from direct to indirect contexts. This would at least report the correct caps if it would work. Imho the indirect context may be useless for us.
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #26 from Henri Verbeet hverbeet@gmail.com 2013-09-01 12:07:28 CDT --- (In reply to comment #25)
I think there are two issues.
- Why does mesa return an indirect context when we request a direct one in
glXCreateContextAttribsARB? The spec says that's correct.
Yeah, you're allowed to get an indirect context if you request a direct one, though we'd obviously like to avoid it if possible.
Imho mesa defaults to version 2.1 (see mesa: src/glx/dri2_glx.c) and these cards fail, because they are not capable of running this opengl version, thus we likely get indirect rendering. Maybe we should pass in the highest available version like 1.3 if it is below 2.1? Or mesa should be fixed to take the max version supported by default, as reporting an indirect context over a direct one is a bad default I think.
That sounds like a bug in Mesa. Afaik the defaults for GLX_CONTEXT_MAJOR_VERSION_ARB/GLX_CONTEXT_MINOR_VERSION_ARB are 1/0. I was under the impression there are piglit tests for that though. It would perhaps be interesting to pass that in explicitly, although IIRC there are some issues with nvidia driver returning a 2.1 context when explicitly requesting 1.0 vs. 3.0 when leaving the version attributes unspecified.
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #27 from Rico kgbricola@web.de 2013-09-02 08:00:47 CDT --- This patch http://lists.freedesktop.org/archives/mesa-dev/2013-September/044152.html may help, but it is for mesa. It works fine when using e.g. "MESA_GL_VERSION_OVERRIDE=1.3 ./main_linux" here. You may give it a try.
Maybe the piglit test valid-attribute-null/empty are candidates. But these tests don't care if they got a direct or indirect context.
http://bugs.winehq.org/show_bug.cgi?id=34238
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |galtgendo@o2.pl
--- Comment #28 from Rafał Mużyło galtgendo@o2.pl 2013-09-02 13:42:48 CDT --- For completeness sake - after restart, linux strings are: 1: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" direct 2: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" indirect 3: renderer="(null)" vendor="(null)" version="(null)" indirect 4: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" indirect 5: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" indirect
I'll see if that mesa patch changes anything.
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #29 from Rafał Mużyło galtgendo@o2.pl 2013-09-03 15:37:10 CDT --- OK, that mesa patch seems to do the trick and going by the mailing list discussion does the right thing too.
Output after the patch: 1: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" direct 2: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" direct 3: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" direct 4: renderer="Mesa DRI R200 (RV280 5964) TCL DRI2" vendor="Tungsten Graphics, Inc." version="1.3 Mesa 9.2.0" indirect 5: renderer="(null)" vendor="(null)" version="(null)" indirect
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #30 from Rafał Mużyło galtgendo@o2.pl 2013-09-03 15:40:02 CDT --- PS: tested with the modified patch version, that sets 1.2, not 1.0.
http://bugs.winehq.org/show_bug.cgi?id=34238
Rico kgbricola@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |UPSTREAM
--- Comment #31 from Rico kgbricola@web.de 2013-09-05 01:35:20 CDT --- This should be fixed by mesa commit 8b302e1635534bfc6ed3ad671f2428470b3a765d
@Rafał: Thanks for testing. You may try this commit, as a slightly different version than you've tested was committed. It shouldn't change the testing result at all. Please report if the commit doesn't work as expected.
This is an UPSTREAM bug for mesa.
There may be another issue, when switching from a direct to an indirect context, but I'm not sure if we should care, yet. It may get a problem if we are trying to create a special version of the context (and getting back an indirect mesa software context)...
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #32 from shatteredlites@gmail.com 2013-09-06 12:39:44 CDT --- I just updated to 1.7.1 and the error is still there will this patch be added in the next realese?
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #33 from Rafał Mużyło galtgendo@o2.pl 2013-09-06 14:29:28 CDT --- (In reply to comment #32)
I just updated to 1.7.1 and the error is still there will this patch be added in the next realese?
Honestly... This was a patch to *mesa*, not wine, so version of wine will not (well, should not) matter.
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #34 from shatteredlites@gmail.com 2013-09-06 14:56:39 CDT --- so how do I get this mesa update?
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #35 from shatteredlites@gmail.com 2013-09-06 16:35:23 CDT --- I tried getting an update from xorg-edge ppa and it worked but the update did make my cpu run at a crawling speed nothing responded quickly so I did ppa purge and im back on my stable mesa drivers. where do you suppose i get my updates and how will i go about doing it?
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #36 from Bruno Jesus 00cpxxx@gmail.com 2013-09-06 18:38:09 CDT --- Hi, please look for help in the Ubuntu forum. Bugzilla is meant for bugs, not general help.
http://bugs.winehq.org/show_bug.cgi?id=34238
--- Comment #37 from shatteredlites@gmail.com 2013-09-11 22:32:01 CDT --- I have updated to the latest bleeding edge drivers from Xorg-edgers despite the very low performance issues after getting them wine still fails to initialize can I expect this patch to be released in the next big stable drivers update?
http://bugs.winehq.org/show_bug.cgi?id=34238
shatteredlites@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|UPSTREAM |
--- Comment #38 from shatteredlites@gmail.com 2013-09-11 22:34:41 CDT --- its either the patch has not been applied or Its wine thats at fault and if im doing it wrong help me this once the forums wont do jack for me
http://bugs.winehq.org/show_bug.cgi?id=34238
Rico kgbricola@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |UPSTREAM
--- Comment #39 from Rico kgbricola@web.de 2013-09-12 01:56:26 CDT --- There is no mesa release with the fix, yet. It will likely take some weeks... There is nothing we can do about that!
Imho, you can (if you have the knowledge or you may ask the corresponding forums / help channels). Your solutions are: - use wine <= wine-1.5.28 (use a package or build wine from source), mesa version doesn't matter - compile mesa from source (git >= 8b302e1635534bfc6ed3ad671f2428470b3a765d) or use a fixed package (likely your distribution doesn't ship one, yet), wine version shouldn't matter - use another graphics card which doesn't trigger the bug (either one with GL>=2.1 and mesa or some amd/nvidia with the corresponding drivers) - wait till your packages ship the fixes ...
I'm not sure if I said all possible solutions, but all this solutions have nothing to do with wine or this bug at all. Please stop posting / changing the bug and don't reopen. For us it is an upstream bug! If you need help, ask in the wine forum (e.g. http://forum.winehq.org/viewtopic.php?f=8&t=19536 ), better in the help channel for the problem you like to solve (mesa / ubuntu / hardware distributor).
https://bugs.winehq.org/show_bug.cgi?id=34238
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #40 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Rico from comment #31)
This should be fixed by mesa commit 8b302e1635534bfc6ed3ad671f2428470b3a765d
@Rafał: Thanks for testing. You may try this commit, as a slightly different version than you've tested was committed. It shouldn't change the testing result at all. Please report if the commit doesn't work as expected.
This is an UPSTREAM bug for mesa.
Since mesa was fixed I'm closing this bug too.