5 ms·

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

> 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
        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.
pjmlp 8y ago
WebGL also does not use OpenGL on game consoles.

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

pjmlp 8y ago

WebGL also does not use OpenGL on game consoles.