| Summary: | WoW crashes in OpenGL mode with Mesa, but not with NVIDIA blob | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Chris Rankin <rankincj> |
| Component: | Drivers/Gallium/r600 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED NOTOURBUG | QA Contact: | Default DRI bug account <dri-devel> |
| Severity: | normal | ||
| Priority: | medium | CC: | mike |
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | WINEDEBUG trace, including R600 shaders | ||
It is possible that the WoW client is trying to use an extension that the R600 driver doesn't support. E,g, it could be trying to use something > OpenGL 3.3 without bothering to check for its availability. (The NVIDIA blobs I have tested have all advertised OpenGL 4.x) Is there any way of asking Mesa to log what an application is trying to use? I think this was a regression brought in by patch 6.2 - OpenGL worked fine for me before the patch. Now I'm forced to use DX9 which crashes on exit or Alt+Tab. I'm not sure if that's related to DRI3 or Kwin on Plasma 5 It appears that Wine isn't using Mesa's OpenGL 3.3 core profile yet:
> 0063:warn:wgl:is_extension_supported The function requires OpenGL version '4.3' while your drivers only provide '3.0'
> 0063:warn:wgl:wglGetProcAddress Extension GL_ARB_internalformat_query2 GL_VERSION_4_3 required for glGetInternalformati64v not supported
I don't know if GL_ARB_internalformat_query2 is the missing extension that is causing the crash, but it does show that WoW is only able to use OpenGL 3.0 natively atm.
(In reply to Chris Rankin from comment #3) > It appears that Wine isn't using Mesa's OpenGL 3.3 core profile yet: > Creating core contexts should work fine on Wine, but WoW may not be trying to create one. (Since you'll get the same functionality in a compatibility context on proprietary NVIDIA.) (In reply to Henri Verbeet from comment #4) > Creating core contexts should work fine on Wine, but WoW may not be trying > to create one. I have added this to my WoW start-up script: MESA_GL_VERSION_OVERRIDE=3.3COMPAT export MESA_GL_VERSION_OVERRIDE And now WoW is running successfully in OpenGL mode. It appears that WoW *requires* OpenGL 3.3 over 3.0. FWIW, I have determined that WoW now requires OpenGL >= 3.2 when running in OpenGL mode, and I suspect that the function call that kills WoW when running with OpenGL < 3.2 is glDeleteSync(). Now it seems that glDeleteSync() belong to the ARB_sync extension, which Mesa *does* advertise as part of my OpenGL 3.0 Compatibily context, so I can't say that I completely understand what is going on here. Could there be a Mesa bug after all, or is it more likely that the WoW client is just being sloppy? Mesa does not implement compatibility contexts so it could be some interaction between core and legacy GL features that is not handled correctly. |
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.
Created attachment 117619 [details] WINEDEBUG trace, including R600 shaders Hardware tested: Linux x64, both HD4890 and HD6450 World of Warcraft (OpenGL mode) has been crashing ever since it upgraded itself to 6.2. I had assumed that it was a bug in the WoW client, until I noticed that WoW did not crash on a machine running with the NVIDIA binary blob. I have executed WoW using the following command: $ R600_DEBUG=fs,vs,gs,ps,cs WINEDEBUG=+opengl,+wgl,seh ./Wow-64.exe And it appears that WoW is throwing an exception in a glLoadMatrix() operation: trace:opengl:glCallList (1) trace:opengl:glLoadMatrixf (0x22f610) trace:seh:raise_exception code=c0000005 flags=0 addr=(nil) ip=0 tid=0027 trace:seh:raise_exception info[0]=0000000000000000 trace:seh:raise_exception info[1]=0000000000000000 trace:seh:raise_exception rax=0000000006e9d2c0 rbx=0000000006e9ffd0 rcx=0000000000009117 rdx=0000000000000000 trace:seh:raise_exception rsi=00000001413696b1 rdi=0000000006e9d2c0 rbp=000000000022fa60 rsp=000000000022f898 trace:seh:raise_exception r8=000000000000000a r9=000000000022f610 r10=00007f2857d369f6 r11=000000000022f7f0 trace:seh:raise_exception r12=00000000001b6b06 r13=0000000000000000 r14=00007fffff7e8000 r15=00007ffd34f83da0 trace:seh:RtlVirtualUnwind type 1 rip 1400de519 rsp 22f8a0 trace:seh:dump_unwind_info **** func de4d0-de5aa trace:seh:dump_unwind_info unwind info at 0x1412e21ac flags 0 prolog 0x6 bytes function 0x1400de4d0-0x1400de5aa trace:seh:dump_unwind_info 0x6: subq $0x20,%rsp trace:seh:dump_unwind_info 0x2: pushq %rbx trace:seh:RtlVirtualUnwind type 1 rip 1400d0ec9 rsp 22f8d0 trace:seh:dump_unwind_info **** func d0e70-d0ef8 I don't know how to debug this any further; the more flags I add to WINEDEBUG, the less likely WoW is to do *anything* (i.e. "run at all"). Raising this as a means of requesting more ideas.