Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emulating double precision on the GPU to render large worlds

godotengine.org

Post reply on HN
Print view View original

21–30 of 66 posts

Re: Emulating double precision on the GPU to render large worlds

#21

Post by no_time »

frogblast wrote: post #18

The 2xFP32 solution is also dramatically faster than FP64 on nearly all GPUs. While most GPUs support FP64, unless you pay for the really high-end scientific computing models, you're typically getting 1/32nd rate compared to FP32 performance. Even your shiny new RTX 4090 runs FP64 at 1/64th rate. 2xFP32 for most basic operations can be 1/4th the rate of FP32. It is quite often the superior solution compared to using…

>While most GPUs support FP64, unless you pay for the really high-end scientific computing models, you're typically getting 1/32nd rate compared to FP32 performance.

I wonder if there is a hardware reason for this or It's just market segmenting by nvidia.

Re: Emulating double precision on the GPU to render large worlds

#22

Post by Taniwha »

skykooler wrote: post #19
Dylan16807 wrote: post #15

Earlier quoted context omitted.

For Kerbal, isn't it easier and more accurate to set the origin on the craft being simulated? Why use world space?

That is what is done in KSP ever since planets beyond the Mun were added - on every frame, the coordinate system is re-centered on the active vehicle. The problem that still remains is mainly in trajectory calculations - you might have an intercept with a planet way on the other side of the solar system, and you can generally see that the predicted trajectory does not pass through the encounter point in these cases d…

Other stuff too if you want to look around, I did a quick and dirty solar system a couple of decades ago, one with texture maps where possible, and quickly discovered that Pluto was all lumpy .... simply because tessellating a sphere that far out quickly runs into FP resolution issues if the Sun is the origin

Re: Emulating double precision on the GPU to render large worlds

#23

Post by edflsafoiewq »

Animats wrote: post #14

"Then, when doing the model to camera space transformation instead of calculating the MODELVIEW_MATRIX, we separate the transformation into individual components and do the rotation/scale separately from the translation." That's the core idea here. A bit more detail would help. Is that done in the GPU? Is that extra work for every vertex? Does it slow down rendering because the GPU's 4x4 matrix multiplication hardwar…

This looks like the PR: https://github.com/godotengine/godot/pull/66178

Re: Emulating double precision on the GPU to render large worlds

#24

Post by Hextinium »

no_time wrote: post #21
frogblast wrote: post #18

The 2xFP32 solution is also dramatically faster than FP64 on nearly all GPUs. While most GPUs support FP64, unless you pay for the really high-end scientific computing models, you're typically getting 1/32nd rate compared to FP32 performance. Even your shiny new RTX 4090 runs FP64 at 1/64th rate. 2xFP32 for most basic operations can be 1/4th the rate of FP32. It is quite often the superior solution compared to using…

>While most GPUs support FP64, unless you pay for the really high-end scientific computing models, you're typically getting 1/32nd rate compared to FP32 performance. I wonder if there is a hardware reason for this or It's just market segmenting by nvidia.

My naive guess is that most floating point code uses FP32 and FP64 uses at least double the die size. So optimize for FP32 and have some FP64 for the rare equations that need it.

Re: Emulating double precision on the GPU to render large worlds

#25

Post by TT-392 »

Feels kinda weird to be using a data type that gets less precise, the further you move out from the center. Unless the world is infinite (which it sometimes is), isn't it a bit of a waste of precision? I kinda doubt you need nanometer precision, but only within 1 meter from the center. I get that gpus have existing floating point hardware to accelerate stuff. But with more open worlds being a thing. Wouldn't it make sense to include some new, big, floating point data type in hardware / emulate it in software?

Re: Emulating double precision on the GPU to render large worlds

#26

Post by TT-392 »

TT-392 wrote: post #25

Feels kinda weird to be using a data type that gets less precise, the further you move out from the center. Unless the world is infinite (which it sometimes is), isn't it a bit of a waste of precision? I kinda doubt you need nanometer precision, but only within 1 meter from the center. I get that gpus have existing floating point hardware to accelerate stuff. But with more open worlds being a thing. Wouldn't it make…

Or like, I guess a 64 bit int would probably do the job

Re: Emulating double precision on the GPU to render large worlds

#27

Post by pastrami_panda »

bpye wrote: post #2

I wonder if there isn’t another solution here. It seems like the issue is due to large translations? Presumably your view frustrum is small enough that single precision floats are sufficient for the entire range, so couldn’t you just add subtract some offset when calculating the translation matrix for both your view and the model translation? I suppose this may result in instances where you need to recalculate the tr…

Your intuition is right, there's a pretty standard algorithm to solve this called "floating origin".

Essentially you translate the world back to origin when the player gets too far away.

Re: Emulating double precision on the GPU to render large worlds

#28

Post by bullen »

A better way to solve this problem is to move the world around the origin instead. Just like you had to with OpenGL 1!

Really half-floats are more interesting, saving 50% memory on the GPU for mesh data. You could imagine using half-floats for animations too!

Then we could have the debate about fixed point vs. floating. Why we choose to use a precision that deteriorates with distance is descriptive of our short sightedness in other domains like the economy f.ex. (lets just print money now close to origin and we'll deal with precision problems later, when time moves away from origin)

What you want is fixed point, preferably with integer math so you get deterministic behaviour, even across hardware. Just like float/int arrays both give you CPU-cache and atomic parallelism at the same time, often simplicity is the solution!

In general 64-bit is not interesting at all, so the idea Acorn had with ARM that jumping to 32-bit forever is pretty much proven by now. Even if addressing only jumped to from 26-bit to 32-bit with ARM6.

Which leads me to the next interesting tidbit, when talking 8-bit the C64 had 16-bit addressing.

Re: Emulating double precision on the GPU to render large worlds

#29

Post by alwayslikethis »

no_time wrote: post #21
frogblast wrote: post #18

The 2xFP32 solution is also dramatically faster than FP64 on nearly all GPUs. While most GPUs support FP64, unless you pay for the really high-end scientific computing models, you're typically getting 1/32nd rate compared to FP32 performance. Even your shiny new RTX 4090 runs FP64 at 1/64th rate. 2xFP32 for most basic operations can be 1/4th the rate of FP32. It is quite often the superior solution compared to using…

>While most GPUs support FP64, unless you pay for the really high-end scientific computing models, you're typically getting 1/32nd rate compared to FP32 performance. I wonder if there is a hardware reason for this or It's just market segmenting by nvidia.

Mostly market segmentation. There is a software lock to a certain ratio (of clock speed) to the FP32 performance that varies by the card. For most consumer NVIDIA cards it is locked to 1/24 of FP32 speed to prevent use in professional settings that require FP64 performance. However, some cards, such as the Radeon VII, is only locked to 1/4 of FP32 speed (much faster)

Re: Emulating double precision on the GPU to render large worlds

#30

Post by AlunAlun »

pinum wrote: post #12

>The MODELVIEW_MATRIX is assembled in the vertex shader by combining the object’s MODEL_MATRIX and the camera’s VIEW_MATRIX I was taught that MV/MVP should be calculated CPU-side per-model, and that doing it in the vertex shader is wasteful. Is that advice out of date?

Not necessarily, but it doesn’t solve the problem - if you calculate MVP on the CPU with double float precision, when you pass the final matrix to the shader, it will be cast down to single float precision, and cause the issue described.
Post reply on HN