WebGPURenderer: Read/Write Only Storage Buffer Creation

[cmhhelgeson]

Re-do of pull request #28400 without pinging multiple people from an accidental merge commit.

[RenaudRohlinger]

As mentioned in #28400 I think it would be more interesting to add a more general API with an access mode property instead.

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 storage,read-write would be the default for Storage Buffers (read-write access), read-only would be your newly introduced access mode and we can add in the same PR or a separate one read-only and read-write access to StorageTexture too.

[sunag]

What will we use write-only buffering for?

[cmhhelgeson]

As mentioned in #28400 I think it would be more interesting to add a more general API with an access mode property instead.

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 storage,read-write would be the default for Storage Buffers (read-write access), read-only would be your newly introduced access mode and we can add in the same PR or a separate one read-only and read-write access to StorageTexture too.

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.

[RenaudRohlinger]

What will we use write-only buffering for?

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 readOnly attribute, but I am concerned about the upcoming PR that introduces writeOnly. How will it be integrated? Additionally, for GPUStorageTexture, an access property would be more logical. cc @sunag

but it would align the code more closely with the relevant WGSL and WebGPU syntax.

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. (storageTexture: { access: 'write-only' } } for example)

[sunag]

I think we could follow this names bellow and the change for setAccess() in this PR. For other PR we can certainly do checks at the AssignNode, *ElementNode and any other TSL level.

export const storageReadOnly = ( value, type, count ) => storage( value, type, count ).setAccess( 'read' );
export const storageWriteOnly = ( value, type, count ) => storage( value, type, count ).setAccess( 'write' );

[cmhhelgeson]

I think we could follow this names bellow and the change for setAccess() in this PR. For other PR we can certainly do checks at the AssignNode, *ElementNode and any other TSL level.

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.

[cmhhelgeson]

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.

[cmhhelgeson]

@sunag Is there anything else I should do for this pull request in terms of formatting and syntax?