[Bf-committers] Metal GPU support

Stuart Carnie stuart.carnie at gmail.com
Tue Dec 4 22:10:12 CET 2018


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.


*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

More information about the Bf-committers mailing list