So I got a good gaming session in last night with GPL enabled on FFVII and I only noticed one negative thing -- what appears to be texture streaming issues. Occasionally upon entering a new area, doing an unused summon, fighting a new enemy, and things like that can cause textures to lose detail for a few seconds. GPL actually seems to have fixed an issue I had with my stupid-long RADV_PERFTEST line -- when accessing the Weapon Upgrade screen using my line before it was very laggy and janky on that screen with and without GPL. Fired it up last night with the full line + GPL and that screen was as smooth as ever.

Aside from that texture streaming issue that is more prominent with GPL, everything seemed to be better. Frankly, even the streaming issues were better than before since it'd stutter for a few seconds while I assume it was generating shader cache.

It really sucks not being able to run DXVK_HUD with an Epic game. Not sure what causes this, but using DXVK_HUD in Lutris gives the HUD to Epic and putting a DXVK_HUD line in dxvk.conf next to the FFVII executable causes the game to crash.

Linux People Problems.

If anyone is curious:

RADV_PERFTEST=cswave32,dccmsaa,gewave32,gpl,ngg_st reamout,nggc,nv_ms,pswave32,rt,rtwave64,sam

Now if I could only beat that son of a bitch Jules at pull-ups....

DXVK_HUD doesn't work with FFVII because it runs on DX12 by default, which also means that GPL doesn't help and only disables the shader cache. Also wtf is that RADV_PERFTEST line? You do realize that most of those thing are not the default because thay are detrimental in general, right? Especially ngg_streamout most likely hurts on RDNA2 and all the wave32 stuff probably too, did you actually benchmark any of this?

Just enabled them blindly to see what would happen. Got a new GPU a couple weeks ago and figured why not the other day which just happened to coinside with all this..

According to that vkoverhead it's a tiny bit slower with all that enabled. I just finished diffing with and without.

EDIT: Because the Mesa documentation doesn't really help someone know what option should be used with what generations (without really, really digging into the source and commit history conversions), which ones would be helpful for a 6700XT?

EDIT: And per your suggestion I shortened the line to RADV_PERFTEST=dccmsaa,gpl,nggc,nv_ms,rt,rtwave64,s am which seemed either be more performant with negligible differences according to vkoverhead. Using the misc tests at the end, only "126, misc_resolve_mutable," was slower by 2 TOPS while the rest were the same or faster (or unsupported in the case of GPL).

In regards to the shader caching, I don't care if it's disabled if the game plays and feels better. Outside of some textures looking like they're from the PS2 or PS3 for a few seconds the game itself is smoother. I don't seem to notice the micro-stutter that this game is notorious for with GPL.

Success!!!


I used RADV_PERFTEST=dccmsaa,gpl,nggc,nv_ms,rt,rtwave64,s am

That's also in HDR

Oh, and with all that other stuff disabled I didn't have (or notice) any of those texture issues I was noticing last night.

And that was my 2nd time trying today.

I tried for something like an hour and a half to beat that mini-game last night

Have you actually benchmarked any of those? I think you don't need them.

• pswave32 will definitely hurt performance
• rtwave64 will definitely hurt performance on RDNA2 (we don't have enough data about RDNA3 yet to judge)
• sam is automatically enabled by the driver when beneficial and will otherwise hurt performance
• nv_ms is only there for historical reasons and will be removed soon, please don't use this
• dccmsaa is not enabled by default because it isn't finished yet
• cswave32, gewave32, ngg_streamout: shouldn't hurt, but we haven't enabled them by default because we haven't measured a noticable benefit in any benchmark. I'm curious whether you notice any perf difference from them, let me know please

pswave32 definitely hurts performance, but the others shouldn't. Do you have a reason why you think they would? I'm not aware of a benchmark where they made a notable difference either way.
​

Generic test, but a few minutes ago I ran from the Sector 6 Park to the Wall Market Gym in FFVII and didn't have a single texture stream issue that was very noticeable last night when running between areas. Granted, until very, very recently I only every tried the game with all or none in regards to the PERFTEST line and this was my first time trying with the shortened one. Like I said, new card so I skimmed the man pages threw darts at the wall to see what stuck. Playing with HDR made me curious.

Removing all the wave32 stuff definitely helped. I wouldn't be surprised if they're what caused the texture issues in conjunction with GPL since I didn't have those issues when they were enabled but not using GPL.

vkoverhead is for benchmarking CPU overhead of drivers, it is not for measuring GPU-bound performance which the above options affect.

Please open a bug report in mesa if you think wave32 mode casues visual glitches. Don't forget to select the Radeon Vulkan bug report template and provide us with steps to reproduce the problem.

I think it's only with GPL. Well, actually, I did notice very bad frame pacing in the Weapon Upgrade screen with them enabled and, funnily enough, didn't when GPL enabled.

I need to experiment some more to see what makes what happen before I submit anything official. I just happened to notice that the full blown line without GPL caused stuttering in the FFVII Weapon Upgrade screen and adding GPL fixed that while simultaneously causing lower quality textures for a second or three upon loading assets. Removing the wave32 stuff while keeping GPL fixed the low quality texture asset loading I was noticing and the stuttering was gone in that upgrade screen. Without any PERFTEST I didn't have either issue but the game itself is tends to micro-stutter and both something in the previous line and GPL both help with the game's micro-stuttering. The biggest takeaway, AFAICT, is that one of the wave32 options + gpl causes it. That's the only time I've noticed it.

Should I try RADV_PERFTEST=cswave32,dccmsaa,gewave32,gpl,ngg_st reamout,nggc,rt

I thought I read somewhere that adding sam can enable optimizations that aren't normally picked by auto.