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

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?

Regards,
Maciej


[1] Ok, it's possible a WebSPIR-V to SPIR-V translator that does static validation and which adds runtime bounds checks could work, that is sort of what ANGLE does after all, but on Metal or DX12 systems it would be silly to translate WebSPIR-V to SPIR-V and then to the native shader language, instead of doing it all as one step. Alternately, we could require runtime checks to be present in the SPIR-V IR itself, in which case there's a complicated (halting problem equivalent?) validation problem to make sure all the places that are supposed to have bounds checks actually have them. I'm assuming these strategies are not ideal.


> On Aug 15, 2017, at 12:27 PM, David Neto <dneto@google.com> wrote:
> 
> Thanks, this is a very good clarification.
> 
> I strongly agree with many of your points.  More detail inline.
> 
> On Mon, Aug 14, 2017 at 7:45 PM Myles C. Maxfield <mmaxfield@apple.com <mailto:mmaxfield@apple.com>> wrote:
> Replies inline.
> 
> —Myles
> 
>> On Aug 14, 2017, at 2:28 PM, David Neto <dneto@google.com <mailto:dneto@google.com>> wrote:
>> 
>> I have a question for Myles.  From the minutes of 2017-08-16:
>> 
>> MM: the language that the author writes their shader in should match the languages they use the API in. If we add / remove features from SPIRV, we’ll need to make it match more the language the API is used in.
>> JK: For Vulkan having multiple high level languages is a strength, no one complained about it.
>> MM: not trying to restrict to using a particular high level language. but if we’re using a set of features from an IR, that set of features has to be applied to the high-level language the author would be writing in.
>> 
>> I disagree with this assertion about how closely the shader IR should match the language in which the API is used.
> 
> I may have been a bit unclear here. I’m not saying that shaders should be written in the same source language that the API is exposed in. (Read: I’m not saying that WebGPU shaders should be written in Javascript.) I’ve clarified it below. 👇
> 
>>   I'd like to know more about why you think this is important.
>> There are many scenarios with good results that don't hold to this requirement, e.g. any current scenario where SPIR-V is used.  I *can* see that some things might be more convenient with the constraint, but definitely not a requirement.
>> 
>> Or have I misjudged the force of your statement?
> 
> We believe that a successful shading language must necessarily be coupled with the API it is being used with. The shading language and graphics API work together, and must not be designed completely independently. Features in the API inform features of the shading language, and vice-versa. You did not misjudge the force of the statement. 
> 
> Here are some examples:
> 
> Data representation: Shaders often need to pass uniform data to draw calls, and shaders are allowed to define structures of data (for example, a “Light” struct may include a position and a color). The API needs to know how to pack this information so that the GPU reads the data at the correct location. OpenGL includes an API where you ask what the particular offset of every item in your struct is, whereas Metal Shading Language is based off of C++, and is intended to let its header files be shared between shader and target application. We have received feedback that developers love the simplicity of the Metal approach.
> 
> I see this as describing the host/device interface.    As you say, we need to be able to describe the same basic data types, their combination into composite types, and how to associate them with externally-provided resurces.   In my view once the fundamental mechanism assures interoperability, good tooling makes it easy to use.
>  
> 
> Tessellation: Metal’s model of tessellation is different from other existing graphics APIs. For example, when using tessellation, your vertex shader runs after the fixed-function tessellation unit runs. Metal Shading Language has facilities for interacting with this, such as describing the post-tessellation vertices within a patch within the vertex shader. Similarly, a compute kernel pre-pass is used for outputting the tessellation factors into a buffer, rather than writing to an intrinsic variable within the draw call.
> 
> Right.  To me the issue really the higher level aspects of the graphics pipeline programming model.  The affect on the shader programming model / language is incidental.
>  
> 
> Security and Environment: A shading language must be compatible with the constraints of the environment its API is running in. For example, a shading language which allows arbitrary reads anywhere from video memory is not suitable for an API present in Web content. (Similarly, a shading language which doesn’t have a concept of UBOs / SSBOs is not suitable for an API designed for scientific computing.)
> 
> Agreed.    Addressing safety / boundedness was discussed a bit last time, when we talked about "logical addressing mode".  We (SPIR-V/Vulkan community) can offer more detail on why we think it offers the required safety.   I didn't say it at the time, but I think there's always going to some need for runtime checks: static analysis can only go so far, e.g. due to halting-problem type limitations.
>  
> 
> Binding model: GLSL allows individual uniform variables (outside of a Uniform Buffer Object), so OpenGL therefore allows uploading of a single individual value to a particular variable in a shader. Metal Shading Language requires uniforms to live in a buffer, and therefore does not include these types of calls. Similarly, a resource in Vulkan is identified by its descriptor set as well as its position in the set, which the shading language needs to mirror. Lastly, a single Metal Shading Language library can have multiple entry points, which changes how authors write their shaders and leads to improved code reuse. Much of the Metal API interacts with a whole library, rather than individual shader stages.
> 
> This another case where it's the programming model that matters.  Impact on the shader language is incidental.
> E.g.
> - SPIR-V is used both in Vulkan and GL.  GL allows so-called loose uniforms, but Vulkan requires them to be gathered like Metal does.
> - Yes, Vulkan requires both a set and binding
> - SPIR-V and Vulkan allow multiple entry points per module, accessed by string name.  Current tooling places only one entry point per module, but that's only because of its GLSL roots.  (OpenCL 2.1+ uses SPIR-V and exercises multiple entry points per module.)
> 
>  
> 
> We bring up the previous points because these are places where we have received feedback from Metal developers describing how they prefer the approach Metal has taken. These features would not have been possible if the shading language was designed without influence from the API.
> 
> Overall, I separate shader language fundamentals from external considerations like environment interfacing rules and the underlying programming model.   For example, language fundamentals would be: what types are expressible, is the language in infinite-register SSA form, is a function is a set of basic blocks, etc.  
> 
> Any minimally expressive shader language ought to be adaptable to the external environment.
> 
> For me this discussion revisits an unresolved issue:  What are we standardizing?  
> - One view is that we standardize a low level mechanism, and then build nice tooling on top of it to expose nice / easy language(s), with a strong push to making the higher level abstractions universally available.
> - Another view is you standardize the easy-to-use layers instead.
> 
> I won't rehash the arguments here, but I separate out the shader language fundamentals from the external factors.  In my mind, your examples (except addressing model issues) are really about the external factors.  So yes, of course those can't be finalized until we know more about the external environment.
> 
> 
> david