Bug 22181 - r200: Doom3 engines with r200 renderer (Mesa-7.5-rc3 regression)
Summary: r200: Doom3 engines with r200 renderer (Mesa-7.5-rc3 regression)
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r200 (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-09 12:15 UTC by smoki
Modified: 2009-06-19 11:04 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Doom3 (49.91 KB, image/jpeg)
2009-06-09 12:15 UTC, smoki
Details
prey (46.04 KB, image/jpeg)
2009-06-09 12:16 UTC, smoki
Details
possible fix (495 bytes, patch)
2009-06-09 18:29 UTC, Roland Scheidegger
Details | Splinter Review

Description smoki 2009-06-09 12:15:15 UTC
Created attachment 26599 [details]
Doom3

Screenshots from Doom3 and Prey attached. They was worked good in 7.4.2, also
they works good now in 7.5-rc3 with r200 renderer, but only when sw tcl is used.
arb renderer not have this problem.

 Problem is very similar to bug #20965, but now seems to be Doom3 based games are affected only.
Comment 1 smoki 2009-06-09 12:16:28 UTC
Created attachment 26600 [details]
prey
Comment 2 Roland Scheidegger 2009-06-09 18:29:24 UTC
Created attachment 26606 [details] [review]
possible fix

No this rather looks like classic z fighting, I think this bug reappeared a couple of times already.
Does this patch fix it?
I think r100 should also do this though it won't matter for doom3 (and results between fixed function and vertex programs will be different anyway since one will be running in hw one in sw so it might not really help there). (r300 probably wants to set this too.)
Comment 3 smoki 2009-06-09 19:21:44 UTC
(In reply to comment #2)
> Does this patch fix it?

 Yes, it is good now. And yes it is z-fighting thing, it remains on mirrors in toilets in both Doom3 and Prey, but OK that is a known thing, not a regression here... Thanks.

Comment 4 Maciej Cencora 2009-06-09 19:22:28 UTC
(In reply to comment #2)
> Created an attachment (id=26606) [details]
> possible fix
> 
> No this rather looks like classic z fighting, I think this bug reappeared a
> couple of times already.
> Does this patch fix it?
> I think r100 should also do this though it won't matter for doom3 (and results
> between fixed function and vertex programs will be different anyway since one
> will be running in hw one in sw so it might not really help there). (r300
> probably wants to set this too.)
> 

How does dp4/mad selection affect the resulting vertex position?
Comment 5 Roland Scheidegger 2009-06-10 04:03:40 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > Created an attachment (id=26606) [details] [details]
> > possible fix
> > 
> > No this rather looks like classic z fighting, I think this bug reappeared a
> > couple of times already.
> > Does this patch fix it?
> > I think r100 should also do this though it won't matter for doom3 (and results
> > between fixed function and vertex programs will be different anyway since one
> > will be running in hw one in sw so it might not really help there). (r300
> > probably wants to set this too.)
> > 
> 
> How does dp4/mad selection affect the resulting vertex position?
This affects resulting vertex position only very slightly due to rounding errors. The reason for z fighting is doom3 renders the same geometry twice, first pass with fixed function (for shadows), second pass with vertex program. If the generated fragments don't match z fighting will happen, and since r200 uses DP4 for fixed function hw tcl we need to match that for vertex program.
Comment 6 Roland Scheidegger 2009-06-19 11:04:21 UTC
Fixed in master and mesa_7_5_branch.


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.