| Summary: | r300g MSAA breaks Half-Life 2 in Wine | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Stefan Dösinger <stefandoesinger> |
| Component: | Drivers/Gallium/r300 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Screenshot | ||
|
Description
Stefan Dösinger
2013-01-13 16:43:16 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. Could you please attach a screenshot of the issue. Also, are there any GL errors? 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.
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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.