https://bugs.winehq.org/show_bug.cgi?id=40164
Bug ID: 40164 Summary: Add Vulkan support Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: jj@stusta.net Distribution: ---
Vulkan is now released: https://www.khronos.org/vulkan/
Wine may profit from this. The HLSL -> SPIR-V compiler can make it possible to translate direct3d shaders.
I guess implementing that backend can make Wine much faster for 3D graphics. I'm unsure though if the translation interface is too complicated and slow if the application still does the OpenGL/Direct3D calls.
https://bugs.winehq.org/show_bug.cgi?id=40164
Jonas Jelten jj@stusta.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jj@stusta.net
https://bugs.winehq.org/show_bug.cgi?id=40164
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=40164
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com Version|unspecified |1.9.3 Severity|major |enhancement
https://bugs.winehq.org/show_bug.cgi?id=40164
3vi1 winehq.org@eternaldusk.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq.org@eternaldusk.com
https://bugs.winehq.org/show_bug.cgi?id=40164
--- Comment #1 from Bruno Jesus 00cpxxx@gmail.com --- Can you or anyone else elaborate more on this for the 3D illiterate like me? I think it would be useful to describe more precisely what has to be done to avoid turning this into a meta bug.
https://bugs.winehq.org/show_bug.cgi?id=40164
Nguyen Thai Ngoc Duy pclouds@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pclouds@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=40164
mexahotabop@w1l.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mexahotabop@w1l.ru
https://bugs.winehq.org/show_bug.cgi?id=40164
--- Comment #2 from Matteo Bruni matteo.mystral@gmail.com --- This bug as expressed in comment 0 doesn't mean anything specific so your objection is perfectly valid, Bruno.
Given what I know about Vulkan (which is admittedly not much) I can think of two "steps" for "supporting" Vulkan in Wine. The first step would be to make a wrapper DLL to forward Vulkan API calls from Windows applications to the native (e.g. Linux) Vulkan lib, pretty much in the same way as we currently do for opengl32.dll. It's probably not entirely trivial to do but I guess much of the same infrastructure we have for OpenGL can be reused / reworked for Vulkan.
Then we could ideally use Vulkan as another option for translating D3D APIs in addition to OpenGL. This is going to be hard work and I don't see it happening any time soon. I also think this is what the OP meant.
I guess you can update this bug to target either of those two options specifically (or maybe some other kind of "support" we could add). As it is the bug doesn't seem useful.
https://bugs.winehq.org/show_bug.cgi?id=40164
oscarbg rtfss1@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rtfss1@gmail.com
--- Comment #3 from oscarbg rtfss1@gmail.com --- I was going to create a bug for Vulkan support in Wine and found this bug..
I strongly believe that by title it should point to adding support for running Windows programs using Vulkan by a wrapper similar to OpenGL or even OpenCL in Wine and CUDA support in Wine-Staging..
Current shipping content are the Talos principle Beta or a simple Nvidia demo (http://developer.download.nvidia.com/mobile/shield/assets/ThreadedRenderingV...) Nvidia here provides a simple Vulkan demo making advanced usage of Vulkan features so could be a simple target to test that wrapper is working.. more it has 32bit and 64 bit Windows binaries so we could check 2 binaries works currently..
I'am willing to test once patches start appearing!
https://bugs.winehq.org/show_bug.cgi?id=40164
Johannes Brandstätter jbrandst@2ds.eu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jbrandst@2ds.eu
https://bugs.winehq.org/show_bug.cgi?id=40164
Fernando Otero granamachine-wa@yahoo.com.ar changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |granamachine-wa@yahoo.com.a | |r
--- Comment #4 from Fernando Otero granamachine-wa@yahoo.com.ar --- (In reply to Matteo Bruni from comment #2)
Then we could ideally use Vulkan as another option for translating D3D APIs in addition to OpenGL.
Could be possible to actually IMPROVE native performance of DirectX 9/10/11 games, by taking advantage of Vulkan's new features? I assume this would require much more than the mere translation of calls. But, if doable, no doubt it would be revolutionary.
https://bugs.winehq.org/show_bug.cgi?id=40164
Gabríel Arthúr Pétursson gabriel@system.is changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gabriel@system.is
--- Comment #5 from Gabríel Arthúr Pétursson gabriel@system.is --- Translating DirectX 9/10/11 or OpenGL to Vulkan commands is unlikely to bring any performance improvements over existing solutions. OpenGL and DirectX 9/10/11 drivers are already employing highly tuned heuristics and tricks to bring out the best possible performance given the limitations of these APIs.
I'm currently working on implementing Vulkan support, to allow running Vulkan programs under Wine. Hopefully I should have patches available for you all to play with soon.
https://bugs.winehq.org/show_bug.cgi?id=40164
--- Comment #6 from Nguyen Thai Ngoc Duy pclouds@gmail.com --- (In reply to Gabríel Arthúr Pétursson from comment #5)
Translating DirectX 9/10/11 or OpenGL to Vulkan commands is unlikely to bring any performance improvements over existing solutions. OpenGL and DirectX 9/10/11 drivers are already employing highly tuned heuristics and tricks to bring out the best possible performance given the limitations of these APIs.
I'm a complete ignorant. But given that Gallium Nine improves DX9 performance, can we possibly expect the same for Vulkan? G9 only works with open source AMD driver, but Vulkan will be supported by both nvidia and amd proprietary drivers. That's what made me think performance could be better.
https://bugs.winehq.org/show_bug.cgi?id=40164
kaito.linux@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kaito.linux@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=40164
--- Comment #7 from Fernando Otero granamachine-wa@yahoo.com.ar --- (In reply to Gabríel Arthúr Pétursson from comment #5)
Translating DirectX 9/10/11 or OpenGL to Vulkan commands is unlikely to bring any performance improvements over existing solutions.
Translating similar or equivalent commands would make no benefit, because of that, I clarified it would require more work, perhaps converting/adapting some calls to the new Vulkan features. I didn't mention it, but this would be beneficial not only to DX9/10/11 games, also to OpenGL ones.
Vulkan is based on Mantle, and shares the same feature set with DX12 (mainly low level, low CPU overhead). Performance improvements could be noticeable when using multiple cores. Of course, this could only happen when you have native apps for DX12/Vulkan. But for instance, Dolphin (Gamecube/Wii emulator) has already shown up to 60% improvements on AMD multi-core CPUs, only by using a DX12 plugin.
https://bugs.winehq.org/show_bug.cgi?id=40164
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |STAGED CC| |dmitry@baikal.ru, | |erich.e.hoover@wine-staging | |.com, sebastian@fds-team.de Ever confirmed|0 |1 Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/vulkan-Vulkan_ | |Implementation
https://bugs.winehq.org/show_bug.cgi?id=40164
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|directx-d3d |-unknown Summary|Add Vulkan support |Implement vulkan-1.dll to | |provide Vulkan API for | |Windows applications
--- Comment #8 from Sebastian Lackner sebastian@fds-team.de --- As Matteo pointed out, there are basically two different interpretations of this bug report. I would suggest we concentrate on the vulkan-1.dll implementation here, and move all discussions about how to speed up d3d* using Vulkan to a different bug report, to keep those two issues separated.
In Wine Staging 1.9.6 we have added an initial version of a wrapper library to make Vulkan accessible to Windows applications (like The Talos Principle). Feel free to give it a try and report any issues you encounter.
https://bugs.winehq.org/show_bug.cgi?id=40164
Christopher Joseph Dean Schaefer disks86@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |disks86@gmail.com
--- Comment #9 from Christopher Joseph Dean Schaefer disks86@gmail.com --- Personally I think it would be better to have to D3d to Vulkan code separate from the main codebase. As long as Wine can pass calls through to the native vulkan library and translate the WSI extensions it should be sufficient. I've personally been working on wrapper library that implements the D3d9 interfaces using vulkan. Once I have a little more functionality in place I plan to test it under Wine.
https://github.com/disks86/SchaeferGL
https://bugs.winehq.org/show_bug.cgi?id=40164
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wylda@volny.cz
--- Comment #10 from Wylda wylda@volny.cz --- Created attachment 55849 --> https://bugs.winehq.org/attachment.cgi?id=55849 Output of 32bit's vulkaninfo
(In reply to Sebastian Lackner from comment #8)
...Feel free to give it a try and report any issues you encounter.
Hi Sebastian, i tried vkquake-0.71.0_win32.zip under wine-staging-1.9.20. I have nVidia GTX970 v367.44. I'm able to run linux version of Dota 2 (64bit).
The results: ... Vulkan Initialization
ERROR-OUT BEGIN
fixme:imm:NotifyIME NI_CLOSECANDIDATE
QUAKE ERROR: Couldn't find VK_KHR_surface/VK_KHR_win32_surface extensions
https://bugs.winehq.org/show_bug.cgi?id=40164
--- Comment #11 from Michael Müller michael@fds-team.de --- There was a problem in vkEnumerateInstanceExtensionProperties. The patch implements VK_KHR_win32_surface using VK_KHR_xcb_surface and/or VK_KHR_xlib_surface. If both extensions are available on the host system, the wine implementation enumerated the VK_KHR_win32_surface twice. The game didn't like this behavior.
The issue has been fixed in the staging commit 3fe8a52e3c794e1884c212d7585e9844876fe23c. The game should work now, can you retest it?
https://bugs.winehq.org/show_bug.cgi?id=40164
--- Comment #12 from Wylda wylda@volny.cz --- Yes, it works and look awesome :c) Thank you Michael. I noticed some glitch at video setting. When i change resolution or switching to fullscreen mode, vkQuake quits with message like ...Wrong surface size... But that can be issue with vkQuake itself. Latest nVidia drivers also mention some fixes for vkQuakes/DOTA's Vulkan. In upcoming days i will test the native Linux and Win versions to see, if that is Wine-only issue or not.
BTW: If this is a right approach to implement vulkan-1.dll, was is considered/discussed to push it upstream? I guess next stable version of Wine is imminent. Would be nice to have it in one place for the next year ;c)
https://bugs.winehq.org/show_bug.cgi?id=40164
Nathan version2013@openmailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |version2013@openmailbox.org
https://bugs.winehq.org/show_bug.cgi?id=40164
--- Comment #13 from Wylda wylda@volny.cz --- Created attachment 56890 --> https://bugs.winehq.org/attachment.cgi?id=56890 vkQuake 0.94 32bit crashes
There is a new crash log in 32bit and only 32bit version of vkQuake. All the following results are from wine-staging-2.0-rc5:
32 bit vkQuake & wine 32bit only ================================ vkQuake v0.71 ... OK vkQuake v0.72 ... OK vkQuake v0.90 ... crash vkQuake v0.94 ... crash
64 bit vkQuake & wine WoW64 =========================== vkQuake v0.71 ... OK vkQuake v0.72 ... OK vkQuake v0.90 ... OK vkQuake v0.94 ... OK
https://bugs.winehq.org/show_bug.cgi?id=40164
--- Comment #14 from Michael Müller michael@fds-team.de --- (In reply to Wylda from comment #13)
There is a new crash log in 32bit and only 32bit version of vkQuake. All the following results are from wine-staging-2.0-rc5:
Should be fixed in the Wine Staging commit e0e48313dfa3cc42de2eda5df9d0108581027251.
https://bugs.winehq.org/show_bug.cgi?id=40164
--- Comment #15 from Wylda wylda@volny.cz ---
Should be fixed in the Wine Staging commit
Yes, 32bit vkQuake works for me perfectly in wine-2.0-160-g152b240153 (Staging). Thank you.
https://bugs.winehq.org/show_bug.cgi?id=40164
programmerjake@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |programmerjake@gmail.com
--- Comment #16 from programmerjake@gmail.com --- I think it would be better to implement a custom passthrough installable client driver (ICD) instead of a custom vulkan-1.dll, and use the standard vulkan loader instead. This way, you will be able to use other ICDs and vulkan layers. As an example, I'm developing a software-rendered vulkan implementation, and, from what I can tell, I would be able to use it on Windows, but not on this implementation of vulkan for win32. If we switch to using the standard vulkan loader and use a custom ICD, then I'd be able to use my vulkan implementation alongside this one as if wine was an ordinary version of windows.
ICD interface reference:
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master...
https://bugs.winehq.org/show_bug.cgi?id=40164
--- Comment #17 from Christopher Joseph Dean Schaefer disks86@gmail.com --- If we went the route of an ICD how would we handle multiple GPU scenarios where they are different drivers?
https://bugs.winehq.org/show_bug.cgi?id=40164
--- Comment #18 from Gabríel Arthúr Pétursson gabriel@system.is --- (In reply to Christopher Joseph Dean Schaefer from comment #17)
If we went the route of an ICD how would we handle multiple GPU scenarios where they are different drivers?
A single ICD can expose multiple physical devices to the loader. There's little more to it than returning more than one device from a call to vkEnumeratePhysicalDevices.
https://bugs.winehq.org/show_bug.cgi?id=40164
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=40164
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |winevulkan
https://bugs.winehq.org/show_bug.cgi?id=40164
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k@gmail.com Status|STAGED |RESOLVED Resolution|--- |FIXED
--- Comment #19 from Roderick Colenbrander thunderbird2k@gmail.com --- We have a functional Vulkan implementation in Wine as of 3.4. While we haven't exactly implemented vulkan-1, we did it through an ICD. I would say we should consider this fixed as the ticket also went over different design options.
https://bugs.winehq.org/show_bug.cgi?id=40164
--- Comment #20 from Roderick Colenbrander thunderbird2k@gmail.com --- We now have a vulkan-1 dll as well, so we can fully close this now.
https://bugs.winehq.org/show_bug.cgi?id=40164
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |3a6c724e904e4730adc365df03a | |b7a096532ed1e CC| |joseph.kucia@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=40164
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #21 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.5.
-
wine-bugs＠winehq.org