Skip to content

Minutes 2019 01 14

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

GPU Web 2019-01-14

Chair: Corentin

Scribe: Dean, Corentin, Austin, Kai

Location: Google Meet

TL;DR

  • Made an agenda for the F2F
  • Buffer mapping
    • Recapped the respectives pros of #147 and #154
    • The buffer subrange proposa in #156 is mostly orthogonal but helps for descriptor set explosion in zero-copy UBOs in #147
    • Discussions of cross-process mapping of buffers and number of copies in multi-process browsers.
    • Decision postponed again, both proposal #147 and #154 have their advantages but need some more work.
  • Compressed textures #144
    • Suggestion to innovate by letting the browser compress texture (lossily)
      • Pushback because of performance and divergent behavior.
    • Will discuss more at the F2F.

Tentative agenda

  • Agenda for the F2F
  • Buffer mapping
  • Compressed textures
  • Uniform/storage texel buffer views?

Attendance

  • Apple
    • Dean Jackson
    • Justin Fan
    • Myles C. Maxfield
    • Robin Morrisset
  • Google
    • Austin Eng
    • Corentin Wallez
    • Dan Sinclair
    • James Darpinian
    • Kai Ninomiya
  • Intel
    • Yunchao He
  • Microsoft
    • Chas Boyd
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Joshua Groves
  • Matt Kielan

Agenda for the F2F

  • Agenda is https://docs.google.com/document/d/1tXp8CJ0GQa4TGkjjS_4skRPegzFut9alZkRt4KCP7m7oQk
    • Shading Lang - Tuesday PM (for David N)
    • Pass at IDL improvements
    • Test Suite
      • DJ: Plan to come with template spec doc
    • Multi Queue (Jeff will have a proposal)
    • Buffer mapping
    • Compressed texture
    • Actual creation of Swap Chain
      • DM: We have texture views. But do we return the view, or ask the user to create the view, etc? Lots of unclear aspects
      • MK: Is there a plan for a timing query? To know when a frame is displayed?
      • KN: We have fences that tell you when it was used.
      • MK: Still not enough to know when it is actually presented. There is a hitching problem. Google made a nice extension [VK_GOOGLE_display_timing] to tell you when a swap chain was presented.
      • CW: We’ll have to investigate portability. Not clear if all platforms (and browsers) can support this.
    • CW: Would like to have some form of Hackathon on the spec / idl / pair program an example.
    • MM: should talk about memory model for the shading language
      • CW: tuesday afternoon for dneto
    • #156

Buffer mapping

  • #147 (CW) Add explainer document for BufferOperations
  • #154 (DM) Proposal for a simple streaming API
  • #156 (MK) Proposal: BufferSubRanges to solve buffer-tracking, streaming and descriptor set explosion.
  • CW: I think 156 should be discussed after the others. So let’s start with 147 and 154.
  • MM: Let’s have a recap of the proposals.
  • CW: The pros of one suggestion are the cons of another.
    • 154 looks more simple
    • 154 less opportunities for validation errors
    • 147 can initialize UMA resources with zero-copy
    • 147 less complexity on implementation side
    • 147 closer to next gen APIs
    • 147 might be able to skip zero-ing the ArrayBuffer
  • CW: Is that a good enough summary?
  • MM: Yes
  • CW: Based on that, is there any initial feeling? We (Google) still like our own proposal.
  • JG: Simple is nice, but powerful is better.
  • MK: Two problems with 154 and 147. 154 can’t be a ring buffer because you have no guarantee that the memory won’t be used up. 147 suffers from descriptor set explosion. You would have to use different buffers for each frame, and thus multiple descriptor sets.
  • CW: For UBOs in 147 you would use the mapped buffer as staging for a copy in the UBO, the proposal 156 would be a more thorough fix.
  • MM: It seems that using sub buffer ranges are orthogonal to each proposal.
  • MK:
  • CW: buffer sub range is mostly orthogonal, but removes a concern for 147. Would still work on 154.
  • MK: restores closer functionality to what we have in native with persistent mapping.
  • CW: Let’s put 156 on the agenda for the F2F
  • MM: Other question, in 154 could this allow for zero-copy?
    • DM: Thinking about zero-copy initialization of buffers, but it should be possible. Needs to be more formally proposed. Potential API change.
    • CW: Doable provided we are able to map gpu buffers in the webpage’s process (Safari, and some systems). DM’s IDL should support it, but it would be complex.
  • MM: Zero copy uploads/downloads?
    • CW: Complexity for multiprocess, but doable
    • MK: Possible for UMA (and AMD), but not others (can’t map device memory)
    • JG: Other issue is that Read-write vs. Read-only etc.
    • MM: Seems that using staging memory to stage copies and using a temporary buffer to do the copy should be treated the same way.
    • JG: There would be two copies: CPU to GPU buffer in the wrong heap then copy to the actual process.
    • MM: Would implementation do this?
    • CW: Yes. If we can’t map into the content process. Write into shmem, copy into gpu memory.
    • MM: That seems like an unsolvable problem.
    • JG: My understanding is that we could do this in Vulkan.
    • CW: The Web App would write to shared memory, then the GPU process would copy that into GPU memory.
    • MM: I thought we were discussing getting it from one Heap on the GPU to another Heap. It sounds like you might need to do 3 copies in Chrome if the Vulkan file-descriptor API isn’t available.
    • CW: I think we max out at 2, by copying from shmem to staging, then staging to the actual place.
    • JG: I think this would be easier to discuss in person with a whiteboard.
  • CW: Do you think we can decide on one of these now? Or wait to the face2face.
  • DM: It would be useful to have some sort of proposal for resource initialization for simple API (154) so we can compare.
  • CW: OK. Postponed again.
  • CW: DM, you’ll make an updated proposal?
  • DM: Yes, and you’ll make an update to #156?
  • CW: OK. I’ll try to refactor and see if it is still fine.
  • MM: Is the thing that is holding us up just determining the number of copies in #147?
  • CW: Not really. The question is really do we want to optimise the number of copies, or do we want something more simple and javascripty?
  • MM: I would prefer the simple approach if the problems can be solved there. Are there other qualitative attributes?
  • CW: I think we’re confident in the number of copies involved. It’s just about the approach.
  • DM: Other issues - having a dedicated allocator per thread of per commandbuffer.
  • DM: Also, you have to be in a recording state for some uploads. Many implementations would separate asset loading from command buffer recording.
  • MM: I thought we just decided that there is a non-zero set of GPUs that will require a two-stage copy. And thus there will be access to a command buffer.
  • DM: I’m talking about the API usability, rather than the number of copies.

Compressed textures

  • #144
  • CW: Do we want to guarantee what the compressed texture format is, or assert that there will always be at least one extension available?
  • MM: It should be ok for an implementation to always compress textures under the hood. The system better knows the environment.
  • JG: Disagree. That is not the primary use of compressed textures, and causes quality issues.
  • CW: The implementation is allowed to losslessly compress textures if it wants to. But not lossy.
  • KN: Lossy means we can’t provide guarantees to the application about correctness.
  • JG: Propose discussing this after MVP.
  • MK: I suggest advertising a lot of formats being available...
  • JG: Here we are talking about compressing te
  • MK: How do you compress resident textures?
  • JG: Assuming there is a way to do this, can browsers do that?
  • MM: Basically the browser has control of where the resources are, not the application.
  • MM: I was also going to suggest what Chad raised, which is a flag to say that it is ok for this particular texture to be compressed.
  • CW: After the MVP because it doesn’t seem essential.
  • JG: Doesn’t seem very useful to me.
  • JD: Seems like a good candidate for an extension.
  • KN: Texture compression needs to depend on the content of the texture. Would need to give hints to the browser as to what compression format it is.
  • MM: Letting the application choose the format sounds good, but should describe the content of the texture.
  • KN: Can’t do this in core, because it is not possible for every implementation to compress textures appropriately.
  • MM: This would be more about allowing the browsers to compress
  • JG: You do understand by introducing lossy compression, you're introducing divergent behavior on different systems?
  • MM: Yes
  • MM: Browser better knows what is appropriate for the system.
  • JG: Hard to know what’s appropriate for the application.
  • CB: Would make sense to have the wire format of resources be JPG, and then have the browser reencode to the best GPU compression format.
  • MK: Why isn’t the application in charge?
  • JD: There is no transcoder from JPG to ETC, so we have to do a full decode. The application can do that.
  • MK: Developers are VERY vocal about the need to choose the format for texture compression.
  • MM: Both could live together.
  • JG: Does Metal do the in the fly compression today <MM: No> then why should browsers do it? This is very novel, so don’t think we should innovate there.
  • MM: Not novel in browsers, for example using displaylists to optimize 2d canvas.
  • CW: But that is lossless.
  • CW: [explaining Basis transcodable texture format]
  • MM: Text rendering in CSS is allowed to be lossy (fast. Vs. nice).
  • JG: Punt extension discussion to after MVP?
  • MM: Need to discuss it at the same time as the compressed texture format extension.
  • JG+CW: Disagree.
  • JG: WebGPU is not a mature API without compressed texture format support. So we can’t punt them. However heuristic based compression is novel so we should punt.
  • MM: I disagree. There are real benefits to both.
  • CW: We don’t disagree that there are real benefits, but as Jeff said, WebGPU is not a useable, mature API without support for compressed texture formats
  • CW: More compressed texture discussion at F2F.

Uniform/storage texel buffers?

  • Skip.

F2F Planning

  • Tues afternoon + Wednesday
  • CW: Most of us going to Khronos F2F
  • CW: Have dinner at Khronos Plenary?
  • Answer was yes.
  • CW: I’ll send an email with logistics.
  • YH: Will there be dial in?
  • CW: Yes, we’ll have the Google Hangouts Meet (or whatever it is called these days).
Clone this wiki locally