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