Bug 28363

Summary: [stencil_twoside] shadows wrong in doom3
Product: Mesa Reporter: Tobias Jakobi <liquid.acid>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: hramrach, jonjon.arnearne, pedretti.fabio
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Tobias Jakobi 2010-06-02 17:39:23 UTC
Hi there,

I'm using the most recent drm-radeon-testing kernel which incorporates the r6xx+ tiling patchset. Both the ddx and mesa are patched so that tiling is used (ColorTiling=true in xorg.conf).

Both ddx and mesa are also git master (plus the patches, like stated before).

Just tried the doom3 demo and noticed that the shadows are not rendered correctly, probably some issue with stencil buffering.

Should be reproducable with this version of the demo:
doom3-linux-1.3.1.1304.x86.run

Played around a bit with the ingame graphics settings, but ramping the quality up and down doesn't have any effect on the issue (when not completly disabling the shadows). Looks like it always uses the same approach, I think it was called Carmack's reverse.

Performance is quite good and I don't see any other obvious rendering issues, so fixing the stencil stuff would make d3 a 'perfectly playable' game on the OSS driver :)

Greets,
Tobias
Comment 1 Tobias Jakobi 2010-06-02 17:39:52 UTC
Forgot to mention my hardware:
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon HD 4770 [RV740]
Comment 2 Alex Deucher 2010-06-02 21:52:01 UTC
Are you saying this is a regression with the tiling patches?  Does it render correctly without the tiling patches?  Also, make sure you have the drm patch in bug 28327.
Comment 3 Andy Furniss 2010-06-03 02:51:26 UTC
(In reply to comment #2)
> Are you saying this is a regression with the tiling patches?  Does it render
> correctly without the tiling patches?  Also, make sure you have the drm patch
> in bug 28327.

Not a regression for me - doom 3 demo has never rendered shadows properly as long as I have been testing rv670. I thought it was a known issue and would maybe get better when shadowtex starts working.
Comment 4 Tobias Jakobi 2010-06-03 07:05:48 UTC
(In reply to comment #2)
> Are you saying this is a regression with the tiling patches?  Does it render
> correctly without the tiling patches?  Also, make sure you have the drm patch
> in bug 28327.

No, no - like Andy wrote this is no regression introduced by the tiling patches. The shadows are even wrong without tiling, but of course performance is worse then.
Comment 5 Alex Deucher 2010-06-03 08:23:06 UTC
Ok, updating the topic appropriately.
Comment 6 Tobias Jakobi 2010-06-03 08:28:23 UTC
Ok, sry - I see now, adding 'tiling' to the description was of course confusing :)
Comment 7 Andre Maasikas 2010-06-03 12:39:00 UTC
I looked it a while back and if i remember correctly this went like:
Doom uses ext_stencil_two_side if available
There's 2 back stencil states: 
1 opengl 2.0
2 ext_stencil_two_side
Mesa sets ctx->Stencil._BackFace to 2 if GL_STENCIL_TEST_TWO_SIDE_EXT
is enabled and to 1 otherwise - this is what r600 and also intel? uses

Doom3 does some stencil setup while
GL_STENCIL_TEST_TWO_SIDE_EXT disabled and the driver uses wrong values then

The spec is imho also inconclusive but i read it as GL_STENCIL_TEST_TWO_SIDE_EXT
should be 'tested' at rendering time and you can set up backface stencil state
(via glActiveStencilFaceEXT) while this enable is not (yet) set.

2 options, use ctx->Stencil.ActiveFace in driver as in stencil.c
or set ctx->Stencil._BackFace also to 2 in _mesa_ActiveStencilFaceEXT()

I'm setting this to core mesa for comments
Comment 8 Tobias Jakobi 2010-08-09 15:36:41 UTC
Just wanted to retest this, but I can't even get ingame. After the level loading is done the app simply freezes. No messages in the kernel log.
Comment 9 Andre Maasikas 2010-08-19 08:42:31 UTC
also replaced (r600, kms) with stencil_twoside in description
Comment 10 Tobias Jakobi 2010-10-15 17:05:05 UTC
Graphics look perfect now with r600g, I didn't bother to check with the classic driver. Since all major development effort currently goes into gallium, I'm resolving this one to fixed.

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.