Skip to content

GPU Web 2020 02 03

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

Chair: Dean (Corentin out)

Scribe: Dean, Austin, Ken

Location: Google Meet

TL;DR

  • Agenda items for D3D meeting
  • #524 Pluralize requestAdapters
    • Some discussion about the goals.
    • KN: I really need to make a concrete proposal.
  • #521 requestDevice returns null if adapter is lost
    • Resolved: merge.
  • #522 gpu.onadapteradded
    • Already resolved; still needs followup.
  • #523 document that requestAdapter can delay too
    • Resolved: merge.
    • MM: Browser policies should consider compute-only applications. We would need a signal. KN: We talked about an 'allowComputeOnly' flag for headless GPUs or VPUs. Good point that it would be a really useful signal here too.
  • #543 Add GPUPipelineBase.getBindGroupLayout
    • Still WIP, CW not here. Skip.
  • #540 Define extensions, limits, and "valid usages" for requestDevice
    • Resolved: resolve the minor open comments, merge.
  • #517 Make imageHeight optional
    • Should at least consider making imageHeight=0 REALLY mean 0 - duplicate the data to each layer/slice.
      • Need to look at whether ANY native API allows this.
  • #519 imageHeight -> imagePitch
    • Naming: probably resolved
    • Units: not resolved, let’s have a small discussion at the F2F.

Tentative agenda

  • Agenda for the F2F
  • Agenda for discussions with D3D team
  • Agenda for discussions with the Metal team
  • “SetSubData” ?
  • PR burndown, specifically #521 #522 #523 #524
  • Agenda for next meeting

Attendance

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

Agenda for the F2F

  • https://docs.google.com/document/d/1vQPA1JSOvfCHjBrkAEDLA1qCqQXe72vGen_1quoHZV8/edit#
  • Meeting with D3D team
    • haven’t specified a time or day yet
    • RC: We can pick the time. We should agree to topics beforehand so that they bring the right people.
    • DJ: Should we decide the topics now?
    • RC: Yes, they asked that if they need to review our spec, we give them advance notice.
    • (See below.)
  • MM: We would like to discuss shading languages. Phil would like to participate - he can be there in person on Tuesday. He can call in on Wednesday.
    • DJ: Any issues with shading languages on Wednesday?
    • Nope.
    • Resolved: Some shading language.
  • MM: would like progress updates from all the teams.
  • Add #543

Agenda for discussions with D3D team

  • MM: One of the topics I’d like to talk to them about is keeping data on the chip. I should make a proposal by next week. The D3D docs don’t mention much about how to do it - so I’d like to hear from them about that.
    • RC: is this in regard to Metal APIs?
    • MM: yes, Metal has ImageBlocks. Vulkan has sub-passes. Wildly different APIs designed to accomplish similar things.
  • RC: I was going to ask about dealing with multiple GPUs. Having discussion about that, about what Safari / Firefox / Chrome does on macOS, etc. would be useful.
  • KR: I’ve added fxc/dxc discussions (topic came up in WebGL).
    • MM: in regard to shading language, probably matters whether producing something being ingested by fxc or dxc.
    • KN: also might affect WebGPU if ever intending to make a WebGPU targeting D3D11.
  • Is it still important to support occlusion queries? #72
  • fxc / dxc questions. Performance issues from WebGL. Questions (again) about using DXC compiler pipeline with D3D11.
  • We need to determine whether we’ll be targeting FXC or DXC (or producing our own DXIL)
  • Robust Buffer Access - when does it help/when doesn’t it help? Any clarifications?
    • MM: do you mean, a well-defined behavior, or “can do anything as long as it doesn’t crash”?
    • RC: well-defined behavior. Indexing out-of-bounds of a vertex buffer using an index buffer will return 0. But in some cases in D3D12 it can’t do that bounds checking, so you might get “any data” from within the process. Doesn’t work well if putting all domains’ rendering results into the same GPU process.
    • KN: someone should look through old issue list and see if anything came up in the past that we didn’t figure out about D3D or Metal.
  • DP: has there ever been a conversation between the web groups and D3D team about security boundaries and where they are? E.g., putting everything in one process and expecting software boundaries to enforce everything, not sure if that sits well with the D3D team.
    • MM: when you talk about process boundaries, would be good to know what in D3D is enforced by a process boundary.
    • KR: In WebGL, I think we talked with the OpenGL working group and the D3D team, and the WebGL OOB access behavior was specified in terms of that. These things have probably changed, so it’s a good idea to talk to them.
    • KR: Vulkan specified Robust buffer access behavior from the start, drawn from OpenGL. Not sure if it’s testable in its current form. With alignment constraints, it’s possible you might be able to access beyond the end of a buffer before the end of a “page” where hardware knows you’re out of bounds.

(after meeting) KN’s collected issues from browsing gpuweb issues:

  • #435 Managing on-chip memory: Can the D3D team share any plans about subpass/imageblock like features?
  • crbug.com/dawn/336 Should we expect any differences between “desktop” and ARM/64 D3D12?
  • What about Xbox D3D12?
  • Shader explosion problem?
  • Opinions on inclusion in WebGPU 1.0 (are they useful? fast across architectures? etc):
    • #431 ExecuteIndirect
    • drawIndirect/dispatchIndirect: opinion on inclusion in the API?
    • #442 #395 programmable blending, fragment shader interlock, raster order views, etc.
    • #162 uniform texel buffer / storage texel buffer?
    • #275 Picking a good value for threads-per-threadgroup
    • #284 Consider associating the texture with its clear color value
    • #72 occlusion queries?
    • pipeline statistics queries?

Agenda for discussions with the Metal team

  • DJ: thought perhaps we could have the Metal team call in to the F2F - may not be the best use of time since it wouldn’t be F2F anyway.
  • #537 Metal Validation Layers require sourceBytesPerImage >= 512 bytes
  • AE: It would be nice if we had a list of what validation layers enforce in Metal.
    • ACTION: DJ to ask Metal team for this documentation.
  • KN: Metal shader compiler performance is an issue.

“SetSubData” ?

  • DJ: No Jeff here today, so not productive to talk about it now. Move to F2F agenda.

PR burndown, specifically #521 #522 #523 #524

  • KN: on #524, about requestAdapters:
    • I know that JG had something he wanted to say, but not sure what it was.
    • DJ: he approved the changes.
    • KN: we decided during meeting a couple of weeks ago that this wasn’t done yet - has to be designed with privacy budget in mind. JG wanted to say more about the change as it stands.
    • MM: wanted to raise the idea that browsers matching behavior in this area really matters. Even if API allows the browsers to do different things. Websites will then expect different things.
    • KN: if some browsers choose to return only one adapter, that’s not a concern - most systems only have one adapter anyway. Issues like: adapter names, etc., could matter more.
    • MM: disagree with first point. Fact that most devices only have 1 GPU doesn’t mean we shouldn’t fight fingerprinting.
    • KN: just mean it’s not a compatibility concern; apps have to handle the 1-adapter case. I don’t disagree with anything you wrote on the issue. Just pointing out that the single-adapter case isn’t a portability concern.
    • MM: the number of adapters returned isn’t the concern; it’s whether apps are expected to iterate the result, or call it multiple times.
    • KN: if we had an “easy mode” requestDevice, no adapters, that would remove complexity in other parts of the API. Just an idea I was going to try to incorporate.
    • MM: having “easy mode” is a great idea. Should have something like it. Need to figure out what it means on Vk and D3D.
    • KN: probably not any different than taking the first adapter in the list with some default arguments.
    • MM: if there is a fingerprinting problem with an API, solution can’t be “add another API”.
    • KN: understood.
    • KN: someone needs to come up with a proposal - probably me.
  • #521 - changes what requestDevice does if the adapter is lost.
    • KN: Return null to say “I can’t create you a device” rather than exception. Exception means you asked for something invalid. Should simplify how apps handle these cases.
    • Pretty small change. Nobody had any concerns.
    • MM: because throwing exception causes promise rejection?
    • KN: logic is: there are 2 different things going on. One: the adapter is lost. You can then try to get another adapter. Other is, you’ve just messed up, asked for limits on a device that can’t be supported by its adapter. In latter case, the app shouldn’t have done this, so shouldn’t be expected to recover. Think exception is better way to say, exit your device selection logic completely.
    • KN: if we return both through an exception, app has to detect one but not the other exception.
    • MM: so sometimes it returns null and sometimes throws exception / rejects promises depending on what app should do?
    • KN: yes.
    • RC: recently, I was told that promise rejection should only be used when web developer is doing something wrong. Here, if adapter’s lost, requestDevice returns null. If options are invalid, it rejects. Is exceeding the limits of the adapter something we should expect a web developer to know how to do correctly?
    • KN: we expect an app to never ask for a device that exceeds the limits of the adapter. If they’re doing to ask for limits above the defaults they should have looked at those limits available.
    • RC: in that case I’m fine with that part of the PR.
    • KN: everything else is details.
    • JF: I’m OK with #521.
    • DJ: OK, let’s accept and merge it.
  • #522 - GPU onAdapterAdded event.
    • DJ: last comment: consider whether should be “onAdaptersChanged”.
    • KN: let’s defer this one. Had resolution, not followed up on yet.
  • #523 - Document.requestAdapter can return null.
    • KN: not written in spec yet. This documents when the browser can delay due to the tab being in the background, for example.
    • DJ: so idea is that the promise doesn’t resolve / reject until tab is foregrounded?
    • KN: yes. Then browser can decide what adapter to return later rather than earlier.
    • MM: this is a good idea.
    • KN: this is how it should work. Don’t want requestAdapter to choose while tab is in the background, then do something different when tab is foregrounded 5 hours later and you’re on battery.
    • MM: should have sample code for case where you don’t want to wait 5 hours?
    • KN: page should be suspended, should not be doing any WebGPU stuff. Suppose an app might want to do some fallback logic if it can’t do WebGPU quickly, but should be pretty rare case. If not in foreground, don't’ need to do anything visual.
    • DJ: what if you’re on a games portal and wanted to right-click and load a game in the background?
    • KN: up to the browsers to decide when they delay. Think that we wouldn’t delay new tabs. If tab goes to background and is there a long time, and we take away its device, then the page would immediately request another adapter, but wouldn’t get a response until it comes to the foreground.
    • MM: makes sense for graphical apps but maybe not compute-only.
    • KN: can’t currently request compute-only, but we’ve talked about it. Adapters which can only support compute. If you have an NVIDIA GPU only for CUDA, for example. Or one of the Intel compute chips that only does compute. Need to have a discussion. Very good point that we should be able to use the compute-only signal here.
    • DJ: any other comments? Otherwise I think we accept it.
    • KN: I’ll double-check it’s ready to merge before merging it.
  • #543 - Corentin opened - not a lot of discussion yet. GetBindGroupLayout
    • DJ: at least some changes requested, not a lot of updates
    • KN: in-progress, and Corentin and Dzmitry aren’t here. I don’t remember whether we talked about this idea in general. Is everyone happy with GetBindGroupLayout?
      • MM: I think Jeff was somewhat negative on it.
  • #540 - another requestDevice change
    • DJ: approved, but some follow-ups.
    • KN: mainly just details about how the spec’s written.
    • MM: no change in behavior.
    • KN: correct. Does formalize some things. Mostly an editors’ meeting topic. I’ll check and merge it.

Optional imageHeight #517

  • DJ: Discussed last week. Kai asked for comments from Jeff and Dzmitry.
  • DJ: leave until next week.
  • MM: if rowPitch = 0 is that an error?
  • KN: hasn’t been documented at all yet. There is a question about a 1D texture and whether you can have a rowPitch of 0. Says it’s required. Guess we should extend the same logic: if doing a 1D texture copy, ...
  • MM: 1D texture op, 0 is special: but 2D op, 0 is an error. 2D more common than 1D.
  • KN: could give rowPitch 0, …
  • MM: if I want to copy from one texture to another, have fanout where same level of input texture is copied to multiple levels of output texture, maybe it’s a good idea to have rowPitch of 0?
  • KN: they don’t apply to texture-to-texture copies.
  • MM: then copying from buffer, would like it to be written to multiple parts of the dest texture.z
  • KN: semantically makes sense, but in some backends we’d have to emulate this with multiple copies.
  • MM: probably better to make app do it themselves.
  • KN: think nice to stick with semantics. 0 means 0. Don’t think the backend APIs let you do this.
  • MM / KN: can’t be added in later.
  • KN: it is possible to pick another value, like Undefined (probably shouldn’t distinguish between this and 0), -1, or something else.
  • RC: could another option be, split this one dictionary entry, have one be “Depth” and one be “Layer”? Having “height” be a proxy for both depth and things-in-an-array seems weird.
  • KN: I don’t like the name imageHeight - proposed we change it. Makes sense to use “Image” to mean a 2D texture or a slice of a 3D texture layer. It’s the way native APIs do it. Height, I think of as a view into a buffer. Pitch would be clearer in my opinion.
  • MM: is there a PR for that?
  • KN: Yes. #519.
    • MM: thought we weren’t going to put documentation in comments.
    • KN: yes, we will put it in the docs when we have actual documentation. Will take care of it later.
    • RC: how will it work when pitch will refer to texture array layers? That won’t be in bytes. Will imageHeight be zPitch?
    • KN: imagePitch
    • RC: can’t be in terms of bytes since it’s in units of array layers.
    • KN: this is in GpuBufferCopyView. rowPitch is in bytes. Image in units of rowPitches - how many to be read out into layer / slice of 3D texture.
    • RC: so this is specifically for copying buffers, which are random bunches of bytes.
    • MM: can we have imagePitch as a multiple of rowPitch?
    • KN: not sure. Metal does it in bytes.
    • MM: think people will be confused.
    • KN: Metal does it in bytes, Vulkan in terms of texels (confusing), not sure about D3D.
    • AE: Vk does it that way probably for compressed texture formats.
    • MM: want it to be hard for author to write something wrong, but want API to be familiar. The first one wins when in conflict.
    • KN: don’t feel strongly about imagePitch units. Don’t think the answer is obvious enough that people won’t look it up.
    • DJ: do we want to merge #519? Next week’s call is cancelled.
    • KN: we can put it off until the F2F.
  • KN: #517 - making a note about 0 really meaning 0.
    • MM: can someone figure out whether 0 can be passed to the native APIs?
Clone this wiki locally