WebGPU PipelineLayout question

[SetoKaiba]

How to set PipelineLayout to auto like the original js WebGPU does? Thanks.
@kainino0x

[kainino0x]

Setting the pipeline layout to nullptr/NULL/0 should be equivalent to using "auto" in JavaScript.

emscripten/system/include/webgpu/webgpu.h

Line 1080 in 08bb133

WGPUPipelineLayout layout; // nullable

However Emscripten has not been updated to translate 0 into "auto" so right now you have to rely on the deprecated behavior in Chromium (assuming you're targeting Chromium). We plan to get Emscripten updated before removing the deprecated path from Chromium.

[SetoKaiba]

[kainino0x]

The automatic layout algorithm will only include entries in the bind group layout if they're "statically used" in the entry point (i.e. are mentioned in the shader code for the entry point or any function it calls). Is that the case for your shader?

[kainino0x]

Yes, the codebase is the same for all Chromium-based browsers as long as they have WebGPU support (Chrome, Chromium, Edge, etc.)

[kainino0x]

And yes, that shader statically uses the texture and sampler. I assume you are using pipeline.getBindGroupLayout to create the bind group?

It seems possible something is not getting passed through correctly to the JS API. Consider using the dev tools debugger to check the calls to createShaderModule, createRenderPipeline, createBindGroup to make sure they're getting the correct inputs.

[SetoKaiba]

[kainino0x]

The release in Emscripten is a little hidden. It is generated here:

emscripten/src/library_webgpu.js

Line 38 in 1105368

s += ' WebGPU.mgr' + type + '.release(id);\n'

which generates a C binding which calls mgrXXX.release. The C++ bindings call that C binding from their destructors.

However that's not relevant to GPUExternalTexture because it doesn't have a "mgr". In your code, the GPUExternalTexture isn't kept as a reference at all, so it should get GCed at any time after the function returns. Internally, it's held onto by the GPUBindGroup, but once the texture expires (which happens automatically), it should just be a lightweight shell with no heavy memory behind it.

[kainino0x]

GPUBindGroup doesn't hold a reference to the GPUExternalTexture object, in Emscripten or in the JS WebGPU API. The reference is internal (deep in the GPU process in Chromium). So the GPUExternalTexture JS object becomes unreachable the moment your my_bind_group function returns and can get GCed anytime after that.

[kainino0x]

Please file a bug. It may be the case that your code is holding GPUExternalTexture objects alive, which would be a bug in your code, but nonetheless this should not be causing 100GB of memory leak in Chromium's GPU process.

[SetoKaiba]

[[active_imports]], of type list
A list of all imported textures which have not yet been closed. The items in list are checked during each animation frame to determine whether to close them.

https://gpuweb.github.io/gpuweb/#gpu-external-texture
I know the problem now. I should use emscripten_set_main_loop(frame, 0, true); instead of emscripten_set_main_loop(frame, 60, true);
But anyway, should there be a way to release GPUExternalTexture instead of dependency on requestAnimationFrame?

[kainino0x]

For reference for future readers, the bug is filed here: https://crbug.com/1353621