*Stuart Carnie*
On Tue, Dec 4, 2018 at 7:56 PM Clément FOUCAULT <foucault.c...@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.car...@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 <r...@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 <r...@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@blender.org > > > >>> https://lists.blender.org/mailman/listinfo/bf-committers > > > >> _______________________________________________ > > > >> Bf-committers mailing list > > > >> Bf-committers@blender.org > > > >> https://lists.blender.org/mailman/listinfo/bf-committers > > > >> > > > > _______________________________________________ > > > > Bf-committers mailing list > > > > Bf-committers@blender.org > > > > https://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > > > Bf-committers mailing list > > > Bf-committers@blender.org > > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers