Final Blit Pass from LWRP Killing Perf on Android

This has been an issue for a long time now and even on the latest 6.9.1 it persists. The issue is reported at least here and here and also within several forum posts here.

This is crucial for performance on Oculus Quest and other Android VR platforms.

Could we please get any kind of status update on a permanent fix for this issue? (We've been hacking the source code of the LWRP package on each release to work around it so far).

Thank you!

 

Removing Final blit would cause problem with linear color space on many devices. Unity2019 removed the internal Final Blit for android, so we have to rely on the final blit of the LWRP, otherwise linear color space rendered image will suffer from missing gammar correction, which leads to much darker result
I don't know if it's safe to remove that in vr applications, but for us, it's definitely neccessary to have the final blit.
It's also required on some android device to kill alpha value on the framebuffer to prevent display issue, that also requires final blit

 

Then perhaps the proper fix here is a VR-specific check - at least in the case of Oculus Quest in linear color space rendering seems correct without this expensive final blit.

 

Have you reported it as a bug through the bug reporter in the editor? Their QA team won't often be checking the forums to see this. Any time I have had an issue I bug reported it and got a response from the developers within a day or so.

 

In this case i linked to existing bug reports.

 

Consider compute shader？

 

Does anyone know of any news about this yet? @ROBYER1 I think you mentioned in some other thread that you were also manually editing the LWRP package to turn this final blit pass off manually, right? Are you still having to do that on the latest?

 

Hi, @aleksandrk , in my case, it is definitely being triggered by the fact that I'm using "RenderFeatures", though the simplest possible kind - RenderObjects. This is simply to render groups of things in order. The mere fact that I'm using these causes createColorTexture to become true inside of ForwardRenderer.cs. Is that really necessary? I'm only using these at all since the old "normal" way of simply layering multiple cameras stopped being an option in LWRP a while back.

I'm not able to run on the Quest at this moment so I can't be sure about whether
RequiresIntermediateColorTexture() is also triggering it. As soon as I can run on the Quest again, I will update this thread with that info, too.

Either way, thanks a ton for taking an interest and for any information!

 

I would also like to simply ask: is using URP for VR actually a recommended thing to do for projects that want to ship during the first half of 2020? Is this just a bad idea? Thanks!

 

Woohoo! Thank you letting us know @ElvarOrnUnnthorsson ! When do you think 8.0.0 will be released?

 

So apparently on the Oculus Quest, you do *not* need this extra blit even when rendering with linear color space. I tested by hardwiring this extra blit to false in ForwardRenderer.cs and setting to linear color space. Everything looks visually correct (not darker as you would expect if this were needed).

This extra blit will still be here on the Quest even after @ElvarOrnUnnthorsson 's other fix lands, so we will still have to make a custom hack to this package every time we build until this is fixed in some more permanent way. Is it possible to say something like #if VR_ENABLED then set this flag to false in there?

Heck - even just a project specific setting where we can check a box that says "Don't do the extra blit - I know the hardware I'm targeting and I don't need it" would be fine!

 

There was a thread somewhere here with an explanation of where in the source you could disable the final blit yourself until a first-party fix is available. But now I can't seem to find it to save my life! If anyone knows where it is, please share it here!

 

Found it:
https://forum.unity.com/threads/quest-lwrp-urp-msaa-not-working.786026/#post-5374629

 

I would like to know if it conflicts with the Vulkan FFR which is now enabled in Multiview, could you enquire about that also please?

 

Given that omitting the extra blit is also going to be a very common use case for Android (especially Quest/Vive Focus, and probably more headsets to come in the future) developers, it really should be at least a checkbox with a warning or something. I mean, it's really hard to even get approval to ship a game on Quest without disabling this, so it really needs to be some sort of standardized option. It's a little much to require everyone who will need it to write their own custom pipeline. I could see that if it was an unusual edge case, but it isn't. It's pretty much the default situation for anyone developing for Quest, etc.

 

I had to do the same hacks for our Quest app, and talked about / reported bugs since middle of last year about this.
Any rendering that's not going to backbuffer breaks FFR, reducing performance on top of already killing performance because of the blit(s).
See https://forum.unity.com/threads/fix...oculus-quest-not-working.686662/#post-4694618

Commenting out all those extra blits and also everything related to postprocessing is currently necessary to get decent performance on Quest. I have a fork of SRP which is "optimized" (read: hacked) to work on Quest and kill all unecessary features (e.g. 25-30 MB of Uber postprocessing shader that is ALWAYS included in stock URP for no reason, even if turned off everywhere). I'd be very interested in having a good, complete fork of URP for actual high-performance VR - I'll test it with Render Features tomorrow to see whether it actually already supports that without blit.
(Dev fork is here, in the process of testing it. Production-tested fork is here.)

@phil_lira can you elaborate on why camera stacking (without post processing) requires an extra blit? In good old builtin rendering stacking cameras would just render them one after the other with their respective clear flags (or none, usually), no blits involved.

 

Is this issue now fixed with the release of 7.2? It is mentioned in the release notes at least but some clarity would be nice. Especially on the Quest side of things.

EDIT: The final blit pass still seems to be there in the frame deugger for me. So I guess this was not fixed.

 

@aleksandrk
No keywords as far as I can tell. I noticed that the blit is related to the AntiAliasing. If I turn off MSAA in my Quality Profile then the blit is gone aswell. Is that blit needed for MSAA to work (I guess it has to resolve the multiple samples)?

 

Quest doesn't need the final blit to resolve MSAA... that is one of the issues I reported. The internal bool "needs msaa resolve" returns true for Quest but forcing it to false makes MSAA work.

 

This is the fundamental thing. Just giving us a checkbox to force the blit off would solve it for those of us on this kind of hardware. It can include a big warning icon and flash red and sound a siren if you like, but we want to check it. ;-)

 

I don't know how to answer that question. Is this a choice that's made inside of the URP source somewhere that I can check for you?

 

Don't need fancy 2nd Cameras and never have, so I think that's about as common a people wanting a second camera. I think it would be a great idea to provide a lean forward renderer out of the box, from the drop down for the optimised crowd so people can pick.

 

The problem I have with final blit is on VR it prevents FFR from working as the FFR is only applied to the final blit... if this is fixed than I'll get my coat and politely exit

Also worried about avoiding any needless Adreno tile resolves.

 

Agreed, if it is enabled for all the stack somehow that would be great..

 

@phil_lira if URP team starts hacking in device-specific pass exclusion rules (done yesterday for Hololens as I can see) why not just hack in Quest as well to get it working? I mean, that's basically what my fork does, but still ... can't really understand why you can't do that for months and then suddenly such a hack is ok.

 

Well hololens is generally for clients with deep pockets so you'll have to accept some bias for some things. I don't consider this unfair in the slightest, it's simply the right decision to have exceptions sometimes.

Looking forward to XR fixes, thanks for the heads up

 

An official fix for this coming in this PR
https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/5900

 

Should be fixed in this commit https://github.com/Unity-Technologi...mmit/42d6b37d0cb6c9a98b24dc3ea914da11e7b7c956

 

Hi,
Do we need special access to view the https://github.com/Unity-Technologies/ScriptableRenderPipeline/ repo? It seems inaccessible from my end (404 Error).

 

Important note: it's not only a move, but actually a new repo with changed history.

 

https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@7.5/changelog/CHANGELOG.html

From URP 7.5.3 changelog, which is compatible with 2019 LTS. Just checking, is this the aforementioned fix by @ROBYER1?

Based on my (newbish) knowledge, there seems to be a few separate issues right now concerning Quest + URP blitting (which disables FFR, and even without FFR would incur a performance cost, if blitting occurs):

• Linear color space: Fixed in 7.5.3 as shown above...?
• Eye resolution not 1: Fixed in 7.5.3
• Post processing: Not yet fixed
• Camera stacking: Not yet fixed
• Render features in general: Not yet fixed

Could anyone confirm this? Thanks

 

Is there any updates to this situation?

 

It seems Linear Color Space is forcing a FinalBlit. We're using 2020.3.18 with URP 10.3.

 

Actually, I was wrong. It was a unique renderer feature we added that was forcing the FinalBlit. We just hardcoded it into URP and forced the FinalBlit to not do its thing.