Arm: Optimize away unnecessary clear empty RenderPass (Vulkan) in 2DRP. #4149
Conversation
…iptableRenderPass can assume responsibility of clearing the target manually.
| @@ -932,7 +932,7 @@ private bool IsRenderPassEnabled(ScriptableRenderPass renderPass) | |||
| void SetRenderPassAttachments(CommandBuffer cmd, ScriptableRenderPass renderPass, ref CameraData cameraData) | |||
| { | |||
| Camera camera = cameraData.camera; | |||
| ClearFlag cameraClearFlag = GetCameraClearFlag(ref cameraData); | |||
| ClearFlag cameraClearFlag = renderPass.overrideCameraClear ? ClearFlag.None : GetCameraClearFlag(ref cameraData); | |||
There was a problem hiding this comment.
in 2D renderer you never care about camera clear flags? In this case I’d rather suggest to add logic for 2D renderer to override functionality of GetCameraClearFlags instead of adding internal API to ScriptableRenderPass.
There was a problem hiding this comment.
So, any feedback on the injected passes issue?. As it stands, either with the current approach or if I override the camera clear flags to NONE in 2DRenderer, an earlier pass happening before Render2DLightingPass would render to a non-cleared camera RT and we would later clear such target overriding whatever was in there. I think the way to go here is to check whether there are ScriptableRenderFeatures queued and decide whether to allow clearing or not based on that. What do you think?
|
Hi! This comment will help you figure out which jobs to run before merging your PR. The suggestions are dynamic based on what files you have changed. URP Depending on the scope of your PR, you may need to run more jobs than what has been suggested. Please speak to your lead or a Graphics SDET (#devs-graphics-automation) if you are unsure. |
The current logic of ScriptableRenderer assumes that RenderPasses using the camera target as colorAttachment will render to it immediately. If that's not the case it will result in empty RenderPasses in Vulkan clearing the RT which will end up in storing and loading to/from memory instead of staying on-chip. This patch gives support to override that logic to assume responsibility of clearing the camera color target and clears the attachments in "Render2DLightingPass.cs" only when needed. The following image shows the impact of this change in GPU counters (measured LostCrypt using Vulkan on a Mali-G77 device).
As we can see, the fragment workloads have been reduced resulting in an improvement of both bandwidth and "GPU Active Cycles".