Allow HDR creating huge decrease in performance

Hi, I actually need bloom affect . So I enabled Allow HDR and am using post processing bloom. But there is very huge loss in performance. As I want bloom only for one object actually, I set high bloom threshold .

Is there any possibility to get bloom post processing effect only for one required object? Or Allow HDR to work only for one required object?
Or any ways of optimisation to have Allow HDR for all objects, with high bloom threshold?


Thankyou !!

 

You don't really need HDR for bloom, it just becomes easier to process it (more bright spots for blooming, easier to brightpass)

The reason behind low HDR performance is that it greatly increases memory bandwidth (as main textures and most of the "transient" ones used for post processing (read - multipass blurring) take at least twice as much memory. And mobile devices are not very good when it comes to memory speed and bandwidth (mostly to save energy).

Allowing HDR just for one object won't do any difference because you will still need a full-res render pass into an HDR texture and the same amount of transient HDR textures used for blurring passes. So blooming one object will take just as much time and effort as blooming all of the scene objects.

Moreover, Unity has a severe bug with HDR rendering on 2017.x versions which just outputs black screen in certain GPUs (https://issuetracker.unity3d.com/is...enabled-on-certain-device-using-mali-t720-gpu) and the list of GPUs is not really full, I alone have three devices with different GPUs (Adrenos and Malis) with the same behaviour.
Even if no postprocessing involved, it's still a black texture. I have investigated that due to some internal graphical pipeline tweaks, Unity sometimes just randomly clears the screen with black color, overriding everything that has been rendered (even if the HDR texture format is really supported and scene renders normally before that random clearing with black). So until it's really fixed and stable, I strongly discourage using HDR with Unity 2017.x on mobiles. (they say it's fixed in 2018, but there are no backports to 2017 yet)

 

Hi, thanks, but my target platform is not mobile. Its desktop application only. How can I get bloom for few things without HDR ?

Thanks !

 

@Tejaswini_G which hardware do you test it on? HDR shoudln't generally cause problems on desktops

 

Hi, its a PC with GeForce GTX 1060 graphics card, 8GB RAM.

 

Are you sure that this issue is due to HDR? GTX 1060 should chew on "thousands of HDRs" like nothing.

 

Yeah, I am sure. ANd FPS before enabling HDR was around 80-90, but just after enabling HDR , it dropped to around 45. If HDR enabling should not be problem, I will start adding objects in incremental way after enabling HDR and see what's happening then. Thanks !

 

Hi @Kumo-Kairo , it is Virtual Reality game , with system specs as above mentioned. Generally will Allow HDR work without affecting performance for VR enabled also?

 

@Tejaswini_G I'm not really experienced in desktop programming and graphics, it was always about mobiles for me. So what I suggest you doing to be sure you are getting every bit of performance information, is to install some sort of a native Graphics Profiler on your machine, something like RenderDoc, or native NVIDIA things (system profiler or something like that, it should be somewhere in their SDK). But you can start with RenderDoc to see additional info right from Unity https://rubentorresbonet.wordpress....-go-when-unitys-frame-debugger-is-not-enough/
it shows API overhead and overall render passes cost, so it's a good starting point to finding bottlenecks

 

Okay, will do that . Thanks !!

 

I'm sorry for off-topic, but could you confirm that HDR wokring in unity 2018?

 

Yes, its working .

 

Thanks Kumo

I've been out of the loop for years and hadn't gotten around to learning what HDR is all about.. thanks for the explaination

 

Is there a way to optimize for mobile?

 

SteamVR disables the "Allow HDR" on their included prefab with camera. Is it recommended to avoid HDR when developing for VR?

 

If it's desktop VR - no, it's not that of an issue
In mobile VR - yes, it's critical

 

Off Topic:
On PC you can bring a 1060 to its knees with an 8xmsaa 4k frame buffer, and in that case, the bloom would be very expensive. This may not be true in this case, but PC devs often run at insane resolutions, profile in editor and then worry about the performance of their screen space operations.

Back on Topic:
I do not understand why something like 11:11:10 HDR is significantly more expensive than a 10:10:10:2 frame buffer or an 8:8:8:8 frame buffer.
We haven't had reason to use HDR in our project but we do use 10:10:10:2 for our main renter-target when supported as it does not seem to have a cost and it improves the quality of transparency. linear lighting and post-processing slightly as it provides 4x the precision to play with.
In many cases, you do not need very high dynamic range. You can get a decent bloom by using 10:10:10:2, scaling your lights by 0.5, then generating a bloom buffer for luminances above about .45, and finally scale by 2 while applying bloom.

Or you can use a Sprite.

 

Very nice trick, but there's this problem.
Since ARGB2101010 format can only store Unorm values (no hardware sRGB-encoding), rendering to ARGB2101010 produces much more banding in dark areas, while light areas get extra precision comparing to ARGB32 rendering.

When [0..1] range uses these 10 bits entirely, this banding may be bearable, but once we start using 9 bits or less (by scaling as you suggest), dark areas quickly become ugly.

That being said, I still like your trick and may end up using it, but I'm on the fence. Do you know of any full-fledged projects using this trick? so I could check whether they have problems with banding or not.

RGB111110Float apparently is slightly better than ARGB32, according to https://bartwronski.com/2017/04/02/small-float-formats-r11g11b10f-precision/

 

The r11g11b10 float format is ideal for low numbers and dynamic range but your mantissa is 5 or 6 bits which can be noticeable between .5 and 1.
I wish that the r11g11b10 has used fewer bits for the exponent, but that is neither here nor there.

That is a good point about SRGB encoding. You could convert to sRGB in your shader, but then your alpha blending is non-linear, and you are paying a cost that should be handled by the hardware. (in this case, you can use sqr and sqrt as you are transforming back and forth yourself so 2 is about as good as 2.2)
Still, it might be a workable solution.
For a legacy reason (early sRGB issues on mobile), our project is stuck in sRGB and the artists don't want that to change for this project.