Bug 100239

Thanks for reporting this.

It would be nice if you can upload good/bad screenshots. And it would be very nice if you can record an apitrace which reproduces the issue.

I can't reproduce this with my Fury, and have never seen it, for reference...
Any tweaks like R600_DEBUG etc?

Hello,

I have the same problem on my RX 480 and current mesa git.
I produced an apitrace but it is ~734MiB and trimming seems to be corrupting it, I might be doing something wrong.
How should I share and eventually trim/extract only the relevant part from the trace?

You can upload the trace on Google Drive or some similar storage service.

I took another apitrace, which I uploaded here : http://dl.free.fr/u43NDpptG
But when I replay my traces (glretrace), I notice :
- Graphical corruptions when I open the ingame console or when a map is loaded  (which is NOT a problem I seen during normal runtime). The menu is fine.
- The scope bug (this report subject) is not visible from the replayed trace on my end... 

Maybe it is an apitrace bug from my side? Not sure if I may report this to the apitrace project, this happens in apitrace from git too.

Try setting the environment variable MESA_EXTENSION_OVERRIDE=-GL_ARB_buffer_storage when capturing the apitrace.

Thank you very much Michel, indeed masking this extension produces a correct trace that can be replayed to reproduce the scope bug.

So here is a new apitrace showing the bug : http://dl.free.fr/oD7tgoSw9

For reference, the outside of the scope is supposed to be slightly blurred. Random screenshot found on google images to show the expected rendering : http://misc.team-aaa.com/perso_skullgun/MaJCSGO/Augscope.jpg

Thanks for the trace.

The issue can be reproduced with mesa/llvm from today on RX480. I'm investigating.

Created attachment 131302 [details] [review]
bo clear hack, needs 4.9 kernel at least

This seems to be the same problem as with DOOM Vulkan, some buffer is not cleared  when it should be. It still needs to be investigated wether it's game's fault or radeonsi's though...

Thank you Samuel.

Grazvydas, thanks for the patch, it does fix the visual issue, even though I understand this is not a proper fix. I did not notice a performance drop (in CS:GO at least) with it, so I will be using until this issue is resolved.

There is no corruption on scope with current mesa git + llvm 6.0 on TAHITI. I don't have RX480 anymore, so I can't test it with POLARIS.

The apitrace link not longer works so can't test on POLARIS but assuming this is fixed as per comment 11. Please reopen if this is not the case.

Created attachment 140499 [details]
issue on 18.1.3

Unfortunately this is not resolved on RX480 and mesa 18.1.3.
I attached a screenshot of the issue.

(In reply to Bruno Jacquet (Xaapyks) from comment #14)
> Unfortunately this is not resolved on RX480 and mesa 18.1.3.
> I attached a screenshot of the issue.

I confirm this is happening on mesa-git + RX560. Unfortunately, the hardware is not mine, so I cannot test it with bo clear hack. There is also some texture corruption ob de_nuke, but i'm not sure if it's related to this bug: https://i.imgur.com/tjfI2uY.jpg. If someone can test these with bo clear hack please do it, I can't do it myself as I'm still waiting for the refund money for my dead RX480 :(

Here is the apitrace for the scope bug : http://xaapyks.info/csgo_linux64.3.trace.bz2 (mesa 18.1.3)
md5 = a876e4fd64168486c3e6dfefd9edca86

It seems I have to set STEAM_RUNTIME=0 to reproduce it.

>There is also some texture corruption ob de_nuke, but i'm not sure if it's related to this bug: https://i.imgur.com/tjfI2uY.jpg.
I am not experiencing this.

Still happens with Mesa git master 9fc1ce258cf956d21a9d4940a3c10c5547d93408, Polaris10 only, Oland and Tahiti are not affected.

Is this bug still being worked on?

The problem is still here, but there's a little update: sometimes texture gets cleared correctly. 

Currently running Mesa git master 31e4c9ce400341df9b0136419b3b3c73b8c9eb7e

If you run steam from the command line with:

R600_DEBUG=zerovram steam

Does that fix the issue for you?

(In reply to Timothy Arceri from comment #19)
> Does that fix the issue for you?

Yes, it does fix scope rendering for me.
Is any negative performance impact to be expected with that flag? Also, is it doing effectively same thing as patch from comment #9?

(In reply to network723 from comment #20)
> (In reply to Timothy Arceri from comment #19)
> > Does that fix the issue for you?
> 
> Yes, it does fix scope rendering for me.
> Is any negative performance impact to be expected with that flag?

Potentially but it's unlikely to be noticeable. 

> Also, is it doing effectively same thing as patch from comment #9?

Yes.

Should be fixed by:

commit 49025292fbbf285d4473d2c20a83b6c533a79d45
Author: Timothy Arceri <tarceri@itsqueeze.com>
Date:   Mon May 6 14:39:44 2019 +1000

    radeonsi: add config entry for Counter-Strike Global Offensive
    
    This fixes rendering issues with gun scopes which is rather
    important.
    
    Cc: "19.0" "19.1" <mesa-stable@lists.freedesktop.org>
    Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100239

Since my last message I upgraded my GPU, I now have a Vega 64, and in mesa 19.1.3 I still have the issue, the AUG scope is being all garbled with black patches.

mesa 19.1.3 appears to have a cherry-pick of the commit (825ca9e42eacd305a63f63c61fbbe6348b0266aa) and I checked, I do have the conf in my filesystem:

$ grep -A2 "Counter-Strike Global Offensive"  /usr/share/drirc.d/00-mesa-defaults.conf
        <application name="Counter-Strike Global Offensive" executable="csgo_linux64">
            <option name="radeonsi_zerovram" value="true" />
        </application>

So I'd say the issue is still there.

Created attachment 144987 [details]
vega 64 on mesa 19.1.3

(In reply to Bruno Jacquet (Xaapyks) from comment #23)
> So I'd say the issue is still there.

Maybe you have a ~/.drirc or other drirc file which gets picked up and disables radeonsi_zerovram? (E.g. due to ever starting the old "driconf" application with a driver which supported the option)

(In reply to Michel Dänzer from comment #25)
> (In reply to Bruno Jacquet (Xaapyks) from comment #23)
> > So I'd say the issue is still there.
> 
> Maybe you have a ~/.drirc or other drirc file which gets picked up and
> disables radeonsi_zerovram? (E.g. due to ever starting the old "driconf"
> application with a driver which supported the option)

~/.drirc and /etc/drirc do not exist on my fs.
/usr/share/drirc.d only contains 00-mesa-defaults.conf which is not modified from what the mesa build provides and is packaged in Arch.

strace seems to confirm it is not loading any other "drirc" file any and I don't have any "*MESA*" or "*GL*" env var.

(In reply to Bruno Jacquet (Xaapyks) from comment #26)
> (In reply to Michel Dänzer from comment #25)
> > (In reply to Bruno Jacquet (Xaapyks) from comment #23)
> > > So I'd say the issue is still there.
> > 
> > Maybe you have a ~/.drirc or other drirc file which gets picked up and
> > disables radeonsi_zerovram? (E.g. due to ever starting the old "driconf"
> > application with a driver which supported the option)
> 
> ~/.drirc and /etc/drirc do not exist on my fs.
> /usr/share/drirc.d only contains 00-mesa-defaults.conf which is not modified
> from what the mesa build provides and is packaged in Arch.
> 
> strace seems to confirm it is not loading any other "drirc" file any and I
> don't have any "*MESA*" or "*GL*" env var.

I just tested the trace from comment 16 on my Vega 64 and using the environment variable fixed the issue for me. Do you have an old kernel? radeonsi_zeroram=true will do nothing on pre 4.9 kernels.

If you have at least 4.9 can you try closing steam then running it from the command line with:

radeonsi_zeroram=true steam

And then run CS:GO. This should force the setting even if your system is not picking up the right config file.

-- 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/1261.