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

41–50 of 66 posts

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

#41

Post by thesz »

Hextinium wrote: post #24
no_time wrote: post #21

Earlier quoted context omitted.

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

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.

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

#42

Post by bagels »

TT-392 wrote: post #26
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

All those annoying trig functions get in the way since they're implemented for floats/doubles.

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

#43

Post by p0nce »

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…

You are right, it is what I did when I was working on a planetary rendering system. Drawing a plane would happen far from the Earth origin, and it would show in the shader computations especially specular highlights. The new origin was at the Earth surface I think. However it's not trivial, all shaders need to change, and having things in world space is useful in your shaders. And now eg. you need to convert light positions into that local space. So likely it wouldn't make sense in the context of Godot.

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

#45

Post by automatic6131 »

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…

>The developers have solved this by making the player the origin instead

Perhaps such a brilliant idea came to them in a dream. But maybe they forgot how they did it in another dream.

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

#46

Post by sigmoid10 »

automatic6131 wrote: post #45
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…

>The developers have solved this by making the player the origin instead Perhaps such a brilliant idea came to them in a dream. But maybe they forgot how they did it in another dream.

This is actually a pretty common practice and has been used for a long time. Here is a great explanation by developers of Kerbal Space Program, who built a solar system sized physics sandbox using the same method (and a few other tricks) in Unity: https://youtube.com/watch?v=mXTxQko-JH0

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

#48

Post by veltas »

bagels wrote: post #42
TT-392 wrote: post #26

Earlier quoted context omitted.

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

All those annoying trig functions get in the way since they're implemented for floats/doubles.

No reason you can't have intermediate int's. And if there's some nearby frame to do calculations against then you don't get the loss of precision.

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

#49

Post by oneoff786 »

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

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

#50

Post by JoshTriplett »

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 vfa'g npghnyyl na vffhr va cenpgvpr.

Post reply on HN