Apple proposes new web 3D graphics API
webkit.org
webkit.org
So Apple, the only company not supporting Vulkan on their platforms, is complaining that there isn't a cross-platform solution?
Things worth noting: - We believe other browser vendors agree with us that the web API should work on all three of the major native APIs. - The web has security requirements which force us to go a bit higher-level than Vulkan anyway.
I understand your desire to have Vulkan on Apple platforms, but it's really a separate issue from the right target for WebGPU.
No, you're stating your own company's ambition.
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.
So, they ARE planning full Vulkan support on Intel iGPUs.
Is there any reason to believe that, unlike OpenGL, Vulkan drivers will be sufficiently widespread for browser vendors to use it on Windows?
Besides, "purposefully cripple" is inaccurate. They just put more effort into Direct3D because there's no reason to support OpenGL as fully.
Maybe it'll be different for Vulkan, but that would be a surprise.
Microsoft won't support Vulkan officially, and apps would have to install their own Vulkan drivers.
"DATE: March 11, 2016" "-NEW- Intel® Vulkan BETA 15.40.20.4404 Graphics Driver for Windows® 7/8.1/10 [15.40]"
> https://software.intel.com/en-us/blogs/2016/06/29/new-intel-...
"DATE: June 24 2016" "-NEW- Intel® Graphics Test Driver for Windows® 10 and Windows 7/8.1 [15.40.4473]"
https://software.intel.com/en-us/blogs/2016/06/23/intel-open...
"In his blog published on February 16, 2016, Imad Sousou shared that Intel was selected as one of the leading graphics platform suppliers with Vulkan* 1.0 drivers certified by the Khronos Group Consortium."
https://www.youtube.com/watch?v=bsOTVpepS44
"We are demoing Intel’s implementation of the API available on the latest hardware from Intel on 3 major operating systems: Windows, Linux and Android." Intel Engineer: "This really shows the industry is moving towards Vulkan."
https://www.khronos.org/conformance/adopters/conformant-prod...
Intel sure seems to have been making sure all of their chips are now Vulkan capable. All I can find for "they don't plan to" are what seems like rumors on one forum that are spawned by the current drivers being "unsupported" (but given that they are in beta, that makes sense to me: the storyline here is that they were provided for Vulkan developers to start testing their products and likely testing this driver). It really seems like Intel is at worst being "a little slow" to push Vulkan, but they are definitely not unsupportive.
In addition to what people have said about Intel, Qualcomm, ARM, and IMG are all behind Vulkan. Who else is making GPUs these days?
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.
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.
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.
https://www.lunarg.com/faqs/microsoft-support-vulkan/
"Microsoft has not expressed intent to support Vulkan."
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.
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.
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.
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.
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.
"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"
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.
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.
No, it's not a separate issue.
If Apple supported Vulcan, the simple act of proposing this new API as a standard would be laughed out of the room.
We can only speculate why Apple won't support Vulcan but I'm going to go with "Prefer a solution they designed themselves over one designed by other parties".
Just support Vulkan and let's abandon this silliness, shall we?
In addition, even on platforms where there are unofficial Vulkan drivers (such as Windows), it's likely the natively available API will still have more complete support and better performance.
So either way, we need a cross-platform graphics API.
Let's focus this discussion on improving the web platform, not fighting battles about the underlying system APIs.
So support Vulkan and then let's do the design work! The choice of underlying system API has effects on the design of the upper layers. Your refusal to support Vulkan is blocking progress.
But, that's assuming that it's not possible to write a wrapper on top of DX (for Xbone) that proves a Vulkan API. It's already been shown to be possible to do something similar, with MoltenVK.
The ball would be in Microsoft's court for this one.
Is this not how Vulkan on Windows works? Given how many OpenGL drivers were just shims over DirectX in the past, I wouldnt be surprised if the same course was charted there.
Go ahead and do that, then we can talk about going up the stack and judging the API you're proposing (and let's be honest, it's really Metal-for-Javascript).
Show some good will.
Your arguments are very reminiscent of the "Apple must adopt Flash" era. And as we've learn Apple was 100% right to dump that technology as it was simply a poor fit for mobile.
I've seen nothing about Vulkan that indicates it has some inherent qualities that make it suitable as a Javascript API.
And you are qualified to make this assertion because?
It would make an awesome JavaScript API. It is well defined, well supported, well documented low level API for graphics. It would easily be exposed within JavaScript.
Everyone I know who's ever coded using Vulkan has found it unpleasant, and even Khronos is considering a higher level API (more along the lines of Metal) because Vulkan is just too hard to use.
> I think you are wrong on that. Vulkan is a low-level native API, not a JavaScript API for the web. Lots of design work needs to be done.
Nothing you assert here is invalid. But, I think you've missed the main point, which is that people don't want an entirely new API, they want the same API across all platforms. Vulkan, exposed directly in JavaScript as much as is feasible (e.g. using an automatic API generation tool) would be awesome.
Simply look at how it is possible to cross-compile C/C++ to JavaScript. Now, add in support the Vulkan API. That would be incredible.
> In addition, even on platforms where there are unofficial Vulkan drivers (such as Windows), it's likely the natively available API will still have more complete support and better performance.
Actually that's not correct. Vulkan was explicitly designed to be an efficient and high-performance API. As it stands, even as a newborn API, it's the BEST available for 3D rendering on all platforms that support it, unofficial or not.
> So either way, we need a cross-platform graphics API. Let's focus this discussion on improving the web platform, not fighting battles about the underlying system APIs.
I think you are missing the point here again. As you say, we need a cross-platform API. But, by that logic, accepting that JavaScript is just another platform, we'd like the SAME API.
This seems to have worked out pretty well for innovation in the mobile OS market, no?
As a consumer, the mobile device market is a walled garden. Are apps compatible between platforms? Do you have control over your hardware? Can you choose what software you run on your own device?
But that number doesn't seem to be high enough to cause serious sales dips on iOS devices.
I'm not saying the number is 100% of consumers don't care. But it's also pretty clear it's not 70% who do care.
Say something like "Apple is still successful despite the lack of freedom" :)
Do you really not see the parallels? It seemed like a really great way to point out the fallacy here and demonstrate that "just because people aren't complaining, and even if when asked they are adamant they don't have a problem (an even stronger position than simply that they aren't going out of their way to complain), it clearly doesn't imply they don't have a problem if they haven't been given the necessary knowledge to understand or appreciate the problem" without having to directly engage with the broken logic (which is, of course, impossible).
>However, in a meta-study spanning 40,473 males, the studies rated most accurate found that "circumcision had no overall adverse effect on penile sensitivity, sexual arousal, sexual sensation, erectile function, premature ejaculation, ejaculatory latency, orgasm difficulties, sexual satisfaction, pleasure, or pain during penetration."
On the plus side platform exclusives almost totally gone outside of the game is manufactured by the console makers themselves.
That would be an awful experience for the consumers, UI/UX-wise.
As I value user experience and performance above all, for personal projects I prefer to focus on a single platform. And so far, I was also always more happy when using applications from developers that do the same.
Web is convenient in the sense that its easy to get access to a lot of applications and you don't have to install them etc, but the UX often leaves a lot to be desired...
Especially since things like NaCl exist(ed) which are inarguably lower level and still safe.
I think it's folly to create a whole new API before evaluating the option of using Vulkan.
If you are very interested in the details of API design choices, then I'd suggest joining the Community Group. Anyone can join!
Besides, Javascript doesn't really need driver support to intercept function calls...
> if you're allowed to change the API instead of just inserting checks at each call.
The only case is where you simply make the API so limited that it becomes decidable, e.g. remove all backwards flow control and recursion.
> Besides, Javascript doesn't really need driver support to intercept function calls...
Nope, it doesn't, but it makes for a more flexible approach when there is an existing model and implementation (validation layer) which supports this approach.
Improving the quality of the validation layer means that everyone benefits. It's also a massive job and thus, that something already exists, and is standardised, is a good approach.
Undecidable control flow does not inherently make validation undecidable, or NP, or anything else really. The key (like with any sort of type system) is that it's okay to reject some subset of valid programs in exchange for easy enforcement of the invariants you need.
In addition to my other points, the Vulkan validation layers are objectively (and IMHO significantly) better for debugging than OpenGL ever was. It's not just to improve performance. The debugging and development experience is significantly improved.
Just because it was designed to be high-performance doesn't mean it automatically wins on platform support and implementation quality. Direct3D 12 is at the same level as Vulkan, and I see no reason for the trend of D3D being higher quality than GL to end with Vulkan.
Although you and those you've been discussing this with can't agree on which API is better, there's plenty of evidence that Vulcan, Metal and Dx are all quite good. Why then would we introduce yet another "standard" from scratch, as opposed to working to implement one of the existing ones better across platforms (if the desire is truly to build a universal gfx api)?
Even if the web platform directly replicated one of the existing APIs, you still have to explain how it binds to JavaScript, as well as memory and GPU resource management details. So bringing a modern graphics API to the web will inevitably create a new standard.
The question then is whether to try to clone one of the native-level APIs, or make something that works on each of the top 3. We think working on all of them is better than tying ourselves to just one.
Besides this approach being supportive of lock-in (of underlying closed APIs like Metal and DX), which is more than questionable, more importantly, what shading language should this Web API use for example?
Worth noting also that Khronos is considering a slightly higher-level API than Vulkan as their next iteration. So that's another reason it would be a shame to bind too tightly to Vulkan.
I also find it puzzling how designing to support multiple back ends is "lock-in" but binding tightly to only one underlying API is "open".
Lock-in refers to how that platform affects your options for deployment.
Openness refers to how that platform is being developed.
A platform can be designed in an open way, but if it only works in one environment (e.g. browser) you might consider that to be "locked in". As in, you are "locked" into using a browser for deploying your application.
Vulkan is open, in the sense that it is an open standard. It's managed in a way that allows a wide variety of people/companies to contribute to it's design and implementation.
Vulkan as an API is an abstract model for how a GPU works. Everyone codes to that spec, and they can work on a wide variety of systems. So you are not locked in to a limited set of systems.
In fact, if you wanted to make your own Vulkan implementation you could, and there is a lot of documentation, conformance tests, etc to help with that.
Supporting multiple backends naturally requires an abstract API on top to handle the inconsistencies in the underlying systems. A new API naturally means that existing code would need to be refactored to work with it. If that API only serves the purpose of executing within a specific context, you might consider that to be "lock-in" for that platform.
Maybe that will change, but blocking on a major new WebAssembly feature did not seem wise.
DX12: Windows only. Metal: macOS/iOS only. Vulkan: cross-platform and cross-vendor. Windows 7/8/10, Android, Linux, MoltenVK supports iOS/macOS with a wrapper. That's a big win for Vulkan IMHO. Valve also agrees with this assertion.
In terms of performance, I don't think Metal is even a contender, given how bad macOS hardware is compared to Wintel. w.r.t. Vulkan vs DX, from what I've seen it's pretty close, with Vulkan usually coming out ahead by a few performance points but of course it depends a lot on the implementation when it's at that level. Vulkan has been shown to be systematically better than OpenGL.
In addition, Apple will be rightly considering iOS when evaluating options for web technologies, not the increasingly small section of the planet running Nvidia and AMD hardware on Windows.
I didn't make any such judgement or even mention VR a single time!
But, looking at the points you've raised, I can say with confidence that Vulkan has been designed, taking into considering these issues.
Vulkan has been carefully engineered from the ground up not to alienate tile-based renderer hardware. So, it's just as suitable for mobile GPUs as desktop GPUs. https://www.imgtec.com/blog/tiling-positive-or-how-vulkan-ma...
As such, it's already supported by many mobile GPU hardware vendors.
> In addition, Apple will be rightly considering iOS when evaluating options for web technologies, not the increasingly small section of the planet running Nvidia and AMD hardware on Windows.
The GPU in the iPhone 7 uses a custom version of the PowerVR GT7600 GPU. While this is purely speculation, PowerVR does support Vulkan in their other offerings, so it's not that much of a stretch to assume that the hardware is at least capable of it.
NVidia, AMD and Intel power all of Apple's desktop graphics, in addition, they collectively power almost all of Windows and Linux setups too (excepting other mobile and SFF computers)
> In terms of performance, I don't think Metal is even a contender, given how bad macOS hardware is compared to Wintel.
> In terms of performance, I don't think Metal is even a contender, given how bad macOS hardware is compared to Wintel.
The response was:
> It makes no sense to judge the quality of an API by the power of the available hardware it might be running on.
You are right, that my statement is not very clear.
The key point here is that I'm not judging the quality of an API by the power of the available hardware, but the quality of APIs relative to how much overhead they add, and that's quite a different proposition.
Given my intimate frustration with the state of Mac hardware and GPUs, I brushed off macOS as being somewhat ancient w.r.t. modern hardware and benchmarks. You can't go out and buy a Mac with a GTX 1080 for example. In fact, even the best Mac hardware you can buy is ridiculously outclassed by PCs costing significantly less.
However, back to the specific point of interest:
The overhead of APIs can be measured if you run the same benchmark, on the same hardware, with the different API. On Windows, it's possible to compare, say, DX9, DX11, DX12, OpenGL and Vulkan within the same benchmark. It's not possible to test Metal this way.
Specifically though, Vulkan is a C based API which is essentially as fast as it gets, in terms of actual function calls and so on. In comparison, Metal uses Objective-C. If you are familiar with Objective-C, you'll know that it doesn't have the fastest message dispatch (quasi-function call).
Basically, it would be really interesting to compare them, holding all other things equal. But, doing this with off the shelf GPUs simply isn't possible AFAIK. macOS hardware is simply too far behind. You might be able to jury-rig something using an external GPU, but it's still not a good comparison. My past experience of the graphics stack in macOS tells me it's unlikely to be great.
Also you seem to be under the impression that because a machine is expensive it is destined for gaming.
Without investing a lot of effort, the best I have is this: http://www.codeotaku.com/journal/2009-05/run-time-polymorphi...
In addition, my entire lament is that it's not easy to compare Metal to anything else. Ideally, this would tell you whether function dispatch was REALLY a big issue or not.
> Also you seem to be under the impression that because a machine is expensive it is destined for gaming.
No, that's not a valid assessment of my position.
I have an expensive desktop, and I use it primarily for work. Even the Mac Pro performs poorly when compared to an equivalently priced PC. Even just for work related scenarios. Some good comparisons on YouTube :D
Many times bottlenecks and missteps are not really visible until you can see how your decisions and assumptions encounter reality especially when every other chokepoiht has been removed.
Unless they did their development on Windows or on hardware that has never shipped, Apple isn't really in the position to have evaluated how well Metal works in reality.
I would add that the awkwardness of some "good" API designs is often not revealed until much later (and this is doubly true in the graphics space where there is ample evidence of API choices revealing themselves to be stuck with what turned out to be bad choices some times later).
As for past driver quality, ask a graphics developer doing anything more complicated than a toy weekend project. OpenGL drivers are inconsistent and buggy.
I never asserted that. I didn't even qualify what I meant by "BEST". But, let's evaluate the qualities you mention:
> platform support
Vulkan objectively wins here, supporting Windows 7/8/10, Linux, macOS/iOS with a wrapper, Android, etc. Intel has unofficial drivers for their x86 iGPU. Qualcomm recently announced hardware support, along with ARM.
> implementation quality
Vulkan is developed as an open specification, and has a full conformance test for implementations (https://www.khronos.org/vulkan/adopters/). Many aspects of Vulkan are available on GitHub and you can submit PRs. In my experience, drivers on Linux are very good and there are frequent updates. We currently deploy Vulkan at scale in production and haven't had a single issue with reliability.
In addition, the Vulkan validation layers assist with development because they check almost all API invariants and log incorrect usage. This helps to develop programs that work correctly according to the specs.
So, from the driver stack to the client software, Vulkan, IMHO, has a quality and well thought out implementation.
In comparison to DX12, which is developed behind closed doors, we don't know the implementation quality.
I personally haven't heard about any major bugs in Vulkan drivers, but I have seen quite few DX12 demos plagued by bugs. That's my subjective opinion though.
> Direct3D 12 is at the same level as Vulkan
Vulkan is better than DX12 in terms of openness, conformance testing, development tools, platform support, etc. Performance is about the same.
Even Valve agrees: http://www.kitguru.net/components/graphic-cards/anton-shilov...
> OpenGL drivers are inconsistent and buggy.
Agreed :)
We absolutely know the implementation quality of D3D- you don't have to see the source to see its performance, its stability, or its adherence to the spec. On the whole, it's far more consistent and stable than OpenGL and there is no reason to believe Vulkan will change any of that as it uses the same process for specification, development, and deployment.
Therefore your posts are off-topic.
The driver API exposes a layered stack. It's trivial to add a validation layer between the driver and the client. It's SO much better than existing OpenGL or DirectX driver models for this one reason alone.
I think Metal has a better API. You are free to disagree of course.
/s
Unless you backup the Apple proposal with serious evidences such as :
- hard metrics on performance benefits, why you need them, and why you can't improve vulkan to get them;
- demonstration of blatant issues with the vulkan API and very good solution you can implement and why you can't improve vulkan to get them;
- strong evaluation of the benefits your solution provide given the cost it would have compared to adopting vulkan.
Then you have no credibility.
"Let's fix something that works" is rarely welcomed in programming. Coming from a company that is well known for disrespecting the rest of the world by creating their own island of closed standards and help noone pass the border, it's even worst.
On this one, you are guilty until proven innocent, I'm sorry.
Or rather, he's got to refute the null hypothesis.
Thanks to Apple's bone-headed decision to not support Vulkan, this is what it has come down for me when it comes to graphical APIs. For me it's either "no new graphical APIs, keep being forced to use OpenGL" or "drop macOS/iOS support".
Isn't that what we want? A low-level not opinionated API allows the market and the open source community to create solutions that are subject to competition.
If we get an opinionated high level API then we are close to future developments by small agents. Only the big players can decide on the future of 3D graphics on browsers.
Why can't Apple just develop their ideal API over Vulkan and let developer decide what to use?
Wouldn't that be just about the opposite of everything Apple has stood for the last ten years?
Not Invented At Apple.
Microsoft is exactly the same. They do not support custom APIs on Windows Mobile AFAIK.
I'll need a source for this claim considering that no driver-level Vulkan implementations are available on macOS.
Developers can ask users for their admin password, sudo to root and largely do whatever they want including adding kernel extensions and drivers.
> Developers can ask users for their admin password, sudo to root and largely do whatever they want including adding kernel extensions and drivers.
Apple controls all the keys for macOS, AFAIK there's not even an option to add additional CA's for code-signing trust. To get around this you have to completely disable SIP, and it's rather stupid to tell users they must disable a well-meaning (if somewhat poorly implemented) security feature to install a kext because Apple doesn't like you (no knowledge if this has happened, but it can, and I don't care for that).
Not anymore, even being root doesn't give you total control now[1], and custom kernel extensions are among the things that are prohibited.
This «feature» bas been introduced in El Capitan for «security reason».
[1] System Integrity Protection : System Integrity Protection
https://developer.apple.com/library/content/documentation/Se...
> Developers can ask users […]
Have you ever seen anybody shipping software asking their user to do stuff like this to get their software working ?
> Boot to Recovery OS by restarting your machine and holding down the Command and R keys at startup.
It's simply a no-go for the mainstream market that expects things to just work.
http://www.apple.com/newsroom/2017/01/apple-reports-record-f...
That may have changed, I dunno.
It's Microsoft's lack of official support for OpenGL on Windows that leads to WebGL implementations using of ANGLE translation to Direct3D, rather than direct OpenGL, right? So I assume we'd have the same situation for a hypothetical WebVulkan. Yes, Vulkan would be available on Windows with the right drivers, but the browsers wouldn't want to use it.
Apple never listens to anyone, probably some higher exec wants better lock in and that they design the standards. Everyone else keep their mouths shut.
Yeah, support Vulkan.
There are no 'but's. Just support it and we can have simpler APIs on top of it.
The "lay of the land" is that the rest of the world is adopting Vulkan, and therefore the right target for WebGPU is very obviously Vulkan. Even macOS and iOS can (theoretically) support it thanks to MoltenVK [0], and Vulkan is already available on Windows. Trying to wrap all three "major" native APIs is pointless when there's already one that works everywhere and does so reasonably well.
This is not materially different than the situation with OpenGL, and yet I hope you'll agree that basing WebGL on OpenGL was the right decision, rather than inventing a new API based largely on a lower level API proprietary to a single company's platforms.
Unfortunately, that doesn't work as well for Vulkan. Vulkan is the lowest-level of the three APIs, so it's hard to support on top of Metal or DirectX 12.
Microsoft is only middle-man, the drivers are written by GPU vendors in the first place. Why should I prefer middle-man to the original source?
Historically, the drivers provided by Microsoft via Windows Update were worse (older) than those provided by GPU vendors directly.
> Microsoft works to make sure Direct3D works and I imagine they have lots of tests and compatibility suites there.
So do Khronos group and GPU vendors for Vulkan.
[1] http://winsupersite.com/windows-10/stop-automatic-driver-upd...
My guess would be that these same drivers would be out of date enough not to contain DX12, so if that's really the target, then there needs to be a fallback to OpenGL and/or an older DirectX.
Then focus on fixing that, instead of wasting time on bullshit like this.
On the flip-side of that, the web is supposed to be a universal platform. It doesn't make much sense to limit a feature to the subsection of web users who have hardware that supports 3D acceleration. :)
GPU vendors do not care, they will give you API to their hardware for any OS version that moves their wares. That's why I would trust more GPU vendors than OS vendor.
So calling them unsupported/unofficial is quite a stretch.
Care to elaborate on that?
In the worst case, someone could implement Vulkan on top of the "supported" API. Or, the OS developers could get with the times and ship a modern, functional system?
Drivers from GPU vendors are as official as it gets.
Windows has done an awful lot to make itself more attractive to developers recently because they get that it is vital for their future. I hate Windows but, even I have to admit, it has got way way better.
Apple's decision to stop producing things like AirPort Extreme or monitors is a stupid decision in the long run too. Even if these don't make any money on their own, part of what makes Apple an attractive platform to people is that they can buy everything from Apple and it work together so, even if these lose a bit of money, they make sense to do.
There are an awful lot of reasons to not use Mac OS so, it has to get the reasons to use it right and, it is quickly losing them. Fair enough, most of their money comes from selling iPhones but, sales of these will be seriously harmed in the long run if Apple can't sell other systems that integrate well with them. For example, Microsoft would not have to port or update Office on iOS if there wasn't the possibility that it could weaken their hold on the market if there was a Mac and iOS Office alternative. As it is, they would be insane not to support it on iOS but, without Mac OS and Macs, not doing so would be an option and, it would be a serious selling point for Windows phones. Apple's strategy is seriously broken and, it is going to be a serious problem for the company in the long term if it doesn't fix it soon, if it isn't already too late.
I don't say it is already too late, I say it might be. That may be overly dramatic but, unless you refute that there is a problem with an actual argument, you are hardly arguing against that.
The HN echo chamber is strong, but its silly anecdotes don't reflect reality.
What I don't think they did is sell many to developers or programmers. Although small in number compared to the overall size of the market, Apple's losses there are important. Mindshare matters when you're talking about the people you expect to build the software for the platform you sell.
A few years ago, I tried my hand at making an HTML5 application using the apple-mobile-web-app-capable, apple-mobile-web-app-status-bar-style, apple-touch-icon-precomposed META tags and the apple-touch-startup-image LINK tag.
It was so slick how the iPhone put my webapp's icon on the home screen and had a very beautiful startup splash screen as well. It felt very native and I could feel Jobs' influence on the way that presented, especially because it reminded me of his original iPhone reveal where he hinted that one would write apps for the iPhone using HTML5 (this was prior to the appstore.)
Ultimately, I had to give up on offering my webapp as a homepage app because of differing behaviors of my page in application mode versus in Safari.
For one, if the user switched applications and switched away from my html5 application, it would fully unload. Whereas the same web page would only pause/suspend if safari lost focus (I assume this is iff there is enough memory to keep the tab alive/passivated, which is of course reasonable.)
I can't have my webpage unload/reload on focus changes because it's a single-page webapp and keeps a lot of transient state.
Second, if I recall correctly, there was some oddities about the browser chrome that differed between application mode and safari mode whereby you stole some extra screen real-estate in application mode with an opaque bar and I needed that space for my layout. This second issue I think would be already addressed because your devices post iPhone5 have larger screens.
It would be so neat if these limitations were lifted on HTML5 applications and I could offer it to my users! Are there new/recent improvements to the system that you can share with me? Are there any super secret toggles I might add to my meta tags to tell the iPhone to preserve my HTML5 app's context as aggressively as Safari?
Thanks for talking even though people here are dogging on your proposal!
If you can share any history or stories about the origins of that feature landing on the iPhone, I would be grateful. I find it all fascinating.
The state of OpenGL will never improve: if you've followed Apple at any point over the last 25 years, it's pretty clear that they disengage very quickly from any technology that is starting to look deprecated/not the future. It works for hardware and software: first iMac with only USB and Ethernet, dropping the floppy drive, dropping CD/DVD drives, avoiding Blue-Ray entirely [1], only USB-C on last MacBook Pro, flash, etc. So my opinion is that OpenGL will never be developed further at Apple. They will probably drop all OpenGL support at some point in the next few years.
The other thing that is clear is that Apple doesn't like having their hands tied by third parties. The lack of adequate Kaby Lake processors for the launch of the last MacBook Pro, and the subsequent heat/hatred directed towards Apple because of it [2], is probably making quite a few people think that at some point they will really have to move the whole Mac line to Apple made ARM processors.
Apple started to ship a working Metal implementation to iOS developers before Vulkan was more than a draft [3]. This freedom to move at their own pace is worth a lot to Apple. Vulkan is a great piece of technology, but I don't have high hopes for it to be supported by Apple anytime soon.
[1] There were some licensing issues there, but had Apple thought the future of media consumption to be BR I'm sure they would have found a comprise. Instead they found an excuse to promote streaming / the Apple TV.
[2] Including on HN, where I would have thought the average reader to be a little bit more sophisticated on these technical matters.
[3] I don't have the exact timeline in head, so I might be wrong.
Edit: typo
Android is a Java based OS, which happens to use Linux as kernel, Google can very easily change it to something else.
Only these set of C and C++ libraries are available to native applications on Android, which happen to be compiled to a .so anyway, to be loaded inside ART/Dalvik.
https://developer.android.com/ndk/guides/stable_apis.html
Trying to link into any other GNU/Linux library that happens to be on the devices, but isn't part of that list, will trigger an app termination, starting with Android 7.
https://developer.android.com/about/versions/nougat/android-...
Also, many POSIX APIs have been removed from the kernel and require extra wrapper libraries, if they can be emulated at all.
https://roxanageambasu.github.io/publications/eurosys2016pos...
https://thesai.org/Downloads/Volume4No7/Paper_15-POSIX.1_con...
If Google would gives this away have my perfect development solution. I can play my Android games on my 2 in 1 and then use full Linux when in laptop mode. But I can also debug my containers on my laptop as native.
But when needed I have sold browser and other core things can never be touched. Basically give me a iPad and a Chromebook and a full Linux development machine. Well no kernel dev on Linux but most things, native, shared read, etc.
But I want an extra SSD that is separate from the kernel SSD. I think this can be done and even keep read share from boot dev and something running as a container.
Also, given that Windows versions other than ten still make up more than half of the PC market, Direct3D 12 is not even an option for most PCs, but Vulkan is.
So if we're being honest, it's not really "all three", but Apple vs. literally every other platform.
Obviously web applications can't simply be trusted not to crash an exposed driver, but "will result in a better API for the web." is exactly the opposite of what you would expect, given the history of high-level graphics APIs. Any layer of abstraction or heuristic other than those required for security reasons, will ultimately increase the number of implementation inconsistencies, that would be objectively worse.
Then consider just the shader language. It would be considerably easier and less error-prone to just support SPIR-V shader programs; but with this there will have to be even more levels of translation, even more places for things to go wrong, and a need to make completely new tooling to generate shader binaries.
Furthermore, driver bugs are a given, but Vulkan makes the skills to debug and report driver bugs portable across vendors and operating systems. If I'm an ISV and users are experiencing issues on Metal on OS X on an AMD card, I don't have layers, I largely don't know where to shim the library, and even if I could figure that out, why should I have to figure it out for every system?
Sony doesn't has official plans to ever doing it, as the PS4 APIs are better anyway.
Nintendo is only supporting Vulkan for easing bringing in titles to the Switch, because they actually have a better API called NVN that exposes all the graphics hardware features.
Considering that browsers implemented WebGL on top of DirectX, why would it be any different for a proposed new API?
In which case it's reasonable to at least have a discussion about what this new API might look like.
What hardware Nvidia and AMD will support with Vulkan? It might turn out, that they will support relatively new hardware and Windows 7 usually used with older hardware, so it might be unavailable even for Windows 7. And if those users will upgrade to Windows 10, they'll have working DirectX 12.
NVIDIA provides Vulkan back to Fermi (April 2010). AMD provides Vulkan on all GCN models (January 2012). They provide this support on all supported versions of Windows. For Fermi cards, I believe NVIDIA may have shipped Vulkan drivers all the way back to Windows XP (though I think they stopped doing XP releases in June last year).
It's yet more 'not invented here syndrome' from Apple.
OSX support for OpenGL is several versions behind, with low performance and you definitely are not going to write AZDO OpenGL code there.
Hedging almost-baseless assertions about verifiable facts by calling them opinions does little to hide the fact that you can't prove this and know you can't. IMHO, Macs are still very popular with developers, and the reason hasn't changed: a great GUI and a *nix command line. I personally would use Linux before Windows though because I hate both the Windows GUI and the Windows command line but I only hate the Linux GUI and could probably adjust to xmonad quickly and possibly even gain productivity. Granted I suppose I could use "Bash on Ubuntu on Windows" if I absolutely had to, however I think that name itself is an adequate synecdoche for my issues with the OS as a whole.
For what it's worth I feel pretty well supported as a Rust and Haskell developer in the Mac ecosystem, and Microsoft will have to do a lot better than give me bash to make me switch. It is a necessary but not sufficient condition for my computer usage ;)
Not all developers care about it.
Some relevant quotes:
“It was a result of not having all the technological support we needed to make the game viable on Mac systems.” says Kaplan, referring to Apple’s policies with OSX. “We have a real love and dedication for Mac players, they’ve been extremely loyal to us and we love giving them Blizzard games.
“But when dealing with the PC, the Xbox One and the PS4 - all of which are extremely welcoming to the technological needs to run a next-generation shooter - in a lot of ways we felt left behind, that we weren’t given the support we needed to make a great product on the Mac.”
What part of that is "leverage to get their way"?
The post explicitly states that they don't expect the WebKit syntax to be the accepted syntax; it is merely one implementation that can help inform the discussions.
If you want to vent your rage about 3D graphics on the mac go file a radar.
Apple decided to not support Vulkan as it had been developing a competing API called Metal at around the same time. I don't know why they don't also support Vulkan.
1) Windows allows the GPU manufacturers to ship their own Vulkan support; AMD, Nvidia and Intel all do this, which covers 99.99999999999999% of all Windows machines where this is an issue. It's not as good as native support, but it's good enough.
2) Windows has over 90% market share on desktop. macOS has far, far less. It's a lot easier to get people to support your API when you have that kind of market share. iOS doesn't have enough market share for devs to ignore Android.
It's likely not worth the vendor's effort but still.
TIL Matrox only has <00.00000000000001% of the market. :(
Metal is available since Jun 2014. Vulkan announced on 2015 and the initial release is on 2016.
[1] http://www.anandtech.com/show/9095/amd-mantle-api-programmin...
In 2014, it assumed that the GPU has unified memory architecture, for example (i.e. the GPU can access a memory buffer that you have a pointer to). That's why it was introduced on iOS only.
Though I do agree.
1) It's currently the fastest (unlike DirectX)
2) It's not controlled by an OS company (unlike DirectX and Metal)
3) It reflects recent developer and hardware concerns (unlike OpenGL)
2) Apple is proposing an open standard here, they're not making WebMetal
3) Why do you think Apple's proposal doesn't?
2) I think the people here would rather it be developed by an independent group like Khronos Group. For example, Apple created OpenCL as an open standard too and then abandoned it.
Thanks.
I know a bit about DirectX and OpenGL, and I wouldn't expose a direct interface to either of them on the web. Does Vulcan make security and isolation assurances? If not then it is useless.
There's no way Apple would ever allow Metal proper to be ported to PlayStation or Windows, so you're limiting yourself to at best two platform coverage targeting this new standard. Vulcan will, hopefully, work on every platform. At least subsets of it, with shims. No way Metal ever gets there.
This is the new normal, coinciding with the death of expertise.
The WebKit developers clearly are not working in a vacuum, if one bothers to read the blog post:
> Our proposal has been received positively by our colleagues at other browser engines, GPU vendors, and framework developers.
Not to mention that the WebKit developers are pretty much the forefathers of all modern web tech. So the WebKit developers and their colleagues are the experts. And the expert consensus is the successor to WebGL will be something new, something that can be implemented in DirectX 12+, Metal, and Vulkan.
But all the non-experts have heard of Vulkan, and are armed with the simplistic notion that Vulkan is the "next generation of OpenGL". They erroneously conclude that WebGL's successor must also be a Vulkan based solution.
The non-experts will justify this belief with all manner of ridiculous conspiracy-esque conclusions to reinforce their bias. Like "Apple is trying to force the standard", "Apple wasted their time developing Metal", "Apple is a closed-source walled garden", "Apple is expensive". All of which is is essentially the tech version of "libtard" based arguments.
RIP expertise.
IE4 was the forefather of modern web tech[1].
> They erroneously conclude that WebGL's successor must also be a Vulkan based solution. [...] All of which is is essentially the tech version of "libtard" based arguments.
No, people are sick of working against 3 different APIs. One of which is a standard. It's Microsoft doing their own thing with IE all over again. A safe subset of Vulkan would be familiar and would have existing documentation. All designed by GPU experts.
We did indeed discuss this widely. No one thought that an API which only works on top of Vulkan was right, everyone in the relevant sector thinks it has to support the big three. Very few thought modeling the API closely on Vulkan was the best technical path.
I honestly don't understand why everyone here is so obsessed with Vulkan. Cloning it on the web won't make it more successful in the market. Building a Web API that is able to work on top of it (without mandating it) will likely help Vulkan in the end.
I suspect part of the issue is that since video games intersect so heavily with graphics APIs it will bring out the angry gamer crowds and with your being an Apple employee, it brings out the extreme anti Apple crowds. There will be people with legitimate claims, but I think they're being drowned out by the noise.
> Meanwhile, GPU technology has improved and new software APIs have been created to better reflect the designs of modern GPUs. These new APIs exist at a lower level of abstraction and, due to their reduced overhead, generally offer better performance than OpenGL. 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.
Oh, really? And who is to blame, that Vulkan is not available on Apple platforms?
[1] https://www.g-truc.net/doc/OpenGL%20Drivers%20Status.pdf
I'm willing to give Apple the benefit of the doubt on this. Like any big tech organisation, I'm sure they have people who want to do the wrong thing, and people who want to do the right thing. Everyone supporting Vulcan would be nice, but a standardised, patent-free, cross-platform, web-enabled, low-level GPU API would still be a major step forward.
[1] https://gpuweb.github.io/admin/cg-charter.html [2] https://www.w3.org/community/about/agreements/cla/
So how come they didn't manage to have the same idea for touch events?
> Everyone supporting Vulcan would be nice, but a standardised, patent-free, cross-platform, web-enabled, low-level GPU API would still be a major step forward.
I'd say design and its roots matter. If they base it off Metal, and use Metal like technology, while Metal itself remains a closed Apple only API, then W3C should reject it. Consider the whole related ecosystem, like shaders and so on. Anything like that should be based on open APIs and related ecosystems, like WebGL is based on OpenGL.
If Apple want to help, let them base WebGPU on Vulkan. If not, they shouldn't waste everyone's time. I hope W3C participants will have enough common sense to come to the same conclusions.
I have no clue. You'd have to ask them. But they have had this idea for WebGPU. If you think it's better than what they did for touch events, let's hope you approach it with an open mind and-...
> I'd say design and its roots matter. If they base it off Metal, and use Metal like technology, while Metal itself remains a closed Apple only API, then W3C should reject it.
...No, you're just going to get mad about a hypothetical.
Literally the whole point of the WG is to design a low level GPU api specifically for the web with security etc in mind (i.e. not just "give javascript direct access to the GPU" like Google's WebUSB and WebBluetooth proposals) that can be backed by whatever GPU library is on the platform: for Window's that's DirectX (do you really want a web app to tell you that you need to update your GPU drivers to get support for Vulkan?), on (mac|tv|i|watchOS) that's Metal, on Linux its.. um.. Vulkan I guess or perhaps OpenGL or who knows what else people decide to install?
Why wouldn't you want to do it? Same can happen when you install some non Web application that requires it (games / VR etc.). I don't see how Web or non Web makes any difference. If you don't have up to date graphics drivers, problems are inevitable anyway, and you better fix that. If Web application gracefully warns you about it, instead of crashing - all the better.
Are you fucking serious? The web is always being trumpeted as "works everywhere". But now you want to tie the web to specific GPU drivers?
> Same can happen when you install some non Web application that requires it (games?)
You can use the web on a lot of devices that you can't install local applications on.
> I don't see how Web or non Web makes any difference
Perhaps you should look into that, because problems are inevitable and you better fix that.
This isn't just "The Web". It's a Web interface for intense graphics usage. Expecting it to work if the user doesn't have working drivers is beyond silly.
> You can use the web on a lot of devices that you can't install local applications on.
And that doesn't mean you have full capabilities there. If user has no control, and vendor doesn't care to keep it up to date as well, I doubt browser makers can do anything to remedy such cases. They'd just blacklist certain driver combinations (that's already the case for the reference).
Such users would contemplate either using a normal system, or skipping such applications on their un-updateable / broken one.
It isn't just about working drivers, it's about a specific version of working drivers. Microsoft don't provide Vulkan support on Windows, it's provided by certain GPU drivers, which is pretty much guaranteed to be less than those that support e.g. DirectX on your average PC.
> that doesn't mean you have full capabilities there.
The point of this WG is to have powerful 3d capabilities using different underlying libraries, which maximises the potential to have the capability on different platforms.
You seem to revel in the idea that certain users can't use 3d-based web applications because they don't want to or can't install specific vulcan-supporting drivers.
> If user has no control, and vendor doesn't care to keep it up to date as well, I doubt browser makers can do anything to remedy such cases.
You're somehow confusing "having a Vulkan supporting driver" with "up to date".
As time goes on, this will be less of an issue. Transitional periods are always more complex.
Again, likely use cases for such APIs are intensive graphics applications like games. So users who are interested in that usually are aware, that it's a bad idea to use outdated drivers. So again, this isn't very different with Web or non Web cases.
No, I'm talking about users even having the unofficial vulkan-supporting drivers installed (on Windows).
Users aren't going to suddenly get Vulkan support in a driver update from Windows/Microsoft Update.
> I don't see how browser makers can fix that, besides warning users that their drivers are too old.
Try to read this carefully, I've mentioned it several times: The point of this WG is to provide an API layer on top of a range of low-level GPU libraries.
For Windows (where Vulkan support is possible but not practical due to the unofficial nature of Vulkan supporting drivers) the most common API library that browsers would use, is DirectX, which is provided and supported by Microsoft, across a vast range of hardware.
No one insists that all browser vendors use the same TLS library, or the same DOM library, or even the same JavaScript engine. They just (aim to) support the same standards, usually building on things already available from the OS.
If you still can't grasp this, I have to assume you're simply trolling.
They aren't likely to get updates for DX either, let's say if they are using Windows 7. They won't get DX12, right? So again, there isn't anything browser makers can do about cases of outdated drivers, besides warning the user (if they rely on such drivers). If users can fix that (by updating drivers / system), good. If not, users can skip those applications.
> Try to read this carefully, I've mentioned it several times: The point of this WG is to provide an API layer on top of a range of low-level GPU libraries.
Yes. This assumes 1. those libraries are installed, and 2. they have certain minimal required capabilities. And browser makers have no control over it. Only user has (or in worse cases - vendor, if the system is all locked up). So it's only a natural thing to expect, for browsers to warn the user, if minimal requirements aren't met (in whatever way).
The aim of the web is to just work and then as a lower priority work well.
Apple want to stand up for the user and fix it? Let them support Vulkan. Oh, wait... They don't really want to.
You should take that idea seriously, if you want to view it as a truly collaborative project that invites everybody's participation. I.e using MSL from the start was a major mistake.
> We don’t expect this to become the actual API that ends up in the standard, and maybe not even the one that the Community Group decides to start with, but we think there is a lot of value in working code.
I think it's pretty natural to write what is essentially a proof-of-concept with tools one is ga,iliar with.
When designing an API, you have to take the characteristics of the calling language into respect. Especially when you are trying to achieve the highest possible performance. You can define highlevel APIs, which try to minimize the amount of computation in the calling language, or a more lowlevel API, which gives only very basic operations, and the client has to implement more logic themselves.
When targeting "fast" languages like C/C++ you tend to design more lowlevel APIs, assuming that the client can implement abstractions more efficiently as they are more tuned to his needs. When targeting slower languages, you want to do more computation in the API.
So for designing a new Web API, you both have to consider that Javascript is slower than compiled C and on top of that, you have to consider security requirements. Your API should not create an attack vector to your device. This means, the best Web API would be an abstraction on top of the native low level API and the only question with respect to those would be: can the proposed API be implemented well and efficient on e.g. Vulcan?
off topic, but who is the client?
Is there a specific person you're talking about, or just a programmer in general? Does this have to be male, or are women also allowed to code?
I can only imagine the type of flack I'll get for raising this hear, but I find it difficult to parse sentences that are overly specific about a general collective of people. There's no need to mention gender here - consider using something like "they" instead.
Because I usually think, HN is different, from the angry, uninformed mobs out "on the streets".
I mean, I don't know much about low level graphic API's, I read about them, but I don't work with them directly. But apparently most of the people here don't know either!
They basically seem to know that they like open standards (so do I) and that Vulkan is a open Standard and they heard of a possible WebVulkan so that must be the solution then. Or just continue using WebGL. Because it works, right?
What they didn't heard of and what I came up with a bit of reading, before posting anything, is that WebVulkan first of all don't exist and secondly probably shouldn't exist mainly because of security. And that it is very, very low level. (e.g. https://floooh.github.io/2016/08/13/webgl-next.html) And that WebGL in itself has some flaws, so it makes sense to design a new API for the future, without them. Because even though WebGL is working and awesome right now, that's not a reason to not evolve ...
But why bother reading and really discuss a new WEB proposal, when "People just want Vulkan on MacOS and/or IOS."?
- Apple, particularly recently, have been terrible on supporting modern web proposals. Worse than anyone. Much worse than the typical historical reputational lower bar that is Microsoft.
- Apple's record on proposing new web standards has been demonstrably aggressively anti-open and not generally condusive to promoting interop https://www.w3.org/2012/te-pag/pagreport.html
- Apple's general record on cross-platform development is pretty much non-existent. To the contrary, much of their business decisions are specifically based on limiting interop with non-Apple platforms.
I think on a holistic level, if you take Apple's record into account at all, any criticisms from them of a cross-platform proposal of any kind need to be taken in context. Before you even start considering the pros and cons of Vulkan or WebVulkan, there's a very blatant case of cui bono to examine behind this.
Even if you do get past that, the points about commonality between native and web APIs are growing more and more relevant every day as Emscripten, WebAssembly and other such tech brings the two worlds closer to each other. Cross-compilation efforts will invariably be made easier with a more consistent API between (web and native) platforms.
Not really. Because yes, it is well known that Apple closes down their system and wants full controll over it and locks other partys out. One of the Reasons for me, to not buy them.
But what does this have to do, when they propose a new Web API? If Apple chooses to go a different way with metal (and a way apparently quite some devs like), than I don't see much point in trying to force them to go another way. Maybe metal is even superior - I can't judge that, but I am not going to say vulkan is superior, just because it is open(even though I would like it to be superior just for that fact). ButI don't see much point in dragging Web-Technologys into these discussion in the first place.
Especially since apparently it is possible to implement the proposed WebGPU on top of metal, vulkan or Direct3D !!
And even though "Cross-compilation efforts will invariably be made easier with a more consistent API between (web and native) platforms." is true , it is not gonna happen at the moment, since simply not everybody wants vulkan at the moment, but 2 major players stick with something else. And I am not sure it is only for power reasons, but maybe also for technical reasons, as I read from quite some devs, that working with vulcan is huge pain(and they prefer metal, if it would be open) .... as it is not made for working with it directly, but rather to be worked through a higher level API. So ... is there a different proposal for that higher level API than WebGPU to be discussed right now?
The web being inherently cross-platform in nature there's a motivation on their part to not support it, or - in this case - cripple it (perhaps to a mild degree but at least enough to render it categorically inferior to native metal and not worth the trade-offs). I can't say that their proposal does this necessarily, but there's inarguably a motivation to do so.
For a previous obvious example of this kind of thing, see the deliberate crippling of iOS UIWebView.
> I am not sure it is only for power reasons, but maybe also for technical reasons
Call me a cynic, but while there may be good, valid technical arguments against Vulkan, it's mainly for power reasons.
I see, that they hypothetically might have motivation, to do so ... but this is not valid, since the web is inferior to native implemantations in the first place! The "only" advantage of the web is, that it is more or less, cross plattform.
Add to that the fact that what positive feature development there has been in Safari (e.g. the above-mentioned excellent es6 support in the Technical Preview) has very specifically excluded the addition of any of the APIs that begin to blur the web/native divide (web notifications, userMedia, service workers, &c.)
It shows what I said before, yes they control their system and making it harder for other implemations if they want ... but his is something completely different.
Apple has consistently shown that their locked down platform is priority number one. I think there are people who, for better or worse, have grown wary of that and need some extra convincing if Apple wants to influence big decisions.
Safari feels more and more like IE to me as the years go by. I just have a hard time taking it seriously and don't go out of my way to support it, just like Apple doesn't go out of it's way to support it when they have proprietary platforms that they can make vastly more money from.
All that said, yes, Apple has pushed the envelope from time to time, and has made some major contributions to open standards, so credit where credit is due, and accountability where accountability is due.
The web is de facto inferior, but it is not de jure inferior. That is to say that many people would very much like to see the web match native in capability, and efforts that derail this effort are criticized in kind.
"What a WebGL2 successor could look like and why it can’t be WebVulkan" - https://floooh.github.io/2016/08/13/webgl-next.html
See also the the author's sketch of a next-gen web graphics API on top of WebGL (https://floooh.github.io/2016/10/24/altai.html) which is (perhaps unsurprisingl) broadly similar to the sketch given the article (minus command queues, shader libraries, ...).
They haven't even made a public statement.
And now we get the news that they are working on another API. It doesn't really matter that the new API is targeting a completely different market to Vulkan. It doesn't really matter that a WebVulkan can't really exist in the first place. It doesn't matter if this is probally the correct starting point for a NextGen web graphics API.
It doesn't even matter that the team at apple proposing this API is not the same team that would be responsible implementing Vulkan in OSX.
People just want Vulkan on MacOS and/or IOS.
The Apple employees posting in here posting some really interesting stuff, but it's all being drowned out by this noise that has little to do with the topic at hand.
Scads of this thread are giving me that signal loud and clear. Not HN at it's best.
Vulkan is great, but you need to think about the cross compatibility of the web.
If Vulkan took this long to adopt partially, how long do you think a new 3D + Web standard will actually take? My money's in 10 years.
Mind you, it does at least look like they're trying not to be jerks about it (even if the motivation is somewhat selfish). They specifically mention the competition to Metal and how "webgpu" is ideally an abstraction that'll sit on-top of Vulkan, Metal and Direct3D 12.
It'll be interesting to see how this pans out. Vulkan, Metal and Direct3D 12 are all intentionally very low level, adding a wrapper of any kind may be seen as non-ideal by all parties.
It is a joke to suggest putting another abstraction over the low-level api. That is squarely the domain of libraries and frameworks.
That's fine for native apps when the libraries and frameworks can be native and thus high performance but, on the web, these have to compile to JavaScript and, while that can be very fast, a native framework is going to be faster than one running in JavaScript ontop of a lower-level API. This is a problem with the web though.
We've discussed our proposal a lot with key players in this space (including other browsers, GPU vendors, relevant ISVs) and we're pretty sure a cross-API abstraction is the way to go.
Some even want to build a form of cross-API abstraction at the native C/C++ level.
The end goal is to maintain Metal as a proprietary bit of tech for native apps, in order to make it more burdensome for people to port native apps away from the Apple platform and as a result give Apple more exclusive apps and more artificial barriers to entry for competitors. Why should the web standards people be bending backwards to support that goal?
That would be a really great outcome for consumers (including Apple users) and developers and only not so great for Apple and its lock-in strategy. Seems like a net positive.
No, the right thing for the broader ecosystem is working only on Vulkan, and forcing Apple to adopt Vulkan, so that one API is usable natively on every OS, device (even Nintendo will support Vulkan on its consoles!) and browser.
If Apple wants to go their own way, sure, but they’ll be cut off from the rest of the world, and quickly realize where they went wrong.
That makes sense to me. What is special about the web that should exclude it from the single API narrative?
Remember claims of Flash being the necessary thing on the mobile web, and efficient too? It turned out it was never true.
Note there's still no web version of "pure" Vulkan. If it gets to be modified to be less "ridiculously low level" in its web variant, it is anyway going to come closer to the goal Apple proposes for the web.
Again, to quote from the Apples proposal: "We don’t expect this to become the actual API that ends up in the standard, and maybe not even the one that the Community Group decides to start with, but we think there is a lot of value in working code. Other browser engines have made their own similar prototypes. It will be exciting to collaborate with the community and come up with a great new technology for graphics."
---------------
Yes, it doesn't have a web API. That's because there's no existing web API for low-level graphics of this nature. The question is, what this API should look like. It seems natural to answer this question with, "whatever is the standard outside of the web". Now, there isn't one - but Vulkan is the closest that we have.
So, from an engineering perspective, if Apple does want standardization in this area, it would make sense to standardize on Vulkan for both web and non-web applications. Or if they want something else, like e.g. Metal, because Vulkan is somehow inadequate, then they should also submit Metal as a cross-platform standard API outside of the web.
Basically, this is trying to solve the standardization problem at a higher level in the stack, while ignoring the same exact problem one layer lower - despite the fact that there's a similar effort ongoing on that layer. Good design would dictate solving it at the lower level first, then building on that for the higher level.
I'm guessing the changes that may occur in the lower level aren't big enough to affect the upper level.
A lot of people in this discussion seem to just be operating under the assumption that the web API SHOULD be the same as the native API. But if you want a layer of indirection there for any reason (optimization, security, future proofing, whatever) then trying to be a one to one match to a lower level API may not be a good design decision.
There are one or two comments by the Apple people here on this point but not many from others: let's just assume the Vulcan is everywhere... would it still makes sense to use that (directly) as a web API? I'm not convinced it would.
Neverming the fact that it implied running a VM on a phone, tie themselves to Oracle in undesirable (read: licensing) ways, or that it was not the best technical choice: market forces (including dev skillsets in production, down to mass customer adoption) determine the winning strategies in tech. It's all about money, and waiting for hundreds of thousands of devs worldwide to train on a new tech isn't cheap nor easy nor fast.
So that's a good real-world example of a successful strategy that didn't make much sense from an engineering standpoint (surprising move by Google of all big tech, given their deep engineering DNA/culture).
However it's been stated time and again that most people Apple talked to regarding WebGPU are in agreement that this high-level web API should be able to target pretty much any and all low-level graphics API (DX12, Vulkan, Metal and perhaps others eventually, like NVN or other custom implementations on consoles etc.) So there's that. The reasons are probably as much political as they are technical (nobody probably wants to drop their own horse). It might require more work, and produce lesser results (in terms of performance) but ultimately that may be the way to make WebGPU succeed, regardless of who's proposing it.
If we look at the JS situation generally (ref: "what it's like using JS in 2016"), the same could be argued that standards are very much not the norm beyond W3C specs (because TypeScript this, framework that, Babel this, npm that, etc.) Is that a good thing? Some say yes. Is that a bad thing? Some say yes. If we end up having several disparate implementations of WebGPU we know it'll be the same: you have one problem to solve and a solution space that's 10x redundant -but what little idiosyncrasy you find in all this mess is also the reason why everyone and their mother can use JS (different problems meet a bunch of various solutions), it's also probably why the field is so dynamic.
The matter of the fact, imho, is that thinking of 3D on the web in 2017 without considering AR/VR from the get go is just a loss of time, and that implies catering to mobile (because the economic revolution of that will be shaped as portable glasses or lenses, not 60-pounds workstation). It's highly likely that these devices will rely on custom/new OS more of an IoT flavor, and in making these the classic vendors (MS, Google) can add whatever drivers WebGPU requires by then. In the meantime, it may be a reason not to lock anyone into any particular low-level API, including OSS Vulkan, simply because we don't know yet what the actual reqs/specs of the next wave of devices will be. Designing WebGPU to be low level API-agnostic is probably safer in this transitional environment.
Not advocating anything here, just thinking out loud.
The truth comes through even in the first part of the sentence containing "Vulkan".
User phire was even more honest(1)
"Everyone here (including me) is upset that Apple are refusing to support Vulkan (or even improve their existing OpenGL support)." "It doesn't really matter that the new API is targeting a completely different market to Vulkan. It doesn't really matter that a WebVulkan can't really exist in the first place. It doesn't matter if this is probally the correct starting point for a NextGen web graphics API." "People just want Vulkan on MacOS and/or IOS."
Blink, WebKit, gecko, etc are implementations that support that standard.
The response wasn't about how Vulkan was good for the web, but rather about how a different route might help the Vulkan ecosystem. That may or may not be good, but it has nothing to do with what's good for the web.
They don't think it's the best way because it hits a fundamental API impedence mismatch with the browser (it's too low level, and probably not the right fit for JavaScript as an API - Vulkan being a standard does not mean we should senselessly emulate it), it's not at all clear the security model matches what the browser actually wants (part of being too low level, but also not being designed with the web's security model in mind), and it requires a lot on the half of users in forms of software support to support 'true' Vulkan as it stands, and it will be difficult to emulate such a low level API and its quirks (it's possibly the lowest level of the 3), which is why WebGPU aims to be a bit higher level. Even on systems like NVidia/Windows with top OpenGL support for years, the variance among OSs, hardware, and cards means e.g. Browsers and developers all implement WebGL in terms of DirectX, not OpenGL, even on suitable platforms. This is simply because the "native" graphics API -- for any platform -- tends to be the one with the most first party support, care, and stability across everything. It doesn't actually matter if you have OpenGL support on Windows, WebGL will still work because of this decision. That means more people can use it. Re-creating this same mistake with Vulkan will likely be costlier, due to it being so much less generic and much more low-level. If we're going to make "WebGL 2.0" happen, whether or not it's actually WebGPU -- it should avoid mistakes like this one.
(It turns out when your software is used by literally billions of people on extremely diverse hardware, sometimes fantasies about driver support from nerds with $2,000 premium machines aren't always true.)
Now that I've said all that: you are now free to continue ignoring literally everything written in the original blog post and ignore everything written by the developers here about its design, and assume whatever you want. That's apparently what people like doing, it seems.
> Working on top of all the major APIs is the right thing for the web.
A standard is the right thing for the web. Whether that's an abstraction or agreement upon an existing implementation remains to be seen.
They only care about standards when they're basically forced to adopt/support them, or they're their own.
These are the same guys that:
- use lightning instead of mini USB
- removed the headphone jack
- are creating yet another proprietary connector for accessories
- don't allow their OS on third-party hardware
- only allow developing for iOS from macOS
- only allow apps on iOS if you install from the App Store
- only allow their own browser engine on iOS
- etc.
Everyone wants their own standard to be the standard, if they really cared about it they would contribute to Vulkan and create WebVulkan.
“It seems many people are missing the point of this. 3rd party cable makers want to make certified cables that are Lightning to UAC port so people can plug in iPhones and iPads into cameras that use these ports. Apple isn't wanting to use this port, it is the cable manufacturers wanting to make adapter cables to plug more things into iPhones and iPads.”
[1] https://arstechnica.com/apple/2017/02/no-apple-isnt-developi...
mini usb? http://phandroid.s3.amazonaws.com/wp-content/uploads/2009/06... I'm assuming you mean USB-C, which was developed after Lightning with a push from Apple (they contributed more engineers to the USB-C spec team than any consumer electronic company).
Where are getUserMedia, MediaRecorder, WebRTC, filesystem, vibration, screen orientation, Service Workers, Web Bluetooth ? What about WebGL 2? I'm sure there are a few more I missed too.
Those are things that are really holding the web browsing experience back on iOS/MacOS, not an extra 20% 3D performance and slightly shinier graphics.
Or why not lift the app store restrictions so that Google/Mozilla can actually ship non-crippled web browsers and implement it all for you?
The sudden interest in a web graphics api is somewhat conspicuous coming from a company known not to adhere to web standards.
There must be some reason for apples sudden interest in this stuff. Knowing apple they're interest probably isn't aligned with their users interest.
* Non-standard headphone connectors (to force license costs onto manufacturer)
* Proprietary bluetooth codec (to force license costs onto manufacturers)
* Not using USB connectors on phones even though they were a part of the EU
group that concluded that all phones have to have USB connectorsAs someone who spends a lot of time in that space I don't really see what this is solving, WebGL is good enough and anyone serious about performance/compute are going to drop down to native anyway.
In the extreme case you get stuff like "GPU-Driven Rendering Pipelines" described in http://advances.realtimerendering.com/s2015/
- Implementing OpenGL drivers is very complicated, this leads to huge drivers full of bugs and performance issues. Just look at something like this: https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and...
- OpenGL's state machine logic is outdated and horrible to debug. We need something more modern. Basically its carrying cruft from the last ~20 years.
- It can be very slow compared to Vulkan/Metal/DX 12.
- It doesnt allow modern features like GPGPU. this would allow is to truely use the GPU for computing stuff (e.g. AI, novel shaders, new graphics pipelines etc.)
Not true at all; if your primary performance bottleneck is the GPU code, not CPU code, you could use a better web API modeled after Vulkan, for the same reason people switch from GL to Vulkan.
In general, if there's ever something where people feel they "have to" use native instead of web, that needs fixing in the web platform.
Another aspect that scares me about this is the security implications of exposing compute to the browser. Esp when you start talking about unified memory architectures. There's been more than a few exploits from a clever soul calling glReadPixels in the right circumstances. Increasing the surface area here doesn't seem like a great idea. Shader compilers are also great targets for instability and obscure bugs.
Memory bandwidth for your textures, geometry, and other data, quite often. Or nothing at all, if you can successfully reach your desired target framerate.
But if CPU turns out to be an issue, that's what WebAssembly is for.
So in other words a GPU bottleneck?
If your GPU is designed with a small bus between system and GPU memory, that's still a GPU issue. You could make the same argument on the CPU side for caches and DRAM if you want to go that far. I appreciate the education lesson but I think you'll find most graphics programmers will consider it a GPU problem :).
At the end of the day though here's the thing. The intersection of users that have a GPU capable of discrete pipelines, compute shaders and all the other things that make this interesting but won't go through the effort of installing a native app is relatively small. You can't polyfill(otherwise why use the GPU in the first place?) on the users don't have a cutting edge machine so you're going to have a swath of people that your WebApp won't work for. From a value proposition it just doesn't make sense.
You potentially can polyfill, if you have a graphics engine with a higher-performance Vulkan/WebVulkan backend and a lower-performance GL/GLES/WebGL backend. The Vulkan version will make better use of resources and allow you to turn up the quality higher while still hitting the all-important framerate targets.
All the same problems apply just as much if you go native as if you go web. You either have to work with older APIs (often via an engine), or write off older GPUs and some subset of users. Whether you can do that depends on what you're doing.
I'm pretty sure you just argued in favor of creating a new API instead of using Vulkan...
Problem is you cannot get anything close to that on any reasonable sampling of OpenGL platforms, in anything close to working condition. At best you just end up using the degenerate subset of APIs that can actually work across all your targeted systems - for a fully cross-platform title, that would include Android, and probably limit you to OpenGL ES 2. If you drop mobile, it would be around OpenGL 3.1-3.3. If you throw out some hardware as new as 2012, you could get stuck at Apple's last supported (which is buggy and broken all the same) OpenGL at 4.1. You can throw out Apple, and get stuck at recent Windows AMD and Intel support around 4.2.
But that is the best case - where you don't then pick your target and find out all the drivers are broken in a dozen different ways each for the extensions you are using.
It is only OpenGL 4.4 and 4.5 that Khronos has required conformance testing for certification for, and very few people are targeting those for development because of how limited a subset of the market actually supports them.
So that is the point where you throw the whole mess out and just use Vulkan - which only has one major release version, and has 3 feature support levels you can pick from, with conformance testing for all of them.
As someone who also spends a lot of time in the GPU space, I really want something newer than WebGL. WebGL is not good enough.
FWIW there's tons of things build on OpenGL ES 2(all of Android for instance). If you're going to write something to run on a wide range of platforms you're either going to deal with least-common denominator(GLES2) or write per-platform layers(like we'd do on consoles/etc).
You say that like it's a good thing! The point of WebGL is to put that pain on the browser vendor.
OpenGL ES 2 is incredibly limited, as you know. Yeah, you can do a lot with it, but there's a ton of stuff you can't do (tessellation, compute, image load/store, heck, even unbounded loops in shaders). Why should the Web be limited to that?
I just don't see how you push it to the web. You're forcing device capabilites onto users and the web always lags well behind what's happening in the native domain.
> You're forcing device capabilites onto users
I guess this is an argument about portability? That's an argument against WebGL at all, not about WebGL 2. Besides, WebGL 2 is targeting an API that's 7 years old at this point. A seven-year-old API is not exactly bleeding edge.
> the web always lags well behind what's happening in the native domain
Again, you say that as if it were a good thing! It's not! That's what this is trying to fix!
A good graphics API, even a web one, is one that provides good control over the GPU.. and to have sane standards which limit future implementation fragmentation (like shader byte-code instead of a specific shader language), and to have good debugging tools, etc.. That's what Vulkan is, regardless of how verbose it is in comparison to OpenGL.
I'm not saying you can just make Vulkan run on the web, but I'm certainly in favor of a Vulkan-subset (using SPIR-V as a shader base) becoming the successor to WebGL over one inspired by Metal and MSL.
As someone else noted, Apple created OpenCL, helped make it a standard and dumped it. It embraced OpenGL when Mac OS X first came out and now it can't be bothered to implement anything beyond 4.1. All of these little irritations serve to remind people of the Apple of yore that had NIH in extremis and was the gang that couldn't shoot straight.
The hostility is unfortunate, but I fear it's going to become more frequent if Apple's senior management thinks the ship is fine.
Moreover, web standards last much longer than typical desktop APIs. Do we really want to take a snapshot of Vulkan's API today and live with it on the web for the next couple decades, as desktop Vulkan continues to evolve?
It's better to build a web API that is fluent for its target platform, taking care that it's possible to implement it performantly on foreseeable host platforms.
Let Apple lock themselves in if they want. Don't lock the web into Vulkan.
This doesn't even touch the reasons it hasn't been, and the most important of these for me is security. "Well yes, it's extremely low level and admittedly very dangerous, but we can make it secure enough to expose to the most hostile environment in the history of computing" is how we ended up in the mess we are in right now security wise. You want a secure system, you have to build it that way from the start preferably in languages that don't let you decapitate yourself like Rust. I'm pretty sure it's a consensus that it's impossible to write secure C code these days, so why is everyone so convinced we could sufficiently harden a low level graphics API for web use? This is like if when NetScape proposed JavaScript if everyone went "well you're just trying to dominate it, we already have C89 just put that in the browser." Fucking NO. When are we as an industry and a discipline going to learn our lesson with this "code first, secure later" crap?
And again, if this could be done and it's such a great idea, why is this the first proposal and not actual WebVulkan? The argument here is not WebVulkan vs WebGPU because again WebVulkan does not fucking exist. When or if it does, perhaps we can argue about why Apple won't support it if they don't, but until then, you're shooting down one attempt at a standard API with a hypothetical thing that does not exist and which a lot of experts in the field seem to think is a bad idea from several angles.
I will reiterate this one last time because it seems like everyone has missed this: there is currently no cross-platform solution for next-gen web graphics except for this proposal. Put up or shut up.
How convenient to propose your own standard as the standard, made specifically for your own engine...
The major browser vendors have basically already committed to this sort of effort and the GPU vendors are signed on as well. The blog post even says they don't expect the final syntax to look like their proposed syntax. It's called a prototype for a reason and it helps inform the thinking around what to do and what not to do.
This is just HN anti-Apple mania. If you have a bone to pick about Vulkan support then go file a radar. Email DTS. Email Apple leadership and lay out your case in detail for why Apple should support Vulkan. None of that has anything to do with trying to standardize low-level graphics on the web.
Yes, they're using the Metal Shading Language in this initial proposal. But in the blog post they explicitly say that the choice of the shading language is likely to be contentious (or, as they put it, "fun"), and so they're deferring the issue right now and just picking the Metal Shading Language because they're Apple developers. The actual choice of shading language in the final version of this proposal is going to be the result of the standardization process, and will probably not end up being the Metal Shading Language.
My interpretation might be too uncharitable, or yours might be too charitable by taking it at face value, it's pretty difficult to know without having insider knowledge.
I would like to have such simplicity in a potential language that when I see a scene in my minds' eye, it's really easy to transfer to the digital realm. I think the simplicity of representation is key.
Being a web dev on my own hours for the past several years now has given me a pretty solid grip of all the needs of an interactive application, and I can say that there has to be some way for users to easily interact and offer all the possible inlets for the information. Starting a 3D-internet movement might require rethinking the inputs. Won't we just use holo-wands to navigate vast swathes of data rapidly? Run through this field of data sheets...
So yeah, rethinking the medium will naturally come up as a question in conversations around this, and I think that it's simply a matter of keeping "user input" as straightforward and easy as possible, in the local _and_ distributed sense. With that as a foundational block, the rest of the 3D scene can start to make sense.
From a dev perspective my thinking is this. If I were to learn a 3D graphics API for the web I'd like that knowledge to be transferable to native development as well. An API built on Vulcan - even if abstracted - would be more pertinent and more compatible with existing tools than one built on Metal.
I'll be curious to see comments from other committee members as they'd have more insight on the subject.
It is a common observation among game developers who have really tried both that Metal is a much more accessible API than Vulkan; "90% of the performance for 10% of the effort".
Any citation on the matter?
But see this: https://twitter.com/aras_p/status/749546349474054144 https://twitter.com/aras_p/status/767740566792724480
and this:
http://zeuxcg.org/2016/12/01/metal-retrospective/
and this:
I can see two views here. Firstly, that as the open standard, Vulkan should have a privileged position and be supported from the Web side, to make the Vulkan -> Web -> Native abstraction layer standard, small and efficient. As a developer you would just implement the necessary algorithms for your application once, using Vulkan.
The alternative view is that Vulkan is just too low level and doesn't fit in the web security model. Then, the purpose of WebGPU is not to implement Vulkan in Javascript. Instead, it's another target in addition to the existing three: Apple, Microsoft, Kronos, and web. To get maximum performance, developers must write an application-specific, high level platform abstraction layer, and implement that interface for each supported platform.
It seems to me that this article is of the latter view, especially as it doesn't put Metal in a strategically weaker position than Vulkan.
If you don't need state of the art or original rendering techniques and algorithms, I think there is already a high level abstraction which is compatible with the web: OpenGL ES 2, and soon OpenGL ES 3. (WebGL & WebGL 2).
It's a very different situation to macOS, where Apple are the sole gatekeepers of the graphics stack and nothing can ever happen without their direct support.
Considering the lengthy turn-around time for these APIs (WebGL 2.0 took four years to get from a draft spec to enabled in some browsers by default), any Windows machine that couldn't run WebVulkan would be rather long in the tooth by the time the standard sees any real world use.
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.
https://communities.intel.com/thread/104380?start=30&tstart=...
https://software.intel.com/en-us/forums/developing-games-and...
Disclaimer: haven't read the new Apple web 3D spec, just curious about others' opinions.
We expect threadsafety, memory safety, data validation, and memory protection for the shader language to be the big issues.
The main security issues will likely be: * Avoiding out of bounds memory reads * Avoiding threadsafety issues * Figuring out lifetime for everything to avoid enabling out of bounds memory reads * Coming up with a safe and validatable shader format (probably a binary one, which makes validation harder) * Checking correctness of things enough to avoid making drivers completely choke
We haven't figured out a lot of these deeper issues. We don't believe the basic model is intrinsically harder to secure than OpenGL though. In fact, OpenGL's complex drivers make security harder, because exploiting the driver means a kernel exploit, so you have to be super paranoid about what you pass to the OpenGL API. Modern graphics APIs have thinner drivers so there's less risk.
1. What is the (proposed) backward compatibility across devices?
2.Given that it is structured for Metal shaders, what are the plans for other, non-apple devices? I see the hat tip to D3D and Vulkan, but I assume they need to get on board first - any early takers? After all common standard means cross-platform hardware support, something Apple has never really embraced.
Also, Metal was announced June 2014, released September 2014. Vulkan was announced March 2015, released Feb 2016.
I don't see any reason for favoring Vulkan specifically for Web when compared to Metal I can read: "Metal still does a lot of hand holding and behind-the-scenes management for you, while with Vulkan you are responsible for — literally — everything. And man they were NOT kidding when they said that the API is explicit. Its actually quite ridiculous how difficult and detailed the API is." (1)
It was rebranded then, but OpenGL Next was announced in August 2014.
http://www.anandtech.com/show/8363/khronos-announces-next-ge...
But to the people saying use Vulkan for the web API, that wouldn't be a good idea. Vulkan is a very verbose low level API.
Here[1] is a sample for the most basic of renderers (renders a single triangle). That's 1,000 lines of (commented) code. It's not a good fit for web development. A far better solution would be to evolve the current WebGL API, than shoehorn Vulkan into somewhere it was never meant to be.
[1] https://github.com/SaschaWillems/Vulkan/blob/master/triangle...
(edit: I realized this API is mostly designed 1:1 with the Metal API, so the docs for that API have filled in most of the missing pieces)
In general, Vulkan was not designed with the web in mind. For example: Vulkan's design intentionally has a whole lot of undefined behavior. Instead of strictly specifying what happens in all possible accidental cases, they strictly specify what is defined and provide debug layers that help you identify during development when you are unknowingly stepping into bizarro land.
Also, I expect Vulkan was designed with the expectation of process-level isolation being the end-all of security concerns. That's not sufficient for single-process, multi-tab browsers.
Chrome has process isolation, and Firefox is developing process isolation right now. I don't think it makes sense for a new technology stack to go out of its way to support single-process multi-tab browsers.
It does allow you to create pipeline state objects ahead of time like Vulkan and D3D12 but they only include a subset of state (shader + antialiasing state + color/depth attachment state). The rest of the state is set when recording the command buffer.
On the other hand all the big engines already support multiple backends so adding another for yet another API is probably not a problem
As a WebGL replacement and as a 3D API in general, many details of the proposal are strange.
>Since we were building on Apple platforms we picked the Metal Shading Language.
Mature and portable technology...
>pipelineDescriptor.colorAttachments[0].pixelFormat = "BGRA8Unorm";
No enumerations? Are they going to validate strings?
>let vertexData = new Float32Array([ /* some data */ ]); >let vertexBuffer = gpu.createBuffer(vertexData); >commandEncoder.setVertexBuffer(vertexBuffer, 0, 0);
No internal structure?
>commandEncoder.drawPrimitives("triangle", 0, 3);
One triangle? No index buffers?
I don't understand whether they are offering an insultingly dumbed down overview of a rather complete (but presumably ugly) proof of concept implementation or throwing around gratuitously WebGL-incompatible ideas to dominate the standardization process.
The string thing is the way enums tend to be done in modern JS APIs. It's not really a bottleneck but if it turned out to be, we'd go a different way.
That said, from what I read of the proposal there were some interesting and useful ideas. So take those ideas and start going to the meetings to build consensus with the open standards instead of trying to co-opt it (which is how this comes off).
In addition, Apple might want to consider getting WebKit in line with the existing web standards before throwing curve balls. Currently lagging way behind in many areas, which means we have to do much more work for Webkit based browsers than anything from Mozilla, Microsoft or Google, and support for some features isn't even possible.
Don't mean to be a Debbie Downer, and I'm sure the team itself has good intentions, but come on.. Like everyone says the last thing the world needs right now is yet another proposal for a modern Web 3D. It will reset the clock. Again!
I mean can't you pretty much already use low level GPU tech like Vertex Buffers and Shaders already?
Clearly there is a lot of misunderstanding, or at the least passion in regards to Vulkan and Metal. Rather than disregard it as "yeah, we thought about it.. but no". Why not actually help educate us?
> "Metal is a bit higher level than the others and Vulkan is probably the lowest level, but they are about the same performance"
The above is what you claim, but why not actually put it to the test? Compare the two in an open forum, have a fact based discussion, hopefully including benchmarks and code examples, and come up with conclusions. Allow people to correct you (where appropriate), and write a follow up blog post with conclusions.
You seem to also have another point, "Even if Apple supported it, Microsoft doesn't, and therefore WebKit couldn't implement a hypothetical WebVulkan". That's a fair conclusion, and would push the pressure from Apple over to Microsoft, and at that point no one could fault Apple/WebKit from proposing a different design. However, as it stands (i.e. without an open conversation/comparison), you while clearly educated on the matter, come across disingenuous (I'm sorry to be pointing out the truth).
Yes, it's like a Vulkan for the web since it's a competing standard.
I mean if we're only paying attention to desktops than this whole discussion is moot. Safari on the desktop has a pathetically small market share, Chrome and various versions of IE easily dominat it. There's no reason to think that even if we ended up with the equivalent of WebMetal that would seriously boost desktop Safari's market share.
iOS, especially given the rules around alternate browsers, is the reason this discussion is important at all. Those hundreds of millions of devices or where this may matter.
Re: iOS being popular; You're in a bubble, the iOS market share as of 2016Q3 is 12.5%.
As for market share, that's percent of devices sold. By web browsing it's about 25%, and that doesn't include the possibly outsized influence it has due to being so much more common at the top of the market.
Porting an app from OpenGL to Metal is much easier than porting to Vulkan. A naive port to Metal often performs better than the GL version, whereas getting performance out of a Vulkan port is a lot harder [1]. So, I really hope the proposed API will be a C-based API that can also serve as a middle layer on top of Vulkan/D3D12 for lesser mortals like me in writing cross-platform native apps.
[1] aras-p is a Unity dev: https://twitter.com/aras_p/status/628569113053528065 and https://twitter.com/aras_p/status/628569238794543104
Given that nobody wanted to fix the WebSQL proposals (they had already been deployed, and some apps relied on them, making it impossible - good job there) there was no choice but to move to another proposal (IndexedDB).
If you do not understand why tying standards to specific implementations is a bad idea, I feel sorry for you. Good for us, the rest of the industry is - most of the time - smarter than that.
I recommend supporting ffv1 or HEVC Still Profile (where patents don't apply).
Obviously Safari wouldn't matter if Apple allowed other browsers on iOS, but no, they insist on dragging the whole Internet a few years behind.
Which works only on one size of screen? :)
Otherwise it's just an incompatible wart like the getUserMedia implementation was for years, like webaudio still is, and like some of their latest hardware ideas have been.
Polyfill first, engine bloat later
Note that on desktop, OpenCL is dead for NVIDIA too (they've been stuck on 1.2 for ages, they removed their profiler, ...), and AMD's new stuff also dropped OpenCL 2.0 support.
I like OpenCL but it doesn't look like it's going anywhere. The unified compute+graphics APIs are king.
https://jakearchibald.github.io/isserviceworkerready/
Safari is intentionally crippled in several areas. Its very specific and obvious. It is dishonest for you to at this point pretend Apple is going full force for web standards while they are explicitly not implementing features that are available everywhere else. And how those specific features line up directly as features which allow web apps to compete with its native application market.
Edit: To anyone seeing this down-voted. Apple employees typically down-vote stuff like this so please do not take this being greyed as anything but manufactured opinion.
In terms of tracked features they're ahead of Edge with both their stable release and in development (TP) builds.
Don't let your own prejudices distort reality.
Every. single. other. browser. Including desktop Safari.
http://caniuse.com/#feat=es6-module
Like I said, "ahead of the game in a lot of areas", not every area.
I hate websites trying to give me notifications. I like that I don't get stupid prompts from mobile Safari about that kind of thing.
IE: Not Supported
Opera Mini: Not Supported
Chrome for Android: Not Supported
When the alternative is installing an app just for some simple notifications I temporarily want, hell yes I want that option. Let's hope PWAs get there and the browser vendors figure out good UI to deal with them.
We detached this subthread from https://news.ycombinator.com/item?id=13593606 and marked it off-topic.
We need concise, clear and coherent code.
Currently, it's not possible to access a user's microphone or webcam in Safari (desktop and iOS). They're the major outlier when compared to other browser vendors: http://caniuse.com/#search=getusermedia
Vulkan isn't available on the Mac huh? Yeah Apple, and just who's fault is that??
We have seen this before - fortunately no matter how much money they put behind this bad idea, the internet is larger than apple, and open standard apis and choice will eventually win.
I don't want an apple api, I don't want yet-another-kool-language-fad they will drop in the next marketing cycle, I want old style javascript to run fast and be standards compliant on mobile, including on iOS devices.