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

Comienza en crates/rustc_codegen_spirv/src/builder/builder_methods.rs alrededor de la generación referenciada de OpConvertFToS y, después, compara la referencia de Rust y la especificación de SPIR-V enlazadas en el issue. Determina el comportamiento predeterminado previsto o el comportamiento controlable por el usuario para la conversión de flotantes a enteros y valídalo con el ejemplo proporcionado. Se considera terminado cuando la semántica elegida está acordada explícitamente y el comportamiento de CPU/GPU está alineado o se puede configurar deliberadamente.