Chair: Corentin

Scribe: Ken

Location: Google Meet

• The F2F in Google San Diego is confirmed.
• Implementation status:
  • Apple:
    • Crawled HLSL repos on Github to find sources of incompatibilty, Lots of use of the preprocessor, found ~12 changes to the language needed for 90% compat.
    • Started implementing the API in WebKit itself, have prototype HelloTriangle
  • Google:
    • Making progress on making Dawn match WebGPU, it is tested on all 3 platforms on every commit, will work on Chromium integration soon.
    • Created start of SPIR-V execution environment, filling WHLSL issues, fuzzing SPIRV-Criss.
  • Microsoft: Nothing to report
  • Mozilla: Have FF bindings and a wgpu native library on top of gfx-rs. Very WIP
• Preprocessor:
  • Most uses are for #define and #if/endif
  • Disagreement on how hard it is to spec a minimal preprocessor
  • There are tiny C/C++ preprocessor libraries that could be WASMed
  • Could also be replaced by specialization constants except for bindings.
• Deviations between WHLSL and HLSL
  • WHLSL doesn’t have methods like texture.Sample. Could be added as a sugar.
  • Hard to leave them out completely, 40% of HLSL shaders uses texture.Sample
  • The DXC SPIR-V backend made a list of aspects of HLSL that are hard to support.
• Homework for next time:
  • Apple would like to see a list of each opcode in the execution environment along with whether it is allowed or not, and potentially a formal description of its execution.
  • Google would like to see progress on WHLSL’s memory model.

• Implementation status
• Shading language
• Agenda for next meeting

• Apple
  • Dean Jackson
  • Filip Pizlo
  • Justin Fan
  • Maciej Stachowiak
  • Myles C. Maxfield
• Google
  • Corentin Wallez
  • Dan Sinclair
  • David Neto
  • James Darpinian
  • Kai Ninomiya
  • Ken Russell
• Microsoft
  • Chas Boyd
  • Rafael Cintron
• Mozilla
  • Dzmitry Malyshau
  • Jeff Gilbert
• Mehmet Oguz Derin

• CW: San Diego F2F confirmed, will send email soon.

• Apple
  • MM: heard that HLSL compat is really important or even the most important thing
  • MM: wrote a github crawler to find repos with lots of HLSL source files
    • Picked ~20 repos from the list
    • Chiefly: no compilers. Think this is imp’t because compiler test suites include every corner case of languages, which isn’t what we’re after, but rather real-world use.
    • Ran parser over it. Found lots of uses of the preprocessor. On average, there’s a preprocessor directive every ~10 lines in the corpus.
    • 2 paths we can take:
    • 1. We can spec a preprocessor, make it as simple as possible.
    • 2. Authors have to preprocess their source.
    • In order to proceed, we took our corpus, ran it through MSFT’s preprocessor, and now have a corpus without preprocessor macros.
    • Compatibility there:
    • Doesn’t have very good compatibility yet. ~5% successful parses.
    • Found several compatibility improvements to WHLSL that would improve parsing rate a lot.
    • Found ~12 changes to language that would deliver 90% compatibility. Some are more imp’t than others.
  • DJ: in WebKit we have a start of the implementation of the API itself. Code landed can’t draw a triangle yet, but coming soon.
  • CW: we should focus on the IDL a bit more. Have partial pipeline changes, need to remove.
  • DJ: I’ve been going through the IDL slowly to fix it.
  • MM: IDL doesn’t capture uploads/downloads yet.
  • CW: would like to fix. Buffer mapping also not done. Let’s talk about that maybe next week.
• Google
  • CW: still making progress on making Dawn match WebGPU API. Want it to be 1:1 mapping between Web IDL and C++ header. Some things will be different: no C++ Promises in headers for example. Still lot of things to go through.
  • CW: done infra work to test all 3 of Dawn’s API backends on every commit. Working on Chromium integration soon.
  • CW: shading language: created beginning of SPIR-V execution environment for WebGPU. Hard to have concrete discussion about it. Please open issues with concerns about it, so we can have 1 thread per concern.
  • CW: spent time studying WHLSL and opening issues there.
  • CW: fuzzing SPIR-V cross.
  • MM: thanks for filing WHLSL issues.
  • DN: I put links under the shading language section where those artifacts are. Was prior discussion about undefined behavior in SPIR-V spec, mostly from Kai. CW had 5-6 other cases that have to be included in env spec, too.
• Microsoft
  • RC: nothing to report aside from reading wonderful PRs and issues, and providing feedback where appropriate.
• Mozilla:
  • DM: have start/end of pipeline: FF bindings for old WebIDL, and a library which exposes a C API written in Rust which implements the Web IDL. Resources, state tracking, etc. but not wired up yet.

• DN: Filed cluster of issues on WHLSL memory model. Unimplementable, ignores races between writes, etc.
• DN: Filed cluster of issues on WHLSL entry point interface:
  • ambiguities,
  • missing pieces,
  • no statement of how data is laid out in buffers
  • specialization constants not designed yet
• DN: First draft of proposed execution environment. https://github.com/gpuweb/spirv-execution-env/blob/master/execution-env.md
  • Some general parts, but mainly WebGPU env spec for SPIR-V
  • Corentin folded in text describing out-of-bounds cases and recommended outcomes
  • TODO: Fold in remaining undefined behavour cases from a year-old issue. See https://github.com/gpuweb/spirv-execution-env/issues/2 for what remains.

• MS: while the full C preprocessor is tricky, implementing just a small subset of it is tractable as part of the parser, and doesn’t have to be as complex. This is another option.
• CW: my experience with ANGLE is that even #defines are a hairball. We fuzzed ANGLE’s preprocessor and it was difficult.
• FP: the C preprocessor used by AOT compilers isn’t a hairball. ANGLE might be having some outlying experiences in this area.
• MS: another option is to require people to preprocess. Multiple options.
• DN: where would developers do this preprocessing?
• FP: you could load up a C preprocessor in your web app, etc.
• DN: what’s the expectation that developers have currently? Preprocess in the app, or on the target machine?
• CW: looking at existing frameworks, think they would want to preprocess at runtime. Depends on what the browser ingests. If the browser ingested pre-compiled pre-ingested things, they’d want to handle that at build time, otherwise at runtime.
• MM: tried to analyze usage of preprocessor. ~9% were includes. Others were #if/endif. Seem to use it to enable/disable rendering features.
• CB: in the AAA space, this is a specialization usually done on the client based on what’s installed.
• MM: if people are using the preprocessor to write code which affects the shading algorithm itself, seems we should try to include this in the language.
• DN: that was the hypothesis with specialization constants in SPIR-V. This would be the way to specialize code.
• DJ: we’ve got some SPIR-V output happening for WHLSL, but not for all WHLSL programs yet. Haven’t run it through a SPIR-V implementation yet.
• DM: had a question about which language features were imp’t for compat.
• MM: C buffers. Something only in HLSL, not in Metal.
• MM: global variables. Resources (resource decl in global scope), and static const data which anyone can refer to.
• MM: default arguments are pretty popular.
• MM: Syntax for texture functions: in HLSL “texture.sample(...)”, WHLSL doesn’t have the dot syntax
• MM: HLSL parser supports any arbitrary semantic name, not just well-known ones?
• MM: Casting style: HLSL uses C-style, not function-style casts
• MM: array decls: putting brackets after variable name rather than type.
• DM: HLSL is an OO language, yours is not at this point. ?
• MM: methods in side structs.
• DM: things like textures and samplers having methods you can use.
• MM: language doesn’t have to be OO. Can teach parser what texture.sample(args) is.
• FP: WHLSL is OO but doesn’t have the syntactic sugar of a method call. That’s just sugar we can add without much trouble.
• DM: it’s not part of the language but you’ll still parse it?
• FP: yes. Desugaring. Will turn that feature into some other feature. a.b(c) -> b(a, c) is enough to give you method call syntax without methods.
• MS: it’s just a way to implement this without modifying the core language.
• DM: trying to match this with the claim that WHLSL is as low-level as SPIR-V. You’re saying that there is more syntactic sugar that will be resolved to these core features?
• FP: fairly simple rule we’re trying to add to the parser. Analogous to adding a new opcode to SPIR-V.
• JG: nobody’s upset about this. The surprising bit was that it’s not part of the language, but it is, just not the core.
• FP: method/function calls have a symmetry.
• MS: SPIR-V analogy would be adding a new opcode that does the same thing.
• CW: if method calls are sugar in the spec, is it part of the language or not?
• MM: the grammar will accept that syntax. That doesn’t affect things like function overload resolution.
• CW: was worried that there would be another compile step from HLSL to WHLSL. Glad there won’t be.
• DN: overloading; if you add a method like “flip” on a sampler. Then you could write “sampler.flip()”?
• FP: yes, that’s an outcome (for better or worse) of desugaring.
• DN: is that true if the first parameter’s an int?
• KN: would depend on the type.
• JG: did you consider leaving this as a deviation from HLSL?
• MM: something like 40% of HLSL source files use textures and sample from them.
• KN: it’s just this function you need it for right?
• MM: this, and texture bounds. e.g. is this a 3x4 texture.
• JG: if people are doing a 1-way port from HLSL to WHLSL this would be an easy deviation to fix.
• KN: don’t think it’s feasible to do a 1-way port if it’s not backward compatible.
• CW: would probably still work for HLSL. You’d define a function “sample” which does texture.sample.
• FP: this is such an easy desugaring to add that we should.
• JG: I like this desugaring.
• MM: if we wanted to add real methods we might not be able to do this.
• FP: not sure that’s true. Gives us a path for adding methods. Main downside is that we’re introducing an incompatibility with C++: methods scoped to a class are in a different namespace than those at the top level. Doesn’t prevent us from adding more sophisticated mechanism later.
• MS: typed polymorphism for functions is also doable in the form of overloading. Adding a polymorphism at runtime is totally doable. Doesn’t clash with function call syntax. There are languages that have sophisticated dispatch based on argument types that don’t have the dot syntax.
• MM: another detail: didn’t find anything deal-breaking. Should send this list out. Will do.
• KR: DN, DS can you point out the issues lowering HLSL to SPIR-V? These incompatibilities are important for this group to understand.
• DN: there’s a document in the shader compiler repo that shows the examples we’ve found in real games and apps. You have to do a fair amount of transformation of the original code to get something runnable. Passing buffer references, returning samplers. In dxc, we parse through MSFT’s parser, translate to naive SPIR-V, go through optimization passes to get to valid SPIR-V. We didn’t do this for fun; did it to get applications running. MM: what your team’s done is good for avoiding corner cases; these were ones that had to be done to run at all.
• MM: these are difficulties producing SPIR-V from HLSL?
• DN: there’s a semantic gap between what you can do in HLSL (passing image handles around, storing things to structs, assuming things are dead code eliminated, etc.) and what’s valid for Vulkan. Doesn’t matter what language you end up going through. There’s a semantic gap that needs to be bridged.
  • Examples in the “HLSL Cookbook”
    • https://github.com/Microsoft/DirectXShaderCompiler/blob/master/docs/SPIRV-Cookbook.rst
    • And captured in a suite of HLSL source files
    • https://github.com/Microsoft/DirectXShaderCompiler/tree/master/tools/clang/test/CodeGenSPIRV/legal-examples
• CW: to be 100% conformant to HLSL / fxc there are a lot of things that should be incorrect that are papered over by optimization passes in fxc. Being 100% compatible with HLSL means replicating lots of optimization passes in fxc. Would be good to remove these warts.
• MM: you’re suggesting changes to WHLSL to make it easier to output SPIR-V?
• CW: rather, to avoid dependence on existence of optimization passes.
• MM: would like to read more about this.
• DN: have added link above about HLSL cookbook and ~20 shaders that came from game engines.
• CB: when converting HLSL to Metal do we expect similar restructurings?
• MM: probably not.
• MS: SPIR-V is probably the most restrictive of our shader execution environments.
• DN: SPIR-V on Vulkan is the restrictive one.
• MM: did we ever resolve what to do about the preprocessor?
• MS: don’t think we have to decide what to do right now but should look at preprocessor features people rely on, and explore various options. Full preprocessor, minimal one, etc. People doing online compilation (three.js, etc.): do that need a preprocessor? Probably don’t have enough information to conclude.
• DN: many of the cases are for runtime specialization. If we can capture this without a preprocessor, might eliminate a need.
• MS: we’re confident that runtime specialization can be handled. If you probe a runtime feature and change a constant, we can strip out dead code. The preprocessor’s only being considered for compatibility.
• CB: GPUs are so much worse at flow control than CPUs, specialization is much more important for performance. Devs aware of this; they use many different mechanisms (preprocessor, recompiling shaders at runtime).
• FP: are you saying that specialization constants are insufficient for this? There seem to be 3 different claims: 1) no preprocessing or spec constants 2) spec constants 3) preprocessor, but mainly for compatibility.
• CB: I can’t commit to that. Think people have probably done clever things with preprocessors that we haven’t found yet.
• FP: someone wrote a C preprocessor in ~2k lines. Could compile with WebAssembly.
• KR: could do the same with the language.
• FP: interesting observation that you can do frontends on whatever WebGPU accepts. Orthogonal to whatever WebGPU accepts.
• CB: one more piece. Middleware / frameworks: at the time the framework was written it didn’t know what the app was going to do. Lot of interest from these devs in doing the specialization on the client to understand the device characteristics.
• MS: what kind of specialization?
• CW: for compute shaders: spec on size of warps and register file they can address from these warps.
• CB: you tile matrices for different cache sizes.
• MM: spec on number of lights they want to light pixels with.
• CW: CB was talking about framework code adapting to the hardware.
• MS: specialization: 1) generic for your use but you specialize for yourself. Could do AOT. 2) code reuse. Instead of runtime branch, want specialization. 3) want things to work differently based on hardware characteristics. Would have to have pre-altered form of shader for each hardware config.
• CW: correct.
• MS: for others you could imagine that happening offline in a more automated way.
• JD: earlier you suggested adding preprocessor as a language feature. Did work for limited set of use cases; can’t do everything you can in the preprocessor.
• MM: what’s the benefit of adding it to the grammar?
• MS: many compilers today have the preprocessor integrated. Benefit is you don’t have another pass doing text preprocessing. Simplicity.
• CW: ANGLE’s preprocessor is integrated in the parser too. Expands tokens on the fly.
• FP: probably easiest to spec preprocessor as string-to-string transform. No problem restricting the features of it to match the parser.

Homework for next time

• FP: following evolution of exec env document. Think that right now, the issues we have with it are best described verbally and not as Github issues. Would love to see a version of that document that outlines the execution of each opcode. Right now, written as a list of deltas that doesn’t feel exhaustive and can’t know whether it’s exhaustive.
• CW: not exhaustive right now.
• MS: for tracking purposes we can file issues, but right now they’d be high level. Right now exactly one opcode is banned. A few listed as accessing memory, but have to read whole SPIR-V spec to know it’s exhaustive. Multi-spec thing is hard because rather than spec’ing security qualified semantics of opcode it installs side constraints. Have to think about: is the combination secure? ambiguous? Is it likely for real-world shaders that they’ll get different results from this ambiguity?
• CW: for concern about exhaustive list: for each section of the SPIR-V spec and exec env, we can copy out every opcode and say “supported / not changed / changed”. Tedious, but not hard to do. Could make things more clear.
• CW: concern about side constraints making things hard to read: if we want to rely on hardware features to do robust buffer access, it seems it has to be encoded on the side. Robust buffer access works the same across many different kinds of operations, and works differently on different GPUs.
• FP: the way that JS bounds checks work is different on different implementations but they are all spec’ed. The difficulty here is that there are different techniques under consideration (clamping, trapping, etc.). Choose among different outcomes.
• MS: easier to write this as, “one of these will be the outcomes”, rather than ambiguous.
• CW: do you agree that the exec env is already doing this?
• MS: no. the exec env isn’t saying, to implement this opcode here are the valid behaviors.
• FP: discussion about JS spec and english / OCaml implementations. SPIR-V doesn’t have this level of granularity.
• DN: before we end: I’d like some progress on WHLSL’s memory model. About 4 of them are fundamental. Races between writes is not contemplated. Would like clarity on how memory works.
• CW: can we please have this discussion on the issue tracker. Could you please file a bug about the form of the exec env you want, per discussion above.

• CW: Need to go back to buffer mapping. Google will make a proposal. Has changed because we have implicit barriers now.
• CW: push constants vs. dynamic buffer offsets.
• CW: (stretch) multi-queue