[Bf-committers] Metal GPU support

[Stuart Carnie]

*Stuart Carnie*


On Tue, Dec 4, 2018 at 7:56 PM Clément FOUCAULT <foucault.clem at gmail.com>
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 use in some places (not that many actually but important
> ones like the edit mesh cage and outlines wireframes).
>

Sounds like we could use compute shaders here.



> 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.
>

Do you think it would be reasonable to maintain duplicate code paths
for these cases? That is, using compute shaders for APIs such as
Metal or Vulkan?


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