Gallium Nine Lands Threaded Context Support, Other Improvements

[leipero]

Wow, that's stupid. Tells a lot that managing a checkbox option to register DLLs in a prefix is already too much of a maintenance burden for them...

I assume Lutris devs did it because they used standalone method, and it gets broken often enough, it got broken again now as well.

wine ninewinecfg.exe
002c:fixme:winediag:LdrInitializeThunk wine-staging 6.14 is a testing version containing experimental patches.
002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org.
Application could not be started, or no application associated with the specified file.
ShellExecuteEx failed: File not found.

I assume script got broken as well. For GUI however, running "wine /usr/lib32/wine/fakedlls/ninewinecfg.exe" (or equvalent for prefix) would still work, spew a few errors, but work.

On the topic, great news, I did found a few cases where DXVK have advantage over nine, but in most cases nine is still better with far less overhead.

[Quackdoc]

this one is useful unlike zink. now proton should support it out of the box

Id say zink is fairly useful, We are already reaching a point where mobile hardware will work with zink but not native desktop OpenGL. and as mobile hardware gets better and better it will become more worthwhile. it also helps inept develooers get a good implementation. not to mention it could potentially be a backend native for DX10/11 already works with DX9 via G9.

zink has a lot of potential. not only for opengl but also retro APIs assuming you can implement in gallium (I would love to see 3dfx's glide for instance) and as I said native DX11 and below.

Note that a dx11 zink would work different to dxvk. as dxvk replaces d3d libraries and dxgi. where as zink can do that but also could be treated as a UMD driver allowing direct translation of d3d > vulkan at a driver level on windows, allowing windows to run in a VM with fast paravirt graphics. and this is just a single usecase.

I can think of a few more. but zink is far from useless.

[pal666]

Id say zink is fairly useful, We are already reaching a point where mobile hardware will work with zink but not native desktop OpenGL.

ok, zink is theoretically useful for mobile hardware, subj is practically useful for any hardware

Note that a dx11 zink would work different to dxvk. as dxvk replaces d3d libraries and dxgi. where as zink can do that but also could be treated as a UMD driver allowing direct translation of d3d > vulkan at a driver level on windows, allowing windows to run in a VM with fast paravirt graphics. and this is just a single usecase.

no, the only differences vs dxvk would be
1) you have to write dx11 gallium frontend first
2) it will have overhead of extra translation to gallium before vulkan

[Quackdoc]

no, the only differences vs dxvk would be
1) you have to write dx11 gallium frontend first
2) it will have overhead of extra translation to gallium before vulkan

Not true. DXVK is not a 1 to 1 translation of dxgi and d3d implementation. and anything that directly calls the private APIs in those are incompatible with dxvk. In therory this can be fixed, but the guys at dxvk explicitly stated that those functionality won't be supported.

Zink (Or any gallium backend) would not have this issue as it can be at the umd level

converting to gallium isn't much if an issue. it is usually minor ammount of overhead.

of course you could use dxvk for individual apps. but it won't work on a system wide level without that work being done.

note there is already a d3d10umd driver (though it only supports LLVM pipe at the moment) and that may very well be enough to get accelerated 3d. then run dxvk for everything else. But even then that would require zink to get an acceptable level performance for this specific use case.

and obviously for opengl support in the guest too as virglrenders ogl is slow as molasse. zink will also be helpful in linux guests for the same reason.

[kylew77]

Damn I wish Wine worked on OpenBSD. The perfect OS just doesn't support very many games. I have a FreeBSD install that supports Wine and a Windows 10 install I got in college being in the IT department because heaven forbid I pay Microsoft a dime. Just wishful thinking that OpenBSD would be the most mainstream secure OS and great for games.

[lorn10]

Not true. DXVK is not a 1 to 1 translation of dxgi and d3d implementation. and anything that directly calls the private APIs in those are incompatible with dxvk. In theory this can be fixed, but the guys at dxvk explicitly stated that those functionality won't be supported.

Zink (Or any gallium backend) would not have this issue as it can be at the umd level

converting to gallium isn't much if an issue. it is usually minor amount of overhead.
...

Thanks for this very interesting technical insight. So it looks that DXVK is not always an absolutely complete D3D replacement. In some regards this would then justify a modern DX10/11 Gallium implementation. But this time please in C and not C++, and most likely also on top of NIR instead of TGSI. A suitable name would be Gallium 11. And maybe the code of the failed "D3D1X Gallium State Tracker" can be reused in certain parts:

https://chromium.googlesource.com/chromium/deps/mesa/+/refs/heads/main/src/gallium/state_trackers/d3d1x

Don't worry folks, it can't be that difficult, - this has been done before by just one def guy.

[s_j_newbury]

this one is useful unlike zink. now proton should support it out of the box

FWIW, my Proton fork (see link) does support gallium-nine out of the box if it is installed on the system. It defaults to gallium-nine with an environment variable to disable it.

[aufkrawall]

FWIW, my Proton fork (see link) does support gallium-nine out of the box if it is installed on the system. It defaults to gallium-nine with an environment variable to disable it.

Does it work with Steam Overlay?
It does when running Windows Steam in Wine prefix with Nine.

[Quackdoc]

Thanks for this very interesting technical insight. So it looks that DXVK is not always an absolutely complete D3D replacement. In some regards this would then justify a modern DX10/11 Gallium implementation. But this time please in C and not C++, and most likely also on top of NIR instead of TGSI. A suitable name would be Gallium 11. And maybe the code of the failed "D3D1X Gallium State Tracker" can be reused in certain parts:

https://chromium.googlesource.com/chromium/deps/mesa/+/refs/heads/main/src/gallium/state_trackers/d3d1x

Don't worry folks, it can't be that difficult, - this has been done before by just one def guy.

That code was largely unmaintained and didn't work very well if I remember right. but yeah, to do it right, you need to implement it as a UMD. DXVK might be able to be implemented as a UMD, but it would probably be better just to make a gallium state tracker. Gallium is really nice for driver development afterall.

[pal666]

Zink (Or any gallium backend) would not have this issue as it can be at the umd level

it cannot as it is. with more development anything can

converting to gallium isn't much if an issue. it is usually minor ammount of overhead.

minor amount is more than nothing