Skip to content

Minutes 2022 11 30

Jump to bottom
Corentin Wallez edited this page Dec 6, 2022 · 1 revision

GPU Web meeting 2022-11-30 APAC-timed

Chair: KG

Scribe: KR

Location: Google Meet

Time: 4-5pm (America/Los_Angeles)

Outstanding issues: V1, Untriaged

Attendance

  • Apple
    • Dan Glastonbury
  • Google
    • Brandon Jones
    • Kai Ninomiya
    • Ken Russell
    • Shrek Shao
  • Intel
    • Hao Li
    • Jiawei Shao
    • Shaobo Yan
    • Zhaoming Jiang
  • Mozilla
    • Kelsey Gilbert

Administrivia

  • Orgs: Please vote on proposed charter for the GPU for the Web working group!
    • Not very many have yet, and we’d like to see more support!

CTS Update

  • KR: Gyuyoung from Igalia's been adding new operation tests to exercise how the pipelines work.
  • KN: in rendering, blending and depth/stencil operation tests so far

“Tacit Resolution” Queue

Add samples #3573

  • KN(pretyped): I haven’t had a chance to review this but we should probably accept it (though maybe with a smaller texture resource). I’m not even sure our other samples are up-to-date, maybe they are. In the past I’d have worried about maintenance but the API should be stable enough now that this won’t break regularly.
  • KR: it sounds fine to expand out the samples (the samples/ dir already exists), but I would like to find a path for migrating Austin's https://github.com/austinEng/webgpu-samples into a more formalized repo under gpuweb/. Then these samples could be migrated into this new repository as well. This would keep the spec repo cleaner and more focused. So maybe create gpuweb/samples now and put this PR in it instead? Otherwise this large binary file will be in the git history of the spec repo forever.
  • KG: +1
  • BJ: +1 to having canonical samples, but not in the spec repo, instead adjacent to it.
  • KG: let's go in that direction then. Canonize Austin's samples into gpuweb/samples, then look at additions to that.
  • DG: haven't discussed this internally, but I'm in favor of a separate repo.

Optional feature request: filterable 32-bit float textures #3601

  • KN(pretyped): Realized this looks like a duplicate of #3556. All the more reason to consider getting it in now.
  • KG: common, but not universal, WebGL extension. Would be a regression if people can't optionally filter 32-bit float textures. Agree, think we should just have this in V1.
  • (No objections)
  • KG: let's do that. Someone please put up a PR.

Almost no PowerVR devices satisfy minimum Vulkan requirements #3631

  • BJ: don't recall the combination of limits. From discussion with Kai, wanted to break down the limits in the way this would require anyway - for the Metal backend, I think. Separating them into something less monolithic would make it easier to support more devices.
  • KG: similar to max combined vertex inputs (?), which we already approved.
  • BJ: yes.
  • KG: a PR would be welcome.

Should "mark adapters stale" be called more quickly? #1630

  • KN(pretyped): Last week’s minutes record a consensus to expire adapters on successful requestDevice, but then we kept talking for a long time. Do we have a consensus (is KG OK with it for V1)?
  • KG: think we can accept this for now and do something else later. Think we're done here.
  • KG: consensus then is - make it so adapters only live long enough to have resources requested from them, and they may expire earlier than that, too.
  • BJ: yes, that's a sufficient high-level explanation.
  • KG: there was a request to make it easier to simulate context/device loss, ideally in the core API. More that if I'd like that, I should write a PR for it. Any concerns about that?
  • BJ: it's been beneficial for WebGL (via an extension).

Primitive clipping at the rasterization stage is inconsistent between APIs #3638

  • KN: on Metal, clip mode can be "clamp" or "clip". On Apple devices, behavior's like OpenGL/Vulkan, but on desktop devices, it's D3D12's behavior. Didn't realize this until we wrote a test. Doesn't make things too much more complicated. We do have to add a clamp in the Metal backend as well, for Apple devices. (We already do this on Vulkan.) Makes things a little more complex.
  • KG: what's this clamping specifically?
  • KN: the fragment depth. A primitive can be clipped to the clip volume, which may or may not clip in Z-direction; and … can get clipped to the range of the viewport when they're output. OpenGL conflated the two. Can only have one or the other, not neither and not both, though they're separate. Vk inherited this behavior. Metal partially inherited it. Vk now has an extension to control them separately. Without the extension, have to modify the shader to clamp frag depth before it's output. We already implemented this for Vulkan (I think), so just have to do it for Metal.
  • KG: and then specify which direction we chose?
  • KN: yes. Wouldn't change the spec, since the spec says clamping's always enabled.
  • KG: just a note to implementors, and needs CTS.
  • KR: Is there any perf consideration here? Is this happening in the vert shader? No, this is frag, right?
  • KN: Yes clipped in frag shader, but only if frag depth is output. Not seeing any alternative, because d3d12 always clamps, and I don’t think we can emulate anything else on d3d12.
  • KR: So for early-z, we just need to make sure we don’t fall off that fastpath?
  • KN: would need to revisit original discussion, but think it's fine for the general case.

Agenda for next meeting

  • Take a look at the upcoming agenda items, let's try to make progress offline. Everything took less time than expected this week, which is great!
  • Upcoming WebGPU API schedule:
    • December 07: Non-APAC
    • December 14: APAC
    • _December 21: _Non-APAC
    • (Christmas Eve & Day, Sat Dec 24 & Sun Dec 25)
    • December 28: no meeting due to Christmas/New Year’s Day
    • January 04: APAC
  • Agenda
    • (stretch) Frame presentation timing queries/control? #3634
Clone this wiki locally