Bug 12061

Summary: flickering decals, possible polygon offset problem
Product: Mesa Reporter: Tobias Jakobi <liquid.acid>
Component: Drivers/DRI/i915Assignee: haihao <haihao.xiang>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: brian.paul, liquid.acid, michael.fu
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 16029    
Attachments: my xorg.conf
xorg logfile from last run
glxinfo from my system
patch for polygon offset

Description Tobias Jakobi 2007-08-19 08:16:45 UTC
Hi there,

I recently noticed that decals were heavily flickering while gaming. I first noticed this when playing the good old CS 1.5 through wine. I could however also reproduce this with the native q3a version. Marks on wall, and everything that is drawn through decals flickers (I didn't notice this earlier because I have most decal effect deactivated in q3a because of performance).

I don't remember this to happen two weeks ago. I'm regularly updating the whole driver package (drm, mesa, xf86-video-intel) to recent git to track the development.

mesa git version is
53cf87be1b93c760228e6a9af8115d2a9ff99337

AFAIK the whole 3D stuff is in mesa, so I should bisect there, right?
Does bisecting also work when I only have these IDs (how are they called anyway?).

Thanks,
Tobias
Comment 1 Tobias Jakobi 2007-11-11 06:41:21 UTC
The problem is still present with a recent MESA git version:

git version 578641941f45c56deb382317a7ff7cad496679cf
Comment 2 Michael Fu 2008-02-18 23:19:00 UTC
nanhai fixed a polygon offset issue in around end of Dec 2007. Would you please try the latest git? thanks.
Comment 3 Zou Nan hai 2008-02-19 19:26:20 UTC
Hi Jakobi,
   Why do you think it is a polygon offset issue?
I have fixed a polygon offset issue in commit 15653b5d88c0f88f49c2d5497b4fb9e045f53560

Would you please have a try?
Comment 4 Tobias Jakobi 2008-02-20 04:02:46 UTC
Sorry, but I've currently no access to the system I was filing the bug from (my notebook system).

Furthermore I would habe to upgrade both mesa and xorg-server to GIT to make 3D acceleration work. I don't think this would be a good idea with the current state of the system (rather stable, except for the acceleration part).

Was the commit before or after mesa tag 7.0.2 (that's the version that's currently installed on the system).

I have to say that I didn't try any 3D games on the system recently, so the problem might not appear anymore - but I simply didn't recognize it.

I'm checking if I can upgrade to GIT when I have access the system again.

So long,
Tobias
Comment 5 Michael Fu 2008-02-29 16:16:12 UTC
Tobias, any update?
Comment 6 Tobias Jakobi 2008-02-29 18:39:14 UTC
I can confirm that the flickering doesn't appear with mesa 7.0.2, that's the version that's currently installed on the system.

I can't update to GIT because I would have to update also xorg-server and a lot more packages. Sorry, but I resolve the bug to fixed.

When mesa 7.0.3 is released together with the corresponding xorg-server update AND the bug reappears I'm going to reopen this report.
Comment 7 Tobias Jakobi 2008-05-13 14:45:17 UTC
To benefit from TTM and i915tex I did a massive GIT upgrade of core components.

I'm now on mesa GIT (three days old). Must say that speed improvement is quite astonishing; wine's D3D emulation finally doesn't produce a slide show on my screen.

Visual artifacts are there again, so I'm reopening this one.
Comment 8 Tobias Jakobi 2008-05-13 14:59:05 UTC
I should note that apparently i915tex was not used when mesa-7.0.2 was installed on my system.
The intel driver seemed to load i915_dri.so and NOT i915tex_dri.so

Deleting i915tex_dri.so didn't have any effect on 3d acceleration. On the other side deleting i915_dri.so and symlinking from i915tex_dri.so to it didn't work (DRM version didn't match - more precisely the DRM version was too old).

This was on a 2.6.24 kernel with in-kernel DRM modules. I solved this problem by updating most of the core X and core DRM components to GIT (like xorg-server, libdrm, DRM kernel module, mesa, various xyzprotos).

So the problem seems to be in i915tex and NOT in i915 (the old driver implementation).

I had mesa-7.0.3 on this machine for a short time and didn't notice any change in decal behaviour there (no flickering, but also horrible performance). i915 with mesa-7.0.3 didn't have the decal problem.

I don't see any differentiation between i915 and i915tex in the components selector, so I'm not changing this for now :-)
Comment 9 Michael Fu 2008-06-19 00:58:19 UTC
(In reply to comment #8)
> I should note that apparently i915tex was not used when mesa-7.0.2 was
> installed on my system.
> The intel driver seemed to load i915_dri.so and NOT i915tex_dri.so
> 
> Deleting i915tex_dri.so didn't have any effect on 3d acceleration. On the other
> side deleting i915_dri.so and symlinking from i915tex_dri.so to it didn't work
> (DRM version didn't match - more precisely the DRM version was too old).
> 
> This was on a 2.6.24 kernel with in-kernel DRM modules. I solved this problem
> by updating most of the core X and core DRM components to GIT (like
> xorg-server, libdrm, DRM kernel module, mesa, various xyzprotos).
> 
> So the problem seems to be in i915tex and NOT in i915 (the old driver
> implementation).

i915tex is abandoned. please don't use it any more. thanks.

> 
> I had mesa-7.0.3 on this machine for a short time and didn't notice any change
> in decal behaviour there (no flickering, but also horrible performance). i915
> with mesa-7.0.3 didn't have the decal problem.
> 
> I don't see any differentiation between i915 and i915tex in the components
> selector, so I'm not changing this for now :-)
> 

Comment 10 Tobias Jakobi 2008-06-19 02:33:45 UTC
As I said this WAS with mesa-7.0.2!!

Back then two drivers were build: i915tex and i915, with i915tex being the newer one.

Current mesa GIT (which I'm using now) of course only builds ONE driver, which I'm using now and which DOES have the issues with the flickering decals.

So this problem is NOT fixed!

Greets,
Tobias
Comment 11 Michael Fu 2008-06-19 17:22:29 UTC
ok. I'll re-assign to haihao to see if he can reproduce this.
Comment 12 haihao 2008-06-19 19:25:29 UTC
Could you attach some log and config files, such as Xorg.0.log, xorg.conf, the result of glxinfo?

Thanks.
Comment 13 Tobias Jakobi 2008-06-20 06:46:46 UTC
Created attachment 17253 [details]
my xorg.conf
Comment 14 Tobias Jakobi 2008-06-20 06:48:19 UTC
Created attachment 17254 [details]
xorg logfile from last run
Comment 15 Tobias Jakobi 2008-06-20 06:51:37 UTC
Created attachment 17255 [details]
glxinfo from my system
Comment 16 Tobias Jakobi 2008-06-25 09:00:26 UTC
Any update on this one? I can provide some screenshots if that helps.

Greets,
Tobias
Comment 17 haihao 2008-06-25 18:47:36 UTC
You are using mesa7.1rc1(based on master), and according to comment #8, i915 with mesa-7.0.3 (based on mesa7_0_branch) didn't have the decal problem. 

If I understand correctly, this issue only occurs when using i915 with mesa master, right?
Comment 18 Tobias Jakobi 2008-06-26 04:17:47 UTC
(In reply to comment #17)
> You are using mesa7.1rc1(based on master), and according to comment #8, i915
> with mesa-7.0.3 (based on mesa7_0_branch) didn't have the decal problem.
Yes that's correct. Currently there is a mesa GIT (master branch) snapshot from 25. June 2008 installed on the system.
The mesa build system of the master branch only creates one driver for the i915, that is i915_dri.so.

Back when I was using mesa-7.0.3 two drivers were built:
i915_dri.so and i915tex_dri.so

The intel driver was loading the i915_dri.so driver. As already described manually forcing the load of the i915tex driver did NOT work because of the DRM kernel interface version number problem.

The i915_dri.so driver from mesa-7.0.3 was slow, especially with framebuffer operations (glReadPixels, glDrawPixels, etc.)

According to the mesa 6.5.2 release notes (http://www.mesa3d.org/relnotes-6.5.2.html) the i915_dri.so driver from mesa-7.0.3 was the old non-accelerated driver, and i915tex_dri.so the newer one with all the acceleration supported by TTM and co.

I don't know exactly what happened during the development of mesa but I remember that the old i915 driver (non-accelerated version) was dropped in favor of the accerelated (tex-variant) version, and i915tex was renamed to i915.
Is this even correct?

 
> 
> If I understand correctly, this issue only occurs when using i915 with mesa
> master, right?
> 
Yes, the problem appeared when upgrading to mesa GIT master branch. With mesa-7.0.3 the problem did not appear.

As stated above I think this is because the old non-accelerated driver was used.

Greets,
Tobias
Comment 19 haihao 2008-06-26 19:31:48 UTC
Created attachment 17409 [details] [review]
patch for polygon offset

Could you try this patch?
Comment 20 Tobias Jakobi 2008-06-28 05:34:38 UTC
Sure! Tested patch applied on current mesa master GIT (snapshot from today).

Works for quake3 and cs 1.5 (through wine, opengl renderer), no more flickering of decals visible.

Thanks Haihao for fixing this! If you have some additiona time, could you take a look at bug #16520 - also a i915 problem, possibly related to memory corruption (resulting in texture corruption).

Cheers,
Tobias
Comment 21 haihao 2008-06-29 18:27:34 UTC
Hi, Brian
    It seems the commit b755a2d9de5b7977c410a904a8adb7c07c88f82a breaks polygon offset on 915. The attached patch (see comment #19) was tested on 915, but I am not sure whether it breaks other DRI drivers, Could you take a look?

Thanks 
Haihao
Comment 22 haihao 2008-07-01 20:32:33 UTC
Brian, 
  Any comments? If this fix is right, I will check in it to git.
Comment 23 Brian Paul 2008-07-02 09:10:29 UTC
I don't have time to fully test this, but it appears OK.  I'd say go ahead and check it in.
Comment 24 haihao 2008-07-03 18:56:31 UTC
fixed in mesa 0c1e96e6d38c0acfd3fe6b4116f2a67f5bf62136
Comment 25 Adam Jackson 2009-08-24 12:27:48 UTC
Mass version move, cvs -> git

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.