vkd3d-proton
vkd3d-proton copied to clipboard
HansKristian-Work
Implement DXR
TODO list:
- [ ] D3D12_RAYTRACING_GEOMETRY_FLAGS
- [ ] Object libraries
- [ ] Static samplers in local RS
- [ ] AddToStateObject
- [ ] ... and the rest
@HansKristian-Work Will this work also extend to allow/enable DLSS for applicable GPUs now driver support is officially available on Linux?
No, DLSS is a separate API that'd need wrapping and it's headers etc are not available publicly.
No, DLSS is a separate API that'd need wrapping and it's headers etc are not available publicly.
@Joshua-Ashton Thanks for clarifying, unfortunately DXR without supporting features like DLSS is of little benefit for most titles due to the general performance overhead (e.g. Battlefield V, Control, Cyberpunk 2077, DIRT 5, Ghostrunner, Metro Exodus, Wolfenstein: Youngblood)
Hopefully AMD have a more "Open" alternative in development.
Hopefully AMD have a more "Open" alternative in development.
AMD mentioned some open API for upscaling that they are developing to be usable on all GPUs. So we'd probably need to wait until that materializes before such features become practically useful. Not sure if it will help for existing games that are already stuck with DLSS.
And if ray tracing doesn't work without upscaling hacks in some title, it likely means it's wasn't meant to be used in real time in the first place there.
No, DLSS is a separate API that'd need wrapping and it's headers etc are not available publicly.
@Joshua-Ashton Thanks for clarifying, unfortunately DXR without supporting features like DLSS is of little benefit for most titles due to the general performance overhead (e.g. Battlefield V, Control, Cyberpunk 2077, DIRT 5, Ghostrunner, Metro Exodus, Wolfenstein: Youngblood)
Hopefully AMD have a more "Open" alternative in development.
I can quite disagree with this. Without any upscaling technologies used I am playing absolutely fine with ray tracing on RTX 3080. Basically, anything higher and including 3070 is capable of playing ray-traced games very well. I get 120-140 fps on Linux in Q2RTX, and have played already all the games using ray tracing on Linux and it does it quite well. So this comment makes absolutely no sense to me.
The case of Control - I get quite decent FPS there as well with ray tracing and even without using DLSS on windows. Only when I switched to 4K I had to switch to using DLSS (upscaling from 1440p) to get better performance, but this is 4K.
Either way, the DLSS and ray tracing are separate things and should be implemented both no matter what.
Without any upscaling technologies used I am playing absolutely fine with ray tracing on RTX 3080.
@vityafx Unfortunately brute-force alone is not a realistic option as most users are not using high-end RTX 3XXX series GPUs for realtime ray tracing:
https://store.steampowered.com/hwsurvey/videocard
Without any upscaling technologies used I am playing absolutely fine with ray tracing on RTX 3080.
@vityafx Unfortunately brute-force alone is not a realistic option as most users are not using high-end RTX 3XXX series GPUs for realtime ray tracing:
https://store.steampowered.com/hwsurvey/videocard
I still don't see a good reason for not implementing the ray tracing translation without dlss.
Friendly reminder that AMD supports DXR as well without supporting Nvidia's DLSS.
We have to start somewhere and relying on one vendor's proprietary upsampling solution that we have absolutely no control over whatsoever isn't going to help anybody.
Friendly reminder that AMD supports DXR as well without supporting Nvidia's DLSS.
We have to start somewhere and relying on one vendor's proprietary upsampling solution that we have absolutely no control over whatsoever isn't going to help anybody.
Hans seems to have already started, so kudos to him. Monitoring the branch 24/7, just in case I see something I can help with.
Also, the upsampling from amd, perhaps, has more chances to be used on linux as amd doesn't have that proprietary mindset as nvidia.
No, DLSS is a separate API that'd need wrapping and it's headers etc are not available publicly.
on this topic maybe NVIDIA's @liam-middlebrook (that is updating Vulkan Wine support) or other from NV Linux team is interested in doing a DLSS Wine wrapper (will also require translating DLSS D3D12 mode calls to DLSS Vulkan mode calls).. anyway I think will possibly be easier to support DLSS >2.0 titles i.e. that require no special training per game and shipping the "weights" of NN in the driver..
No, DLSS is a separate API that'd need wrapping and it's headers etc are not available publicly.
on this topic maybe NVIDIA's @liam-middlebrook (that is updating Vulkan Wine support) or other from NV Linux team is interested in doing a DLSS Wine wrapper (will also require translating DLSS D3D12 mode calls to DLSS Vulkan mode calls).. anyway I think will possibly be easier to support DLSS >2.0 titles i.e. that require no special training per game and shipping the "weights" of NN in the driver..
Sad news, DLSS probably won't ever work in Wine, there are multiple reasons. I have done a lot of work for the past few days for it. I won't share the details as this is not a hundred percent chance that I am correct (still have ideas), but Nvidia really tried hard to make this non-working in wine. Once I will run out of ideas completely or will just stuck or something like that, I will share, but until then, everything I share - nvidia can find it out and "close" even these doors which are deeply hidden.
So, I am more and more looking forward to seeing AMD's solution.
No, DLSS is a separate API that'd need wrapping and it's headers etc are not available publicly.
Probably a dumb question; did somebody try contacting Nvidia and asking them about it? I don't see a reason why they'd need to restrict this particular feature on Linux. Error 43 was at least understandable (product segmentation).
No, DLSS is a separate API that'd need wrapping and it's headers etc are not available publicly.
Probably a dumb question; did somebody try contacting Nvidia and asking them about it? I don't see a reason why they'd need to restrict this particular feature on Linux. Error 43 was at least understandable (product segmentation).
TLDR: vulkan-to-vulkan is not possible at this moment, d3d is still being researched (slowly now).
Well, I did ask two guys a few times, no one has responded to my questions. From the patches of wine-staging I made a conclusion that they have never helped with any questions regarding the nvapi, as the patches were made most likely by reverse engineering rather than with someone's help.
Anyway, the latest findings of mine are most likely to end up with nothing, apparently, the ngx on windows is closely tied to nvapi there, and so it requires some undocumented features of nvapi implemented while the reverse engineering is probably not suitable for wine, hence I may do that for myself, but I will not be able to publish this (yet to confirm that); anyway, it will require months of researching of what exactly is required there. Probably, vulkan-to-vulkan can work as it goes a completely different path even in nvapi, but still, Wolfenstein Youngblood goes also a different path, probably due to using an old(?) and undocumented GfeSDK.dll: apparently, it uses this library to check whether the hardware or system is capable of ngx and doesn't even load the ngx library if the GfeSDK reports it shouldn't. That said, Youngblood doesn't even load the ngx at all on Linux, while other games do. Having more games using dlss and vulkan should help, so far there is only one single game that doesn't even load the corresponding libraries on Linux and it is hardly anyone can do something about it, as it uses a closed and probably an old library which I couldn't find any information about (GfeSDK). I assume Youngblood developers do it wrong then, as they should rely on the nvidia-ngx library to detect the os/hardware capabilities and don't do that on their own. What is also possible to do (though I haven't researched that yet) is mocking the GfeSDK.dll: the API seems to have not too many functions, I've mocked all of them just to see the outcome, but still haven't had any progress there, needs more work on that front. Moreover, I do not think this is the best way to go, as again, games should always load the nvngx library and rely on its behaviour, rather than doing something else to enable DLSS.
D3D translation is still being researched by me, but after I fix one thing in nvapi, there goes another one, so slowly going closer to a finish, but the final result is uncertain, I am not sure that even if I let it work (the ngx library), the DLSS will actually work and not segfault and anything else, as we don't have d3d support on Linux but rather translation layers and the DLSS API changes the d3d objects. Even if vkd3d/dxvk's translation is 100% perfect, I myself am not sure whether it will work fine.
P.S. I do not think this issue is the best one to discuss DLSS and anything else except DXR implementation: these two are completely separate things, moreover, the DLSS and all the corresponding changes are not related to vkd3d/dxvk at all as of now.
VKD3D has DXR support now, I can get it to work with Control no problem by using the following launch command:
PROTON_HIDE_NVIDIA_GPU=0 VKD3D_CONFIG=dxr %command% -dx12
So I went ahead and tried to run WoW using (oversimplified):
WINE_HIDE_NVIDIA_GPU=0 VKD3D_CONFIG=dxr
But World of Warcraft still won't allow me to enable Ray Tracing.
edit: added a log, it shows DXR is enabled but the game says no :(
Ok I answered my own question, WoW uses DXR1.1.
I tried the DXR11 branch and it works!
There are some occasional flickers here and there, but it is a start!
On nVidia 495 series beta driver, works beautifully on the new release 2.5, but to get DX12 loading you have to run
nvidia-modprobe -u -c=0
I wonder what happens on the machines that so-called "have to" run nvidia-modprobe -u -c=0.
All that does is:
- Creates
/dev/nvidia0which everyone already has (checkls /dev/nvidia*) - Sets it up with "UNIFIED MEMORY" model which is only related to CUDA library (not games).
I literally cannot figure out why this tip to run that useless command keeps cropping up on forums. Perhaps some distro has a broken nvidia driver that doesn't create the device automatically, that is my only guess.
Edit: Out of interest, I am on Fedora 35 with NVIDIA 495.46 beta. No, I don't have to run the command.
I wonder what happens on the machines that so-called "have to" run
nvidia-modprobe -u -c=0.All that does is:
- Creates
/dev/nvidia0which everyone already has (checkls /dev/nvidia*)- Sets it up with "UNIFIED MEMORY" model which is only related to CUDA library (not games).
I literally cannot figure out why this tip to run that useless command keeps cropping up on forums. Perhaps some distro has a broken nvidia driver that doesn't create the device automatically, that is my only guess.
Edit: Out of interest, I am on Fedora 35 with NVIDIA 495.46 beta. No, I don't have to run the command.
I'm not entirely sure why this happens, but I've had to run this command whenever I installed the vulkan beta driver manually.
There currently seems to be something wonky going on with the Wrath of the Lich King and DXR, when I turn on DXR the game slows to a crawl even on a 3080!
edit: running the command makes VKD3D work by the way, I'm not sure why but if there is no character device in /dev DX12 games will not run for me.
Today I tried CyberPunk 2077 with DXR and it flatlines:
vkd3d.txt edit: I checked with and without DXR enabled the difference in logs is: xxxx:warn:vkd3d_allocate_device_memory: Memory allocation failed, falling back to system memory.
DLSS works fine.
@sfjuocekr What GPU are you using? The master build of vkd3d-proton works for me with a RTX 3080 using version 1.5.2 of CP2077.
@sfjuocekr What GPU are you using? The master build of vkd3d-proton works for me with a RTX 3080 using version 1.5.2 of CP2077.
I have a 3080 as well.
I have 1.6 CP2077 working with DXR. You just need to build vkd3d-proton with the latest code.
I wonder what happens on the machines that so-called "have to" run
nvidia-modprobe -u -c=0.All that does is:
* Creates `/dev/nvidia0` which everyone already has (check `ls /dev/nvidia*`) * Sets it up with "UNIFIED MEMORY" model which is only related to CUDA library (not games).I literally cannot figure out why this tip to run that useless command keeps cropping up on forums. Perhaps some distro has a broken nvidia driver that doesn't create the device automatically, that is my only guess.
Edit: Out of interest, I am on Fedora 35 with NVIDIA 495.46 beta. No, I don't have to run the command.
On the new nVidia 520.56.06 drivers, that command no longer needs to be run. Several distros actually had that as a udev rule, while others explicitly loaded nvidia-ivm.ko to get around this issue we've seen. Per the new 520 release notes, this issue was resolved by:
Updated the Vulkan driver so that the following extensions no longer depend on nvidia-uvm.ko being loaded at runtime:
VK_KHR_acceleration_structure VK_KHR_deferred_host_operations VK_KHR_ray_query VK_KHR_ray_tracing_pipeline VK_NV_cuda_kernel_launch VK_NV_ray_tracing VK_NV_ray_tracing_motion_blur VK_NVX_binary_import VK_NVX_image_view_handle
With the recent changes (version 2.7?) it seems that the RT shadows used in World of Warcraft can now be enabled. They seem to be working as there are slight differences in the shadows between the settings. These examples are from the Classic version of the game but the settings can also be enabled in the retail Dragonflight version.
Disabled:
Good:
High:
