Diablo II: Resurrected graphic artefacts on NVidia-495.44 drivers
rinaldus opened this issue · comments
I noticed graphic artefacts in Diablo II Resurrected in 2nd act. They appear only with NVidia drivers version 495.44. I rolled back to 470.86, there are no any artefacts. I switched back to new version, they appeared again. I recorded a small video with these artefacts to make you understand what I mean. They appears on 28th second.
Is possible to fix this bug? I'll roll back to 470xx drivers and wait for fix.
Without any logs or possibly apitrace (not sure it would run on d3d12 and this game?), it is somewhat hard to pinpoint the problem.
I think the minimum requirements for getting anyone (devs) to look at this, would be some logs...
Generally speaking in the case of weird bugs (on nVidia) i think it is adviced to use the latest "vulkan beta" driver branch from nVidia. Currently 470.62.13 from here: https://developer.nvidia.com/vulkan-driver aswell as the latest GIT of vkd3d.
or possibly apitrace (not sure it would run on d3d12 and this game?)
Unfortunately apitrace is too broken with Diablo 2 to be useful.
The newer Vulkan driver branch dev driver doesn't have this issue, so hopefully it's just a temporary driver regression in the stable driver.
Looks like DLSS can be used as a workaround.
If this is the bug I am thinking it is, it is most likely a Nvidia driver bug (or a game bug triggered by certain driver versions) as it also happens on Windows: https://us.forums.blizzard.com/en/d2r/t/graphical-bugs-in-a2-and-a5/7635
I have same issue with nvidia 495.44
ACT 2 - Dry Hills
ACT 4 - River of Flame (the best glitches are there)
ACT 5 - Halls of Pain (also the best glitches
Here is some:
)
There went that hope: Still broken with 510.39.01 driver.
Glad to know it's not just me. Are the new vulkan drivers part of the 510 branch? If so, then that's most unfortunate.
Glad to know it's not just me. Are the new vulkan drivers part of the 510 branch? If so, then that's most unfortunate.
Does not look like it is. Linux Vulkan beta still at 470 branch it seems as of yesterday... Well, i have not checked to see what vulkan extensions is included in the 510 branch, so it may be that it is "mostly implemented", but would think 510 is not "fully conformant vulkan 1.3". Kind of confusing with the various branches to me
January 25th, 2022 - Windows 473.11, Linux 470.62.22
New: Fully conformant Vulkan 1.3 implementation Includes full support for Roadmap 2022 VK_KHR_global_priority
Somewhat readable changelog put together on the Phoronix forums: PhoroniX
Welp updated to today's 511.65 driver release and vulkaninfo shows this:
Vulkan Instance Version: 1.3.201
I think it's safe to say the real cause of this problem is in their own driver branch change from 470 to 490+. Once we see the Vulkan branch get rebuilt against these new Nvidia driver branches, I bet we'll see the same issues with no other course of action besides staying on old drivers.
@DaRkL3AD3R You mean 510.47.03? (As the 511.65 driver is a windows version). Probably same "branch" when it comes to vulkan anyway tho.
I am on Windows myself, where the same issue presents itself.
Scratch all that, still bugged on latest drivers just took a lot to bring it out of hiding.
Can confirm this happening on nVidia GTX 960, driver 510.60.02.
Frequency of occurrence description in this post is accurate for me too: #940 (comment)
Updated to Vulkan Beta drivers 516.48. Still happening. Really stinks.
yeah i have found this same graphics glitch in both linux mint 20.2 and slackware 15.
mint is using nvidia 510.73.03 .
oddly enough legacy graphics works ok though.
nvidia 515.65.01
nvidia 1050ti
latest git vkd3d
It's happening, in some areas.
i have also found that nvidia 470.74 and vulkan-sdk-1.2.176.1 does not have these artifacts.
this is on slackware 15 64 bit multilib.
seems D2R / driver related https://us.forums.blizzard.com/en/d2r/t/black-box-texturesanimations-in-some-acts/6457/23 happends for windows users aswell.
@gulafaran i looked at the said mentioned post and was wondering if the problem was card firmware that gets loaded
when windows boots up, some sort of dynamic power scaling problem or maybe a combination of the two. Honestly
i enjoyed the game remake but having a graphics layer operating on top of the old game smacks of a cheap
corporate "please everyone at once" move and we all know you can only please some of the people some of the time.
I think it would have been a better move to just make an updated version without the old game running under it.
Seems unstable and complicated and a bit rushed and what do you expect me to think when it is unstable even in
windows ? Honestly maybe it would be better just to drop the legacy graphics layer if it would stabilize it. I only hope
some one who can do something about this sees this whole thread. Oh and i don't blame nvidia here for the most part after all their drivers work well else where well enough. Also i had less problem running the path of diablo
mod graphics so maybe that would have been a better solution, just saying ...
FYI - using DLSS appears to mitigate this issue, for those who can utilize it.
How do you even get DLSS to work with VKD3D? As soon as I switch to it, the option to use DLSS disappears.
um i did a bit of searching and it seems a bit more complicated then just "using DLSS"
for example i found this link:
https://www.reddit.com/r/linux_gaming/comments/tk2ik4/is_dlss_possible_in_wine_staging_not_proton/
and from that one:
https://github.com/jp7677/dxvk-nvapi
soo it does not seem quite as simple as just that. Yes i shall look a little closer into this and report back
but yes this is going to require a little more work and also there is no doubt more skulduggery and we shall
have to try to work around it yet again (are you surprised hmm ?)
ok i managed to get it working using the above links. dlss will show up in d2 res video options and you will then be able to enable it. I don't know how stable it will be or for how long it will work (i used proton experimental which gets
updated a lot). And you may have to repatch the dlls when it updates. you will probably need this:
https://github.com/Saancreed/wine-nvml
and this:
https://github.com/jp7677/dxvk-nvapi
and may or may not have to compile wine-nvml depending on the version of your glibc (mine necessitated compilation). Also adjust your sharpness in the video options as well. your mileage may vary depending on your distro (mine is slackware 15) Yeah and if you didn't guess i used steam proton to run it and not plain wine although it is probably quite possible using wine. Still looks like a win and i am sure eventually dlss will be better implemented
in the future without such convoluted workarounds (are you listening nvidia and blizzard?)
Afaik you do not need wine-nvml for using dlss.
perhaps that is how some may do it and it may work well enough but based on the recommendations of the dxvk-nvapi link above
and i quote: " When available, DXVK-NVAPI uses NVIDIA's NVML management library to query temperature, utilization and others for NVIDIA GPUs. See wine-nvml how to add NVML support to Wine/Proton." so that is how i did it. Now if you have a better idea that is simpler and quicker and perhaps safer by all means please share that with us.
https://github.com/jp7677/dxvk-nvapi#proton
All i meant was that you do not NEED wine-nvml to use nvapi for dlss.. it is more of a "addon" to get further nvapi functions. Some benchmarks (eg. Unigine Valley++) show GPU temperature and stuff, and to get that you need wine-nvml.
I am using a normal wine prefix, not proton (not recommended to use proton for non-steam games for many reasons)
DLSS is possible as long as all the necessary components are where they need to be:
in this case, you need dxvk installed alongside vkd3d-proton to use dxvk's dxgi rather than WINE's. Then ensure nvapi is present in the corresponding system32 and syswow64 directories of the prefix, don't forget to set the override. Then, copy nvngx.dll and _nvngx.dll to the system32 directory from /usr/lib/nvidia/wine.
Per the NVAPI readme:
Wine
Wine does not includes DXVK-NVAPI.
Copy nvapi.dll/nvapi64.dll into the syswow64/system32 folder of your x86/x64 Wine prefix.
Ensure that Wine uses the native version of nvapi/nvapi64, e.g. with WINEDLLOVERRIDES=nvapi,nvapi64=n.
Ensure that DXVK is installed in your x86/x64 Wine prefix.
Ensure that Wine uses DXVK's dxgi.dll, e.g. with WINEDLLOVERRIDES=dxgi=n.
Set DXVK_ENABLE_NVAPI=1 to disable DXVK's nvapiHack in DXVK.
DXVK 1.10 and older does not support DXVK_ENABLE_NVAPI. Disable the nvapiHack in DXVK 1.10 and older with dxgi.nvapiHack = False set in a DXVK configuration file, see dxvk.conf.
all of this said, I don't know if this is an issue within scope for VKD3D-Proton since it definitely seems like an Nvidia driver problem to me. DLSS appears to mitigate the issue on my end without any noticable loss in sharpness. You can achieve a similar result by just lowering the rendered resolution setting but that of course results in a pretty blurry image.
well thanks for the heads up for a wine howto @vide0hanz. It can be a little frustrating not having a more standardized
howto some times although a bit unclear when it comes to why proton can be a "problem". Also i have a /usr/lib/nvidia directory but no /usr/lib/nvidia/wine, all i get is:
bash-5.1$ ls /usr/lib/nvidia/
32 egl_dummy_vendor.json glvnd_check libGLX_installcheck.so.0
so you see my setup is not quite the same as yours and yes with slackware 15 64 bit multilib i have nvidia drivers
installation support with sbopkg. Also i get my dxvk from:
https://github.com/jp7677/dxvk-nvapi as i said above so i don't know how you are getting them yourself although
your method may very well work with said source and my libraries are: nvapi64.dll/nvapi.dll not "nvngx.dll and _nvngx.dll". So perhaps a little more clarification and we can get this cleared up a little better.
Also looking into vkd3d-proton as well, i get that i didn't use it in my setup
@10ked The nvngx DLL files are packaged with the nvidia driver, at least according to this chapter of the Nvidia driver docs. I'm not sure how slackware does things. Its possible they do not include these files, or they could be placed elsewhere. For example, on Arch Linux, they are specifically packaged with the nvidia-utils package, which is a dependency of the nvidia package.
Proton tries to include them in its prefixes already by copying them to the prefix automatically, so you definitely have them otherwise DLSS wouldn't work at all. As far as I know, current versions of proton also include dxvk, dxvk_nvapi, and vkd3d-proton. The version of Proton you're using will determine which version/build of the aforementioned libraries you're working with.
Since you mentioned using Proton for this game, there's some things you should know. When you use Proton outside of Steam, you're really just using the build of Wine that it points to. The bulk of what makes Proton are the Steam specific game fixes and client integration. As for adding non-steam games to the client and running via proton, the same thing happens - proton just points the game to a generic fallback prefix that isn't tied to a specific AppID which Proton uses to create separate prefixes for separate games (as intended).
My understanding is that there is no real benefit to running non-steam games with Proton, or using proton outside of Steam. While it may work (and most of the time does), it is not the correct way of doing things. You're just using a build of wine that has a lot of Steam client integration baggage that is effectively useless.
All of this is based on my understanding, which admittedly may be inaccurate in places. Hoping someone comes along to clarify if this is the case.
TLDR: Use Proton for Steam games, and nothing else.
I believe proton has other advantages as well that wine does not have and it is not "baggage that is effectively useless" valve put a bit of work into it and i am using proton experimental which has an advantage of being updated
regularly but also i have to repatch any custom dlls whenever it updates (which i have to because i run dayz with it
which needs custom dlls) so it has its advantages and disadvantages as well ... Still thanks for the explanation, a
bit of clarity always helps when people use linux especially when some one is new to it. Also good to see that DLSS
pretty much seems to have solved the graphics glitches. Now if anyone needs to know how they can do this.
yeah it's funny i see libnvidia-ngx.* in the 64 bit directory (i have both 32 and 64 bit multilib setup) but no 32 bit library for it, nvidia-ngx-updater is also there but no /usr/lib/nvidia/wine/nvngx.dll type libraries. Maybe i should bring this up at linuxquestions and see what shakes loose. So even if i wanted to at this point i could not use wine with your method until i resolved (safely and effectively) this issue. It seems odd though, no 32 bit libnvidia-ngx.* maybe it isn't a big deal we shall see. Still i am not fully satisfied more work needs to be done to make this more
refined ,easier and more effective but is is a lot better.
I don't think there is a 32-bit version of nvngx.dll. Is there any 32-bit games being made that would use dlss nowadays?
There is a lot more to proton than just steam fixes. If you want to build a customizable version including various patches, you can look at: TKG repo.
If you are looking for a more pre-built package, lutris provides the GE version of wine with proton patches.
Using proton/GE/++ as standalone will not copy or create symlinks to dxvk/vkd3d/nvapi+++. It is scripted when steam creates prefix, as well as when lutris creates prefix, so if you are creating prefix yourself, you must do these overrides/symlinks manually.
Debating various fix and proton/wine versions is completely out of the scope of this thread, so i hope things can stay on topic to the actual bug in question 😄