Is alpha test still "the evil" for mobile ?

So several years ago when there was the first iphones and PowerVR gpu, alpha testing was to be avoided because it had a huge performance hit.
Is this still the case today?
If I wanted to target a broad audience of current low end devices(max 3 years old) and iphones from Iphone 5 and later, is it still a big performance hit?

Or is it like PC now where alpha test is even better performing than alpha blend?

 

I'd say alpha testing should always be faster than alpha blending. The impact of alpha testing compared to opaque rendering could be relatively high on mobile devices where rendering strategies often differ from the desktop approach, but I don't directly see why.

In general, overdraw/fillrate is much more of an issue on mobile than on desktop. That's why post process effects and deferred rendering are generally a no go on mobile. For every pixel on the screen mobile hardware is sometimes only able to do 3-5 color writes with realtime frame rates. On desktop hardware this number is in the 100's.

 

No, on old PowerVR gpu the alpha test had a quite serious hit because it prevented to use some optimization on the graphic pipeline. They say it is common for all Tile based gpu but especially bad for them. I just don't know if newer gpu still have this big drawback, cause I would like to insert some vegetation in the game and alpha blended vegetation really suck.

 

Alpha test is still evil on tile deferred hardware, and always will be due to the hardware design. It will hurt less as those gpus get faster, but it will always hurt. It's all relative though.

 

I guess I need some extensive testing before throwing a lot of alpha test in the game then.

 

I would consider going opaque and stylised.

https://developer.apple.com/library...ProgrammingGuide/Performance/Performance.html

Some more tips.

 

But even so, is alpha blending faster than alpha testing?

 

No I don't think it is but on that hardware a discard or alpha test causes the entire tile to resolve, thus abandoning any rejection methods it might've employed.

 

Alpha blending is very likely to be faster than alpha testing on most mobile hardware. Yes.

Writing to the depth buffer has a greater cost on mobile than on desktop / console, so just avoiding that can often be faster with simple enough fragment shaders. Writing to the depth buffer with a shader that uses alpha testing disables several optimizations making rendering anything else afterward slower. For example alpha testing may disable early z for an entire tile meaning anything that renders after an alpha tested object will render to every pixel it overlaps in that tile regardless of if it's visible or not, where as normally if it's behind something it'll be rejected prior to the fragment shader.

 

Recently in my several 3D mobile game projects.
Although mobile specs enhanced a lot but I'm still keep avoiding alpha testing if possible.
Doesn't means can not use at all but just use if we have really no choices.
Meanwhile researching on shader customization to see what mobile can display.

In additional, I have another question related to this too.
Those 2D sprite images for 2D games. Why they can run so smoothly on mobile?
Aren't they also consider alpha blending / testing? Or because it can be sprite packed?
Please correct me if anything.

 

Alpha blending means you can't use the hardware tile sorter to avoid rendering part of a triangle to the screen where it is occluded by another triangle ie. overdraw.

It applies to any alpha blended geometry. Which includes 'sprites'.

It's not to say you can't feature/use it, just in certain use cases it can be expensive.

If your 2d game's sprites don't cause a lot of overdraw than this will likely not be an "issue" ("issue" is probably the wrong word, more a case you may not care about trying to optimise, say by adding geometry to your sprite to render the inner say 80% as opaque or using geometry to define the edge of the sprite rather than alpha)

 

Plus, Unity has an overdraw optimization in place for sprites already. They do not render a quad, but a "tight mesh" that represents the sprite. This can reduce a significant amount of overdraw. Unfortunately, it does not work with UI images.

https://www.gamasutra.com/blogs/Rub..._SpriteRenderer_vs_UIImage_CanvasRenderer.php

 

Sprites are also generally very simple fragment shaders. Sample a texture from a fixed UV and you're done. Maybe multiply it by a color. Overdraw is a problem, but not that bad. Also generally 2D games completely avoid using the depth buffer which makes them faster to render too as there's no depth to write or test against.

3d games tend to have more complex shaders. Even if it's just a lightmap, that's two textures now being sampled instead of one, but probably also some amount of basic dynamic lighting, etc. Overdraw in this case can have a much more serious impact on performance, plus it usually requires use of the depth buffer to keep proper sorting. Old school PS1 / PS2 era games didn't use a depth buffer, but they also often sorted every triangle in the scene, which Unity does not do.

 

That makes thing a lot more clear bgolus. I understand the assumption that alpha tested geometry does write depth and alpha blended geometry does not. So then it's clear why alpha testing is practically slower than alpha blended.

Writing depth with alpha testing is not required though, so it's the combination that makes it slow. Alpha testing with depth write enabled. Without it depth write enabled I still assume alpha testing is faster than alpha blending.

 

Best case scenario there’s no difference, but it’s more likely alpha testing is still slower with out depth writing. The blend does have some cost associated with it over opaque, but it’s not a lot, especially on GLES 3.0 hardware. But so does pixel rejection. Best case is it’s handed as a blend operation, at which point it’s exactly the same as alpha plus an additional fast conditional operation. Worst case it’s handled as a branch and causes GPU stalls.