http://bugs.winehq.org/show_bug.cgi?id=34051
Bug #: 34051 Summary: Low FPS with winemac driver in Unreal Tournament GOTY Product: Wine Version: 1.6-rc4 Platform: x86-64 OS/Version: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: opengl AssignedTo: wine-bugs@winehq.org ReportedBy: brymaster@gmail.com Classification: Unclassified
Unreal Tournament GOTY (from GOG.com)
Running on 10.8.4 with Nvidia 9400M
Configured to use OpenGL driver in-game.
The winemac driver has low FPS (like a slideshow) compared to X11 which is smooth.
I've experimented with the default OpenGlDrv.dll and a patched renderer version here (http://www.cwdohnal.com/utglr/) which gives slightly better performance.
http://bugs.winehq.org/show_bug.cgi?id=34051
--- Comment #1 from brymaster@gmail.com 2013-07-13 19:28:31 CDT --- I forgot to note that the performance for winemac with this game has been the same since it was first included in wine
http://bugs.winehq.org/show_bug.cgi?id=34051
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com, | |ken@codeweavers.com Component|opengl |winemac.drv
http://bugs.winehq.org/show_bug.cgi?id=34051
--- Comment #2 from Ken Thomases ken@codeweavers.com 2013-07-23 16:05:37 CDT --- Does the performance improve if you set this registry setting?
[HKEY_CURRENT_USER\Software\Wine\OpenGL] "DisabledExtensions"="WGL_ARB_framebuffer_sRGB WGL_ARB_make_current_read WGL_ARB_pbuffer WGL_ARB_pixel_format_float WGL_ARB_render_texture WGL_ATI_pixel_format_float WGL_EXT_framebuffer_sRGB WGL_EXT_pixel_format_packed_float WGL_NV_render_texture_rectangle"
http://bugs.winehq.org/show_bug.cgi?id=34051
--- Comment #3 from brymaster@gmail.com 2013-07-24 13:31:23 CDT --- I didn't notice any change with that registry key.
I ran the app through OpenGL Profiler for a few minutes to collect statistics on where its spending most of its time with GL calls: http://i.imgur.com/89c84yv.png
I also set a few breakpoints for 'Break on GL error' and 'SW fallback' - no errors but quite a few calls fell back to software for example:
glFrustum(-4, 4, -3, 3, 4, 32768) glColor3fv({1, 1, 1}) glBindTexture(GL_TEXTURE_2D, 9) glActiveTexture(GL_TEXTURE1) glEnable(GL_TEXTURE_2D) glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 8, 16, GL_BGRA, GL_UNSIGNED_BYTE, 0x04a500e0) glDrawArrays(GL_TRIANGLE_FAN, 0, 5)
Anyway, hope some of this is helpful
http://bugs.winehq.org/show_bug.cgi?id=34051
--- Comment #4 from Ken Thomases ken@codeweavers.com 2013-07-24 13:42:55 CDT --- What is the pixel format of the context?
http://bugs.winehq.org/show_bug.cgi?id=34051
brymaster@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|winemac.drv |opengl
--- Comment #5 from brymaster@gmail.com 2013-07-24 14:51:35 CDT --- The output from Pixel Format: http://i.imgur.com/pIIlaXl.png
http://bugs.winehq.org/show_bug.cgi?id=34051
--- Comment #6 from Ken Thomases ken@codeweavers.com 2013-07-24 15:04:09 CDT --- It looks as though it has picked an unaccelerated pixel format. Please attach a +tid,+wgl log. Run it just long enough to see the problem and then exit, to keep it short. Probably best to compress it before attaching it. Thanks.
Your original report says "Configured to use OpenGL driver in-game". What other options are there? Does it support Direct3D and, if so, does that work better?
http://bugs.winehq.org/show_bug.cgi?id=34051
--- Comment #7 from brymaster@gmail.com 2013-09-08 12:26:06 CDT --- Created attachment 45900 --> http://bugs.winehq.org/attachment.cgi?id=45900 1.7.1 log with +tid,+wgl
Ken,
Attached is a +tid,+wgl log of the winemac issue in 1.7.1
As for running in D3D, video seems to be smooth but there's the issue of nothing being on-screen until i've command-tabbed and then I can't get the game to respect my native resolution.
http://bugs.winehq.org/show_bug.cgi?id=34051
--- Comment #8 from Ken Thomases ken@codeweavers.com 2013-09-08 23:04:06 CDT --- Created attachment 45905 --> http://bugs.winehq.org/attachment.cgi?id=45905 Tighten double-buffer, stereo matching in ChoosePixelFormat
It looks like the game requests a pixel format supporting double-buffering, stereo, 24 bits of color, and 32 bits of depth. ChoosePixelFormat is returning an unaccelerated format when it shouldn't.
I think ChoosePixelFormat is supposed to restrict its search to formats supporting double-buffering and stereo if any are available. They are available, but the logic in ChoosePixelFormat is broken. Ultimately, it seems to be giving priority to the requested depth buffer size. On your system, the only formats with a 32-bit depth buffer are the software-rendered ones.
The attached patch fixes the logic of ChoosePixelFormat with respect to double-buffering and stereo. This incidentally avoids the software-rendered formats, because they don't support stereo. (I think, though, that ChoosePixelFormat would still pick a software-rendered format if the game had not requested stereo, which means there are further bugs.)
I've added some additional logging, too. So, if it is still terribly slow, please collect another log.
http://bugs.winehq.org/show_bug.cgi?id=34051
--- Comment #9 from brymaster@gmail.com 2013-10-12 12:41:40 CDT --- Created attachment 46273 --> http://bugs.winehq.org/attachment.cgi?id=46273 1.7.4 log with +tid,+wgl
Hi Ken,
Sorry for the delay. I've just applied the /dlls/opengl32/wgl.c portion of the patch to Wine 1.7.4 (/dlls/winemac.drv/opengl.c was already present) and it's still slow so I've attached a new +tid, +wgl log.
http://bugs.winehq.org/show_bug.cgi?id=34051
--- Comment #10 from Ken Thomases ken@codeweavers.com 2013-10-13 00:21:34 CDT --- Thanks.
First of all, I was incorrect in my previous analysis of the properties being requested of the pixel format. I had said that stereo was being requested, but it wasn't. I had assumed that the "flags" were being logged using hexadecimal but it was using decimal.
It seems that the problem is that the game is requesting a depth buffer with 32 bits. Your GPU does not support that but Apple's software renderer does. See the "Depth Buffer Modes" section toward the bottom of this table: https://developer.apple.com/graphicsimaging/opengl/capabilities/GLInfo_1084....
So, ChoosePixelFormat() is selecting a pixel format from the software renderer as the best match to the request. The question is why it's choosing differently when using the X11 driver. Could you collect a similar log with that driver, please?
Also, you said you're not using Direct3D, but the log shows Direct3D being used. I'm not sure what explains that.
You also said that the reason for not using Direct3D is that you can't see the game until you Command-Tab away and back but then the game doesn't use the selected resolution. Wine 1.7.4 includes a change to the Mac driver so that it reapplies any custom resolution selection when you switch back. So, it's worth checking if that solves that particular part of the problem.
http://bugs.winehq.org/show_bug.cgi?id=34051
--- Comment #11 from Ken Thomases ken@codeweavers.com 2013-10-13 00:54:11 CDT --- Created attachment 46279 --> http://bugs.winehq.org/attachment.cgi?id=46279 Patch to ignore unaccelerated renderers
You can also try this patch to ignore unaccelerated renderers, just to see how things work if there are _no_ pixel formats with 32-bit depth buffers.
http://bugs.winehq.org/show_bug.cgi?id=34051
--- Comment #12 from brymaster@gmail.com 2013-10-13 01:02:20 CDT --- Created attachment 46280 --> http://bugs.winehq.org/attachment.cgi?id=46280 1.7.4 log with +tid,+wgl (X11)
Attached is a +tid,+wgl log with X11 driver
I'm not sure what would account for the log showing Direct3D as I have the OpenGL driver selected in-game.
I switched to the Direct3D driver again and am getting a black/gray empty screen and cannot command-tab away to fix the issue it seems.
http://bugs.winehq.org/show_bug.cgi?id=34051
--- Comment #13 from brymaster@gmail.com 2013-10-13 01:27:48 CDT --- (In reply to comment #11)
Created attachment 46279 [details] Patch to ignore unaccelerated renderers
You can also try this patch to ignore unaccelerated renderers, just to see how things work if there are _no_ pixel formats with 32-bit depth buffers.
That worked! The game now appears to run equal to X11.
Thank you, Ken!
http://bugs.winehq.org/show_bug.cgi?id=34051
--- Comment #14 from Ken Thomases ken@codeweavers.com 2013-10-14 21:49:21 CDT --- Well, you're welcome I guess. That wasn't intended as a fix, but as a diagnostic to confirm my theory.
To make sense of your most recent log from the X11 driver, I could use the output from glxinfo. Do you mind attaching that?
http://bugs.winehq.org/show_bug.cgi?id=34051
--- Comment #15 from Ken Thomases ken@codeweavers.com 2013-10-14 23:25:26 CDT --- Actually, never mind. I was able to reproduce the problem here. I don't need your glxinfo.
It turns out there's nothing wrong with the Mac driver. The problem is the implementation of GLX for Mac OS X in Mesa. It's not rigorous.
GLX reports to the X11 driver that there are fbconfigs with 32 bits of depth buffer. Glxinfo shows that these fbconfigs are "slow" (i.e. software rendered). The X11 driver attempts to use such an fbconfig to satisfy UT:GotY's request.
However, the code which enumerates the fbconfigs doesn't match the code which actually sets up a GL context. When setting up a GL context, GLX normally refuses to allow the use of software rendering at all. If you set the environment variable LIBGL_ALLOW_SOFTWARE, it will at least allow it.
But even then it doesn't actually enforce the parameters of the requested fbconfig. For example, it passes along the request for 32 bits of depth buffer, but it allows the OpenGL implementation to give it a pixel format which has a smaller depth buffer if that would be "better". If it insisted on a true match, it would end up with software rendering. But since it doesn't, the Mac OpenGL picks an accelerated renderer.
So: X11 driver requested an unaccelerated fbconfig with 32 bits of depth buffer. GLX ends up using an accelerated pixel format with 24 bits of depth buffer.
The Mac driver suffers by comparison because it actually respects and enforces the pixel format selected by the app. I guess, to get behavior similar to X11, I will have to add a registry setting to the Mac driver to allow users to forcibly disable the use of unaccelerated pixel formats, just like the patch does. Yeesh!
http://bugs.winehq.org/show_bug.cgi?id=34051
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Status|UNCONFIRMED |NEW Component|opengl |winemac.drv Ever Confirmed|0 |1
--- Comment #16 from Ken Thomases ken@codeweavers.com 2013-10-21 16:44:40 CDT --- I have submitted a patch that should fix this. It disables software rendering by default to match GLX but allows one to enable it via a registry setting. http://source.winehq.org/patches/data/99874
http://bugs.winehq.org/show_bug.cgi?id=34051
brymaster@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #17 from brymaster@gmail.com 2013-11-03 21:34:35 CST --- Thanks Ken, I can confirm this now works as expected in 1.7.5
http://bugs.winehq.org/show_bug.cgi?id=34051
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |742c48b3489a21dd373221aa10b | |b648dd02c86d8
--- Comment #18 from Ken Thomases ken@codeweavers.com 2013-11-03 21:41:25 CST --- Glad to hear it. Thanks for confirming.
http://bugs.winehq.org/show_bug.cgi?id=34051
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #19 from Alexandre Julliard julliard@winehq.org 2013-11-08 12:32:54 CST --- Closing bugs fixed in 1.7.6.
https://bugs.winehq.org/show_bug.cgi?id=34051
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.6.x
https://bugs.winehq.org/show_bug.cgi?id=34051
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.6.x |---
--- Comment #20 from Alexandre Julliard julliard@winehq.org --- Removing 1.6.x milestone from bugs included in 1.6.2.