Re: Shader language "levels": moving forward

Thanks for taking this up and advancing the conversation.

I have two things to add, one simple and another more subtle.


- I agree with Kirill that the text-IR and bin-IR ought to be just
different encodings of the same thing.
(If we have a bin-IR, then a text-IR is practically required anyway just so
we can engineer tools properly.  This was our experience with SPIR-V, and
that echoes what Chas in the meeting, and what Keith said about
WebAssembly.)




- What informs the decision on what level to focus on?
  - I think a key factor is judgement about the *feasibility and cost of
ensuring safety.*
  - In turn that's informed by *the execution model of the shader programs*,
at least in general terms

For example, consider the following argument:
  1.  Many performant implementations will run the shaders on a GPU (either
compute or graphics pipeline)
  2.  As Ken described during the meeting, GPUs operate in bulk and can't
(commonly) be pre-empted.  There is no way to signal a precise fault to
halt computation on a fine grain level.  So you must allow for the case
that many other invocations in the compute shader or other primitives in
the pipeline will complete.
  3. For safety, when a fault occurs, you must contain the side effects
from that shader or pipeline.
  4. To have consistent safety rules across implementations, we should
accommodate this GPU case.
  5. Therefore, the common safety model should be expressed in very coarse
grain terms, at suitable "checkpoints":  e.g. side effects must be
contained at level of* an entire of graphics pipeline execution* (or even
worse at an entire command buffer)

If the argument is valid, then a minimum valid implementation could:
 - Keep a single bit per pipeline execution to track whether any invalid
behaviour occurred during its execution.  This is a sticky bit: once set to
"invalid" it stays invalid until the next checkpoint.
 - That "invalid" bit is used to decide whether to discard all side effects
at the end of the coarse grain checkpoint.
 - If invalid behaviour has occurred, the pipeline can continue, and allow
potentially invalid writes to its own storage, provided these side effects
are thrown away at a subsequent checkpoint.

My point is that the assumed execution model affects the cost of safety
checks, and even what checks are necessary for a given language-level.

So: * I think we need to agree on some details the execution model while
evaluating various shader language "levels".*


thanks,
david


On Thu, Aug 24, 2017 at 8:34 AM Kirill Dmitrenko <dmikis@yandex-team.ru>
wrote:

> The answer's in citation.
>
> 24.08.2017, 07:12, "Kai Ninomiya" <kainino@google.com>:
> > In today's call, I think there were some communication gaps regarding
> the different "levels" of shading language/format. I think it's valuable to
> take such a confusing discussion into email, where we can be more precise.
> >
> > I think we agree there are roughly 3 possible levels: GLSL/C-level,
> text-IR, and binary-IR.
> It's not immediately obvious for me why text-IR and bin-IR are two
> separate levels? Aren't they just two representation of a the very same
> thing: the IR? And regarding the 4 question, wouldn't answering them for
> the IR itself kinda give answers for the representations (ok, maybe beside
> the one out ingesting in implementations:)?
>
> > For each of these 3 levels we need to eventually answer these 4
> questions, ignoring (if possible) exactly which language is used at each
> level:
> >
> > - Should we bless any particular language/format at this level?
> > - If so, should we spec/test that format?
> > - If so, should the browser ingest that format?
> Those three question are a bit interleaved, so I'll try to answer them
> from my point of view in bulk.
>
> If we choose for implementations to accept IRs for shaders, then as an app
> developer I don't care much about specifying any particular GLSL/C-lvl
> language as long as there're toolchains to generate IR one way or the
> other. There're however libraries such as Three.js and Babylon.js (and, of
> course, many others) that allow a user to supply a shader. That'll either
> require us
> to choose a GLSL-lvl language and probably even require implementation to
> ingest (the rationale here is that if everуbody ships the same component, a
> compiler is our case, there maybe some sense to standardise and ship it
> with implementations). However, we better ask guys working on those libs
> about that.
>
> Whatever form of shaders we choose (i.e., IR or GLSL-lvl one), I think we
> definitely should specify it and develop a set of conformance tests.
>
> > - If not, should we bless an app-side converter library from that format
> TO the ingested format?
>
> Yes. Or a tool like a reference compiler. Otherwise it'll be somewhat
> tricky to start to use the API.
>
> >
> > It sounds like there's disagreement on these questions right now. So
> instead of asking for opinions on these questions immediately, I want to
> start with this: Are there issues we can discuss first which inform these
> questions? Are investigations or research needed? Are we blocked on "big"
> un-agreed-upon questions such as the security model? (If we're blocked,
> maybe we can agree to eschew this topic for now.)
> >
> > (And if it wasn't already meta enough,) If you have anything to add or
> modify about anything I've said in this email, please bring it up now,
> before further discussion to avoid confusion.
> >
> > -Kai
>
> --
> Kirill Dmitrenko
> Yandex Maps Team
>
>