W3C home > Mailing lists > Public > public-gpu@w3.org > November 2017

Re: Ill-defined programs

From: Corentin Wallez <cwallez@google.com>
Date: Mon, 13 Nov 2017 15:42:26 -0800
Message-ID: <CAGdfWNMK0ibcp1BgFQPAb7TuzZqcfeu-4QQD0biHNTUPAfnMxQ@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Dzmitry Malyshau <dmalyshau@mozilla.com>, Kai Ninomiya <kainino@google.com>, public-gpu <public-gpu@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:22 UTC