Vulkan/OpenGL Next Generation Initiative: unified API for mobile and non-mobile devices.

[Xmas]

Why bad for Google? They build on a substantial amount of work (API specification, driver development) and get a high-performance, low-level graphics API that will be usable on existing hardware. What alternative would be any better?

In practice I don't think the feature set definitions will turn out significantly different from the Android Extension Pack idea.

 

[willardjuice]

In my opinion they have a big enough market that they don't need to cede any power/control to Khronos. IHVs should be catering to their will and not the other way around. I understand in practice it's not quite like that but why does Google need Khronos at all? They have enough money and talent to develop their own 3D API which in turn could allow for better integration with Android. To me it's like asking why does Microsoft have DirectX or why does Apple have Metal. It allows a company to have better control of their platform.

 

[Scott_Arm]

I don't really see why Vulkan would not integrate well with Android. The whole point of the API is that it's low level. You get the side benefit that the API will also be available on Linux, Windows and probably any Unix variant. Apple is probably the only company that will actually block it in the PC space. Nvidia, AMD and Intel will most likely support it in Windows even with Directx12.

 

[Novum]

In my opinion they have a big enough market that they don't need to cede any power/control to Khronos. IHVs should be catering to their will and not the other way around. I understand in practice it's not quite like that but why does Google need Khronos at all? They have enough money and talent to develop their own 3D API which in turn could allow for better integration with Android. To me it's like asking why does Microsoft have DirectX or why does Apple have Metal. It allows a company to have better control of their platform.

Oh god, please not another API. Metal is infuriating enough already.

There was zero reason to adopt it vs. Vulkan besides NIH syndrome.

 

[silent_guy]

There was zero reason to adopt it vs. Vulkan besides NIH syndrome.

Vulkan probably didn't exist when work on Metal started. And people are using Metal now in shipping apps. Vulkan still hasn't been released publically AFAIK. (And Mantle was never available open either.)

 

[lanek]

Vulkan vs OpenGL ES, gnomes Horde demo running on PowerVR Rogue GPUs.

This new demo is called Gnome Horde and runs under Android on the Intel-based Nexus Player, a consumer device integrating a PowerVR G6430 GPU; it uses the latest prototype Vulkan API driver for PowerVR GPUs (final performance may differ).

More informations:
http://blog.imgtec.com/powervr/gnomes-per-second-in-vulkan-and-opengl-es

 

[Xmas]

In my opinion they have a big enough market that they don't need to cede any power/control to Khronos. IHVs should be catering to their will and not the other way around. I understand in practice it's not quite like that but why does Google need Khronos at all? They have enough money and talent to develop their own 3D API which in turn could allow for better integration with Android. To me it's like asking why does Microsoft have DirectX or why does Apple have Metal. It allows a company to have better control of their platform.

Due to the limited hardware base Apple can take full control of the driver stack. Google doesn't have that luxury, and if they need to work with several IHVs anyway, why not do it through Khronos? After all, there's a group already committed to creating a high performance graphics API using the joint expertise not only from IHVs but game/engine developers and other companies as well.

And as the feature set definition issue shows, they retain control over important decisions. Khronos has always been open enough, and Google is important enough for Vulkan adoption, that if there was a serious problem with integrating Vulkan with Android, Google would get their way.

Vulkan probably didn't exist when work on Metal started. And people are using Metal now in shipping apps. Vulkan still hasn't been released publically AFAIK. (And Mantle was never available open either.)

Yes, work on Metal must have started a lot earlier. Also, Metal isn't quite as low level as Vulkan and thus easier to use (imo Metal is easier than OpenGL ES).

 

[willardjuice]

Due to the limited hardware base Apple can take full control of the driver stack. Google doesn't have that luxury, and if they need to work with several IHVs anyway, why not do it through Khronos? After all, there's a group already committed to creating a high performance graphics API using the joint expertise not only from IHVs but game/engine developers and other companies as well.

And as the feature set definition issue shows, they retain control over important decisions. Khronos has always been open enough, and Google is important enough for Vulkan adoption, that if there was a serious problem with integrating Vulkan with Android, Google would get their way.

That's not true, metal is heading to desktop so I assume they have to worry about at least ImgTec, Intel, AMD, and Nvidia. It really is no different.

I guess my question to you is do you think Google could come up with an API that's as "good" as Vulkan? If yes, it's not clear to me why Vulkan is so advantageous to Google. Even if they retain significant power, why bother? I don't see why Google can't have its cake and eat it too (having complete control over a good 3D API).

 

[Xmas]

That's not true, metal is heading to desktop so I assume they have to worry about at least ImgTec, Intel, AMD, and Nvidia. It really is no different.

Apple releases a limited number of Mac models per year. It's a limited hardware base compared to the variety of Android devices, and Apple is the customer directly buying the GPUs and designing the whole system. Google isn't. Google doesn't fully control Android, either.

I guess my question to you is do you think Google could come up with an API that's as "good" as Vulkan? If yes, it's not clear to me why Vulkan is so advantageous to Google. Even if they retain significant power, why bother? I don't see why Google can't have its cake and eat it too (having complete control over a good 3D API).

That would depend on what you define as "good". More efficient? I doubt it. More convenient? Possibly. More features? Not if they require new hardware.

I don't see what Google would really gain from "complete control" that would make up for the investment required and the detrimental effects. Cutting themselves off from direct PC ports as well as from drivers already in development doesn't help them, and developers wouldn't applaud them for introducing yet another API, either.

Apple moved first with Metal. Google would have had to release their API earlier to reap the same benefits.

 

[tuna]

Do we know when Metal will be available for MacOS and what Macs will support it?

 

[pTmdfx]

Do we know when Metal will be available for MacOS and what Macs will support it?

It is available now in OS X El Captain Beta, and is supported by all GPUs from the three vendors in all Macs introduced since 2012 per the WWDC session.

 

[liolio]

With DirectX 12 landing just now that initiative is mostly see as a mobile affair though I wonder if it could go further than that. It could be seen as convenient for one API to cover most of the successful operating system from Windows passing by SteamOS and Linux ending up on Android.

 

[lanek]

I think the same, who will port DX or console games, or even Vulkan games to metal for desktop ( imac ? ) .. I mean, if Apple dont put billions of dollars for make it happend and succeed to make think to the studios, that the next gaming platform is OSX, i really dont see it happend .. ( and we know all that they could put way much money for it, but that dont seems to be their plan )

Most Apple laptop, desktop users are using Bootcamp windows, the other play on Indie games OpenGL from Steam ... Outside porting some iOS Iphone/ Ipad games to iMac using Metal.. i really dont see what will be the interest for it ..

Well for said it otherwise: I dont see Metal as a factor that could change the situation....

What is the market part on gaming for OSX ? single digit number ?

 

[willardjuice]

Apple releases a limited number of Mac models per year. It's a limited hardware base compared to the variety of Android devices, and Apple is the customer directly buying the GPUs and designing the whole system. Google isn't. Google doesn't fully control Android, either.

The underlining hardware architectures are still very different even if there aren't as many as Android. Metal still has to be as accommodating to various GPU architectures just as much as Vulkan/DirectX have to.

That would depend on what you define as "good". More efficient? I doubt it. More convenient? Possibly. More features? Not if they require new hardware.

I don't see what Google would really gain from "complete control" that would make up for the investment required and the detrimental effects. Cutting themselves off from direct PC ports as well as from drivers already in development doesn't help them, and developers wouldn't applaud them for introducing yet another API, either.

Apple moved first with Metal. Google would have had to release their API earlier to reap the same benefits.

I didn't say better, I said as good as. The aim wouldn't be to "one up" Vulkan, but merely match it. So could Google obtain similar efficiency and feature set? I think so. Could they make it more convenient/better integrated for Android developers (debugging, tools, robustness, etc)? I think a strong possibility!

With respect to what google would gain is being able to have the final say on the direction of the API. You might say they already have this power by being able to set "feature levels" for Vulkan on their platform, but it's not really the same. They can essentially only pick and choose features that IHVs present them. IHVs are still largely driving the API. And maybe in practice Android's priorities will generally align with the IHVs priorities. I suspect though there will be situations where Google really wants X, but IHVs deliver Y. Perhaps Y is close enough to X that's it's passable/workable, but if they controlled the API they could demand X (and probably get it).

As for providing (yet) another API, if you're already targeting Metal, DirectX, Vulkan, what's one more (and in this situation, depending on how well steamos does developers may not even bother with Vulkan)? Moreover, if you're using middle-ware (which mostly everyone does), I don't think you even notice.

 

[3dcgi]

They can essentially only pick and choose features that IHVs present them. IHVs are still largely driving the API. And maybe in practice Android's priorities will generally align with the IHVs priorities. I suspect though there will be situations where Google really wants X, but IHVs deliver Y. Perhaps Y is close enough to X that's it's passable/workable, but if they controlled the API they could demand X (and probably get it).

If Google pushes for a feature you can be sure IHVs will listen. Of course they'd have more control of their own API, but it doesn't matter what Google wants if they can't persuade some IHVs it's a good idea.

 

[Xmas]

The underlining hardware architectures are still very different even if there aren't as many as Android. Metal still has to be as accommodating to various GPU architectures just as much as Vulkan/DirectX have to.

Being more accomodating means taking less control, though.

I didn't say better, I said as good as. The aim wouldn't be to "one up" Vulkan, but merely match it. So could Google obtain similar efficiency and feature set? I think so. Could they make it more convenient/better integrated for Android developers (debugging, tools, robustness, etc)? I think a strong possibility!

Could you point out examples in Google's track record that justify expecting a "strong" possibility here? There are nice dev and debugging tools for OpenGL ES. They're not by Google.

IHVs are still largely driving the API.

And that will continue, for obvious reasons.

 

[willardjuice]

Being more accomodating means taking less control, though.

Sure, various degrees of control exist. And while I actually think Apple might have the market share to justify developing their own gpu, that is for another discussion. It is not practical for Google to be the sole gpu provider for Android, but it is practical for Google to be the sole api provider.

Could you point out examples in Google's track record that justify expecting a "strong" possibility here? There are nice dev and debugging tools for OpenGL ES. They're not by Google.

An excellent point that I agree with. When reflecting about my experiences with Google, excellent documentation, tool support, and robustness do not come to mind. Having said that, I don't view Khronos any better in this area. I don't think Khronos has done a good job with robustness (weak conformance tests lead to different behavior across different drivers/ihvs), standard debugging/performance tools, and maintaining a clean api (e.g. core vs compatibility was a bad idea). And it's not just OpenGL; I have almost the exact same feelings about OpenCL too. So while I agree Google is no slam dunk for making developers' lives easier, I don't believe they'll make the status quo any worse.

At any rate, I could ramble on about Khronos forever. Your use case though is exactly what my "dream world" would hope to solve. Essential tools should be as tightly integrated as possible. I think that goal is more likely to be achieved if Google controlled the graphics api. Being able to set and align timelines between departments, having different departments talk directly to each other, and being able to release a single fully featured product are all very advantageous. Often those advantages will lead to a better experience.

And that will continue, for obvious reasons.

I think this ties in pretty well with my next question, what does Khronos have to offer Google? Experience and knowledge in 3D graphics? I agree that they are quite skilled in that area but I'm not convinced that's enough. I really do believe Google could produce an api that's technically analogous to Vulkan. And I believe most of Khronos's shortcomings can be attributed to politics. Politics obviously wouldn't go away with Google in charge (see DirectX), but they would be in a better position to "control it". And just to be clear, I'm not suggesting Google should develop this api in isolation without any IHV input. I just think they are unnecessarily ceding power.

Of course they'd have more control of their own API, but it doesn't matter what Google wants if they can't persuade some IHVs it's a good idea.

Very true, but I'd argue as long as Google wasn't being completely insane, IHVs would do it.

 

[Alessio1989]

Let's prepare to tons of exotic extensions, aka extension hell 2.0...

 

[Xmas]

At any rate, I could ramble on about Khronos forever. Your use case though is exactly what my "dream world" would hope to solve. Essential tools should be as tightly integrated as possible. I think that goal is more likely to be achieved if Google controlled the graphics api. Being able to set and align timelines between departments, having different departments talk directly to each other, and being able to release a single fully featured product are all very advantageous. Often those advantages will lead to a better experience.

I'd like to see a concrete example of what Google could really do better if they controlled the graphics API compared to what they can do now.

I think this ties in pretty well with my next question, what does Khronos have to offer Google?

A two year head start. A significant amount of work saved. An ecosystem that developers are already committing to. Portability with Windows and Linux and along with that drivers that will be tested by more diverse software.

 

[willardjuice]

I'd like to see a concrete example of what Google could really do better if they controlled the graphics API compared to what they can do now.

Like I said previously, integration. We'll even take your example. GPU profiling is quite easy for me on Windows Phone. Simply use Visual Studio without having to install/download/integrate anything. This isn't true for Android or iOS. Xcode's profiler only gives a high level overview and android studio is essentially useless for this use case. I have to download external software from ihvs if I want more detailed information. For android that means I have to maintain like 4+ sets of the same tool if I want to cover all my bases.

Now you may claim that this has nothing to do with opengl. Microsoft just happens to make a superior ide that offers great support for directx apps. I'll admit there's some truth to that, but it's kind of awesome that with Visual Studio I can often profile an issue without even needing a physical device (the builtin virtualized images run great and are pretty accurate representations). No extra downloads, no extra integration of 3rd party software/drivers/images, no extra hassle. New changes to directx? You can expect great Visual Studio support day one. That is what I want from iOS and Android. Perhaps the same level of integration could be achieved with opengl/vulkan, but it would seem other platform holders are struggling to achieve Microsoft's level of integration.

A two year head start. A significant amount of work saved. An ecosystem that developers are already committing to. Portability with Windows and Linux and along with that drivers that will be tested by more diverse software.

Developers are only committing to Vulkan because Android picked Vulkan (developers wouldn't commit to an api that's only used on SteamOS). As for starting later, I suspect Android won't collapse because Google had to use ogl es 3.x + extensions for an extra year. Finally, Android already has portability with Linux and Windows using ogl es, but that certainly has not helped driver quality!

I'll give you it's more work for Google, but they have the talent and resources to make that a nonissue.