[Bf-committers] Metal GPU support

[Ray Molenkamp]

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 interesting but I haven't spend any time with it, so that may or may not be a terrible idea.

--Ray

[1] https://github.com/KhronosGroup/glslang

[2] https://github.com/KhronosGroup/SPIRV-Cross


On 12/4/2018 2:10 PM, Stuart Carnie wrote:
> 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 the desire to support multiple back ends natively, with their own set of
> shaders or to take an approach similar to RA or bgfx (
> https://bkaradzic.github.io/bgfx/overview.html) and use a unified shader
> model. The former is simpler for consumers of the GPU_* APIs, as they only
> need to provide a single set of shaders, but it does mean that offline
> compilation and other optimizations may be limited.
>
> I will also take a look at the thread you shared.
>
> Cheers,
>
> *Stuart Carnie*
>
>
> On Tue, Dec 4, 2018 at 1:14 PM Ray Molenkamp <ray at lazydodo.com> wrote:
>
>> 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 over the code base.  Before you
>> can add a backend you'd have to deal with the cleanup first.
>>
>> I started a cleanup a couple of months ago to wrap these calls from GL*
>> calls to GPU* calls but due to the speed 2.8 was progressing at this point
>> it was difficult to keep up with the daily changes, or not interfere too
>> much with the eeve progress so put it on hold for a while.
>>
>> To facilitate this cleanup there's the WITH_OPENGL cmake option which will
>> limit the visibility of the opengl headers to pretty much just the BF_GPU
>> module so any code that shouldn't be making any opengl calls will give a
>> nice compiler error.
>>
>> This thread may be of interest to you
>>
>> https://devtalk.blender.org/t/alternative-rendering-backends/830/13
>>
>> --Ray
>>
>> On 12/4/2018 12:14 PM, Stuart Carnie wrote:
>>> Hi Blender 3D developers:
>>>
>>> Given the deprecation and poor support of OpenGL on Apple platforms, I am
>>> curious if there is any interest in my desire to develop Metal GPU
>> support
>>> for Blender 3D?
>>>
>>> I recently implemented Metal support for RetroArch (a cross-platform
>>> emulator front end). Some of the highlights of RA:
>>>
>>> * supports multiple GPU back ends, including GL, Metal, Vulkan, DirectX
>> and
>>> other esoteric APIs
>>> * a complex, shader pipeline for post-processing using a unified shader
>>> system of glsl shaders, some in excess of 20 passes (
>>> https://github.com/libretro/slang-shaders). These are cross compiled to
>>> target APIs such as Metal, Vulkan or DirectX using glslang and
>> SPIRV-cross.
>>> I've had a bit of a peek at the blender 2.8 branch and imagine the place
>> to
>>> start would be the GPU folder. I suspect, given the abstractions, there
>> has
>>> already been some thought into multiple-GPU support and wonder if there
>> is
>>> any public information on this?
>>>
>>> Cheers,
>>>
>>> Stuart
>>>
>>> *Stuart Carnie*
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers