SharedTextureMemory: expose fences on beginAccess/endAccess?

[pepperoni505]

The GPUSharedTextureMemory header notes that fence-based sync isn't exposed yet:

react-native-webgpu/packages/webgpu/cpp/rnwgpu/api/GPUSharedTextureMemory.h

Lines 34 to 37 in 0ccc35a

	// texture's content is preserved (or not). Callers that want fence-based
	// synchronization should pass fences via beginAccess descriptor (not yet
	// exposed - we currently take the implicit/no-fence path that matches the
	// most common RN use cases: still images, single-producer video frames).

We have a use case that needs it: we import an app-owned IOSurface / AHardwareBuffer via importSharedTextureMemory, render into it with the WebGPU device, then composite that surface into a separate GPU pass (Mapbox) on a different queue, so we need the MTLSharedEvent Dawn exports from EndAccess on iOS, and the sync-fd on Android to protect against texture reads before rendering is finished.

I've prototyped this and am happy to open a PR, but wanted your take on the API shape first. The current sketch:

• device.importSharedFence({ type, handle }) → GPUSharedFence (with .export())
• beginAccess(texture, initialized, fences?, signaledValues?) - wait fences
• endAccess(texture) → { fences, signaledValues, ... } - surfaces the fences (this changes the current boolean return)

Does this match what you had in mind, or would you prefer a different shape?

[wcandillon]

@pepperoni505 I'm very close to merge importExternalTexture (readonly) at #372 would that help with your use case or not really?

[wcandillon]

I might actually walk back to importExternalTexture approach for now and indeed maybe give full control to people via importSharedTextureMemory instead. While I think there is a path where could "polyfill" completely the browser's importExternalTexture, it might not be ready yet.

[pepperoni505]

Hey @wcandillon! #372 doesn't cover our case - we need to render into the shared surface, and then have a separate context sample it. Giving full control via importSharedTextureMemory with fences exposed would be ideal for us!

[wcandillon]

nice! I'm currently looking into it (I've been flip flopping some ideas today but now getting a clearer picture). In your use-case you would have a way to expose a native fence via JS? am I getting this right?

[pepperoni505]

yep! We'd want the native fence Dawn produces from endAccess surfaced to JS as a handle, which we forward into our own native side to wait on before sampling.

[wcandillon]

That makes a lot of sense, would definitely be open to a PR there.