More Of Valve's RADV Optimizations Around Fast-Linking Reach Mesa 23.1

[nuetzel]

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.

And try with latest code:
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21042>
and
radv: skip compilation when possible with GPL fast-linking
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21068>

[Spike_Spiegel]

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

I am not sure how much difference is in dxvk_HUD vs mangohud but maybe you can give mangohud a try.


Mind you I am not using amd but just sharing some images to show you about mangohud maybe you didn't know about it yet. Also one thing that in my opinion about this game , if your not using reshade then you should. Top image is reshade on second is reshade off. Night and day difference. In this scene it appears a bit more warm than some others but that cane be tweaked to users needs quite simply. Also if your playing on keyboard and mouse the pullup game is better suited for a controller if you use only for this sub-game will make it easier.

[Venemo]

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.

This game doesn't benefit from graphics pipeline libraries at all, so the "gpl" option won't make a difference for you.

[tildearrow]

Typos:

and the efforts carred out by him, Samuel Pitoiset, and other Valve pipe-fitters to ideally avoif shader pre-caching

[Linuxxx]

This game doesn't benefit from graphics pipeline libraries at all, so the "gpl" option won't make a difference for you.

AFAIK, this game (FFVIIR) is an Unreal Engine 4 one, so while the DX12 renderer is default, DX11 can easily be forced via a commandline switch.

BTW, any plans for VKD3D-Proton to be able to take advantage of GPL?

Thanks!

skeevy420

So, which API are you running the game with?

[skeevy420]

This game doesn't benefit from graphics pipeline libraries at all, so the "gpl" option won't make a difference for you.

The ole placebo effect

After a bit of testing on 3c25edfdb74 I found that I could trigger that texture issue anytime I used the chocobo service regardless of what was or wasn't set in RADV_PERFTEST so I think that's just the game itself being poorly optimized and I'm chalking that up to being hypersensitive to things after enabling stuff.

Linuxxx DirectX 12.

[ResponseWriter]

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.

Perhaps it works with legendary, a command line EGS client.

[Laughing1]

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

How did you get HDR?

[Venemo]

BTW, any plans for VKD3D-Proton to be able to take advantage of GPL?

D3D12 only has pipeline state objects, which are basically the same as a Vulkan pipeline. So there isn't anything in there that could really take advantage of Vulkan graphics pipeline libraries.

[skeevy420]

How did you get HDR?

Gamescope from git, Linux 6.2 with Josh's HDR patches, Mesa from git, DXVK 2.1, VKD3D-Proton 2.8, and with FFVII I was using the Lutris Wine-GE-Proton-35 runner with DXVK and VKD3D manually updated. Josh told me about a week ago that Proton Bleeding Edge was necessary, so of course I compiled it from TKG's scripts, but I've never needed it for FFVII from the EGS nor did it help with any of the games I that I was unable to get HDR working. I'm just passing along what the guy behind all this told me and my experiences. For Steam games I think the latest Proton Experimental is good enough since it includes the latest DXVK and VKD3D-Proton.

If you don't feel like compiling your own kernel and are on Arch/CachyOS, CachyOS's current linux-cachyos-rc kernel is Linux 6.2-rc5, contains up-to-date HDR patches, and is what I've been using.

Once you have all those dependencies you have to run a Gamescope session (either from a login manager or manually from another TTY) with both "ENABLE_GAMESCOPE_WSI=1 gamescope --hdr-enabled" as well as set either DXVK_HDR=1 or dxgi.enableHDR = True in dxvk.conf. That was the bare minimum gamescope command for using HDR. From there you'll either have success or a lot of frustration. I'm not joking about frustration. Not a lot is 100% reproducible.

An approximation of the command from the gamescope session script I use is the following:

ENABLE_GAMESCOPE_WSI=1 gamescope -W 3840 -H 2160 -e --default-touch-mode 4 --force-windows-fullscreen --xwayla
nd-count 2 --hdr-enabled -- steam -gamepadui -steamos3 -steampal -steamdeck

I haven't had good results when using the non-deck BPM or even when passing just -gamepadui. After spending an hour or two the other day just trying Steam launch options to see what made Steam+HDR tick, all of them seem necessary for me. I saw a Steam update the other day about depreciating the old BPM so fingers crossed that it helps. I'm using Steam Beta. I was using non-beta until trying out HDR. It seems to have helped.

And since I bought FFVII from Epic (literally two weeks before the Steam announcement ) I used Lutris to configure everything (runner, DXVK, VKD3D, etc) and had it create a shortcut in Steam. From there I use Steam to launch FFVII. I do it that way because for whatever reason FFVII won't detect my PS5 controller correctly unless I run it through Steam. Also, disable all the Epic notifications since they'll prevent FFVII from using HDR.

I modified the launcher script from the gamescope-session-git AUR package to handle all the gamescope flags and variables. The gist of it is to add "export ENABLE_GAMESCOPE_WSI=1" somewhere near the top and "--hdr-enabled " in the middle of the gamescope launch parameters.

On CachyOS I have an issue where compiling Gamescope it didn't pick up some of the new header files from sub-projects that Josh added so I had to tweak the gamescope-git PKGBUILD to omit cloning and initializing vkroots and libdisplay-info (the new sub-projects) and had to install those packages from the AUR to get gamescope to compile. Just a heads up in case you get those issues when compiling it.

There's a lot to digest so feel free to ask away.