DXVK Entering Maintenance Mode

I have a feeling Valve with throw another body or two at the project and make Philips life easier.

I think what happened is he got it to working point 6 7 months back and then most work was override fixes for this or that title... and before you know it things start stepping on things. Guess the code has gotten to be a mess and hard for one person to parse through properly.
 
Yeah, I'm pretty sure graphics driver code becomes a similar mess. Lots of exceptions with the possibility of lots of regressions. Hoping someone throws some money and people at the problem.
 
I think the dev just needs a break, he's burnt out. Valve need to implement a system whereby the correct DXVK version is used for the selected game in an attempt to ensure regressions like this don't happen.
 
I think the dev just needs a break, he's burnt out. Valve need to implement a system whereby the correct DXVK version is used for the selected game in an attempt to ensure regressions like this don't happen.

Only problem is that would make an already difficult project that much more complex.
 
Only problem is that would make an already difficult project that much more complex.

Not really.

I also believe that Valve need to pick a distro and stick with it as opposed to trying to maintain compatibility with everything from LTS releases to bleeding edge distro's running bleeding edge kernels/drivers. You can run bleeding edge if you want, but if you experience issues you're on your own.
 
Not really.

I also believe that Valve need to pick a distro and stick with it as opposed to trying to maintain compatibility with everything from LTS releases to bleeding edge distro's running bleeding edge kernels/drivers. You can run bleeding edge if you want, but if you experience issues you're on your own.

Picking a distro changes nothing. Ensuring things work is up to the disto maintainers not Valve. Everyone is already on their own if you break something... Valve doesn't guarantee anything works under Linux anything.

All picking a distro would do would be to force Valve to guarantee things work at all... why do they need to do that. Force Ubuntu to take care of their systems in the same way everyone else does to ensure things work. :) What I'm saying is picking Ubuntu may have made sense out of the gate... but long term if you want the other major Distros to be on board with making gaming work, don't go and give their competition a leg up by doing all their work for them. Why would red hat or suse or any other major listen to anything Valve has to say when they are pushing specific tech from their competition and doing all their "gaming" work for them. Better for Valve to stay neutral and as distro agnostic as possible. If some offshoot distro a Manjaro or a MX is doing something really funky its up to them to make sure it works with the generic Linux build Valve is pushing.

The issue with DXVK maintenance has nothing really to do with anything outside of DXVK. The single sole person working on DXVK is Philip... and it sounds like he is both overworked, and the past number of months not perhaps creating the cleanest code. He is being frustrated by regressions which means he has almost for sure created some spaghetti. That can be fixed but it takes time... and is super unfun, but it is doable. I would imagine 2-3 people on it would take care of it in a few months of work.

They need to get him an extra couple sets of eyes... and they probably need to tear his code back to a point where they know exactly what is going on and then rebuild. I can see why he wouldn't want to take that on himself.
 
Last edited:
Picking a distro changes nothing. Ensuring things work is up to the disto maintainers not Valve. Everyone is already on their own if you break something... Valve doesn't guarantee anything works under Linux anything.

All picking a distro would do would be to force Valve to guarantee things work at all... why do they need to do that. Force Ubuntu to take care of their systems in the same way everyone else does to ensure things work. :) What I'm saying is picking Ubuntu may have made sense out of the gate... but long term if you want the other major Distros to be on board with making gaming work, don't go and give their competition a leg up by doing all their work for them. Why would red hat or suse or any other major listen to anything Valve has to say when they are pushing specific tech from their competition and doing all their "gaming" work for them. Better for Valve to stay neutral and as distro agnostic as possible. If some offshoot distro a Manjaro or a MX is doing something really funky its up to them to make sure it works with the generic Linux build Valve is pushing.

The issue with DXVK maintenance has nothing really to do with anything outside of DXVK. The single sole person working on DXVK is Philip... and it sounds like he is both overworked, and the past number of months not perhaps creating the cleanest code. He is being frustrated by regressions which means he has almost for sure created some spaghetti. That can be fixed but it takes time... and is super unfun, but it is doable. I would imagine 2-3 people on it would take care of it in a few months of work.

They need to get him an extra couple sets of eyes... and they probably need to tear his code back to a point where they know exactly what is going on and then rebuild. I can see why he wouldn't want to take that on himself.

There's no doubt that things are going to break depending on distro used ChadD, it shouldn't be up to the DXVK dev to make sure everything works in perfect harmony under every single distro. Even if the developer of the distro is the one making sure things work, they're still going to communicate with the DXVK dev and request changes upstream that could break other distro's compatibility with the software. Pick a distro, make that the supported distro, if you want to use anything else your on your own.

It already happens regarding native titles, I fail to see why it can't happen regarding DXVK and be effective in removing unnessecary workload and stress in the process.
 
There's no doubt that things are going to break depending on distro used ChadD, it shouldn't be up to the DXVK dev to make sure everything works in perfect harmony under every single distro. Even if the developer of the distro is the one making sure things work, they're still going to communicate with the DXVK dev and request changes upstream that could break other distro's compatibility with the software. Pick a distro, make that the supported distro, if you want to use anything else your on your own.

It already happens regarding native titles, I fail to see why it can't happen regarding DXVK and be effective in removing unnessecary workload and stress in the process.

DXVK is distro independent. There is NOTHING about any distro that has anything at all to do with that project. It converts DirectX closed source calls into Vulkan.

DXVK works under windows if you compile it to do so. I compiles into a two .dll file for heaven sake... your distro matters not. Compile the DXVK versions of d3d11.dll and dxgi.dll and use them under windows if you want. (people have done so... its in general much slower but it does work)

The only place the distro stuff comes into play at all with steam is with frankly their own shitty 32 bit launcher. They coded it aimed at frozen way out of date libraries included with a 5 year old version of Ubuntu. Every major distro has added workarounds to ensure their launcher runs on their distros. It is a non issue anymore.... but it could be again if Valve ever gets around to properly updating its Linux launcher.

Running games comes down to Proton (which is wine with some tweaks) which is again completely distro independent. Wine works on every distro I have ever run... it isn't trying to call 5 year old libraries. Quite the contrary. If anything its the old LTS distros that have issues with newer versions of wine (and proton).... as the wine folks do add actual new feature capabilities from time to time that require newer kernel bits ect.

Locking Steam down to an old Distro was not sustainable once they started using up to date wine code.

Wine and DXVK... neither use many system libraries. The few they do use in general need to be at least somewhat recent. The newest versions of proton for example are not going to run on the old LTS kernel they used to claim as official. I guess I'm saying they always had to abandon Ubuntu (unless canonical was willing to make major changes). Steam of course works fine with Ubuntu as long as your on a current updated version and not some library frozen LTS.
 
DXVK is distro independent. There is NOTHING about any distro that has anything at all to do with that project. It converts DirectX closed source calls into Vulkan.

DXVK works under windows if you compile it to do so. I compiles into a two .dll file for heaven sake... your distro matters not. Compile the DXVK versions of d3d11.dll and dxgi.dll and use them under windows if you want. (people have done so... its in general much slower but it does work)

The only place the distro stuff comes into play at all with steam is with frankly their own shitty 32 bit launcher. They coded it aimed at frozen way out of date libraries included with a 5 year old version of Ubuntu. Every major distro has added workarounds to ensure their launcher runs on their distros. It is a non issue anymore.... but it could be again if Valve ever gets around to properly updating its Linux launcher.

Running games comes down to Proton (which is wine with some tweaks) which is again completely distro independent. Wine works on every distro I have ever run... it isn't trying to call 5 year old libraries. Quite the contrary. If anything its the old LTS distros that have issues with newer versions of wine (and proton).... as the wine folks do add actual new feature capabilities from time to time that require newer kernel bits ect.

Locking Steam down to an old Distro was not sustainable once they started using up to date wine code.

Wine and DXVK... neither use many system libraries. The few they do use in general need to be at least somewhat recent. The newest versions of proton for example are not going to run on the old LTS kernel they used to claim as official. I guess I'm saying they always had to abandon Ubuntu (unless canonical was willing to make major changes). Steam of course works fine with Ubuntu as long as your on a current updated version and not some library frozen LTS.

The problem is drivers, and love or hate Nvidia they use binary blobs and will do so into the vast foreseeable future. When it comes to drivers and bleeding edge distro's/kernels you get problems - It doesn't matter how the driver is compiled, you get problems with bleeding edge kernels.

Even AMD's open source drivers aren't perfect.

You can try to blame the distro, you can try to blame the kernel, you can try to blame Nvidia or any other manufacturer that uses binary blobs - At the end of the day that's the reality of the situation and Valve need to settle on one distro as the supported distro to take the load off the DXVK devs. I never stated the distro should be an LTS release, I simply stated a distro needs to be chosen for it's wide compatibility, suitable package manager, ease of use and distro developer support - Canonical does tend to tick those boxes.

One of the problems with DXVK is bleeding edge features breaking compatibility resulting in the devs rolling back features - Perhaps Valve need to slow down on pumping out the bleeding edge features?
 
One of the other reasons we see a lot of regressions is linked directly to how much "custom code" is put into drivers to make games work (even on Windows). There's a reason you see NV release "game day drivers" for a lot of AAA games. There are tons of individual game or engine based tweaks that have to be worked on. That's probably a bit too much for one person to do.
 
One of the other reasons we see a lot of regressions is linked directly to how much "custom code" is put into drivers to make games work (even on Windows). There's a reason you see NV release "game day drivers" for a lot of AAA games. There are tons of individual game or engine based tweaks that have to be worked on. That's probably a bit too much for one person to do.

Nvidia do this under Linux. I'm not sure whether it's still the case, but there was actually an Nvidia representative at Valve working specifically on Nvidia driver tweaks for Linux games.
 
Does this still work on the latest games like Starfield even though dxvk isn't getting anymore feature updates?
 
Does this still work on the latest games like Starfield even though dxvk isn't getting anymore feature updates?

It is still under active development - I think the dev was subsequently contracted by Valve and development continued

edit: also Starfield is a DX12 game and needs VKD3D, not DXVK.
 
Last edited:
Back
Top