Re: RFC: Re: shader IR vs. application IR

Whoops I forgot to "Reply all". Adding back public-gpu for context on the
main thread.

---------- Forwarded message ----------
From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, Aug 15, 2017 at 7:19 PM
Subject: Re: RFC: Re: shader IR vs. application IR
To: Corentin Wallez <cwallez@google.com>



(Was this off list intentionally? Replying in kind, but feel free to reply
on-list.)

On Aug 15, 2017, at 3:29 PM, Corentin Wallez <cwallez@google.com> wrote:

Most replies inline but first a small blurb about SPIR-V:

In SPIR-V the client API is responsible for defining an execution
environment for the SPIR-V modules, see for example Appendix A of the
Vulkan spec
<https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#spirvenv>
as
well as the Shader Interface section
<https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#interfaces>.
The API decides on a number of capabilities that the modules have access
too and how the shader resources are declared; for example in Vulkan things
like uniform buffers and textures are "descriptor set variables" that must
have both "DescriptorSet = X" and "Binding = Y" decorations.

On Tue, Aug 15, 2017 at 5:41 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Aug 15, 2017, at 2:29 PM, Kenneth Russell <kbr@google.com> wrote:
>
> On Tue, Aug 15, 2017 at 1:57 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
>>
>> Let's say we started with SPIR-V to make WebSPIR-V with at least the
>> following changes:
>>
>> - Some different APIs and interfaces are exposed than you would expect in
>> a WebGL or Vulkan shader.
>>
>  Not exposing things for security reasons is covered by the third bullet,
so the only difference between a WebSPIR-V and "regular" SPIR-V would be:

   - The way the shader interfaces have to be declared. SPIR-V delegates
   this responsibility to the client API so WebGPU can define it however it
   wants. What's more the binding model for WebGPU looks like it may be
   similar to the Vulkan binding model, so we should be able to use the same
   way of declaring shader variables and get free tooling.
   - Capabilities that cannot be exposed in a portable manner. I expect
   SPIR-V capabilities are already granular enough that we can define a useful
   set of capabilities that can be translated efficiently to other shading
   languages.

Basically we could use SPIR-V as is and "configure" it for our needs. The
SPIR-V flavor we would get would be extremely similar to the flavor tools
for Vulkan output so we would get tooling for free.

> - At compile-time we generate code with runtime bounds checks and other
>> safety features.
>>
> That would require tooling whichever shading language we choose, and
doesn't depend on the input format. Also in SPIR-V in "logical addressing
mode" almost all operations are guaranteed to be safe.


I guess I need to read about "logical addressing mode" to understand why it
implies that.

Basically only OpAccessChain on Storage or Uniform variables is unsafe,
which translates to accessing a buffer bound to the shader. Logical
addressing mode is the only addressing mode allowed for OpenGL and Vulkan
SPIR-V.


Does the fact that it's only one opcode make it easy because we can ban the
opcode? (I'd expect it doesn't greatly simplify adding runtime bounds
checks.)


- We possibly subset SPIR-V to remove dangerous capabilities that can't be
>> effectively guarded with bounds checks or other runtime checks.
>>
>> As mentioned above, only OpAccessChain needs to be checked / guarded.

> If we did all these things, then it seems to me we wouldn't benefit from
>> the existing SPIR-V ecosystem:
>> - Existing SPIR-V shaders could not be reused with WebGPU
>> - Front ends that compile to SPIR-V could not be used unmodified
>> - Existing SPIR-V back ends could not correctly process the modified
>> language, since they wouldn't have the ability to do runtime checks.[1]
>>
>> Is my analysis correct? If so, then what is the benefit of basing on
>> SPIR-V?
>>
>
> Hopefully I've convinced you above that we can easily specify a flavor of
SPIR-V that would be portable, secure and able to reuse all Vulkan tooling.


I'm closer to convinced, but I concede I don't understand all the details
of the safety model. I will read up on logical addressing mode.

This analysis is incorrect and oversimplifies the issues in order to cast
> SPIR-V in a negative light.
>
> The problematic areas are mainly in bounds-checking accesses in the input
> and output buffers to compute shaders. Pipeline stages like vertex,
> geometry, and fragment shaders are well and securely handled by the
> capabilities SPIR-V exposes, since it was designed as a shading language
> for graphics APIs.
>
>
> My point isn't to make SPIR-V look bad. I don't believe there's any shader
> language that meets all our requirements as-is.
>
> My intent is only to argue that it shouldn't have a leg up based on
> ecosystem considerations, because we'd likely have to modify it enough that
> the existing SPIR-V ecosystem won't be compatible with the end result.
> Despite your disagreement, I still think that's probably true.
>
> I'm not clear on how SPIR-V avoids having a bounds checking problem for
> shader types other than compute shaders. Are they unable to use the
> non-bounds-checked operations that compute shaders can use? Do they only
> get access to fixed-size arrays? Do they only get range-checked buffer
> operations? To be clear, I would consider anything that can be used to read
> or write arbitrary locations in video memory to be a security risk. Even if
> it's limited to the video memory of a specific process.
>
> If I'm missing something that makes this a non-issue, please explain.
>
> Instead of attempting to dismiss one particular solution a priori, what
> should be done is to enumerate the needed capabilities of the various kinds
> of shaders in WebGPU, and see what would need to be done to the starting
> point (Metal Shading Language, WebAssembly, DXIL, SPIR-V, a higher-level
> language, something brand new...) in order to have it be secure and
> performant. There are multiple interesting analyses, designs and
> comparisons to be done.
>
>
> I agree that this should be the approach. I did not mean to dismiss
> SPIR-V, merely to argue that it should not be considered to have any
> particular advantage over the other options. Except perhaps on intrinsic
> technical merit, which I think is the point of the overall analysis. It
> might be that a modified version of SPIR-V is sound technical choice
> whether or not it interoperates with regular SPIR-V.
>
> Regards,
> Maciej
>
>