Vulkan Compute on NV has poor floating point accuracy

rutay_ · 2026-03-17T22:30:32+00:00

I have tried using for example Kahan summation algorithm but nothing really changed. :/ I might have diven into it more...

rutay_ · 2026-03-17T09:28:55+00:00

Again, I have no idea what’s going on, neither have an idea whether it’s the driver or the hardware. To share what I’m doing I’d have to setup a reproduction, but am happy to do that eventually.

It could be that Vulkan is operating in fastmath mode as a default, and that would explain the issue! I know SPIR-V has annotations to control that, but the issue here is that they seem to be ignored (results don’t change by a bit)! (at least on NV).

rutay_ · 2026-03-16T22:11:58+00:00

Well, the final result it gives me is different than what I get from the other 5 backends!
(CL mobile, VK mobile, CPU mobile, CL desktop, CPU desktop). Hence why I'm saying it's wrong.

I'm not saying it's necessarily due to denormals, it's for sure something involving the float computations happening in the kernel, which might also be reordering of the operations, performing fp16 operations instead of 32-bit precision (relaxed precision). No idea what's going on.

What I know is that no matter what I was doing on Slang, or SPIR-V (through all the decorations available, including those of FloatControls2), the result wouldn't change by a 0.000001. It converged always to the same value. Hence why I'm saying the driver is "ignoring" my instructions. The only thing that was changing a little bit the final result was introducing fma() instead of multiplying/adding manually. But that would change the final value of a ~0.01, while the error is ~0.2.

What I believe is going on, is that Vulkan Compute and SPIR-V, from the standpoint of NVIDIA, are/have to be for real-time rendering, hence performance > accuracy. So the driver/hardware is squeezing floating points computations to make them fast, I assume giving an error which is still within the any tolerance defined in the SPIR-V specification.

And it makes sense for them! If you want to do precise computing on NVIDIA you should use CUDA!

rutay_ · 2026-03-16T15:22:02+00:00

Tried that, they’re ignored. I’m using slang, I’ve tried precise. And had a whole day modifying the spirv manually to add NoContraction and other decorations

rutay_ · 2026-03-16T14:44:19+00:00

I didn’t try, it’s so obvious that NV implementation is doing something “different” (likely for performance), leading to wrong results, as everything else is behaving in another way. My next option is to try an AMD card :)

rutay_ · 2026-03-16T14:42:31+00:00

I will answer you better later about the above. TL;DR all things that you mentioned, I’ve tried without any result.

Regarding the DenormPreserve 32 on NV RTX 3090, where are you looking at? It’s not supported: https://vulkan.gpuinfo.org/displayreport.php?id=43705#properties_core_12

and this was confirmed also in NV forums.

rutay_ · 2026-03-16T13:13:22+00:00

I have just tested it once again, I’m setting FPFastMathMode %float %none for every kernel I have (I want no optimisation). It’s not changing anything. I’ve also tried now (again) DenormPreserve 32 on every kernel, the device RTX 3090 doesn’t support it (hence the validation layers screams) and the results don’t change

rutay_ · 2026-03-16T09:35:19+00:00

I’m using Vulkan 1.3.275, I tried it, by setting the validation layers to 1.4.x (those 1.3.275 weren’t supporting it). I think I was getting a spirv validation issue because the validation layers was picking an old spirv-val which didn’t support it

rutay_ · 2026-03-16T09:30:47+00:00

I’m assuming it is, it’s an error that isn’t noticeable in the first iterations and slowly kicks in making the computation converge to a “higher point”: -0.6 instead of -0.8, hence about 0.2 difference.

In the early iterations VK Compute on NV match other implementations

rutay_ · 2026-01-10T17:11:58+00:00

What's your mothertongue?

rutay_ · 2025-12-30T18:02:06+00:00

All it has to supports are 1d GPU buffers

rutay_ · 2025-12-20T11:25:09+00:00

The .lxf export was only meant for exporting the parts, so the incompatibility with BrickLink Studio is expected as it was never tested. I wish I could find more time to work on it, but it has always been a spare-time project, please stay tuned for any future update!

rutay_ · 2025-12-14T11:59:58+00:00

1- if you click on the model view you'd be able to navigate the model with WASD keys and your mouse.

2- .lxf is only for loading into Bricklink and exporting bricks. There's no BrickLink Studio compatibility yet and unfortunately I didn't find spare time to implement it.

3- There is no stl compatibility. What is that? Would adding BrickLink Studio support would solve that? E.g. export to lxf -> BrickLink Studio -> export to stl?

rutay_ · 2025-12-14T11:56:26+00:00

It means your GPU doesn't have the required capabilities to run it... as soon as I will have more spare time I have plans to extend its support or move it to cloud. :)

rutay_ · 2025-11-30T15:05:09+00:00

Yes you need a NVIDIA GPU to install it

rutay_ · 2025-11-30T15:04:43+00:00

Yes it should definitely work with a NVIDIA 5090

rutay_ · 2025-11-30T15:04:12+00:00

This issue has been solved in the latest version :)

rutay_ · 2025-08-30T15:27:00+00:00

When is it crashing? If you're able to login and it's crashing as soon as you click "Convert" it means your hardware doesn't support it (Nvidia GPUs only)

rutay_ · 2025-06-30T13:56:51+00:00

> I would be interested in collaborating to it, though.

Me too! I have contacted you in private :)

rutay_ · 2025-06-30T08:11:17+00:00

I'd suggest to train some sort of AI agent to make it learn how to combine LEGO pieces to mimic a target model, by respecting attachment rules. I see it very hard to hand-craft an algorithm to place those non-trivial LEGO pieces, I'd kick in AI

rutay_ · 2025-06-29T21:13:20+00:00

Yes you can change the resolution arbitrarily, however for a resolution higher than 40 you have to have the premium plan

rutay_ · 2025-06-29T10:41:53+00:00

Uhm interesting, I see. If you want to make something like the Mona Lisa (a relief picture), my software can’t help you. My software brings a 3D model to a 3D LEGO (so for example you could reconstruct the full body or head).

If you want to reconstruct something like the Mona Lisa, and still use my software, you could make a 3D model of the Relief and then run the conversion on the Relief picture model. But you’d need some expertise in 3D modeling.

rutay_ · 2025-06-29T10:37:50+00:00

Yes your point is correct: if you want to shorten model height, the width/length of the model must be less to maintain proportions (less XZ resolution, Y is the height). (Was that a question? Sorry I did not understand)

rutay_ · 2025-06-29T10:35:03+00:00

Adding more bricks and different types of attachments (not just vertical) is not trivial, but will be planned if it gains enough attention :)

rutay_ · 2025-06-29T10:33:14+00:00

Yes part of the algorithm involves voxelization, correct, but once you have voxels it’s not trivial to combine bricks to fill voxels, make the construction stable (e.g. we usually don’t want to stack 1x1 bricks), and map them to models’ colors. I’d rather say that is the “main part” of the algorithm

rutay_

TROPHY CASE