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