Three years of Metal
blog.roblox.com
blog.roblox.com
I think in an ideal world, Vulkan would have arrived years earlier and became the central standard that succeeded where OpenGL failed. However, Vulkan is the phoenix which arose from the ashes of AMD's Mantle API in the mid 2010s. Thus, Apple chose to do what Apple does best: eschew common standards for their own proprietary solution which only works for their platform. It seems they've made this gamble with graphics and their structuring their machine learning ecosystem to be quite similar.
From a computer architect's point of view, seeing all of this diversity reminds me of the days of the console wars. Architects were willing to make crazy (at the time) design choices with their system architecture and developers were expected to learn how to leverage it to the best of their ability.
Hopefully someone with more experience than I can comment on whether these educated guesses amount to anything.
Note that Metal preceded Vulkan.
Apple surely was aware of this, yet wanted to go their own way.
Mantle became Vulkan when Khronos realized they weren't going to be able to deliver anything worthwhile using, and AMD gently gave Mantle to Khronos .
Metal was already on their way when this decision took place.
AMD announced Mantle late 2013, Apple announced Metal early 2014 with initial release mid-2014, AMD stopped development of Mantle as Khronos announced the Vulkan project in mid-2015 (and the first release of Vulkan was in 2016).
AMD was the first out of the gate, but the API style was really in the air at that point e.g. Dx12 was also announced in early 2014 though only released in mid-2015. The high-level OpenGL API style had been getting really long in the tooth by that point, GPUs were diverging more and more from it (requiring more and more complex drivers in order to bridge the divide) and the stateful nature of OGL really hadn't aged well.
First, well, AMD wanted to go their own way (designing their own thing in Mantle), so why not Apple?
Second, the year Metal appeared publicly wasn't the year Metal was designed in Apple. It was released in 2014 -- so it could very well preceed Mantle by a lot.
Mantle was much, much simpler than what eventually was shipped as Vulkan 1.0. When mobile vendors got onto the bandwagon, it turned into the monstrosity it is today.
Mantle was a proprietary API promised to work on AMD cards only. The work on it started in 2013.
Apple released version 1 of metal in June 2014. So, they'd already spent at least a year working on it. So why would they want to somehow go ahead with something proprietary that AMD was developing at the same time?
Khronos groups announced they were going to work on the next generation graphics API in July 2014 (a full month after the release of Metal v1).
AMD donated Mantle to Khronos in 2015, a full year after Metal v1.
---
There are reasons why Apple went with Metal, and they make a lot of sense: OpenGL was a disaster. Any improvements to it would require immense effort, and fighting against Khronos committees. OpenGL ES was only marginally better and only marginally better suited for mobile devices. So why would not Apple develop their own low-level graphics API for their own devices?
It certainly doesn’t look like AMD started working on a new API long before Apple did.
So the team that mostly created Mantle left AMD, got hired by Apple, where they built Mantle 2.0, aka Metal.
From where I'm standing the only real problem with extensions in OpenGL is that they are all enabled by default so it's easy to accidentally rely on one that happens to be supported by the hardware/driver you are testing on. This is not the case with Vulkan where you explicitly need to ask for the extensions you want.
And everyone ends up writing their own extension loading framework anyway, because feature X differs on extensions across GPUs and the same high level call should be orthogonal to the loaded extension.
Vulkan has a lot of faults, but this is such a weird complaint.
So instead of one "Vulkan API" you have a mess of sub-APIs which offer different features on each device, that's the opposite of a "cross-platform API" that Vulkan apparently wants to be.
Other APIs group capabilities into a very small matrix of API versions and feature levels which keeps the amount of optional code paths very small or in many cases eliminates the need for them completely.
As for fragmentation ... Yeah, it would be nice if Metal would be supported on Windows and on Android. Not really Apple's fault it isn't.
Is it Microsoft's fault that DX12 is not supported on Apple?
But another point I would add to OpenGL: Legacy.
Yes, with later versions, there was a way to migrate away from legacies like stippled line, but the very same legacy was used by CAD programs, which did not want to do away with everything and redo everything from scratch, so it had to be dragged along too.
OpenGL Drivers had to be very complex.
If you reached that point, than it is usually easier to do from scratch and clearly break the legacy use-cases.
> Thus, Apple chose to do what Apple does best: eschew common standards for their own proprietary solution which only works for their platform.
Funnily enough, I would say Apple was doing best when they stopped doing that. (Classic MacOS -> Intel, MacOSX, Objective-C, TCP, NFS, USB...)
Fragmentation isn't stable; the largest fragment tends to expand to dominate the market.
And we get the joy of Electron...
That is the problem right there.
Hence now we have ChromeOS as the Web, just give Chrome a couple more years with the current trend.
And OSes adopting the Linux ABI, or even running it virtualized, instead of caring for POSIX compatibility.
> adopting the Linux ABI, or even running it virtualized, instead of caring for POSIX compatibility.
So what happens when you want to use a feature that's not in pure POSIX?
I remember that quite a lot of the ugliness and insecurity of the original OpenSSL code was attributed to having #ifdefs all over the place to deal with weird and eventually dead systems.
An old comment on SO dives into OpenGL vs Direct3D: https://softwareengineering.stackexchange.com/a/88055
> Thus, Apple chose to do what Apple does best: eschew common standards
When Apple released Metal, OpenGL had already been an unusable mess, and Vulkan had not even begun to be a thing.
Vulkan began as a project a month after first version of Metal was released.
The main reasons there has not been a big push to create only one graphics API are:
1. it's hard after the genie of many API:s is out of the bottle (why should i port my code)
2. Surprisingly, the benefits would not be that huge (IMO) - compared to the enormous amount of energy this would take.
The graphics data the different API:s consume is more or less the same. Since it's eventually fed to the same hardware. So for an engine a large part of the non-trivial code is actually graphics backend agnostic.
All of the API:s basically
1. select whether to draw to onscreen or texture
2. load triangles
3. load shader program which a) modifies vertices of triangles (projection etc) b) computes pixel color for each sample in triangle
4. load variables and textures that are used as input to the shader program
5. draw.
The shader code has different languages but all of them are more or less isomorphic.
The above is a ELY 5 trivialization, but the gist of it is more or less so.
The difficult part actually is managing the state of any complex graphics program, not getting the graphics to the screen. So, first you need to learn a graphics API and think that's hard. Not so! What's actually hard is then figuring out how to make any coherent application around that.
It totally was when OpenGL was controlled by the ARB. ARB stands for "Architecture Review Board", even the name screamed "designed by committee". In the end, you couldn't do much without proprietary extensions, except using Direct3D...
After transfer the Khronos Group, it went better. Still a committee, but at least, the spec is not completely out of touch with modern hardware.
I don't know about Metal but Vulkan is not a replacement for OpenGL. It is a low level API, made so that engines like Unreal or Unity can have a lot of control and keep overhead to a minimum. However, it is absolutely terrible for small projects. It takes several pages of code to draw your first triangle.
According to the article, it looks like Metal is somewhere between OpenGL and Vulkan: lower level than OpenGL and easier to use than Vulkan. It doesn't look like Apple is doing crazy stuff with its hardware, but because they don't need to be portable, they can provide a simpler API compared to Vulkan which need to support all kinds of hardware and platforms.
I am not against Metal, however, I hate Apple for deprecating OpenGL. You used to have 3 options
1- Use an engine, and let it deal with all the rendering API stuff.
2- If you have a smallish project and want to do your own engine, use OpenGL.
3- If you are an engine developer, you make it so that it can support the best API for the system you are targeting, it can be Vulkan, Metal, DirectX 12,... and keep OpenGL for compatibility.
Now, option 1 is not portable anymore, and for option 3, you don't have a quasi-universal fallback anymore. MoltenGL/MoltenVK may be an option, but that's not ideal.
Option 2 was never an option for most consoles (check which ones are listed at Khronos).
Option 3, as per option 2 never had much gain on quasi universal API.
>I got the port that rendered most things in a suboptimal fashion running in about 10 hours in a single day, and spent two more weeks cleaning up the code...
So the author is a developer. How do you want to transfer me the $10?
But I love a lot of the actual Metal APIs.
Ideally I'd want to see shader compilers merged into regular compilers, so that "CPU code" and "GPU code" can be mixed in the same source file and share the same data structures (at least their declarations). Actually, the latter (sharing struct declarations via shared headers) works in Metal + MSL though.
What you are looking for is basically CUDA's model, and what Khronos is trying to catch up with SYSCL.
First, there's no clearly visible direct link to the company page from the blog (the logo doesn't take you there but to the start of the blog).
Second, I removed "blog." to get to the main roblox.com page, and it's a form to sign up without saying WTF this is.
The closest thing to this is an "About" page -- which is still so cryptic, I don't have any clear indication what they do.
And I cared enough to go through this and read some of the About text. The average person landing on their page / blog wont care that much.
P.S. I still don't know what they do. Looks like a game store. Or not.
As far as I've understood, it's a game with a game builder inside that allows users to create their own games, that can then be shared. This viral loop, especially among the main demographic of tweens, has propelled it pretty strongly.
Like Tik Tok, the concept is abstract, but the execution and usage seem off the charts regardless.
[0] https://www.gamesindustry.biz/articles/2020-06-29-roblox-pla...
Read this so often that it seems to be the consensus by now. I used to think "why doesn't Apple just hop on the Vulkan bandwagon and everyone will be happily united under one API", but given that Metal came before Vulkan, and it still has better DX, Apple was right.
What excuse does Vulkan have being the second iteration on the same concept, but still be more tedious?
And also being able to synergize hardware and software, which they love doing.
1. You think you can do better
whoever thinks they can do better and has the power to make it happen will.
2. To be able to control your own path
Standards take forever to come to consensus. If you control it you can do whatever you want.
3. To lock developers into an API and therefore make it expensive to port.
I'm sure there is plenty of software that would ship on more platforms if shipping on those other platforms was no work. This reason was brought up with Microsoft introduced DirectX. It's no different for Apple. I'm not saying either Microsoft or Apple are doing it for that reason but it's still a valid reason.
Also you can't with a straight face say on the one hand Metal makes is much easier to run an app or game across all Apple's platforms, and on the other argue it imposes an excessive cost on porting apps to their platforms.
If I'm developing a top tier game and want to port it to MacOS and iOS, does Metal make it harder because it's different from the system on other platforms, which in reality were different enough in the OpenGL ES days anyway, or does it make it easier because I get access to all Apple's platforms in one go? It might make it harder in some very specific cases, but a lot easier in many others so it's really a wash.
Thus Apple did the right move - good api, good performance, fast to implement.
Where as if you use OpenGL ES 3.0 your game, for the most part, your game just works. (having done both). I'm not advocating for OpenGL (yuck), just saying it's a real factor to use something portable vs not. Of course now-a-days most devs use an engine for which that's already taken care of but it certainly wasn't that way in the past when these types of complaints of lock-in came up for DirectX vs OpenGL and C# vs C/C++ etc. They're no less valid for Apple than Microsoft.
The other aspect is that openGL has nothing to offer when it comes to accelerated compute services to compete with CUDA. Apple needed a single solution across desktop and mobile, that could also provide a compelling alternative to CUDA and that didn't leave them dependent on anyone else.
> If you come from Direct3D or console world, you may take every single one of these for granted – trust me, in OpenGL every single one of these is unusual and is met with excitement, especially on mobile where you are used to dealing with occasionally broken drivers, no validation, no GPU debugger, no GPU profiler that is helpful, no ability to gather GPU scheduling data and being forced to work with a text-based shader language that each vendor has a slightly different parser for.
This is the main pain point with any Khronos API, just doing paperwork for standards and then let the partners come up with something, which most of the time just don't.