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.
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
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.
Could you please attach a screenshot of the issue.
Also, are there any GL errors?
Created attachment 72999 [details]
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.
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.
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.
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.
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.
(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.
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.
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.
Fixed by http://cgit.freedesktop.org/mesa/mesa/commit/?id=1302c66896e6fbdb4eeb086d41901ddaeb89513f Closing.
on Dec 04, 2016 at 16:17:38.
(provided by the Example extension).