Not sure what you are saying. Blender 2.8 will dump compatibility with OpenGL < v3.0, I believe. But OpenGL itself has to keep compatibility. Later versions can deprecate functions, but the underlying architecture is from 1992.
That is what I mean. Weren’t they saying that version 3 broke backwards compatibility with the earliest versions of opengl?
I’m not a developer so maybe there is a detail I don’t understand, but info in the wikipedia article for opengl seems to indicate this as well:
I understand the argument that opengl is harder to code for than metal, but it doesn’t seem like its an api that is worse because it tries to keep backwards compatibility at all costs or anything like that.
I don’t think you understand. OpenGL 3.1 dropped backward compatibility. Pretty much anything from OpenGL 1.0 won’t work in a modern core profile OpenGL context.
That is why Blenders transition to the newer OpenGL took time - because lots of old immediate mode code had to be stripped and replaced.
It isnt. Metal (and Vulkan) are less convenient than OpenGL by design. By exposing the hardware more directly, more work is shifted from the driver to the application developer.
Windows 10 still shows all the underpinnings from 1990s Windows NT. MacOS Mojave is under the hood still NextStep (1989 I think?), with its 1970’s BSD Unix code.
You have a good analogy there, but it doesn’t prove your point.
Photoshop soon. A simpler Illustrator already.
Onshape and Shapr3D have been on iPad for 2 years. I reckon because the transition is easier since the OS’s share so much code. And because the iPad pro is very, very powerful for a tablet.
Sculpting too. I wouldn’t mind seeing Blender on iOS 
But I’m fairly certain it won’t happen. Multi-platform and simple development + upkeep is too important.
The App Store TOS are incompatible with the GPL, so don’t hold your breath.
Well Metal and Vulkan are quite different beasts - I wouldn’t lump them together.
Metal isn’t any more difficult than OpenGL, but try implementing multi-threading with OpenGL, and then you will realize that Metal is a lot easier to use.
A minor nitpick, Metal is supposed to be the replacement for both OpenGL and OpenCL (the former has always been about graphics done on the GPU).
1 Like
I’m curious if considering Metal compute for Cycles is as bad of a minefield as replacing OpenGL. Cycles supported CUDA before anything else and that’s completely proprietary to nvidia cards only.
With OpenCL being deprecated (and is currently outdated on the platform as well), there will be pretty much no compute option at all for Amd users, which would be almost 100% of the macs out there since 2013. The only other solution is to use an eGPU with an nvidia card.
Does anyone have any insight into how much work would be involved in supporting metal compute?
A lot. Supporting CPU, CUDA, and OpenCL has thus far been (relatively) painless because there exists a common subset of C-ish code that works in all three with minimal custom work for each. Metal, AFAIK, has no such subset included.
Unless apple open sources metal, I kind of doubt the foundation will put resources towards a metal implementation of anything. By that I mean I could see them switching to metal if it were truly cross platform, but it’s not so I doubt they’ll want to split development effort like that. Recent decisions suggest that the foundation is trying to make development easier on themselves (the retirement of the game engine and blender internal).
I suspect that all users with mac hardware will have to dual-boot into linux in order to use blender in the future. It’s possible to set that up on a mac, right?
[quote=“Fordee, post:286, topic:1113803”]try implementing multi-threading with OpenGL, and then you will realize that Metal is a lot easier to use.
[/quote]
That’s a missing feature in OpenGL, not an issue of ease of use. Or else I would claim that geometry shaders are easier in OpenGL than in Metal - they’re not, because Metal doesn’t have any.
Amd has implemented metal compute support into prorender. I wonder if that effort could be leveraged in any way for cycles.
From a birds-eye view, Metal Shading Language is a C++ subset that’s fairly close to OpenCL (with similar limitations), so I think it should be possible to support it in the same way as those other languages.
[talking about multi-threading]
That’s really a false equivalence. Being able to code in an asynchronous manner (i.e. use multi-threading) is core to the architecture, and OpenGL wasn’t built to be able to support it. It’s not something that can be effectively added.
And it isn’t a specific feature like geometry shaders. If Apple decided that geometry shaders were useful, then they could add them to Metal 3.
Oh, I fully understand. Some level of thread-safety would be expected from a high-performance framework in this decade, and OpenGL was never intended for that (even though nothing would prevent anyone from adding an extension for that).
My point was mainly about @zanzio’s comment that OpenGL were “harder to code for”. Your point that doing multithreading using OpenGL would be harder than in Metal - sure, you picked the one thing that OpenGL was never ever meant to do. Trying to use a single-threaded API from multiple threads will always be inconvenient, no matter what (I learned OpenGL on BeOS, where you couldn’t write a GUI application that wasn’t multithreaded).
Of course Metal (and Vulkan) have their advantages over OpenGL. If they didn’t, nobody would have any incentive to use them. But that doesn’t mean OpenGL became obsolete overnight. As Joel Spolsky once wrote, code doesn’t rust, rot or deteriorate in any other way. Especially in the Unix world, we’re used to lots of code that’s decades old and still in daily use without major concerns.
I seriously don’t think that Apple will be able to sustain the idea of such a move. There’s simply too much basic code out there which uses OpenGL for graphics. I have no problem with the notion of them wanting to advance their graphics foundation software, but you can’t throw out the baby: it’s just too big. Some “thunking layer” will have to be provided, somehow, and then made a permanent part of the system.
Code doesn’t rust. But hardware capability marches on. The latest trend in CPUs is more and more cores. OpenGL wasn’t designed for such an architecture.
From the SIGGRAPH 2018 Report
- Had a long chat with Neil Trevett of Khronos. They’re actually funding Blender development now (glTF exporter). He also would look forward seeing us moving to Vulkan – we can make a project plan for it. And he knows that Apple Metal and Vulkan will get a good compatibility library as well. No worries for the Apple users then!
1 Like