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
Forgot to mention my hardware: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon HD 4770 [RV740]
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.
(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.
(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.
Ok, updating the topic appropriately.
Ok, sry - I see now, adding 'tiling' to the description was of course confusing :)
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
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.
also replaced (r600, kms) with stencil_twoside in description
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.