Hacker News Reader

Comment by shmerl | Hacker News Reader

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?

View on HN

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/

> 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?

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?

> 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?

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.

> 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".

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.

> 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.

> 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).

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.

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.

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

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.

Yes, they clearly are deeply into their usual NIH routine. So it's highly hypocritical for them to complain, how open APIs aren't cross platform enough.

Apple supported Blu-ray and even took a seat on the Blu-ray board. How many Blu-ray drives did Apple ship?

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.

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.

It's a prototype with an explicit understanding that MSL is only a place holder. What is there to understand?

Expect some friction :)

Expect the developers that have been abandoned by Apple not to move at all.

Reply on news.ycombinator.com