Created attachment 88573 [details] An ugly myriad of white dots CPU: Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz 3.11.6-1-ARCH #1 SMP PREEMPT Fri Oct 18 23:22:36 CEST 2013 x86_64 GNU/Linux local/glu 9.0.0-2 Mesa OpenGL Utility library local/intel-dri 9.2.2-1 Mesa drivers for Intel local/lib32-glu 9.0.0-2 Mesa OpenGL utility library (32 bits) local/lib32-intel-dri 9.2.2-1 Mesa DRI drivers for Intel (32-bit) local/lib32-libtxc_dxtn 1.0.1-5 S3 Texture Compression (S3TC) library for Mesa (32-bit) local/lib32-mesa 9.2.2-1 an open-source implementation of the OpenGL specification (32-bit) local/lib32-mesa-libgl 9.2.2-1 Mesa 3-D graphics library (32-bit) local/libtxc_dxtn 1.0.1-5 S3 Texture Compression (S3TC) library for Mesa local/mesa 9.2.2-1 an open-source implementation of the OpenGL specification local/mesa-demos 8.1.0-1 Mesa demos and tools local/mesa-libgl 9.2.2-1 Mesa 3-D graphics library 3.11.6-1-ARCH --------------- When turning on antialiasing under wine, a myriad of white dots appear. See the enclosed attachment for the apperance of these dots. Steps to reproduce: - open winetricks and install 3dMark2001SE - launch 3dMark2001SE - Select 1680x1050 resolution and set AA to 8 - Launch benchmark and observe small dots on initial benchmark screen and then during actual graphics of benchmark Alternatively: - launch game such as GTA San Andreas - use in game menu to turn on AA and set resolution 1680x1050 I have discussed this bug with one or two participants in the #intel-gfx channel on Freenode. I have created an API trace file, which is available for download here: https://docs.google.com/file/d/0B8rj1_DmnmmrZmtDTnlzTFBnbGc/edit?usp=sharing This was independently tested and the white dots were visible using intel drivers but not under nvidia drivers.
Created attachment 88574 [details] Xorg.0.log
Created attachment 88575 [details] Ugly myriad of dots
Created attachment 88576 [details] output of dmesg
Created attachment 88578 [details] glxinfo
Created attachment 88579 [details] Ugly myriad of dots; example under GTA SA 1680x1050 AA:ON
I've reproduced this and I'm now investigating.
This appears to be the same root cause as bug 53077, which was discovered and diagnosed back in 2012 but never fixed. I've got some experimental code which fixes the problem, but it still needs polishing. I hope to have a fix out to the mailing list by the end of the day. *** This bug has been marked as a duplicate of bug 53077 ***
(In reply to comment #7) > This appears to be the same root cause as bug 53077, which was discovered > and diagnosed back in 2012 but never fixed. > > I've got some experimental code which fixes the problem, but it still needs > polishing. I hope to have a fix out to the mailing list by the end of the > day. > > *** This bug has been marked as a duplicate of bug 53077 *** Wow, I'm impressed by the rapid response. I wonder whether the involvement with the framebuffer ties in my finding that, under wine, using the registry fix: | +->OffscreenRenderingMode | | [Select the offscreen rendering implementation. | | backbuffer - Render offscreen render targets in the backbuffer | | fbo - Use framebuffer objects for offscreen rendering (default) to thereby select 'backbuffer', as opposed to framebuffer, resulted in the problem going away. Unfortuntately however under Wine this resulted in two overlayed images wherein one of the two is rendered upside down(!). This may be completely irrelevant. I wonder whether Intel have commented on the matter?
(In reply to comment #8) > (In reply to comment #7) > > This appears to be the same root cause as bug 53077, which was discovered > > and diagnosed back in 2012 but never fixed. > > > > I've got some experimental code which fixes the problem, but it still needs > > polishing. I hope to have a fix out to the mailing list by the end of the > > day. > > > > *** This bug has been marked as a duplicate of bug 53077 *** > > Wow, I'm impressed by the rapid response. I wonder whether the involvement > with the framebuffer ties in my finding that, under wine, using the registry > fix: > > | +->OffscreenRenderingMode > | | [Select the offscreen rendering implementation. > | | backbuffer - Render offscreen render targets in the > backbuffer > | | fbo - Use framebuffer objects for offscreen rendering > (default) > > to thereby select 'backbuffer', as opposed to framebuffer, resulted in the > problem going away. Unfortuntately however under Wine this resulted in two > overlayed images wherein one of the two is rendered upside down(!). This may > be completely irrelevant. I can think of two possible reasons why this might be the case: (a) It's possible that you don't have a multisampled backbuffer, in which case the problem is going away because you're not getting multisampling anymore (or, at least, you're not getting multisampling for the rendering operations that provoke the bug). (b) It's possible that by coincidence, the upside down image has far fewer artifacts than the right-side up image (I recall when I investigated bug 53077 that the bug was highly sensitive to the orientation of the triangles being drawn). In any case, you're right that it's probably irrelevant. What matters is that we have an apitrace that reproduces the problem, and a good idea of what's going wrong under the hood. > > I wonder whether Intel have commented on the matter? Actually I'm one of the Intel driver developers :). Back when 53077 was first discovered, I tried to get in touch with one of the hardware architects to see if I could get more information about the bug, but I didn't succeed. I'm going to talk to some of the other driver devs today, and depending on what we decide, I may try to ping the hardware architects again.
(In reply to comment #9) > I can think of two possible reasons why this might be the case: > > (a) It's possible that you don't have a multisampled backbuffer, in which > case the problem is going away because you're not getting multisampling > anymore (or, at least, you're not getting multisampling for the rendering > operations that provoke the bug). > Yeah, we only do multisampling with FBOs.
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.