[Bf-committers] Metal GPU support

[Clément FOUCAULT]

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 would be nice to get rid of them but the thing is they are sometimes
faster than their alternative on some hardware so we have to maintain both
version already.

Other thing to keep in mind is that we need to keep compatibility for
opengl 3.3 for now. So using compute shaders for some things means
duplicating codepaths.

Le mer. 5 déc. 2018 à 00:07, Stuart Carnie <stuart.carnie at gmail.com> a
écrit :

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