Apple has announced yesterday at the WWDC (Worldwide Developers Conference), that OS X 10.11 (codenamed El Capitan, the name of the largest monolith of granite in the world, in Yosemite National Park), the new iteration of Apple’s operating system for desktop, will bring the Metal API, introduced last year at the same WWDC, to OSX 10.11. So far, Metal was reserved to iOS.
This new support is a good and bad news at the same time. Good news because graphics developers will be able to play with this low level API and add its support to their applications. Bad news because the future of OpenGL and Vulkan is unclear on OS X. OpenGL is currently years behind what it should be (current version is OpenGL 4.1 on OSX while OpenGL 4.5 is available on both Windows and Linux) and it would be nice to have at least OpenGL 4.3 carved on El Capitan’s rock. And what about Vulkan, the universal low level API? I only hope that the support of Metal will not take all resources needed to properly update OpenGL and implement Vulkan. A solution could be OpenGL on top of Vulkan and Vulkan on top of Metal, or both OpenGL and Vulkan on top of Metal, like OpenGL on this picture:
OS X 10.11 will be available to developers very shortly and will be available as a free update for all users later this fall.
Links:
Well, the writing was on the wall for quite a while now. There hadn’t been any OpenGL progress since 10.9 came out and even less so for OpenCL, which hasn’t changed much since 10.7 (10.9 was only a very minor update). So, at this point it’s highly unlikely that we’ll ever see updated OpenGL/OpenCL support – at least from Apple.
Now, on the plus side, what would you rather like to see: Apple halfheartedly supporting OpenGL/OpenCL, or Apple fully committing to and pushing their own graphics/compute framework?
Also, with Vulkan/OpenCL/SPIR(-V) and Metal/AIR being backed by LLVM, there are ways to consolidate these now if you want to 😉
I am not entirely convinced by Metal at this point, notably by its shading language.
There are good things in it, e.g. I think templates and classes can bring a new category of higher-level constructs. Except no inheritance? Why not? Single inheritance, at least, was relatively simple to get. Or is it because they don’t want to support virtual functions?
The main problem with advanced C++11 features is that they tend to be expensive to compile. It’s not a coincidence if Metal shaders are compiled ahead of time instead of JIT like GLSL. Now, in general, compiling ahead of time has a number of benefits. But there are also use cases where you want to generate your shader code on the fly. A good example is a web browser or Tao3D, since they load the shaders at run time. How would you do something like ShaderToy with Metal? Is there even a way to easily compile a shader dynamically with Metal?
Introducing pointers in shaders doesn’t seem like the best idea in the world either. It brings all the bad things that go with pointers, e.g. issues with bound checking, etc. GLSL had proven that you could do a good enough shading language without pointers. Specifying ‘in’ and ‘out’ parameters is a much better way to achieve highest performance, as it lets the compiler select the best way to pass parameters around based on the target architecture, size of the object, etc. And with ‘in’ and ‘out’, the programmer cannot take the pointer, add 1 and see what happens.
The shader language is also extra verbose. It’s a good thing to be able to put vertex and fragment shaders in a single file, except that it forces you to prefix functions with “vertex” or “fragment”. In my own experience, I have rarely leveraged a same function between vertex and fragment shaders. Doesn’t mean there is no use case. There are also all the annotations, all the template notations for simple things, etc.
In short, the shader language looks like a few steps forward, a few steps backwards compared to GLSL.
As for the Metal API itself, it leaves me the save feeling. On one hand, it may seem like a good thing to give access to command pointers and low-level primitives. On the other hand, it means all application developers must understand relatively complex GPU/CPU communication and synchronization concepts, instead of just driver developers. Just like pointers, I expect latent bugs or performance under-optimizations to crawl in.
I don’t want to completely dismiss Metal, far from it. There are many use cases, e.g. games, where I think it’s the right choice. It’s more that I am quite concerned about Apple trading OpenGL for Metal, and for my particular use case, OpenGL seems much better at least today.
“A solution could be OpenGL on top of Vulkan and Vulkan on top of Metal, or both OpenGL and Vulkan on top of Metal, like OpenGL on this picture:”
The picture is wrong. OpenGL cannot be on top of Metal.
Whole point of the exercise is that OpenGL is old and does not
match modern GPU design.
Last year people had the notion that Metal was only for Imagination GPU and shared memory
with tile based architecture. This year Apple has brought Metal to discrete GPU with private memory.
There is no way Apple is going to update OpenGL, OpenCL. they are legacy now just for backward compatibility.
Vulcan will not be ready for another year. It is based on C API.
Apple is moving from Obj-C to Swift. Vulcan is incompatible with Apple’s other API
like multithreading, error handling. Metal is designed to hook into Cocoa and other frameworks.
Vulcan can never do that. Apple would have to kludge like OpenGL was kludged into their frameworks.
Portability matters. That’s why OpenGL is selected, because it is ubiquitous (runs on Mac, Windows, Linux, Android, iOS, WebGL, lots and lots and lots and lots of embedded devices, professional avionics, etc etc).
OpenGL is fast on Windows and Linux. It is Apple’s sucky drivers that are slow, not OpenGL (I know, I have a Mac Pro with dual D700s and the OpenGL runs twice as fast in the same hardware in Bootcamped Windows compared to Apple’s crappy drivers).
I have no interest in developing non-portable code. Lack of support for modern OpenGL is a massive fail for Apple, IMHO. I’m not interested in proprietary solutions (which ATI could orphan at any time if its priorities change). Plus editing GLSL as your program runs and changing your shaders on the fly as you run your program is *awesome* for development speed. Metal doesn’t do this.