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:

Quoting: ShmerlProgress 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.

Quoting: ShmerlProgress 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.

Quoting: YoRHa-2B

Quoting: ShmerlProgress 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.

Quoting: Shmerlis 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.

Quoting: crt0megaI'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.

Quoting: YoRHa-2BMesa 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

Quoting: RinkutuxThis 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.