Re: [WGSL] Test for round-trippability

Myles,

Thanks for trying to advance the conversation.

Google suggests that the CG defer defining the round-trip requirements
until we have had the time and opportunity to publish further updates to
the WGSL specification. The current WGSL snapshot is known to be incomplete
in many areas, and was hastened toward publication in order to enable
forward progress in the CG.

Based on feedback from developers with whom we collaborate, the definition
of WGSL in terms of SPIR-V semantics, and round-trippability to SPIR-V, are
hard requirements. The criteria Apple proposes seem to allow significant
deviation from these requirements. Still, we would like to avoid responding
point-by-point at the present time, in the hope that further clarifications
to the current WGSL specification may alleviate concerns and make it easier
to reach consensus.

Is deferring this conversation for the time being acceptable to everyone?



regards,
david




On Sun, Mar 29, 2020 at 7:40 AM Myles C. Maxfield <mmaxfield@apple.com>
wrote:

> Hi!
>
> There has been a fair amount of discussion
> <https://github.com/gpuweb/gpuweb/issues/622> recently about the process
> of round-tripping SPIR-V -> WGSL -> SPIR-V. In particular, this
> round-tripping operation may introduce
> <https://github.com/gpuweb/gpuweb/issues/579> some modifications to the
> original source which were not present
> <https://github.com/gpuweb/gpuweb/issues/581> in the original source.
> This group has already agreed that the round-trip will not be
> byte-for-byte identical
> <https://docs.google.com/document/d/15Pi1fYzr5F-aP92mosOLtRL4qLczmVRWQaomfQmGNzo/edit> to
> the original source. However, the WGSL group hasn’t come up with a set of
> criteria for whether not a transformation is too disruptive to the original
> source to introduce.
>
> It is also accepted practice in WebGL for certain browsers to reject
> specific versions of certain drivers which are known to have bugs in them.
> In addition, the WebGPU group has already required certain common Vulkan
> extensions, thereby effectively rejecting specific Vulkan drivers which
> don’t support those common extensions.
>
> With all that in mind, I’d like to propose the following test to determine
> whether a particular construct in the source SPIR-V program must be
> required to be unperturbed in the round-tripped SPIR-V program:
>
>    1. A class of shaders exists, written in a human-writable shading
>    language, which a human might have reasonably written
>    2. … when compiled from that human-writable language into SPIR-V using
>    the latest version of a popular compiler, and then the construct is
>    perturbed (e.g. a variable hoisted, or a const promoted to a variable, or
>    duplicate code moved to a common function, etc.),
>    3. … it results in a reproducible and significant performance or
>    correctness problem
>    4. … on a shipping system configuration of the most recent version of
>    a major browser (because only new browser versions will get WebGPU)
>    5. … which has a significant number of users
>
>
> If passing this test can be demonstrated, and the specific performance
> results or incorrect behavior can be displayed publicly (preferably on a
> WebGPU GitHub issue), then this is a compelling case to redesign WGSL such
> that it doesn’t require this specific perturbation.
>
> This also goes for HLSL and MSL. If compiling to HLSL or MSL produces a
> problem which passes this test, then that is is a compelling case to
> redesign WGSL such that it doesn’t require this problem.
>
> Thanks,
> Myles and the rest of the WebKit WebGPU team
>