Bug 71195

Summary:	Antialiasing glitches visible under wine (e.g. HD4000)
Product:	Mesa	Reporter:	lynx.light0
Component:	Drivers/DRI/i965	Assignee:	Paul Berry <stereotype441>
Status:	RESOLVED DUPLICATE	QA Contact:	Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity:	major
Priority:	medium
Version:	9.2
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	An ugly myriad of white dots Xorg.0.log Ugly myriad of dots output of dmesg glxinfo Ugly myriad of dots; example under GTA SA 1680x1050 AA:ON

Description lynx.light0 2013-11-03 20:04:41 UTC

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.

Comment 1 lynx.light0 2013-11-03 20:06:48 UTC

Created attachment 88574 [details]
Xorg.0.log

Comment 2 lynx.light0 2013-11-03 20:08:02 UTC

Created attachment 88575 [details]
Ugly myriad of dots

Comment 3 lynx.light0 2013-11-03 20:09:19 UTC

Created attachment 88576 [details]
output of dmesg

Comment 4 lynx.light0 2013-11-03 20:30:57 UTC

Created attachment 88578 [details]
glxinfo

Comment 5 lynx.light0 2013-11-03 20:31:58 UTC

Created attachment 88579 [details]
Ugly myriad of dots; example under GTA SA 1680x1050 AA:ON

Comment 6 Paul Berry 2013-11-04 13:52:43 UTC

I've reproduced this and I'm now investigating.

Comment 7 Paul Berry 2013-11-04 15:53:45 UTC

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 ***

Comment 8 lynx.light0 2013-11-04 16:53:05 UTC

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

Comment 9 Paul Berry 2013-11-04 18:09:36 UTC

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

Comment 10 Henri Verbeet 2013-11-05 11:16:17 UTC

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