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.
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.
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.