3 ms·

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 wa

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
    I'm not talking about directly wrapping Vulkan, I was referring to skocznymroczny's comment: "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" The goal would be to maximally retain the advantages of the new generation of graphics APIs, while accommodating all three as backends to the system. (Comparable to the way ANGLE maps WebGL onto Direct3D, but without 'picking favourites'.) You sound ambivalent on the practicality of this. WebGL itself has been more successful at doing this (wrapping a highly 'trusting' graphics API to give a secure and portable API) than I thought it would be (though we did have the very alarming security issue I mentioned before).
    - pjmlp 8y ago
      There are GLSL exploits. "Vulnerability analysis of GPU computing" https://lib.dr.iastate.edu/cgi/viewcontent.cgi?referer=&httpsredir=1&article=4122&context=etd https://lib.dr.iastate.edu/cgi/viewcontent.cgi?referer=&http... "Grand Pwning Unit: Accelerating Microarchitectural Attacks with the GPU" https://www.vusec.net/wp-content/uploads/2018/05/glitch.pdf https://www.vusec.net/wp-content/uploads/2018/05/glitch.pdf Just two random papers, there are quite a few others. Ah, and as usual when discussing 3D APIs, games console also use their own flavours, XBox is not the exception.

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
  I'm not talking about directly wrapping Vulkan, I was referring to skocznymroczny's comment: "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" The goal would be to maximally retain the advantages of the new generation of graphics APIs, while accommodating all three as backends to the system. (Comparable to the way ANGLE maps WebGL onto Direct3D, but without 'picking favourites'.) You sound ambivalent on the practicality of this. WebGL itself has been more successful at doing this (wrapping a highly 'trusting' graphics API to give a secure and portable API) than I thought it would be (though we did have the very alarming security issue I mentioned before).
  - pjmlp 8y ago
    There are GLSL exploits. "Vulnerability analysis of GPU computing" https://lib.dr.iastate.edu/cgi/viewcontent.cgi?referer=&httpsredir=1&article=4122&context=etd https://lib.dr.iastate.edu/cgi/viewcontent.cgi?referer=&http... "Grand Pwning Unit: Accelerating Microarchitectural Attacks with the GPU" https://www.vusec.net/wp-content/uploads/2018/05/glitch.pdf https://www.vusec.net/wp-content/uploads/2018/05/glitch.pdf Just two random papers, there are quite a few others. Ah, and as usual when discussing 3D APIs, games console also use their own flavours, XBox is not the exception.