Kernel: (drm-intel-fixes) f01c22fd59aa10a3738ede20fd4b9b6fd1e2eac3
Bug detailed description:
Screen mess when running 3D games(like ExtremeTuxRacer,lightsmark).Pls see attachment photos.
2.run 3D games(like ExtremeTuxRacer,lightsmark)
Created attachment 48641 [details]
the photo of Extreme TuxRacer
Created attachment 48642 [details]
the photo of lightsmark
These look like they're probably stencil related. This may be a dup of bug #39132.
Doubtful. I can confirm this bug, even after Chad's stencil fixes.
Interestingly, using Eric's ff_fragment_shader patches changes the misrendering (but doesn't fix it).
Could you please confirm if the issue still happens with latest master?
The problem is still exists with latest mesa master 4a96a02de7c1b8c136ffc0cd278401c85faab233 in IVB. (In reply to comment #5)
> Could you please confirm if the issue still happens with latest master?
It still exists on mesa 7.11 branch.
Ken, what's the plan? Can we fix this in the next release?
I'm fairly certain that the TuxRacer and Lightsmark bugs are separate issues. Both are really high on my priority list for Ivybridge fixes, I just haven't had any luck figuring out the problem. I may need to try Carl's new apitrace trim tools and see if I can cut down the problem to something more tractable.
Ken, good to know this is on your high priority list. If you don't mind, I'm adding this into the release blocker tracker.
If you think they should be separated into different bug reports, just let us know.
Here is a cut-down apitrace that reproduces the etracer issue:
It's a dirty bit issue. Adding more dirty bits to the gen7_ps_state atom fixes etracer, but I have absolutely no idea why any of them should be necessary.
I've sent a patch to the mailing list that fixes ExtremeTuxRacer:
[PATCH] i965: Don't reallocate push constant URB space on new VS programs.
It did turn out to be a dirty bit issue---but I wasn't missing any on gen7_ps_state. I had too many on gen7_urb. :)
As I suspected from the beginning, the Lightsmark issue is entirely unrelated. No leads on that yet.
I notice that in your lightsmark screenshot, everything is bright pink. On my system it's bright yellow.
I know this sounds odd, but...if you run the Piglit "tex-border-1" program, does it display a pink square? On my system it's the same bright yellow that I see in Lightsmark.
(In reply to comment #14)
> I notice that in your lightsmark screenshot, everything is bright pink. On my
> system it's bright yellow.
> I know this sounds odd, but...if you run the Piglit "tex-border-1" program,
> does it display a pink square? On my system it's the same bright yellow that I
> see in Lightsmark.
Also, note that the color produced likely depends on the exact machine being used.
Xun, can you reply Ken today?
It display a yellow square.
Is Lightsmark still pink, or is it yellow too?
Nevermind, I believe I've fixed this. I'll send the patch out shortly.
Lightsmark is now fixed. On master, the commit is:
Author: Kenneth Graunke <firstname.lastname@example.org>
Date: Fri Jan 20 03:33:40 2012 -0800
i965: Fix border color on Sandybridge and Ivybridge.
While reading through the simulator, I found some interesting code that
looks like it checks the sampler default color pointer against the bound
set in STATE_BASE_ADDRESS. On failure, it appears to program it to the
base address itself.
So I decided to try programming a legitimate bound, and lo and behold,
border color worked.
+92 piglits on Sandybridge. Also fixes Lightsmark on Ivybridge.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunke <email@example.com>
Reviewed-by: Yuanhan Liu <firstname.lastname@example.org>
Reviewed-by: Eric Anholt <email@example.com>
This has also been cherry-picked to 8.0.
Closing the report as both bugs have been fixed.
so it should be mesa blocker not kernel.
This issue has been resolved now. My tested environment :