-
-
Notifications
You must be signed in to change notification settings - Fork 35.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebGPURenderer: Read/Write Only Storage Buffer Creation #28435
WebGPURenderer: Read/Write Only Storage Buffer Creation #28435
Conversation
As mentioned in #28400 I think it would be more interesting to add a more general API with an Storage Buffers are not the only type of ressources in WebGPU with an access property. For example GPUStorageTexture since Chrome r124 now includes this feature too: enum GPUStorageTextureAccess {
"write-only",
"read-only",
"read-write",
}; So |
What will we use write-only buffering for? |
I can change the property in StorageBufferNode from readOnly to access, and assign GPUBufferBindingTypes to this new access property. For the case of storage buffers, I'm not sure how useful this would be given that there are currently only two relevant access types for storage buffers ('read-only' and 'read-write'), but it would align the code more closely with the relevant WGSL and WebGPU syntax. Regarding texture access, I think that might be better tackled in a separate pull request. I'm personally not aware of all the considerations that would have to be made for texture access, but I think a good place to start would be providing similar functionality to StorageBufferNode that allows the user to explicitly specify that they would like the texture to be accessed in a read-only context. Perhaps we could also separate out the functionality from within textureStore that allows the user to pass a storage texture to a wgslFunction into its own function as well. |
Write-only buffering can be used to reduce bandwidth in deferred rendering, generate procedural content such as textures and landscapes, and for intermediate storage in GPGPU tasks. We can continue using the
As mentioned here by @cmhhelgeson, I believe that this approach is more intuitive for developers since it matches what is sent to the shader and the correct binding properties. ( |
I think we could follow this names bellow and the change for export const storageReadOnly = ( value, type, count ) => storage( value, type, count ).setAccess( 'read' );
export const storageWriteOnly = ( value, type, count ) => storage( value, type, count ).setAccess( 'write' ); |
I'll change the function in StorageBufferNode to setAccess, but is this comment referring to storage buffers or storage textures? According to the WebGPU Working Draft, storage buffers can not be created with the write-only modifier, only storage textures, so the name storageWriteOnly wouldn't be accurate to the storage buffers access restrictions. EDIT: Although I suppose if write-only storage buffers do get implemented in a future pr, it wouldn't hurt to have the ability to specify it. |
There's currently a discontinuity in the way I've architected this code versus the rest of the WebGPU code. I've currently set up the access property to take a value that corresponds to the WGSL syntax rather than the WebGPU syntax, with translation between WGSL shader syntax to WebGPU binding syntax occurring within WebGPUBindingUtils.ts. When I get the chance, I'll re-edit the code to have it better match the existing architecture. |
…lied storageReadOnly to examples as reference in appropriate locations
…ilder, added considerations for hypothetical write-only buffer access mode mentioned in PR conversation, added readOnly and writeOnly commands for creating a storageObject
…mhhelgeson/three.js into webgpu_readonly_storage_branch
@sunag Is there anything else I should do for this pull request in terms of formatting and syntax? |
Re-do of pull request #28400 without pinging multiple people from an accidental merge commit.