Support MacOS via Vulkan Portability

[kvark]

Vulkan isn't natively available on MacOS, but it's becoming more accessible as a user-space layer. It would be great to have the corresponding Meson configuration setup, build instructions, and eventually CI coverage.

[kvark]

@cdavis5e - would you have something to share in this regard? Given your continuous work to chop through the dxvk/vkd3d blockers on MoltenVK, you probably have some sort of a playground setup.

[doitsujin]

I cannot and will not support that platform. If you need Mac support, someone who actually uses one has to provide support. Also I'm not sure if any of the wrappers are capable of running it.

[ssorgatem]

Why would MacOS need a different Meson configuration?
You can use the win32/win64 ones (which essentially crosscompile as a Windows DLL, regardless of the host system, as long as you have MinGW64 and Vulkan headers) .

I guess the winelib builds maybe require some tuning (maybe to change .so to .dylib or something? Is wine0s Vulkan support on OSX exposed differently? or... actually there?) or maybe not!

[K0bin]

The Vulkan to Metal layers won't cut it.

Here's just a few major features that MoltenVK (and probably gfx) doesn't have that DXVK relies on:

• Depth clamp
• Geometry shaders
• Tessellation shaders
• Setting texture swizzles

A lot of these simply aren't supported by Metal.

[Leopard1907]

FYI , texture swizzling resolved on gfx layer.

RPCS3/rpcs3#4996

At least worked around for RPCS3 on MacOS.

But , i rather his focus on DXVK only. Not on Mac. So Philip shouldn't make adjustments , people should adjust their layers to DXVK.

[K0bin]

They work around the lack of swizzle support by doing that manually on the cpu and in shaders,

While that could be done for DXVK, the missing shader stages are the biggest problem.

[Leopard1907]

I agree , that's why i said Philip shouldn't make workarounds.

It is an open source project , people can make adjustments on their forks etc.

If Philip involves with MacOS that would also mean he would have to consider MacOS situation on every step.

[kvark]

@doitsujin that's fair. Since you don't technically object this code path to be supported by somebody else, would you mind keeping the issue open? It's useful to know what the blockers are, and what works out of the box.

@ssorgatem

Why would MacOS need a different Meson configuration?

I don't know, tbh. The building instructions in README weren't enough to get it even configured for me (likely due to the lack of context). Will looking into it some more. Is there an (IRC/gitter/etc) chat somewhere for more interactive communication on dxvk development?

@K0bin
Thank for for the comprehensive list! These are difficult features to provide on Metal. However, there must be some D3D11 applications that don't require either of the features to work, and it would be great to have those working at least.
As VkPI (the portability initiative) progresses, we should be able to unlock more applications, hopefully ;)

[Guy1524]

@kvark yes, the VKx discord is good place where DXVK development is discussed

https://discord.gg/wHBTezH

[doitsujin]

Texture swizzles are crucial to implement a number of texture formats (the most common one being A8_UNORM). That's something MoltenVK should try to emulate on their end if possible.

DXVK already emulates swizzles for render targets since Vulkan doesn't support that, but that's effectively a zero-cost emulation since the render target formats are known at pipeline compile time. For sampled textures this would be much harder to support.

Another thing is extensions - does MoltenVK implement all the extensions that DXVK currently depends on? If not, there are going to be more issues. And the upcoming transform feedback EXT will probably make things worse. I just don't see full D3D11 support happen on Mac OS X, as nice as it would be.

[Guy1524]

Looking through MoltenVK source, here's the list of supported extensions:

VK_MVK_moltenvk;
VK_MVK_macos_surface;
VK_MVK_ios_surface;
VK_KHR_surface;
VK_KHR_swapchain;
VK_KHR_maintenance1;
VK_IMG_format_pvrtc;
VK_AMD_negative_viewport_height;
VK_KHR_shader_draw_parameters;
VK_KHR_get_physical_device_properties2;
VK_KHR_push_descriptor;
VK_KHR_descriptor_update_template;

So we are missing:
VK_KHR_dedicated_allocation_extension
VK_KHR_get_memory_requirements_2
VK_KHR_image_format_list
VK_KHR_maintenance2

[K0bin]

More information in here: KhronosGroup/MoltenVK#203

[kvark]

@doitsujin Vulkan Portability != MoltenVK. I represent gfx-portability. I'd appreciate if we discuss this in a more general sense of Metal limitations instead of MoltenVK implementation details.

Texture swizzles are crucial to implement a number of texture formats (the most common one being A8_UNORM).

That got me curious as well, since D3D11 doesn't have swizzling. You must be requiring a limited set of swizzles to cover formats that are in D3D11 but missing from Vulkan, and we might be able to provide them. For example, A8Unorm is already a supported swizzle. Is there a list of formats+swizzle combinations for us to work on?

In terms of extensions, there is indeed still work to do, but it's not the end of the world.

And the upcoming transform feedback EXT will probably make things worse.

I don't think it's worse. TF via vertex stage should be fairly trivial in Metal. TF via geometry shader / tessellation is more of a problem for those shader stages not supported natively by Metal, not as much of a problem for TF specifically.

[doitsujin]

Is there a list of formats+swizzle combinations for us to work on?

(R,G,B,1) might be useful for some RGBX formats where the 'X' component is ignored.

TF via geometry shader / tessellation is more of a problem for those shader stages not supported natively by Metal

Transform feedback via geometry shaders is the only thing that is supported in D3D11. It's annoying to emulate because it may require a compaction pass when vertices are conditionally emitted, but if Metal doesn't support geometry shaders, you'll probably have to do that anyway.

[Hello71]

The Witcher 3 doesn't render correctly for me with Mesa. I'm on a TeraScale AMD, so Vulkan is not supported. Is it worth trying to use dxvk with gfx-portability or is there no way this will possibly help?

[doitsujin]

Your GPU is too old, it doesn't support D3D11.

[Hello71]

In fact it does. You can see at https://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units#Features_Overview that Evergreen and Northern Islands class cards support D3D feature level 11_0. Also, TW3 runs fine in Windows (well, renders properly. can't turn the settings up beyond medium otherwise the fps goes to shit). I want to run it under Linux because the AMD drivers are unmaintained and don't even properly support dual monitor.

[doitsujin]

Well, you only said "TeraScale", which also includes pre-D3D11 GPUs, I couldn't know that you actually meant something else. Why not just name your GPU to avoid confusion?

Anyway, I don't see how gfx-rs is supposed to help you when there is no Vulkan support for your GPU, or what this has to do with Mac OS X.

If there are rendering issues using wined3d, please file a Mesa bug (the game works fine with radeonsi).

[Hello71]

gfx-rs apparently supports rendering to opengl, although I'm not totally sure how that works.

[kvark]

Our OpenGL backend is not ready for external testing atm, unless you are willing to fix things as you go and submit PRs ;)

@doitsujin is right though, your issue is not relevant to the topic ("Support MacOS ...").