Hijacked by life… I know the feeling!
Anyway, thanks for your interest and involvement. I know the mac community are not the biggest in Blender but we love blender and would like to be included in the GPU rendering crowd. Pity Apple are not more helpful.
Keep going, we really appreciate it.
3 Likes
Blaming Apple is the right thing to do but not for the reason people may expect, the story is a bit more complex. If you are interested read on …
When OpenGL was implemented it was not intended to be a high level graphics API but actually lower level. However graphics became more complex and game engines at the time were not a thing as they are today so OpenGL very slowly changed and did not manage to keep up with the increasingly complex architecture of modern GPUs. It’s ironic that Apple is blamed for the demise of OpenGL while they were the ones that practically invented it in the first place and pushed it forward for so long. But as I said , there is some truth to this blame.
As much I am an Apple fan , this has been mostly Apple’s “fault” , see its no secret that Steve Jobs was never a fan of games in general, this is why Apple did not push things graphics wise. So most likely because Apple was and still is part of the board that makes OpenGL , they did not care about lower level API. Problem was that Apple also was the main driving force behind OpenGL as well, Apple needed OpenGL to fuel the speed of its GUI, like Blender , MacOS GUI is build on top of OpenGL. On other hand when iPhone and iOS came out , it became apparent that games was a main driving force of the sales. Apple “overnight” from a software/hardware orientated company became a game/hardware orientated company. Problem was that OpenGL was not know for its performance , so they came up with ES which was OpenGL for mobile devices, consumed less battery power but way less performant.
Problem was the game devs were gettting more ambitious on the mobile platform, the age of Candy Crash Sage and Angry Birds was ending and now gamers started to see mobile hardware as a serious gaming platform. Hardware was capable, but OpenGL was dragging things behind. Apple now predominatly a game driven company could not afford to stay behind with iPhone driving the vast majority of its revenue. As such Apple went back to the board and demanded a redesign of OpenGL. Apple overall is a bold company that is very design driven so is not afraid to redesign, I suspect Google and other big companies were not so willing to take similar risk. What they did not know was that Apple being Apple had a plan B, Metal. Apple had no intention exposing itself to any potential gaming company, cough Microsoft cough.
After the shock of Apple releasing Metal, the rest of the board rushed into releasing Vulkan and there was no further talk about OpenGL, in their website or youtube channel. OpenGL “overnight” was… dead.
If the term “dead” sounds a bit vague let me put it in numbers the latest API specification, basically its board guide how OpenGL should be made and look like is OpenGL 4.6 that will be 2 years old this July. Vulkan on the other hand had its latest stable release 20 days ago. You could say that OpenGL is moving forward 17 slower but I think “dead” is a very fair term in this case.
To give an idea about the complexity you can make a triangle with around 100 lines of code in OpenGL but you will need around 1000 lines to do the same in Vulkan. But the bonus will be that your code could be also around 10 times faster too. Because those APIs have deeper access into the GPU internals they allow you greater deal of fine tuning and freedom to pick the solution that fits your problem.
Thus Blender moving to Vulkan or Metal is pretty much inevitable in the long run, how long is the question. Funding is the answer 
Nowdays generally speaking people rarely access Metal or Vulkan directly, with the vast majority of games made with game engines like Unreal and Unity , you dont even have to know OpenGL to make a game cause those engines handle all the technical stuff for you so you the coder can focus on making your game. Large companies can afford not to use such engines and directly access Metal, Vulkan , DirectX etc. but they are a minority of the game industry although they collect much of the money.
150k apps (including games) use Metal directly while 2 million use it indirectly (through game engines mostly iOS). Metal overall has been a huge success of Apple from a user and a developer perspective.
What most people do not know is that Apple is still on the board that designed OpenGL which also designed Vulkan and they actively push for Vulkan improvement and adoption. Although they have little reason to port Vulkan to MacOS I would not be surprised if they do so in the future or help other developers do it.
3 Likes
Thanks so much for this, it does help to put things into perspective. I have been using Apple since the early days of “desktop publishing” and one thing I have noticed is that Apple will drop things and implement new things and the rest of the industry follows along (can you even buy a PC with a floppy drive now days?).
Its going to be a bit of a hard road for the Blender devs, they may just find themselves having to learn Metal and Valcan like it or not. I wonder is we are going to see the demise of OpenGL altogether?
Its funny how we mac users in the Blender community tend to give up and just accept out lot as a minority group. I have been worked in the Graphic Design industry for a while now and most studios, small and large here in Australia I have seen use Mac. Maybe as Blender makes it into the Studio we might see Blender forced to change.
2 Likes
OpenGL is dead in terms of evolution but not dead in terms of usage, there tons of legacy software that still depends on it, but most importantly Android still depend on OpenGL.
When the Android “fort” falls, the yes its practically the end credits for OpenGL. With Vulkan moving forward and OpenGL frozen, that is just a matter of time.
The problem for Blender is not only that Metal/Vukan is far more complex but also the fact that OpenGL code is spread all around the code base. It may sound normal for a non coder but for a coder this is a nightmare scenario because it means that he/she has to change a lot of code. An ideal scenario would have been if OpenGL was indirectly used through a secondary library , then transition to Vulkan would have been far easier, because the coder would have to update only that library.
None the less with 6 full time devs its actually quite doable to move to Vulka for version 2.9. Currently there is no huge rush to move to Vulkan because offline rendering is done by CPU or CUDA , both using latest APIs. The one that makes heavy usage of OpenGL and needs the extra performance is Eevee.
I think there is still room for Eevee to improve without having to abandon OpenGL but there is going to be a point when it will need something like Vulkan and Metal to compete with the big boys. Generally speaking when it comes to computer graphics technology 3d apps are surprisingly behind the curve because they have much less customer and thus funding/revenue than games. Which is why Eevee look very impressive when compared to say Maya but not that impressive when compared to say Unreal.
Of couse making Eevee as good as Unreal is not really the goal. As artists we do not need the latest and coolest technology on real time rendering as desperately as the average high end game does.
So Blender can play the waiting game for a couple of years without any major cost to its user base. Again all that depends on funding.
On the matter of Mac users, not only Blender cannot afford to ignore them but it would be suicidal to do so because mac users are far more likely to provide general funding not just for a mac version but any version of Blender compared to your average pc users. Funding has become a matter of life and death for Blender because it has grown so large its unmaintainable by just a solo full time dev. This also a big reason why BI and BGE had to go. Sure technically you cannot “kill” open source but you cannot stop people from abandoning it either if you don’t move forward relative fast. However as I said, mac users so far have been pretty silent on the matter because currently it does not affects us directly.
If Blender stop working on Mac that’s another story altogether which with current funding seems highly unlikely.
You would think so, but it’s not that easy. I’ve been though that exact scenario before.
I’ve worked with code that was written for Mac OS, but intended to be portable. So instead of calling the API directly, it went though an abstraction layer. Instead of calling SetGWorld() for example, one would call Platform_SetGWorld(). And then ports in the future would just need to implement their equivalent of Platform_SetGWorld() and everything would be fine - right?
Porting that to MacOS X was a nightmare. There was no replacement for Platform_SetGWorld(), because whole concept of a current GWorld was abandoned. And even if, half of the drawing code would not have worked anyway, because the whole “who draws when” concept was different between MacOS and MacOS X, in addition to event handling being overhauled too. In the end, the abstraction library did not provide any more help than what search/replace could have done.
Why didn’t this work? Having an intermediate layer for the API calls is useless if the underlying concept changes. A hypothetical abstraction layer for OpenGL in Blender would have had to foresee the conceptual differences between Vulkan, Metal and OpenGL in order to be useful.
1 Like
I agree. Really for an abstraction layer to be useful it needs to truly be abstract and higher level than all implementations of it. An abstraction layer which relies on a ‘world’ with specific behaviours isn’t a useful abstraction if you want to implement it with something that doesn’t have that concept.
What are the existing abstractions which have been used in Blender so far? As far as I’m aware, they have defined interfaces for certain cycles calls, which can be implemented in a variety of manners. I guess it depends on whether the interfaces built in Cycles can be implemented in a performant manner on Metal.
Not to mention that OpenGL itself is an abstraction layer already. The whole point of it is to allow application developers to draw graphics using the OpenGL API and not having to worry about how the operating system and the hardware implement those drawing calls.
Now, if we’re just talking about Cycles, then that’s the easy part. There’s only a handful of OpenGL calls in Cycles, and the compute API calls for OpenCL are not too different conceptually from the Metal compute API. Moving from one host API to the other is not the stumbling block.
The bigger issue most likely will be to translate the render kernels to Metal kernel language, adding workarounds for possible limitations and bugs in Metal and performance tuning. Those are the parts that no abstraction layer could do for you.
2 Likes
Indeed. The biggest problems will be because the actual call patterns and concepts change, not because api_ogl(…) becomes api_vk(…). The GPU_* abstractions added to blender recently to segregate ogl calls will not be very useful in some hypothetical vk future.
The vulkan/dx12 benefits are because they change how and when resources/work/state needs to be filled in and submitted to the gpu, creating new concepts along the way. The ‘when’ part, in particular, can be one of the hardest things to abstract and plan for. If you used to call api_ogl at step 4, you may need to call the equivalent api_vk at step 0… and you may not currently have that info at step 0… and that’s if there’s even a good mapping between the calls in the first place.
Come on , you cant possible tell me that this is like not a common way to code. That’s the whole point of Java , C# etc. Pretty much anything is an abstraction of an abstraction nowdays coding wise.
No we are not talking Cycles because as I said Cycles does not depend so much on OpenGL. The elephant in the room is GUI that like any other app takes a huge chunk of the code base and is OpenGL all the way down. I am working on the GUI code almost daily and there is a ton of OpenGL code used for drawing and yes it could have been easily abstracted away at least to a small degree.
Of course one would argue that the GUI would not benefit so much from Vulkan/Metal anyway and is a valid point but with OpenGL stagnating on all platforms is not like there is a choice. Coders also are not know for their love for GUIs. Eevee also depends heavily on OpenGL. That a ton of code to rewrite.
Yeah struggling with OSes specific is a pain in the hat but its not as if Blender does not already have like a gazillion abstractions inside for image manipulation, event handling etc etc. It’s not as if one has have tough time with a couple of function he has to give up and completely abandon because of those two function or three or whatever. I am not arguing here that OpenGL was not abstracted enough, it was not abstracted at all, all calls are basically very thin wrappers at best.
Of course abstracting OpenGL is not exactly a walk in the park either. No OpenGL is definetly not an abstraction layers because it was never intended to be one, we use as abstraction layer which is why it stagnated. I remember when Vulkan came out I was saying that it will replace OpenGL, people called me silly and ephasized that Vulkan is definetly not a replacement but a lower level API . Years later it has replaced OpenGL. Although almost none cares because the vast majority use it via a game engine. These people know more about OpenGL that they know about Vulkan.
In any case I wish good luck to the poor coders that will have to port all that code. Ain’t going to be a walk in the park but I am sure devs are more than capable doing this.
2 Likes
I don’t understand. OpenGL is not native to any operating system, and OpenGL is not native to any hardware. The intention of OpenGL was to provide an API that would allow one to write software that runs on different operating systems and different hardware without having to care about differences. That was the whole point.
What is your definition of abstraction layer that OpenGL does not fit?
I meant it from the point of you that it sits directly on top of the driver of the GPU. So like Metal and Vulkan it was intended to the give direct access to GPU features. However because GPUs became more and more complex it stayed behind instead of keeping up with the times. As such it is easy to see it as an abstraction , which technical it is, but it was not originally intended to be one.
Of course in coding essentially everything is an abstraction and non native , even machine code to a degree.
Additionally it seems there are a lot of efforts to run OpenGL on top of Vulkan and Metal , I have already found GLOVE and ANGLE. Which is good news even if Blender decides to keep OpenGL a bit longer. GLOVE is OpenGL ES running on top of Vulkan (MoltenVK) running on top of Metal.
https://github.com/Think-Silicon/GLOVE. Of course it can be used also for any other OSes that support Vulkan like Windows, Linux, iOS and Android
It wasn’t. It was supposed to give you indirect access, so you didn’t have to care about the actual capabilities of the graphics hardware.
Back then, some hardware did support acceleration for T&L, some didn’t. (T&L didn’t come to PCs until the GeForce 256). With OpenGL, and that was the whole point of it, you could write your code against the API as if the hardware did support T&L, and it was the OpenGL implementation’s job to figure out whether to run it in hardware or software. So when you wrote OpenGL software on a Windows NT machine in 1996, you could rely on T&L even though it took three more years until you finally got hardware that actually knew how to do that. Which meant that your program could benefit from new hardware capabilities without needing an update. That is abstraction, and that is what OpenGL was designed to do from the beginning.
Even today, you can use OpenGL to access functionality that your hardware doesn’t even have (I don’t believe any currently shipping consumer card implements GL_SELECT in hardware, yet you can use it from OpenGL).
Regarding the “staying behind” part, most new hardware features were available from day 1 as OpenGL vendor extension. For example, the day Nvidia started shipping Turing hardware, their drivers included the OpenGL extension for the new mesh shader feature. Metal on the other hand doesn’t implement geometry shaders, a feature that Blender 2.8 relies on for dashed wireframe drawing.
The reason why Metal and Vulkan (which was originally called glNext, as in next generation OpenGL) gained traction is because they had fewer features than OpenGL and provided less abstraction, removing driver overhead.
You can’t blame anyone for not abstracting Blender away from OpenGL. When you want to write an abstraction layer, you need to know your common denominator. Just until very recently, there was no alternative to OpenGL for Blender: For the majority of supported platforms, OpenGL was the only available API anyway, with Windows and Direct 3D being the only proprietary alternative.
You’re awesome! I’ve been stressing a bit about this since Mojave (without Nvidia Support) dropped and Apple focusing on Metal.
I’ve been contemplating a dual boot setup on my iMac Pro, with an Nvidia egpu… BUT if cycles supported Metal, I could save a TON of money and hassle making use of my current hardware!
Anyway this is just to say I really wish I had the knowledge to help this along, but I’m super grateful for your efforts here!
Summary:
I never blamed any Blender dev, you just put words in my mouth. I mainly said that OpenGL is all over the code and thus removing it will be hard work. Abstractions are slow, OpenGL main purpose was all about speed on multiple platforms, some abstraction was necessary to make it able to run on multiple platforms, GPU companies showed little interest on keeping up OpenGL low level enough to be fast, it abstracted away to oblivion, Apple abandoned a sinking ship, like Flash everyone blamed Apple and call it greedy and to" prove it" moved on to Metal/Vulkan the same way people moved to HTML/JS " to prove" how wrong Apple was to move away from Flash. Like Flash in a decade almost none will remember or care about OpenGL. In the mean time let’s all blame Apple.THE END
Long version:
Ok let’s take things from the start
When Elite , one of the first games to use 3d graphics , appeared there was no OpenGL , there was no GPU. Everything had to be rendered via software. Essentially software predates hardware by several decades.
So when you say that OpenGL can do things that hardware cannot do, you basically say that software does things that hardware cannot which is the whole point of software.
The abstraction you see in OpenGL was placed there because it necessary to make it possible to use on any GPU. Without it OpenGL would not have been able to run only on any OS but also any GPU and none would have used it. So it’s not as if OpenGL ever had a choice on that department.
However to actually claim that OpenGL abstraction was the main reasoning behind the API is basically equal to claiming that ease of usage was the main reason instead of speed. Nothing could be further from the truth. When OpenGL came out game developers were still relying on Assembly for game development as C++ was deemed too slow for their demands , I know because I was learning 3d graphics coding back in 1996 with the current craze that was 3d mazes. 1996 was a time that 3d games was already popularized by DOOM that was released 3 years earlier and took the world by storm. Guess how much of it was hardware accelerated.
Creating features on the software side, aka “software acceleration” or “hardware emulation” or “virtual hardware” , is a popular technique that has been always in use way before OpenGL was even a grain of an idea, the problem however with software acceleration is that is slow.
It’s slllllooooooowwwwwwww … last time I checked over a decade ago was at least 10 times slower than hardware accelerated features. It’s true that game developers do use software features to achieve results not possible with hardware, or to support multiple platforms, but that has been always a mainly no go zone because game development is all about speed. So it’s not practical possible for OpenGL to either target abstracting away hardware or ease of use without bringing the system to a crawl. Elite devs had to count bytes to make sure the hardware did not explode under all the software emulation which was super basic.
Since the vast majority of graphics coders are game coders having something that is not 10 times slower but even 10% slower is a no go. Simple as that.
Also the future features you describes were introduced because the group behind OpenGL was made from members like NVIDIA which introduced hardware features before hardware was even released. That’s normal because OpenGL did not release that often and could not keep up with the crazy evolution with hardware which was also the main reason for its demise.
The main reason why Metal and Vulkan gained traction is also the same reason why OpenGL gained traction.
Apple
It’s not coincidence that the moment Apple decided to abandon OpenGL , everyone abandoned OpenGL. Apple was not the company to invent OpenGL but it was the company to popularize it and establish it, without Apple OpenGL could not survive , the same way without Apple , Flash could not survive.
The reason why Apple abandoned OpenGL ?
Speed
To paraphrase a famous quote
“Speed, speed, speed, speed, speed, speeeeed”
I did not blame any dev, I did not say that blender dev were stupid not to abstract OpenGL away . Afterall my whole point is that abstractions hurt performance. I mainly said that this would make it hard to port Blender to Vulkan/ Metal. Of course they could have predicted the demise of OpenGL which was no surprise with the ridicule it was suffering from people comparing it with the speed of DirectX which was always a big thorn for game devs using it, not to exclude how poorly it was supported by GPU manufacturers which had little interest for the MacOS platform which at the time had 3.5% of the market, compared to almost 15% it has nowadays, and zero interest on Linux that its market share was basically… welll… zero
Which what led Linus to show the middle finger to NVIDIA, a video that turned to one of the most popular memes.
But Blender with only a couple of full time devs could not do much on the issue anyway. OpenGL was the right choice and the obvious choice, in case of Blender, it was the only choice.
2 Likes
Its interesting to see all this lively debate going on… programmers are a passionate lot and Apple has always been a passionate subject from its early days in desk-top publishing to, well… today. I have used both apple and windows platforms since the beginning and even used a Tandy TRS 80 at high school and believe me what you guys are going on with has been going on “forever”.
Over the years I have seen Apple drop a lot of hardware and other stuff, then an outcry, then a few years later, its gone on other platforms too. I am not a particular Apple fan, I use it because I have CS6 and want to be able to keep my investment and use of it, I also really like the interface.
My opinion is that Apple market share will only grow, there will be more and more Apples running Blender and eventually things will have to change sometime.
For myself I do not think that arguing over this is going anywhere, some of this debate is simply not understanding each others syntax. Why not join together, identify the problems and challenges and solve them. All the time spent in arguing and debating could be spent on the beach enjoying the sun… or coding.
It would be so nice to see some exchanges of code, lists of priorities, ideas for improvement and a discussion around helping Blender into the future.
1 Like
The problem is not that Apple is dropping is dropping OpenGL or OpenCL. The problem is using a proprietary technology instead of open standard to replace it, and not even allowing graphics vendors to support that open standard like they do on other platforms.
A lower level graphics API has been coming for a long time, Mantle and DirectX 12 were under development long before Metal was announced. There’s no problem moving Blender and Cycles towards newer technologies. It’s just unfortunate that a lot of duplicate work is needed not because of technical reasons, but because of strategic decisions by some companies.
6 Likes
Why not use MoltenVK then, its Apache 2.0 so not only open source but also compatible with GPL 3 if I am not mistaken and its basically Vulkan run on top Metal and supported by Valve to run Dota 2 on MacOS. Also actively developed/maintained
So you kill two birds with one stone.
1 Like
We’ll probably use MoltenVK to replace OpenGL on macOS in the future. However it is not a practical replacement for OpenCL or CUDA in Cycles, which is what this topic was originally about before it got off-topic.
3 Likes
you got a point there, sorry about that I got carried away.
On the matter of CUDA the good news is that it is not maintained by Apple on MacOS but NVIDIA, on the other hand that may be of small comfort to more modern mac user that have AMD GPUs. I am one of the lucky ones my iMac has an NVIDIA GT 755m. So CUDA seems to be ok for future version of MacOS, OpenCL future is still to be determined. Maybe AMD will follow the road of NVIDIA (as it did with CUDA) and offer their own OpenCL for MacOS, we will have to wait and see.
Unfortunately, there are no CUDA drivers for macOS Mohave, and there aren’t any in sight. If you have a working setup, don’t upgrade your OS until we either have a new driver or Cycles on Metal.