Wine's Direct3D Vulkan Back-End Continues Seeing An Uptick In Activity

[phoronix]

Phoronix: Wine's Direct3D Vulkan Back-End Continues Seeing An Uptick In Activity

Last month we reported on Wine's Direct3D Vulkan back-end seeing new activity as an alternative to the project's mature Direct3D-to-OpenGL path. Over the course of May work on this Vulkan back-end has edged only even higher...

http://www.phoronix.com/scan.php?page=news_item&px=WineD3D-Vulkan-More-For-May

[Templar82]

Seems like a bit of "Not from here" Syndrome, but being open-source hopefully any major improvements in one project can assist the other.

[rmfx]

Can't they rename their stuff with consistency ?

"WineD3D [...] not to be confused with VKD3D for Direct3D"

Why the directx12 wrapper has a different nomenclature than 9/10/11 ?
VKD3D9, VKD3D10, VKD3D11, VKD3D12... was a pretty simple rule to follow yet.

[ix900]

Can't they rename their stuff with consistency ?

"WineD3D [...] not to be confused with VKD3D for Direct3D"

Why the directx12 wrapper has a different nomenclature than 9/10/11 ?
VKD3D9, VKD3D10, VKD3D11, VKD3D12... was a pretty simple rule to follow yet.

At least they didn't name it "Squiggly Wiggly", "idv9000", or "Tesla". They get a 6/10 from me which is not that bad as naming goes.

From now on, we can just call it Steve lol.

[oiaohm]

Can't they rename their stuff with consistency ?

"WineD3D [...] not to be confused with VKD3D for Direct3D"

Why the directx12 wrapper has a different nomenclature than 9/10/11 ?
VKD3D9, VKD3D10, VKD3D11, VKD3D12... was a pretty simple rule to follow yet.

Because vkd3d:
1) Independent project to main wine. https://source.winehq.org/git/vkd3d.git/ from here.
2) is build without any other wine parts so you can use vkd3d in native Linux binaries without any complex wrappers.
3) DX12 is massive different to DX11 and before.

Wined3d
1) is part of the wine source code that is where the wine bit comes from.
2) Dx 1-11 due to the direct X is design does in fact depend large sections of the Windows API and Memory layout. So using Wined3d on anything other than Windows or Wine is not in fact possible. Please note dxvk must also be on wine or windows or not work so the limitation is not a wine unique one but part of how direct x 1-11 was designed.

Wined3d is the bit that provides the driver provided interfaces of dx 1-11 in wine. The libraries that the application interface with inside wine are named the same as windows of course.

[geearf]

Can't they rename their stuff with consistency ?

"WineD3D [...] not to be confused with VKD3D for Direct3D"

Why the directx12 wrapper has a different nomenclature than 9/10/11 ?
VKD3D9, VKD3D10, VKD3D11, VKD3D12... was a pretty simple rule to follow yet.

It is consistent. It is WineD3D because it is part of Wine and deals with D3D.
VKD3D is not part of Wine and like WineD3D does not have a number.

[Vash63]

Please note dxvk must also be on wine or windows or not work so the limitation is not a wine unique one but part of how direct x 1-11 was designed.

Not true. dxvk-native is a thing, though it mostly dropped off due to lack of developer interest.

https://github.com/Joshua-Ashton/dxvk-native

(note that the readme hasn't been updated and is just the standard dxvk readme).

[oiaohm]

Not true. dxvk-native is a thing, though it mostly dropped off due to lack of developer interest.

It was not just developer lack of interest.

https://github.com/ValveSoftware/ToGL

There is a long list attempts by even quite big companies like Valve. Be to opengl or vulkan back end at first it seams straight forwards to take dx8-11 to native Linux then the finer points start kicking you in your ass and you work out sooner or latter you will need to fake the complete windows memory layout. So yes dxvk-native was doomed to failure as soon as the developer started attempt to-do it it was only a matter of time until the problem came crystal clear to them.

The most successful are like the valve one ToGL that end up as a subset particular DX version converted to Linux native. By taking a subset you are able to drop the different bits that depend on Windows memory layout this also reduces how useful it is for porting. Yes you see valve grow out of this idea as well.

Its is very interesting that DX12 design did not really include any windows particular memory layout stuff so its the most portable designed out of the complete DX line.

[Vash63]

It was not just developer lack of interest.

https://github.com/ValveSoftware/ToGL

There is a long list attempts by even quite big companies like Valve. Be to opengl or vulkan back end at first it seams straight forwards to take dx8-11 to native Linux then the finer points start kicking you in your ass and you work out sooner or latter you will need to fake the complete windows memory layout. So yes dxvk-native was doomed to failure as soon as the developer started attempt to-do it it was only a matter of time until the problem came crystal clear to them.

The most successful are like the valve one ToGL that end up as a subset particular DX version converted to Linux native. By taking a subset you are able to drop the different bits that depend on Windows memory layout this also reduces how useful it is for porting. Yes you see valve grow out of this idea as well.

Its is very interesting that DX12 design did not really include any windows particular memory layout stuff so its the most portable designed out of the complete DX line.

You act like this developer didn't know what he was doing... Josh Ashton is the developer of d9vk and thus the d3d9 backend of DXVK itself. I'm not sure you should be questioning whether he knew what he was getting into when he forked his own project to make a native Linux compatible version.

[Weasel]

vkd3d is like FAudio. It implements an API similar to, but not exactly the same as, the Windows "equivalent" (which relies on Windows stuff). To be honest I do wish Wine just statically linked vkd3d somehow. Less pain in the ass dealing with a fucking distro's packages and you'd be sure it was specific to a Wine version when compiling Wine yourself.

Compiling vkd3d is not difficult but it's an extra step, and now imagine if all other stuff had separate libraries. Yikes.