Progress is good, but is Nier Automata really using a lot of DX11 features? It doesn't seem to be a demanding game.

Holy Ship!! :-)

Can't wait to try Witcher 3 on it.

EDIT:

Progress is good, but is Nier Automata really using a lot of DX11 features? It doesn't seem to be a demanding game.

These days it seems they'll use DX11 even for 2D games (I'm looking at you "The Mummy: Demastered" ). Hilarious, I used to play such games on the Amiga 600.

Nice! I'd rather have that D3D10/D3D11 Gallium state tracker but DXVK looks really good.

Progress is good, but is Nier Automata really using a lot of DX11 features?

It is relatively simple, and that is one of the main reasons why I focussed on getting that particular game to run first (the other being that I'm a bit of a fanboy when it comes to Nier). It doesn't use tessellation or geometry shaders, no deferred contexts, and in general it does things in a rather efficient way (from a CPU perspective).

On the other hand, it does use fairly complex compute shaders with atomic operations etc., even some niche features like Append/Consume buffers which don't have a direct equivalent in Vulkan or OpenGL. And the most annoying part: It has a whole bunch of really, really nasty bugs and does a few unexpected things as well, such as this issue which is still present in Wine and required a workaround in DXVK. And there seem to be more such cases which still cause minor visual discrepancies in both DXVK and WineD3D, but I'd consider it playable with both.

Progress is good, but is Nier Automata really using a lot of DX11 features?

It is relatively simple, and that is one of the main reasons why I focussed on getting that particular game to run first (the other being that I'm a bit of a fanboy when it comes to Nier). It doesn't use tessellation or geometry shaders, no deferred contexts, and in general it does things in a rather efficient way (from a CPU perspective).

On the other hand, it does use fairly complex compute shaders with atomic operations etc., even some niche features like Append/Consume buffers which don't have a direct equivalent in Vulkan or OpenGL. And the most annoying part: It has a whole bunch of really, really nasty bugs and does a few unexpected things as well, such as this issue which is still present in Wine and required a workaround in DXVK. And there seem to be more such cases which still cause minor visual discrepancies in both DXVK and WineD3D, but I'd consider it playable with both.

Interesting, and thanks for working on this! How do you estimate this effort, is it huge, or not as massive as what Wine developers are doing to implement it on top of OpenGL?

I've tested some games with DXVK 0.21, Wine-Staging 2.21 and Mesa 17.3.3, unfortunately none of them worked:

• Prey (2017) launches, but the screen stays black


• TES5SE launches, but only 2d UI stuff renders. Gonna take a look at this


• Lichdom: Battlemage launches, but crashes in the first intro movie


• Shadow Warrior 2 launches, but GPU hangs after the progress bar reaches 3/4

That doesn't mean I'm not impressed. It's still awesome for a young project like this :)

I'm gonna try Shadow Warrior 2 again after applying this fix.

is it huge, or not as massive as what Wine developers are doing to implement it on top of OpenGL?

It is a lot of work either way, but keep in mind that Wine implements all versions of Direct3D that are even remotely relevant, as well as GDI and DirectDraw. They need to do this for maximum compatibility, whereas this is D3D11 only (maybe D3D10 at some point since it's a strict subset of D3D11) and doesn't interop with anything else.

In general though, the answer is it depends. Most API features are rather straight-forward to implement, some don't have an equivalent in Vulkan but in OpenGL (such as Transform Feedback) and will require some hacks. But the reverse is true as well, especially considering that D3D11 and Vulkan are thread-aware whereas OpenGL still requires everything to be serialized into one thread.

I've tested some games with DXVK 0.21, Wine-Staging 2.21 and Mesa 17.3.3, unfortunately none of them worked:

Mesa 17.3.3 seems to be broken and requires
export RADV_DEBUG=nohiz
That's not to say that any of these games would work, although apparently Skyrim SE did already work at some point - thing is, there is absolutely no way of debugging this unless people actually manage to provide apitraces, but apitrace itself seems to cause a lot more trouble than I had imagined.

Mesa 17.3.3 seems to be broken and requires
export RADV_DEBUG=nohiz
That's not to say that any of these games would work, although apparently Skyrim SE did already work at some point - thing is, there is absolutely no way of debugging this unless people actually manage to provide apitraces, but apitrace itself seems to cause a lot more trouble than I had imagined.

Thanks! I'm gonna try that. Unfortunately I don't have the slightest idea how to provide such an "apitrace". I'm more an user who likes to take part in experiments than an experienced dev/debugger yet I'd like to contribute them.

We'll see. I'm gonna get myself a Github account, dig through some manpages and come back with these apitraces – maybe in February when I've got some more spare time.

This looks amazing, I'm gonna try it really soon !
Random question : What is used to display fps on-screen on the screenshots ? (https://github.com/doitsujin/dxvk/wiki

This looks amazing, I'm gonna try it really soon !
Random question : What is used to display fps on-screen on the screenshots ? (https://github.com/doitsujin/dxvk/wiki

The environment variables section of the readme lists DXVK_HUD=1. Seems like a safe bet.

It doesn't use tessellation or geometry shaders, no deferred contexts, and in general it does things in a rather efficient way (from a CPU perspective).

Can you please ping The Witcher 3 in Wine thread, when you'll think DXVK will be at the stage good for testing TW3 in it already? I'd be glad to run tests and report issues. Tesselation would be one major milestone for it I suppose.

Witcher 3 requires pretty much a complete implementation so I don't see that happen any time soon - will report when it does though.

Any chance of getting this merged on wine/wine-stagin?

Nice! I'd rather have that D3D10/D3D11 Gallium state tracker but DXVK looks really good.

Don't you think that once there is a vulkan based converter that the gallium state tracker is no longer necessary?

Don't you think that once there is a vulkan based converter that the gallium state tracker is no longer necessary?

Nope.

Can somebody explain me, how to use that?
I've downloaded the precompiled version (i'm not into compiling), but there are only 2 folders in the archive (x32 and x64), with 2 dlls in every folder (d3d11.dll and dxgi.dll).
How can i implement them to any wine prefix??

Can somebody explain me, how to use that?
I've downloaded the precompiled version (i'm not into compiling), but there are only 2 folders in the archive (x32 and x64), with 2 dlls in every folder (d3d11.dll and dxgi.dll).
How can i implement them to any wine prefix??

Instructions from the readme:

In order to set up a wine prefix to use DXVK instead of wined3d globally, run:

cd /your/dxvk/directory/bin
WINEPREFIX=/your/wineprefix bash setup_dxvk.sh

The script didn't exist at the time the binaries were released, you can however copy (or symlink) the 32-bit ones to your drive_c/windows/syswow64 and the 64-bit ones to drive_c/windows/system32 (blame Microsoft for naming it like that). That's basically what the script does.

Not every Wine installation is WOW64 by the way. The simplest way is probably to build the DLL, place it in your game binary directory, and add DLL override in Wine settings.

It is a lot of work either way, but keep in mind that Wine implements all versions of Direct3D that are even remotely relevant, as well as GDI and DirectDraw. They need to do this for maximum compatibility, whereas this is D3D11 only (maybe D3D10 at some point since it's a strict subset of D3D11) and doesn't interop with anything else.

Do you know what is the purpose of vkd3d project? From the description it sounds it's focused on D3D12 only, but in this dxvk issue there was some discussion that makes it sound like it's for all versions of D3D. So does it mean there will be duplication of effort?