struct Rav1dTaskContext::scratch: Make into zerocopy-based "unions"

[randomPoison]

Makes the various scratch unions into safe "union"s by using zerocopy.

[kkysen]

A couple of overarching points:

• Do we need to lazy initialize things? Can we just initialize them where we need to?
• I'm still thinking about this, but these initializations as a different variant are quite expensive given the size of these structs and arrays (up to 250 KB). It might be better to do a zerocopy cast to different variants instead. In essence, a safe union where the variants are safely transmutable to each other. Then the backing scratch buffer becomes just a [u8; N] aligned to whatever alignment we need.

[randomPoison]

@kkysen I've reworked this to use zerocopy to make the scratch data into safe "unions", with most of the structs containing appropriately-sized byte buffers that are then cast to the needed data type using FromBytes::mut_from_prefix. I ended up not needing to impl any of the zerocopy traits for BitDepthUnion or AlignN, which is for the best because I suspect those would have been a source of UB. Please give it another review when you have a chance.

[kkysen]

Generally looks really good now. I just had a few comments.

[kkysen]

Do we want to return the 30 padding bytes? Provenance-wise, I think that's safer.

[randomPoison]

What do you mean by "return the 30 padding bytes"? Return the full size of the buffer, including padding, from buf_mut? I don't think doing that would be a good idea, the buffer had a specific length for a reason and we shouldn't be changing the size of it. There's also code using this data that assumes a length of 257.

[kkysen]

So we start with a [u8; 257 * 2 + 30]. Say we then return a &[u16; 257] for bpc16, and then asm accesses 30 bytes after that. That violates stacked borrows since it expands provenance. So to do things correctly with no UB, we need to keep that 30 bytes there the whole time. Is it worth it? I'm not sure, but it technically is UB.

[randomPoison]

Given that the original code was written to be a buffer of 257 elements without any padding at the end, I think it's reasonably safe to assume that the asm won't read beyond that. If it is, the behavior isn't going to be any different than it was in the original C.

[kkysen]

Given that the original code was written to be a buffer of 257 elements without any padding at the end, I think it's reasonably safe to assume that the asm won't read beyond that

I'm pretty sure the padding is there since asm is using SIMD instructions that over-read.

If it is, the behavior isn't going to be any different than it was in the original C.

C has different UB rules than Rust, and doing it in Rust with all raw pointers is also different than creating that intermediate slice.

[kkysen]

I still think that 30 padding bytes is technically UB, but it's okay to merge. I think we should take a further look at it at some point.