iframe-proxy

Kangz · 2026-06-23T15:59:49Z

Removes texture.pin/unpin and all associated logic.
Adds pinning in the "Alternatives considered" section.
Move setResourceTable to GPUComputePassEncoder/GPURenderPassDescriptor so there are at most one resource table per usage scope.
Detail isShaderVisible, the validation performed by the shader when accessing a resource table slot, along with implementation notes.
Add setResourceUsage and a detailed explanation of the use for it.

Fixes gpuweb#5378 - Removes texture.pin/unpin and all associated logic. - Adds pinning in the "Alternatives considered" section. - Move setResourceTable to GPUComputePassEncoder/GPURenderPassDescriptor so there are at most one resource table per usage scope. - Detail isShaderVisible, the validation performed by the shader when accessing a resource table slot, along with implementation notes. - Add setResourceUsage and a detailed explanation of the use for it.

github-actions · 2026-06-23T16:06:11Z

alan-baker

Some minor typos.

alan-baker · 2026-06-23T19:24:49Z

-When a resource is unpinned it can be used with any usages specified at creation, but when pinned only the single pinned usage is allowed.
-This proposal contains WGSL-side validation for the accesses which is augmented to also check that resources are pinned in addition to being present and of the correct type.
-This way unpinned resources are not accessible via resource tables, ensuring that correct validation and barriers are done when resources are pinned.
+WebGPU's guarantees that there are no data races must be uphelp when resource tables are used, without resource tables, this is done via usage scope validation.


Suggested change

WebGPU's guarantees that there are no data races must be uphelp when resource tables are used, without resource tables, this is done via usage scope validation.

WebGPU's guarantees that there are no data races must be upheld when resource tables are used, without resource tables, this is done via usage scope validation.

alan-baker · 2026-06-23T19:26:33Z

+Other helper methods not exposed to the IDL are also defined (`isReadable`, `isWritable`).
+However in practice shaders cannot call CPU functions and instead implementations will maintain per-slot metadata updated before each usage scope (that shaders will query for validation).
+
+The validation prevents using a slot of the associated full resource has any subresource with a conflicting usage in the usage scope.


Suggested change

The validation prevents using a slot of the associated full resource has any subresource with a conflicting usage in the usage scope.

The validation prevents using a slot if the associated full resource has any subresource with a conflicting usage in the usage scope.

alan-baker · 2026-06-23T19:32:02Z

+So we need to prevent data races, so authors need to explicitly choose which usage is accessible through the resource table.
+
+Even if only readonly resources are in the resource table, they are useful to let the implementation know which resources are intended as accessible during an operation.
+Otherwise implementation have to assume that any resource in the resource table can be accessed, causing pessimizing synchronization and memory barriers during execution.


Suggested change

Otherwise implementation have to assume that any resource in the resource table can be accessed, causing pessimizing synchronization and memory barriers during execution.

Otherwise implementations have to assume that any resource in the resource table can be accessed, causing pessimizing synchronization and memory barriers during execution.

jasmine-nominal · 2026-06-24T14:47:22Z

 A new `GPUResourceTable` concept is added to WebGPU that represents a variable-size, sparse and (totally or partially) heterogenous set of bindings.
 The resource table can be set in the `GPUCommandEncoder` state and used in shaders to retrieve the resource of a given type at a given index in the currently set `GPUResourceTable`.
 Bindings in the `GPUResourceTable` can be updated over time as new resources become needed, or previous resources get no longer in use.
 To efficiently implement the validation, memory barrier and other similar kind of tracking needed for `GPUResourceTable`, the mutable resources contained in them must be "pinned" to a certain usage which prevents other kinds of accesses to them.


This sentence mentions pinned still.

jasmine-nominal · 2026-06-24T15:08:27Z

Where is barrierAndMakeVisible defined in the proposal?

Kangz · 2026-06-24T15:10:55Z

Where is barrierAndMakeVisible defined in the proposal?

It's not part of the proposal, it's pseudo code of what the implementation would do internally. I'll make that more clear.

jasmine-nominal · 2026-06-24T15:18:11Z

Is GPUResourceTableUsage.writable read_write? or just writable only?
How would end-users switch between a sampled usage and a storage texture usage of the same texture? GPUResourceTable.update with a new binding?

Kangz · 2026-06-24T15:22:49Z

TBD exactly what the GPUResourceTableUsage are, maybe writable should be storage_read_write instead, but the intent is definitely to allow for switching between sampled, and read-write storage usage using setResourceUsage.

Kangz · 2026-06-25T14:45:57Z

GPU Web WG 2026-06-24 Atlantic-time

CW: Hoping committee agrees to merge and continue iterating, but it’s also fine to just do a Q&A in this meeting, bindless is always mind-bending
CW: In terms of diff, this removes pinning from the proposal, pinning is gone as a concept. What remains is the table part: you can put resources in and remove them, and set tables on encoders. There can only be one resource table per usage scope; previously we’d had setResourceTable in the binding commands mixin, now you can only set it on the compute pass encoder or the render pass descriptor. So each usage scope has only one resource table.
CW: Validation steps are adjusted accordingly.
CW: Pinning language is deleted.
CW: Instead of pinning, the visibility of resources in the table is done automatically. We’ll say that when a shader tries to access a slot, it’s as if there’s a callback to the CPU to decide whether the slot is allowed or not. In practice, implementations will push metadata to the GPU, but the spec will describe things more simply.
CW: When a shader accesses a slot, it does so with a specific WGSL type, and within a particular usage scope, so we validate that. If there’s a conflict between two different subresources [...]
CW: We check that the resource is not destroyed, and then consult the usage of that resource stored in the resource table. It’s basically a memory barrier or usage bit that is part of the resource table for each resource in the table, that says how the shader is allowed to access the resource. It can say, not allowed, or readonly (if there is no writing elsewhere in the scope), or writable (if it’s not read-only elsewhere in the usage scope). This is the automatic visibility algorithm. It’s specified as a callback to the CPU, but we can implement it differently.
CW: The proposal includes implementation suggestions. So it’s part of the code all implementations have for processing usage scopes.
CW: Why do we have “none” alongside “readonly” and “writable”? There are two reasons to have resource usage state. The first onn is you don’t want to allow both “sampled” and “storage” for textures. The other is that with bindful, the implementation has full knowledge of what is statically used. However in bindless the implementation loses a lot of information. Consider rendering to various shadow maps. The implementation needs to make visibility decisions, and that costs a lot of barriers. But if the application is able to promise not to use a resource, by setting its usage to “none”, then the implementation can issue fewer barriers. The implementation gets more semantic information about what the application wants to do, and we can optimize better. We have setResourceUsage, which you can set on the encoder, or on the device timeline.
CW: API is just a sketch, we’ll refine it.
CW: So that’s the automatic visibility proposal. Exact interface and semantics will change, based on implementation experience and users’ experience. But I think this is the best way forward we’ve seen so far.
CW: What’s missing is what happens when people use writable resources in the table within multiple scope. Maybe we'll need to add explicit storage barriers.
RC: As you’re modifying the resources in the resource table, what timeline do those additions and subtractions occur on?
CW: That aspect hasn’t changed. The resource table is a big array, put this resource at this slot. That happens on the device timeline, in between queue submits. If you want to overwrite a resource in the table, you can’t just do that. You have to free up the slot, and then in the future when WebGPU can guarantee that the slot is no longer being used by the GPU, then you can overwrite it.
RC: So it makes a snapshot of the resource table on submit?
CW: No - if we snapshotted, we’d need to make a copy. We have one persistent object. You’re forbidden from changing items in the resource table while it’s being used by command buffers in flight.
CW: wgpu’s Connor believes this latest proposal is “annoying but implementable”.
AB: Can I use the resource usage to say, I’m not going to use this resource at all? Can I put a resource back into an automatic tracking state?
CW: The current idea, at least, is that usage is persistent on the resource table, even across submits.
KN: Is the automatic state the same as writable?
CW: It starts in the read-only state. People are just going to put every texture they’ve got into the table, so we want read-only to be the default, to make that easier. You should have to opt into writability.
JB, MW: We’re okay with merging this change into the proposal.

alan-baker reviewed Jun 23, 2026

View reviewed changes

jasmine-nominal reviewed Jun 24, 2026

View reviewed changes

Sunbelt Computer Software

PL/B Language Development and Support

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

bindless.md: Replace pinning with automatic visibility#6308

bindless.md: Replace pinning with automatic visibility#6308
Kangz wants to merge 1 commit into
gpuweb:mainfrom
Kangz:replace-pinning

Kangz commented Jun 23, 2026

Uh oh!

github-actions Bot commented Jun 23, 2026

Uh oh!

alan-baker left a comment

Uh oh!

alan-baker Jun 23, 2026

Uh oh!

alan-baker Jun 23, 2026

Uh oh!

alan-baker Jun 23, 2026

Uh oh!

jasmine-nominal Jun 24, 2026

Uh oh!

jasmine-nominal commented Jun 24, 2026

Uh oh!

Kangz commented Jun 24, 2026

Uh oh!

jasmine-nominal commented Jun 24, 2026

Uh oh!

Kangz commented Jun 24, 2026

Uh oh!

Kangz commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

	WebGPU's guarantees that there are no data races must be uphelp when resource tables are used, without resource tables, this is done via usage scope validation.
	WebGPU's guarantees that there are no data races must be upheld when resource tables are used, without resource tables, this is done via usage scope validation.

	The validation prevents using a slot of the associated full resource has any subresource with a conflicting usage in the usage scope.
	The validation prevents using a slot if the associated full resource has any subresource with a conflicting usage in the usage scope.

	Otherwise implementation have to assume that any resource in the resource table can be accessed, causing pessimizing synchronization and memory barriers during execution.
	Otherwise implementations have to assume that any resource in the resource table can be accessed, causing pessimizing synchronization and memory barriers during execution.

Sunbelt Computer Software

PL/B Language Development and Support

Uh oh!

Conversation

Kangz commented Jun 23, 2026

Uh oh!

github-actions Bot commented Jun 23, 2026

Uh oh!

alan-baker left a comment

Choose a reason for hiding this comment

Uh oh!

alan-baker Jun 23, 2026

Choose a reason for hiding this comment

Uh oh!

alan-baker Jun 23, 2026

Choose a reason for hiding this comment

Uh oh!

alan-baker Jun 23, 2026

Choose a reason for hiding this comment

Uh oh!

jasmine-nominal Jun 24, 2026

Choose a reason for hiding this comment

Uh oh!

jasmine-nominal commented Jun 24, 2026

Uh oh!

Kangz commented Jun 24, 2026

Uh oh!

jasmine-nominal commented Jun 24, 2026

Uh oh!

Kangz commented Jun 24, 2026

Uh oh!

Kangz commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants