[Bf-committers] Metal GPU support

[Stuart Carnie]

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 to Metal and Vulkan at runtime without issue. I anticipate it
would be possible to automate conversion at build time and map glsl inputs
to their native outputs, allowing for offline compilation of core shaders.

*Stuart Carnie*


On Tue, Dec 4, 2018 at 3:34 PM Ray Molenkamp <ray at lazydodo.com> wrote:

> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>