glam v0.33.6 breaks rust-gpu's Matrix4x3 layout, causing certain raytracing-related intrinsics to miscompile into invalid spirv. See compiletest ray_query_get_intersection_object_to_world_khr breaking after glam update, as seen in this CI of PR #630
PR bitshifter/glam-rs#786 changed the definition of Vec3A to make it bytemuck::Pod:
#[repr(align(16))]
#[repr(C)]
#[cfg_attr(target_arch = "spirv", rust_gpu::vector::v1)]
pub struct Vec3A {
pub x: f32,
pub y: f32,
pub z: f32,
+ _w: f32,
}So from rust-gpu's perspective, this is now a vector with 4 floats instead of 3 floats. Which should also have further implications beyond just Matrix4x3, like we should be seeing all kinds of Vec3A usage suddenly think they're Vec4s. But I haven't seen any other changes in our compiletests.
PR #646 adjusts Matrix4x3 to use Vec3 instead of Vec3A. The layout of that special type is screwed up anyway, so we don't really care about it changing.
will update this description as I go
glam v0.33.6 breaks rust-gpu's
Matrix4x3layout, causing certain raytracing-related intrinsics to miscompile into invalid spirv. See compiletestray_query_get_intersection_object_to_world_khrbreaking after glam update, as seen in this CI of PR #630PR bitshifter/glam-rs#786 changed the definition of
Vec3Ato make itbytemuck::Pod:#[repr(align(16))] #[repr(C)] #[cfg_attr(target_arch = "spirv", rust_gpu::vector::v1)] pub struct Vec3A { pub x: f32, pub y: f32, pub z: f32, + _w: f32, }So from rust-gpu's perspective, this is now a vector with 4 floats instead of 3 floats. Which should also have further implications beyond just
Matrix4x3, like we should be seeing all kinds ofVec3Ausage suddenly think they'reVec4s. But I haven't seen any other changes in our compiletests.PR #646 adjusts
Matrix4x3to useVec3instead ofVec3A. The layout of that special type is screwed up anyway, so we don't really care about it changing.will update this description as I go