Skip to content

Minutes 2019 08 19

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

GPU Web 2019-08-19

Chair: Dean (Corentin on vacation)

Scribe: Ken

Location: Google Meet

TL;DR

  • PR Burndown
    • #385 - Add textureCompressionBC to GPUExtensions
      • Delayed until we have more spec to go with it.
    • #384 - Add a component type for GPUBGLBinding compatibility
      • Approved
    • #383 - Remove the 16bit component snorm formats
      • Approved
  • Shading language
    • Status updates
      • Apple: Progress on WHLSL, have security tests and a collection of demos working. Outreach to 29 developers with some questions about shading language.
      • Google: 134kb WASM module for online compilation of GLSL ES 300 to SPIRV. Upstreamed soon. Landede a Robust Resource Access SPIR-V transform pass. Tests on Dawn and Vulkan.
    • Summary of Apple’s outreach feedback
      • Developers split 4 ways: don’t care or want WHLSL/GLSL/SPIRV only.
      • A lot of developers treat shaders as assets that are hard to translate / rebuild.
    • Focus for the F2F:
      • Apple: the group should have clear ownership of the language in a way understandable to non-programmers. Have the standard be as few parts as possible.
      • Google: shader robustness testing, making existing developers using GLSL not have to rewrite all their code.

Attendance

  • Apple
    • Dean Jackson
    • Justin Fan
    • Myles C. Maxfield
    • Robin Morisset
    • Saam Barati
    • Filip Pizlo
  • Google
    • Austin Eng
    • Corentin Wallez
    • David Neto
    • Idan Raiter
    • James Darpinian
    • Kai Ninomiya
    • Ken Russell
    • Ryan Harrisson
    • Sarah Mashayekhi
  • Intel
    • Yunchao He
  • Microsoft
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Mehmet Oguz Derin

Administration

PR Burndown

  • #385 - Add textureCompressionBC to GPUExtensions
    • CW: Should we accept?
    • DM: Yes
    • JG: I think we need text to go with it.
    • CW: you want to defer until spec’s more ready?
    • JG: yes. Investigation still happening, things need to be resolved. Let’s do whole instead of half. “Weak no” but not reject, from me.
    • CW: could be something that lives in Chromium’s IDL for now.
  • #384 - Add a component type for GPUBGLBinding compatibility
    • CW: in most APIs this is undefined behavior - to use a different texture type than the texture itself. uint texture w/sampler that uses filtering -> undefined. Component type of texture views should match.
    • RC: should this be part of the view rather than the binding?
    • CW: it’s a compat constraint between the shader and the view. Can’t be part of the view.
    • RC: in the binding, at runtime, have to make sure binding agrees with the view?
    • CW: in BindGroupLayout...we have to make sure the component type matches
    • JG: you don’t have to do this.
    • CW: get garbage data on Vulkan then.
    • JG: could reject at command buffer writing time.
    • DM: at recording time. Add’l property we have to validate. No point to defer until drawing time.
    • JG: annoying to have to spec this.
    • CW: it is, but bind group layout specs how the pipeline interacts with its environment, so much faster to make sure env and pipeline match.
    • JG: I’m more interested in this if it defaults to float.
    • CW: happy to do this and add more defaults.
    • JG: should either default to float or be required.
    • CW: it’s not currently required. Will update PR to have it default to float. Everybody happy?
    • DM / JG: yes.
    • RC: LGTM. Alternative is to whip up more pipelines on the fly.
    • CW: or more expensive validation.
    • KN: possible to figure this out. Possible to figure this out from the pipeline itself. If you have the shader you can check it, but don’t know until you know what pipeline you’re using.
    • MM: no comment from Apple.
  • #383 - Remove the 16bit component snorm formats
    • CW: removing some formats not supported on recent Qualcomm hardware.
    • KN: pretty soon we’ll be out of formats. :D
    • JG: would be nice to have a clear list of formats we always support.
    • CW: that’s in the spec.
    • JG: we keep getting rid of a lot of these. One of RC’s points was that maybe we should have a way to query for optional types.
    • CW: extensions.
    • DM: it could be an extension. If RG16_SNORM is supported, likely RGBA16_SNORM will be too.
    • JG: if we have 4 different classes of formats, don’t want to shove all of them into an extension. Default-supported things in the impl, but the driver we’re running on them might not support. Could be extensions, but really want to know, can I use this format?
    • KN: I’ve been thinking about rephrasing how extensions work. Want to provide a list of all the capabilities. We have GPUExtensions which is a list of booleans. If we instead renamed it to “capabilities”, then we can put extra things in GPUCapabilities. Then, when we have extensions, we spec that it adds X capability. If we think of capabilities as lower overhead than WebGL extensions, then it seems okay to phrase them in this way.
    • CW: like spec-built-in extensions.
    • JG: you have to ask for these at the beginning of time. Everyone’s just going to add the list of extensions into the list of capabilities. Anyway, I’m fine with this.
    • DM: could have mechanism where users could say, I want this extension but it’s not required. Creates the device, then query.
    • KN: they can already do this. Concerned what will happen if they requested something and then it wasn’t there. Portability problem.
    • RC: support to this point has been yes/no. What about, is it blendable? Can I sample from it? etc.
    • CW: will be a list of things you can do with each format.
    • DM: these are vertex formats right?
    • CW: no, texture formats, and they’re all renderable.
    • KN: So Rafael, you’re saying the texture support table needs to be richer than the capabilities table and should be more than yes/no.
    • CW: in Dawn we’re building such a table based on drivers and testing. Will contribute to spec. Think it’s pretty correct. The spec will have such a list: this format is renderable, filterable, UAV-able, etc.
    • RC: makes sense. All options supported in all APIs?
    • CW: yes.
    • RC: and if we add more later we’ll have a CheckFormatSupported-like thing, etc.?
    • CW: yes.

(PR burndown stopped at this point)

Shading Language

  • Status updates
  • Apple
    • MM: spending a lot of time on WHLSL. Have an implementation behind an experimental feature flag in Safari Preview. Shipped a couple of weeks ago. Focusing on areas:
      • Security: think the Metal code we emit is secure in buffer accesses and reads/writes. Have substantial test suite. Runs on real GPUs. Can run graphics / compute shaders on Macs today.
      • Spec: fairly polished. Not complete, but think it’s usable.
      • Perf of compiler: WHLSL -> MSL is 10% of the Metal compiler itself.
      • Collection of different demos working. Many are shared between Chrome and Safari. Have almost all of the Helmet Babylon demo working. (Haven’t implemented cubemaps yet.)
      • Outreach. Think we’ve been fair. Talked with 29 different external teams (using WebGL today) about interest in shading languages and what they hope / desire. Can get into the meat of what they’ve been saying.
    • MM: all in all: have compiler that runs real code on real devices, safe, is fast.
    • DM: compiler targets MSL? Any update on it targeting SPIR-V?
    • MM: no. We’ve been working on Metal, we don’t have a lot of Vulkan devices. Main compiler has a strict API between platform dependent/independent parts.
  • Google
    • DN: Status update:
    • Online compilation of GLSL to SPIR-V for WebGPU, for current WebGL users with online generation of shaders
      • Rafael asked for small module for embedding with babylon.js
      • Google now has 138kB module: 6.6 kB from JS and 131kB from WASM (glslang). Supports GLSL ES 3.0 (for WebGL 2.0 support). Full language coverage. (No compute shaders yet, but WebGL 2.0 doesn’t support that.)
      • Will continue development, e.g. add compute shaders
      • Some of these patches are being productionized and committed to master
      • DJ: it’s not a port of glslang to make it smaller for wasm?
      • DN: no, it will go onto master. Have been trying a lot of things.
      • CW: it’s upstream glslang, slimmed down, wasm port.
      • DN: the upstream glslang supports all GLSL versions, so once you strip out desktop support, vendor extensions, etc., it gets smaller.
      • RH: Experimental/Prototyping/Proof of Concept branch: https://github.com/zoddicus/glslang/tree/wasm-merged
      • RH: Emscripten/WASM build rules already upstreamed https://github.com/KhronosGroup/glslang/pull/1867
      • RH: Current outstanding PR with majority of implementation https://github.com/KhronosGroup/glslang/pull/1855
    • Landed a SPIR-V transform to inject address-index clamping, to emulate Vulkan’s “robust buffer access” feature.
      • Useful if underlying API does not support robust buffer access natively
      • Tested on Vulkan and Dawn: example
      • WIP(?) incorporate into Dawn’s Metal backend
      • Intent is that this will be injected after consumption from user and on its way to e.g. the Metal backend.
      • MM: is that part of spirv-cross?
      • DN: transform in spirv-tools’ optimizer suite. Will link to PR.
  • Intel:
    • YH: no status updates on shader part.
  • Microsoft:
    • RC: no status updates or work on this.
  • Mozilla:
    • DM: working on some things but nothing to report.

Shader Discussion

  • RC: brief summary of opinions of the 29 teams? Range of opinions?
  • MM: nobody I talked to agreed to have their names / words used directly.
  • MM: focused on engines using WebGL. Talked with one engine that didn’t use WebGL.
  • MM: found roughly even split 4 ways:
      1. Don’t care, will take whatever.
      1. WHLSL would work better for them.
      1. SPIR-V would work better.
      1. Don’t touch my GLSL. Don’t want to deal with extra stuff.
  • RC: think that answers my question, yes.
  • CW: that’s interesting.
  • MM: many of the GLSL users we talked to generate their shaders at runtime. A lot of them either have lots of preprocessor macros, or assemble shaders from snippets by copy/pasting. Think that’s a case we should have a story for.
  • CW: makes sense. We’ve been talking with Babylon folks and their use case for online shader compilation. The slimmed down glslang makes this palatable. There’s a lot more we could do. Even if people are doing GLSL and want to port to WebGPU that doesn’t do GLSL, there are a lot of options to help them do a lot of compilation offline, so people doing just GLSL don’t have to pay run-time cost.
  • MM: talked with game developers and engines. Asked a lot of questions. One: do people who use your engine write their own shader snippets? No overwhelming majority either way. Some engines have built-in shaders, but others let authors write their own GLSL snippets. Of the latter, ⅔ of them would require strong backward compatibility. Others say their way forward would be to have bimodal engine - if you wrote GLSL they’d use WebGL, and if you used the other language you’d use WebGPU. Also the way SceneKit works.
  • RC: you said ¼ of the people are in the GLSL camp. By being in that camp are they unwilling to use anything else? I’m not going to port to WHLSL no matter what?
  • MM: in general, yes. Didn’t want to port shaders, change API to use compiler, etc. They already have a pipeline that works for them, don’t want to change it.
  • FP: they’re equally opposed to porting to WHLSL, too.
  • JG: they realize they’ll have to create pipelines and bind groups, right? It’s not the same API as before?
  • MM: many teams treat shaders as assets. Imagine you have to pay your artists to make new textures.
  • JG: understood. But aversion to having runtime compiler seems a preference, not a requirement.
  • FP: how to empathize with these people: if we told anyone that in order to use new JS features they had to distribute a WASM compiler to transpile on the fly, they wouldn’t like that. Telling people they have to package something to support their old language, can understand why that’s offputting.
  • MM: one team was trying to get their whole engine in 100 KB. Wouldn’t work for them.
  • KN: not sure you have this data point but: for people who want to keep using GLSL, are they going to use WebGPU or are they going to keep using WebGL?
  • MM: for them, WebGPU is this nebulous feature and they don’t know what they’re going to do with it yet.
  • CW: makes sense. Don’t have a spec, explainers, etc. to show them.
  • KN: under assumption that WebGL keeps working, for people that don’t do porting effort they’ll just keep using WebGL? But that only covers people not treating shaders as assets.
  • CW: thanks MM again for the data. The 4-way split is funny / sad at same time. GLSL is an option, WHLSL is an option. Many options. At the end we’ll need a strong ecosystem to satisfy everyone: people coming from native APIs, WebGL folks.
  • MM: tried to ask about ecosystem. Q I asked: has the GLSL ecosystem helped you in your engine? Most people didn’t understand the question, didn’t get good feedback.
  • DJ: I don’t understand the question, either. StackOverflow answers, etc.?
  • MM: was thinking ShaderToy. If there were 100 languages being used on the web then ShaderToy wouldn’t work.
  • CW: if we’re bringing stuff online on WebGPU there will be shader translation happening somewhere. From native, from WebGL GLSL, etc. People need to be able to instrument their shader. Lot of tooling around shaders is needed. In WebGL, a lot of the ecosystem is coming from the OpenGL ecosystem, can find lots of answers about GLSL on the web. For WebGPU we need more than this. Need shared knowledge plus tools.
  • DN: people spend a lot of time making their shaders work. One dev I worked with was willing to rewrite the API side 10x over but not their shaders. So we built a whole compiler for them. That’s work outside the implementations. Help people stay wherever they are, mostly, and still come to your platform. That’s what I see as the ecosystem. Disturb them as little as possible but give them the better performance, etc. All the tooling to reduce pain points to get them onto your new thing.
  • DM: what’s the hesitation to touch the shaders?
  • DN: the shaders were viewed as the core intellectual assets of the group. Portable, hardened, very high cost to change / reverify. Would rather have some other team create compilers, analyzers, etc.
  • CW: shader codebases can be orders of magnitude larger than the codebase which touches the API.
  • MM: is that team you’re describing writing shaders in their own language?
  • DN: it’s not HLSL. It originated from CUDA. CUDA’s close enough to other languages that you can go very far from that original source. Old codebase, sometimes an acquisition involved. Sometimes agglomeration of old codebases. Single tree that targets multiple platforms.
  • FP: it’s not like GLSL or HLSL? C-like but something different?
  • DN: Yes. It’s very very vanilla in its features. All compute, all C-like. They’ve got mounds of code they don’t want to reverify.
  • DJ: there’s one thing Robin wants to cover on the processing model. For next month: let’s talk about the “dealbreakers” - the positions each of the implementers have in order to make their decision.
  • RM: want short discussion of uniformity analysis. Feedback from mailing list was relatively positive. Anyone in the community opposed or think it should be changed?
  • DN: think it’s fundamentally sound. I commented on the doc that discard wasn’t treated, because WHLSL didn’t have it at the time. Like relative simplicity of it - can give clear errors to the user.
  • MM: let’s say we accept this proposal. How would that work in SPIR-V?
  • RM: should be possible to adapt.
  • MM: there is some modification needed.
  • CW: my understanding is that in SPIR-V that could be an additional constraint. It’s basically a validation constraint and has to be encoded as much in the execution env.
  • DN: as soon as you identify the nesting, have to walk it and propagate attributes down the paths and generate messages.
  • CW: what’s on our mind is: 1) will be testing robustness of shaders - it’s a crucial feature of WebGPU that we haven’t paid enough attention to testing wise. 2) We’re partnering with at least 3 WebGL users to port their app to WebGPU. We feel their need to have GLSL “just work” in WebGPU in some way or another. They can’t rewrite their shader code bases. Like security and compatibility were the path forward for WebGL apps.
  • MM: one of our major beliefs is that no matter which language we pick, this group has to have ownership of it. Have to be able to change it, add / remove features, in an autonomous way. Concerned - had some chats with people inside the company - that non-programmers have to be able to understand the relationship.
    • Would be difficult for us to work with a standards body we’re not in. If that ends up being the path forward, have to have the terms written out in a way that’s robust. That being said, even if the terms are robust, the ownership is the most imp’t part.
    • DJ: would be really great if the WebGPU shading language - whatever it is - is a standalone spec you can read in one place.
    • FP: we want a spec that in one go, tells you what happens when things execute. As part of that one unified story: what checks take place, error modes, what things happen
  • KR: It sounds like you’re designing requirements to tank efforts to use SPIR-V
  • FP: WASM / JavaScript is not a monkey-patch on top of something else.
  • KR: ...
  • FP: Worried that we shouldn’t monkey patch several specs together
  • KR: Object to ignoring 10 years of experience and success with WebGL.
  • CW: Let me try to rephrase. WebGL is based on OpenGL ES because there is a huge complexity to graphics APIs. Coming up with a new one like we are doing with WebGPU is really hard, and was even harder when WebGL was first being designed. And that’s why a native spec was “updated” to run on the web. That’s what happened when it was too hard to make something new. On our side, we’re feeling the same way about shading languages for WebGPU. There is a ton of industry expertise that we just can’t throw out the window because it is super hard to design a shading language + ecosystem that maps to all hardware. So the way WebGL was based on a native spec out of necessity, that is our feeling about SPIR-V. Saying we have to write a standalone spec basically means we cannot rely on industry experience.
  • DJ: Let’s hear from the other vendors before we continue.
  • DM: At Mozilla we like open source and building on existing technology, rather than creating and building monolithic structure. Like to build on the existing experience and ecosystem.
  • RC: It’s great to see all the progress DN’s team has done with the compiler. I look forward to seeing where we end up when we add all of the compute stuff. So long as that stay smalls, SPIR-V is a good contender for the shading language. We do worry about adding features that aren’t in SPIR-V right now. We hope new language features moving forward do match with D3D12. We do want to be able to have an addendum of sorts if things don’t work out in the future.
  • YH: We don’t have a preference of which one, but I think it’s not good to invent a new thing, just use existing tech.

xAgenda for next meeting

PR Burndown continued

  • #378 - Do not require vertexInput in GPURenderPipelineDescriptor
  • #376 - Add a default for GPURenderPassColorAttachmentDescriptor.storeOp
  • #411 - Remove vertex input
  • #408 - Clarify render bundle state inheritance
  • #412 - Change vertex stride/offset to u32
  • #389 - Add defaults to GPUTextureViewDescriptor, remove createDefaultView
Clone this wiki locally