looking for suggestion whether it is worth implementing a post process FXAA pass on modern mobile GPU's (mainly looking at apple A Series chip), or should i simply use the MSAA. Did a basic test with implementing basic FXAA which took eight neighbouring samples and averaged them for result. The performance of this FXAA was even a bit slower than turning on MSAA. I am using Metal API, if that helps.
$\begingroup$
$\endgroup$
2
-
$\begingroup$ This seems like a very vague question that will attract mostly opinion-based answers. What does "worth it" mean here? Are you asking whether it can be done as fast as MSAA? Or with better or at least similar quality? What does "worth it" mean to you? $\endgroup$– user1118321Commented Sep 10, 2019 at 1:45
-
$\begingroup$ @user1118321 in understand that it is a bit subjective. I mean in my personal testing with even a very basic FXAA implementation (averaging 8 nearest pixels for final color) my performance was slower than 4x MSAA. And the visual quality of MSAA is far better. $\endgroup$– gndpsinghCommented Sep 10, 2019 at 11:08
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
1
Most mobile GPUs use tiled rendering, which can make MSAA surprisingly cheap relative to desktop GPUs. If the app is doing simple forward rendering without filtering/blurring passes, the GPU may be able to do MSAA rasterization and resolve directly on chip (per tile) without ever storing the MSAA samples out to memory. This may make MSAA both faster and less power-hungry than a technique like FXAA that relies on filtering the framebuffer (which necessitates storing it out to memory and reading it back in when sampling).
As for image quality, it's difficult to compare (and is subjective anyway). FXAA might be better at reducing jaggies depending on the MSAA level, but at the cost of over-blurring edges. FXAA can also address shader aliasing, for example aliasing due to specular on a rough normal map and such things, which MSAA won't help with. Ultimately you'll have to make a choice whether the aesthetic benefits (if any) outweigh the increased cost.
answered Sep 10, 2019 at 3:17
-
$\begingroup$ Thank you for shinning light on the Specular scenario limitation with MSAA (no pun intended). I hadn't thought about that. In my testing i have found that MSAA is both faster and better visual result for my use case. Only case when FXAA could work is on a low end phone where MSAA is just not an option, there, using a crude FXAA could be faster with some respite from jaggies. $\endgroup$ Commented Sep 10, 2019 at 11:22
$\begingroup$
$\endgroup$
It's important to understand that "anti-aliasing" techniques like FXAA were invented mainly to deal with the fact that standard methods like multisampling do not work well at all in deferred rendering situations. In order to do MSAA in a deferred renderer, you would need to have all of your G-buffers be multisampled, which dramatically increases the size of those g-buffers. Which puts more pressure on the GPU's memory bandwidth during the lighting passes, since you have that much more data to read. Plus, the lighting passes have to do per-sample rendering, so most of the benefit of MSAA compared to straight super-sampling gets tossed out with lighting passes.
However, all of that is only really true on standard desktop GPUs. Tile-based platforms (commonly found in the mobile space) can potentially avoid the memory cost increase entirely by keeping the multisampled g-buffers within tile memory alone. Of course, only modern APIs like Metal and Vulkan are capable of really expressing this concept at the API level, but the capability is there.
Oh sure, MSAA on a TBR will still require lots more tiles and therefore lighting shader invocations. And the lighting passes still have to do per-sample computations. But the overall performance cost will scale much better than a desktop GPU for deferred rendering, as there will be a lot less memory bandwidth pressure.
Plus, there's the fact that FXAA-style techniques run roughshod over how TBRs work. FXAA-like techniques require reading from neighboring texels, which may be outside of the current tile. Well, that means you have to resolve all of your rendering before doing the FXAA pass. That's a bad thing. By contrast, multisampling, including the multisample resolve operation, can be done in-situ within a given tile.
So it's not really a surprise that FXAA would not yield better performance than even relatively light MSAA on a TBR-style GPU. Especially if you're not using deferred rendering.
