Created attachment 20726 [details]
conf

Created attachment 20727 [details]
screenshot

Created attachment 20728 [details]
screenshot

Created attachment 20729 [details]
screenshot

Created attachment 20730 [details]
screenshot

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
> 8e5639577c03ccd75bb421e494638fbb5a3e7dcd.
> 

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
commit 2511d57fa487e4b46a4919913103c2491da7a856
Author: Ian Romanick <ian.d.romanick@intel.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
func GL_ALWAYS
clear value 1.0.

commit 81d555068408d4343d7627c8bedda5675f09bd21
Author: Eric Anholt <eric@anholt.net>
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