5 ms·

Not GP, but I think the ossification of WebGL has little to do with security concerns and a lot to do with the fact that the GL model is a poor fit to the direc

by mrec 8y ago

Not GP, but I think the ossification of WebGL has little to do with security concerns and a lot to do with the fact that the GL model is a poor fit to the direction hardware has taken over the past couple of decades. Realistically, any successor is going to be benchmarked to within an inch of its life too, so the same worry would apply. The shape of that successor is still very vague, but it'll probably be closer to the Vulkan/Metal/DX12 generation. Various interested parties have been putting together exploratory proposals (see e.g. Mozilla's Obsidian), and Khronos appears to be accepting that "Vulkan everywhere" ain't going to happen and working on a "3D portability" initiative that's pretty much lowest-common-denominator. That would almost certainly have a web binding if it pans out. Disclaimer: I don't work in this area, I just follow it out of morbid curiosity. A few links: https://www.khronos.org/api/3dportability/ https://www.khronos.org/api/3dportability/ http://floooh.github.io/2016/08/13/webgl-next.html http://floooh.github.io/2016/08/13/webgl-next.html https://www.phoronix.com/scan.php?page=news_item&px=Mozilla-Obsidian-Graphics-API https://www.phoronix.com/scan.php?page=news_item&px=Mozilla-...

skocznymroczny 8y ago
> Khronos appears to be accepting that "Vulkan everywhere" ain't going to happen and working on a "3D portability" initiative that's pretty much lowest-common-denominator. That would almost certainly have a web binding if it pans out. this isn't actually such a bad idea. Right now, WebGL isn't OpenGL everywhere either. It's "OpenGL where possible but Direct3D on Windows because OpenGL drivers used to be terrible". Likewise, it might not be such a bad idea to create a common graphics API, which will use Direct3D 11/Vulkan on Windows, Metal on macOS and Vulkan on Linux
- MaxBarraclough 8y ago
  > Likewise, it might not be such a bad idea to create a common graphics API, which will use Direct3D 11/Vulkan on Windows, Metal on macOS and Vulkan on Linux So, a higher-level graphics API. Like WebGL? I'm not just being facetious - if we're ruling out a low-level API like Vulkan, aren't we back to square one? What's wrong with WebGL that could be fixed with an API like you describe?
  - gmueckl 8y ago
    WebGL is modelled after the worst part of OpenGL: hardware state is presented as something that can be altered by the application software at any time in any way, no matter how brain dead the change actually is. Instead of preventing the user to from writing slow rendering code on top of that interface, it actively encourages that. The new generation of interfaces are based on the tenet that most of the state information is known in advance anyway and can be precompiled into static opaque handles which represent precomputed and sanity-checked hardware register values that the driver just needs to push when required instead of having to run the heavy checking again each time the user calls some glEnable/glDisable or other state altering shenanigans. I think that a new JavaScript interface that is modelled like this, but is sufficently high level, might be faster, easier to use and safer to implement than what we currently have.
    - MaxBarraclough 8y ago
      You clearly know a lot more than I do - so that kind of thinking is reflected in the architectures of Direct3D 12/Vulkan/Metal? Could an indirection layer really be practical? (Vaguely related: Zed Shaw's blog post on Indirection Is Not Abstraction, https://zedshaw.com/archive/indirection-is-not-abstraction/ https://zedshaw.com/archive/indirection-is-not-abstraction/ )
      - gmueckl 8y ago
        I don't understand what you mean here. You definitely can't expose Vulkan to untrusted code because it is designed to have a very high level of trust between driver and application - the driver is quite likely to crash the whole system on bad input. And there are countless possibilities for bad input in this interface. So what you need for browsers is an interface that keeps the general ideas of flexible buffer usage and immutable state objects, but puts the user in a rubber cell with heavily padded levers. It can be done, but it likely can't have the full flexibility of DX12/Vulkan/... with memory aliasing etc.
        MaxBarraclough 8y ago
- pjmlp 8y ago
  WebGL also does not use OpenGL on game consoles.
yig 8y ago
It's called WebGPU. All the major players are cooperating. The mailing list reveals quite active biweekly meetings. https://www.w3.org/community/gpu/ https://www.w3.org/community/gpu/
- MaxBarraclough 8y ago
  Thanks! I had no idea about that project.

by mrec 8y ago

skocznymroczny 8y ago

> Khronos appears to be accepting that "Vulkan everywhere" ain't going to happen and working on a "3D portability" initiative that's pretty much lowest-common-denominator. That would almost certainly have a web binding if it pans out. this isn't actually such a bad idea. Right now, WebGL isn't OpenGL everywhere either. It's "OpenGL where possible but Direct3D on Windows because OpenGL drivers used to be terrible". Likewise, it might not be such a bad idea to create a common graphics API, which will use Direct3D 11/Vulkan on Windows, Metal on macOS and Vulkan on Linux

MaxBarraclough 8y ago
> Likewise, it might not be such a bad idea to create a common graphics API, which will use Direct3D 11/Vulkan on Windows, Metal on macOS and Vulkan on Linux So, a higher-level graphics API. Like WebGL? I'm not just being facetious - if we're ruling out a low-level API like Vulkan, aren't we back to square one? What's wrong with WebGL that could be fixed with an API like you describe?
- gmueckl 8y ago
  WebGL is modelled after the worst part of OpenGL: hardware state is presented as something that can be altered by the application software at any time in any way, no matter how brain dead the change actually is. Instead of preventing the user to from writing slow rendering code on top of that interface, it actively encourages that. The new generation of interfaces are based on the tenet that most of the state information is known in advance anyway and can be precompiled into static opaque handles which represent precomputed and sanity-checked hardware register values that the driver just needs to push when required instead of having to run the heavy checking again each time the user calls some glEnable/glDisable or other state altering shenanigans. I think that a new JavaScript interface that is modelled like this, but is sufficently high level, might be faster, easier to use and safer to implement than what we currently have.
  - MaxBarraclough 8y ago
    You clearly know a lot more than I do - so that kind of thinking is reflected in the architectures of Direct3D 12/Vulkan/Metal? Could an indirection layer really be practical? (Vaguely related: Zed Shaw's blog post on Indirection Is Not Abstraction, https://zedshaw.com/archive/indirection-is-not-abstraction/ https://zedshaw.com/archive/indirection-is-not-abstraction/ )
    - gmueckl 8y ago
      I don't understand what you mean here. You definitely can't expose Vulkan to untrusted code because it is designed to have a very high level of trust between driver and application - the driver is quite likely to crash the whole system on bad input. And there are countless possibilities for bad input in this interface. So what you need for browsers is an interface that keeps the general ideas of flexible buffer usage and immutable state objects, but puts the user in a rubber cell with heavily padded levers. It can be done, but it likely can't have the full flexibility of DX12/Vulkan/... with memory aliasing etc.
      - MaxBarraclough 8y ago
pjmlp 8y ago
WebGL also does not use OpenGL on game consoles.

yig 8y ago

It's called WebGPU. All the major players are cooperating. The mailing list reveals quite active biweekly meetings. https://www.w3.org/community/gpu/ https://www.w3.org/community/gpu/

MaxBarraclough 8y ago
Thanks! I had no idea about that project.