Repository navigation
Problem with the default queue #1977
Description
@pythonesque pointed out that having the default queue on the device is causing a few issues.
First, it introduces a circular dependency. Device points to a queue, but a queue is owned by the device. Resources, owned by a device, submitted in command buffers to a queue, are held alive by the queue for the duration of GPU use of them. So "Resource <- Queue <- Device" and "Resource -> Device".
Arguably, this is an implementation issue. Generally, however, designing a structure of classes without (or with minimum) circular dependencies could be considered a better design.
Secondly, in the multi-queue world, it would harm the ability of users to control what's happening on the queues. Since the queue argument isn't participating directly, it's used implicitly, and it makes it more difficult to reason about the queue loads.
The list of operations that currently depend on the default queue:
- command encoder creation - Associate command encoding with a queue #1278
- unmapping of buffers created with "mappedAtCreation". A queue needs to do a copy operation from the staging area into the GPU memory of such buffer.
- maybe something is missing in this list?
Activity
kainino0x commentedon Jul 21, 2021
Depending on how we model mapping wrt queue transfers, I'm not sure whether this is a problem. FWIW I think it also applies to mapAsync?
kvark commentedon Jul 21, 2021
No, I don't think so. Mapping buffers generally involves copying shared memory around on CPU (into mapped native staging buffers), it doesn't involve any actual queue operations.
For this, we'd need to know the queue at
unmap()time. @pythonesque suggested to add a queue parameter there.Maybe on D3D12 and a fraction of Vulkan devices, but doesn't look portable.
Kangz commentedon Jul 22, 2021
In one of the multi queue proposals: #1073 I suggested a
GPUUnmapOptionsoptional argument tounmap. While we don't need to add it now in the spec because it would be backwards compatible, I think we should have something inwebgpu.hto prepare for when we need options.litherum commentedon Aug 2, 2021
GPUUnmapOptionsmakes sense to me.Kangz commentedon Dec 15, 2021
We'll remember to do something about this when we do multiqueue.