Skip to content

Minutes 2019 09 09

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

GPU Web 2019-09-09

Chair: Corentin

Scribe: Ken

Location: Google Meet

TL;DR

  • PR burndown, bunch of PRs merged.
  • Coordinate systems: consensus to use D3D / Metal’s convention.

Tentative agenda

  • Brainstorm for the F2F
  • PR burndown
  • Coordinate systems #416
  • Out of bounds clamping #311
  • Agenda for next meeting

Attendance

  • Apple
    • Dean Jackson
    • Justin Fan
  • Google
    • Austin Eng
    • Kai Ninomiya
    • Ken Russell
    • Shrek Shao
    • Ryan Harrisson
    • Sarah Mashayekhi
  • Intel
    • Yunchao He
  • Microsoft
    • Chas Boyd
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Mehmet Oguz Derin

Administrative item

  • Please register for the F2F.
  • Thanks to Ken for arranging the A/V and room with the event planners.

Brainstorm for the F2F

  • Shading languages, yay! 🎉
  • Status update
    • Tests - it’s possible to contribute tests to the CTS now!
  • SetSubData
  • Push constants
  • Multi-queue
  • PRs - have a fair number outstanding to discuss. We should try to clean them up as they come.
  • Swap chain orientation - if necessary
  • Remove vertex input?
    • KN: suggest we don’t want to remove it
    • DM: I suggest we remove the feature until we know how to solve it
    • CW: let’s put it back on the agenda. Removing it seems a bit optimistic / aggressive
  • Test-a-thon
    • Couple of errors where we all get acquainted with the processes and contribute spec and tests
  • In the Drive folder there are already minutes for the F2F; can just drop items into it. We will add more.
  • DM: I added: figure out what operations can be done on swap-chain-acquired images, and whether we should expose that image, or just a view.
  • CW: I talked with our Canvas engineer and he said we’re doing swap chains wrong
    • KN: I have a to-do item for redoing how the swap chain is exposed.
  • CW: now that we’ll have a precise spec, we won’t have to backtrack on items like vertex input or swap chain as much in the future.
  • Multithreading

PR burndown

  • CW: fair number in flight, in particular spec PRs. We should get familiar with them so we don’t have to discuss them all in person in this meeting.
  • #422 was already landed!
  • #424 Fully specify the defaults of GPUTextureViewDescriptor
    • Agreement between Kai and Dzmitry and seems everyone has reviewed
    • Merged
  • #427 Describe validation and creation of GPUBindGroupLayouts
    • DM: can we have little more time to review it?
    • KN: think we can review this online, doesn’t have to be on a call
  • #429 Make device.popErrorScope() throw an exception if there are no scopes
    • AE: Kai had a comment on the placement of comments, which I fixed
    • KN: think we’re good on this. Any concerns with returning Promise that can reject, and throw exception? Makes more sense here.
    • JG: maybe. Add easier-to-track client side state? I don’t particularly mind.
    • CW: agree. It’s annoying. Just a counter.
    • JG: it’s state that can become divergent. It shouldn’t. It’s fine.
    • KN: I agree but I think it would be more annoying to the developer if the promise rejected rather than if you get told about it immediately.
    • CW: ship it.
  • #418 (defer)
  • #412
    • CW: reason for this: vertex buffer stride can’t be big because of limitations in Metal and Vulkan. Offset must be less than stride.
    • CW: vertex attribute offset inside the stride.
    • DM: it’s not that the new types capture the limitations anyway. I don’t see the point. Would rather use the buffer offset everywhere in the API as a single type. It’s not the hot code that uses it; it’s the pipeline creation.
    • KN: I don’t really care.
    • JG: it’ll just end up as a number.
    • KN: it doesn’t even show up in the JS API unless you import explicitly.
    • JF: I only slightly prefer.
    • CW: kill it.
  • #408 Clarify GPURenderBundle state inheritance
    • CW: basically nothing is inherited from RenderPass to RenderBundle. After RB, nothing from previous pass is inherited.
    • AE: mainly because Vk has this restriction.
    • CW: for secondary cmdbuf can’t inherit?
    • DM: don’t you spec what you inherit?
    • AE: docs explicitly say there’s no inheritance. Couldn’t find where you state the inherited attributes.
    • CW: seems the only thing the cmdbuf can say is, in Vulkan, which level it’s in. Doesn’t get any pipeline state / render pass state.
    • AE: render pass info has to be compatible. That’s why it’s inside the RenderBundleEncoderDescriptor. Color formats.
    • CW: Vk spec has some docs on inheritance. Can’t inherit bind groups though.
    • DM: makes sense from API perspective. Even if Vk allowed it - to have render bundles isolated.
    • CW: having render bundles inherit bind groups would be nice, inherit projection matrix etc. But sure people can work around that somehow.
    • RC: if RBs don’t inherit anything then what’s the rationale for people not making a new command list?
    • CW: they can reuse them. They can create them on different threads and aggregate inside render pass. Can build 2 RBs while walking scene graph and then reorder commands because they’re inside a render pass.
    • RC: OK this is inside-render-pass replay. Makes sense.
    • CW: sounds like everyone’s fine with 0 inheritance between render bundles and the render pass.
    • CW: ship it.
  • CW: #402, #401, #400, #399
    • Collection of pull requests that make objects serializable. Transfer between workers. Basically allow the basis of multithreading WebGPU.
    • JG: doesn’t serializable also imply you can put it in local storage and pull it out?
    • KN: there’s a flag specifying what the serialization algorithm is. If it’s “ForStorage”, throw an exception. Silly, but that’s how it works. We have to do that, but we will.
    • JG: serializable is being able to access the same object from different workers.
    • KN: in this case, yes.
    • DJ: this is different from Transferable? You can have 2 copies in 2 workers?
    • JG: yes. Depends on the spec.
    • KN: the way I’m intending to spec, they’re copies of references to the same thing.
    • CW: copying from worker A to B and then B to A, do you get the same reference in worker A?
    • KN: 2 different JS objects.
    • RC: if 2 diff JS objects refer to same internal object, what about races where 2 threads try to fill it with data? Thought we were going to transfer things.
    • JG: one of the things we agreed to: it’s fine to share references to immutable objects. References to mutable objects we’d have to talk about, because it’d expose race conditions. Thought e.g. once you produce a pipeline you can share them.
    • KN: some of these are mutable and some are not. ShaderModule. PipelineObject, etc. all immutable.
    • RC: there’s GPU buffer / texture.
    • KN: that’s why it’s a separate PR.
    • CW: let’s add multithreading to the F2F agenda.
    • KN: do people want to merge 399, 400, and 401?
    • JG: approving the immutable ones, for what it’s worth. Dzmitry’s already done so.
    • CW: ship it.
    • KN: someone can revert it if they want to.
    • CW: can talk about objects with mutable content at the F2F.
    • JG: let’s schedule it.
  • #387
    • KN: Myles isn’t here and he didn’t respond to my question
    • CW: defer to F2F then.

Coordinate systems #416

  • CW’s proposal
  • CW: basically: all the coordinate systems are Y-down. There’s a way to get the preferred swap chain orientation. That depends on the hardware you’re running on. If you want the canvas to display as efficiently as possible, you have to be able to query it from the browser so we can render differently.
  • CW: that was the original proposal. Question about whether normalized device coordinates will be Y-up or down. At this point I personally don’t care so much.
  • DM: I think we’re in a situation where we need stronger principles to align to. Chas’s comment is appealing. Provides a model where it’s easy to think about. 2D is Y-down, 3D is Y-up.
  • CW: Chas’s comment is why I don’t have an opinion any more. Chas’s comment is pretty appealing to me as well.
  • RC: I agree of course with Chas. Also, for MVP, don’t think we should have a choice - API should tell you what to use and save anything else as an optimization for the future.
  • KR: Agree and don’t think we should expose preferred orientation yet. There are even two approaches floating around the office (for WebGL/2d) right now. Either have a magic flag to rotate canvas in composition, or use CSS transform to do it explicitly.
  • YH: I agree with that. The orientation’s also different from flip-Y. Orientation’s like portrait/horizontal. If you need to do flip-Y for OpenGL, it’s different.
  • CW: to be clear: the flip-Y suggested in the proposal is only when the swap chain is presented to screen. Not related to NDC. Since that’s a problem happening in different groups maybe it should be solved for Canvas in general. Makes sense to drop the preferred swap chain stuff for now until we see how Canvas evolves. Unfortunate for people coming from WebGL but they can just do a blit.
  • CB: given level of consensus, do we mark this closed? Do we have to bring it up at the F2F?
  • JG: we have to resolve which way to do it.
  • CW: everyone seems happy with D3D model and no swap chain orientation.
  • JG: yes.
  • YH: yes.
  • JG: we should put together a PR for that saying as much.
  • CW: not sure what section of the spec this should go in. Obviously, Microsoft’s happy with this. Google, Mozilla too.
  • DJ: Apple is OK too.
  • CW: great! We have a coordinate system.
  • DJ: unless everyone wants to use polar coordinates everywhere. :D

Out of bounds clamping #311

  • CW: Myles is not here; Dean, Justin, can we discuss this now?
  • DJ: I prefer to wait for Myles. FYI: Myles and I won’t be here next week; Justin will be.

Agenda for next meeting

  • CW: would be nice to have more spec contributions to go through in meeting. Maybe even test suite contributions. Have to figure out how to review those.
  • DM: also issues to discuss. #421, offset to vertex buffers. (If we have vertex buffers.)
  • CW: next time we can go through a number of these. #430 is interesting. If there’s an issue you’re interested in please drop it in the agenda for next week. I’ll select a group of issues and PRs as well.
Clone this wiki locally