DXVK Is Making Significant Progress In Implementing Direct3D 11 Over Vulkan

[nanonyme]

Right - radeonsi has back ends for both kernel driver options.

You do need to change the X driver if you are using -ati (the radeon X driver) AFAIK - either the amdgpu or modesetting X drivers will work.

Or use Wayland and not worry about the X driver?

[Dukenukemx]

Yes. RadeonSI = OpenGL implementation, and it uses a kernel driver called either RADEON or AMDGPU.

Radv = Vulkan implementation, and it uses a kernel driver but only currently works with AMDGPU.

So by switching to AMDGPU you can use Radv and RadeonSI for both Vulkan and OpenGL. By using the older radeon kernel driver, you don't get any Vulkan support.

Up to this point I've been installing Oibaf or Padoka PPA's thinking I've had Vulkan support. I thought AMDGPU was a totally new driver for newer AMD graphic cards that runs poorly compared to RadeonSi. It wasn't until recently when I tried to get Dolphin to use Vulkan that I realized something was wrong. That's when I read that I need to enable AMDGPU, which I thought means I lose RadeonSi. Hence why I never bothered to try and use it before.

I've been visiting this site for years and my understanding about this has been wrong.

[geearf]

Yes. RadeonSI = OpenGL implementation

Hmmm, I think you're forgetting the other state trackers, like vdpau, nine etc..
radeonsi is much more than just OGL.

[ssorgatem]

Tested it with ESO on my Vega 56 and it runs well... for a couple of minutes, until it freezes the GPU and I'm forced to reboot.

Not sure if that's a problem with DXVK, RADV, or the amdgpu driver. I can't see anything useful in the logs...

[ssorgatem]

And for some reason it won't work at all if launched through (native) Steam.

[STiAT]

Wow, that's amazing. I didn't think they (he) would get along with the implementation that fast.

With both, d3d9 and dx11 running over vulkan one day, the hope grows for less bugs and hopefully even better performance.

Outstanding work.

[VikingGe]

Not sure if that's a problem with DXVK, RADV, or the amdgpu driver.

This is probably an issue with how DXVK currently deals with out-of-bounds access into shader resources (not at all) and unbound shader resources (only very few cases are handled at the moment). Fixing this is easy on paper, but in practice it is a tedious process that will take time.

Vega also seems to be a bit more sensitive than Polaris, so if a game triggers a case that isn't handled properly yet, Vega may freeze whereas Polaris (and older GPUs) just keep running, potentially even without logging a VM fault.

[oiaohm]

Yes, but it took them years to make their d3d11 -> GL wrapper

But d3d11 to GL is round peg square hole.

https://www.gamingonlinux.com/articles/opengl-multi-threading-what-it-is-and-what-it-means.9092

Opengl has a lot of places where the documentation suggests it will multi thread perfectly fine then you try it on real world drivers and all hell breaks lose and it fails.

You are talking massively lower complexity implementing any of the direct x since direct x 8 on vulkan compared to opengl. Vulkan gives you properly working multi threading with less major issues. There was reason why a lot of game developers started using direct x over opengl and that opengl backend on some games on windows was half the speed of their direct x back ends and it was not all bad back end code by game developer some of it was opengl itself..

Most vulkan had to wait until the end of 2017 due to the fact that drivers were all over the shop for vulkan.

9 years ago the only hardware accelerated option that worked on all video cards was opengl. So it was a requirement to make a DX to opengl wrapper no matter how bad/horrible it was. How fast DX to Vulkan is being made does show how bad opengl is to work with.

[ssorgatem]

This is probably an issue with how DXVK currently deals with out-of-bounds access into shader resources (not at all) and unbound shader resources (only very few cases are handled at the moment). Fixing this is easy on paper, but in practice it is a tedious process that will take time.

Vega also seems to be a bit more sensitive than Polaris, so if a game triggers a case that isn't handled properly yet, Vega may freeze whereas Polaris (and older GPUs) just keep running, potentially even without logging a VM fault.

Interesting, thanks.

I'll give it a try with amdvlk anyway, to see if there's some luck there...

[ssorgatem]

Well, I tried ESO on dxvk on amdvlk.
It starts, both the GPU and CPU usage seem lower than with RADV... but it crashes before it can actually render any 3D model with a 'dxvk:xvkError'.

Well, let's see in a couple month from now!