Re: Shader language "levels": moving forward

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

Received on Thursday, 24 August 2017 12:34:21 UTC