make sense to integrate general UE4 MacOS hack/fix via some enviroment variable?

[oscarbg]

Hi,

seeing https://www.youtube.com/watch?v=Yl86dLJjTW0 learned there is a hack/patch allowing lots more UE4 games to render more or less correctly on MacOS M1/M2 using DXVK+MoltenVK..
the patch is here:
nastys@be6488d
what's new is the SPIRVToMSLConverter.cpp part of the patch.. there other parts enable DXVK+MoltenVK as before..
there is a prebuilt MoltenVK release listing the bug of many UE4 games more precisely:
https://github.com/nastys/MoltenVK/releases/tag/ue4-workaround-1

This happens because, presumably due to a bug, the "CombineLUTs" step generates a 32x32x32 3D texture with all "layers" black except the first one, resulting in a black frame after post-processing.
I have patched the shader to bypass the LUT for now.

would be nice if that part of the patch can be integrated in MoltenVK and enabled via some enviroment variable (like MVK_FIX_UE4_games?).. makes sense?

thanks..

[Gcenx]

I don’t believe these kind of hacks should become part of MoltenVK once the real issue has been tracked down this could probably be fixed correctly.

What might be acceptable is playing private APIs behind an env/compile option.

[cdavis5e]

This happens because, presumably due to a bug, the "CombineLUTs" step generates a 32x32x32 3D texture with all "layers" black except the first one, resulting in a black frame after post-processing.
I have patched the shader to bypass the LUT for now.

And this, in turn, happens because MoltenVK doesn't yet support geometry shaders. UE4 uses geometry shaders for layered rendering, because D3D11 originally didn't let you set the SV_RenderTargetArrayIndex and SV_ViewportArrayIndex sysvals from vertex or tessellation shaders.

[Gcenx]

The above is why I hate faking Vulkan extensions in MoltenVK to keep DXVK happy.

Allowing DXVK to avoid geometry shaders but provide a message when required helps show things like this.

Edit:
I'd still make use of these kind of hacks just don't think it's right to have upstream carrying said hacks.

[nastys]

If it is because of geometry shaders in post-processing (I haven't really had the time to look into it), I think it would make more sense to implement partial support for geometry shaders (using compute shaders, CPU callbacks or whatever) and lock it behind an environment variable.
My hack doesn't work for all games, probably because the recompiled shader is sometimes slightly different.

[italomandara]

If it is because of geometry shaders in post-processing (I haven't really had the time to look into it), I think it would make more sense to implement partial support for geometry shaders (using compute shaders, CPU callbacks or whatever) and lock it behind an environment variable.
My hack doesn't work for all games, probably because the recompiled shader is sometimes slightly different.

I guess you could even do full geometry shaders support with compute shaders, with little overhead. It's just a matter of someone willing to do it.

[Gcenx]

Something for everyone to keep in mind, Bill is the only person working on MoltenVK full-time.

Chips is working on fixing CT failures (Khronos contract)

[italomandara]

Something for everyone to keep in mind, Bill is the only person working on MoltenVK full-time.

Chips is working on fixing CT failures (Khronos contract)

When I say someone I mean anyone that opens a pull request in the repo, like me or you or anyone else.
edit: not long ago actually there was someone working on mapping geometry shaders to mesh shaders.

[billhollings]

Something for everyone to keep in mind, Bill is the only person working on MoltenVK full-time.

Chips is working on fixing CT failures (Khronos contract)

When I say someone I mean anyone that opens a pull request in the repo, like me or you or anyone else.
edit: not long ago actually there was someone working on mapping geometry shaders to mesh shaders.

We will get to geometry shaders at some point. So far, it hasn't been identified as a priority, but this issue here is demonstrating some significant need. And in the meantime, yes, we are always happy to make this a collaborative development if someone has the time and priority to submit a PR with a proposed implementation.

Issue #1524 is the request for geometry shaders. And @italomandara has made some suggested implementations there. Compute or mesh shaders are options for solutions. Let's continue discussion of geometry shaders in #1524.

And if someone does start working on a proposed PR, please identify that in #1524 by posting a comment there, and assigning the issue to yourself.

[billhollings]

Closing as duplicate.