feat(🚧): add fence for shared texture memory#375
Conversation
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
I like it a lot, thank you for the PR. In my case I was flip flopping between 1. enabling people to do everything in JS using the SharedTextureMemory API or 2. pushing the importExternalTexture API. And I realized that it's both 1. and 2. Item 1 makes a lot of sense considering that this is React Native. You want to give full access/control over the native APIs. And I have a list of items there and this PR is part of that list, so again thank you for doing this. And item 2 is also unavoidable anyway for zero-copy YUV texture support on Android. |
pepperoni505
changed the title
wcandillon
left a comment
wcandillon
left a comment
There was a problem hiding this comment.
Looks good! I am just confused about the two changes I commented on.
| label: "test-frame", | ||
| }); | ||
| const texture = memory.createTexture(); | ||
| if (!memory.beginAccess(texture, true)) { |
There was a problem hiding this comment.
does this change make sense? Can you explain me?
| frame.release(); | ||
| return null; | ||
| } | ||
| memory.beginAccess(texture, true); |
There was a problem hiding this comment.
does this change make sense? Can you explain me?
Co-authored-by: William Candillon <wcandillon@gmail.com>
2 participants
Closes #369
Adds
GPUSharedFence, exposing Dawn's shared-fence primitives soGPUSharedTextureMemorycan be synchronized across queues/APIs. Until nowbeginAccess/endAccessonly took the no-fence path, which is fine for single-producer still frames, but it can't safely coordinate an external producer and a GPU consumer on different queues (e.g. a video/camera surface being written while Dawn samples it).