bug: Integer division generates floating point division WGSL

[lorents]

The following function silently casts the arguments to f32 in the generated WGSL, resulting in loss of precision:

function integerDiv(a: number, b: number){
	"use gpu";
	return d.u32(a) / d.u32(b);
}

I expected it to work like this (working) function:

const integerDiv = tgpu.fn([d.u32, d.u32], d.u32)`(l: u32, r: u32) -> u32 {
	return l / r;
}`;

TypeGPU version: 0.10.2

[aleksanderkatan]

This is the current behavior because we strive to make TypeGPU functions behave similarly when executed in JS and when run on the GPU. Since JS will always perform a floating-point division here, we do the same in the generated code (docs).

The intended way of resolving this is to wrap the division result d.u32 or d.i32 (e.g. d.u32(d.u32(a) / d.u32(b))), or to use WGSL implementations. We're working on a solution that would be more intuitive. If the lint plugin happens to release before we address this, there already is a rule highlighting this issue.

[lorents]

As far as I can tell d.u32(d.u32(a) / d.u32(b)) still does floating point division in the current version, and there is no way at all to do an integer division without inlining WGSL.

[iwoplaza]

As far as I can tell d.u32(d.u32(a) / d.u32(b)) still does floating point division in the current version, and there is no way at all to do an integer division without inlining WGSL.

That's true, d.u32(d.u32(a) / d.u32(b)) currently casts to f32 and back to u32 leading to a loss in precision. We've had a plan for a while now to make use of the fact that when transforming d.u32(a) / d.u32(b) we know that it's eventually going to be cast to a d.u32, so instead of generating u32(f32(a) / f32(b)), we can generate a / b if both operands are already u32 or u32(a / b) if one of them is a signed integer or abstract int.

I wanted to avoid changing the behavior of / to mean different things based on what we infer operand WGSL types to be, because it would be hard to determine their behavior locally without explicit casting each time:

function foo(a: number, b: number) {
  'use gpu';
  return a / b;
}

foo(1, 2); // 0
foo(1, d.f32(2)); // 0.5

By inheriting JS behavior, we can expect a / b and u32(a / b) to behave the same no matter what operands are passed in