I will try this, but I thought it was just a proposal - I will check if this has been already implemented.
You can use gamescope for such benching purposes.
gamescope -W monitorvalue -H monitorvalue -w valueyouwannalieas -h valueyouwannalieas -r yourrefreshrate -f --
1 Like
Actually, latest Patch 8 along with the Nvidia 575 beta drivers seems to have resolved the Vulkan renderer frame pacing issues. It is buttery smooth now. Not sure if it was the game patch or the beta drivers that resolved it. Still have to specify __GL_13ebad=0x1 %command% though.
Nvidia said they’re looking into it. The VKD3D devs have said that the issue is entirely out of their hands, so its up to Nvidia to profile whatever code path VKd3d-proton is taking on their gpus.
Both AMD and Nvidia are able to get DXVK performance overhead to around 1-3% as compared to native DX11 under Windows.
Unless there’s some sort of fundamental architecture issue, or Hans-Kristian Arntzen is lying, which I highly doubt, this issue has to lie somewhere in Nvidia’s part of the stack
Yes, correct that is the info which is generally known:
“The NV descriptor copy path goes through more indirections, since they dont get the true heap. It is significantly slower then the AMD path. The Create*View() or whatever is slower on NV yes through vkd3d-proton.”
4 Likes
Nvidia got all the tools at hand, they got the driver source code and vkd3d-proton is open source. I really don’t see the problem, just fix it and make everyone happy.
I waited 2 years for a fix.
/Ex-Nvidia GPU owner
5 Likes
Excuse me as I’m not a great programmer at all, but its hard to say with the way this is phrased, whether this means chunks of vkd3dp or nvidia’s driver need rewriting, or if this turns into another EGL vs GBM situation where your average user is just stuck waiting for years.
If it is an issue of the structure of vkd3d-proton interfacing so badly with Nvidia’s driver, then Nvidia needs to put funding aside so that they can provide the vkd3d-proton team as much documentation, profiling, and extension support necessary.
The vkd3dp devs legitimately have their hands tied since they don’t have source access, so anything where it seems like Nvidia is just throwing up its hands and pretending its driver structure is immutable is just passing the buck by the company with the 3rd highest market value on earth.
AMD has a machine learning powered upscaler now which will soon get linux support. AMD is still behind Nvidia in RT performance overall but considering that this issue overlaps with RT games so much, it’s not like I get to see the fruits of buying green over red in Linux anyways. If you’re not doing professional CUDA work or generating terrible art, whats the point in buying Nvidia?
I despise telling people to have to replace their GPU if they want to get away from Windows, but its approaching that.
1 Like
It’s hard to feel much consumer loyalty to a company when I can go look at Valve and AMD’s programmers fighting and bickering to make my stuff work better, where problems have usable workarounds. Meanwhile it takes 6 months of no-contact to get the vk_khr_present_wait issue acknowledged, and a few more for a fix to actually end up in a proper beta driver release.
Meanwhile we all have to watch Nvidia’s CEO walk around in his stupid jacket either play politics or brag about how many people are gonna lose their jobs due to his company.
2 Likes