Compute a collatz sequence in the compute example

[DJMcNab]

These changes were made at the behest of @raphlinus.

The expected values can be found at https://oeis.org/A006877

Should we rename the example to compute_collatz?

I'm also planning on integrating the overflow detection from wgpu. (Edit: Done - unfortunately can't use checked_add and friends (yet?))

We also should insert the timing queries into this example, since wgpu now supports them.

[DJMcNab]

I will change the SpirvBuilder invocation to only use the vulkan version which they need - i.e. make only the compute example use vulkan 1.1. (Edit: Done)

I'm also not sure whether the dummy bind group still needs to exist, and ideally I'd remove the new unsafe code (i.e. using flat_map core::Array::IntoIter on u32::to_ne_bytes().) (Edit: Done)

Additionally, now that multiple things are async it might be worth threading that through further. (Edit: I've made a custom block_on function instead - it's a bit ugly but it gets the job done.

I should also create a CPU runner, because this shader is simple enough that the naïve implementation of that would work fine (it seems to me that the CPU runner could live in examples/shaders/compute/main.rs, but I'm not certain). Putting it in with the existing CPU runner would be fine, although the dependencies thereof are a bit heavy weight, since this runner doesn't need any capabilities apart from stdout access. (Edit: It's probably fine for this to wait - given that the sky shader CPU runner works, that's probably enough evidence that the build could build for CPU).

I found the change/run/execute cycle to be excruciatingly slow - am I missing some tricks I can use to get it faster? For reference, my current invocation is:

$ cargo run -p example-runner-wgpu -- --shader Compute

[raphlinus]

It's odd to me that this requires Vulkan 1.1. Playing with it, it seems it needs the VK_KHR_storage_buffer_storage_class extension, probably because the SPV refers to StorageBuffer. If you look at the GLSL version and the spv it compiles to, it looks pretty different - it's a BufferBlock.

I'm not super expert on this, but it seems like it's using more advanced features than it really needs to, which might hurt compatibility.

[khyperia]

I forget if we documented this anywhere, but a decision made in rust-gpu is to be pretty opinionated in that we should only support non-deprecated SPIR-V features, and be pretty "modern" in that sense (for now at least - perhaps when we have more fundamentals in place, we can look at supporting older things). BufferBlock is explicitly deprecated, replaced with Block/StorageBuffer, and so we don't plan on supporting BufferBlock right now, and so require vulkan 1.1+ for this.

[raphlinus]

@khyperia Good to know thanks! I've been spending a lot of time looking at compatibility recently because I'm trying to target phones, and very much appreciate the load of dealing with older stuff. Having a clean, well documented line is a good strategy.

[DJMcNab]

I think that the only things left are:

• Potentially renaming the example to compute_collatz, which I think is probably not needed
• Adding timing queries and then looking at Compute a collatz sequence in the compute example #623 (comment) (edit: Done in dd6110b)

[DJMcNab]

If these performance counters are done correctly, then we should also add them to the other example, closing the saga of #259

I have also only now realised that I have inadvertently duplicated #360. I was just trying to show @raphlinus that rust-gpu can be used to make compute shaders 😅