That doc says:
"It[WebGL] was based on OpenGL ES, a cross-platform API for graphics targeted at embedded systems. This was the right starting place, because it made it possible to implement the same API in all browsers easily, especially since most browser engines were running on systems that had support for OpenGL."
And then it says later this:
"The major platform technologies in this space are Direct3D 12 from Microsoft, Metal from Apple, and Vulkan from the Khronos Group. While these technologies have similar design concepts, unfortunately none are available across all platforms."
And one imagines you could put up a big chart and have all the platforms as the columns and each technology as the row, and show all of the gaps. But the consensus is that Vulkan would show up on all the platforms except Apple's. So one might ask "well if you put Vulkan on your platforms, then you would be back to the WebGL situation where you had stuff that ran on all platforms and you could work on a Web API to that code.
So "optically" which is to say, to a casual observer, it seems like Apple is saying everyone put this new thing on your platform as this web api we're working on will talk to it.
I understand that you just want the best experience possible given the advances that have been made in GPUs over the last decade.
In which case won't browser makers target directx anyway, as they have with webgl?
Adding another standard to the mix just seems to be compounding the problem to me.
Also, if you compare the sample code in the post with a sample of Vulkan code, I think it will be clear that a literal "WebVulkan" is a road best not traveled.
Are you sure? Don't forget about WebAssembly… Just as Emscripten currently exposes the original OpenGL ES API as a wrapper for WebGL, for the sake of porting existing C/C++ code that uses it, in the future there will be a desire to port Vulkan renderers to the web. That will be easier if the browser API is based on Vulkan; otherwise you'll end up with a shim on top of a shim. Also, the same arguments about developer familiarity that led to WebGL being designed as it is could apply just as well to Vulkan - albeit somewhat more speculatively, given Vulkan's newness.
The whole point of Vulkan/Metal/DX12 is that since GPUs have their own MMUs it's totally OK to seg fault your own process from the GPU side. You just crash your process, but you don't take down the system.
That line of thinking doesn't really translate well to a JS API.
Even if that weren't the case, for a standard to be a success then pragmatism is more useful than idealism. Telling the maintainers of most of the worlds desktops to fall in line isn't really practical.
https://www.lunarg.com/faqs/microsoft-support-vulkan/
"Microsoft has not expressed intent to support Vulkan."
Also "Vulkan is available on all versions of Windows that are on DirectX 12, so there is potentially some value to the developer community to having a single API that spans multiple Windows versions."
Vulkan is fully supported on Windows with semi-recent GPUs (e.g. its supported by Nvidia with Geforce 6xx - released in 2012!) by all vendors.
The article is only saying that MS defers what API is supported to GPU manufacturers. Its not supported by Xbox and Windows Phones, but Xbox is a very different market and no one cares about Windows Phone.
https://en.wikipedia.org/wiki/Vulkan_(API)#Compatibility
In addition to Nvidia and AMD, Intel, Imagination Technologies, Qualcomm (!!!), and ARM support Vulkan. Hardware wise, there is absolutely no problem whatsoever.
The current Plan Of Record is that Intel® is not supporting Vulkan on Windows drivers. The drivers that were made available on Developer.com are intended for Vulkan developers.
So, it is expected that some Vulkan drivers may not work for end users.
Intel GPUs power at least 50% of Windows PCs, and I'd guess the number is closer to 70%. Unless this situation changes, Vulkan is not the single cross-platform answer.
"Vulkan support right now is for 6th Generation and newer products and we are targeting developers not consumers. Thus why the releases are beta and are listed in the Game Developer Zone and not anywhere else."
is full Vulkan support planned for consumers: "To my knowledge yes, but I do not know when and would not want to hazard a guess"
Windows 10 is at around 25% currently.
https://en.wikipedia.org/wiki/List_of_games_with_Vulkan_supp...
Versus these ones:
https://en.wikipedia.org/wiki/List_of_games_with_DirectX_12_...
The fact that game studios decide to use one API or another is no factor in evaluating API availability. (Also note how many DX12 games not published by Microsoft are DX12 exclusives - that says something about Microsoft motives, but not about API qualities).
When given the option, professional game developers choose the one that better helps them achieving their goals.
All of them used by most desktop applications on Windows, including image, video and 3D editing applications.
CAD, GIS, or other applications that need to use 3D explicitly, on the other hand.... Basically only Autodesk ventured there, with 3ds Max and AutoCAD (since 2015).
For example, most of our customers prefer MicroStation, for some reason (no, we are not Bentley shop ;).
And actually, by the numbers there are more titles on Vulkan than there are titles not released by Microsoft on D3D12.
NVIDIA and ATI are hardly "all" vendors I care about. I'm personally not interested in the big desktop PCs. YMMV of course. But I'm personally very against "winner takes it all" and I'd really like some more universal web API, especially one that consumes less power on the iOS devices.
Edit: the answer to the question below by sydd: I'm honestly and pragmatically interested in iOS and Apple devices, not Microsoft, and not the Google-controlled ones. All these comments are about Apple's proposal for a standard for Web. I'm with the ones having the smaller market share here. I'm still sad Opera Presto is no more. I consider such "smaller" players extremely important for the web.
Also the majority of all the new OS APIs are UWP only.
Vulkan: Its on most Windows PCs, most Linux PCs, on newer Android devices, and on the Nintendo Switch. Also there are rumours of the next PS going with Vulkan too.
DX12: most Windows PCs, XBox One.
Metal: iOS/OSX only.
So its clearly the future on the desktop market. Obviously it will take a few years for it to spread, since AAA game companies go for the proven solutions.
On mobile, we will see, I cant imagine Google adopting Metal or DX12, and Apple sadly seems to be sticking to their proprietary API.
The most Windows PCs have Intel cards, which only have a beta driver available.
The majority of AMD and NVidia owners with Vulkan support, are on Windows 10, which supports DX12 anyway.
Newer Android devices, means Android 7, which thanks to how update process works, a whooping 0.7% market share, composed of Google Pixel, Smasung S7 and LG v20.
Nintendo has added Vulkan support to Switch, but they are only testing waters, the actual API that allows to make full use of the available hardware is called NVN.
Sony, I really doubt it. The PS4 APIs, the successor of LibCGM is actually quite close to DX 12 and the PS 3 experience with OpenGL ES wasn't that great.
http://sandstormgames.ca/blog/tag/libgcm/
Vulkan is still catching up with DX12 for stuff like multi-GPU processing.
Linux PCs are just 2% on Steam, and drivers are kind of working, hardly a value proposition to make to most professional game studios.
The web GPU API and the lower-level API aren't "totally orthogonal" if you're using the Metal shader language in your web GPU API! You're trying get web authors to use (a part of) Metal! It's totally not orthogonal.
The shader language is partly independent of the API though, and we though the API was the interesting thing to prototype, more so than shaders.
The post was VERY clear that that was temporary while working on the other basics and a real decision would be made later.
Isn't this the way you're supposed to do open source? Post code early and often for comments?
It seems like a ridiculous requirement that to show a sketch of what they think a web API should look like for next generation 3-D graphics they should have to design an entire shader language that's different from the one they already have.
It's just a placeholder. They didn't even SHOW the language. They just referred to its name and said they were using that for expediency during the initial version of the document they were showing.
> should have to design an entire shader language that's different from the one they already have.
They don't need to design a new language - take existing open one and use it.
I think you're reading a lot of intention that isn't there into that placeholder.