Examples shouldn't use bytemuck to cast out of a get_mapped_range() BufferView

[Oberdiah]

Description
Currently, the examples use bytemuck::cast_slice() to cast u8 slices returned in the BufferView from get_mapped_range() to slices of larger types (u64s, u32s etc.), but this call panics if the underlying slice is not aligned to the larger type.

wgpu/examples/src/timestamp_queries/mod.rs

Line 169 in 26398ea

bytemuck::cast_slice(&timestamp_view).to_vec()

wgpu/examples/src/repeated_compute/mod.rs

Line 123 in 26398ea

local_buffer.copy_from_slice(bytemuck::cast_slice(&view));

At present, wgpu makes no guarantees about the alignment of get_mapped_range(), and in certain situations does in fact return a slice that is not u64-aligned.

Until wgpu can guarantee alignment here, it would be nice to remove this footgun from the examples, as currently code that works there can mysteriously break when put into a larger project.

Additional Information
I had previously been using bytemuck::cast_slice() without issue in 0.18.x but upon updating to 22.x the alignment shifted. It only seems to have happened on the Vulkan backend.

[BGR360]

Just curious as an onlooker: what would be the correct thing to do here?

[Wumpf]

only deal with raw bytes and do memcopies as needed

[cwfitzgerald]

We should be guarenteing 16byte alignment - this is something webgpu-native discussed at length previously. I think there's another issue about it too.

[Wumpf]

This one? webgpu-native/webgpu-headers#180

I agree, but until there's any movement there, our examples are wrong as-is