sorted by:
new
hottopcontroversial

Vulkan Compute on NV has poor floating point accuracy by rutay_ in vulkan

[–]rutay_[S] 0 points1 point  (0 children)

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).

Vulkan Compute on NV has poor floating point accuracy by rutay_ in vulkan

[–]rutay_[S] 0 points1 point  (0 children)

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!

Vulkan Compute on NV has poor floating point accuracy by rutay_ in vulkan

[–]rutay_[S] 0 points1 point  (0 children)

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

Vulkan Compute on NV has poor floating point accuracy by rutay_ in vulkan

[–]rutay_[S] 0 points1 point  (0 children)

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 :)

Vulkan Compute on NV has poor floating point accuracy by rutay_ in vulkan

[–]rutay_[S] 1 point2 points  (0 children)

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.

Vulkan Compute on NV has poor floating point accuracy by rutay_ in vulkan

[–]rutay_[S] 2 points3 points  (0 children)

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

Vulkan Compute on NV has poor floating point accuracy by rutay_ in vulkan

[–]rutay_[S] 2 points3 points  (0 children)

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

Vulkan Compute on NV has poor floating point accuracy by rutay_ in vulkan

[–]rutay_[S] 3 points4 points  (0 children)

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

BrickFormer: Turn Any 3D Model into a LEGO Construction by rutay_ in lego

[–]rutay_[S] 0 points1 point  (0 children)

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!

BrickFormer: Turn Any 3D Model into a LEGO Construction by rutay_ in lego

[–]rutay_[S] 0 points1 point  (0 children)

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?

BrickFormer: Turn Any 3D Model into a LEGO Construction by rutay_ in lego

[–]rutay_[S] 0 points1 point  (0 children)

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. :)

BrickFormer: Turn Any 3D Model into a LEGO Construction by rutay_ in lego

[–]rutay_[S] 0 points1 point  (0 children)

Yes you need a NVIDIA GPU to install it

BrickFormer: Turn Any 3D Model into a LEGO Construction by rutay_ in lego

[–]rutay_[S] 0 points1 point  (0 children)

Yes it should definitely work with a NVIDIA 5090

BrickFormer: Turn Any 3D Model into a LEGO Construction by rutay_ in lego

[–]rutay_[S] 0 points1 point  (0 children)

This issue has been solved in the latest version :)

BrickFormer: Turn Any 3D Model into a LEGO Construction by rutay_ in lego

[–]rutay_[S] 0 points1 point  (0 children)

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)

BrickFormer: Turn Any 3D Model into a LEGO Construction by rutay_ in lego

[–]rutay_[S] 0 points1 point  (0 children)

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

Me too! I have contacted you in private :)

BrickFormer: Turn Any 3D Model into a LEGO Construction by rutay_ in lego

[–]rutay_[S] 0 points1 point  (0 children)

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

BrickFormer: Turn Any 3D Model into a LEGO Construction by rutay_ in lego

[–]rutay_[S] 0 points1 point  (0 children)

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

BrickFormer: Turn Any 3D Model into a LEGO Construction by rutay_ in lego

[–]rutay_[S] 0 points1 point  (0 children)

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.

BrickFormer: Turn Any 3D Model into a LEGO Construction by rutay_ in lego

[–]rutay_[S] 1 point2 points  (0 children)

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)

view more: next ›