Fedora Looks To Make DXVK Their Default Back-End For Direct3D 9/10/11 On Wine

[pal666]

Should be fine. Anyone with a GPU of the last 10 years should be good to go. There will be some exceptions, but then again, its an expception to the much greater as is.

change page talks about using dxvk on supported gpus only

[eydee]

one of configuration choices in lutris is "system"

It's not about wine versions, it's about the literal "enable dxvk" setting.

[geearf]

Seems to be doing effort for the sake of doing effort. Lutris already has this and even configurable. Is there any masochist who uses stock wine on its own for gaming?

I do, and I am pretty sure I am not the only one.

[theriddick]

People who don't know any better, who haven't learned about Lutris, new Linux users, non-Phoronix readers, etc.

I found that some people just don't like GUI based control of their wine containers and prefer to manually type/copy/paste their designed commands in. I only do that for testing purposes if something really confuses me and doesn't work in Lutris (or debugging).

I have yet to find a option to output lutris terminal output to log files so it can be hard to debug even if it has options for it.

[Guest]

Seems to be doing effort for the sake of doing effort. Lutris already has this and even configurable. Is there any masochist who uses stock wine on its own for gaming?

I do, although in Fedora's case, they package Staging by-default. I prefer manual configuration a lot more than trying to use some front-end like PoL and Lutris.

[Auzy]

Honestly, I just use Steam/Photon for my games these days. I use Wine for Apps (which it does an awesome job with).

Since this change is downstream though, it's not a huge deal. Worst comes to worst you could simply grab the upstream builds of Wine probably if you don't like the change, and diversifying code bases is always good.. There's nothing to complain about here, and it will be interesting to see how the change goes.

[Weasel]

Bad idea, while DXVK is amazing for games, it's not entirely correct and cuts corner for performance. Again, because it's made for games, and that's the developer's goal.

You know, not every Direct 3D application is a game, right? You'd be surprised that even basic "2D" productive apps (not even related to video or image processing!) are using D3D under the hood. And then they'll crash in new ways they shouldn't if DXVK is not up to par with wined3d for general application compatibility.

But tbh I don't care because I don't care about Fedora anyway.

[JoshuaAshton]

> Bad idea, while DXVK is amazing for games, it's not entirely correct and cuts corner for performance.

Why do you people say this without knowing anything about the design of DXVK or WineD3D?

The only real blocker for applications is child windows which is a Wine bug and partial presentation which will be solved eventually.

[Black_Fox]

Would it though? It would have to be ported anyway, you couldn't build the code as-is.

Oh but yes, you definitely could (source):

libd3d12.so is compiled from the same source code as d3d12.dll on Windows but for a Linux target.

I'm aware it's DX12 only, but I find the news amazing either way.

[Melcar]

I also prefer to manage my own scripts and prefixes from the CLI rather than use GUI front ends like Lutris. The only one I ever bothered with was q4wine just for simplicity. Most games and applications I run with default wine-staging, with a separate dxvk prefix for certain games (mostly +DX10 ones), since I find dxvk breaks some of my older games and some applications for some reason and never bothered troubleshooting it. Most newer games I have on Steam anyway, with wine mostly for my GOG library of "retro games".