Rust and SPIR-V float rounding semantics are different

There is a footgun when trying to share code between CPU and GPU. Rust and SPIR-V have different semantics when rounding floats:

Rust:

• Rust’s built-in conversion using as truncates the fractional part, effectively rounding toward zero.
• For example, 1743028479.999... becomes 1743028479.
  Rust Language Reference

SPIR-V:

• SPIR-V uses the OpConvertFToS instruction for converting floating-point values to integers. Here is where it happens in rust-gpu.
• It rounds using round-to-nearest-even, which can round 1743028479.999... up to 1743028480.
  SPIR-V Specification

fn main() {
    let x = 1743028480i32;
    let y = (x as f64) * (1.0 / (i32::MAX as f64));

    // Without explicit rounding, differs:
    let without = (y * (i32::MAX as f64)) as i32;
    // Using `trunc()` forces Rust’s truncation:
    let with = (y * (i32::MAX as f64)).trunc() as i32;

    println!("x = {}. Without rounding = {}. With trunc() = {}.", x, without, with);
}

I'm not sure which should be the default. If it is Rust's we'll want to polyfill on the spir-v side. Might be good to have this user controlled in any case.

Originally posted by @LegNeato in https://github.com/Rust-GPU/rust-gpu/discussions/228#discussioncomment-12784276

Beginne bei crates/rustc_codegen_spirv/src/builder/builder_methods.rs rund um die referenzierte Erzeugung von OpConvertFToS und vergleiche anschließend die im Issue verlinkte Rust-Referenz und SPIR-V-Spezifikation. Ermittle das beabsichtigte Standardverhalten oder das vom Benutzer steuerbare Verhalten für die Konvertierung von Gleitkommazahlen in Ganzzahlen und validiere es anhand des bereitgestellten Beispiels. Als erledigt gilt die Aufgabe, wenn die gewählte Semantik ausdrücklich vereinbart ist und das CPU-/GPU-Verhalten angeglichen oder bewusst konfigurierbar gemacht wurde.