Apple proposes new web 3D graphics API(webkit.org)
webkit.org
Apple proposes new web 3D graphics API
https://webkit.org/blog/7380/next-generation-3d-graphics-on-the-web/
626 comments
We're not complaining, we're explaining the lay of the land. Working on top of all three of these APIs is totally doable and will result in a better API for the web.
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.
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.
> I understand your desire to have Vulkan on Apple platforms, but it's really a separate issue from the right target for WebGPU.
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?
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?
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.
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.
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 what you are going to find is that there is a lot of frustration w.r.t. Apple not supporting Vulkan. One system for everything else and one system for Apple.
> 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.
> 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.
> 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.
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.
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.
Those are pretty subjective assertions. Do you have any evidence to back that up?
Do you have any evidence for your claim that Vulkan is best? Metal and D3D 12 are also low-level APIs designed for performance. I've seen no evidence that Vulkan is better on platforms where there are drivers for two different APIs.
I think we've all gone a bit off the rails here.
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)?
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)?
Making a new standard is inevitable. That's not really a choice.
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.
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.
> 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?
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?
Tying the implementation to a single underlying API is just another kind of lock-in. You can be locked in to an open standard just as much as a proprietary one. Suppose this had been proposed 5 years ago and been tied deeply into OpenGL? In the world of today, that would pretty much make it a dead end. It's just not the job of a standard like this to pick and choose winners at a different level of abstraction.
When you look at the amount of effort that's gone into SPIR-V you'll only have one conclusion to this question.
This brings another question. Would it be better given the likely use cases for WebGPU to be designed as a WebAssembly only API?
WebAssembly doesn't currently have a way to expose APIs to it directly. It only has an interface to call JavaScript.
Maybe that will change, but blocking on a major new WebAssembly feature did not seem wise.
Maybe that will change, but blocking on a major new WebAssembly feature did not seem wise.
Why is making a new standard inevitable?
Well, I guess you know all this but you've asked me to elaborate. So, in terms of compatibility you have:
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.
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.
It makes no sense to judge the quality of an API by the power of the available hardware it might be running on. The discussion is not about what platform will run VR the best.
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.
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.
> It makes no sense to judge the quality of an API by the power of the available hardware it might be running on.
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)
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)
You did make such a judgement- you wrote:
> 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.
It does, though.
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).
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).
There's nothing subjective about it. Take a look at the APIs, they operate at the same level and are designed around the same principles.
As for past driver quality, ask a graphics developer doing anything more complicated than a toy weekend project. OpenGL drivers are inconsistent and buggy.
As for past driver quality, ask a graphics developer doing anything more complicated than a toy weekend project. OpenGL drivers are inconsistent and buggy.
> Just because it was designed to be high-performance doesn't mean it automatically wins on platform support and implementation quality.
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 :)
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 :)
I make no argument against what you've said except you used Valve as an "appeal to authority", when they have a vested interest in promoting Vulkan (since SteamOS is based on Linux). So of course they will be persuading developers to use Vulkan over DX12, because it broadens the domain of users who can buy an individual title on Steam.
If you look up the endorsement by Valve, it's not just a straight up "Use Vulkan" but a well reasoned set of arguments and case studies by people with a lot of experience. So, this is not an "appeal to authority", but a reference to an existing body of research which supports my assertions.
By "platform support," I was not referring to the number of platforms supported by the API, but the quality of support for the API provided by the platform(s). Vulkan objectively loses to D3D and Metal here.
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.
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.
The Vulkan development process is very different from OpenGL. It's a significant improvement so it's not fair to make this judgement. There is significant evidence: The quality of the API, the number of platforms supported within the first 12 months of publication, the availability of source code and documentation on GitHub (including allowing contributions). These are all things which are far better than the equivalent DX model, and also, in comparison, OpenGL.
None of that directly impacts Vulkan driver implementation quality (which is not open source at all).
Vulkan isn't designed for adversarial input. The web language has to be. That alone is likely to require a ground-up redesign.
But OpenGL wasn't either. I'd like to hear concrete examples of how it couldn't be made workable. There are already validation layers that do a pretty good job of checking for bad usage.
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.
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.
We did evaluate the option of using Vulkan. So have others. It's not even necessarily off the table, we just don't think it is the best design approach.
If you are very interested in the details of API design choices, then I'd suggest joining the Community Group. Anyone can join!
If you are very interested in the details of API design choices, then I'd suggest joining the Community Group. Anyone can join!
Which is a good example why I don't have any issues with native code on OpenGL ES 3.x mobiles, while Chrome with WebGL is just choppy and dropping frames left and right.
Naw, that's happening because you have a JS thread doing everything. Native code on OpenGL ES is structured very differently.
I'd argue that Vulkan IS designed for adversarial input. It deliberately provides a layer mechanism within the driver for validation of function calls. It's trivial to create your own layers and they can be used to validate EVERY entry point into the Vulkan driver.
Validation layers were created so drivers could remove checks to improve performance. And regardless, properly handling adversarial input is much more involved than just a validation layer.
Yes, you are right, but solving the problem of adversarial input is probably NP. A validation layer can intercept every API call and validate it. It's probably the best you can do. The nice thing about it, is that you could actually use it in many different contexts, since, you know, Vulkan makes it a standard feature of the driver.
It's not NP (whatever that means) if you're allowed to change the API instead of just inserting checks at each call.
Besides, Javascript doesn't really need driver support to intercept function calls...
Besides, Javascript doesn't really need driver support to intercept function calls...
NP means non-determinstically polynomial. Validating a GPU shader is undecidable if it include flow control. This is a problem for security.
> 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.
> 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.
I know what NP means, my parenthetical implied that you used it in a way that made no sense.
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.
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.
> remove checks to improve performance
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.
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.
> One system for everything else and one system for Apple.
This seems to have worked out pretty well for innovation in the mobile OS market, no?
This seems to have worked out pretty well for innovation in the mobile OS market, no?
Yes, for Apple... For the consumer? I don't think so.
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?
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?
> Are apps compatible between platforms
That would be an awful experience for the consumers, UI/UX-wise.
That would be an awful experience for the consumers, UI/UX-wise.
And yet somehow web apps, each with their very own shirty UI and UX, that looks and works completely different than the platform you use them from, are doing just fine.
And the vast majority of webapps are shitty UI/UX from a consumer perspective. Doing just fine with shitty UI/EX, because the platform is crippled does not equal the best solution for the user.
I completely agree!
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...
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...
Web apps just have lower standards.
It wouldn't need to be. The application could have different UI/UX models based on the expectations of the user.
As a developer I see this as a "damned if you do, damned if you don't" issue. Professionally I develop an application with Linux and Windows support, it is a pain and requires a great investment in time. Of course one could use a web technology such as Electron but then you get insulted because of memory hogging, non optimization and disrespect for UX. Developing an iOS and Android application the right way practically takes twice as much time.
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.
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.
Consumers don't appear to be bothered by any of those missing freedoms.
Consumers are bothered by games that get released much later (or not at all) on iOS instead of Android, or the other way around. They're not directly bothered by the cause, but they sure as hell hate the symptoms.
I don't like it, but I think consumers are pretty accepting of platform exclusives.
Not really. Gamers don't like exclusives, when they are excluded especially. Why would they like to be excluded?
it's hard to be consciously bothered by the lack of something that you've never experienced?
That's a faulty generalisation. I am a "consumer" and I'm bothered by it.
There are definitely consumers who care. There are a lot of them here on hacker news.
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.
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.
So, if you know that, don't say "Consumers don't appear to be bothered by any of those missing freedoms."
Say something like "Apple is still successful despite the lack of freedom" :)
Say something like "Apple is still successful despite the lack of freedom" :)
Men in America also don't appear to be bothered by having been circumcised, but that is only due to their lack of knowledge and should not be used as evidence that "routine infant circumcision has worked out pretty well for health outcomes in America".
That was an interesting non sequitur...
It is not a non sequitur: it is the same argument applied to another situation where people fall into the same trap of lack of knowledge leading to a lack of understanding of their own plight (we might even call it a "blissful ignorance"). The other person who responded to the same parent comment saying "it's hard to be consciously bothered by the lack of something that you've never experienced?" could have been leaving that exact same comment with respect to having an intact foreskin in response to someone claiming the point about circumcision.
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).
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).
OT, but I'm an uncircumcised gay guy who has had a fair amount of experience with both types of penis. I suspect that anyone who's all beat up about being circumcised (except a small minority of people who have had botched circumcisions) is projecting some other problem with their sex life onto that. Both types of penis work perfectly fine.
Vulkan is not suitable for exposure directly to the web. Full stop.
Therefore your posts are off-topic.
Therefore your posts are off-topic.
Do you even know how Vulkan works?
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.
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.
Yes, I do. I'm also slightly familiar with OpenGL and Metal.
I think Metal has a better API. You are free to disagree of course.
I think Metal has a better API. You are free to disagree of course.
The persons in favor of Vulkan in this thread don't have to prove their point, you have. Their solution works, is battle tested, is cross platform and almost an industry standard.
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.
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.
> On this one, you are guilty until proven innocent, I'm sorry
Or rather, he's got to refute the null hypothesis.
Or rather, he's got to refute the null hypothesis.
In the case of web standards, the null hypothesis is "no new API" rather than "make something that works only on top of this specific native API". For the web, the latter is not even the default assumption once you've decided something needs to be added. The web is cross-platform by design.
>In the case of web standards, the null hypothesis is "no new API"
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".
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".
I understand and see some merit to your angle, but at the end of the day, I don't think Apple will be taken seriously in that area until they support Vulkan.
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.
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.
Apple will always be taken seriously since they are not just a major mobile vendor but the only vendor capable of getting any technology widely deployed.
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.
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.
> 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.
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.
Serious question, have you ever written any nontrivial code using Vulkan?
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.
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.
[deleted]
> Lots of design work needs to be done.
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.
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.
Why so combative? How is a JavaScript API standard going to benefit from Vulkan support on Apple platforms? More specifically, how will a JS API benefit from being built exclusively for Vulkan, instead of multiple "APIs that have nuanced architectural differences", to borrow Dean's phrase?
To the extent that Vulkan has capabilities or features that don't map perfectly to Metal capabilities and features, native Apple Vulkan support would increase the performance and capabilities, and reduce the complexity and bugginess, of a hypothetical WebVulkan implementation on Apple platforms. And by reducing the compromises that have to be made for platform compatibility it would benefit the API design on all platforms.
You can simplify the design and reduce bloat if you don't need to address multiple APIs as backend.
To play devil's advocate: Isn't a big focus of web tech the goal of supporting multiple backends for everything? If a new platform wants to support WebGPU but not Vulkan (ex: XBone or PS4) it should be not just theoretically possible, but actively supported by the design of the Web spec.
Good point.
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.
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.
"it should be not just theoretically possible, but actively supported by the design of the Web spec."
> But, that's assuming that it's not possible to write a wrapper on top of DX (for Xbone) that proves a Vulkan API.
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.
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.
No, it's pointless to do that. Why all the extra overhead? Vulkan talks directly to the hardware driver.
Could be, but PS and Xbox don't support Vulkan for the same bad reasons (lock-in), so messing up the spec because of that doesn't sound convincing.
[deleted]
> 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.
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?
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?
> Why can't Apple let developer decide what to use?
Wouldn't that be just about the opposite of everything Apple has stood for the last ten years?
Wouldn't that be just about the opposite of everything Apple has stood for the last ten years?
You wanna focus this discussion on improving the web platform? Great, start with finally shipping WebRTC.
Relax--they’re working on it: https://webkit.org/status/#specification-webrtc
What people seem to be missing here is that based on available info it seems Microsoft isn't officially supporting Vulkan either. Sure Nvidia and AMD have released drivers for Windows that have Vulkan support, but we're talking about a web standard that would need to be implemented by browser makers and if Microsoft isn't going to use Vulkan, then what do they implement as the backing for this new standard in Edge? Probably DirectX. I think the idea is to sort out an API that would be compatible between all three due to Microsoft and Apple _both_ not wanting to officially support Vulkan over their own platforms in their browsers, regardless of the support at the OS level.
There is a difference between "not officially supporting" Vulkan and completely preventing anyone from providing a Vulkan implementation for your platform. Microsoft allows competing APIs to be integrated into their platform at the driver level. Apple does not.
FWIW, Microsoft doesn't allow that on ARM. Only where they have previous antitrust decisions holding them back (x86).
It used to be the case that 3D APIs other than Direct3D couldn't be used from whatever Metro^H Windows Store apps are called this week. Which kind of blocks it at a platform-within-a-platform level.
That may have changed, I dunno.
That may have changed, I dunno.
Could someone not provide Vulkan driver support on the Mac or is it forbidden by Apple to do so?
On Windows, Vulkan support is provided by the IHV graphics drivers from Nvidia, AMD etc. On Mac, Apple themselves ship the drivers (incorporating some portions of IHV code, but ultimately all under Apple's control).
If you're using a newer Nvidia card, you can download and install much more up to date Mac drivers direct from Nvidia's site. Yes, Apple bundles their own drivers but there's nothing stopping hardware vendors from shipping their own Mac drivers.
That still wont change the version of OpenGL supported by the driver as far as I know. If someone has OpenGL 4.5 working on OSX I would be very interested in finding out.
Apple allows you to provide an alternative API on OSX but not on iOS.
Microsoft is exactly the same. They do not support custom APIs on Windows Mobile AFAIK.
Microsoft is exactly the same. They do not support custom APIs on Windows Mobile AFAIK.
> Apple allows you to provide an alternative API on OSX
I'll need a source for this claim considering that no driver-level Vulkan implementations are available on macOS.
I'll need a source for this claim considering that no driver-level Vulkan implementations are available on macOS.
macOS is not popular among gamers? I don't understand what the problem is.
No. Provide a source that Apple actively prevents it.
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.
kext's must be signed now, Apple can freely revoke developer certs and block them if they so desire.
Signing was designed for security purposes which is the only reason where certificate revocation has been used to date. There seems to be a lot of FUD here but without any actual hard examples.
But it prevents doing what you just said above :
> 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.
Having a technical means to make distribution of a driver awkward is quite a few steps short of forbidding it.
But they only use these power to shut out malware. Not to nix software they don't like.
Windows drivers need to be signed as well, whats the problem?
But not by Microsoft, you can opt to obtain WHQL certification for your driver and have MS sign them - but it's also acceptable to get a code signing cert from any trusted CA.
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).
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).
> sudo to root and largely do whatever they want
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
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
It's easy to disable System Integrity Protection:
https://developer.apple.com/library/content/documentation/Se...
https://developer.apple.com/library/content/documentation/Se...
Let's not forget the post I was replying to :
> 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.
> 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.
Sure, and your grandma (=proxy for mainstream user) is surely going to do that.
It's simply a no-go for the mainstream market that expects things to just work.
It's simply a no-go for the mainstream market that expects things to just work.
It's a dead platform with no market-share.
Latest results of the so-called dead platform--"iPhone, Services, Mac and Apple Watch Set All-Time Records"
http://www.apple.com/newsroom/2017/01/apple-reports-record-f...
http://www.apple.com/newsroom/2017/01/apple-reports-record-f...
Why are they so hostile to Vulkan and what problems does Vulkan, which is vendor independent and open, have that adding a new API to support to the pile would not?
No good reason whatsoever.
Do you have a source for your claim?
Lack of known good reasons, and their major infamy in perpetuating lock-in in general. They have only themselves to blame for being seen in negative light in this topic by default.
That doesn't mean their isn't good reason. I guess they believe they can build a better product by having control over the graphics pipeline. Obviously I cannot say for sure what they think in that regard, but neither can you.
Not very convincing. They often used excuses of good reasons to do sinister stuff, so, they'd need to work much harder to fix their ruined reputation.
> Microsoft isn't officially supporting Vulkan either
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.
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.
I was under the impression that DX wasn't available out of the box either? That you'd need to install suitable drivers and a suitable runtime?
Also HN seems to forget consoles a lot, which don't support OpenGL (PS3 GL was never used in production), even Nintendo with Switch actually does have another API besides Vulkan(NVN), which devs are more keen in using as it allows even more fine grained control.
I'm sure Microsoft has an interest in a 3D web API working on top of D3D, even if NVIDIA and AMDS are putting out Vulkan drivers for the platform (Microsoft is not supporting Vulkan themselves as far as I can tell).
Anyway, WebVR support is shaky on most browsers, except Firefox / Nightly where it works properly. Get that working before WebGL 2 or whatever. And throw in some support for external GPUs. Moved away from Apple and got myself an Intel NUC i7 w/ Thunderbolt. Better everything in there. Can use external GPUs of all kinds for easy testing. Apple may have had its best quarter ever but is not sexy to me anymore.
Yeah, support Vulkan.
Yeah, support Vulkan.
> I understand your desire to have Vulkan on Apple platforms, but
There are no 'but's. Just support it and we can have simpler APIs on top of it.
There are no 'but's. Just support it and we can have simpler APIs on top of it.
I agree
While I agree with you, I doubt some random webkit engineer has any power saying what to support.
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.
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.
Then why should W3C accept the views of that higher execs as something useful for the Web? Let them remain Apple only.
The optics are just really bad. Apple could say "In the mean time we'll support Vulkan" and bam! there is a cross platform solution. Instead you say "We will generously let everyone implement our specifications, we hate to see everyone suffering so, but if everyone else works really hard to do what we say, things will be great!"
I don't get what you are suggesting. Apple supporting Vulkan on macOS and iOS wouldn't do anything to expose a new GPU API to the web. They are totally orthogonal. We're expecting work on the new web API to be super collaborative, so your framing is uncharitable and incorrect.
Not trying to be uncharitable here, I'm just sharing how it looks to someone driving by.
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.
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.
But isn't the Vulcan situation on windows similar to the OpenGL one? You need to install drivers...
In which case won't browser makers target directx anyway, as they have with webgl?
In which case won't browser makers target directx anyway, as they have with webgl?
Why would Microsoft behave any differently to this new API when they have not officially supported previous open attempts?
Adding another standard to the mix just seems to be compounding the problem to me.
Adding another standard to the mix just seems to be compounding the problem to me.
I think it's a bit disingenuous to say they're totally orthogonal. Presumably you understand that if Apple supported Vulkan natively, then "WebVulkan" would be the obvious choice for a web API (just as it was with OpenGL/WebGL).
I don't think browsers will choose to pipe this through Vulkan drivers on Windows (since they are all unofficial and in general don't have as complete coverage) and I don't think they'd choose to use unofficial Vulkan drivers for Apple platforms either, even if they existed.
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.
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.
> 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.
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.
It's likely there will be a need for a C++-level meta-API that can work on top of Vulkan, D3D and Metal. There's already been discussion of making such a thing. It would be nice if that could be exposed to WebAssembly via Emscripten.
But to what degree might this 'meta-API' be different than WebGPU/JS? Might this effort effectively end up creating two, new APIs, each with different vocabularies (one for JS, another for C or C++)?
I mean, that's going to happen anyway.
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.
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.
What does "unofficial" mean here? AFAIK Vulkan is fully supported by the current versions of both AMD and Nvidia's Windows drivers, which seems about as official as a driver can get.
So who stops Apple (and MS for that matter) from making it official? If it's about collaboration, let them grow up and stop their petty lock-in games. And if not, I don't think anyone should accept proposals coming from them for such things.
The proposal in this case appears to be coming from the safari group rather than the metal one.
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.
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.
If Apple supported Vulkan, all major platforms would support the same API. Exposing this to the web would be relatively straight forward. So, I don't think your assertion that they are orthogonal goals is correct.
Why come up with a new API for this? Why not use the one supported by Google, and MS, Vulkan? We dont need another (a fourth!) API for the same thing.
Introduce a web variant like Khronos with with WebGL (its almost like OpenGL ES, which is almost like OpenGL).
> Why not use the one supported by Google, and MS, Vulkan?
https://www.lunarg.com/faqs/microsoft-support-vulkan/
"Microsoft has not expressed intent to support Vulkan."
https://www.lunarg.com/faqs/microsoft-support-vulkan/
"Microsoft has not expressed intent to support Vulkan."
and the next sentence goes "However, there are well defined mechanisms by which IHVs can ship a Vulkan driver on any version of Windows. But it will be as it is the case now with OpenGL. That is, it is up to the application to negotiate with the implementation to install an appropriate Vulkan driver for the hardware that is on the machine."
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.
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.
Someone else mentioned that they don't care about Nvidia and AMD both advocating for Vulkan because I'm personally not interested in the big desktop PCs
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.
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.
Intel has only released beta/test drivers for Windows, and this was their statement as of August:
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.
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.
Intel has (unofficially?) said they will deliver production quality Vulkan drivers for their iGPUs. https://software.intel.com/en-us/forums/developing-games-and...
Thanks for providing the link. The relevant quotes:
"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"
"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 8 and older power more than half of Windows PCs, so Direct3D 12 is no more widely deployed than Vulkan.
[deleted]
> by all vendors
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.
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.
Then which vendors do you care about from the Microsoft ecosystem (which this thread is about)? Vulkan is supported by Nvidia, AMD and Intel, I think this covers >99% of the Windows landscape. Windows phone? or Xbox? Hololens?
Intel does not support Vulkan. They had some beta drivers for devs to test on, but no further plans
This is not true. Intel has (unofficially?) said they will deliver production quality Vulkan drivers for their iGPUs. https://software.intel.com/en-us/forums/developing-games-and...
[deleted]
They don't need to support it, because the GPU vendors have done so in their drivers, so it works fine on Windows without Microsoft's assistance.
Not on UWP applications, which are the future.
They've been saying that for a few years, but nobody seems to be buying it. The store is still a wasteland of mobile-style shovelware, and none of the real Windows applications have made the jump, far as I have seen.
Many of the Windows 10 applications like the file explorer and Edge are UWP.
Also the majority of all the new OS APIs are UWP only.
Also the majority of all the new OS APIs are UWP only.
I dontknow, what are you trying to prove?
Its a fact that from the new, low-level APIs (Vulkan, Metal, DX 12) Vulkan has the most widespread support:
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.
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.
> 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.
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.
https://www.youtube.com/watch?v=ynyO3O3zd3E
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.
https://www.youtube.com/watch?v=ynyO3O3zd3E
> Apple supporting Vulkan on macOS and iOS wouldn't do anything to expose a new GPU API to the web. They are totally orthogonal.
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 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 Metal Shader Language use in our prototype is totally a placeholder, and the post says so. We expect the standards process to define new source and binary representations, possibly based on Khronos's SPIR-V.
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 shader language is partly independent of the API though, and we though the API was the interesting thing to prototype, more so than shaders.
That's already something. But you shouldn't have started with a bad placeholder, waiting for others to criticize and propose replacing it. Start with open languages and technologies right away.
Should they have invented a different place holder (and all the work that would require) just to throw it away and be all data they weren't using the shader language that Vulcan uses?
The post was VERY clear that that was temporary while working on the other basics and a real decision would be made later.
The post was VERY clear that that was temporary while working on the other basics and a real decision would be made later.
This shows, that this idea wasn't thought through enough. And coming from Apple, it raises a concern naturally. These things should have solid foundations from the start.
> This shows, that this idea wasn't thought through enough.
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.
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.
MSL is a non starter, because it's closed. Making a project from scratch that invites collaboration, requires thinking about such issues in advance and having them at the very foundation. That's my whole point. Failure to do it, is not an encouraging sign.
> 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.
> 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.
They explicitly said that it's a placeholder. They weren't suggesting it be used. It was just something easy for them to rig up for their initial demo.
I think you're reading a lot of intention that isn't there into that placeholder.
I think you're reading a lot of intention that isn't there into that placeholder.
Don't bother, they clearly don't get it.
I have to agree. They lack credibility in this discussion. Apple's abandonment of open standards on the desktop leaves their proposal of related web standards looking very cynical.
...but Vulcan wouldnt run in a web browser anyway so whether Apple platforms support Vulcan or not is kind of beside the point, isnt it?
That's like saying "OpenGL doesn't run in a web browser"... and then it did, because someone understood that having 99% the same API and shader language support in a web browser as what is used in native applications is extremely high value.
It runs in a web browser sitting on top of different underlying apis though. Which is basically what's being suggest here.
Many of the people in this thread are looking for the analogous solution to WebGL for Vulkan, and the primary argument for not doing it from the WebKit engineers is that Vulkan is a lower-level API than Metal and DirectX 12, which makes it difficult to impossible to simulate efficiently on top of those APIs; but, this is actually only a problem because Apple refuses to implement Vulkan.
[deleted]
> We're not complaining, we're explaining the lay of the land.
No, you're stating your own company's ambition.
No, you're stating your own company's ambition.
While I have your attention - what can be done to improve the state of Vulkan and OpenGL on the mac - its the single biggest reason for me to ragequit the OSX platform every time I try to give it a shot.
I think you'll want to talk to Apple Developer Relations and see if they can put you in touch with the teams responsible for the GPU-level stuff. We as the browser team can't do much with this feedback.
I will try do do this, though I remain sceptical that this will lead to anything. Not supporting external graphics APIs and Apple effectively controlling the drivers seems to be more of a business decision to me than a decision from a tech / dev relations team. Unless someone high up at Apple takes a call that supporting something like Vulkan / OpenGL is the path forward I doubt that this can be solved in a bottom up manner.
Hi om2, this is completely off-topic, but I'm so intrigued that Safari devs are actually chatting openly about their product, I figured what the heck I'd ask something.
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!
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!
I appreciate the list of issues affecting home screen web apps on iOS. We're looking into improving how they work. I can't promise any specific set of improvements or timeline but we are aware of the issues you mention.
Appreciate the willingness to address it, it would be the completest thing if HTML5 Apps worked as well as safari tabs. Very empowering thing for you to do for us web devs, thanks!
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.
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.
It is a serious problem for the future of Apple that they have almost completely lost the support of software developers. It used to be that most software developers had MacBook Pros and, the ones that didn't wished they did. Now software developers are generally buying non-Apple machines and running Linux or Windows. In the short term, this is only a tiny market so the loss of sales is irrelevant but, these people are people that other people look to when they are deciding what to buy and, they are people that develop software that other people use. If there is no decent software for Mac OS because none of the developers who would otherwise write it and release it use it anymore, it will make it much harder for other people to use. Both of these are long term effects and, it is too soon to show their effect on sales but, they are important. Since the release of Mac OS X, it has been an attractive platform for developers but, this has completely changed in the last couple of years and, the only reason to use it now is for iOS development IMHO.
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.
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.
Oh please. Stop claiming every pet issue you have is shared by every developer and that it's "already too late."
Where do I point to any "pet issues"?
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.
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.
FWIW, I agree with you. The most recent macbook 'pro' release has caused a majority of the devs I know say 'screw this' and trade their macbooks in for surfaces. Not exaggerating. Apple should be concerned.
Apple sold a record breaking amount of tbMBPs in the quarter since its release.
The HN echo chamber is strong, but its silly anecdotes don't reflect reality.
The HN echo chamber is strong, but its silly anecdotes don't reflect reality.
Perhaps I was being unclear- I don't doubt that they sold a ton of them. The length of time since the previous update alone would ensure pent-up demand.
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.
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.
Not true on Apple selling a record amount of Macs. Apparently they added 7 days to the quarter versus a year before and therefore Mac sales declined again. For 2016 Mac sales also declined compared to 2015. Apple Mac sales declining is tied to the lack of new OS X software, IMO. Otherwise why decline?
Here is the Apple data and you can see for 2016 Mac sales declined 14%.
http://www.apple.com/newsroom/2016/10/apple
http://www.apple.com/newsroom/2016/10/apple
Not the person to whom you are asking, but this is my perception of Apple.
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 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
"We're not complaining, we're explaining the lay of the land."
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.
[0]: https://moltengl.com/moltenvk/
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.
[0]: https://moltengl.com/moltenvk/
Vulkan on Windows is all based on unofficial drivers that don't come with Windows and aren't supported by MS. We don't think it's right to depend on this even if it's theoretically possible. Likewise for unofficial macOS/iOS drivers.
> Vulkan on Windows is all based on unofficial drivers that don't come with Windows and aren't supported by MS.
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.
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.
As it happens, OpenGL was so high level that supporting it on top of DirectX was feasible. A number of Windows browsers use the DirectX back end to ANGLE, so users don't have to download OpenGL drives.
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.
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.
Since WebGL was released, Microsoft has demonstrated a new willingness to support Web graphics. They joined Khronos, and now ship a WebGL implementation of their own with Windows. I have confidence that if the industry moved toward a WebVulkan standard that this new Microsoft would make platform changes to better support it. Unfortunately I have no such confidence about Apple.
I would much prefer hardware vendor supplied drivers since they have an active interest in adding support for newer versions of graphics apis. OS vendors have proven to have a very poor track record supporting newer versions of graphics apis that they did not create themselves. (Microsoft support for OpenGL on Windows and OpenGL/Vulkan support on Mac). Calling driver vendors "unofficial" seems a bit backwards to me.
You're leaving out the "official" counterpart- Direct3D drivers. Microsoft and hardware vendors both have an active interest in adding support for new versions there.
Microsoft has interest for pushing new versions only in new OS releases and uses that to push these new OS releases - see DirectX since 10.
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.
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.
Is it your position that the only drivers worth using are those produced by the operating system's vendor? While I suppose this would make sense to Apple, it sounds entirely crazy to me. IMHO, it makes much more sense for the hardware vendor to write the drivers.
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 install graphics drivers.
In the case of Windows, the operating system installs proper drivers automatically. I don't recall if these are the exact same ones from, say, the NVIDIA or AMD or Intel website, but I'd be very surprised if these drivers didn't nonetheless ship with Vulkan support.
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. :)
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. :)
I'm not saying that operating system provided drivers should be ignored, but that it makes no sense to ignore vendor provided drivers either. In this case we have all the major GPU vendors on board with the standard, yet Apple claims that since the OS vendor (i.e. Apple themselves) doesn't produce the driver, it shouldn't be depended upon.
What do you mean by "unofficial drivers"? Looking at the support matrix on Wikipedia, it seems that both NVIDIA and ATI support it in their official Windows drivers.
I guess he means that Microsoft isn't aggressive enough in distributing these drivers via Windows Update. Definitely the case with older Windows versions like Windows 7 where Windows Update doesn't seem to offer GPU driver updates at all if you have manually installed something like the driver cd that was in the GPU box. However with Windows 10 they have gotten more aggresive in updating these drivers. [1] Still, a lot of people on older Windows versions where the GPU drivers are likely out of date enough not to contain Vulkan.
[1] http://winsupersite.com/windows-10/stop-automatic-driver-upd...
[1] http://winsupersite.com/windows-10/stop-automatic-driver-upd...
"Still, a lot of people on older Windows versions where the GPU drivers are likely out of date enough not to contain Vulkan."
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.
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.
DirectX 12 is only available on Windows 10, so that's the case regardless of drivers.
I believe he means unofficial as in not provided by Microsoft. Microsoft works to make sure Direct3D works and I imagine they have lots of tests and compatibility suites there. I'm guessing they don't have any tests or standards were requirements around Vulcan.
> I believe he means unofficial as in not provided by Microsoft.
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.
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.
NVIDIA/AMD drivers with Vulkan support pass through WHQL, which is as official as a 3rd party driver can get.
So calling them unsupported/unofficial is quite a stretch.
So calling them unsupported/unofficial is quite a stretch.
Intel's drivers may be beta but official NVIDIA and AMD GPU drivers both fully support Vulkan on Windows.
> We don't think it's right to depend on this even if it's theoretically possible.
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?
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?
I'd hardly call the drivers distributed both via Windows Update and via the vendors' own websites "unofficial". They're about as official as it gets.
> Vulkan on Windows is all based on unofficial drivers
Drivers from GPU vendors are as official as it gets.
Drivers from GPU vendors are as official as it gets.
> We don't think it's right to depend on this even if it's theoretically possible. Likewise for unofficial macOS/iOS drivers.
Then focus on fixing that, instead of wasting time on bullshit like this.
Then focus on fixing that, instead of wasting time on bullshit like this.
As an outsider, I'm very curious as to why this was downvoted. Is it incorrect? I know nothing about 3D platforms.
You say Vulkan drivers will, for the forseeable future, be of lower quality than D3D12 drivers and lack official support. Lets assume I blindly accept this faith-based argument. WebGPU than, must be implemented on top of D3D12 and Metal, two already very different APIs. What, than, makes a hypothetical WebVulkan unfeasible in contrast to WebGPU?
Keep in mind that DX12 doesn't support Windows 7 or 8, so that cuts out a significant portion of the existing market.
Still higher than GNU/Linux will ever be.
Not if you take Android into account.
Which is why I have precisely written GNU/Linux.
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...
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...
It has the Linux kernel you just bring the GNU or whatever you need. But Google now supports containers on ChromeOS so if access you can just run in a container and the use Android X Windows server on same box.
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.
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.
Correct, Android is not GNU/Linux, I responded too fast.
As the parent comment spoke about DirectX support, I should have phrased it 'Android is also in the camp of "Doesn't support DirectX" and counts for a large number of devices.'
A hypothetical WebVulkan is tied to an API that it is guaranteed to have to translate from. A hypothetical WebGPU could simply be tweaked to better support its multiple target APIs.
The straightforward translation and predictability of a hypothetical WebVulkan is a strong point in its favor. WebGPU's JavaScript interface can be changed arbitrarily, yes; there is nothing simple about that process.
Vulkan (and similar APIs) are straightforward as translation targets, not so much as sources.
Vulkan is a lower level API, so implementing it on higher level APIs becomes problematic.
Why is DirectX support needed? Isn't Vulkan supported on the same platforms as DirectX anyway?
We expect DirectX 12 drivers to be more complete, more performant, and more likely to be available out of the box without a separate install. We expect Windows browsers will want to build on top of DirectX, not Vulkan.
https://www.lunarg.com/faqs/microsoft-support-vulkan/
Microsoft won't support Vulkan officially, and apps would have to install their own Vulkan drivers.
Microsoft won't support Vulkan officially, and apps would have to install their own Vulkan drivers.
Not true, Vulcan drivers are included in drivers of the GPU manufacturer.
No, Nvidia and AMD including Vulcan drivers. Intel isn't and said they don't plan to. Intel has a HUGE market share thanks to integrated graphics. There are other companies too.
> https://software.intel.com/en-us/blogs/2016/03/14/new-intel-...
"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.
"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.
According to https://software.intel.com/en-us/forums/developing-games-and... Intel DOES plan on releasing official production quality drivers at some point.
> There are other companies too.
In addition to what people have said about Intel, Qualcomm, ARM, and IMG are all behind Vulkan. Who else is making GPUs these days?
In addition to what people have said about Intel, Qualcomm, ARM, and IMG are all behind Vulkan. Who else is making GPUs these days?
[deleted]
I don't see why this would be the case. The vendors (i.e. NVidia) are providing the drivers, I see no reason why they would porposely cripple them.
It's the current reality with OpenGL on Windows, which is why Windows browsers do not implement WebGL with OpenGL, but rather by translating to Direct3D.
Maybe it'll be different for Vulkan, but that would be a surprise.
Maybe it'll be different for Vulkan, but that would be a surprise.
Because they have been doing so with OpenGL (an identical situation) for years.
Besides, "purposefully cripple" is inaccurate. They just put more effort into Direct3D because there's no reason to support OpenGL as fully.
Besides, "purposefully cripple" is inaccurate. They just put more effort into Direct3D because there's no reason to support OpenGL as fully.
Including the SDKs, AMD and NVidia SDKs for a long time used to have better DirectX tooling than OpenGL.
Care to back up those assertions with real world evidence?
Chrome and Firefox felt there were sufficient problems with OpenGL driver availabity that they implemented WebGL using DirectX (via the ANGLE project), despite the more obvious mapping to OpenGL.
Is there any reason to believe that, unlike OpenGL, Vulkan drivers will be sufficiently widespread for browser vendors to use it on Windows?
Is there any reason to believe that, unlike OpenGL, Vulkan drivers will be sufficiently widespread for browser vendors to use it on Windows?
That's really fascinating and I didn't know that.
Intel has no stated intention of releasing production-quality Vulkan drivers for Windows. Forum statement from August:
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.
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.
A quick google finds an Intel representative providing clarification: https://software.intel.com/en-us/forums/developing-games-and...
So, they ARE planning full Vulkan support on Intel iGPUs.
So, they ARE planning full Vulkan support on Intel iGPUs.
Good find, it's a shame that the only info is buried in forums and there's no timeline or official statements.
xbox
Concrete example: The PS4 dashboard is actually WebGL via Chromium (https://www.youtube.com/watch?v=sIhtcUvi0BQ&t=55m25s) I don't think PS4 supports OpenGL, DX or Vulkan. Sony has their own API.
Sony has historically supported a variant of OpenGL on the PS3 (in addition to their low level API) - I would be surprised if they don't have one for the PS4.
I worked on PS3. PSGL is the half-truth rumor that refuses to die. It was an experimental GLES1.0 with Nvidia's Cg shaders as an extension. I don't think any games actually used it.
https://en.m.wikipedia.org/wiki/PSGL
https://en.m.wikipedia.org/wiki/PSGL
Besides what corysama replied, there are a few game blogs that described how bad it was, but I cannot link to them as I am behind a proxy currently.
If Vulkan doesn't have enough security features to support the web, you'd think Apple would work with Khronos to get them implemented, instead of rolling their own API.
It's yet more 'not invented here syndrome' from Apple.
It's yet more 'not invented here syndrome' from Apple.
Are you familiar with https://xkcd.com/927 ?
While Microsoft hasn't committed to supporting Vulkan first-party, every major Windows(and macOS) graphics vendor has a compliant Windows Vulkan driver which performs well, most vendors have two or three independent implementations. There are real applications being built today under the assumption that these drivers will continue to work.
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?
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 and Nintendo don't support it as well.
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.
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.
Intel doesn't have a production quality Vulcan driver as of now.
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.
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.
> 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.
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.
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.
They support mostly the same hardware with Vulkan, and they already ship Vulkan drivers by default through Windows Update. If they're on Windows 7, they'll have working Vulkan. If they move to Windows 10, they'll still have it.
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).
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).
Seriously, even fricken Nintendo is on board with Vulkan: http://www.gamasutra.com/view/news/287995/Nintendo_Switch_to...
Kind of, they have their own API that has better capabilities to expose the graphics hardware called NVN.
I don't know why Apple thinks they're going to have any sway over the people working on 3D graphics. Their hardware support for 3d graphics has been so awful for so long, I have a hard time imagining there's a very big user base they can leverage to get their way. So far as I can tell, what Apple wants here is almost completely irrelevant to the industry.
I don't get it either. Apple graphics support has always been bad and it doesn't seem to have gotten better recently. Blizzard, a company that's always released their games for both Mac and PC, long before Apple even had a particularly relevant userbase was unable/unwilling to put in the effort to release their latest game (Overwatch) on Macs because they weren't able to garner satisfactory performance on Apple hardware.
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.”
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.”
Apple is proposing an open working group collaborate to agree on an open standard for low-level 3D graphics and compute workloads that all browsers can support.
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.
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.
Because iOS is incredibly relevant (many users willing to buy apps) and the A series chip actually has great graphics performance compared to the mobile competition.
IMHO you are underestimating the leverage that Apple has given that macs are the tool of choice for most web developers. Apple is probably aware of this and this move looks like an anticipation.
IMHO you overestimate the use of macs as development machines, doubly so in parts of our industry that works on projects where high performance GPU APIs are actually needed (games, cad, simulations)
I would be interested to know, where is such a place.
OSX support for OpenGL is several versions behind, with low performance and you definitely are not going to write AZDO OpenGL code there.
OSX support for OpenGL is several versions behind, with low performance and you definitely are not going to write AZDO OpenGL code there.
Macs used to be popular with developers but, this has basically changed IMHO. Perhaps they are popular with web designers still but, developers seem to be using Macs no more than the rest of the population to me now. It is Apple's complete lack of support for them that has brought this about IMHO and, I think it will be the end of Apple in the (very) long run (it will be the end of them as anything other than a phone manufacturer sooner and eventually completely I think).
>Macs used to be popular with developers but, this has basically changed IMHO.
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 ;)
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 ;)
I hate that being a developer requires me to be a FOSS UNIX guy from HN view on the world!
Not all developers care about it.
Not all developers care about it.
The unstated point of leverage is iOS Safari. I would assume that at some point, they will deprecate webGL on iOS Safari.
You are thinking about desktop AAA games. There're mobile games too and Apple produces very performant mobile devices.
Why is Vulcan so magical that everyone in this thread thinks it is the only choice?
Your question seems rhetorical, but here are my thoughts anyway...
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.
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.
> WebKit developers are pretty much the forefathers of all modern web tech.
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.
[1]: https://en.m.wikipedia.org/wiki/Dynamic_HTML
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.
[1]: https://en.m.wikipedia.org/wiki/Dynamic_HTML
I appreciate this comment.
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.
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 think you mistake is that you're conflating an angry, vocal (and frankly somewhat belligerent), minority with the opinions of the majority.
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.
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.
A voice of reason in a cacophony of wailing elephants.
It has three things going for it:
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)
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)
1) Compared to Metal or the low level thing MS has (don't they have one?)
2) Apple is proposing an open standard here, they're not making WebMetal
3) Why do you think Apple's proposal doesn't?
2) Apple is proposing an open standard here, they're not making WebMetal
3) Why do you think Apple's proposal doesn't?
1) The low level thing MS has is DirectX 12. I saw some benchmarks across multiple graphics cards that showed it was slower than Vulkan, but I can't seem to find it now... so its unclear to me if it is or isn't slower.
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.
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.
On one, ok. I haven't followed DirectX too closely. I knew 12 was designed to match modern GPUs much closer but I didn't know if that was sort of 'medium' between DX 11 and Vulcan, there being something even lower from MS.
Thanks.
Thanks.
Im sure it was probably just early drivers and its faster now (or at least getting faster).
And does it make security assurances making it suitable to expose to the web?
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.
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.
Obviously there has to be a ground up rethink with security in mind. The standard won't be the same API, just like WebGL isn't the same as OpenGL. It's just, where it's possible to, you use the same API. The point is why not start with a starting point you can use on potentially every platform?
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.
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.
Vulkan has validation layers - that are transparent to both app using the API on one side and to the driver on the other end.
The WebGPU code there looks a lot like vulkan. Just no big struct's or vk prefixes.
Apples handling of Vulcan / Metal should be a colossal embarrassment.
I doubt it's up to the webkit team to make this decision. Anyway, Apple adopting would make things easier
I've submitted this as the first GitHub issue regarding the charter.
https://github.com/gpuweb/admin/issues/1
https://github.com/gpuweb/admin/issues/1
To be fair, they are proposing a JS API, not a native one.
Though I do agree.
Though I do agree.
Pardon my ignorance, but what do you mean by "not supporting Vulkan on their platforms"? I thought Vulkan was an API that software developers used for graphics... Isn't that a part of OpenGL? Is Apple actively blocking something or have they just left something out?
Vulkan is a new API distinct from OpenGL. It's lower level but has a nicer API in some respects.
https://en.wikipedia.org/wiki/Vulkan_(API)
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.
https://en.wikipedia.org/wiki/Metal_(API)
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.
https://en.wikipedia.org/wiki/Metal_(API)
But Microsoft isn't supporting Vulkan in Windows either, so why is there only a fuss about Apple's support for it? Both companies have competing API's (Direct X and Metal), but Apple is the only one getting flack for it. Why is that?
For Windows I install a graphics driver by the GPU maker and get Vulkan support (according to wikipedia that is the case for Nvidia, AMD and Intel), since Windows allows drivers to offer such APIs without any specific support by Microsoft. With a Mac all the drivers come via Apple, without support for it.
Not just Mac. A big deal is ios' missing support.
Two major reasons:
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.
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.
>which covers 99.99999999999999% of all Windows machines where this is an issue.
TIL Matrox only has <00.00000000000001% of the market. :(
TIL Matrox only has <00.00000000000001% of the market. :(
Apple allows GPU manufacturers to ship their own Vulkan support as well.
It's likely not worth the vendor's effort but still.
It's likely not worth the vendor's effort but still.
If they were, say, actively revoking the certs of people trying to do this then it would be a different question, but it seems like the answer is the same for why anything gaming-related works worse or doesn't work at all on macOS: most gamers use Windows.
Saying it is around the same time is to ignore the history.
Metal is available since Jun 2014. Vulkan announced on 2015 and the initial release is on 2016.
Metal is available since Jun 2014. Vulkan announced on 2015 and the initial release is on 2016.
You're right. And Vulkan is based on Mantle which was already available in 2013 (in drivers; with api docs available in 2015 for some reason[1]). Why Kronos/Valve/etc didn't use Metal as a starting point, I don't know.
[1] http://www.anandtech.com/show/9095/amd-mantle-api-programmin...
[1] http://www.anandtech.com/show/9095/amd-mantle-api-programmin...
Metal in 2014 is a different animal than Metal in 2016.
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.
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.
I love how they mention Direct3D and Vulkan in the same breath as Metal.
You are forgetting Sony and Microsoft.
Will it be patent encumbered, like Apple's "proposal" for touch events API?
> 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?
> 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?
The group's draft charter[1] proposes that contributing organisations would be required to agree to the W3C Community Contributor License Agreement[2], which includes a patent licensing commitment for all essential claims. So, if a specification came out of this, then it would not be patent encumbered; at least not by any patents held by Apple.
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/
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, if a specification came out of this, then it would not be patent encumbered; at least not by any patents held by Apple.
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.
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.
> So how come they didn't manage to have the same idea for touch events?
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.
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.
> If Apple want to help, let them base WebGPU on Vulcan.
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?
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?
> do you really want a web app to tell you that you need to update your GPU drivers to get support for Vulkan
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.
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.
> Why wouldn't you want to do it?
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.
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.
> The web is always being trumpeted as "works everywhere".
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.
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.
> Expecting it to work if the user doesn't have working drivers is beyond silly.
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".
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".
I assume you are talking about cases of drivers not being up to date. The reason it's relevant, is because all these new APIs including Vulkan are relatively new. So even if hardware has such capabilities, drivers for it can be lacking because user didn't keep the system / drivers up to date. I don't see how browser makers can fix that, besides warning users that their drivers are too old.
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.
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.
> I assume you are talking about cases of drivers not being up to date.
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.
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.
> Users aren't going to suddenly get Vulkan support in a driver update from Windows/Microsoft Update.
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).
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).
You seem to be wanting to expose the messed up world that is high end PC gaming to the rest of the web. That is quite delusional and I would be thrilled to have Apple standing up for ordinary users in fighting any such move.
The aim of the web is to just work and then as a lower priority work well.
The aim of the web is to just work and then as a lower priority work well.
Gaming has nothing to do with the cause of the mess. The mess stems from the likes of MS and Apple not supporting common cross platform APIs. There is no one but them to blame for that.
Apple want to stand up for the user and fix it? Let them support Vulkan. Oh, wait... They don't really want to.
Apple want to stand up for the user and fix it? Let them support Vulkan. Oh, wait... They don't really want to.
Not only that, but Apple seems to have decided to stop supporting open graphics standards altogether, including OpenGL [1]. Apple used to be quite vocal and influential as part of the ARB, not sure what caused the shift of the last few years.
[1] https://www.g-truc.net/doc/OpenGL%20Drivers%20Status.pdf
[1] https://www.g-truc.net/doc/OpenGL%20Drivers%20Status.pdf
The shift was especially jarring on the compute side of things. Apple literally started the OpenCL initiative, then decided to completely abandon their OpenCL driver in favor of Metal Compute.
We're committed to abiding by the W3C Patent Policy for this spec.
That's a positive thing, but the whole effort looks like an indirect attempt to push Metal, without making it open itself. What about shader tools and etc.? Are there any open ones for Metal? IMHO if anything like that should be created, it should be based on open APIs.
We think the eventual shader language will not be based on MSL. We need both source and binary formats, and MSL doesn't even have a public binary format at this time. However, if we do end up with something MSL-inspired, the same commitment to follow the Patent Policy would apply.
I think it's a sane expectation to use something that is both open and already available. GLSL, SPIR-V and etc. Using something like MSL won't go anywhere, if there won't be comparable, open and freely available implementation already.
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.
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.
Quoting from their 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.
I think it's pretty natural to write what is essentially a proof-of-concept with tools one is ga,iliar with.
> 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.
It's a prototype with an explicit understanding that MSL is only a place holder. What is there to understand?
[deleted]
[deleted]
For all arguing "to use Vulcan": the API proposed is a high-level API which could be implemented on top of Vulcan. Or any other lowlevel API like DirectX or Metal.
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?
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?
> assuming that the client can implement abstractions more efficiently as they are more tuned to his needs.
off topic, but who is the client?
off topic, but who is the client?
The part of the software calling/using the API. So, if you are writing a C++ application targeting the API, you should be able to implement high level abstractions at least as efficient than an API provider could. Possibly more efficient, as you can tune your abstractions to your very non-generic needs. An API provider though has to implement the more common use cases which might bring inefficiencies. However this turns around 180 degrees, when talking about a language like Javascript, which despite all JIT enhancements does not produce as efficient low level code. There you want to put as many of the computations as possible into your API so the resulting application runs faster.
> tuned to his needs
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.
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.
Sorry, not a native English speaker here. In my native German, it is usually proper to use the male form for the undetermined gender. This might leak into my use of the English language. I would be happy, if you could rephrase the offending sentence in correct gender-neutral English, so I could avoid this mistake in future.
The correct way to be neutral in english would be "tuned to their needs"
Not to be pedantic, but the male form is actually also the neutral form in English; "their" is not actually correct. That said, I think it's entirely appropriate to use it in practice.
Singular they is used and appropriate in English as well.
https://en.wikipedia.org/wiki/Singular_they
https://en.wikipedia.org/wiki/Singular_they
[deleted]
It is so sad to see this whole discussion.
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."?
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."?
These are good points, but here are some more to consider:
- 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.
- 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.
"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."
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?
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?
> But what does this have to do, when they propose a new Web API?
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.
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.
Hm, do you really believe, that Apple wants to artifical cripple the web?
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.
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.
As far as i can remember, they've been consistently behind on support for emerging web technologies (since the app store came out), it just doesn't seen to be in their business interests to keep up.
Not really. What about MSE / DASH and touch events? Apple were often hindering adoption if new technologies, if they had their own locked up / patented alternatives, which they didn't want to undermine my accepting open competition.
But it is something different, to not "keep up" with full priority, than to intentionally sabotage WebStandards ...
Sabotage is a strong word, but it doesn't have to be intentionally malevolent. In psychology the word sabotage is often used to describe situations where people don't have faith in relationships (maybe because of personal hangups) and go at them half heartedly. When their relationships fizzle out, people said to "sabotage relationships" are often left feeling confused about what happened.
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.
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 UIWebView is an interesting example. They released significant performance advances in the iOS Safari web browser, but denied those features to developers of cross-platform apps on frameworks such as Cordova, artificially degrading the performance of Cordova apps compared to natively developed iOS apps. Both need to go through the AppStore anyway, but keeping as much dev lock-in as possible in terms of the tech used is obviously an interest here.
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.)
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.)
But where does your example show, that they sabotage webstandards?
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.
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.
... and it might be that they dont like certain standards ... but graphics is a different category.
>the web is inferior to native in the first place
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.
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.
Related reading re. Vulkan
"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, ...).
"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, ...).
Everyone here (including me) is upset that Apple are refusing to support Vulkan (or even improve their existing OpenGL support).
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.
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.
So, you're mad about a desktop API choice and therefore any discussion involving graphics API and Apple in any context must devolve into a fight over what you care about? Not the topic at hand even if it is "probably the correct starting point for a NextGen web graphics API"?
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.
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.
> It doesn't matter if this is probally the correct starting point for a NextGen web graphics API.
Scads of this thread are giving me that signal loud and clear. Not HN at it's best.
Scads of this thread are giving me that signal loud and clear. Not HN at it's best.
And you're going to derail every thread until you get it?
Vulkan is a horrible choice for a web standard. Their hardware support is abysmal, the only graphics hardware that supports it was made from 2012 on wards. Even then a decent chunk of the support is experimental: https://en.wikipedia.org/wiki/Vulkan_(API)
Vulkan is great, but you need to think about the cross compatibility of the web.
Vulkan is great, but you need to think about the cross compatibility of the web.
We're talking about a web standard. Something that will take 5+ years to be implemented fully on all platforms, and even then might still be behind feature flags.
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.
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.
I feel like Apple are just trying to get in early with a proposal so they don't get forced into supporting Vulkan (and wasting all that effort on Metal).
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.
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.
Is that really a "just" or is it the right thing to do? Working on top of all the major APIs is the right thing for the web.
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.
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.
Apple knows they aren't going to push something closed like Metal itself onto the web, so they want to make the web API easy to use with Metal as a backend instead.
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?
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?
Turns out that you don't have to bend over backwards if you're already supporting Vulkan and DirectX 12. But still, the ability to run your awesome 3D web apps on Apple platforms seems to be a good reason to support a Metal back end.
I think 3D web standards are going to take off in spite of Apple. Apple might even end up supporting Vulkan as a result.
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.
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 disrespect intended. You've undoubtedly got a much better grasp of these APIs than I do! However...
> 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.
> 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.
I agree with you that a cross-browser standard is the right thing. We worked hard to bring all the interested parties to the table to kick off this standards effort. What the output looks like remains to be seen.
Agreement upon an existing implementation is not sufficient. WebSQL was rejected because it had only one implementation (SQLite).
https://www.w3.org/TR/webdatabase/
https://www.w3.org/TR/webdatabase/
You do realize you're commenting on a Web standard proposal right? This is in the document were Apple just said "here's what we're doing, deal with it", there are literally trying to work with the community on how it should look.
> Working on top of all the major APIs is the right thing for the web.
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.
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.
Sounds like you're focused on what is best for Vulkan, not what is best for the web.
So far as I can see, the argument he's making is that there's already an actively emerging standard for a 3D API outside of the web, so it would make sense if the web also jumped on the same bandwagon, and we could have a single API everywhere.
That makes sense to me. What is special about the web that should exclude it from the single API narrative?
That makes sense to me. What is special about the web that should exclude it from the single API narrative?
The standard in question is still "one of the standards" (and a "me too" one, "the one to end all the previous standards" (1) as far as I see it) not the standard.
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."
---------------
1) https://xkcd.com/927/
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."
---------------
1) https://xkcd.com/927/
I don't think the XKCD reference is appropriate. Vulkan is trying to standardize low-level graphics API, which is a niche in which other existing contenders (notably, D3D 12 and Metal) are explicitly platform-specific, and don't even try to be standards outside of their ecosystem. Thus, it fills a useful niche.
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.
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.
> 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.
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.
It's not that it should be the same exactly. But I don't see any advantages in it being drastically different. It can be higher-level if needed, but if it's similar both conceptually and in things like semantics and even naming, it's just fewer concepts to hold in your head, and therefore easier to learn. That, to me, is an advantage. Why make stacks more complicated than they need to be?
That's pretty much the reason why Google went with Java as the first-class language for Android dev back then: being late to market they wanted the biggest programmer skill subset available, and that was (perhaps still is?) Java.
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.
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.
> 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.
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."
1) https://news.ycombinator.com/item?id=13594501
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."
1) https://news.ycombinator.com/item?id=13594501
Care to explain? Why is Vulkan not good for the web?
The best 3D standard for the web is one that can be delivered cross-platform with high performance, high quality, and no need for end-user driver installs. And that can be made safe and secure without losing too much performance. In exploring the issue, we concluded that basing it 100% on Vulkan wasn't the best way to achieve these goals.
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.
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.
Don't you agree that the main reason Vulkan is not the best way to achieve those goals is because Microsoft and Apple are refusing to support it? This is circular reasoning.
No, they don't.
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.
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.
Nit: WebGL 2 already happened, Firefox shipped it first and it's almost almost done in Chrome too (though disabled by default).
Because Vukkan is too low level for the web, and thus not a good impedence match. Here is a nice writeup: https://floooh.github.io/2016/08/13/webgl-next.html
With that logic, we should only have blink, or webkit or gecko, just one engine
You're conflating implementations with APIs. If we had a theoretical "WebVulkan" standard, we'd have implementations in each browsers and along with display drivers underneath.
But we do have more less one standard: HTML & JS.
Blink, WebKit, gecko, etc are implementations that support that standard.
Blink, WebKit, gecko, etc are implementations that support that standard.
[deleted]
It is not "seen as non-ideal", it was the very point of existence for all of those standards. Graphic apis had become a leaking abstraction of non-standardized driver behavior with single-digit FPS lurking around every non-popular feature corner.
It is a joke to suggest putting another abstraction over the low-level api. That is squarely the domain of libraries and frameworks.
It is a joke to suggest putting another abstraction over the low-level api. That is squarely the domain of libraries and frameworks.
> 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.
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.
Naive to think that any companies reasons for doing anything should be or is coming from the purest of motives.
Apple proposing standards is ridiculous.
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.
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.
I'm disappointed that I had to scroll this far down to get to the real heart of the matter - Apple removing the headphone jack!
Apple’s “new” UAC port wasn’t made by Apple, and it isn’t new
https://arstechnica.com/apple/2017/02/no-apple-isnt-developi...
Eh? Seems you're _both_ wrong according to an Ars commenter[1]:
“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...
“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...
This should be the top comment. Apple has no ground to stand on on this. Their self-serving intentions are plainly clear.
> use lightning instead of mini USB
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).
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).
I'm assuming he means the 'common external power supply' initiative of the EU of 2009 (and IEC 62684:2011), where a micro-usb connector must be used to connect to a mobile phone, versus the propietary lightning connector of 2012.
I'd like to see Apple implement Safari's missing functionality before they try and come up with a replacement for WebGL.
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?
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?
We are working on many of the things you list. We are able to work on more than one thing at a time though.
The features on that list are industry standard everywhere else. You 'working' on them is not entirely convincing.
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.
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.
"Knowing apple their interest probably isn't aligned with their users interest." Explain cases please.
While going in-depth with this would be fun, it think mentioning some of the proprietary cables they force onto their users is one simple example:
* 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 connectorsAbsolutely this. Safari's lack of support for WebRTC is extremely frustrating. And I think has more to do with their app ecosystem/income than any technical hurdle.
Anything that's not based on the Vulkan spec is just a land-grab by Apple to push their own technologies.
As 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.
As 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.
> As 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.
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.
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.
As soon as you clear up that GPU bottleneck guess what's going to be your next one? (Here's a hint, it's the thing that's dispatching to your GPU).
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.
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.
> As soon as you clear up that GPU bottleneck guess what's going to be your next one?
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.
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.
> Memory bandwidth for your textures, geometry, and other data, quite often.
So in other words a GPU bottleneck?
So in other words a GPU bottleneck?
No, a memory bottleneck. (That may be GPU memory or system memory, depending on the architecture of your graphics stack.) That's not the same as a GPU processing bottleneck. You can have a bottleneck in GPU processing, or a bottleneck in getting enough data to the GPU.
Oh I see, we're getting pedantic over semantics.
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.
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.
The reason for the distinction is that that's one of the specific things Vulkan helps with: keeping the GPU well-fed with work to do. (Also, keep in mind the architectural differences between integrated graphics and discrete graphics.)
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.
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.
>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.
I'm pretty sure you just argued in favor of creating a new API instead of using Vulkan...
I'm pretty sure you just argued in favor of creating a new API instead of using Vulkan...
Modern graphics APIs help you reduce the CPU bottleneck for CPU-bound graphics code. Parallelism, command buffers and generally thinner drivers all help reduce the CPU overhead.
Exactly. They also help you keep the GPU saturated, and minimize round-trips between the GPU and CPU.
People aren't really switching from GL to vk for performance reasons. If you were able to get a full AZDO OpenGL environment everywhere you would probably be getting better frames from that (since a lot of driver performance optimization in vk is pushed on the user, and the GL drivers are more mature).
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.
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 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.
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.
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.
There's plenty of stuff if you want to go native or are you just talking web technologies?
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).
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).
> 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?
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 definitely wasn't saying it was a good thing, just the reality in the graphics space.
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.
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.
I don't understand what you're arguing.
> 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!
> 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!
Why consider just WebGL 1 (ES 2 feature set)? WebGL 2 is already shipping, even in wildly optimistic scenarios any successor is going to take many years to surpass it in browser support. In WebGL 2 you get better support for compute, integers, dynamic loops, halfway to tessellation (transform feedback), etc. And like with WebGL 1, more features will come incrementally as WebGL extensions.
Yeah,what is wrong with WebGL anyway? It seems to work pretty well.
WebGL is pretty great. But, like GLES, it requires a lot of API calls to get stuff done. Hopefully, with a Vulkan-like API, you should be able to move a whole lot of that work to initialization time and make the act of actually drawing stuff frame-by-frame require very little API activity.
In the extreme case you get stuff like "GPU-Driven Rendering Pipelines" described in http://advances.realtimerendering.com/s2015/
In the extreme case you get stuff like "GPU-Driven Rendering Pipelines" described in http://advances.realtimerendering.com/s2015/
lots of things:
- 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.)
- 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.)
All of you complaining about this proposal not being based on Vulkan seem to be overlooking the fact that Vulkan is actually quite cumbersome to use. Metal, on the other hand, is a really well designed API and in my opinion strikes just the right balance between performance and usability. If it was available for non-Mac platforms too, it would be my first choice of graphics API every time. So for me, a cross platform web graphics API based on Metal is really quite an exciting prospect - much more so than one based on Vulkan - and I applaud Apple for proposing it.
Yeah, have the people arguing for Vulkan on the web actually experienced what it's like to use Vulkan? Here's a small taste: https://renderdoc.org/vulkan-in-30-minutes.html
There are many third-party libs which make using Vulkan much easier, all the way up to Game Engines which abstract everything. That isn't a argument against Vulkan.
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.
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.
I think this is a fruitful and promising discussion on the part of the WebKit team. The biggest problem here is that the antipathy towards Apple in response to the perception that Apple management thinks the Macintosh is a dead-end and this is starting to infect other discussions.
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.
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.
I find Apple Inc. as annoying as the next geek does, but I agree with them here. It's rarely -- possibly never -- a good idea to tie a web API design to a desktop API (see, e.g., WebSQL). The web platform is too different from desktop platforms for any nontrivial functionality to port slavishly to it.
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.
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.
Why exactly are we laying it on thick against Apple here when they have the support of other browser vendors in proposing this and are trying to fix a legitimate problem? All of the comments seem to be "well wouldn't it be nice if they used WebVulkan instead" when WebVulkan doesn't fucking exist. If it were so obviously superior why isn't it in the pipeline already? Apple is not the only company that can propose standards, if there was really such an immense appetite for WebVulkan I think it would already have been proposed!
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.
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.
Another anti-competitive initiative disguised as "Apple-led innovation" - maybe Apple should get on board with Vulkan, everyone else has, instead of complaining about there being no cross-platform solutions.
How is this anti-competitive? They're explicitly trying to create a cross-platform JavaScript API for graphics, one that can be built on top of whatever platform-specific low-level APIs that exist. This seems to be the exact opposite of anti-competitive.
Because it's their own.
How convenient to propose your own standard as the standard, made specifically for your own engine...
How convenient to propose your own standard as the standard, made specifically for your own engine...
No it's not. I get the feeling you didn't really read the blog post. This proposed standard is supposed to be able to be implemented on top of all 3 platform-specific APIs, it's not made specifically for Metal.
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.
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.
While I'm far less negative about this blog post than most of the other commentators seem to be, the part where you cite seems more like "well yeah, we're proposing Metal, and that's obviously going to be contentious so lets sheepishly point out that again this is all subject to negotiation".
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.
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.
My reading was "we have to pick something so here's something we have on hand because we don't want to spend all the time of making a fake one we intend to throw out anyway".
The blog post explicitly says they're choosing to "defer the issue". That seems very clear to me as saying "we're not seriously proposing the Metal Shading Language, this is just a placeholder for the purposes of writing up this proposal, we'll let the standardization process decide on the actual language".
I understand what the text literally says, my point is that if a company proposes a strawman that is literally just their proprietary solution on the web any one liner disclaimer that says "but we're not actually necessarily proposing that it use our proprietary solution for this (but maybe!)" can be reasonably suspected as potentially being disingenuous.
There's a whole standardization process to this, which everybody can participate in. The whole point of the proposal is to kick off the discussions and standardization process. Literally nobody expects the proposal to be standardized as-is, so I don't think there should be any concerns whatsoever about the fact that they punted on designing a new shading language. Standardization isn't a "yes or no" vote, it's a process by which the proposals are modified again and again until they come to a solution that everybody is willing to accept. It's simply not possible for Apple to force everybody to accept their Metal Shading Language.
Do you know what a proposal is, by definition? Such things tend to go through a number of web standard committees and are often changed throughout the process. It's not like Apple can directly dictate web standards and expect everyone to fall in line.
I know, but they could make a proposal based on what most people already agree on, instead of their own thing made for Metal.
That's not true because there is no alternative standard proposed for low-level graphics on the web. None. Zero. Zilch. Nada. DOES. NOT. EXIST.
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.
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.
Go for it! I would love to see more focus on browser-based what-the-future-of-code-may-look-like. That said, I don't think that 3D interfaces are the only kinds that need good language / representation. Not that the rules should be really rigid, but I think that if we pursue the notion of reversely symmetric UI-languages we can make a lot of progress. Imagine that you have a 3D scene, what is the minimal language you need to describe it? How can we make it so that language/code is not only minimised but extensible? We must strike a balance.
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.
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.
Is this some kind of procedurally generated programming related nonsense?
After reading it over a couple times I realize it may read that way. Just a (terse) synopsis of some of my thoughts on the state and future of UI "programming"
I'm glad to see Apple getting interested in web standardization again, but I'm not a big fan of this one. Wouldn't a WebGL 3.0 based on Vulkan make more sense? I'd much rather see Apple warming up to Vulkan rather than have so much Metal influence on a common web API.
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.
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.
"Only platforms without Vulkan are Apple's" is most certainly NOT true. The Xbox One is a widely available platform for which a lot of 3D effort is invested, and rewards this effort really well - much better than other platforms (like desktop Linux or old versions of Windows) that are frequently thrown around as arguments for "Vulkan everywhere".
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".
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".
>>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?
Any citation on the matter?
No, sorry, this particular quote is from a private channel.
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:
https://twitter.com/search?q=from%3Azeuxcg%20metal%20vulkan
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:
https://twitter.com/search?q=from%3Azeuxcg%20metal%20vulkan
An obvious use case for this API is to allow native games that use Vulkan to be ported to the Web without a proprietary abstraction layer. (The abstraction layer would be in the emscripten standard library rather than the game engine.) But is this a legitimate use case that someone actually needs?
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).
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).
MS doesn't support Vulkan! Why are many people bashing Apple as the sole company not supporting it??? MS has abandoned OpenGL in support of D3D. Why have people forgotten this???
Microsoft doesn't need to support Vulkan, because Windows is flexible enough that GPU vendors can expose other APIs like OpenGL or Vulkan without Microsoft's permission.
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.
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.
Not every GPU vendor or all the cards of a vendor support Vulkan. Even new ones being sold today. The adoption is broad but not complete for Windows. I guess the argument can be made that vendors ought to support it but that would vastly expand the scope of any web API Vulkanization efforts.
Support for Vulkan on Windows is pretty extensive - AMD and Nvidia are retroactively supporting their hardware back to 2012, and Intel back to 2015, all of them on Windows 7 and up.
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.
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.
Ok, thanks. Although I'm curious about the exact details preventing it.
MS might have abandoned OpenGL, but you can use the latest OpenGL version on Windows if you have an NVIDIA/AMD/Intel GPU and driver, unlike on macOS (4.1 on macOS vs 4.5 on Windows)
NVIDIA and Intel both ship Vulkan drivers for Windows.
Intel ships beta/test drivers, and states they will not be supporting/distributing them as production-quality:
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=...
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=...
They just don't want to commit to a timeline, but they plan on supporting Vulkan for end users (hence why they care enough to even put out a beta driver).
https://software.intel.com/en-us/forums/developing-games-and...
https://software.intel.com/en-us/forums/developing-games-and...
How is this on security? Vulkan API is built on being able to modify command buffers and pass parameters by directly writing to memory, rather than the client/server model of OpenGL. I could see that being an issue with the sandboxed model of the browser.
Disclaimer: haven't read the new Apple web 3D spec, just curious about others' opinions.
Disclaimer: haven't read the new Apple web 3D spec, just curious about others' opinions.
We haven't yet solved all the security problems, but we're aware of and thinking about them.
We expect threadsafety, memory safety, data validation, and memory protection for the shader language to be the big issues.
We expect threadsafety, memory safety, data validation, and memory protection for the shader language to be the big issues.
Why are you proposing a new standard when you are still thinking about security?
Thoroughly solving the security problems will require more eyes on it than just ours. Which is why we're proposing a starting point for a standard, and a process to work on it, not an endpoint.
Thoroughly solving security problems would of course take time. But the parent comment asked a very high level question: How does the security of this new proposal compare to a client-server model such as that of OpenGL? One can simulate one model over another, but in that case, performance can suffer due to overheads. This sort of thing needs to be addressed at the outset, because graphics needs performance and the web needs security; neither can be compromised upon.
I don't think passing command buffers or structures in memory will be an obstacle to security.
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.
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.
Biggest questions I have are:
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.
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.
The blog post explicitly says that they think that discussion around the shading language to be "one of the most fun parts of the standardization process" (i.e. most contentious), and they explicitly said they're deferring the issue of shading language and just accepting an existing language "for now", and that they picked the Metal Shading Language because the authors of the proposal here are using Apple platforms. I think the implication is clear that they don't expect the Metal Shading Language to actually be the final shading language after the proposal has gone through the standardization process.
Yea I saw all of that, I'm wondering if it's just lip service or if they did any outreach beforehand.
This is a great move by Apple. Webkit team is thinking ahead about power of GPU's and opening it up for more than just 3D graphics. GPU are already being utilized for AI and ML. Web developers need better access to low level computation and simple api's.
The API looks like a direct port of Metal to JavaScript.
"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."
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)
1) https://forums.developer.apple.com/thread/38469
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)
1) https://forums.developer.apple.com/thread/38469
>Also, Metal was announced June 2014, released September 2014. Vulkan was announced March 2015, released Feb 2016.
It was rebranded then, but OpenGL Next was announced in August 2014.
http://www.anandtech.com/show/8363/khronos-announces-next-ge...
It was rebranded then, but OpenGL Next was announced in August 2014.
http://www.anandtech.com/show/8363/khronos-announces-next-ge...
As such, it should be rejected by W3C. Let Apple get behind Vulkan, instead of proliferating clones of Apple only APIs.
I'm not quite sure what Apple were expecting, when they have shown a clear contempt for OpenGL by leaving it at version 4.1 (while everyone else is up to 4.5, even Mesa).
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...
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...
That API looks potentially more pleasant to use than WebGL, which is a nice surprise given it's purportedly more low-level.
That's one of the benefits of designing an API for the web from the get-go, instead of just literally copying an API that's meant to be used from C. It makes for a cleaner and nicer API, even though some lower-level details are exposed.
It's basically a webified Metal API, similar to how WebGL is a webified OpenGL, so I wouldn't say it was designed from the get-go for the web. And as far as I can see from the proposal, WebGPU will still be well usable from C (this is important for talking to it from asm.js / WebAssembly)
It's Metal-inspired, but we tried to use JS API design idioms where possible. It does help that Metal is already an object-oriented design instead of bare functions passing around primitive values and structs.
Ha, sorry I wasn't aware that you're on the WebGPU team when I replied. Please don't forget about us emscripten users, I'd love to give WebGPU a whirl with my C++ mini-3D-framework (http://www.github.com/floooh/oryol), would be interesting how the C/C++ code would differ from the Metal rendering backend, and how performance compares to WebGL on one hand, and Metal / GL on the other.
I'm being a little generous to myselff with saying "we". I'm on the WebKit team and I followed this project but I wasn't personally involved in implementing it.
Maybe someone can enlighten me, but it doesn't actually look any more low level. The only lower level thing I see is the texture attachment load/store ops. Can you commit a command buffer more than once?
(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)
(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)
Yes, you can submit a command buffer more than once, with modified parameters.
Lots of negativity in this thread related to non-adoption of Vulcan. But we've been waiting too long for generic compute and the sooner Apple leads something to the browser for GPGPU then maybe it will get everyone else to finally act - competing standard or not.
As someone whos knows almost nothing about 3d graphics and its APIs, how does Vulkan play into all of this? Why should this new API be used instead of adding Vulkan's API to the browser?
This is intended to be WebVulkan|WebDX12|WebMetal with room for other possible underlying implementations.
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.
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.
> 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.
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.
But even in chrome, several tabs can share the same process, which means that information can be leaked, cross-tab.
It is higher level than Vulkan as you don't need to allocate or manage GPU memory, the implementation handles that for you. You also don't need to worry about transitioning render surfaces between different states (D3D12 and Vulkan).
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.
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.
The Safari API is severely lacking relative to Chrome/Firefox. It would be great if Apple would spend some time getting Safari up to parity so devs can create a more consistent user experience for their browser.
what a coincidence. just the other day i kind of stumbled across the situation with apple and vulkan and was totally mystified. why would apple, who was a supporter of vulkan, not implement drivers for it, and in effect block the possibility for a universal webvulkan standard and all the glorious benefits of it? lo there was a reason! i have to say that i think apple is being a complete dunce. so they refuse to implement vulkan drivers, or even modern gl drivers, and now their next move is to create yet another graphics api? the success of which would depend on everyone else supporting it when apple wouldnt support stuff? apple has enough money (tax dodgers) to support other standards. they should probably do that and do it well before telling everyone else what to do. /rant
This probably doesn't matter but one of the advantages of WebGL is it's just OpenGL ES so porting to it is relatively simple.
On the other hand all the big engines already support multiple backends so adding another for yet another API is probably not a problem
On the other hand all the big engines already support multiple backends so adding another for yet another API is probably not a problem
The discussion about Apple not supporting Vulkan is irrelevant because the point of this Webkit proposal is replacing WebGL 2 for web applications, not replacing the sadly fragmented "real" GPU APIs for native applications.
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.
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.
It's really hard to make the example complex enough for experts without completely losing most people. This is deliberately a simple example.
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.
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.
First of all I'd agree with everyone that if any new Web 3D API should come to fruition, it should be based on a Vulkan like state model.
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!
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!
So is this supposed to be like a WebVulkan?
No it's WebGPU like it shows in the code. Vulkan is a competing standard and technology.
> like a WebVulkan
Yes, it's like a Vulkan for the web since it's a competing standard.
Yes, it's like a Vulkan for the web since it's a competing standard.
You misunderstand. I wasn't asking what it's called. I was asking if the idea here is a Vulkan like API for the web.
Our proposal is a little higher-level than Vulkan but it's the same basic idea.
So if it higher level than Vulkan where does it fit in with WebGL?
I mean can't you pretty much already use low level GPU tech like Vertex Buffers and Shaders already?
I mean can't you pretty much already use low level GPU tech like Vertex Buffers and Shaders already?
If you draw a 2-dimensional chart of low-levelness vs performance, Vulkan, DirectX12 and Metal are all higher performance and lower-level than OpenGL. Metal is a bit higher level than the others and Vulkan is probably the lowest level, but they are about the same performance. WebGPU is a bit closer to the Metal level than the Vulkan level, but it's still lower-level and higher-performance.
Why not write a blog post, comparing a hypothetical: WebMetal vs WebVulkan?
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).
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).
I think rough consensus and running code will end up more convincing than the things you suggest. So that's what we're working towards.
Thanks that helps me understand better. I'd like to see a more detailed comparison of WebGPU/Metal/Vulkan in terms of their level of abstractions.
[deleted]
Any word from Carmack on this?
Thanks for sharing this valuable information to our vision. You have posted a
trust worthy blog keep sharing. Nice article i was really impressed by seeing <a href="http://googlepc.org/filmywap-apk-app-2017-android/">filmywap app</a>
this article, it was very interesting and it is very useful for me.
Could this be adapted for graphics virtualization, e.g. allowing several VMs to securely and performantly render 3D workloads on a single physical GPU?
If they were running a web browser...
If Apple has like 4% of the OS market and seems to be abandoning the desktop, why do we really care what Apple thinks?
Because of the fact they helped usher in the modern web with WebKit and they're the ones in charge of this very popular thing called iOS?
WebKit came from the Linux Open Source landscape. It was created withing KDE.
Re: iOS being popular; You're in a bubble, the iOS market share as of 2016Q3 is 12.5%.
Re: iOS being popular; You're in a bubble, the iOS market share as of 2016Q3 is 12.5%.
WebKit did start with KHTML as a base, but it was Apple (and later Google) who brought it to prominence. When it was only KHTML it was a bit player.
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.
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.
Everything I'm reading in this thread pertains to Mac OS, so I'm sticking with my assertion.
You mean people complaining about the lack of Vulcan on OS X?
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.
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.
On iOS, Apple is going to do it's own thing and that's that.
This is awesome. IMHO, reducing the complexity of resource management in the app is the right way to go for a web API, and Metal is closer to what a web API should be than Vulkan.
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
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
If this takes off, what are the chances it will spread out of the web and be the new standard way we draw graphics, the new abstraction available almost everywhere, the successor to OpenGL?
Apple can't even ship up to date desktop and laptop hardware, and own such a small percentage of that market, it makes the proposal almost laughable.
I'm new to this, but does it mean that Apple is preparing for some AR stuff ? Thanks.
Hey Apple, how about developing your browsers to support modern web technologies first?
The latest Safari release is actually ahead of the game in a lot of areas. I don't run it as my primary browser still, but it does look like at least someone within Apple cares.
Isn't Safari Technical Preview supported 100% ES6?
https://news.ycombinator.com/item?id=11708840
https://news.ycombinator.com/item?id=11708840
Not only Technology Preview, but already released Safari 10 is currently the only 100% ES2015 (ES6) compliant browser.
https://kangax.github.io/compat-table/es6/
https://kangax.github.io/compat-table/es6/
Apple definitely keeps up with core JavaScript and CSS support, but essentially anywhere the web undermines their attempt to maintain control over a protocol, file format, or API--or for anything that makes the browser fundamentally more powerful (which undermines their attempt to get developers to focus on native applications, and which stuff like ES6 is fundamentally not an example)--they invest only a token amount of effort at best and at worst they seem to actively cause more fragmentation (by pushing Safari-only proprietary and sometimes even patent-encumbered alternatives).
Have you examples?
Service Workers, Pointer Events, Web Notifications, WebRTC... I could probably go on, but these are the ones everyone generally has at the top of their heads and which I can just rattle off without thinking about it much (and which have already been mentioned by other people on this very threads, and so absolutely should not require listing :/). The story of IndexedDB vs WebSQL (with Safari developers apparently being extreme zealots for the latter and essentially refusing to implement the former for years) is another great example. I recommend doing some basic searches using Google, as there is tons of great commentary on how Safari is "the new IE6" or is simply holding back the web.
Firefox was just the opposite on Indexed DB/WebSQL. History written by the victors.
Firefox argued that WebSQL was a terrible idea that shouldn't become a standard, and the other vendors eventually agreed, including some that were already shipping it.
Right. "[Firefox] developers apparently being extreme zealots for [IndexedDB] and essentially refusing to implement [WebSQL] for years"
No, that is actually a serious mischaracterization, to be point of being actually malicious. The point wasn't that it had to be IndexedDB, the point was that it couldn't be WebSQL as long as the latter relied on specific SQLite implementation details.
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.
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.
WebSQL was never going to be picked up by Microsoft either: it was a WebKit-only concept that was doomed from the start.
It was a SQLite only concept, not so much a WebKit only concept. Of course defining the API for years to come based on the quirks of one particular implementation was terrible, even if somewhat convenient at the time.
Like?
http://iswebrtcreadyyet.com/
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.
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.
> Apple proposes new web 3D graphics API
Which works only on one size of screen? :)
Which works only on one size of screen? :)
I think it's fine, if they can manage to polyfill this fucker.
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
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
[deleted]
Hey Apple, where's your Web Midi support at?
Wow, I never knew that was even a thing. The idea of turning a knob on my midi controller and having the web app respond is very cool.
[deleted]
Kicking and dragging on WebRTC, WebCL, Vulkan. Business interests much?
WebCL is dead AFAIK. None of the browser vendors is interested in it. They'd rather have compute shaders from OpenGL 3.2 in WebGL.
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.
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.
How about just implementing serviceworker first?
this might be interesting.
Yet another fine API.
Is it maybe time to step back and think about whether having a low-level 3D graphics API in the browser makes any sense at all? I know, we HAVE to run every conceivable thing out of the browser and on Javascript possible. But just maybe building native apps would be easier than trying to shoehorn an API into browser specs, where not only will you have to deal with hardware variations, there will be the inevitable incompatibilities between the implementations by each browser vendor.
That is a very deceptive way to put it.
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.
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.
Presumably the downvotes are because your comment went uncivil, by accusing another user of dishonesty and by insinuating astroturfing without evidence. Neither of those things are allowed on HN, so please don't do them again.
We detached this subthread from https://news.ycombinator.com/item?id=13593606 and marked it off-topic.
We detached this subthread from https://news.ycombinator.com/item?id=13593606 and marked it off-topic.
Wait... what? Deceptive... really? Come on now.
http://caniuse.com/
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.
http://caniuse.com/
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.
http://caniuse.com/#feat=notifications
Every. single. other. browser. Including desktop Safari.
Every. single. other. browser. Including desktop Safari.
I can play that game too:
http://caniuse.com/#feat=es6-module
Like I said, "ahead of the game in a lot of areas", not every area.
http://caniuse.com/#feat=es6-module
Like I said, "ahead of the game in a lot of areas", not every area.
Except all the mobile browsers. Which makes sense since nobody wants notifications on their phone from a website.
> Which makes sense since nobody wants notifications on their phone from a website.
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.
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.
As an iOS and MacOS user..... GOOD.
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.
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.
Instead you get "stupid prompts from mobile Safari" to install apps, which websites mostly do so they can send you push notifications: same prompts, even more annoying (as often the "carrot" is that some of the content or UI requires the app).
Honestly I don't see a lot of those anymore. Perhaps it's the ad blocker, perhaps it's the fact that they realized it doesn't work well, or perhaps I just don't go to sites that push it.
That's clearly not true.
IE: Not Supported
Opera Mini: Not Supported
Chrome for Android: Not Supported
IE: Not Supported
Opera Mini: Not Supported
Chrome for Android: Not Supported
anybody else here actually build a progressive web app only to find that safari supports none of it's features? chrome + android (maybe even microsoft) are so far ahead here it's not even funny
Download pokemon gio hack here
http://techvinn.com/pokesniper-apk-app-download/
Great blog with very useful information provided http://techvinn.com/filmywap-download-2017/
[deleted]
101 mentions of Vulkan so far
So much more value would be created if iOS supported Android-style progressive web applications...
We don't need more new standards.
We need concise, clear and coherent code.
We need concise, clear and coherent code.
It doesn't matter how well-built your house is, if you build it on limestone in a flood zone.
I'd rather Apple implement getUserMedia in Safari first.
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
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
I don't agree with this. The web does not need a 3D rendering API. If you think "web apps" are an appropriate thing, then perhaps it makes sense. Ignoring that, the web to me is still a way to view content and as such I can see a use for having navigable 3D scenes, environments, or content, but the rendering would be left to the browser much the way rendering HTML is left to the browser. I really don't like the amount of code running in my browser and see no need to add more.
VRML (and most of the scene graph style 3D apis) died in the 90s for a reason.
"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."
Vulkan isn't available on the Mac huh? Yeah Apple, and just who's fault is that??
Vulkan isn't available on the Mac huh? Yeah Apple, and just who's fault is that??
Now that Apple has all power and wealth, they arrogantly push an api nobody wants, resulting in man-centuries of wasted effort and frustration .. instead of listening to their users [ in this case developers ]
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.
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.
And yet Apple is proposing creating a fast, open, standards complaint Javascript API.
So Apple, the only company not supporting Vulkan on their platforms, is complaining that there isn't a cross-platform solution?