[Migrated] Support Option<T>
Opened this issue · 8 comments
Issue automatically imported from old repo: EmbarkStudios/rust-gpu#234
Old labels: t: bug,c: rustc_codegen_spirv,s: qptr may fix
Originally creatd by fu5ha on 2020-11-12T18:04:17Z
Expected Behaviour
Be able to use Option<Mat4>
Example & Steps To Reproduce
Use an Option that contains a value larger than some threshold
pub fn from_mat4(t: &Mat4) -> Option<Self> {
let (scale3, rotation, translation) = t.to_scale_rotation_translation();
if scale3.abs_diff_eq(Vec3::splat(1.0), 1e-4) {
Some(Self::from_rotation_translation(rotation, translation))
} else {
None
}
}
Comment from MarijnS95 (CONTRIBUTOR) on 2020-11-12T22:17:38Z
@termhn This error is identical to the one I intended to create an issue for following EmbarkStudios/rust-gpu#220 (comment), thanks for waking me up 😄
error: Cannot cast between pointer types
--> examples/shaders/sky-shader/src/lib.rs:156:19
|
156 | let sun_pos = const_vec3!([0.0, 75.0, -1000.0]);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: from: *{Function} [u8; 16]
= note: to: *{Function} [f32; 3]
= note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)Cannot cast between pointer types comes from zombie_bitcast_ptr.
The const_vec3 macro (and the f32x4 in your error likely means a const_quat! somewhere) use a union to perform casting. Using it on a primitive like [ui]64 is fine (for lack of [iu]128):
union Foo {
a: u64,
b: i64,
}
let x = unsafe { Foo { a: 1 }.b };This compiles without errors. Turning it into a statically sized array (internal representation in glam), no matter how small surfaces this error:
union Foo {
a: [u8; 1],
b: [i8; 1],
}
let x = unsafe { Foo { a: [1] }.b };error: Cannot cast between pointer types
--> examples/shaders/sky-shader/src/lib.rs:163:22
|
163 | let x = unsafe { Foo { a: [1] }.b };
| ^^^^^^^^^^^^^^^^
|
= note: from: *{Function} [u8; 1]
= note: to: *{Function} [i8; 1]Bonus, attempting to "get" a [iu]128 by using a tuple throws something completely different:
union Foo {
a: (u64, u64),
b: (i64, u64),
}
let x = unsafe { Foo { a: (1, 1) }.b };error: Cannot use this pointer directly, it must be dereferenced first
--> examples/shaders/sky-shader/src/lib.rs:163:22
|
163 | let x = unsafe { Foo { a: (1, 1) }.b };
| ^^^^^^^^^^^^^^^^^^^
error: aborting due to previous errorI'm not enough of a compiler engineer to take the plunge and understand + solve this issue (despite that I assume these statically sized arrays should be taken and reinterpreted "by value") but this mini-investigation might give someone else a head-start 😁
Comment from khyperia (CONTRIBUTOR) on 2020-11-13T08:51:23Z
Unfortunately these are far from different errors, they merely fail with the same compiler error message. Enums we can fix via the approach that RLSL took and generate an "exploded" data representation, where each enum kind is stored as separate field (and disallow interaction with host-rust). This will remove the need to bitcast pointers, fixing the compiler error reported here.
However, arbitrary bitcasting between pointers is impossible to do on the GPU, and will never be supported.
Comment from XAMPPRocky (MEMBER) on 2021-01-07T11:46:18Z
Updated title to reflect that this currently affects all Option<T>'s for example this provides the same error.
pub fn foo () -> Option<u8> { Some(5u8) }error: Cannot cast between pointer types
--> examples/shaders/sky-shader/src/lib.rs:40:31
|
40 | pub fn foo () -> Option<u8> { Some(5u8) }
| ^^^^^^^^^
|
= note: from: *{Function} struct core::option::Option<u8> { u8, u8 }
= note: to: *{Function} struct core::option::Option<u8>::Some { 0: u8 }
Comment from XAMPPRocky (MEMBER) on 2021-02-15T15:50:32Z
Adding this as another thing that needs options, which is num_traits::Float::powi, it uses an .unwrap in it's code when converting to usize. https://github.com/rust-num/num-traits/blob/319623616822ab8d77ba0422dc63ed4ff5b9a809/src/float.rs#L684
#[test]
fn powi() {
val(r#"
fn powi(x: f32) -> f32 {
x.powi(80)
}
#[allow(unused_attributes)]
#[spirv(fragment)]
pub fn main() {
assert!(powi(1.0) == 80.0);
}
"#);
}Error
error: Cannot cast between pointer types
--> /Users/.cargo/registry/src/github.com-1ecc6299db9ec823/num-traits-0.2.14/src/cast.rs:278:1
|
278 | impl_to_primitive_uint!(u32);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: from: *{Function} struct core::option::Option<usize> { u32, u32 }
= note: to: *{Function} struct core::option::Option<usize>::Some { 0: u32 }
= note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
error: Cannot cast between pointer types
--> /Users/.rustup/toolchains/nightly-2020-12-28-x86_64-apple-darwin/lib/rustlib/src/rust/library/core/src/option.rs:385:18
|
385 | Some(val) => val,
| ^^^
|
= note: from: *{Function} struct core::option::Option<usize> { u32, u32 }
= note: to: *{Function} struct core::option::Option<usize>::Some { 0: u32 }
Comment from DavidTruby on 2021-09-11T22:59:44Z
This issue also seems to prevent num-complex compiling in shader crates. I'd be interested in having a deeper look at this if it's possible to fix. I have a couple of questions though.
Firstly, why is it that pointer bitcasts aren't possible on the GPU? I worked (briefly) on the GPU OpenMP backend in clang and am pretty sure I remember that we allowed arbitrary reinterpret_casts on there.
Secondly, specifically what I'm seeing is pointer casts like from: *[struct &str { *[u8], u32 }; 6] to *[struct &str { *[u8], u32 }]. I'm not really a rust expert, but why are these even considered pointer casts at all from the GPU's perspective? Aren't these just casts from fixed to "variable" length arrays? The CPU architectures I'm familiar with have no concept of fixed length arrays anyway (as far as I'm aware) so surely this cast is a no-op by that point even on a CPU?
If anyone can point me in the right direction here I'd be happy to take a look!
Comment from khyperia (CONTRIBUTOR) on 2021-09-13T07:35:01Z
(meta note: I believe you discussed those questions on discord with eddyb after you posted this, so I won't answer again here - let me know if I'm mistaken and I can give answers here)
Comment from Lucky4Luuk on 2023-04-20T08:34:00Z
Any updates on this? I'd love to be able to use Option in shaders.