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

51–60 of 66 posts

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

#51

Post by capableweb »

oneoff786 wrote: post #49
Ennea wrote: post #40

Since to-scale solar systems are mentioned in the article, it may be worth talking briefly about Outer Wilds. Outer Wilds is a wonderful game built in Unity and comes with its own solar system. Things are quite a bit smaller than in the real world, but I suppose everything is still large enough for floating point precision to be a potential issue. The developers have solved this by making the player the origin instea…

Good luck doing networked multiplayer for that setup though

Neither the submission article nor Outer Wilds is about multiplayer, nor does every game need multiplayer. So seems fine enough for many cases, not just the case you are thinking about I guess.

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

#52

Post by jrootabega »

JoshTriplett wrote: post #50
Ennea wrote: post #40

Since to-scale solar systems are mentioned in the article, it may be worth talking briefly about Outer Wilds. Outer Wilds is a wonderful game built in Unity and comes with its own solar system. Things are quite a bit smaller than in the real world, but I suppose everything is still large enough for floating point precision to be a potential issue. The developers have solved this by making the player the origin instea…

Outer Wilds can also suffer from issues with simulation precision if you run the solar-system simulation long enough. The developers have talked about this a bit, and people have observed the effects with mods that encourage long-term exploration. This isn't actually an issue in practical gameplay, though. rot13 to avoid spoilers for people who haven't played the game: Gur fha tbrf abin va gjragl-gjb zvahgrf, fb guvf…

I beat the game, but I believe you can experience precision issues if you just zoom the map out far enough and/or fly far enough away from the sun. Makes sense if you can infer that the map was really just an alternate camera showing the entire scene. It doesn't matter where the origin is if you can see all of it at once.

EVE Online had (still has?) a similar issue with its camera being able to zoom in on objects that are very far away. Normally, at those distances, you'd be using your overview or the HUD markers, but if you did zoom in on a far object, the origin would still be on your ship (or maybe the center of the area you were in), and the object would get distorted. Especially fun when it was a floating corpse.

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

#53

Post by adrian_b »

ekelsen wrote: post #32
adrian_b wrote: post #16

Earlier quoted context omitted.

For general computational applications (i.e. not for special graphics cases), implementing double-precision operations using single-precision operations is considerably more complicated than implementing quadruple-precision operations using double-precision operations. The reason is that it is not enough to extend the precision of the 32-bit FP numbers. The exponent range must also be extended. The standard double-pr…

It's interesting that you find the idea of "only" being able to represent numbers as small as 10^-38 and as large as 10^38 as having "very small exponent." In deep learning, this is huge! If you have numbers this big, then something is definitely already wrong. If you have numbers that small, then you definitely don't care. I wonder if deep learning will save us from poorly conditioned linear algebra too.

In physics there are many universal constants or material constants with ranges between 10^10 and 10^40, and their reciprocals are between 10^-10 and 10^-40.

Some of these cannot be represented in single precision, while for the others one or two multiplications or divisions are enough to cause underflows and overflows. Such wide ranges are unavoidable in complex physical simulations, because their origin is in the ratios between quantities at human or astronomic sizes and quantities at atomic or molecular sizes.

Single precision values are perfectly adequate to represent the input data and the final results of any computation, because 24 bit is about the limit for any analog-to-digital or digital-to-analog conversion, and the exponent range is also sufficient for the physical quantities that can be measured directly, but when you simulate any semiconductor device and even when you simulate just an electrical circuit with discrete components, it is very frequent to have intermediate results with values much outside the range that can be represented in single precision, even up to 10^60 or 10^-60. When computing a high-order polynomial in order to approximate the solution of some problem, some intermediate values may be even outside that range.

In theory it is possible to avoid underflows and overflows by introducing a large number of scale factors in the equations, in appropriate places.

However, handling those scale factors in a program is extremely tedious and error prone. The floating point format was invented precisely in order to avoid the need of dealing with scale factors. If someone introduces scale factors in a program, they might as well use fixed-point numbers, because the main advantage of the floating-point numbers is lost.

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

#54

Post by oneoff786 »

capableweb wrote: post #51
oneoff786 wrote: post #49

Earlier quoted context omitted.

Good luck doing networked multiplayer for that setup though

Neither the submission article nor Outer Wilds is about multiplayer, nor does every game need multiplayer. So seems fine enough for many cases, not just the case you are thinking about I guess.

I don’t feel that needed to be stated personally. That’s true of pretty much anything.

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

#55

Post by [deleted] »

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.

[deleted]

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

#56

Post by Sharlin »

mitthrowaway2 wrote: post #38
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…

Integer definitely seems like the right fit here. The precision is translationally invariant, which is the property you want for a Cartesian coordinate system.

Depends on what you want. If you're rendering a 3D world (with perspective projection) and use a coordinate system where the camera is always at the origin or close to it (floating origin), then floats give you more precision where it matters (objects close to the camera) and less precision where it doesn't (faraway objects).

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

#57

Post by TrevorJ »

oneoff786 wrote: post #49
Ennea wrote: post #40

Since to-scale solar systems are mentioned in the article, it may be worth talking briefly about Outer Wilds. Outer Wilds is a wonderful game built in Unity and comes with its own solar system. Things are quite a bit smaller than in the real world, but I suppose everything is still large enough for floating point precision to be a potential issue. The developers have solved this by making the player the origin instea…

Good luck doing networked multiplayer for that setup though

It's actually not a big problem in many cases. If you need to physically interact with something that's N number of miles away from you then yes it could be an issue.

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

#58

Post by my123 »

thesz wrote: post #41
Hextinium wrote: post #24

Earlier quoted context omitted.

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.

These compute units are usually sliced - they can perform either four FP32 multiples or one FP64 multiply on the same die part. This trick was done as long ago as PA-RISC was developed, from what I remember it was HP who introduced sliced ALU, capable of doing one large or several smaller operations on the same hardware. I can be wrong about who did that first, but most FPUs now are done like that.

On GPUs, they're not sliced like this anymore since quite a long time to save die area.

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

#59

Post by mitthrowaway2 »

Sharlin wrote: post #56
mitthrowaway2 wrote: post #38

Earlier quoted context omitted.

Integer definitely seems like the right fit here. The precision is translationally invariant, which is the property you want for a Cartesian coordinate system.

Depends on what you want. If you're rendering a 3D world (with perspective projection) and use a coordinate system where the camera is always at the origin or close to it (floating origin), then floats give you more precision where it matters (objects close to the camera) and less precision where it doesn't (faraway objects).

But if you're doing it that way, why would you need higher precision floats to render a larger world? Single precision should be good enough for any draw distance, because the object dimension on the screen falls as 1/r.

If you want to move in the environment, you want to be able to store the relative positions of a teacup and a table in virtual London with the same precision as in virtual New York. So the coordinates of objects should be stored as integers. Then to render the world, the camera coordinate (also an integer) is subtracted from all objects, with no loss of precision, and the result cast to float for 3D rendering.

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

#60

Post by danhau »

djmips wrote: post #35
bullen wrote: post #28

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 sight…

Minecraft works like this. The camera is the world origin when rendering.

Don't all games do this? The camera is by definition the world space origin, (0, 0, 0). Translating the camera right actually means translating the world left. What does Minecraft do different?
Post reply on HN