https://bugs.winehq.org/show_bug.cgi?id=57326
Bug ID: 57326 Summary: WebGPU running slow. Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: mattias.eliasson@medsa.se Distribution: ---
Currently running any WebGPU implementation inside Wine will use Wine's DirectX or OpenGL emulation layer (or possibly Apples DirectX emulation layer).
This has become extra important for Mac support as they dropped OpenGL and all developers that relied on Wines OpenGL support finds themselves in trouble. Even with growing support of Metal in Wine this now requres an emulation layer like moltenvk. Not only is MoltenVK slower due to emulation but it it is a radically different API to OpenGL.
As a result developers that target Mac have started looking at OpenGPU. It's not an emulation layer so when compiling osx application's it provides almost as good performance as using Metal direct but doesn't require having a Mac specific backend. OpenGPU will also run very well on top of OpenGL, Vulkan and DirectX making it ideal for anyone that wants a single GPU backend.
The fast way to run any application with WebGPU dependencies would be for Wine to use a native WebGPU implementation and provide an abstraction layer for Windows WebGPU applications. On Mac OSX that would mean that WebGPU would directly access Metal and run much faster.
The wgpu implementation of WebGPU works very well on Metal and on all other target platforms that wine has. Porting OpenGL code to WebGPU is also much more straight forward than porting to DirectX or Vulcan for those that want an easy way to support OSX with their Windows application.
With native OpenGPU support in Wine we can finally start making "compile once run everywhere" applications that will run well wherever either Windows or Wine is present. At least for developers that support wine as a target platform it would be extremely welcome.
https://bugs.winehq.org/show_bug.cgi?id=57326
Mattias Eliasson mattias.eliasson@medsa.se changed:
What |Removed |Added ---------------------------------------------------------------------------- OS|Linux |MacOS
https://bugs.winehq.org/show_bug.cgi?id=57326
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #1 from Zeb Figura z.figura12@gmail.com --- That's great context, but can you please give a concrete and specific test case that we can look at and optimize?
https://bugs.winehq.org/show_bug.cgi?id=57326
--- Comment #2 from Mattias Eliasson mattias.eliasson@medsa.se --- The experiments that I have done so far is with proprietary code so I will have to make/find some examples that I can share. So the short answer is yes but don't expect it in less than a week from now.
I'll be back with something more concrete.
It also occured to me that it may be fruitful to make something more abstract like a portable scene graph that allows for more flexibility in backend implementation. Given that WebGPU is eventually going to be replaced with something new, it would be nice to not need a WebGPU emulation layer for legacy applications. Although the problem with this approach is that it's difficult to abstract away access to low levels API:s while not limiting the use cases. The fact that none of the attempts to create a more high level API such as Java3D has succeed makes it a difficult task. I chose WebGPU because it does cover most use cases and is generally considered a suitable replacement for OpenGL and it does that by providing just enough abstraction to not exclude a lot of use cases, leaving further abstraction up to the next layer.
-
WineHQ Bugzilla