TSL: Slow compilation time

[SeeleyLogan]

Description

Description

Large TSL shaders appear to have slow compilation time, as mentioned by Ben Houston

This pull request is creating 40 TSL shaders on init, which takes ~8 seconds to compile after first render call.
(Ryzen 9 5900X - RTX 4060 Ti)

The compilation time is certainly a combination of TSL converting into WGSL and WGSL being compiled for the GPU. How much of the blocking is caused by TSL? How much by WebGPU? Could we get timings for that?

Reproduction steps

1. Create a TSL shader with a large* number of nodes
2. Create an array of objects and apply the shader to them

*refer to pull request

Code

TSL Shader: Line 7 - Line 255
Array of objects: Line 162 - Line 173

Live example

Githack

Screenshots

No response

Version

r179

Device

Desktop

Browser

No response

OS

No response

[cmhhelgeson]

Just did a hasty test by adding a numBindGroupLayoutCreations property to WebGPUBindingUtils. It seems like the program is creating 120 bind group layouts for this example, which seems a bit excessive. Ideally, even if the BindGroup for each mesh is different (different uniform buffers, mesh data, etc), the bindGroupLayout should be cached and reused.

UPDATE: A bind group layout with these parameters is created 35 times

[{"binding":0,"visibility":2,"buffer":{}},{"binding":1,"visibility":1,"buffer":{}}]

New bind groups and bind group layouts are also created every time the user first moves the camera.

Think this might have to do with a faulty bindGroup.bindingsReference? For some reason, logging the bindGroup.bindingsReference before the createBindingsLayout call returns a BindGroup class in the console rather than the expected array of Bindings.

[cmhhelgeson]

Seems like this code in NodeBuilderState passes in a BindGroup instead of Bindings for bindingsReference, which could explain the bindings caching issue.

The JSDoc of BindGroup indicates that the only valid type for a BindGroup's bindingReference value is an array of Bindings, so either the JSDoc is incorrect or this code should be modified.

// instanceGroup is type BindGroup
// this.bindings is type BindGroup[]


createBindings() {
	const bindings = [];
	for ( const instanceGroup of this.bindings ) {
		const shared = instanceGroup.bindings[ 0 ].groupNode.shared; // All bindings in the group must have the same groupNode.
		if ( shared !== true ) {
			const bindingsGroup = new BindGroup( instanceGroup.name, [], instanceGroup.index, instanceGroup.bindings );
			bindings.push( bindingsGroup );
			for ( const instanceBinding of instanceGroup.bindings ) {
				bindingsGroup.bindings.push( instanceBinding.clone() );
			}
		} else {
			bindings.push( instanceGroup );
		}
	}
	return bindings;
}

[cmhhelgeson]

Just for comparison sake, I replaced the existing caching in WebGPUBindingUtils with a simple Map of the stringified layout entires to a bindGroupLayout. The number of generated bind group layouts went down from around 120 to a maximum of 11 after camera motion.

[cmhhelgeson]

Just out of curiosity, would it be acceptable for now to stringify the bindGroupLayout entries as a solve for bindGroupLayout caching, then figure out a more optimal way to cache the bind group layouts down the road? We'd essentially be performing the same amount of work as the current approach sans 100+ calls to device.createBindGroupLayout (bindGroupLayoutDescriptorCalls + deviceLayoutCalls - deviceLayoutCalls amount of work).

I'm also having trouble squaring my results with the results found in #29158. That suggests to me that something may have changed with the bindingsArray, or more unique bindingsArray references are being passed than before.

[PoseidonEnergy]

would it be acceptable for now to stringify the bindGroupLayout entries as a solve for bindGroupLayout caching, then figure out a more optimal way to cache the bind group layouts down the road?

This sounds like a good start--have you been able to implement this quick fix? If so, do you have a fork available that I can test?

I'm also interested in minimizing TSL shader recompilation.

[Mugen87]

Current progress: #31675 (comment)

[cmhhelgeson]

would it be acceptable for now to stringify the bindGroupLayout entries as a solve for bindGroupLayout caching, then figure out a more optimal way to cache the bind group layouts down the road?

This sounds like a good start--have you been able to implement this quick fix? If so, do you have a fork available that I can test?

I'm also interested in minimizing TSL shader recompilation.

Yes in #31682.

I've drafted it for now as I wanted to get approval before finishing/merging it in as it's more of a quick/lazy fix that still requires generating at least the bind group layout entries for each binding. The performance benefits are also minimal, even if we are generating a fraction of the bind group layouts we were before (4 vs around 100 for something like webgpu_materials_toon). The primary benefit of the PR is generating a best-case-scenario number of bind group layouts for each scene, so future PRs with more robust caching and optimization have an accurate target to aim for.

The minimal performance gain from changing the caching system also makes me hesitate to describe my PR as a true fix. #29158 says that the WeakMap reduces layouts from 400 to 6 in webgpu_materials_toon, but I've logged 100+ invocations of createBindGroupLayout for that example. To me this suggests that I'm still missing something.

[cmhhelgeson]