Created attachment 20725 [details]
--3D driver: （master)f1c9016af16aefc08a3e4e859a897009652dac23
--DRM:shipped with kernel for-airlied branch
--Kernel: for-airlied branch commit 728ced8c47f99a2287cdd0d3e77f5ae1a3d410e6
Bug detailed description:
Start X and play doom3/quake4, the display is dark and incorrect, details could be seen in the the attaches.
Created attachment 20726 [details]
Created attachment 20727 [details]
Created attachment 20728 [details]
Created attachment 20729 [details]
Created attachment 20730 [details]
With drm-next branch, it also exists.
This may be the same as bug#18822, which has bisected to a commit. Could you also check if it's caused by that commit?
How about on 965?
Maybe, I need soome screenshot to make sure but there are none in that bug. "git checkout 8e5639577c03ccd75bb421e494638fbb5a3e7dcd~1 <--- Works", on our g45, it is the first commit with which we can test games without low performance or freezing.
(In reply to comment #8)
> Maybe, I need some screenshots to make sure but there is none in that bug.
> "git checkout 8e5639577c03ccd75bb421e494638fbb5a3e7dcd~1 <--- Works", on our
> g45, it is the first commit with which we can test games without low
> performance or freezing.
q965, gm45 have this issue too, 945 is fine.
I'm confused, are you saying that this bug is gone with 8e5639577c03ccd75bb421e494638fbb5a3e7dcd~1? If so, it should be fixed in master, but this bug report started at something that was before 8e5639577c03ccd75bb421e494638fbb5a3e7dcd.
(In reply to comment #10)
> I'm confused, are you saying that this bug is gone with
> 8e5639577c03ccd75bb421e494638fbb5a3e7dcd~1? If so, it should be fixed in
> master, but this bug report started at something that was before
In other words, no low performance and freezing issue in doom3/quake4, but they have incorrect texture issue. f1c9016af16aefc08a3e4e859a897009652dac23
is a mistake, it should be 154a9e5317f890618932cea0129ef887e16baf84.
Sorry for the confusion.
This is most likely the same as bug 18516 I reported earlier. Feel free to mark it as a duplicate of this.
*** Bug 18516 has been marked as a duplicate of this bug. ***
Shadows are correct in Mesa 7.2, I will try bisecting it to find the problem.
Bisecting lead to this:
2511d57fa487e4b46a4919913103c2491da7a856 is first bad commit
Author: Ian Romanick <email@example.com>
Date: Mon Sep 22 17:23:40 2008 -0700
i965: Adapt to new TNL program tracking semantics
This fixes bugzilla #17718.
:040000 040000 1841c56af7560cbf06e8d0d5946e263e10cf3952 c24eab238976ea5daac465a8d5ba521c68530a0e M src
reproduced in quake4-demo. Thanks for the bisect.
note to self: emit_state_always doesn't help. probably a functional change in the porting of the code to mesa core?
I was looking into quake4 last night -- everything looks fine with depth clears stubbed out to software (tri_mask &= ~BUFFER_BIT_DEPTH).
glFlush before/after depth clear doesn't help.
depth clear separate from stencil clear doesn't help.
always_flush_batch=true doesn't help.
glReadPixels(GL_DEPTH_COMPONENT) of ((xmin+xmax)/2, (ymin+ymax)/2) before and after the depth clear shows no changes.
Between depth clears, the depth value sampled moves slowly from 1.0 down to 0.95ish over the course of the half a minute of moving around I do in the level while testing.
glGetError() returns 0 before/after.
ctx->Stencil stays the same before/after except for _Enabled (since _mesa_update_state isn't called again by the time I was comparing results)
ctx->Depth stays the same before/after.
incoming depth state to intel_clear_tris:
DepthRange is at (0,1), so that being missing isn't the problem.
depth test true
depth mask true
clear value 1.0.
Author: Eric Anholt <firstname.lastname@example.org>
Date: Mon Jul 20 17:58:12 2009 -0700
i965: Don't clip everything if FRONT_AND_BACK culling while culling disabled
Fixes everything-black with meta_clear_tris on quake4-mpdemo and doom3-demo.
Bug #18844, 22077.
Eric, we are verifying it's fixed on master. Do you have plan to put it into mesa_7_5_branch?
verified on master