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

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>
wrote:

> Replies inline.
>
> —Myles
>
> On Aug 14, 2017, at 2:28 PM, David Neto <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