The description actually says that it borrows heavily from radeonsi (AMD's OpenGL implementation), so it means the technique is already used.

From my understanding, the main goal here was for Chrome to handle WebGL on Windows using Direct3D because OpenGL driver support on Windows is not good. But it's aiming to be a universal graphics shim for many platforms.

Chrome, Firefox, Qt, and Krita all use it.

https://en.wikipedia.org/wiki/ANGLE_(software)

Virtualized was always it's end game and where well used APIs go to die.

At this point, OpenGL is more important in being fully compatible than in being fully performant. And none of the graphics card guys care about that.

Vulkan is a much easier standard for GPU manufactures to get right. If we could convert all the higher level APIs (such as DirectX and OpenGL) to it, then we could get consistent behavior across a wide range of vendors.

At least MS joined OpenXR effort in contrast instead of pushing their own NIH.

However this did happen for DirectX as an option. There are dxvk (dx9-11) and vkd3d (dx12) which translate DirectX to Vulkan.

But you are right, translating DX12 to Vulkan is easier than translating DX9 or DX11 to it.

You can say that the lock-in is "unnecessary", but these things happen for complicated reasons. Fixing the lock-in isn't just a switch you can flip.

We can dream about a world in which Vulkan came out two years earlier than it did. In the world we live in, Microsoft wanted migration paths for existing DirectX users, and Apple wanted people to take iOS seriously as a platform for developing games. Waiting for OpenGL Next to materialize seemed like a losing game at the time.

When Metal and DirectX 12 were under developement, they weren't competing with Vulkan... they were competing with a set of techniques for OpenGL called AZDO, and it seemed that OpenGL was lagging further and further behind its alternatives with every passing year.

That, and Mantle ran on desktop GPUs. Metal was initially targeted at where the gap between API and hardware was the largest, which was mobile GPUs. At least with desktop OpenGL you had the "AZDO" techniques, but on mobile, you had OpenGL ES. Mobile GPUs aren't just smaller versions of desktop GPUs, they use radically different ways of drawing on the screen (although this gap is narrowing, as desktop GPUs are becoming more like mobile GPUs... basically, expect to see tiled rendering on desktops in the future).

If you were living in 2013, would you say, "Gee, I hope someone else forms a committee to adapt Mantle into something which, in the future, maybe in 2016, I could theoretically use?" Or is it faster to make your own API? Or perhaps you like working with cross-platform steering committees that were, at the time, falling behind and failing to address problems with their APIs?

You'd be a moron to put all your hopes and dreams in a committee / industry working group delivering something to fix the problems with your platform. Sending more engineers to a committee that's already moving slowly will just slow things down further. So these companies, while sitting on the committee, worked on alternatives and had backup strategies.

Those strategies turned into Metal and DirectX 12, and the committee realized, "Oh, if we don't fix the problems with OpenGL, it will become completely irrelevant." So, in response to this new competition, the OpenGL steering committee started working on OpenGL Next, which later became Vulkan, and about two years later, got released.

It's amazing what a little competition can do.

MS execs actually quite explicitly verbalized the idea of it in the past:

https://en.wikipedia.org/wiki/Criticism_of_Microsoft#Vendor_...

This applies here very well too.

For huge monsters like MS and Apple the argument of "we already had this, so we can't join the collaborative effort" doesn't really make sense. They very well can join it and scrap their NIH in the process. They even did that in the past, when their NIH didn't manage to cement itself (anyone remembers ActiveX today?).

Plus, in this case the idea of common low level GPU API existed before Vulkan was out, namely in Mantle. AMD proposed to collaborate on it to everyone. Which indeed resulted in Vulkan eventually. So they totally could back that instead of pushing their own stuff (that's besides the fact that MS literally used same Mantle for making DX12). So I don't see them being random bystanders here, but rather someone who deliberately refused to collaborate.

But the argument "we already have this, so why spend money on that other thing" makes sense, especially if they profit from it and don't pay the bill for it (the companies of non MS devs which have to handle that mess do).

It sounds like there’s a misunderstanding here about what Mantle was. Mantle was not a collaborative effort that different vendors could join in on. Mantle was AMD’s pet project. AMD saying “Hey, why doesn’t everyone use Mantle?” was a non-starter, because as it was, Mantle reflected the architecture of current AMD GPUs. Nvidia or other GPUs would be at a massive disadvantage trying to implement a low-level API that just didn’t fit their architecture right.

However, there was indeed a collaborative effort that Apple and Microsoft were a part of. It was the OpenGL steering committee. In 2013, the steering committee was not busy making Vulkan reality. They were instead trying to fix the problems with OpenGL. The more serious problems—the reasons why Vulkan exists—never actually got fixed.

This was not a massive surprise. The issues were complicated, and most people thought that OpenGL was falling behind DirectX further each year.

> Which indeed resulted in Vulkan eventually.

Yeah, in 2016. By that point, developers had been using Metal for almost TWO YEARS and shipping games with it. Some of those games had shipped sequels or spinoffs.

The project which eventually resulted in Vulkan, called “OpenGL Next,” hadn’t even BEGUN by the time Metal was released to developers. DirectX 12, I assume, was under heavy development at the time.

The story I’ve heard was that the release of Metal was a real kick in the pants for what became the Vulkan effort. If you were to go back in time and rewrite history, and wipe Metal off the face of the planet, who knows what would happen to Vulkan? History is messy.

Not out of the blue. AMD wanted that collaboration and got different parties interested. It took a while to get needed groups together and then develop it until it was out in 2016 (not by AMD alone at that time obviously). Where were Apple and MS when this was happening between 2013 and 2016?

Your argument about non-starter is clearly incorrect, since Vulkan did result from it all. So it was possible, but took time. Khronos was already managing OpenGL so they fit the role of overseeing it. Someone else could do it too may be, but no one else stepped up (including same MS and Apple who easily could if they thought they could do better).

> The story I’ve heard was that the release of Metal was a real kick in the pants for what became the Vulkan effort.

Apple very well knew there is an interest in the common API. Where were they? Making their Apple only NIH of course. Collaboration takes more time, sure. Did Apple join? No. They never cared.

I’m talking about what people perceived in 2013. You are welcome to judge people’s decisions, using your knowledge of future events, if that’s what you really want to do.

> Where were Apple and MS when this was happening between 2013 and 2016?

Apple and MS were thinking, correctly, “I bet I can deliver a working API before this committee with representatives from a dozen different companies with competing interests can get off their butts and even figure out what they’re going to name the project.”

Those years were years of massive, massive growth for the App Store and the iOS ecosystem. If you could fix major problems that your customers a couple years faster, during a time when sales were growing 50% year over year, you’d want to do it yourself too. There’s only so many engineers at your company with the patience and drive to sit on committees.

> Khronos was already managing OpenGL so they fit the role of overseeing it.

It was called “OpenGL Next”, not Vulkan, at the time. Well, not when Metal was released, since it didn’t even exist when Metal was released.

If some thought it was a non starter, AMD thought it's a good idea that would benefit everyone. Who ended up being right? Not the skeptics, that was my point. The idea was correct and those who backed it helped move it forward. But Apple and MS did the opposite of helping.

> Apple and MS were thinking, correctly, “I bet I can deliver a working API before this committee with representatives from a dozen different companies

That was exactly my point. "Correctly" as in "let's push lock-in to hook developers on this and make life harder for them if they want to support multiple platforms". That's the approach MS and Apple were using for years. But it's not right if you care about making things better for the industry, because it's only slowing progress down. I really see no justification for using development tools like APIs for market control, it's a crooked practice.

I think it's pretty absurd to expect Apple and MS to suspend work on graphics APIs until the committee gets around to figure things out. Especially when the committee is already falling behind, and fixing these issues isn't even on the agenda yet. I just don't understand how someone could blame Apple and Microsoft for developing their own APIs, and then let the OpenGL committee off the hook for completely failing to fix the outstanding issues in the OpenGL API in a timely fashion.

Again... and it seems people keep forgetting this part... Metal was released to developers before the project that eventually became Vulkan even started. At the time Metal was released, Vulkan DID NOT EXIST, not even by a different name.

"I know, let's not work on this important project, and hand it off to an industry working group." Said no engineer, ever.

When a committee fails to produce a working standard, alternatives appear. This is how WHATWG appeared.

> That was exactly my point. "Correctly" as in "let's push lock-in to hook developers on this and make life harder for them if they want to support multiple platforms".

That's just begging the question. If you're going to argue, at least make an argument.

And I already brought examples above where MS did the right thing, like with OpenXR.

Nobody believes that Apple could just snap their fingers and start supporting Vulkan today. It just seems too optimistic to me, and these kinds sweeping changes require a lot of coordination. You introduce the Vulkan API internally (which takes time). Then you start with the various low-level frameworks, like Cocoa. With that base in place, you can write transpilers and migration tools to move from Metal shaders to something that compiles to SPIR-V. Perhaps a new backend to an existing compiler? From there, you work up the stack, applying the migration tools. Core Image is a big one. Undoubtedly, you'd have to back out the changes to some frameworks and try again. At the end, you're working on end-user applications like Final Cut.

You'll also want to build a framework on top of Vulkan to manage resources a bit. Metal has an Objective-C interface and works with ARC, Vulkan is all manual.

OpenXR is a lot smaller than Vulkan, and affects a much smaller number of applications. Not really a suitable comparison.

I would love for everything to use Vulkan, but I also understand the reasons why things didn't turn out that way, and why this is a problem that's not easy to solve.

They benefit from lock-in and it's the main reason they didn't fix the situation yet.

I suppose they could’ve dropped Metal right away after Vulkan became usable, but developers tend to get grouchy when APIs change out from under them that frequently.

That said there’s no reason they couldn’t support Vulkan alongside Metal, likely with one being a first-party adapter layer for the other.

Apple didn't care about developers when they let OpenGL rot there, so I don't think it was ever a consideration for them. Their idea for developers is "we know better than you what's good for you".

> That said there’s no reason they couldn’t support Vulkan alongside Metal

Exactly, and the real reason is - they want their API to work as lock-in rather than allow developers to have options.

Do you believe Apple are somehow resource strained in not being able to do that many times over?

> Do you believe Apple are somehow resource strained?

Oh if only you knew... Yes we are very engineering constrained at those companies. Money doesn't replace the fact that there isn't enough people around who have the skills and are willing to work there at any price.

And on top of that there's the opportunity costs of having them work on this instead of something else...

When MoltenVK exists as a compatible Vulkan impl on top of Metal already, it's very hard to justify this.

I don't believe it. They could easily expand their hiring if they were sufficiently motivated. There is a combination of mismatched incentives at the team level and inefficient interviewing processes and requirements.

It's often in the interest of employees to be inefficient in this regard.

Actually, yes.

Let's say Apple has infinite dollars, which is true enough. Therefore they can afford to hire the 100 top graphics API developers in the world and put them to work on Metal.

Now they decide they want to support Vulkan. But they can't go out and buy the 100 top graphics API developers anymore; those people are already working on Metal. They could get the next top 100 developers, but those people, as a rule, won't be quite as good as the people they already have working on Metal.

Now I guess they could mix up the teams so that every other person in the top 100 working on Metal gets folded into the Vulkan team and vice versa and have two teams of roughly equal skill working on each. But then they don't have a super-team of the top 100 devs working on one project anymore.

Now consider that Apple doesn't quite have infinite dollars, and that some top-level developers won't want to move to Cupertino or whatever else Apple may ask of them, and how do you even judge who the top 100 graphics API developers in the world are?

Maybe, even for Apple, the best approach is to get the best developers you can hope to buy and keep all their attention on one project rather than splitting it up.

All that said, yes, the ideal is that there would be some successor to OpenGL which enjoys the cross-platform support that it had. But as stated elsewhere in this thread, Metal was released years before Vulkan, so perhaps the onus for that is on those who have developed adopted Vulkan instead of reaching out to Apple to expand Metal to other platforms (if that would have been acceptable; who knows, maybe they tried but Apple didn't allow it).

And about your last point - Apple is really the worst candidate to ask for something to collaborate on.

This would have been a best-case scenario for everyone, basically. I'm sure many people would have been very happy to use Metal on other platforms, and in exchange Apple devices would actually have support from most modern videogames. However, that ship has probably sailed now, and WebGPU is pretty much "Metal over <X>" where X = Vulkan/Dx11/Dx12/Metal/GLES/WebGL.

The idea isn't to support multiple APIs, but to translate Vulkan into your API since it's a well-documented standard. The main issue would be API incompatibilities, which is the main place Apple could add value.

It should have been the opposite way - Metal should have been implemented on top of Vulkan.

It depends what you mean by consistent. Vulkan is a lower-level API and has many things specific to particular kinds of hardware, even if they're ostensibly supported everywhere.

For example, it is easy for a Vulkan application that has only been tested on desktop GPUs to have serious performance issues and graphical artifacts when run on a mobile GPU. With OpenGL it would at least render correctly, and it might even be performant.

It's an API where you have to be explicit about everything, and therefore you have to be very careful what you wish for. I'm a bit worried about how long-term preservation of Vulkan games will work out.

If there is anything to worry about, it would be how Vulkan/Direct3D 12 limit future GPU architectures.

That said I certainly hope Zink becomes a suitable OpenGL implementation since it would simplify development of open source video drivers. i.e. just implement vulkan and you get OpenGL for free.

1. https://www.phoronix.com/scan.php?page=news_item&px=Zink-Sub...

9 fps is not a video game, that’s a slide show. And indeed, playing tomb raider where you want to make jumps and stuff, I would not play that on 9 fps ever.