Hi,
>However, once Vulkan gets more support in the market it's inevitable that
there will be a Vulkan implementation available for Mac, using Metal.
Not sure about license matters, but this already exists and is maintained
by Khronos themselves: https://github.com/KhronosGroup/MoltenVK
Regards,
Hi Stuart,
Thanks for reaching out. I understand the concern of Apple users.
However, going native with Metal in Blender is not the way to go.
For example:
-The amount of work (since 2014) to move old OpenGL in Blender to OpenGL Core
Profile was huge. Multiple person years of work. A decent
*Stuart Carnie*
On Tue, Dec 4, 2018 at 7:56 PM Clément FOUCAULT
wrote:
> Well given the amount of shader we use, we *need* to only maintain one
> version of each.
>
A very reasonable requirement.
>
> The biggest showstopper I see for porting to metal is the lack of geometry
> shader that we
Well given the amount of shader we use, we *need* to only maintain one
version of each.
The biggest showstopper I see for porting to metal is the lack of geometry
shader that we use in some places (not that many actually but important
ones like the edit mesh cage and outlines wireframes).
It
I'd agree, it would be much easier to use unified shaders. I've had a
really good experience with using glslang and SPIRV-cross in RetroArch to
generate Metal shaders dynamically. Both of these projects are well
maintained. Worth noting that some of the glsl shaders are quite complex
and translate
It's up for debate really, I'd prefer not having to maintain 5 different
versions of all shaders , also there is a fair amount of dynamic glsl being
generated by blender. so having something that'll take glsl and outputs
'whatever we want' would be nice.
glslang[1] with spirvcross[2] looked
Ray:
Thank you for the reply. It sounds like there is an interest in supporting
multiple back-ends, which is exciting.
With regards to the cleanup, it sounds like the current goal is to replace
any GL calls with GPU_* calls outside the GPU folders. I'd be happy to
contribute to that cleanup.
Is
I'm going to assume RA was build with multiple back-ends in mind, the blender
code-base however is an old old code-base, and wasn't really designed to use
anything other than openGL.
Although we have cleaned it up quite a bit, there are still loads of openGL
calls and opengl-isms sprinkled all
