dgvoodoo2 is a decent implementation of D3D <=8 on top of D3D11, which apparently works quite nicely on DXVK and seems to work better than wined3d in some games. Sadly it's not open-source.

View this comment - View article - View full comments

It technically still is a translation layer, it just happens to depend on Mesa. But it was mentioned that it could potentially run on Nvidia (and with some work, even on Windows). Benefits should be obvious:

1. Nobody in their right mind would start a new OpenGL implementation without using Mesa.
2. Gallium itself is a modern API that should map reasonably well to Vulkan for the most part, it's somewhat similar to the D3D11 DDI.
(3. It might bring Nine to Nvidia one day. Would require Nine to add NIR support though.)

View this comment - View article - View full comments

Quoting: loggeHaha, now Nvidia gets their parts of being closed-source only! What a day!

Nah, it's not that simple. There are reasons why Nvapi (and AMD's equally closed-source equivalent, AGS) exist, and that is that the public D3D API, unlike OpenGL or Vulkan, can only be extended by Microsoft and doesn't have any sort of vendor extension mechanism. So if hardware vendors want to experiment with new features, their only option is to implement it in their driver-specific libraries.

The actual issue is that certain games and engines, most notably UE4, assume that loading nvapi is guaranteed to succeed on an Nvidia GPU, and try to load the library on a performance-critical code path. This is why you see UE4 games that *should* run at 60 FPS on a given Nvidia card suddenly drop to 10 FPS, while it runs completely fine on AMD and Intel hardware. In case of UE4, you might partially blame Nvidia because they are Epic's tech partner, but ultimately this issue wouldn't exist if developers didn't make poor assumptions and used error handling instead.

Same goes for AGS. Granted, I've only seen one single game so far where AGS is a problem, that being Assassin's Creed Syndicate, but it has the exact same issue. Runs fine on AMD after spoofing an Nvidia GPU.

I've been hesitant to do report Nvidia GPUs as AMD GPUs by default because it skews statistics, but with Proton doing it anyway I might as well pull this change. Still not a fan of it though.

View this comment - View article - View full comments

Quoting: ArticleThankfully though, this situation is actually really quite rare.

Not sure if that statement is really true when you're writing at least one such article every week as of late.

View this comment - View article - View full comments

Quoting: Blauer_HungerI'd really like to see compatibility with vkd3d and implementations of the other D3D versions in wine by using a common dxgi.dll

I'm already working on hacking vkd3d support into dxvk somehow. It's not an ideal solution, but it should work since vkd3d doesn't interact with DXGI all that much.

A "common" dxgi.dll to host all of vkd3d, dxvk, and wined3d is just impossible to achieve. DXGI is not designed to allow that, and there are significant drawbacks: vkd3d doesn't even implement proper device selection, and with the current state of Wine's DXGI, it just can't.

DXVK can be refactored to kind of work with wine's dxgi provided that wine implements a DXVK-compatible swap chain, but we'd lose a number of things (device selection like vkd3d, some game compatibility hacks which cannot be fixed otherwise, probably the HUD, and all that stuff).

At the same time, DXVK can't ever support wined3d because d3d11 and d3d10 are tightly coupled to their respective DXGI implementation.

View this comment - View article - View full comments

Quoting: Sil_el_motNow i only have to wait till this get implemented in Proton

It already is implemented in Proton (just based on a DXVK build that is three days old).

View this comment - View article - View full comments

Witcher 3 should work fine now.

View this comment - View article - View full comments

Why "obsolete"? It works, it's supported natively by the engine, and it appears to be more than good enough for the game. No need to port it to Vulkan.

The API choice will be much more interesting for LIS2 which uses Unreal Engine 4.

View this comment - View article - View full comments

Quoting: Comandante ÑoñardoIs Stream Output the feature that LIS: Before the storm needs for to be rendered properly with Vulkan?

Since it's Unity Engine, yes.

Pretty much everything using Unity should work fine now.

View this comment - View article - View full comments

Running a 396-series driver isn't a bad idea for Feral's ports either, they basically replaced the entire shader compiler. Might give a performance boost here and there.

And for DXVK it's a hard requirement.

View this comment - View article - View full comments