CodeWeavers Is Hiring Another Graphics Developer To Help With Wine D3D / Steam Play

[archsway]

dgVoodoo 2 site is on the malware list. There was a malware issue turn up with it. Being closed means for business usage you cannot have it audited. So dgvoodoo 2 is useless garbage to particular parties.

Then maybe CodeWeavers or Valve could buy it and release the source?

[archsway]

Also if we want to stay light and flexible; one day Wine might integrate some sort of x86 userland emulation to run on ARM devices like Raspberry Pi. If we have needlessly shunned all devices that do not support Vulkan, we will never be able to get our act together to hook it all up and do cool things. We will always be chasing hardware rather than making do with what we have got.

https://github.com/AndreRH/hangover

I'm not sure about how well hangover performs, as I don't have a 64-bit ARM CPU, but there is another project for running Linux x86 on ARM which can run gzip at 25% percent of native speed, and has wrappers for some native libraries so glmark2 can run 98% of native speed:

https://github.com/ptitSeb/box86/tree/dynarec

[oiaohm]

Then maybe CodeWeavers or Valve could buy it and release the source?

dgVoodoo 2 is really the wrong way.

Wined3d is Dx1-11 to opengl.
d9vk is Dx 9 could be expanded to cover dx 8 and 9 to Vulkan
dxvk is dx 10-11 to vulkan.

Of course a project is missing a dx1-7 to vulkan.

Why is dgVoodoo 2 the wrong way being to DX11 means you have to either go though wined3d to opengl or dxvk to vulkan. This means you have extra translation layer so extra source of bugs.

Thing to remember on a raspberry pi 4 the GPU technically is Vulkan compatible but it does not have a vulkan driver. There are many android devices that only have opengl drivers for their GPU.

https://www.collabora.com/news-and-blog/blog/2018/10/31/introducing-zink-opengl-implementation-vulkan/

Also opengl is not going way either we are going to see over time like above zink appear. They are many cad programs and other things that will want opengl for legacy parts. Under OS X this in time is going to be MoltenVK for Vulkan to metal with likes of zink on top for opengl to vulkan. The horrible part is with all these layers will still work out faster than what the OS X opengl implementation was of course not as fast as MoltenGL for opengl on OS X. So opengl support on OS X has come a pay for feature and the pay for version in fact performs where the OS X provided opengl was basically not optimised and performed horribly.

The need for opengl backend for wine direct x will not go away for at least a decade because that is how long until it will take for all new hardware to always be released with vulkan support. None of this opengl only hardware releases like the raspberry pi 4.

So we have 10 years to transition. Even when we see Vulkan only GPUs there will be a software wrapper on top to run opengl programs.

But the big thing we really don't need stuff long term like dgvoodoo 2 that is to dx11 because dx11 is not native to Linux or any of the platforms wine runs on.

Codeweavers or Valve would be better off investing in making a d7vk and expanding d9vk to cover dx8 and buying nglide for its voodoo/glide to vulkan than putting any money in dgVoodoo direction.