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

> 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 <mailto: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.
> - At compile-time we generate code with runtime bounds checks and other safety features.
> - We possibly subset SPIR-V to remove dangerous capabilities that can't be effectively guarded with bounds checks or other runtime checks.
> 
> 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?
> 
> 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