Conversation
|
|
||
| Embed a copy of |source| from |sourceOffset| to |size| into the {{GPUCommandEncoder}}. | ||
| Encode a command into the {{GPUCommandEncoder}} that copies |size| bytes of data from embedded copy to the |destinationOffset| of another {{GPUBuffer}} |destination|. | ||
| |size| must be less than or equal to 65536 bytes. |
There was a problem hiding this comment.
Possibly implementable with Metal's set{,Vertex,Fragment}Bytes which are limited to (or recommended to be under?) 4k.
There was a problem hiding this comment.
setBytes is only transient. It's basically for setting uniforms OpenGL-style.
There was a problem hiding this comment.
You're right. I guess those are only useful for a push-constant-like feature.
|
Apart from being closer to Vulkan, I'm not sure what the improvement is compared to
|
|
That approach is very similar to #154, which we discussed at length at San Diego F2F. The points about returning |
|
The API we have at the moment for WebGPU has a nice property of increasing in complexity as you want to extract the most of it, but works good enough if you do the simple things.
Also Also
Due to its streaming and "instantaneous" nature, |
| For example, updating model-view and projection matrices before or interleaved with rendering of a scene. | ||
| When these uploads are small, it's viable to inline the update data into the command buffer. | ||
| This does require more copies than other upload paths, but for small data sizes this overhead is negligible. | ||
| Implementations are expected to warn against using this for medium-to-large buffer updates. (e.g. >64k) |
There was a problem hiding this comment.
Where do we draw the line of the "suboptimal" behavior? I.e. what if an application updates 64k of different multiple buffers? what if it updates 64k of data of the same buffer? does it matter if the updated range is the same? etc
| For example, updating model-view and projection matrices before or interleaved with rendering of a scene. | ||
| When these uploads are small, it's viable to inline the update data into the command buffer. | ||
| This does require more copies than other upload paths, but for small data sizes this overhead is negligible. | ||
| Implementations are expected to warn against using this for medium-to-large buffer updates. (e.g. >64k) |
There was a problem hiding this comment.
The problem with warnings here is that this size could easily be unknown at build/development time. Say, the developer loads a mesh and updates some vertices using this function, and everything works on their machine. But then later an user loads a bigger mesh, and not only they get a warning spam, it's also animating suspiciously slow, because of how many copies the data needs to go through (i.e. 4 on this path, as estimated by @Kangz).
|
|
||
| In Vulkan, this is similar to |vkCmdUpdateBuffer|. | ||
| In D3D12, implementations can leverage |ID3D12GraphicsCommandList2::WriteBufferImmediate|. | ||
| Metal might use |makeBuffer(bytesNoCopy:length:options:deallocator:)| around some section of shared command buffer serialization memory. |
There was a problem hiding this comment.
I wonder how this would work in practice. It requires page-size alignment for both the pointer and the size, and also:
The existing memory allocation must be covered by a single VM region, typically allocated with vm_allocate or mmap. Memory allocated by malloc is specifically disallowed.
|
Closing now that #708 is landed |
|
We may still want this later. |
|
Tentatively closing as part of triaging milestone 2. If we get back to trying to update buffers on the queue timeline, we can revive this PR. |
Preview | Diff