MoltenVK
MoltenVK copied to clipboard
KhronosGroup
Add support for geometry shaders
Since MSL3 still doesn't support geometry shaders, and it seems a requirement (along with tessellation) for modern 3D applications, would it be possible to add this in MoltenVK as a polyfill? I saw this repo that gives an example of geometry shader for MSL https://github.com/Kosalos/GeometryShader
Thanks for submitting the request and recommendation.
Interesting idea.
https://github.com/KhronosGroup/MoltenVK/issues/1657#issuecomment-1193364216 Geometry shaders were introduced in OpenGL 3.2 so support could be hidden somewere in the Metal API? Wishful thinking...
#1657 (comment) Geometry shaders were introduced in OpenGL 3.2 so support could be hidden somewere in the Metal API? Wishful thinking...
Metal 3 has new features which help support Geometry Shaders. https://github.com/KhronosGroup/MoltenVK/discussions/1616#discussion-4126755
Metal 3 has new features which help support Geometry Shaders. #1616 (comment)
I Agree but metal 3 is not there yet, also you want to support users that for some reason want to use older OSs for some time?
more suggestions discussed here: http://hacksoflife.blogspot.com/2015/06/os-x-metal-raw-notes.html
If it's still important providing support for the current os without waiting the future release of metal3 with the next OS: more sugggestions on this repo: https://github.com/openglonmetal/MGL#spirv-to-metal.
There are some parts in GLSL that Metal just doesn't support like Geometry Shaders, I think the way forward on support for Geometry Shaders is to translate the vertex and geometry shaders into LLVM from SPIRV then execute the results from processing them on the CPU through a passthrough vertex shader in the pipeline.
Also: one of the contributors also pointed that another source of inspiration is looking into zink and how it emulates geometry shaders.
Doing it on the CPU is a waste of time. That would be too slow to be usable anyway.
Doing it on the CPU is a waste of time. That would be too slow to be usable anyway.
Agree, but there are many other ways of solving this problem anyway. It's worth trying tho, everything is better than nothing at all.
The functionality doesn’t exist in Metal, so I just jumped directly to Compute Shaders which Metal does support and is to be honest the future path for GPU’s.
Again from that project.
There’s really many games that require geometry shaders but it’s not always so in your face.
One reason it’s not so obvious is DXVK-CX and some third-party builds aimed at macOS have a hard requirement on faking extensions on the MoltenVK side.
Instead doing the following https://github.com/Gcenx/DXVK-macOS/commit/934006899a02571f4a381d9be69b3a5104a2132b makes sure that anything the feature is requested the message will show up in the log.
One reason it’s not so obvious is DXVK-CX and some third-party builds aimed at macOS have a hard requirement on faking extensions on the MoltenVK side.
Can you elaborate on what you mean by that? Specifically, what "hard requirement on faking extensions" means?
Are you saying frameworks like DXVK-CX have two code paths, one when geometry shaders are available in the driver, and one when they are not, and both work (maybe not equally well)? And in the second case, how do these frameworks "fake" geometry shaders?
Or are you saying DXVK-CX will not run when geometry shaders are not available because they have a hard requirement to not fake extensions?
Sorry to interrupt the conversation... Just for taking some inspiration for a solution, there's a patent registered by vmware giving some explanation on how it's implemented with compute: https://uspto.report/patent/app/20200265631. I hope this helps somehow.
Or are you saying DXVK-CX will not run when geometry shaders are not available because they have a hard requirement to not fake extensions?
DXVK-CX and some other third-party packages won’t run unless MoltenVK fakes support for geometry shaders (and some other extensions)
The DXVK-macOS packages I advertise are used in XIV on Mac|Wineskin|PortingKit will use geometry shaders and other extensions if available, if these are missing it will continue to run just give a message (for geometry shaders)
Here’s the current version of DXVK-CX shipped with recent versions of crossover https://media.codeweavers.com/pub/crossover/dxvk/dxvk-v1.7-14-gef993b2f_x86_64.tar.bz2 this won’t run on stock MoltenVK
Here’s my own build of the same version but does function on stock MoltenVK https://github.com/Gcenx/DXVK-macOS/releases/download/v1.7/dxvk-macOS-1.7.tar.gz
Or the very latest version https://github.com/Gcenx/DXVK-macOS/releases/download/v1.10.3/dxvk-macOS-async-1.10.3.tar.gz (async is enabled by default on select titles)
There’s no fallback for these missing Vulkan extensions with my packages I simply allow the games to still function (that’s fine until more recent DXVK-git), prior DXVK releases allowed this I’d simply reverted some changes to still allow it.
In older Unity games (at least 2018), geometry shaders are used for gpu skinning. That causes models to not render at all in Crossover.
Now that Ventura has released today, with Metal 3 support, hopefully this will become a reality. Can't wait to be able to use CrossOver to play my UE4 based games rather than having to rely on a virtual machine! +1 for this and the team working on it! :)
Let me just say that I know almost nothing about any of these. But I was reading the Ryujinx blog update and they mentioned this about geometry shaders:
"Geometry Shaders: Geometry shaders do not exist in Metal or MoltenVK. Used for writing 3D textures in UE4 games, and a number of complex graphical effects in others, missing this would definitely hurt compatibility. However, gdkchan has come up with a clever method to emulate these stages using additional draws to vertex shader only. The result is incredibly impressive - hardware-accelerated geometry shaders on a GPU that doesn't support them. Coup de grâce!"
Since Ryujinx is open source, is this a possible solution to this issue?
The compute shader or mesh shader solution would be much more efficient than the Vertex shader solution, but if the Vertex one is easier to accomplish, always better than nothing at all.
There is some PoC effort currently underway using Mesh shaders to provide Geometry shaders.
We're expecting initial availability to be sometime in Q1/23.
That's really good news! I was somewhat worried that Metal 3's features are not enough to provide a solution for geometry shaders.
Also, with regards to other problems that I've read about, Ryujinx also made workarounds for 4-byte Vertex Buffer Alignment Requirement & Transform Feedback.
Mesh shaders alone may not be enough to handle the case where geometry shaders interacts with transform feedback ...
It's a possibility that either tessellation or geometry shaders implementation over mesh shaders on MoltenVK/Metal may never reach parity in functionality with other graphics APIs out there ...
Further development on Geometry shader substitutes from Ryujinx...
- https://github.com/Ryujinx/Ryujinx/issues/4062
- https://github.com/Ryujinx/Ryujinx/pull/4368
Any new updates? I'd also be willing to contribute to any available bounties or donate to anybody working on this issue.
@billhollings your probably aware of this but could this somehow be usable as a pollyfill for older version of macOS https://developer.apple.com/documentation/metal/metal_sample_code_library/mixing_metal_and_opengl_rendering_in_a_view
@billhollings your probably aware of this but could this somehow be usable as a pollyfill for older version of macOS https://developer.apple.com/documentation/metal/metal_sample_code_library/mixing_metal_and_opengl_rendering_in_a_view
Can you elaborate? How are you thinking we could use OpenGL to provide Geometry Shaders?
Can you elaborate? How are you thinking we could use OpenGL to provide Geometry Shaders?
That’s indeed what I was thinking.
That’s indeed what I was thinking.
Yes. But how do you envision it hanging together in a pipeline that is otherwise Vulkan/SPIR-V?
Yes. But how do you envision it hanging together in a pipeline that is otherwise Vulkan/SPIR-V?
It’s probably better someone more knowledgeable with Metal/Vulkan look into how/if this could be made viable, it seems technically possible but not sure how viable.
It's not viable. You'd have to write a Vulkan to OpenGL translation layer, which is impossible, especially with Apples ancient OpenGL 4.1 and then somehow dynamically switch to that based on the rendering pipeline while remembering to sync all previously set state over.