4 ms·

I'm not sure why WebGPU is a step too far but WebGL isn't? Every other API for using a GPU went the same direction; why should HTML be stuck with a JS projectio

I'm not sure why WebGPU is a step too far but WebGL isn't? Every other API for using a GPU went the same direction; why should HTML be stuck with a JS projection of OpenGL ES while native developers get Vulkan? The security properties of both are very similar, Vulkan/Metal/DX12 just lets you skip varying levels of compatibility nonsense inherent in old graphics APIs.

ChadNauseam 2y ago
I agree. I'm not knowledgable enough to say for sure, but my intuition is that the total complexity of WebGPU (browser implementation + driver) is usually less than the total complexity of WebGL.
- smolder 2y ago
  WebGL is like letting your browser use your GPU with a condom on, and WebGPU is doing the same without one. The indirection is useful for safety assuming people maintain the standard and think about it. Opening up capability in the browser needs to be a careful process. It has not been recently.
  - macguillicuddy 2y ago
    It's my understanding that the browsers use a translation layer (such as ANGLE) between both WebGL and WebGPU and a preferred lower level native API (Vulkan or Metal). In this regard I don't believe WebGL has any more or less protection than WebGPU. It's not right to confuse abstraction with a layer of security.
    - immibis 2y ago
      The translation layer is the safety layer. In principle, it's like running Java bytecode instead of machine code.
      - deleted 2y ago
        [deleted]
    - smolder 2y ago
      My analogy was bad and I'd probably be wrong as you (and your sibling post) say to expect WebGPU to have any lurking dangers as compared to WebGL. I was mainly trying to express concern with new APIs and capabilities being regularly added, and the danger inherent in growing these surfaces.
  - modeless 2y ago
    It's clear that you know nothing about how WebGL or WebGPU are implemented. WebGPU is not more "raw" than WebGL. You should stop speaking confidently on these topics and misleading people who don't realize that you are not an expert.
    - smolder 2y ago
      I'd dispute that I know nothing. I'm not an expert but have worked with both, mostly WebGL. Anyways, sorry, it was a bad analogy and you're right, I don't know enough, particularly to say that WebGPU has any unique flaws or exposes any problems not in WebGL. I'm merely suspicious that it could, and maybe that is just from ignorance in this case.
  - flohofwoe 2y ago
    That's incorrect, WebGPU has the exact same security guarantees as WebGL, if anything the specification is even stricter to completely eliminate UB (which native 3D APIs are surprisingly full of). But no data or shader code makes it to the GPU driver without thorough validation both in WebGL and WebGPU (WebGPU *may* suffer from implementation bugs just the same as WebGL of course). > Opening up capability in the browser needs to be a careful process. It has not been recently. That's what about 95% of the WebGPU design process is about and why it takes so long (the design process started in 2017). Creating a cross-platform 3D API is trivial, doing this with web security requirements is not.
deleted 2y ago
[deleted]
smolder 2y ago
> why should HTML be stuck with a JS projection of OpenGL ES while native developers get Vulkan? Because web browsers are supposed to be locked down and able to run untrusted code, not an operating system that reinvents all the same failings of actual operating systems. They should be functionality impaired in favor of safety as much as possible. For the same reason you don't get access to high precision timing in browser (a lesson that took a while to learn!), you shouldn't have arbitrary capabilities piled onto it.
- imiric 2y ago
  Those are all historical remnants. Modern web browsers serve a radically different purpose than they did in the 90s. It doesn't make sense to even keep calling them "web browsers" since most people don't know what a "web" is, let alone "browse" it. Modern browsers are application runtimes with a very flexible delivery mechanism. It's really up to web developers to decide what features this system should have to enable rich experiences for their users. Declaring that they should be functionally impaired or what they "should be" without taking into account the user experience we want to deliver is the wrong way of approaching this. To be clear: I do think we should take security very seriously, especially in the one program people use the most. I also think reinventing operating systems to run within other operating systems is silly. But the web browser has become the primary application runtime and is how most people experience computing, so enabling it to deliver rich user experiences is inevitable. Doing this without compromising security or privacy is a very difficult problem, which should be addressed. It's not like the web is not a security and privacy nightmare without this already. So the solution is not to restrict functionality in order to safeguard security, but to find a way to implement these features securely and safely.
  - mihaaly 2y ago
    > Modern web browsers serve a radically different purpose than they did in the 90s And that is a bad thing it was pushed this far! Exactly this is the argument here!
    - imiric 2y ago
codedokode 2y ago
Both WebGL and WebGPU should be locked behind permission because they allow fingerprinting user's hardware (also they provide the name of user's graphic card). And because they expose your GPU drivers to the whole world.
chrisjj 2y ago
> why should HTML be stuck with a JS projection of OpenGL ES while native developers get Vulkan? Same reason kids should be stuck with Nerf guns while grownups have firearms.

ChadNauseam 2y ago

I agree. I'm not knowledgable enough to say for sure, but my intuition is that the total complexity of WebGPU (browser implementation + driver) is usually less than the total complexity of WebGL.

smolder 2y ago
WebGL is like letting your browser use your GPU with a condom on, and WebGPU is doing the same without one. The indirection is useful for safety assuming people maintain the standard and think about it. Opening up capability in the browser needs to be a careful process. It has not been recently.
- macguillicuddy 2y ago
  It's my understanding that the browsers use a translation layer (such as ANGLE) between both WebGL and WebGPU and a preferred lower level native API (Vulkan or Metal). In this regard I don't believe WebGL has any more or less protection than WebGPU. It's not right to confuse abstraction with a layer of security.
  - immibis 2y ago
    The translation layer is the safety layer. In principle, it's like running Java bytecode instead of machine code.
    - deleted 2y ago
      [deleted]
  - smolder 2y ago
    My analogy was bad and I'd probably be wrong as you (and your sibling post) say to expect WebGPU to have any lurking dangers as compared to WebGL. I was mainly trying to express concern with new APIs and capabilities being regularly added, and the danger inherent in growing these surfaces.
- modeless 2y ago
  It's clear that you know nothing about how WebGL or WebGPU are implemented. WebGPU is not more "raw" than WebGL. You should stop speaking confidently on these topics and misleading people who don't realize that you are not an expert.
  - smolder 2y ago
    I'd dispute that I know nothing. I'm not an expert but have worked with both, mostly WebGL. Anyways, sorry, it was a bad analogy and you're right, I don't know enough, particularly to say that WebGPU has any unique flaws or exposes any problems not in WebGL. I'm merely suspicious that it could, and maybe that is just from ignorance in this case.
- flohofwoe 2y ago
  That's incorrect, WebGPU has the exact same security guarantees as WebGL, if anything the specification is even stricter to completely eliminate UB (which native 3D APIs are surprisingly full of). But no data or shader code makes it to the GPU driver without thorough validation both in WebGL and WebGPU (WebGPU *may* suffer from implementation bugs just the same as WebGL of course). > Opening up capability in the browser needs to be a careful process. It has not been recently. That's what about 95% of the WebGPU design process is about and why it takes so long (the design process started in 2017). Creating a cross-platform 3D API is trivial, doing this with web security requirements is not.

deleted 2y ago

[deleted]

smolder 2y ago

> why should HTML be stuck with a JS projection of OpenGL ES while native developers get Vulkan? Because web browsers are supposed to be locked down and able to run untrusted code, not an operating system that reinvents all the same failings of actual operating systems. They should be functionality impaired in favor of safety as much as possible. For the same reason you don't get access to high precision timing in browser (a lesson that took a while to learn!), you shouldn't have arbitrary capabilities piled onto it.

imiric 2y ago
Those are all historical remnants. Modern web browsers serve a radically different purpose than they did in the 90s. It doesn't make sense to even keep calling them "web browsers" since most people don't know what a "web" is, let alone "browse" it. Modern browsers are application runtimes with a very flexible delivery mechanism. It's really up to web developers to decide what features this system should have to enable rich experiences for their users. Declaring that they should be functionally impaired or what they "should be" without taking into account the user experience we want to deliver is the wrong way of approaching this. To be clear: I do think we should take security very seriously, especially in the one program people use the most. I also think reinventing operating systems to run within other operating systems is silly. But the web browser has become the primary application runtime and is how most people experience computing, so enabling it to deliver rich user experiences is inevitable. Doing this without compromising security or privacy is a very difficult problem, which should be addressed. It's not like the web is not a security and privacy nightmare without this already. So the solution is not to restrict functionality in order to safeguard security, but to find a way to implement these features securely and safely.
- mihaaly 2y ago
  > Modern web browsers serve a radically different purpose than they did in the 90s And that is a bad thing it was pushed this far! Exactly this is the argument here!
  - imiric 2y ago

codedokode 2y ago

Both WebGL and WebGPU should be locked behind permission because they allow fingerprinting user's hardware (also they provide the name of user's graphic card). And because they expose your GPU drivers to the whole world.

chrisjj 2y ago

> why should HTML be stuck with a JS projection of OpenGL ES while native developers get Vulkan? Same reason kids should be stuck with Nerf guns while grownups have firearms.