Bug 58033 - [r300g][r600g] Black gap artifacts when playing WoW
Summary: [r300g][r600g] Black gap artifacts when playing WoW
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-08 22:20 UTC by Chris Rankin
Modified: 2019-09-18 19:01 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Screenshot of corruption in WoW (802.80 KB, image/png)
2013-01-20 22:35 UTC, Chris Rankin
Details
Screenshot of corruption in WoW (549.57 KB, image/jpeg)
2013-01-20 23:35 UTC, Chris Rankin
Details
More corruption in WoW (518.09 KB, image/jpeg)
2013-01-20 23:37 UTC, Chris Rankin
Details
Yet more corruption in WoW (558.06 KB, image/jpeg)
2013-01-20 23:39 UTC, Chris Rankin
Details

Description Chris Rankin 2012-12-08 22:20:25 UTC
When playing WoW with the latest Mesa from git, sometimes black lines and gaps on the screen. These black spaces appear momentarily as I move around, like intense shadows. Sometimes, the entire screen appears to go blank.

export RADEON_DEBUG=nohiz makes no difference, and no "acquiring HyperZ" messages are printed on the console.

This is with a T60p laptop with a M66GL (RV535?) chip, running a 32 bit Linux 3.6.9 kernel.
Comment 1 Marek Olšák 2012-12-08 22:24:11 UTC
Try: RADEON_DEBUG=nozmask
Comment 2 Marek Olšák 2012-12-08 22:25:35 UTC
Also try reverting the commit e866bd1adea2c3b4971ad68e69c6.
Comment 3 Chris Rankin 2012-12-09 22:42:03 UTC
(In reply to comment #2)
> Also try reverting the commit e866bd1adea2c3b4971ad68e69c6.

I've tried this, and have also tried RADEON_DEBUG=nohiz,nozmask,nocbzb. However, I'm still seeing the problem. Interestingly, the problem does not happen with Fedora's "stock" Mesa drivers mesa-dri-drivers-8.0.4-1.fc17.i686.
Comment 4 Alex Deucher 2012-12-10 16:00:33 UTC
Can you bisect?
Comment 5 Chris Rankin 2012-12-16 22:25:53 UTC
(In reply to comment #4)
> Can you bisect?

Apparently, this is the bad commit:

39737e17e7a61535a35669756161005a7a5c887b is the first bad commit
commit 39737e17e7a61535a35669756161005a7a5c887b
Author: Marek Olšák <maraeo@gmail.com>
Date:   Mon Dec 3 01:26:22 2012 +0100

    st/dri: always allocate private depth-stencil buffers
    
    This disables DRI2 sharing of zbuffers. The window zbuffer is allocated just
    like any other texture - through resource_create.
    
    The idea of allocating a zbuffer through DRI2 isn't very useful with MSAA,
    where a single-sample zbuffer is useless.
    
    IIRC, the Intel driver does the same thing.
    
    Reviewed-by: Brian Paul <brianp@vmware.com>

:040000 040000 e8045e2d2c7e9a1ebd6eb1f22c93b97b9c3e8ce7 4deb5755e011d592366e6140bf385bfefe157f3f M	src
Comment 6 Chris Rankin 2013-01-14 22:20:54 UTC
This bug is still present after Marek's latest r300g commits: HEAD is

commit e3e1ffb2520498584ef402213d0c8aa4303a46a3
Author: Marek Olšák <maraeo@gmail.com>
Date:   Mon Jan 14 05:51:05 2013 +0100

    r300g: set a dummy vertex buffer in context_create
    
    so that the driver doesn't crash if an app doesn't set any vertex buffers.
Comment 7 Tomasz P. 2013-01-14 22:55:16 UTC
Marek Olšák post some patches on mailing list that implementing separate depth-stencil clear. Maybe they will help.
Comment 8 Chris Rankin 2013-01-17 22:06:52 UTC
Still broken as of git HEAD:

commit ca39c0f94a4e3cc25b6cc9507fb729b85140733a
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Wed Jan 16 15:34:49 2013 -0800

    mesa/es3: Don't check dimensions in _mesa_es3_error_check_format_and_type
Comment 9 Marek Olšák 2013-01-17 22:28:27 UTC
Could you please attach a screenshot showing the issue?
Comment 10 Chris Rankin 2013-01-17 23:07:19 UTC
(In reply to comment #9)
> Could you please attach a screenshot showing the issue?

Sorry, the corruption is not showing up which I press the "Print Screen" button. I shall attempt to describe instead:

Imagine moving towards a forest, with the trees in the centre of your screen. As you approach the forest, you expect the trees to get larger and appear to slide towards the left and right edges of your screen. (That's perfectly ordinary depth-perception). The corruption seems to be that nothing is immediately rendered where the trees used to be, leaving large black gaps. When you stop moving, the black gaps are quickly filled again.
Comment 11 Chris Rankin 2013-01-20 22:35:10 UTC
Created attachment 73347 [details]
Screenshot of corruption in WoW

(In reply to comment #9)
> Could you please attach a screenshot showing the issue?

I've managed to capture a screenshot using GIMP instead of the Print Screen button.
Comment 12 Chris Rankin 2013-01-20 23:35:56 UTC
Created attachment 73348 [details]
Screenshot of corruption in WoW
Comment 13 Chris Rankin 2013-01-20 23:37:01 UTC
Created attachment 73349 [details]
More corruption in WoW

Another screenshot, to give you a better idea.
Comment 14 Chris Rankin 2013-01-20 23:39:00 UTC
Created attachment 73350 [details]
Yet more corruption in WoW

All of these screenshots were taken while moving. The corruption disappears in a stationary shot.
Comment 15 Chris Rankin 2013-01-26 15:13:54 UTC
I've just upgraded one of my 32 bit boxes to Fedora 18, which has allowed me to compile Mesa git here. And I can now report that the corruption happens with an RV730 chip too.
Comment 16 Chris Rankin 2013-01-26 16:56:02 UTC
My CAICOS (HD6450) is not affected by this bug (64 bit).
Comment 17 Chris Rankin 2013-01-27 22:09:24 UTC
My RV790 (HD4890) is also unaffected by this bug. And this box is 64 bit too. Could it just be a coincidence that both of my affected boxes are 32 bit?
Comment 18 Chris Rankin 2013-07-16 19:36:04 UTC
This bug is still happening on my 32 bit T60p after #66921 has been fixed.
Comment 19 Tomasz P. 2013-09-13 15:43:49 UTC
(In reply to comment #15)
> I've just upgraded one of my 32 bit boxes to Fedora 18, which has allowed me
> to compile Mesa git here. And I can now report that the corruption happens
> with an RV730 chip too.

This corruption appears with all shader backends (sb,llvm,sb+llvm) ?
Comment 20 Chris Rankin 2013-09-14 11:12:51 UTC
(In reply to comment #19)
> This corruption appears with all shader backends (sb,llvm,sb+llvm) ?

Actually, the RV730 corruption has changed: instead of the "shadow-like" artifacts, the window beneath the UI briefly turns completely black instead. (Or sometime completely blue - I guess it depends on my location in the game).

This corruptions happens both with and without RADEON_DEBUG=nosb.
Comment 21 GitLab Migration User 2019-09-18 19:01:50 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/427.


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.