On Mon, Nov 13, 2017 at 3:22 PM, Maciej Stachowiak <mjs@apple.com> wrote: > > WebAssembly managed to do this, so I believe it is possible. WebAssembly > even has a pretty clear definition of what they consider to be > interoperable, and I'd suggest we follow it to the extent it makes sense. > > WebAssembly runs on CPUs which provide a lot of control over their execution, their memory, etc. A lot of the things done there do not translate at all to a GPU API. We don't have fine control over virtual memory and can't have guard pages. We don't have direct access to the hardware and instead have to go through multiple drivers on multiple APIs which all have their semantics. We should definitely learn from WebAssembly's experience but please stop suggesting that because WebAssembly did something WebGPU should be able to do it too. They are very different beasts. > > If websites can turn this layer on or off at their option, then it doesn't > solve the interop problem. If Vulkan and D3D12 provide robustness with > reliable and consistent behavior in the error case, then it seems adequate > to specify that behavior. If the same program could do totally different > things on Vulkan, D3D12 and Metal, or between different devices with the > same API, then if WebGPU takes off we will end up in reverse engineering > hell. > > Even inside D3D12 and Vulkan the robust buffer behavior is a choice of one inside N because the most efficient way to achieve this behavior depends on the hardware. Please read this issue <https://github.com/gpuweb/gpuweb/issues/33> for more information. Corentin
Received on Monday, 13 November 2017 23:43:11 UTC