In my project I have the need to render a very wide dynamic range of light intensities for both the light of distant and nearby stars. For example, the ratio of intensity between the sun at 1 AU vs. the dimmest star visible to a human eye is 2.15e13 (apparent magnitude of -26.832 vs. 6.5). This far exceeds the range and precision of 16-bit float.

There are a few options that I could use to "make it work":

• Increase the brightness of far away stars to reduce the dynamic range. The problem with this is having a smooth monotonic transition from overbright to normal brightness when moving toward or away from a star. It's also less realistic in various ways (e.g. ambient star light at night will be too bright).
  
• I can scale the overall light intensity of the scene to look good in dim or bright conditions (but not both at the same time). This scales the light power prior to rendering pixels so isn't sensitive to framebuffer precision. However, it's hard to do this automatically except for with traditional auto-exposure, and that requires that the dynamic range fits in the texture format, so it can't work here (dim stars are pure black with 16 bits). I would need a separate system for controlling the exposure range based on distance to the nearest star, for example.
  
• Or I can just use 32-bit float RGB textures for the framebuffer and all post processing. With this, everything just works without any funny business (including traditional auto-exposure).

So, I want to get a feeling about if 32-bit float is practical for a game in the near future. I understand the trade offs (more memory, bandwidth), but don't have a good idea if that price is an acceptable one to pay these days. I think I could afford the main framebuffer in 32-bit, but not sure about the extensive post processing for bloom, auto exposure, and tone mapping (and their intermediate textures). I am targeting mid-level to high-end PC hardware (minimum 4 GB GPU) made in the 5 years prior to the release date, which would not be for at least 2 years.

Aressera said:
which would not be for at least 2 years.

‘2 years’ is the programmers favorite constant to avoid thinking ‘10 years or more’.
(I've learned that the hard way. : )

Aressera said:
stars

Aressera said:
I can scale the overall light intensity of the scene to look good in dim or bright conditions (but not both at the same time).

Question: Have you tried 32 vs. 16 bit on a planets surface, and 16 seems enough for that?
If so, the question becomes ‘how can i handle the special case of distant stars with fp16?’.
Imo, it's not worth to go fp32 just to handle some bright dots on a black background with pedantic accuracy. There surely is a good enough hack to handle stars, and nobody will complain or even notice.

Aressera said:
In my project I have the need to render a very wide dynamic range of light intensities

You can do the math, but you can not display it anyway. Current high end displays have at most 1000 nits afaict, but to show sunlight bouncing off a white wall we would need 10k-20k. Sun itself is totally out of reach. (Thankfully, so we won't blind our players.)

What i mean is, considering we have to use hacks such as aggressive tone mapping anyway, accuracy of light sources is no priority. All we can do is simulating the lights interaction with materials.
Stars are light sources, but contribution can be approximated or even ignored. Thus they are not important and do not justify a performance loss.

Btw, i want to port my realtime GI stuff to all fp16, including its spatial scene represeantion (surfel hierarchy).
But when i worked on it i had no GPU with fp16 support, so idk if it works. But i'm very optimistic.
However, currently i'm unsure about fp16 support for RDNA3 for example. Some people say it still has it, other say no - all that's left is a fp16 dot product instruction for ML.
I mean, we always have the bandwidth advantage, but if there is a need to convert all fp16 data to 32 for calculations, it's not certainly a win in the general case.
This would be important to know for a decision.

Aressera said:
I am targeting mid-level to high-end PC hardware (minimum 4 GB GPU) made in the 5 years prior to the release date

I expect a varied landscape regarding future HW. In the long term, the death of x86 and dGPU seems decided. It seems MS attempts to control the HW market by introducing two standards, the 'AI-PC' (low power APU, mobile), and the ‘XBox-PC’ eventually, with rumors about allowing OEMs to build their own X-Boxes. Basically they want to merge Gaming-PC and XBox to remain competitive, hiding the commercial failure of XBox, and taking a cut from OEMs to put an XBox sticker on their PCs.
Not sure if that's true, but makes total sense. It will keep dPGU and x86 alive for some years to come, but handhelds will be included in the XBox brand as well, and after some time… even the richest and dumbest gamers will realize a 4090 is a waste of money. And not even NV will complain, since they can compensate the loss by entering the CPU market now, delivering ARM SOCs.

It's quite likely the average gamers compute power goes down, not up. Or there is at least stagnation from now on. Increased power efficiency and marketing buzzwords become more important than teraflops and core counts, and there is a strong trend towards mobile. So in the long run i expect fp16 will become much more standard than it is now.

Computer generated imagery will be limited by the display output, so having a 32/64/128 bit HDR pipeline to get that tonemapped back into worse-case 8-bit display output seems criminal..excuse my play one words..lol. In all seriousness, there is always going to be accuracy vs efficiency tradeoff, and so far it seems like efficiency has all taken the lead even at the architectural level. So my 2 cents would be to stick with the closest dynamic range that gets you most efficient simulation.

cgrant said:
Computer generated imagery will be limited by the display output, so having a 32/64/128 bit HDR pipeline to get that tonemapped back into worse-case 8-bit display output seems criminal

While that's true for a fixed exposure value, dynamic exposure allows display of higher dynamic range (just not at the same time). Consider an astronaut in orbit. In that situation, depending on which way the astronaut looks, they could see the sun's bright disk, or could look into deep space where only dim distant stars are visible. When looking at the sun, the exposure should be low to avoid large pixel values, which prevents seeing any distant stars. Similarly, looking into the void should use a high enough exposure to see the stars. An automatic exposure control system is used to dynamically adjust the brightness to the lighting conditions. This is how it works in real life with the eye and cameras. It works fine with 32-bit float HDR.

While I can make the distant stars brighter to reduce the dynamic range, it's not quite enough to fit in 16 bit float, and there are issues in certain situations when moving toward and away from a star. Depending on exposure, I either have not enough small precision to preserve the colors of distant stars, or not enough range to represent the bright pixel values for closer stars. The result is unnatural shifts in the color or brightness of stars at certain distances. E.g. a blue star might turn white when it is at a distance where the star's light is concentrated into a single pixel enough to exceed 16-bit range. This happens in two places: once when transitioning from drawing stars as individual pixels to spheres, and again when very close to bright stars. I tried a fair bit to get this to work right but 16-bit always has some problem.

Currently I think I will just expose this as a graphics setting to the user (e.g. HDR: 16 or 32 bits), so that users with big GPU can have the most realistic experience. People using 16 bits will just have to live with graphics artifacts.

Maybe you want a specific solution for tone mapping, not the standard ones which use a simple curve.

For example, if an artist levels an image, he will at least tune lows, highs and midtones separately, so the mapping curve becomes complex, may have a knee, even discontinuities, etc.
He will also not tune the curve so the sun fits into the range. Instead he will tune the curve so the objects lit by the sun fit into the range. Since there is no hope the sun fits into any range - neither for image sensors, displays, or human eyes.

I see in your case the sun may take a unusually large area in the image, still surrounded by distant and dim pixel stars in the background. If you want to show both, you need two different curves combined to one using a hard threshold, but eventually smoothing out the intersection.

Aressera said:
While I can make the distant stars brighter to reduce the dynamic range

But they are not the problem. The close up sun is. So you should make the sun darker the closer you get, additionally to tonemapping hacks mentioned above.

I remember an iconic scene in Mass Effect:

They made the sun so dark we can even see surface details, and it looks good.

@Aressera I think there's a slight misunderstanding to what mentioned and your comments even touched on what I was getting at. If the goal is to create a pretty picture, let say for discussion sake we a have sensor that have infinite dynamic range. That is the sensor, now this sensor output now needs to become this pretty picture. We'll try the follow output format/medium:
1. Print( like a photograph). Unless there is infinite dynamic range ink/dye/film. How do you resolve ? The lack
of an infinite dynamic range medium or one that matches the dynamic range of sensor input would imply
this being the limiting factor in producing the pretty picture.

2. Desktop Display. Pretty much the same as print. Unless the display dynamic matches or exceeds the sensor output, the pretty picture you get won't be the faithful representation of what the sensor captured.

The comment wasn't really about the practicality of using a 32-bit float HDR pipeline, but more about what the end user see in end with their own two eyes.

Also all image sensors usually have a fixed dynamic range expressed in stops that you are allowed to worked within, any reading above/below the range is clipped or shows up as noise in the signal.

Maybe I"m completely off the mark here and you just wanted a feel of should you roll with a 32-bit HDR pipeline from here-on out, in that case, unless you are doing this for only ‘PC-like’ architecture I would say probably wouldn't hurt, 16-bit would be a more pleasant middle ground.