5 ms·

The group's draft charter[1] proposes that contributing organisations would be required to agree to the W3C Community Contributor License Agreement[2], which in

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 https://gpuweb.github.io/admin/cg-charter.html [2] https://www.w3.org/community/about/agreements/cla/ https://www.w3.org/community/about/agreements/cla/

shmerl 10y ago
> 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.
- stupidcar 10y ago
  > 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.
- stephenr 10y ago
  > 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?
  - shmerl 10y ago
    > 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.
    - stephenr 10y ago
      > 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.
      - shmerl 10y ago
        > 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.

shmerl 10y ago

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

stupidcar 10y ago
> 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.
stephenr 10y ago
> 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?
- shmerl 10y ago
  > 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.
  - stephenr 10y ago
    > 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.
    - shmerl 10y ago
      > 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.