Hi,
We noticed a commit related to ARMASR in UE5.6, which appears to be an optimization.
[Image Removed]
（7d765815f22bf555c6685a0a71a75bd08175697c）
Our game uses ASR, as it maintains good image quality even at lower ScreenPercentage settings. However, in our tests, it hasn’t provided much performance improvement and sometimes even leads to performance degradation, particularly due to increased bandwidth in the ASR’s final pass, because four upscaled rt output. Since this commit seems to be a technical submission related to Fortnite, we would like to ask:
(1) Is there any optimization information or guidance available for ASR?
(2) Will there be further optimization updates for ASR in the future?
Thanks
[Attachment Removed]
Hi Sanning,
In general, ARM ASR will not perform better than UE’s TAA, however, final image quality is ofter superior at lower screen percentages.
In the latest release of the plugin/libraries, ARM has added an Ultra Performance quality level which may help if you haven’t tried it yet. We are however not aware of ARM’s future optimization roadmap for the plugin.
Best regards.
[Attachment Removed]
Hi Sanning,
Looking at the code, I may have been transmitted erroneous information. It would appear that Single Pass deferred with subpasses would still be used on Vulkan devices currently. so the optimization would apply.
Best regards.
[Attachment Removed]
Thank you for your reply.
We have tried the Ultra Performance quality of ASR, but it still did not yield the expected improvement. According to Epic’s official sharing, ASR has been successfully implemented in Fortnite and has achieved significant performance gains, which is inconsistent with our test results. We observed this commit and suspect that there may have been some custom modifications to ASR in Fortnite. Would it be possible to inquire with Brad Blankenship about the details of these changes?
[Attachment Removed]
Hi Sanning,
The development team did see some performance improvements SPECIFICALLY with many advanced features enabled (SSAO, SSR, Epic Settings for all materials, high resolution textures for all builds, etc.). But, it was very modest gains. As for the different quality modes for Arm ASR, here are the differences between the shader quality levels and the expected resolution quality levels.
- The shader quality levels essentially cut out more and more of the color correcting, lighting, and velocity adjusting features for ArmASR as you go to more performant.
- The expected “view” or “screen” quality features are the expected resolutions they should be running at (which should mimic FSR quality resolutions as close as possible, as that’s what ASR is based on).
[Image Removed]
One finding was that with ArmASR is that it does add RenderThread overhead which is pretty substantial. If you are not RenderThread bound, it’s unlikely to help game performance at all. There are some tricks the devs came up with that DO help, but they are minor and quite a bit of work to really get working well:
- Create a scheme for caching the various render targets ASR creates every frame. Right now they are created raw and unpooled, so this can be a potential savings.
- Combine some of the different RT passes that can easily be combined. This was a piece of work we have in our backlog to test.
Best regards.
[Attachment Removed]
Thank you for your suggestion. We do want to optimize ASR performance. We would like to inquire about the internal changes made by Fortnite about the submitted code modification’s detail.
[Image Removed]
This submission adds the PrePostProcessPassMobile_RenderThread interface to ISceneViewExtension. Compared to the PC implementation, this FUNCTION set the GBuffer‘s info from BasePass as the Input for PostProcess Pass. However, on Mobile, since SUBPASS are used, GBuffer information is not stored, so this step was previously absent in the mobile rendering pipeline. Does this change imply that Fortnite is using a deferred rendering pipeline that is not optimized by SUBPASS ? Furthermore, based on the Epic share, it seems Mobile is utilizing ReactiveMask, which also require accessing GBuffer contents. We are very interested in this submission and the underlying changes. It would be greatly appreciated if you could provide detailed information about this change and the rationale behind the function implementation.
[Attachment Removed]
Hi Sanning,
Indeed, we are now using the Mobile Multi-Pass Deferred renderer, which is accessible in 5.7. That makes those changes redundant, as we now no longer use the sub-pass optimization.
Best regards.
[Attachment Removed]
Hi Stephane,
That sounds intriguing. I’d like to ask, in what situations would it be better not to use Subpass?
As we are planning to test multi-pass support on mobile, could you please provide the relevant changelist numbers from version 5.7 for our reference?
[Attachment Removed]