vello_shaders: Guard inactive clip_leaf lanes

[gugutu]

This guards inactive clip_leaf shader lanes when the dispatch size is rounded up past config.n_clip.

load_clip_path already returns a sentinel value for lanes where global_id.x >= config.n_clip, but those lanes could still participate in the prefix/search logic and reach shared-memory link reads. In particular, search_link can produce values derived from inactive lane state, and the previous select(link - 1, sh_link[link], link >= 0) form still exposes a potentially invalid sh_link[link] expression to the shader compiler.

On Android/Vulkan, this was observed to make scenes involving clip layers fail to render, producing a black frame. A reduced WGPU reproduction showed the same pattern: even when a value is logically guarded, keeping a potentially invalid indexed read inside select can still be enough for the shader/backend to misbehave.

This change makes inactive lanes contribute a neutral Bic, skips predecessor lookup for them, and replaces the select with explicit control flow before reading sh_link[link].

This avoids invalid accesses from inactive lanes while preserving the behavior for active clip entries. With this change applied, the affected Android/Vulkan clipping scene renders correctly again.

Verified locally with:

• cargo fmt --all --check
• cargo check -p vello_shaders
• cargo test -p vello_shaders

[waywardmonkeys]

I think this is correct, but would appreciate a bit more review from someone more familiar with this aspect of shaders.

[waywardmonkeys]

I think it would be useful to have a comment here about this avoiding a materialization of the index operands on some backends.

[gugutu]

Makes sense, I added a comment explaining why this uses explicit control flow instead of select.

[b0nes164]

I'll take a look tonight

[b0nes164]

LGTM, modulo some nits. Do you have a reproducer test case and device for this issue?

[b0nes164]

Nit: This is unnecessary. If a variable declaration has no initializer, the variable is default initialized

[b0nes164]

This should be removed.

This is already guarded inside load_clip_path which results in bic = (1, 0). Since the scan is ascending, this has no effect on the scan results for valid threads. In search_link the search is exclusively backwards, and so again, valid threads will always search through valid data.

Since we already guarding indexing into sh_link by guarding search_link, this provides no additional protection.

[gugutu]

Thanks, updated! I removed the redundant bic initialization and the extra guard around the bic assignment.

[gugutu]

LGTM, modulo some nits. Do you have a reproducer test case and device for this issue?

Yes, I made a small Android repro here:

https://github.com/gugutu/vello-clip-repro-android

It reproduces on my Xiaomi 23127PN0CC / houji device with Adreno 750 on Android 16. I included the device/driver details and the observed failure modes in the README. With the amended fix branch, the same repro runs through the 120-frame burst cleanly on that device.

[waywardmonkeys]

@gugutu Just curious how you found this. Seems like it must've been a bit of an adventure.

[gugutu]

@gugutu Just curious how you found this. Seems like it must've been a bit of an adventure.

It was a bit of an adventure, though honestly not too bad — I had some AI help with the debugging. :)

I hit this while experimenting with a small Rust Android app using Vello directly. The app would consistently black-screen and freeze on my device. With the AI helping me narrow things down, I reduced it to a tiny clipped scene, added some validation scopes, and eventually traced it to this clip shader path.