RFC: Re: shader IR vs. application IR

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.

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.

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.)

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.

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.

> 
> thanks
> david