Skip to content

Minutes 2018 04 18

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

GPU Web 2018-04-18

Chair: Corentin

Scribe: Corentin

Location: Google Hangout

Minutes from last meeting

TL;DR

  • Build the agenda for the F2F
  • More discussion of error handling
    • A global error callback would be preferred to a error log queried via promises
    • Should have “debug markers” or token that are given back in the error callback
    • Kirill confirmed that faillable allocations are paramount for the Maps use case.
    • Memory heaps were brought up as a potential solution for faillable allocations
    • Memory heaps are difficult because of vkGet*MemoryRequirements

Tentative agenda

  • Agenda for the F2F
  • (Stretch) more on error handling

Attendance

  • Apple
    • Dean Jackson
  • Google
    • Corentin Wallez
    • David Neto
    • James Darpinian
    • Kai Ninomiya
  • Microsoft
    • Chas Boyd
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Markus Siglreithmaier
  • Yandex
    • Kirill Dmitrenko
  • Elviss Strazdiņš
  • Joshua Groves

Agenda for F2F meeting

  • CW: Error handling should be mostly possible to resolve in the F2F
  • DJ: Was wondering if we had finished error handling or were going to talk about it at the F2F
  • CW: Last meeting was mostly to present the proposal.
  • CW: Think we want to talk about memory barriers again.
  • DM: Would be great to have input from ISVs on the big questions.
  • CW: Pb is I can’t know who is registered on the mailing list.
  • DJ: Checked there isn’t a way to know who is on the list. Will send an email to someone that might be able to.
  • DM: Can we ask Epic directly?
  • CW: Did, taking an AI to follow up on it.
  • DM: Asked Arseny to join, dunno if he did.
  • CW: Would like to talk about how we can collaborate on stuff (spec, tests, maybe implementation).
  • CW: Should we talk about shading languages?
  • DJ: Nothing new, don’t think there’s a point in having a discussion again. POR we investigate implementation and most people on the side of SPIR-V.
  • CW: Talk about pollability? Surprised that Microsoft’s Travis was against it.
  • RC: Nothing new since the end of last year on the OffscreenCanvas issue about this.
  • KN: Think I saw something more recently.
  • RC: Travis made it sound like blocking APIs are not something they are comfortable with even in workers. Not sure if all the TAG feels like this bit at least Travis does. He reminded that if you block workers, then you can’t receive postMessage, so…
  • CW: So we don’t put it in the agenda but push our TAG representatives and canvas folks to figure out.
  • DM: Also discuss memory heaps which may be related to errors.
  • CW: Partial pipeline states too?
  • CW: Main entry point (Device creation, features/limits, etc)
  • DJ: And canvas integration
  • RC: How much do we have bitflags that you can OR together.
  • CW: Go over the IDL to fix some stuff so that people feel more comfortable going ahead prototyping.
  • DM: Will we have time to talk about descriptor pools? Might make sense to expose them because they map Metal2 IAB
  • RC: Did we agree on how we were going to do interop with other elements.
  • CW: Seems hard to figure out the synchronization story before we have the rest of the API
  • CW: Will send details about the F2F in an email (with phone number)

Error handling

  • CW: Callback vs. promises for errors from RC’s feedback on the proposal?
  • KN: Worry about producing a huge amount of callbacks when a validation error propagates. That’s a performance concern but maybe not a big concern because the application is erroring out. Callbacks do seem reasonably nice.
  • RC: Similar problem with promises where you can a list of a huge number of errors.
  • CW: Had deduplication of errors described in the document
  • KN: Could have a hard limit on the number of errors, like 150
  • DM: Deduplication doesn’t mesh well with callbacks
  • CW: Callback can get a deduplicated list.
  • DM: Agree that callbacks seem like a simpler solution.
  • CW: In the proposal we suggest there is one error stream per worker, could have one callback per worker, sound fine.
  • RC: Need to define the granularity of callbacks, at least one per-worker.
  • KN: Think it should be at the highest level possible.
  • CW: Promises help narrow down where the error was generated. Could help figuring out it is the middleware that has an issue and not you app. Tiny use-case
  • KN: Could have a token that’s provided in the promise.
  • CW: Would be great to have debug markers that would be included in the error log for telemetry.
  • RC: Think the debug markers should be returned as a different type in the error log. Separate field with attribute like the app’s string, and ...
  • KN: Can go as far as having some stack-based thing. A middleware you push pop when called.
  • CW: Certainly can be an extension. But would be KHR level as in everyone implements it, might as well put it in core.
  • CW: So callback is good enough for global errors if it can have deduplication and debug markers?
  • DM: Would be nice to have severity levels
  • CW: Think the markers would be just to mark the error log, not warnings.
  • KN: Was suggesting “push pop” a context name, if no error happens in that context then nothing gets log. The context name only gets used if an error is generated.
  • RC: If we want to be super MVP we could have push and pop and the error gets tagged with the context name, printf debugging.
  • RC: Is it true that in other browsers if you have the debug console open, the JIT doesn’t JIT?
  • KN: Don’t think Chrome deoptimizes unless you have a breakpoint.
  • CW: Do callback take a sequence of errors for deduplication?
  • JD: Think that filtering errors doesn’t require passing a list to the callback.
  • RC: For MVP we can have one error per callback and deduplicate under the hood.
  • RC: Other comment was about whether we need promises for object creation.
  • KN: Right thing to do is to discuss heaps first because it would change the shape of faillable allocation significantly.
  • RC: We can have the implementation handle heaps for the application.
  • KN: Would probably be ok to have a heap return a promise. (tryCreateHeap -> Promise<WebGPUHeap>). But depends on heap existing. Don’t think it is practical to have promises for individual textures and buffers.
  • JD: And allocating in such a heap makes sure no OOM can happen.
  • RC: How important is it to have faillable OOM errors?
  • KN+JD: We’ve seen customers wanting this, Ken was adamant about this use-case. Without faillable allocations they have to guess how much memory they need to use and risk a context loss.
  • JD: Any LOD streaming needs to guess how much memory it can use.
  • KD: Agree with what’s previously said. Not convenient that when we hit memory limits WebGL context dies. So right now when WebGL dies we need to fallback to something else. If we can get faillable allocations, things are much better for us.
  • KN: Lot of streaming application will as much memory as possible
  • JD: Or at least know they hit an OOM and reduce usage.
  • RC: Is it more useful to tell them how much memory they have.
  • CW: Even in backing APIs you can query how much memory you can have, but you might not actually be able to allocate it.
  • RC: How do these application handle JS OOM?
  • JD: More CPU memory usaully
  • KN: Would cause the page to crash. Not sure how things happen in WASM.
  • CW: Seems like it is important use case, especially on the Web were you do a bunch of visualization. Resolution will depend on whether we have heaps or not.
  • JD: Can we have guarantees of no OOM on allocation on pre-created heaps.
  • CW: Yes except on Metal maybe.
  • DJ: Will ask about Metal.
  • RC: Will application only allocate during setup, or every frame.
  • JD: Maps allocates inside frames because the vertex buffers are not fixed size.
  • RC: Can we have the server side communicate GPU heaps to the client side so that the first allocation is slow but subsequent are fast?
  • CW: Only faillable allocations need to be a promise
  • RC: Think that if we want people to handle OOM and pipelinable operations then we should have all allocations be promises.
  • JD: Promises aren’t pipelineable, you need to wait for the promise to be resolved before you upload to it.
  • DM: If we have heaps you can have resource creation return null if it doesn’t fit in the heap.
  • CW: We don’t know the size of resources on the client side.
  • DM: Client side can keep track of sizes
  • CW: We need to go through the driver to get size requirements at least in Vulkan and D3D12
  • RC: Would a Maps app use promise for resource creation?
  • JD: It would like to pipeline the upload, then wait on the promise to see if both succeeded. Wouldn’t draw until you verify everything is ok.
  • CW: If you’re maps you can show LOD, or wait for submiting the command buffer until the promise resolves.
  • <Abrupt meeting end>
Clone this wiki locally