A common trend I see is that game developers tend to target one platform after another instead of developing cross-platform from the start. This lowers the initial cost, but increases the additional cost for each platform as less of the previous implementation can be reused. This leads to thinks like the discarding Vulkan because it's somewhat harder than Metal for the macOS port and then having to still do the Vulkan work for Linux which may cost too much for the expected Linux sales even thoug the the difference between Metal and Vulkan might have easily been covered by the Linux income.
Now that is a bleeding generalization. As long as Feral is in the Linux market we know that Linux ports can be profitable. There have also been developers that have provided sales numbers for their Linux ports and for many of them porting has been a success.
Maybe that won't be the case for all games, but low market share does not tell you much. Remember that the platform-specific cost - even with rewriting the renderer - of a game will in most cases be dwarfed by design, voice acting, localisation, marketing, etc which all are already covered by the existing target platforms.
Your assertion is also not well defined since "worthwile" could mean profitable (which will be the case for third-party porting companies) or more profitable than other development efforts.
I have been a ROBLOX player since 2009. The Linux anti-cheat began to be enforced because practically no-one used the Wine port for honest gameplay; it was almost always to do some kind of memory manipulation or for script kiddies to execute exploits.
Not many people outside of the ecosystem are aware but ROBLOX was actually really late to the concept of dividing client and server responsibilities. It used to be that one client could actually propagate changes out to all the others; therefore if you could manipulate memory you could arbitrarily execute code (within the sandbox) on all other players. There used to be popular scripts like Person299's admin commands that could be injected into any server and allow the exploiter the ability to run chat commands like "kill/<user>" or "ban/<user>" (self explanatory). Only a few years ago did they introduce RemoteEvents and ServerScriptService which finally allowed developers to ensure some code could only execute server side, and properties like FilteringEnabled which blocked clients from propagating local game changes out to the server and everyone else. This broke hundreds of thousands of old games, which was probably why they held off, but nowadays any new games are using these new features to prevent easy exploitation like in the past.
My guess is they have nothing against Linux now, because they have implemented proper security, but the only thing stopping them are the technical challenges, and there are not enough people in their target demographic who use Linux to make porting worthwhile.
I think the main reason for Apple to go with Metal was that OpenGL has a lot of legacy baggage that they didn't want to support with their custom hardware.
And also being able to synergize hardware and software, which they love doing.
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.
I know I'm swimming against the tide on this, but I really don't think (3) is a significant factor. Apple knows very well that all the top tier games and graphics applications are going to be cross-platform. That's just a fact. They really can't afford to put significant road blocks in the way of getting those games and apps on to their platforms. That would be a massive foot gun.
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.
Apple has iOS where AFAIK there are more games than Android. They're really happy if you adopt things like Swift, Metal, SpriteKit etc, because then you're unlikely to want to port to spend time to port to Android.
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.
OpenGL managed to back itself into multiple, mutually incompatible and backwaters on mobile and desktop at the same time. It also is still mired in an ancient architecture based on technical decisions made 25 years ago that just don't apply now, doesn't take advantage of modern GPU pipeline improvements and has issues with poor multithreading and asynchronous processing. This is why Metal managed to get 10x rendering performance.
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.
I'd really enjoy a detailed writeup on why the graphics industry has been so fragmented. I'm not a graphics programmer myself, but from the outside looking in, OpenGL looks like it has fallen victim to design-by-committee. If I had to guess, the "big" players want to propose changes to the API which are closely reflect ideal usage of their own hardware. This typically upsets another big player, so the compromise is that both changes get added to OpenGL and the users are caught in the crossfire.
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.
IFIR at the time when Metal was released (or at least well into development) it wasn't at all clear what Vulkan would look like or that it would be derived from Mantle. Also Apple didn't exactly go their own way (in the sense of inventing something entirely different). Metal v1 looks a lot like a "next gen D3D11". The only thing that was clear at the time was that the GL programming model had to be abandondend, but better APIs than GL already existed on PC and game consoles to steal good ideas from.
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.
>Apple surely was aware of this, yet wanted to go their own way.
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.
This has a kernel of truth in it, but only a tiny kernel.
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.
> Apple surely was aware of this, yet wanted to go their own way.
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?
A team of small engineers inside AMD created Mantle, and AMD management did fuck-all with it; they donated it to Khronos for Vulkan, but some lawyers got involved and patent claims held up the release for a few years (Vulkan being late? That's AMD's fault!)
So the team that mostly created Mantle left AMD, got hired by Apple, where they built Mantle 2.0, aka Metal.
What is the "hell" here? Just the fact that extensions exist?
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.
The fact that the code ends up with so many execution paths, that it is hardly any better than having plugin abstraction rendering layer using the native 3D API for each target platform.
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.
To be clear, pjmlp, I don't think you've ever written a Vulkan app, ever. You don't need an "extension loading framework" on Vulkan (you might be confusing something like volk with that), since the loader is standardized, and a lot of the extensions are for very minor things or IHV moon-shot ideas, or are rolled into the maintenance extension.
Vulkan has a lot of faults, but this is such a weird complaint.
Since we are pulling credentials here, I have written enough of Metal, OpenGL, OpenGL ES, DirectX (5 - 12), WebGL, XNA, Unit, Java3D, M3G, PHIGS, Glide, Amiga and PC demoscene low level coding, to be able to evaluate Vulkan when going through books like Vulkan Cookbook and NVidia GTC sessions, but yeah, maybe I just don't get it.
The problem is that there are dozens (hundreds?) of extensions adding very tiny vendor-specific features all over the place, so your code feathers out into vendor-, GPU- and driver-version specific code paths, the "hell" there is maintaining and testing such code.
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.
With Vulkan you can choose to have a small matrix of feature levels and thus few optional code paths. Or you can have many. That choice is up to you. Whereas if the API defines feature levels, it isn't.
Vulkan does have versions too that provide bundled feature upgrades - no one is forcing you to use evey extension just because they are available. The same is/was true for OpenGL except for the large time window between 2.1 and 3.0 - you can write perfectly functual code without using any vendor extensions. Think of extensions more as a) a testing ground for bleeding edge features and b) a way to expose functionality that is truly specific to some hardware.
So now you want to blame Vulkan for mobile hardware variety and lack of Android updates? You can still use the lowest common denominator that is supported for all your targets. If you want to have code paths to enable more features on some devices then do that. Complaining that Vulkan gives you the freedom to choose where to make the cutoff for feature levels is pointless.
I don't know Vulkan. But from what I've heard, including this blog post, Metal is an easier to use API. I find Metal very easy to use, but still allowing for many very important optimizations. So I am glad Apple made Metal!
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.
Not saying it is. Don't know DX12 either. But back when I was programming on Windows I hated its API's, so I would probably not be a big user of DX12 on Mac anyway.
That is assuming that native applications will die and everything moves to a browser. While browser based apps have their ever widening place I do not really see them displacing everything else. And if it happens we will have one giant monoculture. Googles's wet dream. I am not really looking forward to such an outcome.
No, I am not assuming that. Instead I think, once this is a common technology available on the net, it will also become compatible on the desktop as time goes by.
Web 3D APIs are castrated as per security requirements and average hardware requirements, you really don't want to use them for native 3D applications and games, unless you don't care about taking advantage of nicely bought GPU cards.
Not sure, if I am terrible more experienced, but it aligns from what I've heard.
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...)
why should it NOT be fragmented? We don't use one OS. We don't use one programming language. We don't use one assembly language. We don't have one CPU design. Why would we have one GPU API?
We all use the same WWW which uses the same markup language and the same programming language with (almost) the same APIs, and huge effort is expended in polyfilling over the differences.
Fragmentation isn't stable; the largest fragment tends to expand to dominate the market.
>We all use the same WWW which uses the same markup language and the same programming language with (almost) the same APIs, and huge effort is expended in polyfilling over the differences.
Given the adoption rate of WebGL 2.0 (including the issues with blacklisting drivers), the current state of WebGL 2.0 compute, I don't have high hopes for a 3D API where the shading language is yet to be defined.
Well, (un)fortunately WebGL 2.0 adoption is mainly blocked by Apple. And as Apple is one of the driving forces behind WebGPU, I expect it to be adopted by Safari faster.
Current Safari Technology Preview on Mac actually has a working WebGL2 implementation that's pretty much complete (maybe apart from a few minor issues that need fixing before the switch can be flipped). The whole thing got rebooted quite recently (AFAIK with the help from Google developers), to integrate ANGLE into Safari instead of a 'from-scratch' implementation.
Isn't that more of a "solution" than a problem? If you want to write an app that runs across different platforms, you have to put an abstraction layer in somewhere. If it's inside your app, it's a maintenance headache. If it's outside, then that becomes the platform you're targeting.
> 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.
Yeah, and didn't Apple even work with Khronos (and other vendors) to come up with a "next gen OpenGL"? But after literally years of nothing materializing, they just kind of said, "Forget it" and made the API they needed? At least I recall something like that happening. I thought they gave it an honest try but it didn't get any momentum.
The ecosystem is fragmented for historical reasons. Wikipedia pages of each API explain the historical context of each.
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.
> OpenGL looks like it has fallen victim to design-by-committee
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.
Maybe it's just me but when a write-up about a porting process keeps repeating "it was a breeze", "the results are great", and maintenance is "effortless" and not a single negative point or writing about something going wrong - it feels fishy to me. Maybe their API abstraction is really good, which could explain it - but there's hardly any words spent on that (and if that's the case, THAT would be absolutely worth writing about, and not a specific API itself).
Yeah. Stay in this industry long enough and you’ll realize that there’s no silver bullet API that is just magic and perfect. It’s good to be suspicious.
>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?
Using Metal IS a breeze. Three years ago I had no experience whatsoever with GPU computing. I learnt it through Metal, and it was a great experience with very few hiccups.
You'll have to use Metal to understand why it is praised so much (by those who actually used it at least). It really is a joy to use, at least compared to Vulkan or OpenGL. It feels a lot like D3D11, which is also (mostly) a very well-designed 3D API, and Metal fixed the few warts of D3D11 and modernized its concepts (like adding render passes, pipeline state objects and command buffers). And D3D11 backend code is very easy to "port" to Metal, so a new Metal backend fits well under existing wrapper APIs which already had to deal with D3D11 anyway.
I will say MSL and associated tooling is horrendous. I like MSL as a language but it pays a heavy price for "being different", it's woefully underspec'd, even compared to HLSL, and the tooling is pretty miserable. You couldn't even run the Metal compiler on Windows until very recently.
Agreed, C++ for the shading language was a very strange choice, I'd have preferred regular C with language extensions (I guess we're lucky it's not Objective-C or Swift, really dodged a bullet there). I don't write Metal shader code though, instead I write GLSL and cross-compile to MSL via SPIRVTool + SPIRVCross (HLSL to MSL would work too, but I don't know if that's as well supported as GLSL to MSL).
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.
They already had backends for desktop, mobile, and console APIs. I imagine them not having to do anything major to support the new API in their engine helped. That being said, Metal is nice to use form a tooling perspective too.
> 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.
>> One other important aspect is Metal implementation is much simpler than a Vulkan one – more on that later – so in some sense I’d prefer a Metal -> Vulkan wrapper instead of a Vulkan -> Metal.
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?
You are not in their audience, because you're not a (pre-)teen. It's a mobile 3D game which also serves as a kind of platform and hub for accessing user-created mini-games. If you think Second Life for kids, you're not too far off the mark. The recent hit Fall Guys bears more than a passing resemblance to a lot of Roblok's more popular mini-games.
I suspect that Roblox enjoys being a product that gets new users by word-of-mouth, so they can slack on the web presence. And Roblox is a game that lets you also build levels, including surprisingly advanced programming, for other users to play. It's very popular with a constantly refreshing demographic of 13-20-somethings.
I was with you in not understanding what they do, however, it seems there are a lot of people who do [0].
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.
87 comments
[ 3.4 ms ] story [ 138 ms ] threadGNU/Linux just doesn't provide revenue to make it worthwhile.
https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...
Maybe that won't be the case for all games, but low market share does not tell you much. Remember that the platform-specific cost - even with rewriting the renderer - of a game will in most cases be dwarfed by design, voice acting, localisation, marketing, etc which all are already covered by the existing target platforms.
Your assertion is also not well defined since "worthwile" could mean profitable (which will be the case for third-party porting companies) or more profitable than other development efforts.
Then, up to the current day: "Roblox anti-cheat started detecting Wine and would force the game to quit."
More details here: https://roblox.fandom.com/wiki/Roblox_on_Linux
Not many people outside of the ecosystem are aware but ROBLOX was actually really late to the concept of dividing client and server responsibilities. It used to be that one client could actually propagate changes out to all the others; therefore if you could manipulate memory you could arbitrarily execute code (within the sandbox) on all other players. There used to be popular scripts like Person299's admin commands that could be injected into any server and allow the exploiter the ability to run chat commands like "kill/<user>" or "ban/<user>" (self explanatory). Only a few years ago did they introduce RemoteEvents and ServerScriptService which finally allowed developers to ensure some code could only execute server side, and properties like FilteringEnabled which blocked clients from propagating local game changes out to the server and everyone else. This broke hundreds of thousands of old games, which was probably why they held off, but nowadays any new games are using these new features to prevent easy exploitation like in the past.
My guess is they have nothing against Linux now, because they have implemented proper security, but the only thing stopping them are the technical challenges, and there are not enough people in their target demographic who use Linux to make porting worthwhile.
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.
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.
https://vulkan.gpuinfo.org/listextensions.php
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.
https://developer.android.com/about/dashboards#Vulkan
https://vulkan.gpuinfo.org/listdevices.php?platform=android
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.
> 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.
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?
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...