Re: Ill-defined programs

On Mon, Nov 13, 2017 at 2:13 PM, Dzmitry Malyshau <dmalyshau@mozilla.com>
wrote:

> Maciej,
>
> Thanks for expressing your position!
>
> Out of curiosity, does WebGL working group take the same stance on
> ill-defined programs (i.e. applying interoperability requirements to them)?
>

As much as is possible without dramatically impacting performance, WebGL
defines undefined behavior from both the OpenGL ES and GLSL ES API
specifications. All of the error conditions at the OpenGL API level are
defined in a testable way. In some situations, for example checking that
indices are in-range for indexed draw calls, a few error behaviors are
allowed, and the browser can choose one.

Shader execution is a more difficult problem. There are some undefined
areas in the shading language – for example, the result of pow(x, y) if
x<0, or if x=0 and y<=0. To avoid impacting shader execution performance by
inserting conditional tests before these built-in functions, these are left
undefined. I expect the same will be necessary for many areas of GPUWeb's
compute facilities, including when multiple invocations of fragment shaders
can all access memory shared between them.

-Ken



> > Yes. Strong objection. If behavior of any programs is not fully
> specified, then web developers will start to accidentally depend on the
> behavior of one browser (usually whichever is most popular), and then
> browsers will have to reverse-engineer each others' behavior.
>
> This sentence touches 2 important topics:
>   1. *Full specification*. I don't believe we can fully specify behavior
> of even well-defined programs... Say, you have a number of UAV/SSBO writes
> in the shaders - there is no efficient way to guarantee particular ordering
> (hence, Unordered part) for us, and thus - any developer relying on the
> order produced by their dev machine may be surprised to see what other
> users get, depending on the backend, OS, driver, etc. If we agree here, we
> need to figure out where to draw the line between strong portable behavior
> and whatnot. My point is, excluding the ill-defined programs from the
> equation provides more opportunity for well-defined programs to run
> efficiently.
>   2. *Reverse-engineering* each other behavior. AFAIK, this group's goals
> is to produce an open-source WebGPU implementation that can be shared by
> browser vendors, no need to reverse-engineer. I would prefer us (as a
> group) focusing on the standard more than implementation though, given that
> we have an alternative.
>
> >>  2. Are there any objections to having an optional debug validation
> layer?
>
> > I don't know what that means so no opinion,
>
> We touched the validation layer topic a few times, accidentally. For
> example, when discussing the robust buffer access, we mentioned that there
> can be a validation layer doing all the clamping and potentially signalling
> errors up (to the CPU side), but we (Mozilla) don't believe it to be
> necessary at all times, given that both Vulkan and D3D12 provide decent
> robustness out of the box. The validation layer could do much more, e.g.
> ensuring pipeline barriers are correct, but the exact responsibilities
> depend on the chosen API direction.
>
>
> > Security (for some appropriate definition) is a hard requirement.
>
> Absolutely! What about ordering of the rest? (portability, performance,
> API simplicity)
>
>
> Kai,
>
> >  When we say, "There is no duty to detect or report whether an
> application is actually ill-behaved," we're only saying that it's not
> required for WebGPU to be secure.
>
> Yes, I understand. I took the discussion outside of the bounds/context of
> the original issue, hence putting it on the mailing list (as opposed to
> discussing in place).
>
> Thank you,
> Dzmitry
>
>
> On Mon, Nov 13, 2017 at 4:42 PM, Kai Ninomiya <kainino@google.com> wrote:
>
>> Dzmitry, I want to just clarify David's intent, if I understand it
>> correctly. His document is focused solely on the security constraints. When
>> we say, "There is no duty to detect or report whether an application is
>> actually ill-behaved," we're only saying that it's not required for WebGPU
>> to be secure.
>>
>> There is, of course, still difference of opinion in whether we should
>> ultimately actually detect/normalize ill behavior.
>>
>> On Mon, Nov 13, 2017 at 12:39 PM Maciej Stachowiak <mjs@apple.com> wrote:
>>
>>>
>>> On Nov 13, 2017, at 12:27 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>>
>>>
>>>
>>> On Nov 13, 2017, at 11:44 AM, Dzmitry Malyshau <dmalyshau@mozilla.com>
>>> wrote:
>>>
>>> I'd like to follow-up on discussion points mentioned in
>>> https://github.com/gpuweb/gpuweb/issues/39:
>>>
>>> > There is no duty to detect or report whether an application is
>>> actually ill-behaved. Attempting to do so may incur overhead. For a
>>> development environment it may be desirable to detect bad behaviour, but
>>> that is not a security requirement.
>>> > We don't care about the computed results or performance of an
>>> ill-behaved application. That may be a user-experience concern, but not a
>>> security concern.
>>>
>>> This is wider than just shaders or just security, so I'm following up on
>>> email as opposed to hijacking the GitHub thread.
>>>
>>>
>>> I agree that consistent behavior for ill-behaved applications is nit a
>>> security requirement. But it is a
>>>
>>>
>>> Meant to say: but it is an interoperability requirement.
>>>
>>>
>>>
>>> The approach expressed by David matches the direction we (as in -
>>> Mozilla) would like to see WebGPU going: allow the user to fully
>>> (*explicitly*) specify what needs to be done, promise the portability and
>>> best performance for well-defined programs, and secure the ill-defined
>>> programs without going extra mile for making them portable or fast.
>>>
>>> It goes somewhat across the Apple's idea that since the browser has to
>>> validate all the API calls (or, in this case, shader code/execution) for
>>> security, it can make detailed decisions on how the work is submitted to
>>> the backend API (e.g. insert pipeline barriers, allocate resource memory,
>>> clamp array indices, etc), thus turning the exposed API to have more
>>> implicit parts.
>>>
>>> Trying to figure out the steps to make an objective (non-opinionated)
>>> call to this issue, we can start with these questions:
>>>   1. Are there any objections to lowering portability/performance
>>> guarantees for ill-defined programs?
>>>
>>>
>>> Yes. Strong objection. If behavior of any programs is not fully
>>> specified, then web developers will start to accidentally depend on the
>>> behavior of one browser (usually whichever is most popular), and then
>>> browsers will have to reverse-engineer each others' behavior. This has
>>> happened so many times in the course of web standards development that it's
>>> almost a running joke. Every once in a while someone says "hey, let's just
>>> not define error handling, we only need to define the behavior for valid
>>> content" it happens. The first time was HTML, Browsers ended up
>>> reverse-engineering each other's error handling until finally they got sick
>>> of the W3C not defining this and formed the WHATWG to create HTML5, which
>>> fully specified parsing behavior for all invalid documents. CSS, JavaScript
>>> and WebAssembly also have fully interoperable behavior by spec, even in
>>> "invalid" or "error" or "ill-defined" cases.
>>>
>>> Let's not make this rookie mistake. We must fully define the behavior of
>>> all programs.
>>>
>>>
>>>   2. Are there any objections to having an optional debug validation
>>> layer?
>>>
>>>
>>> I don't know what that means so no opinion,
>>>
>>>   3. Can we agree that API simplicity is lower priority than security
>>> (starting with obvious), portability, and performance?
>>>
>>>
>>> Security (for some appropriate definition) is a hard requirement.
>>>
>>>
>>> Thanks,
>>> Dzmitry
>>>
>>>
>