Skip to content

GPU Web 2020 01 27

Jump to bottom
François Daoust edited this page Dec 1, 2020 · 1 revision

Chair: Dean

Scribe: Ken, Dean, Austin

Location: Google Meet

TL;DR

  • If you will be presenting at the F2F, make sure to talk with Rafael and make sure Microsoft Teams is working for you!
  • WebGPU will colocate a F2F with WebGL/Khronos in Phoenix, week of May 4-8.
  • At the F2F, we’ll meet with the D3D team. (WebGL topics also OK.)
  • We could teleconference with the Metal team too (F2F or not).
  • #517 Make imageHeight optional
    • Metal has a min value for imageHeight. This makes it relatively complex and non-obvious to define what a “default tightly-packed value” would be.
    • Alternative is, imageHeight default is only valid if depth is 1.
    • Request for feedback from DM/JG on GitHub.
    • (Speculation on why this limit is there.)
  • #498 Add [EnforceRange] to all integers
    • Still needs bikeshedding.
  • #545 Use FrozenArray<> instead of sequence<> for extensions attribute.
    • Just an IDL fix. Merged.
  • #538 Add validation rules for BindGroup creation
    • Last revision only got one review, but can be edited later. Merged.

Tentative agenda

  • Admin
  • F2F in May?
  • Agenda for the F2F
  • Changes to adapter discovery #521 #522 #523 #524
  • PR burndown
  • Agenda for next meeting

Attendance

  • Apple
    • Dean Jackson
    • Justin Fan
  • Google
    • Austin Eng
    • James Darpinian
    • Kai Ninomiya
    • Ken Russell
    • Shrek Shao
    • Ryan Harrisson
  • Microsoft
    • Chas Boyd
    • Damyan Pepper
    • Rafael Cintron
  • Mehmet Oguz Derin
  • Timo de Kort

Administration

  • DJ: Need feedback on the charter. W3C is pushing us on this, but not a huge rush. I still have some comments from DM. Haven’t heard from the other companies yet.
  • KR: Corentin circulated this with our legal team, thought this was generally good to go.
  • DJ: I think so. During F2F, should we discuss concrete next steps?
  • DJ: F2F in 2 weeks. Rafael sent out the address of the hosting building.
  • KR: The Aloft Redmond Seattle is within walking distance.
  • RC: any items for the D3D team, please put on the agenda.
  • DJ: Also RC sent a link to Microsoft teams.
  • RC: Yes, if you’ll be presenting, please install that ahead of time. We should probably also do a practice session and get everything set up so it works well. We’ve had some difficulty in the past.
  • KN: FWIW, AE and I tried Teams this morning. Voice+video+screenshare did work effortlessly, both from Chrome and from the Mac app.
  • DJ: you didn’t need a special login or anything?
  • RC: before the meeting I’ll send out a link. Click it and it’ll connect you to the correct meeting.

Meeting in Phoenix, May

  • KR: WebGL will meet week of May 4-8 in Phoenix. Shall we try to co-locate a WebGPU meeting?
  • DJ: I think that’s a good idea. It also makes sense that KR ask for this. When it comes to expenses, Apple is happy to contribute.
  • KR: Any concerns or go ahead?
  • DJ: only request: after the WebGL meeting. Do we have a day yet?
  • KR: Will schedule. Two days for WebGPU?
  • DJ: Yes, I think that works well.
  • KR: If not T, W, Th, are M, W, T, or W, Th, F okay?
  • DJ: Yes

Agenda for the F2F

  • F2F Agenda
  • DJ: Rafa
  • DJ: Metal team is also happy to come to a couple meetings. (teleconference).
  • KR: RC and DP, would it be okay to raise concerns about the old FXC pipeline?
  • RC: Yes, you can ask whatever you’d like. If you’d like to give feedback on FXC, that’s certainly fine too.
  • DJ: I think it’s fine even if they’re WebGL concerns.
  • KR: Other logistical concern is that I won’t be at the WebGPU F2F. Also will not be able to join remotely. I’ll make sure other questions and concerns are adequately expressed to the rest of the team at Google.

Changes to adapter discovery #521 #522 #523 #524

  • KN: I haven’t done any further thinking after we talked about privacy budgets. I know JG had something he wanted to talk about, but I don’t know what it was.
  • DJ: think Myles had some input as well
  • KN: I probably should have worked more on this this week. Not much more to discuss given Myles’ and Jeff’s absences.

PR burndown

  • KN: we have some PRs open that we should do something about.
  • KN: #517 Make imageHeight optional
    • AE: there are minimum size issues on Metal, filed as a separate issue and linked from it.
    • KN: probably should gather feedback online. Make 0 tightly packed? Don’t care. Previously would rather 0 be invalid for anything depth>1. That’s what the PR says.
    • KN: current PR says 0 is only valid if depth=1. Resolved to change 0=tightly packed, but Austin filed issue, makes it difficult: can’t say “tightly packed, down to some lower limit” because of Metal validation layers. Question is, make it invalid and user has to specify, or tightly packed == size of 1 row, unless image is size 512, in which case it’s 512? I would rather not add the complexity, and leave the PR as it is.
    • AE: seems fine to me.
    • KN: zero would mean, the depth has to be 1. i.e., you have to explicitly specify it if you want to use it.
    • AE: it defaults to 0. You leave out the depth part of the size, means 2D rather than 3D.
    • KN: correct, wouldn’t be valid for 3D. I don’t think anybody’s felt very strongly about it in the meeting. Don’t think it’s contentious given this restriction. DM, JG, JF were all in favor.
    • AE: could ask them if they’re fine with it and then merge.
    • KN: they approved it without changes. JF any strong opinions?
    • JF: the complication with Metal, I don’t know enough about to change my opinion. Like the convenience of 0 meaning tightly packed.
    • KN: in practice, not dealing with 3D data all that frequently anyway. Also, definition of tightly packed isn’t always that easy. Don’t think it’s unreasonable for it to be set. Maybe I’ll ping the issue and we can merge it soon.
    • KR: Are the alignment constraints in Metal surface in WebGPU?
    • KN: they’ll have to be. There’s another issue Austin filed about it. This is not actually an alignment constraint; don’t know why it’s there, but it’s a minimum. Each has to be 512 bytes minimum. Unfortunate because row alignment is already 256, so if this minimum has to be 512, causes confusion.
    • AE: wonder if these minimums in Metal are “optimal” if it’s aligned to that number. For example, 64 byte alignment is performance optimal? This one, 512 bytes?
    • KN: would be good question for the Metal team. Interesting if we had 256 alignment for rows and 512 alignment for images, but seems heavy-handed.
    • KN: will comment on it and ask for JG and DM to provide opinions on this issue (#517). But pretty sure we’ll merge it later.
  • DJ: #498 - just needs to be landed?
    • KN: nobody totally agreed how it should be phrased. Should we have semantic types, or not? EnforceRange on everything? Types like u32strict? Also doubt anyone cares super-strongly because shouldn’t make a difference. JG / DM had strongest feelings. Let’s punt.
  • DJ: others are adapter ones, #545 - should we just land this?
    • KN: that one I’m 99% sure should just be landed now.
    • (Merged.)
  • DJ: #538 - lots of comments / revisions. Last one, Yunchao did send the final patch. Ready to merge?
    • KN: yes, think we should merge this. Hoping someone else would review, but not necessary.
    • (Merged.)
  • DJ: all other ones seem to need discussion.

Agenda for next meeting

  • PR burndown, specifically #521 #522 #523 #524
  • setSubData one still open forever
  • DM has one open on write-only storages. Only discussion between him and Corentin.
  • Anything else specifically to discuss before the F2F?
    • No comments from anyone
Clone this wiki locally