Bug 59322 - r300g MSAA breaks Half-Life 2 in Wine
r300g MSAA breaks Half-Life 2 in Wine
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r300
git
Other All
: medium normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-13 16:43 UTC by Stefan Dösinger
Modified: 2013-07-30 20:44 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Screenshot (83.23 KB, image/png)
2013-01-14 10:51 UTC, Stefan Dösinger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Dösinger 2013-01-13 16:43:16 UTC
When MSAA is enabled in Half-Life 2 running in Wine, the window only contains garbled output. Disabling multisampling in Wine or in the game settings restores proper rendering.

A complication is that the game enables 2x MSAA by default if it is available. A user not knowing this fact will think that 8ed6b140 broke the game. It also makes disabling multisampling in the game settings a challenge.

Hardware info:
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on ATI RV530
OpenGL version string: 2.1 Mesa 9.1-devel (git-8ed6b14)
OpenGL shading language version string: 1.20

01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI M56P [Radeon Mobility X1600]
01:00.0 0300: 1002:71c5
Comment 1 Stefan Dösinger 2013-01-13 16:57:01 UTC
MSAA basically works on this GPU. GALLIUM_MSAA=2 glxgears renders correctly, is slower than glxgears without MSAA and the gear edges look smoother, although it is hard to tell if glxgears is antialiased or not.
Comment 2 Marek Olšák 2013-01-13 19:05:22 UTC
Could you please attach a screenshot of the issue.
Comment 3 Marek Olšák 2013-01-14 00:15:58 UTC
Also, are there any GL errors?
Comment 4 Stefan Dösinger 2013-01-14 10:51:25 UTC
Created attachment 72999 [details]
Screenshot

It looks just like a dump from /dev/random, but here you go :-)

I noticed that the driver seems to reject the multisampled framebuffer during draws, clears and blits:

err:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glDrawElementsBaseVertex @ ../../../wine-git/dlls/wined3d/drawprim.c / 63
fixme:d3d:context_check_fbo_status FBO status GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT (0x8cd6)
fixme:d3d:context_check_fbo_status      Location SFLAG_INRB_MULTISAMPLE (0x200000).
fixme:d3d:context_check_fbo_status      Color attachment 0: (0x186090) WINED3DFMT_B8G8R8A8_UNORM 800x600 2 samples.
fixme:d3d:context_check_fbo_status      Depth attachment: (0x186210) WINED3DFMT_D24_UNORM_S8_UINT 800x600 2 samples.

The problem affects other applications as well, including 3DMark2000(which does not support multisampling itself) when run with GALLIUM_MSAA=2.
Comment 5 Marek Olšák 2013-01-14 14:13:47 UTC
I think this is an issue which should probably be fixed in Wine. There must be something wrong with the FBO setup. The Mesa function which marks the attachment(s) as incomplete is test_attachment_completeness.
Comment 6 Stefan Dösinger 2013-01-14 14:36:17 UTC
I'll have a look at this function and see which check we fail, but I have my doubts that it is Wine's fault. This code works fine on all other drivers - nvidia, fglrx, r600g, osx drivers.

Also keep in mind that MSAA in Wine apps fails if Wine doesn't request the multisampling, but it is enabled with GALLIUM_MSAA=n. I don't see how this can possibly be a fault in Wine.
Comment 7 Marek Olšák 2013-01-14 19:02:28 UTC
Yes, the GALLIUM_MSAA environment variable might break some apps, because it changes the default framebufer to MSAA, which adds lots of limitations to BlitFramebuffer. For example, you can no longer use BlitFramebuffer to do a stretched blit, because the ARB_fbo specification doesn't allow it if either src or dst is multisample, etc.

That's why GALLIUM_MSAA should be used carefully.
Comment 8 Marek Olšák 2013-07-15 02:54:01 UTC
I have found the problem. Wine is trying to use the GL_SRGB8_ALPHA8 format, which is not supported for rendering by the driver internally, but I agree the format should be allowed in the API. The fix is on the way.

Is it a big deal that ARB_framebuffer_sRGB is unsupported? In such a case, the renderbuffer format GL_SRGB8_ALPHA8 is equivalent to GL_RGBA8.
Comment 9 Stefan Dösinger 2013-07-22 16:55:34 UTC
(In reply to comment #8)
> Is it a big deal that ARB_framebuffer_sRGB is unsupported? In such a case,
> the renderbuffer format GL_SRGB8_ALPHA8 is equivalent to GL_RGBA8.
Not really. In this case we generate code in the pixel shader that performs sRGB color conversion as specified in the framebuffer_sRGB spec.

Do r300-r500 GPUs have some dedicated silicon to handle sRGB conversion? If so, it'd be nice to use it.
Comment 10 Stefan Dösinger 2013-07-22 16:57:03 UTC
Fwiw, there's probably a bug in Wine as well. We shouldn't try to render to sRGB formats if framebuffer_sRGB is not supported, but giving textures an sRGB format is the only way to make use of sRGB_decode.
Comment 11 Marek Olšák 2013-07-22 18:20:11 UTC
It's okay to render to an sRGB texture, but FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING should return LINEAR on r300g. That doesn't affect texturing though.