Add read-only and write-only storage textures as new binding types #532

Jiawei-Shao · 2020-01-02T06:44:53Z

This patch adds "readonly-storage-texture" and "writeonly-storage-texture" as new enums of
GPUBindingType.

Jiawei-Shao · 2020-01-02T06:51:40Z

The following table lists the supports of the texture operations on every WebGPU texture binding type.
For simplicity purposes, we are using SPIR-V operations in this table.

WebGPU Binding Type	Operations with Sampler(including OpImageFetch)	OpImageRead	OpImageWrite
sampled-texture	Supported	Not supported	Not supported
storage-texture	Not Supported	Not Supported*	Supported
readonly-storage-texture	Not Supported	Supported	Not Supported

*Currently we cannot support read-write textures in WebGPU core SPEC because this feature requires Metal 1.2.

The following table lists the correspondences of the WebGPU texture binding types in D3D12, Metal and Vulkan.

WebGPU Binding Type	D3D12(HLSL)	D3D12(descriptor range type)	Metal Shading Language	Vulkan(SPIR-V)	Vulkan (VkDescriptorType)
sampled-texture	Texture2D	D3D12_DESCRIPTOR_RANGE_TYPE_SRV	access::sample	Sampled == 1	VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE
storage-texture	RWTexture2D	D3D12_DESCRIPTOR_RANGE_TYPE_UAV	access::write*	Sampled == 2	VK_DESCRIPTOR_TYPE_STORAGE_IMAGE
readonly-storage-texture	Texture2D	D3D12_DESCRIPTOR_RANGE_TYPE_SRV	access::read	Sampled == 2	VK_DESCRIPTOR_TYPE_STORAGE_IMAGE

*"access::read_write" requires Metal 1.2 so we don't include it in this table.

The following table lists the required texture usage for every binding type.

WebGPU Binding Type	WebGPU Texture Usage
sampled-texture	SAMPLED
storage-texture	STORAGE
readonly-storage-texture	READONLY_STORAGE

The following table lists the correspondences of the WebGPU texture usages in D3D12, Metal and Vulkan

WebGPU Binding Type	D3D12	Metal	Vulkan
sampled-texture		MTLTextureUsageShaderRead	VK_IMAGE_USAGE_SAMPLED_BIT
storage-texture	D3D12_RESOURCE_FLAG_ALLOW_UNORDERED_ACCESS	MTLTextureUsageShaderWrite	VK_IMAGE_USAGE_STORAGE_BIT
readonly-storage-texture		MTLTextureUsageShaderRead	VK_IMAGE_USAGE_STORAGE_BIT

Kangz · 2020-01-06T15:36:45Z

Thanks for the investigation and comparison tables. It seems that the motivation for readonly-storage-texture is because in Vulkan they are declared with a different usage flag, and a different binding type.

An alternative is to not add this binding type. If we look at shader operation sampled-texture can do a superset of what readonly-storage-texture so maybe when implementing WebGPU on Vulkan we could just make all storage textures also sampled and use OpTexeFetch instead of OpImageRead.

I'm not sure which one is best: adding the readonly usage adds a bit more complexity to the API, but the alternative adds more usage flags in Vulkan implementations and might make shaders use a different HW path.

*"access::read_write" requires Metal 1.2 so we don't include it in this table.

Note that we want storage-texture to be usable as readonly texture in a shader. The constraint Metal gives us here is that the texture must be declared as "read only" or "write only" in the shader.

Kangz · 2020-01-13T11:06:25Z

spec/index.bs

    const GPUTextureUsageFlags SAMPLED           = 0x04;
    const GPUTextureUsageFlags STORAGE           = 0x08;
-    const GPUTextureUsageFlags OUTPUT_ATTACHMENT = 0x10;
+    const GPUTextureUsageFlags READONLY_STORAGE  = 0x10;


I don't think this usage is needed: see #541

wait, you don't see that this is needed?
confused because you are pointing to the issue saying that it is needed :)

Following discussions in the meeting, can we land this PR and discuss readonly usage flags for buffers and textures in a separate PR?

Editors concluded to slightly prefer STORAGE_READ name, other than that we can land

If we have STORAGE_READ should we not have STORAGE = 0x18?

If we decide there's no chance of adding a STORAGE_WRITE later (TBD), I'd prefer READONLY_STORAGE.

AH right, thanks for the clarification. My take was that STORAGE_READ is just more consistent with other usage names and future-proof for the case where we want to have STORAGE_WRITE. I didn't realize you have a strong preference to READONLY_STORAGE, this would mean we have to resolve the write-only conversation first before proceeding with this one...

To clarify, mainly would prefer READONLY_STORAGE if we end up with "readonly-storage-binding", for consistency.

Jiawei-Shao · 2020-01-17T05:14:13Z

I find another issue with the Image Format declaration in OpTypeImage in Vulkan.
According to Vulkan SPEC:

If shaderStorageImageReadWithoutFormat is not enabled and an OpTypeImage has “Image Format” operand of Unknown, any variables created with the given type must be decorated with NonReadable.
If shaderStorageImageWriteWithoutFormat is not enabled and an OpTypeImage has “Image Format” operand of Unknown, any variables created with the given type must be decorated with NonWritable.
So in my mind it means we must declare Image Format for OpTypeImage, or we cannot call either ImageRead or ImageWrite.

Vulkan SPEC also defines the SPIR-V image formats compatibility rules with the Vulkan image formats. The SPEC says, the SPIR-V Image Format (the Image Format of OpTypeImage) must be compatible with the image view’s format when shaderStorageImageReadWithoutFormat and shaderStorageImageWriteWithoutFormat features are not enabled. The image format compatibility rules are also listed in the SPEC.

Shall we add the "storage texture format" member in GPUBindGroupLayoutBinding for this requirement on Vulkan?

kvark · 2020-01-18T18:15:10Z

@Jiawei-Shao the table in Vulkan spec that you list to has only 1:1 correspondence between the Vulkan formats and SPIR-V formats. So are you basically suggesting that we add the texture format to the bind group layout? On the plus side, that would allow us to validate at pipeline creation time that the shader is using the proper format to access an image. However, it would put a restriction on the user (unable to use the same layout for different formats and shaders) that is otherwise unnecessary.

Notably, bind group layout already has textureComponentType, which, if I'm not mistaken, was introduced in #384 for a very similar reason It appears to me that both the component type and the format would need to be considered together. To make this clear: both textureComponentType and suggested "storage texture format" allow validating the program - binding compatibility at the pipeline creation, as opposed to the draw call time (when we know all the bound groups and the active pipeline).

(I can't make my mind on this yet, so leaving this comment without a proposal)

Jiawei-Shao · 2020-01-19T01:43:37Z

@kvark yes I am suggesting that we add the texture format to the bind group layout because I find Vulkan requires the format of the image view be compatible with the related OpTypeImage object in the shader so we should validate it in WebGPU implementation.

Another choice can be that we just do the validation with the information fetched from the declarations in the shader directly. Note that if we take this strategy everywhere in WebGPU SPEC, I don't think we need textureComponentType any longer.

kvark · 2020-01-19T21:37:27Z

If we start asking the shader, we'll essentially sabotage the whole idea behind the BindGroupLayout. The point of it is declaring the contract between resources and shaders, up-front. Once you have the contract, you use it for both sides, and it guarantees that nothing bad happens at binding time within a pass. If we start querying the component type and texture format from the shader, we may end up with a bind group (created from the same bind group layout) to be incompatible with a pipeline.

kainino0x · 2020-01-22T23:29:53Z

Interestingly, desktop support for shaderStorageImageWriteWithoutFormat is nearly 100% (though only recent android gpus (e.g. adreno 5xx+)), while shaderStorageImageReadWithoutFormat is much lower (65% of gpuinfo.org reports on desktop, lower on mobile).

magcius · 2020-01-22T23:36:16Z

The D3D equivalent to shaderStorageImageWriteWithoutFormat is required for D3D11 support where they're known as "typed buffers" (or "texture buffers" in legacy parlance), so that explains why it's 100% penetration on desktop.

Jiawei-Shao · 2020-02-14T02:44:21Z

Updated this PR to follow the latest decision:

no "STORAGE_READ" texture usage
"readonly" and "writeonly" binding type
"texture format" in bindings

kvark

Thank you!

This patch adds "readonly-storage-texture" as a new enum of GPUBindingType and "READONLY_STORAGE" as a new enum of GPUTextureUsage. The following table lists the supports of the texture operations on every WebGPU texture binding type. For simplicity purposes, we are using SPIR-V operations in this table. |WebGPU Binding Type |Operations with Sampler(including OpImageFetch)|OpImageRead |OpImageWrite | |------------------------|-----------------------------------------------|--------------|-------------| |sampled-texture |Supported |Not supported |Not supported| |storage-texture |Not Supported |Not Supported*|Supported | |readonly-storage-texture|Not Supported |Supported |Not Supported| *Currently we cannot support read-write textures in WebGPU core SPEC because this feature requires Metal 1.2. The following table lists the correspondences of the WebGPU texture binding types in D3D12, Metal and Vulkan. |WebGPU Binding Type |D3D12(HLSL) |D3D12(descriptor range type) | Metal |Vulkan(SPIR-V)|Vulkan (VkDescriptorType) | |------------------------|------------|-------------------------------|--------------|--------------|--------------------------------| |sampled-texture |Texture2D |D3D12_DESCRIPTOR_RANGE_TYPE_SRV|access::sample|Sampled == 1 |VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE| |storage-texture |RWTexture2D |D3D12_DESCRIPTOR_RANGE_TYPE_UAV|access::write*|Sampled == 2 |VK_DESCRIPTOR_TYPE_STORAGE_IMAGE| |readonly-storage-texture|Texture2D |D3D12_DESCRIPTOR_RANGE_TYPE_SRV|access::read |Sampled == 2 |VK_DESCRIPTOR_TYPE_STORAGE_IMAGE| *"access::read_write" requires Metal 1.2 so we don't include it in this table. The following table lists the required texture usage for every binding type. |WebGPU Binding Type |WebGPU Texture Usage| |------------------------|--------------------| |sampled-texture |SAMPLED | |storage-texture |STORAGE | |readonly-storage-texture|READONLY_STORAGE | The following table lists the correspondences of the WebGPU texture usages in D3D12, Metal and Vulkan |WebGPU Binding Type |D3D12 |Metal |Vulkan | |------------------------|-------------------------------------------|--------------------------|--------------------------| |sampled-texture | |MTLTextureUsageShaderRead |VK_IMAGE_USAGE_SAMPLED_BIT| |storage-texture |D3D12_RESOURCE_FLAG_ALLOW_UNORDERED_ACCESS |MTLTextureUsageShaderWrite|VK_IMAGE_USAGE_STORAGE_BIT| |readonly-storage-texture| |MTLTextureUsageShaderRead |VK_IMAGE_USAGE_STORAGE_BIT|

… type

Jiawei-Shao · 2020-02-20T01:39:45Z

PTAL, thanks!

JusSn · 2020-02-20T23:44:37Z

spec/index.bs

    GPUTextureComponentType textureComponentType = "float";
    boolean multisampled = false;
    boolean hasDynamicOffset = false;
+    GPUTextureFormat storageTextureFormat = {};


Is it an error if storageTextureFormat doesn't match textureComponentType?

In fact textureComponentType is not needed when storageTextureFormat is specified. Should I mention it clearly here?

Also should I add all the texture formats that are supported as writable storage texture here?

Unfortunately it's not possible right now for textureComponentType to have no value. If it is not specified, then it will be "float".

We could remove that default (so it defaults to "not set") and put spec text that says "if it's a sampled texture and textureComponentType is not set, textureComponentType defaults to "float"".

We really want to define an algebraic data type (/tagged union) here, but we have to work within the bounds of WebIDL. I think that's probably the best way to do it, unless WebIDL allows GPUBindGroupLayoutDescriptor to take bindings as a sequence of (GPUBindGroupSampledTextureBinding or GPUBindGroupStorageTextureBinding or ...) (which would be indistinguishable at the JS level except by the value of type). I don't think it does.

Would be good to require the user to set textureComponentType explicitly for the sampled textures and storageTextureFormat for the storage ones. Defaulting to "float" wasn't something I was happy about :)

OK with me!

In the latest PR, I've removed the default value of textureComponentType. I have also renamed textureComponentType to sampledTextureComponentType to indicate it is only related to sampled textures.

kainino0x · 2020-02-21T06:07:16Z

spec/index.bs

    GPUTextureComponentType textureComponentType = "float";
    boolean multisampled = false;
    boolean hasDynamicOffset = false;
+    GPUTextureFormat storageTextureFormat = {};


The default value {} is only for dictionaries. You don't need to provide a default value; then the default value will be "not set" (undefined).

kainino0x · 2020-02-21T06:14:05Z

spec/index.bs

    GPUTextureComponentType textureComponentType = "float";
    boolean multisampled = false;
    boolean hasDynamicOffset = false;
+    GPUTextureFormat storageTextureFormat = {};


Unfortunately it's not possible right now for textureComponentType to have no value. If it is not specified, then it will be "float".

We could remove that default (so it defaults to "not set") and put spec text that says "if it's a sampled texture and textureComponentType is not set, textureComponentType defaults to "float"".

We really want to define an algebraic data type (/tagged union) here, but we have to work within the bounds of WebIDL. I think that's probably the best way to do it, unless WebIDL allows GPUBindGroupLayoutDescriptor to take bindings as a sequence of (GPUBindGroupSampledTextureBinding or GPUBindGroupStorageTextureBinding or ...) (which would be indistinguishable at the JS level except by the value of type). I don't think it does.

Kangz · 2020-02-24T16:43:04Z

I'd like to discuss the textureComponentType changes in more detail. Can we rollback changes there so we can land this PR and start another PR or issue to discuss changes to textureComponentType with the group and whether the default should be removed?

This reverts commit 0e6f4af.

Jiawei-Shao · 2020-02-25T06:03:00Z

@Kangz I've reverted all the changes with textureComponentType in this PR. PTAL, thanks!

Jiawei-Shao · 2020-02-27T04:30:45Z

@JusSn PTAL, thanks!

…puweb#532) * Add read-only storage textures as new binding type and texture usage This patch adds "readonly-storage-texture" as a new enum of GPUBindingType and "READONLY_STORAGE" as a new enum of GPUTextureUsage. The following table lists the supports of the texture operations on every WebGPU texture binding type. For simplicity purposes, we are using SPIR-V operations in this table. |WebGPU Binding Type |Operations with Sampler(including OpImageFetch)|OpImageRead |OpImageWrite | |------------------------|-----------------------------------------------|--------------|-------------| |sampled-texture |Supported |Not supported |Not supported| |storage-texture |Not Supported |Not Supported*|Supported | |readonly-storage-texture|Not Supported |Supported |Not Supported| *Currently we cannot support read-write textures in WebGPU core SPEC because this feature requires Metal 1.2. The following table lists the correspondences of the WebGPU texture binding types in D3D12, Metal and Vulkan. |WebGPU Binding Type |D3D12(HLSL) |D3D12(descriptor range type) | Metal |Vulkan(SPIR-V)|Vulkan (VkDescriptorType) | |------------------------|------------|-------------------------------|--------------|--------------|--------------------------------| |sampled-texture |Texture2D |D3D12_DESCRIPTOR_RANGE_TYPE_SRV|access::sample|Sampled == 1 |VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE| |storage-texture |RWTexture2D |D3D12_DESCRIPTOR_RANGE_TYPE_UAV|access::write*|Sampled == 2 |VK_DESCRIPTOR_TYPE_STORAGE_IMAGE| |readonly-storage-texture|Texture2D |D3D12_DESCRIPTOR_RANGE_TYPE_SRV|access::read |Sampled == 2 |VK_DESCRIPTOR_TYPE_STORAGE_IMAGE| *"access::read_write" requires Metal 1.2 so we don't include it in this table. The following table lists the required texture usage for every binding type. |WebGPU Binding Type |WebGPU Texture Usage| |------------------------|--------------------| |sampled-texture |SAMPLED | |storage-texture |STORAGE | |readonly-storage-texture|READONLY_STORAGE | The following table lists the correspondences of the WebGPU texture usages in D3D12, Metal and Vulkan |WebGPU Binding Type |D3D12 |Metal |Vulkan | |------------------------|-------------------------------------------|--------------------------|--------------------------| |sampled-texture | |MTLTextureUsageShaderRead |VK_IMAGE_USAGE_SAMPLED_BIT| |storage-texture |D3D12_RESOURCE_FLAG_ALLOW_UNORDERED_ACCESS |MTLTextureUsageShaderWrite|VK_IMAGE_USAGE_STORAGE_BIT| |readonly-storage-texture| |MTLTextureUsageShaderRead |VK_IMAGE_USAGE_STORAGE_BIT| * Use "STORAGE_READ" * Add storageTextureFormat * Only keep "STORAGE" usage and add "writeonly-storage-texture" binding type * Remove all GPUBindingType/storage-texture and update SPEC * Add missing check on GPUBindGroupBinding/storageTextureFormat * Rename textureComponentType to sampledTextureComponentType * Revert "Rename textureComponentType to sampledTextureComponentType" This reverts commit 0e6f4af. * Remove the default value of storageTextureFormat

JusSn approved these changes Jan 3, 2020

View reviewed changes

kvark mentioned this pull request Jan 12, 2020

STORAGE_READ usages for buffers and textures #541

Closed

Kangz reviewed Jan 13, 2020

View reviewed changes

Kangz mentioned this pull request Jan 16, 2020

Add GPUPipelineBase.getBindGroupLayout. #543

Merged

kvark approved these changes Feb 14, 2020

View reviewed changes

Jiawei-Shao added 5 commits February 14, 2020 13:31

Use "STORAGE_READ"

9f250d6

Add storageTextureFormat

356c32f

Only keep "STORAGE" usage and add "writeonly-storage-texture" binding…

3d5daf3

… type

Remove all GPUBindingType/storage-texture and update SPEC

ed425b9

Jiawei-Shao force-pushed the add-readonly-storage-texture branch from 08ff387 to ed425b9 Compare February 14, 2020 05:37

Kangz approved these changes Feb 14, 2020

View reviewed changes

Add missing check on GPUBindGroupBinding/storageTextureFormat

b2f7663

Jiawei-Shao force-pushed the add-readonly-storage-texture branch from 4efd1c7 to b2f7663 Compare February 14, 2020 05:55

Jiawei-Shao changed the title ~~Add read-only storage textures as new binding type and texture usage~~ Add read-only and write-only storage textures as new binding type Feb 18, 2020

Jiawei-Shao changed the title ~~Add read-only and write-only storage textures as new binding type~~ Add read-only and write-only storage textures as new binding types Feb 18, 2020

kvark requested a review from JusSn February 20, 2020 14:45

JusSn reviewed Feb 20, 2020

View reviewed changes

kainino0x reviewed Feb 21, 2020

View reviewed changes

Rename textureComponentType to sampledTextureComponentType

0e6f4af

Jiawei-Shao added 2 commits February 25, 2020 13:53

Revert "Rename textureComponentType to sampledTextureComponentType"

72d02c1

This reverts commit 0e6f4af.

Remove the default value of storageTextureFormat

fb6f38c

Kangz approved these changes Feb 25, 2020

View reviewed changes

kvark approved these changes Feb 25, 2020

View reviewed changes

kvark requested a review from JusSn March 2, 2020 20:51

JusSn merged commit 31005ac into gpuweb:master Mar 2, 2020

kvark mentioned this pull request Mar 11, 2020

[meta-0.5] Update the API to match upstream gfx-rs/wgpu-rs#196

Closed

13 tasks

kdashg mentioned this pull request Jun 24, 2020

[wgsl] Textures #573

Closed

ben-clayton pushed a commit to ben-clayton/gpuweb that referenced this pull request Sep 6, 2022

roll types, fixes for Iterable color/extent/origin (gpuweb#532)

01ef1c7

kainino0x mentioned this pull request Oct 17, 2023

Remove the need to hard-code texel format for texture_storage_2d in shaders #4298

Open

Add read-only and write-only storage textures as new binding types #532

Add read-only and write-only storage textures as new binding types #532

Uh oh!

Conversation

Jiawei-Shao commented Jan 2, 2020 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Jiawei-Shao commented Jan 2, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kangz commented Jan 6, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Jiawei-Shao commented Jan 17, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kvark commented Jan 18, 2020

Uh oh!

Jiawei-Shao commented Jan 19, 2020

Uh oh!

kvark commented Jan 19, 2020

Uh oh!

kainino0x commented Jan 22, 2020

Uh oh!

magcius commented Jan 22, 2020

Uh oh!

Jiawei-Shao commented Feb 14, 2020

Uh oh!

kvark left a comment

Choose a reason for hiding this comment

Uh oh!

Jiawei-Shao commented Feb 20, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kangz commented Feb 24, 2020

Uh oh!

Jiawei-Shao commented Feb 25, 2020

Uh oh!

Jiawei-Shao commented Feb 27, 2020

Uh oh!

Uh oh!

Jiawei-Shao commented Jan 2, 2020 •

edited by pr-preview bot

Loading

Jiawei-Shao commented Jan 2, 2020 •

edited

Loading

Jiawei-Shao commented Jan 17, 2020 •

edited

Loading