Add countLeadingZeros

[evahop]

Adds countLeadingZeros from gfx-rs/wgpu#4402

For negative expressions return 0, otherwise return 31 - msb.

This assumes findUMsb, findMSB, and firstbithigh all return an index from the lsb,
but I don't have the means to verify this is actually the case atm.

[teoxoy]

Behavior looks good!
But the GLSL and HLSL backends write the expr multiple times which won't always work.

The expression needs to either be baked or the function needs to be polyfilled.
I'd go with baking for now since we have the mechanism already implemented for GLSL.

naga/src/back/glsl/mod.rs

Lines 1767 to 1768 in c7d0215

	} else if self.need_bake_expressions.contains(&handle) {
	Some(format!("{}{}", back::BAKE_PREFIX, handle.index()))

I feel like polyfilling would be a nicer solution but we'd ideally make the transition all at once.
See also #2123 for more details.

[evahop]

The expression needs to either be baked or the function needs to be polyfilled. I'd go with baking for now since we have the mechanism already implemented for GLSL.

Okay, I see the issue.
I'm just now noticing FindMSB also has a minimum requirement of 400 while the README.md pegs it at 330+.
Would it be preferable to replace it with something along the lines of es.math.clz32.js? This is also the case for findLSB both of which are currently being used elsewhere.

[evahop]

I meant uints in the last commit but I assume it's going to get squashed either way.
Otherwise that should do it, it should address the issue in #2123 (comment),
and I can follow up with a commit if the findMSB/findLSB need replacing.

[evahop]

Had some downtime so just went ahead and did it for the scope of this PR and won’t likely have time to address it later.

[teoxoy]

CI is failing due to recently updated clippy lints, we landed a fix in #2229; so we have to rebase this PR.

I'm just now noticing FindMSB also has a minimum requirement of 400 while the README.md pegs it at 330+.
Would it be preferable to replace it with something along the lines of es.math.clz32.js? This is also the case for findLSB both of which are currently being used elsewhere.

Thank you for considering this!
We don't seem to polyfill findMSB/findLSB in the direct translation.
We could introduce a new fn and check if the version supports those functions and if not polyfill; then use it for both, the direct translation and countLeadingZeros.
Similar to how we do it for fma:

naga/src/back/glsl/mod.rs

Line 2901 in c7d0215

if self.options.version.supports_fma_function() {

Had some downtime so just went ahead and did it for the scope of this PR and won’t likely have time to address it later.

Let me know if you can address the comments above. If not, I can rebase it and we can open a new issue for the other change.

Looks great otherwise!

[evahop]

I see what you’re pointing out. You can rebase and open another issue. I tried applying the same polyfill to findMSB just now, using the ((clz + 1) % 33) … method on the msl backend, and I’m not sure if its producing the expected behavior, I need to mess with it some more. If I’m not mistaken, seems like clz will always produce a 0 for negative numbers, while findMSB returns an index of the first set 0

[teoxoy]

If I’m not mistaken, seems like clz will always produce a 0 for negative numbers, while findMSB returns an index of the first set 0.

This sounds correct, so the msl polyfill is not correct for negative numbers.