DXVK Developer Working On New "AGS" Experiment For Possible Performance Benefit

[xpue]

Oh look, nv gameworks, but from amd.

[Nille_kungen]

This sounds interesting.
Even if the gains are not to much i do like to see this explored, i welcome every gain possible.
I hope it's not to much extra work.

[skeevy420]

Well, still no luck with Hitman 2 & ags.

Did manage to get my own Proton builds to run games so that's cool.

Even managed to build it with vkd3d support but the process zombies out trying to start it with DX12.

Now I have Proton based on 4.7 staging, DXVK git, with faudio so I'm gonna go play my game and see if it's any better or worse.

[fuzz]

Oh look, nv gameworks, but from amd.

Except it's been open source since it came out...

[skeevy420]

If anyone is curious, building Proton from source using tk-glitch's script earlier managed to fix the grass flickering annoyance I had in Hawke's Bay, there are some lighting improvements, and I didn't get any lag or frameskipping whatsoever. While I didn't need it for Wine builds, mingw was needed to build Proton. After installing that, every Proton build has worked when they didn't before.

Has anyone had any luck with AGS and any games not RE/DMC?

[skeevy420]

What is the point of this? It is much simpler to use latest dxvk with latest wine-staging and the windows steam client. If the store page does not work, install games with:
wine Steam.exe -applaunch AppID.

Proton causes nothing but troubles as we see.

Once I figured out my problem, not having mingw installed, my locally built Proton works better than what Valve provides me, fixed an odd flickering issue I had when sneaking in tall grasses, random frameskips went away, and I think some of the lighting was improved. The only bug I noticed was when looking at a light through two opaque surfaces, the glare from the light would go away and the source would flicker.

As far as Hitman 2 and AGS is concerned. It uses a 5.0 version of AGS and dxvk-ags has 5.1, 5.2, and 5.3. I was getting build errors using the 5.0 headers.

[schmidtbag]

AGS is for windows. The AMD Linux graphics stack will never support mGPU.

Not sure what your point is... DirectX is also "for Windows". The whole point of DXVK is to use this Windows software on Linux. Meanwhile, there is nothing preventing mGPU support on Linux. You can already use multiple GPUs (with or without Mesa) simultaneously, but currently Mesa doesn't have any implementation for rendering on multiple GPUs at the same time. Last I checked, there's nothing preventing this from happening.

So, if AGS is meant to detect what your hardware configuration is and if the DXVK dev knows how to make it work on AMD's open-source drivers, it's reasonable to assume that the game itself will figure out how to utilize the 2nd GPU (where applicable).

[cute2dgirl]

So, if AGS is meant to detect what your hardware configuration is and if the DXVK dev knows how to make it work on AMD's open-source drivers, it's reasonable to assume that the game itself will figure out how to utilize the 2nd GPU (where applicable).

No, that's not how it works. Games don't use multiple GPUs explicitly, what they do is tell the driver that they wish to use Crossfire and let the driver figure pretty much everything out on its own. AGS provides some APIs for that, as well as for creating shared resources and some synchronization stuff.

TL;DR supporting Crossfire would be an enormous effort that just isn't worth it for the three people using multiple GPUs. No, Vulkan's device group support doesn't help here because it's D3D11 which doesn't have any sort of explicit Multi-GPU support at all.

[skeevy420]

No, that's not how it works. Games don't use multiple GPUs explicitly, what they do is tell the driver that they wish to use Crossfire and let the driver figure pretty much everything out on its own. AGS provides some APIs for that, as well as for creating shared resources and some synchronization stuff.

TL;DR supporting Crossfire would be an enormous effort that just isn't worth it for the three people using multiple GPUs. No, Vulkan's device group support doesn't help here because it's D3D11 which doesn't have any sort of explicit Multi-GPU support at all.

That's why I'm hoping that we'll eventually get something similar to DX12's mGPU with Vulkan. mGPU, not crossfire/sli, is part of the DX12 API and we'll technically need that for full DX12 compliance with DXVK/vkd3d.

[schmidtbag]

A fact is that multiple GPUs for gaming is so yesterday and games will not support that.

I don't disagree that multi-GPU gaming setups are a dying breed but that's not a relevant point.
So, if a game with AGS support was programmed to detect and utilize multiple AMD GPUs, then in theory, I don't see why the work done by this DXVK dev couldn't get that to work in Linux. Whether or not you find it necessary is moot.

No, that's not how it works. Games don't use multiple GPUs explicitly, what they do is tell the driver that they wish to use Crossfire and let the driver figure pretty much everything out on its own. AGS provides some APIs for that, as well as for creating shared resources and some synchronization stuff.

TL;DR supporting Crossfire would be an enormous effort that just isn't worth it for the three people using multiple GPUs. No, Vulkan's device group support doesn't help here because it's D3D11 which doesn't have any sort of explicit Multi-GPU support at all.

There seems to be some misinformation on both of our ends:
You're right that for DX11, the driver pretty much has to handle all of the mGPU support. So, the fact that I wasn't really paying much attention to DX11 is a fault on my end. However, you don't seem to be aware that for DX12 and Vulkan, the game itself can actually be capable/responsible for explicitly directing rendering on whatever GPUs are available. I presume this is due to the help of things such as AGS, because otherwise the game might have a hard time figuring out which GPU should do what when using something like AFR.
That being said, there are games out there, such as Ashes of the Singularity, which allow you to mismatch GPUs for combined rendering and actually yields pretty good performance. I bring this up because I think it's pretty safe to assume that AMD and Nvidia (and I guess Intel) haven't programmed their drivers to communicate with each other's hardware (or drivers). This in turn suggests the game itself is in fact explicitly addressing each GPU for rendering.

To my understanding, DX12 and Vulkan games that do support this "mix'n'match" mGPU configuration have to be explicitly coded to do so; as far as I'm aware, DX12 and Vulkan do not support this out-of-the-box, and I'm pretty confident you can't force the drivers to work this way either. So, these are the kinds of games I was referring to where AGS might actually get mGPU setups working in Linux, even though the Mesa drivers don't have support for Crossfire.