Skip to content

Minutes 2018 06 20

Corentin Wallez edited this page Jan 4, 2022 · 1 revision

GPU Web 2018-06-20

Chair: Corentin

Scribe: Dean

Location: Google Hangout

TL;DR

  • Google’s shading language update:
    • More validation, first WebGPU-specific validation
    • Probably going to do our own SPIR-V transpiler.
  • Apple:
    • Working on a formal grammar and execution/typing rules for a WHLSL in the OTT metalanguage. Link in the WebKit repo.
      • Formal spec helped find ambiguities like “T T = T();”
    • Goal to do the same as WASM: formal model and english spec. Be compatible with most HLSL in the wild but remove some of the bad stuff.
      • Concern that real-world engine rely on some of that bad stuff.
    • In 2 months hope to have enough to bikeshed in the group.
    • Current approach deals more with frontend issues, concern that domain specific issues are being ignored (one example is uniform control flow).
    • Whichever language WebGPU uses, WHLSL will be good as an evolving and standardized HLSL.
    • Suggestion to focus on domain specific issues and not language features in the short term.

Tentative agenda

  • Shading languages!
  • Agenda for next meeting

Attendance

  • Apple
    • Filip Pizlo
    • Myles C. Maxfield
  • Google
    • Corentin Wallez
    • Dan Sinclair
    • David Neto
    • James Darpinian
    • Ken Russell
  • Microsoft
    • Chas Boyd
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert

Administrative stuff

  • CW: CLA blocked on Intel accepting it, please ping lawyers.
  • CW: Any update on the F2F if any
  • MM: Nope

Shading languages

Google’s update:

  • DN: More progress on SPIR-V validation, background task. DS looking at adding more validation, then will jump on a transpiler. Investigated whether to use SPIR-V cross, for various reasons will be doing our own. First WebGPU specific validation check going in todo. Adding a WebGPU version 0 to validation tool.
  • DM: writing a SPIR-V to other languages. No WebHLSL to SPIR-V
  • DN: no spec for WebHLSL yet. Will probably extend toolchain to support that dialect.
  • DM: evaluated SPIRV-cross?
  • DN: rule in Chrome, no exceptions. spirv-cross maintainers wouldn’t allow removal of exceptions, so starting from the ground up. Fortunately, have a lot of test cases and satisfy customers, so can reuse their test suite.

Apple:

  • FP: 1 month into 3-month project to specify “WSL”. Also considering calling it “WHLSL”.
  • Have an LL* grammar for it so far.
  • Have formally written execution and typing rules nearing completion.
  • Remaining work: add English text to decorate the formal rules
  • Formal rules are far enough to say that we can say this is an unambiguous language
  • MM: will email the PDF to the list
  • DN: would be useful to be able to see changes from one version to the next
  • FP: have been landing changes in the WebKit open-source repository
  • FP: using a tool called OTT, for formal language specification
  • Write formal semantics using ASCII, finds bugs where language is ambiguous / has conflicts
  • Can spit out LaTeX doc, OCaml interpreter
  • Using this to get pretty LaTeX for the formal rules
  • Style for formal rules: similar to WebAssembly. For every opcode, specifies in terms of formalism, and then English text.
  • CW: still in tools/shadinglanguage/…? (in WebKit) *
  • FP: yes. You’ll see .ott files in there.
  • FP: the wsl_exec and wsl_type. Type and exec rules in formal specs are usually separate. Typing rules just started on. Finishing up exec rules.
  • Summarizes the grammar. Have grammar written with ANTLR. Juicy part of spec starts at page 3. Logical judgments describing how progression of execution of WSL works. Includes enough detail that the OTT detail can generate an OCaml interpreter for this. Covers variable scoping, how control flow progresses, etc.
  • By themselves, it’s not common to have just these rules. Confusing unless you’re experienced in the trade. With English text, looks like WASM spec. Formal spec has revealed places in existing spec which were ambiguous. For example, what do you do if you have a type called T and then a variable called T of type T? Resolving edge cases in the language like this.
  • JD: are we intending to be compatible with other implementations of HLSL?
  • FP: good question. HLSL is, you take Clang and remove things from it. Things hiding which may or not be intentional. No opinion on backward compat with HLSL except, anything HLSL has which can be spec’d and doesn’t have security problems, we should keep. HLSL features which we don’t want: C++ approach to parsing, context sensitive, is super hard, wouldn’t want it in the browser. Took some changes from C# which make it context free.
  • JD: so that means, no, we won’t be compatible with a lot of HLSL out there.
  • MM: our goal is to be compatible with most HLSL. We don’t want to be compat with 100% HLSL out there. There’s some stuff in HLSL not necessary. For example, printf. How far will we go? Don’t have a particular agenda there. The decisions we’ve made so far are a good balance of accepting most HLSL programs while keeping them easy to parse and type check.
  • FP: the things our grammar forbids are probably things programmers wouldn’t write. E.g., “a+b;” works in current HLSL. This is why C++ isn’t context free. C# forbids effect-less expression statements. “a < b”. Fails at parse time. Makes language context free. Wouldn’t expect “a < b;” to be just there without used in an if, assigned to a variable, etc. But means that in a strict sense that it’s not HLSL compatible.
  • DN: there are real engines out there which do odd things. Programs have real effect, maybe wrote them that way because they didn’t have real templating. It’s not the 100% goal I’m interested in, but the things that show up in engines and are intentional. Talk at GDC by Greg Fischer from LunarG on “legalization” talking about code bases coming from real engines. That’s the space I’m interested in. It’s kind of gross, but also dealing with reality.
  • FP: I hear you. The things we’re subsetting we don’t think will have an effect on real world code. “a < b;” decision – we would reverse that if it was used in the real world.
  • MM: part of our effort will be to look at existing HLSL code bases. Want this to be real, not built in isolation.
  • DN: if we have a working parser, we can run it over the corpora we have.
  • FP: yes. You can take the ANTLR sources, build a parser, see what it accepts.
  • CB: the Unreal Engine is out there, all of their shaders are out there.
  • JD: would be interested in seeing results on real HLSL.
  • CB: willing to adapt HLSL if we find things that are stupid which are preventing simplification.
  • MM: goal is to parse most programs with everyone’s collective judgment.
  • FP: in 2 months time we want to have a spec which is self-consistent, unambiguous, and bikesheddable. Want a complete spec at which point if we agree we like it, then we can decide the bikeshed issues (feature go/no-go).
  • KR: How does the execution spec go with the way GPUs actually run shaders.
  • FP: the exec spec operates on AST, so would be the same if GPU were evaluating an outcome. The interesting hardware details start to come across when you say “what does this + mean”. The current spec is more concerned with variables, type resolution, etc. Not at part of exec spec where interesting hardware details would come to light. Dealing with frontend issues.
  • CW: in SPIR-V there’s a lot of issues like barriers between warps, etc. Details that are ignored when you have a high-level shading language. Weren’t well enough defined in GLSL. Concern: though the language is proven to be unambiguous, getting to GPU hardware and its weirdness compared to CPU languages will all still be there.
  • MM: that’s fair. We haven’t gotten there yet. We can solve that problem in the same way every other GPU spec has: inside the execution rules for GLSL, it doesn’t talk about uniform control flow. It has a bunch of English language descriptions.
  • FP: what’s concern with uniform control flow? Don’t think there’s an incompatibility with this spec and the way GPU execution works.
  • DN: classic example: where can I put a barrier? In a place where all work items / invocations will reach it. So have to know that everyone will get there. If you make a choice in one invocation, have to re-converge if you want to put a barrier there.
  • FP: we’re using small-step semantics. Every control flow decision is made explicit in the spec. While we haven’t written that part yet, it’s written in a way that will admit that.
  • DN: there’s one line in the SPIR-V spec: you enter a divergence, you know where you will re-converge. If all invocations enter a construct together, and they can all exit it, then you can validly put a barrier. (? not sure got this right) Small-step semantics are fine, but collective action of re-converging which needs special callout.
  • FP: so far the grammar calls for well-structured control flow. In the grammar, possible to define these points. Don’t feel afraid about being able to say that. Started discussing how we will describe it. It’s hard but no concern there’s a fear that this language will not be amenable to this.
  • CB: can always get the IHVs to weigh in on this.
  • JG: do we have a story for compiling to SPIR-V in JavaScript yet?
  • FP: we have an early prototype but it’s in a barely working stage. Checked into WebKit repo. Have work to do.
  • MM: let’s answer that again in a couple of weeks.
  • CW: what’s the goal here with the language?
  • FP: our goal right now is to create a spec that all of us can talk about, is this the kind of spec that can fit into WebGPU, SPIR-V vs. this spec. These discussions will be easier when we have this sort of unambiguous spec. At that point it will be falsifiable. You can either agree with us, or say no, SPIR-V gets this right and this spec gets it wrong.
  • JD: will you have test results for parsing existing HLSL at that time?
  • FP: think that’s achievable.
  • KR: Learnt from DN about legalization of HLSL when compiling to SPIR-V. SPIR-V closely matches what the hardware does and its restrictions (in dynamically indexing textures etc.) HLSL is more lose. The reason why HLSL is able to run at all is because compilers have required legalization passes, and inline enough code in the right places to make the code run on a GPU. Otherwise it just wouldn’t run. Seems weird to use HLSL as the lingua franca: if it doesn’t describe what the HW does, then there’s a huge gap. Still have the belief that we should use the simplest description of what the hardware can do. Remain dubious that using a high-level language will work when it will have to fight through these issues.
  • FP: i think HLSL came through these things because it’s a subset of C++. Our interpreter takes into account things like what is a function call, passing by value/reference, etc. Based on this experience I think we can have a spec which talks about an AST language and covers all of these issues. The only difference compared to SPIRV is an AST vs. SSA. The productions in the AST can be as low level as SSA. And the grammar is text rather than binary. We’re eager to continue thinking about these.
  • DN: Ken’s concern will show up in whether we get compatibility with existing code bases. We don’t have to rely on opinions.
  • CW: doing this exercise is extremely good because we’ll still use the result at the end regardless. The two extreme outcomes could be: WebGPU uses SPIR-V, but this group standardizes WebHLSL, and that becomes HLSL in some way. And that would be good for the world. Or, WebHLSL becomes that, plus WebGPU ingests it. In any case, doing this work will be useful in the end.
  • JD: heard earlier “WebHLSL vs. SPIRV” and think we shouldn’t look at it that way. We want WebHLSL and the only question is whether we ingest SPIRV at the API level.
  • FP: we’re happy to keep working on it. Looking forward to when we can work on it in the WebGPU Github because then it’ll be more visible what’s going on.
  • CW: we need to sort out the CLA issue. Then will have to decide if we want split meetings about shading languages.
  • MM: don’t want this to be an Apple-only thing. We should all work on it together.
  • CB: Microsoft’s working with Apple. Having an high-level language widely available is useful.
  • DM: spec work is useful. Validation maybe not so much.
  • CW: still need a validator for the ecosystem.
  • MM: we need a validator because we’re making a language.
  • FP: understanding the validation requirements of SPIRV is useful too. I don’t see anyone doing wasted work right now.
  • DN: along with spec work do you have any example shaders? Wondering if there is any extra material that people can read.
  • MM: have a few full shaders but not much to look at. Have a lot of snippets of relevant shaders. Given that this group hasn’t decided how far we want to match HLSL, we’re not going to 100% compatibility but decide on some line, so right now might be a little early to do that. Want to do it.
  • FP: right now our time spent WHLSL code is to write edge case code to break our spec. Type and variable same name. Variable declaration in weird spot. etc.
  • DN: things that motivate a rule here or there would be useful, esp. for odd things. But it’s bonus points. Need to do my homework and learn this formalism.
  • MM: for any spec / standardization effort those things are useful. We’ll wrok on them.
  • FP: one class of edge cases: generic / template syntax that HLSL admits when talking about vectors and matrices. Parser, etc. handle this. Have vectors of floats in multiple different ways to see if way of declaring those in other shading languages also work in WHLSL.
  • CB: this is where Clang doesn’t help with this.
  • FP: this is where a lot of the parsing ambiguities come from.
  • MM: float4 , vec4 can also be written vector<float, 4>, and this has to work.
  • DM: is templating a first-class citizen?
  • CB: no, the templating supported is added in.
  • FP: WHLSL in the reference interpreter has generics very similar to templates, different tradeoffs. Don’t know how much of this we are going to keep. Want to be able to write “vec<float, 4> x” : HLSL supports this so you have to be able to write it.
  • MM: there’s a difference between user defined template types and built-in ones.
  • CW: e.g. fixed number of template specializations.
  • MM: this is a design decision this group can decide on.
  • FP: we’re prepared to add templates if needed. But it will make the compiler more complex. Each browser will have to handle them. I’m OK with that. Right now, the spec we’ll present in 2 months will probably have full generics, and group can decide how much to keep.
  • CW: feels like this wouldn’t be very useful in 3 months. The extra language features can be added by fancy compilers in the client. Your time would be better spent talking about more graphics-focused things. First version of the language, it’s not that useful.
  • FP: thanks, that’s useful feedback.
  • CW: lot of information to take in. All efforts will be useful; no wasted work.
  • CW: we can talk about this more. Have a F2F meeting in September.
  • DN: proposed date?
  • CW: around end of September, in Bay Area.
  • DN: Khronos F2F around end of September, in Budapest. September 17.
  • KR: could try to make these coincide.
  • MM: someone has to pick.
  • CW: let’s discuss on mailing list. Talk about shading languages again face-to-face next time?

Agenda for next meeting

  • KR: discuss Apple’s ISV feedback?
    • MM: wrote up that feedback, but can talk about it next week. Won’t be an hour though.
  • CW: will not be there next week, can Dean chair?
  • CW: try to figure out what minimal demo we are looking for on MVP implementations? Jeff, you have early bindings patches?
  • JG: yes.
  • CW: maybe very tiny bindings to make some tiny tiny application run.
Clone this wiki locally