Skip to content

Minutes 2019 05 16

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

GPU Web 2019-05-16 Mountain View F2F Day 2

Chair: Corentin

Scribe: Ken

Location: Google HQ in Mountain View, California

NOTES FOR DAY 1

TL;DR:

  • Programming model burndown
    • Consensus that all barriers have to be control barriers
    • Consensus that we don’t do append / consume buffers like GLSL
    • Consensus that no array of resources are available in the MVP.
    • Resource aliasing isn’t possible in WebGPU, need to validation text that no two resources alias when at least one is writable.
    • BitfieldInsert clamping: clamp offset to 0, 31 and clamp size to 0, 31 - clamped offset.
    • Bit shifts get masked.
    • WebGPU should produce errors when it can analyze non-uniformity. Need to be at least as restrictive as compilers on various platforms.
  • Initialization of workgroup memory.
    • All uninitialized memory must be initialized to zero. Can be optimized by vendors.
  • ShaderModule reflection
    • This is dependent on shading language, WHLSL would probably expose a reflection tree, while for SPIR-V this would be produced by offline tools.
    • For now rely on standard layouts.
  • Read-only storage buffers: Want, needs a PR.
  • TexelBufferView:
    • Not really used in practice because sampler parameters are ignored.
    • Drop this.
  • Max texture size: Can assume 8K with 256 array size.
  • 24 bit depth format
    • No depth-stencil format is universal.
    • Discussion that we could have a DMIN24S8, DMIN4 and D32F
  • Timestamp queries: can’t be implemented in care and could be an extension.
  • Interop with WebGL / WebML: mostly ImageBitmap interop.
  • Swapchain and imageBitmap #285:
    • Much discussion that got to some consensus, see code below.

Tentative agenda

  • Programming model burndown (David)
    • Initialization of workgroup memory (from WebGL group)
  • ShaderModule reflection
  • Read-only storage buffers (Corentin)
  • Texel buffer views (Dzmitry)
  • Max Texture Size (Dzmitry)
    • also max number of layers
  • 24 bit depth format (Dzmitry)
  • Timestamp Queries (Austin)
  • Interop with Web platform
    • Interop with WebGL
    • Interop / interactions with WebML
    • SwapChain and ImageBitmap (Kai)
    • OffscreenCanvas IBRC (landed, hooray!)
  • ResizeObserver (Aleks Totic)
  • Agenda for next meeting

Attendance

  • Apple
    • Dean Jackson
    • Justin Fan
    • Myles C. Maxfield
    • Robin Morisset
  • Google
    • Austin Eng
    • Corentin Wallez
    • David Neto
    • Kai Ninomiya
    • Ken Russell
    • Shrek Shao
    • Ryan Harrisson
    • Idan Raiter
  • Intel
    • Brandon Jones
    • Yunchao He
  • Microsoft
    • Chas Boyd
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Joshua Groves
  • Timo de Kort

Programming model issues

Proposed list of issues to discuss. Suggest we time-box this

gpuweb issue WHLSL issue SPIR-V issue Status Category Description SPIRV-Tools transform issue Agenda order
232 part 2 Proposal Memory model Memory barrier, that is not a control barrier, and not image writes

Maybe want OpMemoryBarrier, with restrictions: MSL fence() method on texture maps to OpMemoryBarrier with Image storage class and AcquireRelease orders. (Similar to atomic_work_item_fence in OpenCL C.) MSL does not have general memoryBarrier(...)

GLSL has: memoryBarrier(...); not in MSL

GLSL has: memoryBarrierAtomicCounter(...); not in MSL; WHLSL doesn't have append/consume buffers

GLSL has: memoryBarrierBuffer(...); not in MSL; instead MSL uses control barrier with "device" memory fence flag

GLSL has: memoryBarrier on image: same as MSL texture.fence() method; CL C atomic_work_item_fence.

1
163 Support read-write images?

MSL 1.2 introduced read-write images

read-write images are in OpenGL ES 3.1 and Vulkan 1.0

2
232 part 3 Proposal Memory model Memory barrier, : image fence

Maybe want OpMemoryBarrier, with restrictions: MSL fence() method on texture maps to OpMemoryBarrier with Image storage class and AcquireRelease orders. (Similar to atomic_work_item_fence in OpenCL C.) MSL does not have general memoryBarrier(...)

GLSL has: memoryBarrier(...); not in MSL

GLSL has: memoryBarrierAtomicCounter(...); not in MSL; WHLSL doesn't have append/consume buffers

GLSL has: memoryBarrierBuffer(...); not in MSL; instead MSL uses control barrier with "device" memory fence flag

GLSL has: memoryBarrier on image: same as MSL texture.fence() method; CL C atomic_work_item_fence.

3
Proposal Resources Not support HLSL Append/Consume buffers. (Not in WHLSL currently)

4
Proposal Resources Need arrays of resources? buffers, samplers, images. Myles thinks no?

5
287 Resources Permit resource aliasing? Are two resources in the shader allowed to point to the same underlying storage? (Aliased buffer, or image)

Related to https://github.com/gpuweb/gpuweb/issues/63 which was about render targets.

6
288 27 Proposal Undef value BitFieldInsert: Out of bounds Offset or Offset+Size. Propose clamping Offset to [0,31], and Offset + Count to [0, 31]; alternate: insert or extract value 0 in out of bounds case

Other alternate: we could bitand Offset by 31, somewhat similarly to bit shifting.

We should also decide what happens if count is negative.

GLSL has bitfieldInsert

7
288 27 Proposal Undef value BitFieldExtract out of bounds case. Similar to BitFieldInsert?

GLSL has bitfieldExtract

7
289 Proposal Undef value Bit shift by bit width or more: Proposal: bitwise "and" the shift with bit width minus 1 (in practice, 31); alternate: clamp to [0,31]

8
264 Uniformity Should WebGPU require an error when it can analyze erroneous non-uniformity? (compiler obliged to throw an error in probably non-uniform cases, where a primitive is misused such as barrier or derivative.)

9
Uniformity If a barrier is in non-uniform control flow, is an implementation required to hang?

10
  • #232 - memory barrier which isn’t a control barrier
    • MSL doesn’t have this primitive
    • Robin said, could be emulated if you have uniform control flow
    • HLSL, OpenCL
    • Lean against doing this. Don’t want to tell people they need this barrier in uniform control flow. User could always use the control barrier.
    • RM: Agree we should not put it in MVP.
    • DN: I’ve seen control barrier a lot. Not memory barrier. Only works with atomics and synchronization. Hasn’t worked well.
    • KN: memory barrier without control barrier. Is that possible?
    • DN: memory transactions before it don’t go past it.
    • KN: so this memory barrier doesn’t have to be dynamically uniform?
    • DN: Correct
    • MM: SGTM
  • #163 support read-write images?
    • DN: will need a fence if so.
    • CW: need them.
    • DN: ok, they’re in.
    • MM: Metal has a command in the encoder for texture fence. Not sure about MSL.
    • DN: it has it. texture.fence().
    • CW: so you can see the stores you yourself made when you load.
    • DN: write path to image memory doesn’t necessarily have the snooping.
  • Do we support HLSL append/consume buffers?
    • No.
  • Arrays of resources?
    • CW: believe we don’t have arrays of resources. We have Texture2DArray, but that’s one resource.
    • MM: you can have a SW array of resources. Exists in all SLs. Index has to be a uniform variable, and that’s one of a few places where uniforms would have to exist in the language.
    • DN: there are some places where you need a constant expression. Further extensions having totally dynamic, non-uniform.
    • DM: do we want to get rid of the uniform semantics?
    • MM: to get rid of uniformity we have to get rid of all 3 of them.
    • DN: and derivatives of them.
    • CW: we’d need uniformity analysis to say e.g. dfdx can only be done in uniform control flow.
    • MM: we discussed this a couple weeks ago.
    • DN: no progress since then. Whether you’re requiring the impl to do the analysis, or you get undefined behavior...leaving to the programmer.
    • RM: and questions about how precise the uniformity analysis should be.
    • MM: I did some searching and the HLSL corpus almost never uses arrays of resources. Because they’re not common I think it’d be OK to skip them for now. When we have uniformity rules we can revisit.
    • DM: wondering where users might use them. Texture atlas, etc.
    • MM: texture atlas is actually not a case where you’d use them. For an atlas you could probably use Texture2DArray.
    • CW: we’ll have strong constraints on number of bindings. At max 32 textures for Metal w/o arg buffers. Could have texture arrays, but can’t be bigger than 32, and that uses all texture bindings.
    • DM: so we’ll have this limitation in the spec that no more than 32 textures per stage / bindgroup.
    • CW: we have to.
    • MM: you were envisioning 100 textures?
    • DM: was thinking that, yes.
    • CW: not a feature we can add to WebGPU at this time.
    • DN: that’s a feature that unlocks future game engines.
    • MM: lots of textures would mean lots of validation.
    • CW: we could instrument the shader. Also, WebGPUBindless should come after WebGPU1.
    • ..discussion..
    • CW: think we agree that arrays aren’t that useful and that we need to address the size restrictions.
    • ..some discussion about this..
    • ..discussion about fixed limits that you request to lift, difference between MVP and V1..
    • _Decision: No arrays of resources in MVP. Texture2DArray is allowed (it’s not an array in the shader language.) Reconsider resource count limit is increased much larger than 32. _
  • #287 Resource Aliasing?
    • DN: for example you can’t have a buffer and a texture view of a buffer pointing to the same resource in the same shader.
    • CW: what if those are read-only?
    • DN: good q. Hopefully no complexity with the memory model.
    • KN: is it useful?
    • DM: I think it is useful, asked on the issue, got no responses.
    • CW: at any draw / dispatch on the API side, either resource is read-only, or can be mutated through a single binding point.
    • DN: like a readers/writer lock.
    • MM: how is this enforced?
    • CW: browser validation rules. E.g., can use a resource only under these constraints.
    • CW: the API side should guarantee that.
    • DN: even with different views into the buffer with different offsets?
    • CW: intersection queries get into the same thing as mapping partial ranges. Need to consider buffer views. Usage validation rules don’t currently prevent you from using storage buffer twice. Should we prevent you from using it twice at the 2 bind points?
    • DM: I don’t see why.
    • DN: it makes analyzing the shader harder. Writing through one variable and reading from another, I don’t know what is aliased. For example, you might not be able to vectorize your code.
    • CW: we could say that since they access different binding points they are considered to have different caches.
    • DN: we could also say that if the code would have raced then it was undefined behaviour anyway, so the compiler vectorizing your code can’t make it any more broken. But that’s cheesy and non-intuitive.
    • RM: we’ve implemented that for llvm and it has tricky consequences, interacting with other optimizations and analysis.
    • CW: for shading language safety we’d like to have restrict on writable resources.
    • MM: “restrict” just means the compiler can assume they’re not aliased - we want to validate they’re REALLY not aliased.
    • DM: unique mutable borrowing.
    • CW: Rust semantics.
  • #288 BitFieldInsert
    • RM: where offset is outside [0, 31], would like to AND the offset with 31.
    • CW: for reference: ANGLE emulates this and we do the clamping.
    • DN: clamping feels slower
    • RM: from WASM we know that bit-and is very cheap.
    • CW: we might be doing the bit-and. We wrap it and make sure you can’t go out of bounds.
    • DM: if we do this wrapping can we optimize it away if there are constant offsets in the shader?
    • MM: did we decide on and’ing with 31 or clamping?
    • DN: clamping.
    • RM: what do we do if offset is fine, constant is fine, but offset+constant is out of bounds? Don’t want to have to do the bit-and on this.
    • CW: for reference, the ANGLE emulated function.
    • DN: if it’s already an undefined case we should do the and’ing.
    • RM: since we bit-and the sum, since it’s not what you pass to the next layer, we will have to clamp. For bitshifts we can bit-and. For offsets do we do bit-and or clamp?
    • CW: max operation is usually implemented in hardware?
    • DN: I’ve seen GPUs that have clamp in a single instruction.
    • CW: max is so common that maybe we can just clamp - or clamp both offset and constant. max is very fast.
    • RM: what we would be saying, offset = min of what it is, count is whatever.
    • DM: you said anding the offset, not clamping it?
    • RM: yes. That’s what wasm does for bit shifts. Also done by some processors.
    • DM: if we clamp the bits we also have to clamp the value we extract.
    • RM: doesn’t seem to be doing clamping.
    • CW: option ANGLE chose is, for undefined behavior, return 0. Requires a branch.
    • DM: why is not a setx?
    • KN: it might not compile to a branch.
    • DM: a select sounds cheaper.
    • MM: if it’s undefined behavior a select doesn’t help you.
    • DM: I like the way of returning zeros if we’re doing something weird. Rather than trying to extract the most meaningful value for the user’s request.
    • MM: it’s not discoverable though.
    • RM: knowing what the GPU does would help.
    • DN: we could do an investigation.
    • CW: let’s choose an alternative for now.
    • ..discussion..
    • KR: suggest we bit-and the index.
    • ..more discussion about Offset + Size..
    • JG: this is why it’s an undefined value.
    • DN: say user requests 7 bits and we return 12 with our clamping.
    • RM: it will fail with program error elsewhere then.
    • JG: suggest clamp all the things.
    • RM: ok. Clamp offset to 0,31, and then clamp size to 0,31-clamped offset.
    • DM: do we want to mask the value we put into those bits? Changing number of bits we return.
      • CW: you pass the count to the instruction.
      • JG: your concern is e.g. you have 255 and pass only 3 bits.
      • MM: take the lowest bits from this and put them there.
      • JG: can model this by shift, and-by-mask, and or.
      • DM: ok sounds good.
    • RM: if offset or count are constant, can get rid of all the clamps.
    • MM: in wasm are these values usually constant?
    • RM: haven’t checked. Think so.
    • JG: usually but not always.
    • DN: in SPIRV we only need these instructions because they’re non-constant.
    • RM: from what you were saying, max/min are intrinsic instructions, and it’s all straight line code.
    • MM: think perf of clamp is similar to mask.
  • #288 BitFieldExtract
    • Use same clamping rules as for BitFieldInsert
  • #289 bit shift by bit width or more
    • mask.
    • DM: we clamp the bitfield extraction but mask the shift?
    • RM: it’s unfortunate. That’s why I wanted to use mask everywhere, but hard for bitfield insert / extract because we have 2 things and want to control their sum. Want masking for bitshift for perf and compat with wasm.
  • #264 should WebGPU require error when it can analyze erroneous non-uniformity?
    • DN: revisiting the fxc / dxc issues.
    • DN: treats one level of nonuniformity. Across quad, thread group, etc.
    • CW: Hard to analyze uniformity over a quad.
    • MM: quad is particularly hard. Helper invocations.
    • CW: already want to describe uniformity analysis in the language.
    • MM: how to prove you have uniform control flow.
    • CW: would be nice to have a static assert that you’re in uniform control flow.
    • DN: checked assertion.
    • CW: people scalarize things for subgroup operations, etc.
    • MM: I think that’s a good idea and you should file a bug about that.
    • RM: in this analysis we said, if this variable is ever non-uniform please compile error.
    • MM: do think it’s worth opening an issue for this so it’s not lost.
    • RC: are we going to do our best here?
    • RM: want implementations to agree on what is a valid program or not.
    • RC: so no implementation can do extra credit on things that are provably bad.
    • RM: want rules not just for portability but also to catch bugs in implementations. Different analyses would lead to different bugs. Would like a set of rules.
    • CW: you can succeed compilations with warnings.
    • KN: that extra credit analysis would only allow more valid programs, not fewer.
    • MM: right. The two states are, I can prove this is uniform control flow, and I can’t prove anything.
    • JG: and you can have one browser that’s more clever than another.
    • MM: that’s why you need standard rules.
    • RM: have to determine the level of precision we want.
    • CW: that’s when we talked about the uniformity typing of functions.
    • RC: what about cases where there are compilers that can detect you’re doing it wrong, and the rules in the spec aren’t enough?
    • KN: the rules should be stricter than reality.
    • ..discussion about how conservative these rules should be..
    • RM: that’s an argument for having a relatively imprecise spec.
    • MM: CW, you’re right that the rules we make should not allow anything that fxc would reject.
    • RC: the rules that dxc use aren’t as strict as fxc’s. I don’t want compilers to allow absolutely bad programs through.
    • JG: we are signing up for our spec to have no bugs.
    • CB: isn’t this the halting problem?
    • RM: being complete and sound is impossible. Can’t determine a program is valid or not. We can say, this program is valid, and for this one I don’t know. Can always improve, never perfect, always safe.
    • DN: if you have a condition on FP arithmetic, you probably have to reject or be really conservative.
    • RM: what about constants.
    • DN: OK. Start with dumb rules.
  • If a barrier is in non-uniform control flow, is implementation required to hang?
    • CW: will we need analysis for e.g. are we in uniform control flow for subgroup, or dispatch? E.g., something is actually a constant expression?
    • MM: it’s up to us to determine whether those concepts are exposed in the language.
  • Initialization of workgroup memory.
    • YH: the issue Intel investigated in Chromium: crbug/898030
    • CW: how do you initialize this? Was a perf concern in WebGL 2.0 Compute.
    • KN: ran into this with TF.js. As app, not hard to have threads collaborate on mem init. But, as compiler, it’s harder. Dumb thing is have first thread init the whole thing. Smarter, have each thread init some, but hard.
    • MM: how bad is the dumb thing?
    • KR: we had some measurements that I don’t remember but it was pretty bad.
    • MM: is it observable?
    • KN: no.
    • MM: then the spec should say it and the impls can innovate.
    • KR: Intel had flaws in their memory initialization in WebGL compute. Tried to do better but it was wrong. TF.js were getting indeterminate answers. Lesson: It’s hard.
    • JG: Is there an alternative? Spec that it must be initialized, then let implementations innovate.
    • MM: it’s probably harder to figure out if a program is initializing things correctly than do it ourselves.
    • CW: it was probably that ANGLE’s shader translator is complex, etc. No analysis to try to figure out if things are statically initialized.
    • KR: The rule is that all workgroup memory is zero-initialized. Had problems in Mac where local variables were uninitialized, and got unexpected variability.
    • RC: we saw this on Windows too. In the end we just initialized everything.
    • MM: this is stuff people rely on.
    • CW: we can agree - shared mem should be as-if initialized to 0, locals should be initialized to 0, it’s hard to do performantly and correctly, so we need lots of tests. It’s a hard problem, so let’s make sure we produce enough tests that we get it right.
    • YH: so if it’s not initialized shall we initialize the memory?
    • CW: yes.
    • KN: for local variables it’s easy to optimize out. Shmem is harder, but we have to do it.
    • CW: if driver says, pass this flag and we’ll initialize shmem for you, they’ll have a more optimal WebGPU impl.
    • DN: this applies to all stage input and output variables.
    • CW: yes.
    • CB: We [D3D12 HLSL compiler] will add a flag to initialize.
    • CW: Great, should be easier for you (with lower level access).

ShaderModule reflection

  • Discussion about returning JSON, should devs be making decisions based on this info, should we be returning this from all compilations
  • DM: Don’t want people to make pipeline layout decisions based on the reflection info.
  • MM: at Apple we’ve done this to figure out where to put structs
  • CW: you’re reflecting on the whole type system of the shader.
  • KN: why do we need that? We have standard layouts already.
  • DN: you might want 6 scalars in the function call in the GPU, have to repack for efficiency.
  • MM / CW: it’s on the pipeline state object.
  • MM: It’s a whole tree of objects that you walk.
  • CW: why is it on the pipeline state?
  • MM: your entry points can be templated. Compilation isn’t finished till it’s a PSO.
  • CW: I see. Metal has a lot of awesome magic.
  • MM: DM’s kind of reflection is probably more needed for MVP.
  • DM: My preferred model is to not use any reflection. But “my” reflection reflects only the binding model. Which indices of bind groups, bindings within them, based on shader variable usage. Or build pipeline layout and mention those indices.
  • RC: we have problems in WebGL where old Edge would return attribs in diff order. 0 would be first one. ANGLE then reversed them. Had 1 or 2 compatibility problems because we were opposite of ANGLE. As long as we spec the first one is given index 0, second one index 1, etc., and don’t use the strings, that seems fine. If we want to use indices we should spec how things are numbered.
  • DM: we require the shader to specify the layout. Don’t need to guess or order them.
  • MM: the WebGPU programmer compiles the shader, then ask which indices match up with attribute names, then get back a table saying what the mapping is and we guarantee the order?
  • ..discussion..
  • MM: programmer has to type in the index and the name, so they already know the mapping. Why does the API tell you something you already know?
  • CW: for very beginners, my hope is that WebGPU is used to teach computer graphics, and for people starting they don’t want to worry about bind group layouts, etc.
  • JG: this would be a great thing for a library.
  • CW: agree.
  • MM: we already parse the shader. It’s way cheaper for us to return it.
  • JG: in WebGL we have to toss all the shader info back across the process boundary. It’s uncommon to use this reflection stuff in apps.
  • MM: when we add new syntax to the language will all these libraries get updated?
  • CW: you the developer are in control of the library.
  • KN: there’s an assumption. MM assumes there’s a compiler in the browser. We’re assuming it’s in userspace. shaderc can take a GLSL 1.00 shader w/o layout locations, assign them all and tell you what they were. That’s what OpenGL and the API provides. Ingesting SPIR-V makes it entirely a userspace problem. Ingesting WHLSL does mean it’s more difficult to sync the userspace code and what the browser does.
  • CW: I guess we defer that discussion?
  • DN: one more thing. We’ve done compilers that did that sort of thing, and found we needed more info over time. E.g., constant samplers in OpenCL C, not in Vulkan. Need this to optimize initialization. There’s an accretion of features. Don’t know where it stops. It’s language dependent as well as programming model dependent. Another example: OpenCL C can have a constant table, not Vulkan. Have to dump it out and ingest it to feed it in as a constant buffer.
  • MM: for now we’ll just do standard layouts?
  • DN: that doesn’t solve the problem. Can pass in each arg as a separate storage buffer. Solves the problem, but is terrible. Pack them together, but that changes the API calls.
  • CW: for now, we say, std layout, we know how they’re packed in mem.
  • DN: it doesn’t tell you how we packed them together and how you pass them in during dispatch.
  • ..more discussion about how compiler might pack data and pass arguments to kernel..
  • CW: Dispatch arguments are only workgroup threads; all other data must be bound in uniform buffers, storage buffers, etc.
  • MM: regardless of language we pick, the OpenCL C compiler is the one which has the feature creep.
  • KN: we want that feature creep to be in userspace.
  • CW: I think we all agree. Shelve this until discussing shading languages again. For now we rely on a std layout TBD.
  • DN: OK. That’s a separate discussion.
  • KN: how can we not rely on std layout?
  • MM: we’ll discuss the exact layouts later. For now, we say that if you have e.g. an SSBO, with structs and deeply nested members, we’ll have layout rules and document them.

Read-only storage buffers (Corentin)

  • CW: Our usage validation rules say, within a pass, one readwrite or multiple readonly.
  • CW: You might want to use a storage buffer as readonly somewhere in a pass.
  • CW: Proposal: add readonly storage buffer and storage texture bindings.
  • DM: why do we need storage texture readonly instead of just sampled texture?
  • CW: Ok, for texture maybe not needed. But needed for buffer.
  • DM: Partially overshadowed by TexelBufferView. More universal to say readonly
  • CW: can you tag?
  • DN: you can tag something as non-writeable.
  • CW: and it propagates and is validated within the shader?
  • DN: we could make that rule.
  • MM: HLSL has StructuredBuffer and RWStructuredBuffer.
  • CW: would map to ByteAddressedBuffer.
  • DM: he’s talking about storage and read-only storage. We’re not talking about addressing, but access.
  • MM: in new model, how would it be exposed?
  • AE: there’s ByteAddressed and RWByteAddressed buffer.
  • ..or StructuredBuffer..
  • CW: these correspond to the same kind of binding. ByteAddressed and Structured buffers are storage buffers in OpenGL terminology. Each has read-only and read-write ones. Sound good?
  • MM: yes.
  • CW: I’ll make a PR.
  • RC: sounds good as long as you can do it in D3D12, which I think you can.

#297: TexelBufferView

  • DM: When you have a buffer, and want shader to see it as 1D texture. They’ve been in OpenGL for a long time, since before storage buffers. Let you access larger storage than uniform buffers. If we require support for storage buffers, mostly makes these irrelevant. Only Q: can you have texture unit in the HW to do bilinear sampling from texel buffer view?
  • CW: that would allow you to make 2 mem loads and a mix operation in one sample?
  • DM: yes. One sample to get interpolation. Seems minor. Not sure why we would want to sample non-swizzled 1D textures with interpolation. Lot of unknowns.
  • KN: on the GL wiki, can’t set texture parameters, the sampler object is ignored.
  • CB: sampler parameters are ignored. swizzle is free compared to I/O. So people don’t really sample buffers.
  • CW: we can drop this. Only thing, if we can have a 2D buffer texel view, you could create a 2D texture in linear memory, that’s not possible. Can postpone and probably never do this.
  • DM: ok. Let’s have read-only storage buffers instead.

Max Texture Size

  • DM: proposing max texture size of 8K and max number of texture arrays of 256.
  • DM: remember us discussing this on a poll. iOS 8 doesn’t have 8K textures, only 4K.
  • KN: thought that was old hardware.
  • DJ / DM: iOS family 1.1, 2.1, etc.
  • MM: haven’t shipped new WebKit to old iOS.
  • JG: could you write down what hardware is still around and interesting?
  • MM: we don’t have a policy about which devices are required and which not.
  • CW: do you want to support WebGPU on tvOS?
  • DJ: yes.
  • KN: similar to iOS restrictions.
  • CW: ok, can not worry about 4K devices, just 8K.
  • DM: what about max 256 array layers?
  • KN: what about Vulkan? Are there Vk mobile chips with 4K max?
  • ..discussion..
  • CW: Vulkan max image dimension 2D = 4K. There are only 2 reports of this size, rest support 8K. Want SwiftShader support. Currently says 4K, but can increase it.
  • CW: ok, 8K, max 256 layers. Can you put together a pull request?
  • DM: yes.
  • CW: section on device limits.
  • RC: suggest making a section in the spec called this.

24-bit depth format

  • DM: can we say that some formats can not do all the things?
  • CW: have to say this. sRGB probably doesn’t support storage.
  • DM: OK, we’ll have a table with various support. We can say that 24-bit depth formats only support being sampled and rendered to. Have to spec that precision is within this range if you use them.
  • CW: any concern that 32-bit float is not strictly more precise than depth24?
  • DM: depending on range from 0..1 you use you can have more/less bits of precision. If you use that format we can say your precision is in this range. D24S8 is very useful, and there are only a few platforms where it isn’t natively available.
  • RC: The alternative is to make that an extension.
  • DM: Yes.
  • CW: we’ll have ulp precision defined in the spec. If we say, has 1 ulp imprecision, probably OK. Doesn’t division have precision guarantees in the SPIRV spec?
  • JG: this is a choice we can make.
  • DM: we can say, your 24 bit depth buffer may have 23 bits of precision.
  • CW: sounds fine. If it’s better to use D24S8 than D32S8 because it’s less memory. DM’s proposal is that we add D24 and D24S8 formats. Still packed. On platforms that don’t have D24 style formats we emulate them with D32 style formats. Sometimes may have 1 bit less precision.
  • RC: so if you use D24, we may have to emulate that stencil isn’t there?
  • CW: D3D has D24X8.
  • RC: think that’s only render target.
  • DM: we have the surface of the API to ensure that user doesn’t rely on stencil if they don’t request it.
  • RC: if they request D24 we’ll have to inject API calls to ensure stencil is never written to.
  • CW: DM’s saying these would only be sampleable. Can make sure stencil is never written, stays at 0.
  • RC: I have misgivings about emulating D24 with D32.
  • CW: we’ll have the same issue in Vulkan.
  • DM: if you want something as DEPTH_STENCIL_ATTACHMENT, it must be either D32F or D24. Impl may need to choose D32 in Vulkan.
  • RC: I think we should tell the developer what’s going on. We had a 16-bit depth buffer and some demo didn’t work.
  • JG: D32F can represent all integers D24 can.
  • ..discussion of mantissa bits..
  • CW: also Vulkan doesn’t guarantee D32 rendering support. Guarantees one of D24 and D32.
  • JG: I’d like someone to convince me that 32 bit depth is less precise than 24 bit normalized, because I don’t think that’s true.
  • MM: won’t the shape of the API change because Vulkan doesn’t have any guarantees?
  • JG: only if you don’t allow us to polyfill one with the other.
  • DM: you’re saying we can’t require 32-bit float.
  • KN: if we say, extra precision is allowed by the implementation, then we can say what the precision is. Somewhere between D24 and D32F.
  • JG: I’d prefer to expose both formats as optional. Less preferred would be to choose the less precise of them, and say that sometimes you get the more precise one.
  • MM: in order for both to be optional, all web apps would have to fall back.
  • JG: you have to either trust them, or they have to trust us to do it. If they trust us, then they have a different corner case - precision isn’t what they expect.
  • MM: our logic earlier was, giving them more precision is always OK, with the restriction they can’t do a memcpy. Think option 2 is better. (WebGPU exposes only D24, but sometimes might be D32F, and can’t copy between depth formats.)
  • KN: can always have the magic depth format.
  • JG: that’s what I was thinking of. You want depth? Here it is. You have to pick one of these tradeoffs. Ideally, as a web platform, that’d be something I’d put in a library. If you can’t trust a user to choose the working depth format, will you trust them to get the work group size correct?
  • KN: but that won’t break the app completely.
  • MM: we just want to make it easier for developers to not write apps that don’t run on iPhones.
  • CB: is there a way to expose both, and recommend to developers to test on the other one too? Make sure they test on all shipping platforms.
  • JG: could be a validation time thing.
  • CB: if they can implement a code path that only supports one of these, that’s a bug.
  • JG: you can’t save developers from themselves in this case. Can do renderable format checks.
  • MM: historically, expecting app authors to handle cases that don’t happen in development doesn’t work.
  • JG: I agree, but this is a reality of graphics systems. Question isn’t, can we eliminate this, but how can we eliminate all of it?
  • CW: what if we expose DEPTH_MIN_24_STENCIL_8?
  • RC: trade other incompatibilities.
  • JG: then you can’t copy out of red format textures.
  • KR: what about expose DEPTH24_STENCIL8 and don’t support WebGPU on devices that don’t support it?
  • MM: veto. iPhones don’t support it.
  • KR: really? It’s supported in OpenGL ES.
  • MM: we’ve filed a Radar.
  • DM: I think we should require D32F. It’s extremely common for gamedevs to use it for inverse depth.
  • JG: it’s a larger bits per pixel. Twice as large.
  • https://vulkan.gpuinfo.org/listformats.php (search D24 or D32)
  • DM/CW: resolution: DEPTH_MIN_24, DEPTH_MIN_24_STENCIL_8, DEPTH_32F
    • DEPTH32F_STENCIL8 isn’t widely supported on Vulkan devices.
    • Can’t copy to/from these MIN_ formats because we don’t know exactly what they are.
  • CW: Need to check D32 is output-format-attachable on the devices we care about.
  • DM: if you can’t use as output attachment why would you need it?
  • KN:
D24+ D24+ S8 D32F
Vulkan D24-only D24 X8 D24F S8 D32F
Vulkan D32-only D32F D32F S8 D32F
Metal iOS D32F D32F S8 D32F

#72: Timestamp queries

Interop with WebGL

  • JG: What do you want? WebGL isn’t interoperable with WebGL. If you interop WebGPU with WebGL you make it possible to interop WebGL as WebGL.
  • KN: depends on the level of interop. Use WebGL canvas as source of texture copy.
  • KR: By virtue of having ImageBitmap to WebGPU texture copies, then you can copy from a WebGL Canvas and copy it into WebGPU.
  • KR: Could think about 0-copy but should just have great ImageBitmap support, even if one copy.
  • KR: Sharing only the backbuffer, sharing textures would be really hard.

Interop / interactions with WebML

  • RC: only places we’d have interop would be on import. Importing images, etc. into WebGPU. The things that demo well wtih WebML are pose detection, etc.
  • MM: so no new WebGPU APIs?
  • RC: not for this.
  • MM: all on WebML side? To ingest foreign concept?
  • RC: think that’s fine.
  • CW: so basically, ImageBitmap import.

ResizeObserver (Aleks Totic)

  • Related bugs and test cases:
  • AT: Problem: to scale high-DPI canvases get to the display so that pixels match 1:1 to device pixels.
    • Subtle: the size of the canvas the developer should create depends on both the CSS size and the location.
    • At last TPAC, tried to sell this to CSS WG.
  • AT: think we ran into issues:
    • How to define this rectangle?
    • One sticking point: what happens if there are transforms?
    • Is it cross-browser compatible? Want to make sure backing store size matches device pixels.
  • AT: next step: go back to CSS WG and try to convince them that the rectangle I’ve defined can be implemented in all browsers consistently.
    • Side issues, like what do we do about the transforms.
    • Feedback I’d like:
      • Does this device physical size make sense on all platforms?
      • What do you think we should do about transforms and page zoom?
    • DJ: think we should ignore transforms. Too bad. You just get a rectangle that doesn’t take transforms into account.
    • DJ: for pinch-zoom, don’t know. Definitely don’t want resize events firing while you’re pinching. Maybe at end, get an event?
    • AT: what physically happens in WebGL?
    • DJ: it would be up to the developer to do what they want. It isn’t a WebGL thing - could apply to any canvas. Think it’s OK for now to ignore pinch-zoom because they don’t have it now and we aren’t taking anything away. In a non-transformed environment, without any device zoom, that’s the box I’ll give you.
  • AT: what are the use cases?
    • DJ: doing UI matching what the rest of the page does. Render something in WebGL & have crisp output. No scaling between your texture and the screen.
    • AT: do you see this as having a lot of little canvases on the page? Create a fancy button?
    • DJ: possibly. Full canvas on the page is probably less important. Still, if canvas is covering everything you want things you draw into it to be crisp.
    • AT: I’ve heard that if you use 3D transforms all bets are off. For 2D transforms, people will use them to position on the page. Might want to handle that.
    • DJ: can’t do rotation and skew.
    • AT: right. They said rectilinear transforms. offsetX, offsetY.
    • DJ: don’t know how you provide an API which behaves one way with a certain kind of transform applied. Also concerns about iframes. It’s just too bad. If whatever owns it moves you, you lose.
    • KR: other use cases: drawing programs, CAD/CAM where you want to draw crisp lines.
    • DJ: that’s not possible on some devices. iPhone XS Max for example, you draw with 3x device pixel ratio but it’s changed during scanout.
    • MM: also the default on some of the Mac laptops is not 1:1 with the display. Used to be, but no longer. Also if we take into account pinch-zoom, when you zoom in, if the app will use the number of device pixels to create a new canvas, it could be much bigger than they need, and we can’t tile canvases.
    • AT: my suggestion was to not report pinch zoom.
    • AT: page zoom - we would report that. That causes re-layout.
    • MM: finger zoom is less palatable. Page can get way bigger than expected.
    • DJ: naive developer would likely do something wrong.
    • MM: any technology that’s easier to misuse than use correctly is not what we want to expose.
    • AT: don’t think there are APIs in DOM that expose pinch zoom.
    • DJ: the visual viewport API does.
    • AT got feedback from Apple.
    • JG: was trying to make a demo.
    • AT: we have one. Make a grid, moire pattern will show up.
    • JG: was playing with it. Need to poke more, and figure out what we do on phones. Think it’s working properly with page zoom. Ideally would want an annotation “don’t snap to grid” plus non-integer multiples.
    • AT: you have to snap at some point because of CSS rules.
    • JG: I know.
    • AT: have people positioning with grid, flexbox, etc. Can’t guarantee that X and Y are at integer sized locations.
    • JG: if you have a dummy div and then ask for the CSS bounding rect for that, and then size something inside of it, for example.
    • AT: even there, you’re looking at the snapping offseted from the top left of the page.
    • JG: wondering, can you set CSS position to a real value and not an int? Pre-snap your canvas? Don’t know enough about CSS layout. Under a certain model think it could be viable. Pre-snap your coordinates, then have 1:1 device pixels.
    • AT: still when you’re moving stuff around, your location will change and the ResizeObserver will tell you. When would you pre-snap?
    • JG: same time as ResizeObserver. You won’t get smooth animation offsets at good enough accuracy without jitter.
    • AT: we actually tested this. Moved the canvas ¼ of a pixel each time. ResizeObserver fired just before rendering the WebGL canvas.
    • JG: that does tie into compositor design. We generally implement async pan/zoom on top of what the compositor renders.
    • AT: we were talking about animating from JS.
    • JG: no objections, just questions. Not quite the right person to answer CSS layout questions. But this API crosses questions between layout and canvas.
    • AT: by not doing transforms we save ourselves a lot of hurt.
    • JG: I agree that we shouldn’t deal with transforms.
    • DJ: for us, the sizing is a paint-time operation. We don’t know the subpixel layout until we paint, and ResizeObserver happens during paint.
    • AT: but the WebGL canvas, how do you determine the physical destination for your WebGL canvas?
    • DJ: main question is: what are you proposing to add that isn’t there now? css-content-box-size I think is good enough.
    • AT: I’m adding the size of the box in device pixels.
    • DJ: we don’t know the size of that box in Safari until we repaint it.
    • AT: that kills the whole idea unless we can work around it.
    • DJ: we might have a 100x100 canvas in CSS pixels, no transforms, no zoom, etc. Say we’re on high-DPI. Might be 200 pixels, might be 199 pixels, depending on location of the element. Changes during scrolling. Actual size might change all the time.
    • KR: we saw that in Aleks’s demo.
    • AT: the only thing that affects the size in Chrome is the location. During scrolling, it doesn’t change.
    • DJ: what if you’re deeply nested and scroll a parent?
    • AT: might change location, therefore size.
    • DJ: getting fairly complicated and dangerous. I think it’s a mistake to fire events for changing 1 device pixel, then back, then back again.
    • AT: in Chrome the only time we would fire this is upon re-layout. In order for location to change you’d need layout. Since layout is already expensive I set a flag during layout saying your location’s changed, so recompute device pixel size. I’m able to recompute the device pixel size after layout but before compositing.
    • MM: how do you do it without the graphics context?
    • KR: I’m not 100% sure. Think browser sends down quads, maybe in device pixels, and system compositor handles it.
    • MM: in our browser we could compute something that we give Core Animation or the window server. Can’t know more than that without doing paint.
    • AT: paint is where the physical snapping happens?
    • MM: yes.
    • ..discussion about portability of this API given e.g. Safari’s rendering pipeline..
    • AT: after paint, you’ll know the new size?
    • MM: we wouldn’t implement this by waiting for the next paint. When browsers paint is flexible.
    • AT: ResizeObserver fires before paint.
    • MM: we’d have to run a fake paint to figure out what to fire?
    • AT: no, just that RO runs after layout & style, but before paint. We run it by saying, do you have anything to do, at the right point in time?
    • DJ: what we can do here: we now know it’s an important requirement for a canvas. The rest we can deal with in the CSS group.
    • AT: both Mozilla and Safari just implemented ResizeObserver version 0, so we could prototype this in all browsers.

SwapChain and ImageBitmap (Kai)

  • #285
  • KN: we started talking about this on Tuesday at the WebGL F2F with OffscreenCanvas stuff. It’s similar. You can tear off the back buffer into an ImageBitmap. Designed this so that even if you’re backed by a real system swapchain, this mechanism can still be used to track those SwapChain images. Only trick: you have to be able to read out of them, in case you use it for something else than presentation. Only limitation is that SwapChain textures have to be readable by the browser.
  • KN: you present through ImageBitmapRenderingContexts. Your SwapChain gives you textures, you can transfer those to ImageBitmap, and display those. This removes the complexity of adding a new rendering context type, but adds complexity to the ImageBitmap implementation.
  • RC: do WebGL etc have this problem? Backed by a real SwapChain?
  • KN: other things, maybe not SwapChain, but on macOS for example the back buffer is an IOSurface.
  • KN: fullscreen isn’t the only case of a HW swapchain. HW overlays we do use all the time.
  • RC: those are real swapchains?
  • CW: you get a texture to render to from the system.
  • RC: on Windows, they do want to make those backed by real swapchains on Windows. So, OK, other 2D/WebGL canvases will have this problem?
  • KN: they don’t have that problem in that case. Before I changed this we also didn’t. Because they have implicit swap, browser’s in control of swap chain image lifetime. This proposal gives the app some control in the form of the ImageBitmap. Before this, with the “gpu” canvas context, it was also implicit, but roughly the same as WebGL / Canvas2D. This proposal should be the same, but requires some tricks at the API level.
  • MM: did you implement this?
  • KN: not yet.
  • MM: do you think it’s implementable on top of CAMetalLayer?
  • CW: yes. This one has an explicit present step though. CAMetalLayerOverlay has an implicit present.
  • MM: I don’t think that’s true.
  • KN: what if you don’t call Present()?
  • CW: what if it’s backed by an OpenGL default framebuffer, and you don’t call Present()? Then we need to copy the ImageBitmap into a texture, and clear the back buffer.
  • KN: if we were exclusive full-screen, we’d just not swap. Leave previous contents there. A frame can be longer than 1 vsync.
  • KR: Kai did try doing this with WebGL and found a browser bug in Chrome, filed it. http://crbug.com/961777
  • RC: is the reason we want this explicit swap? Or to be compatible with other canvas contexts?
  • KN: my motivations: explicit swap, and getting rid of another canvas context I didn’t think was needed (webgpu rendering context).
  • KR: this lets you avoid adding another concept, of the webgpu canvas type.
  • KN: at last f2f we settled on implicit swap and semantics, but partially because we couldn’t find an explicit swap pattern we were happy with, thought this one would work.
  • RC: so if using real SwapChain and you do this do you take the SwapChain with you?
  • KN: in that case, with fullscreen canvas, will create native swapchain. getNextTexture takes first texture from that. Transfer to ImageBitmap. It’s still holding onto swapchain texture. Then when you pass that to ImageBitmapRenderingContext, it hands it back to the system swapchain.
  • RC: so you do take the next texture and the SwapChain with you?
  • KN: the canvas is attached with the IBRC and the native SwapChain. The rules are written in a complex way due to ownership, but when you take texture from the native SwapChain, you have to give it back before you can get a new one.
  • KN: if you hold onto one texture, you can’t get another one until you present this one.
  • CW: there’s already the concept of a detached texture because you have the ability to close them.
  • RC: once it’s detached could you make a new SwapChain?
  • KN: if you make a new one it invalidates the old SwapChain.
  • ..discussion about the flow..
  • ..whiteboard discussion..
  • KN: the catching point is whether we can read back from the SwapChain’s texture.
  • JG: every time Firefox has tried to coalesce its surface implementations into one then we’ve had problems.
  • KN: it doesn’t have to be the best. You have to present the ImageBitmap; otherwise you can never get the next texture.
  • JG: what does this buy?
  • CW: it gives us explicit present, and lets us use things we’ve already spec’ed.
  • JG: in my opinion the best reason to do this is to reuse ImageBitmap.
  • RC: can I make another random canvas and then have it point to the ImageBitmap that came from the SwapChain?
  • CW: no, because we created the SwapChain with it knowing which IBRC it was supposed to send frames to.
  • DJ: you can do other things with those ImageBitmaps that came from the SwapChain.
  • JG: you could make 2 IBRCs and put the same frame into both. Then one would be a copy and the other wouldn’t.
  • JG: feels a little superfluous.
  • CW: now, we have a GpuCanvasContext created from the device. You’re suggesting, no GpuCanvasContext, and you can do GpuDevice.configureSwapchain(ibrc) and it’s the same as now?
  • ...discussion…
  • JG: this sounds a lot like we’re adding IBRC and ImageBitmaps to work around the fact that the TAG told us not to add explicit blocking swap.
// See below too for later iteration on this code
ibrc = canvas.getContext("ImageBitmap", { colorSpace: … });
swapchain = device.createSwapChain({
  ibrc, …});
tex = swapchain.getCurrentTexture();
swapchain.present();


---
  • DJ: why pass in the IBRC? Could just be on createSwapChain and you pass in the canvas.
  • …
  • DJ: one thing is that tex is neutered after swapchain.present(). What if you do toDataURL on the canvas?
  • KN: before the present it gives you the previous frame (via copy).
  • DJ: I don’t know how we’ll do that yet.
  • CW: should be easy for Safari because you should have the previous surface. Not sure how the Metal layer works.
  • DJ: my worry is there’s a lot of logic in CAMetalLayer which I don’t know what it does.
  • CW: for battery efficiency aren’t you supposed to use IOSurfaces?
  • DJ: we recommend using CAMetalLayer in almost all situations.
  • CW: we use setContentsTo.
  • DJ: that’s a private API. Or there’s a call afterwards that’s definitely private.
  • DJ: in OffscreenCanvas, do you have a swapchain?
  • CW: would be great if you could make ImageBitmapRenderingContexts against OffscreenCanvas.
  • KR: you can. Landed the other day after Dean expressed interest:
  • DJ: wish it could be as easy as WebGL.
  • KR: WebGL has the problem that it can render to 1 canvas, and lots of people want to render to multiple canvases.
  • JG: suggest you just don’t call present. If you don’t, we detach the texture anyway.
  • CW: what if you call getCurrentTexture twice in one rAF? Does it return the texture, or does it say no because you already got one?
  • DJ: I’d love it to be really simple.
  • CW: you don’t want to do that. The default framebuffer in OpenGL is a real source of pain.
  • DJ: I guess if you have to do that then explicit present() isn’t that painful.
  • KN: OK, so now having gotten rid of ImageBitmap, then the API on the board is the same as we had last time. I’d like to change it back to explicit present.
  • JG: could we do both? What if SwapChain.getNextTexture() took a boolean argument “explicitSwap”? Usually omitted, so you’ll implicitly swap?
  • DJ: you save 1 line of code.
  • MM: you want to be able to commit without getting the next texture, which might be in use.
  • JG: we were thinking about adding early present() to WebGL.
  • CW: could be a SwapChain argument rather than per-texture basis. This is one topic. The RenderingContext topic is another. Explicit present sounds fine to me, not sure about the TAG.
  • KN: I don’t think it’d be hard to sell the TAG on explicit present.
  • DJ: it was the blocking they cared about.
  • KN: it’s similar to image.src= …
  • CW: ok, we add SwapChainDescriptor thing that says implicit / explicit. And an explicit present() method.
  • MM: what’s the benefit to requiring explicit present()?
  • JG: you can work on a frame across multiple ticks / vsyncs.
  • RC: also fencing stuff. Can do fences earlier.
  • MM: you couldn’t call present / getNextTexture in a loop in one rAF?
  • CW: no.
  • MM: then it is observable.
  • KN: Maybe could allow it.
  • CW: there are 2 changes. One, I’d like to do: GpuCanvasContext replaced with ImageBitmapRenderingContext.
rc = canvas.getContext("IB");
swapchain = device.createSwapchain({
	context: rc,
     [requiresPresent: true,]
	...
});
function raf() {
  tex = swapchain.getCurrentTexture();
  // Render...
  swapchain.present();  // or not, if requiresPresent is its default false
  swapchain.getCurrentTexture(); // null, until the next rAF.

}

  • AE: when can you call getCurrentTexture again?
  • CW: rAF.
  • JG: after rAF. Can have microtasks after rAF but before you get the next frame.
  • CW: setTimeout(0) wouldn’t work.
  • KR: can be problems. If GPU is backlogged then we may not have a real SwapChain texture available. WebGL has this issue sometimes.
  • JG: we could polyfill this and make a non-SwapChain-related texture.
  • RC: in the old Edge we’d put event queries in the stream, and before next rAF, if the events weren’t satisfied, we’d skip rAF.
  • RC: when you say transferFromImageBitmap, the content will be the last IB that was transferred in.
  • CW: you have an ImageBitmapRenderingContext. If you call present(), or transferFromImageBitmap(), the last one wins.
  • RC: so when you call present() it’s the same as transferFromImageBitmap.
  • CW: yes.
  • KN: this is the same as what we have now except we use IBRC (could go either way on this), and goes back to explicit present, which we had before, but removed.
  • CW: I think Kai volunteered to put together this pull request. :)

Snapshot

  • CW: we could make a branch called 0.1 (or similar) in the repo so that we can continue evolving, but have a snapshot.
  • JG: so idea is to have impls all target the same snapshot? What if impls are between snapshots?
  • CW: I assume in your CI you can choose which commit of the CTS you use.
  • KN: you won’t get from 0.1 to 0.2 instantaneously.
  • ...discussion…
  • JG: why have a snapshot?
  • CW: so for a month, we can have 3 impls that work together.
  • ...discussion about WebGL…
  • CW: what I would like is, ToT CTS most of the time work on all browsers, and not fail because we renamed something.
  • JG: it doesn’t allow us to move forward. Don’t want to ship both the snapshot and ToT.
  • CW: 2 types of changes. Additions to the API, and renames.
  • JG: ToT might be doing 1 rename, and I want to do a different one.
  • JG: might be too early to have a snapshot.
  • MM: too early today, because we made a lot of decisions.
  • CW: in a month or two?
  • JG: you can have a snapshot, and once you change something, you have a divergence. Active development going on.
  • ...discussion…
  • JG: I don’t think we can both evolve the impls forward and maintain compatibility with snapshots.
  • MM: we’re only going to worry about compatibility when we take it out from behind a flag.
  • CW: the number of tests we’ll have to write are massive. There will be a huge amount of churn and they won’t work in all browsers because some didn’t implement a certain change.
  • JG: by the time we write the tests we should have done most of the refactors.
  • MM: will the CTS be based off ToT?
  • KR: suggest both snapshots and ToT.
  • DJ: why would I target the snapshot then?
  • CW: was thinking that people would target the snapshot and then upgrade the CTS with the bulk changes to the spec?
  • Agreement that we should take an MVP snapshot.
  • DJ: we’re not that far from an API standpoint.
  • CW: but we are, from a spec standpoint.
  • CW: I think we’re close to having an MVP. Considering that MVP can be backward-incompatible. It’s the same thing as a snapshot.
  • MM: we’re still not going to stop development once we reach MVP.
  • JG: it’s all just a problem with backward incompatibility.
  • CW: we can buffer most of the incompatible changes. Most of the changes we’re making aren’t incompatible.
  • DJ: you’re saying that once we have MVP, we can resist changes to the API for a while to get folks to that implementation level. Only if something’s broken and has to be changed would we make it.
  • CW: OK. Let’s have this conversation again at some later time, but let’s prioritize changes that are backward-incompatible. Right now the features are looking good. Please figure out incompatible changes and put them in, and maybe in a couple weeks we’ll feel comfortable calling it MVP. I think we’re close.
  • JG: except for the shading language ingestion.
  • DJ: seems like the only solution is that you can choose to ingest one or the other or both.
  • MM: I think that’s the only thing we can do at this point.
  • RC: like accept: headers for images.
  • DJ: or HTML5 media template type.

Agenda for next meeting

  • Your backwards incompatible-changes here
  • PR burndown
  • Skipping next Monday’s call. One after that is Monday May 27.
Clone this wiki locally