[Bug 38480] New: RuneScape crashes when switching to OpenGL renderer (glCopyTexSubImage3DEXT blacklisted by extension filtering)
https://bugs.winehq.org/show_bug.cgi?id=38480
Bug ID: 38480 Summary: RuneScape crashes when switching to OpenGL renderer (glCopyTexSubImage3DEXT blacklisted by extension filtering) Product: Wine Version: 1.7.39 Hardware: x86 URL: http://www.runescape.com/l=1/downloads/runescape.msi?1 .4.3 OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: opengl Assignee: wine-bugs@winehq.org Reporter: sebastian@fds-team.de CC: matteo.mystral@gmail.com, michael@fds-team.de Regression SHA1: bfd4836867d6d90eaeae6ccbc02e37678b59b8f1 Distribution: ---
Originally reported here: https://bugs.wine-staging.com/show_bug.cgi?id=205
Commit http://source.winehq.org/git/wine.git/commit/bfd4836867d6d90eaeae6ccbc02e376... caused an regression which causes the game to crash when trying to switch to OpenGL renderer mode. The problem still exists in wine-1.7.41-66-g4fbaab2 and is thus not identical to bug 38264.
To reproduce the problem:
1) Install the runescape.msi file 2) Start "JagexLauncher.exe runescape" 3) The game will install updates and then ask to automatically detect graphic settings. Click the button to proceed. 4) At the login form click on the gear symbol at the top right of the screen. Select "custom" configuration, and then click on "OpenGL".
WARNING: The game is affected by a couple additional bugs. If the game for example crashes when trying to detect the graphic settings, or doesn't accept any input, then just restart it until it works, which should usually be the case after a couple of attempts. ;) Actually those issues are most likely also regressions, but I didn't have time to track them down yet.
The problem seems to be:
--- snip --- warn:wgl:wglGetProcAddress Extension GL_EXT_copy_texture required for glCopyTexSubImage3DEXT not supported --- snip ---
Skipping the "return NULL" for glCopyTexSubImage3DEXT (or reverting the whole commit) makes the app work again.
https://bugs.winehq.org/show_bug.cgi?id=38480
--- Comment #1 from Matteo Bruni matteo.mystral@gmail.com --- Had another quick look and I confirm that it seems to be a driver bug in that the driver doesn't report GL_EXT_copy_texture while obviously supporting glCopyTexSubImage3DEXT().
Did anyone report the bug to Nvidia already?
https://bugs.winehq.org/show_bug.cgi?id=38480
--- Comment #2 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Matteo Bruni from comment #1)
Had another quick look and I confirm that it seems to be a driver bug in that the driver doesn't report GL_EXT_copy_texture while obviously supporting glCopyTexSubImage3DEXT().
Did anyone report the bug to Nvidia already?
No, I haven't reported it yet. I am also not sure if it makes much sense because its apparently nothing unusual that drivers do not report all supported extensions. When you search for "was not found, but has the entry point" you'll find various reports created with GLview ( http://www.realtech-vr.com/glview/download.php ) where users have similar problems with all kind of driver / graphic card combinations. Thats why I decided to just revert the patch in Wine Staging, its not one bug which has to be fixed, but more like hundred of bugs. ;)
https://bugs.winehq.org/show_bug.cgi?id=38480
--- Comment #3 from Matteo Bruni matteo.mystral@gmail.com ---
From a quick look it seems at least some of those have to do with GLview
limitations (e.g. complaining for ARB_fragment_program functions when ARB_vertex_program is supported and makes a lot of the same functions available) more than pointing towards actual driver issues.
https://bugs.winehq.org/show_bug.cgi?id=38480
githlar@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |githlar@gmail.com
--- Comment #4 from githlar@gmail.com --- I posted on the NVIDIA Linux Driver forums regarding this issue.: https://devtalk.nvidia.com/default/topic/829402/linux/some-gl-extensions-are...
I agree with Mateo though, since Nvidia seems to be the only driver affected by this, it's probably their responsibility to fix it. I'm no OpenGL programmer, but I know that OpenGL extensions are hierarchical. I guess worst-case scenario somehow a logical test could be done at the initialization of the Wine OpenGL implementation that could sort of "fill in the blanks" so to speak. Something like: "Well, if you have OpenGL 2.0 extensions, then more than likely (most of?) OpenGL 1.0 is supported as well" Of course, a wider version gap would probably make more sense.
Perhaps with passed check on, i.e., 2.0 extensions all 1.0 extensions could revert to the old behavior. Then again, I assume there were issues with the old behavior before that constituted the change to begin with.
https://bugs.winehq.org/show_bug.cgi?id=38480
--- Comment #5 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Matteo Bruni from comment #3)
From a quick look it seems at least some of those have to do with GLview limitations (e.g. complaining for ARB_fragment_program functions when ARB_vertex_program is supported and makes a lot of the same functions available) more than pointing towards actual driver issues.
I've hacked a similar check to what the GLview app does directly into the wglGetProcAddress function, and this is the result: http://pastebin.com/raw.php?i=C61vk8rH Which means about 65 functions not announced properly. If its not just my driver (346.59) it means Wine has to workaround a lot ... probably a bit too much ;)
https://bugs.winehq.org/show_bug.cgi?id=38480
--- Comment #6 from Matteo Bruni matteo.mystral@gmail.com --- Created attachment 51382 --> https://bugs.winehq.org/attachment.cgi?id=51382 Supported functions without the corresponding extension, Nvidia 346.59 driver
(In reply to Sebastian Lackner from comment #5)
I've hacked a similar check to what the GLview app does directly into the wglGetProcAddress function, and this is the result: http://pastebin.com/raw.php?i=C61vk8rH Which means about 65 functions not announced properly. If its not just my driver (346.59) it means Wine has to workaround a lot ... probably a bit too much ;)
None of those functions or extensions are probably significantly used in practice, except for the one in subject here. Or so I think, I might be wrong of course. I'm not planning to workaround those issues in Wine though.
https://bugs.winehq.org/show_bug.cgi?id=38480
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED CC| |sebastian@fds-team.de Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/opengl32-Rever | |t_Disable_Ext
https://bugs.winehq.org/show_bug.cgi?id=38480
Alex Henrie alexhenrie24@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |RESOLVED CC| |alexhenrie24@gmail.com Resolution|--- |NOTOURBUG
--- Comment #7 from Alex Henrie alexhenrie24@gmail.com --- I'm closing this bug. The reply from Nvidia [1] was:
"For the particular case of GL_EXT_copy_texture, the extension cannot be listed as supported because the driver doesn't implement all of the functions defined by that extension."
If Wine called a function that is not listed at supported for the current GL context, the whole program could crash. Wine has no way to know which unsupported functions will work and which will not. We could hack in tables to determine compatibility based on the combination of driver, video card, Xorg version, GL profile, and other factors, but that kind of patch would never be accepted into Wine (although it might be acceptable in Wine Staging).
The only real solution to this is to get Nvidia to finish implementing GL_EXT_copy_texture and add it to their driver's supported extensions list.
[1] https://devtalk.nvidia.com/default/topic/829402/linux/some-gl-extensions-are...
https://bugs.winehq.org/show_bug.cgi?id=38480
--- Comment #8 from Alex Henrie alexhenrie24@gmail.com --- Actually, there is another solution: RuneScape could try to use glCopyTexSubImage3D from OpenGL 4.0 and then fall back to glCopyTexSubImage3DEXT only if OpenGL 4.0 or later is not available.
https://bugs.winehq.org/show_bug.cgi?id=38480
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|NOTOURBUG |---
--- Comment #9 from Michael Müller michael@fds-team.de --- NVIDIA also does not offer the extension on Windows. Take for example a look at http://delphigl.de/glcapsviewer/gl_generatereport.php?reportID=1086 and click on Extensions.
The application knows that glCopyTexSubImage3DEXT is supported by the driver even if other stuff from the GL_EXT_copy_texture extension might not work properly. However, Wine now adds its own logic to blacklist the function using the extension string. In my opinion this is a bug in Wine since the extension is not available on Windows, the application does not check the extension string but still gets a valid pointer. It basically works the same way on Linux with the NVIDIA driver.
It might be the case that a program crashes because it tries to get a pointer to an unsupported function. This would be an application bug which might also occur on Windows, depending on the driver. I think Wine should not add its own logic here. The aim of Wine is to be compatible with Windows and not create a better OpenGL implementation.
https://bugs.winehq.org/show_bug.cgi?id=38480
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |STAGED
https://bugs.winehq.org/show_bug.cgi?id=38480
--- Comment #10 from Sebastian Lackner sebastian@fds-team.de --- I fully agree with Michaels comment.
No matter if you call it an application bug or not, in contrast to other "difficult to solve bugs" Wine could easily be compatible here. Not sure if its still the case, but originally Matteo told me (I think it was on IRC) that no application depends on extension filtering.
We'll definitely keep this fix in our Staging tree, until a revert was accepted upstream, or a better solution is found.
https://bugs.winehq.org/show_bug.cgi?id=38480
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
--- Comment #11 from Béla Gyebrószki gyebro69@gmail.com --- My apologies if this is unrelated, but the game Grim Fandango Remastered crashes on start with Nouveau, and the crash was introduced by commit bfd4836867d6d90eaeae6ccbc02e37678b59b8f1. I can provide a debug log if it is needed (the game has no demo version). I couldn't try the game with the binary drivers yet...
https://bugs.winehq.org/show_bug.cgi?id=38480
--- Comment #12 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Béla Gyebrószki from comment #11)
My apologies if this is unrelated, but the game Grim Fandango Remastered crashes on start with Nouveau, and the crash was introduced by commit bfd4836867d6d90eaeae6ccbc02e37678b59b8f1. I can provide a debug log if it is needed (the game has no demo version). I couldn't try the game with the binary drivers yet...
It could be a different extension or function, but I think its fine to keep track of it in the same bug report. Could you attach a log created with WINEDEBUG=+wgl ? Especially the following debug messages are important in this case:
WARN("Extension %s required for %s not supported\n", ext_ret->extension, name);
https://bugs.winehq.org/show_bug.cgi?id=38480
--- Comment #13 from Béla Gyebrószki gyebro69@gmail.com --- Created attachment 52767 --> https://bugs.winehq.org/attachment.cgi?id=52767 +wgl log (Grim Fandango Remastered with nouveau)
AFAIK, the game requires OpenGL 3.3.
wine-1.7.55-22-g097006b Fedora 23 32-bit OpenGL vendor string: nouveau OpenGL renderer string: Gallium 0.4 on NV92 OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.1.0-devel OpenGL core profile shading language version string: 3.30
https://bugs.winehq.org/show_bug.cgi?id=38480
--- Comment #14 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Alex Henrie from comment #8)
Actually, there is another solution: RuneScape could try to use glCopyTexSubImage3D from OpenGL 4.0 and then fall back to glCopyTexSubImage3DEXT only if OpenGL 4.0 or later is not available.
For the records, glCopyTexSubImage3D is actually from OpenGL 1.2 so hardly a tall requirement for using the correct function.
So, the game isn't particularly well behaved, the Nvidia drivers aren't particularly well behaved and Wine is now particularly picky. I'm not convinced that the regression commit is wrong (it's been somewhat useful for bug 39563 and bug 38264 at least) but I'm not especially attached to it. If someone wants to send a revert I'm not going to veto it.
https://bugs.winehq.org/show_bug.cgi?id=38480
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |5c9ddc55dcf6e64d747b1a8ab01 | |e408d4b8d55e1 Status|STAGED |RESOLVED Resolution|--- |FIXED
--- Comment #15 from Alexandre Julliard julliard@winehq.org --- Fixed by 5c9ddc55dcf6e64d747b1a8ab01e408d4b8d55e1.
https://bugs.winehq.org/show_bug.cgi?id=38480
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #16 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.8-rc4.
https://bugs.winehq.org/show_bug.cgi?id=38480
Alex Henrie alexhenrie24@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=39563
-
wine-bugs＠winehq.org