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