Re: [Bf-committers] Metal GPU support
Hi, >However, once Vulkan gets more support in the market it's inevitable that there will be a Vulkan implementation available for Mac, using Metal. Not sure about license matters, but this already exists and is maintained by Khronos themselves: https://github.com/KhronosGroup/MoltenVK Regards, Nick Renieris Στις Τετ, 12 Δεκ 2018 στις 11:53 π.μ., ο/η Ton Roosendaal έγραψε: > Hi Stuart, > > Thanks for reaching out. I understand the concern of Apple users. > However, going native with Metal in Blender is not the way to go. > > For example: > > -The amount of work (since 2014) to move old OpenGL in Blender to OpenGL > Core Profile was huge. Multiple person years of work. A decent generic > wrapper to support other APIs than OpenGL (Metal, or Direct3d) is going to > be even more work than that. Everything in Blender draws with OpenGL. Every > button, every editor uses it. It means you can only work on graphics apis > when all developers/contributors to Blender agree on it and will help out. > > - Maintaining such a dual or triple graphics framework is going to take a > lot of attention and support as well. We will often get situations where > functionality keeps working in Linux/Windows but then breaks in Mac OS. > > There are better solutions. > > - Blender should choose for supporting open standards. We align closely > with what Khronos does for that reason. > The future is to make Blender work with Vulkan. That should be the core > focus of development efforts. > > - Apple has refused to work with Khronos on Vulkan. However, once Vulkan > gets more support in the market it's inevitable that there will be a Vulkan > implementation available for Mac, using Metal. Supporting Vulkan then will > automatically bring us Mac support back. And we align with every other app > who prefers to keep working cross platform on Macs. > > But if you want to help us with Metal: > > Cycles has been designed from the ground up to support multiple graphics > APIs. > It has good Cuda and OpenCL support for that reason. Here it's possible to > add Metal as well. Cycles code base is much smaller and much better > designed (and newer :) than Blender code. > > Why not volunteer first to help with Metal for Cycles? If that project > looks like it works well, we (and you!) also get more insight in the > complexity of having this kind of work done for Blender. Adding Metal in > Cycles will take 3-6 months of work already. > > Last thing for everyone to know: Apple took back our Mac Pro dev system > loan last summer. My contacts within Apple can't manage to get approval for > sending us another system. Blender Foundation has to pay for the Apple > developer program (to sign binaries). > > Apple is clearly not interested in supporting open source or cross > platform openness in any way. If they would, they'd work with the industry > on getting decent Vulkan support for their systems. If they were, they > would give open source coders access to updated hardware. > > Thanks, > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation, Director Blender Institute > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > > > On 4 Dec 2018, at 20:14, 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
Re: [Bf-committers] Metal GPU support
Hi Stuart, Thanks for reaching out. I understand the concern of Apple users. However, going native with Metal in Blender is not the way to go. For example: -The amount of work (since 2014) to move old OpenGL in Blender to OpenGL Core Profile was huge. Multiple person years of work. A decent generic wrapper to support other APIs than OpenGL (Metal, or Direct3d) is going to be even more work than that. Everything in Blender draws with OpenGL. Every button, every editor uses it. It means you can only work on graphics apis when all developers/contributors to Blender agree on it and will help out. - Maintaining such a dual or triple graphics framework is going to take a lot of attention and support as well. We will often get situations where functionality keeps working in Linux/Windows but then breaks in Mac OS. There are better solutions. - Blender should choose for supporting open standards. We align closely with what Khronos does for that reason. The future is to make Blender work with Vulkan. That should be the core focus of development efforts. - Apple has refused to work with Khronos on Vulkan. However, once Vulkan gets more support in the market it's inevitable that there will be a Vulkan implementation available for Mac, using Metal. Supporting Vulkan then will automatically bring us Mac support back. And we align with every other app who prefers to keep working cross platform on Macs. But if you want to help us with Metal: Cycles has been designed from the ground up to support multiple graphics APIs. It has good Cuda and OpenCL support for that reason. Here it's possible to add Metal as well. Cycles code base is much smaller and much better designed (and newer :) than Blender code. Why not volunteer first to help with Metal for Cycles? If that project looks like it works well, we (and you!) also get more insight in the complexity of having this kind of work done for Blender. Adding Metal in Cycles will take 3-6 months of work already. Last thing for everyone to know: Apple took back our Mac Pro dev system loan last summer. My contacts within Apple can't manage to get approval for sending us another system. Blender Foundation has to pay for the Apple developer program (to sign binaries). Apple is clearly not interested in supporting open source or cross platform openness in any way. If they would, they'd work with the industry on getting decent Vulkan support for their systems. If they were, they would give open source coders access to updated hardware. Thanks, -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation, Director Blender Institute Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > On 4 Dec 2018, at 20:14, 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
Re: [Bf-committers] Metal GPU support
*Stuart Carnie* On Tue, Dec 4, 2018 at 7:56 PM Clément FOUCAULT 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 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 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 > 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
Re: [Bf-committers] Metal GPU support
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 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 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 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
Re: [Bf-committers] Metal GPU support
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 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 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 >
Re: [Bf-committers] Metal GPU support
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 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
Re: [Bf-committers] Metal GPU support
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 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
Re: [Bf-committers] Metal GPU support
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
