I forgot to note that the performance for winemac with this game has been the same since it was first included in wine

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"

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

What is the pixel format of the context?

The output from Pixel Format: http://i.imgur.com/pIIlaXl.png

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?

Created attachment 45900 [details]
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.

Created attachment 45905 [details]
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.

Created attachment 46273 [details]
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.

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.html

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.

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.

Created attachment 46280 [details]
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.

(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!

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?

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!

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

Thanks Ken, I can confirm this now works as expected in 1.7.5

Glad to hear it.  Thanks for confirming.

Closing bugs fixed in 1.7.6.

Removing 1.6.x milestone from bugs included in 1.6.2.