why the alphablend is a better choice than alphatest to implement transparent on mobile device?

discard is GLSL (openGL based shading language) / clip is HLSL (directX based shading language) -> both refer to the clipping operation that can be used for alpha testing.

The reason why alpha blend is "sometimes" the better choice is that for example powerVR gpus use so called "Deferred Tile-Based-Rendering". The gpu collects triangle data and at some point executes pixel processing. But before going there powerVR chips implement an additional optimization stage (this is what the "Deferred" part refers to) that determines which parts of the "Tile" should actually be drawn so we don't shade them multiple times for no reason aka overdraw (overdraw mostly refers to the redundant multiple framebuffer writes but shading is also part of this problem).

So when using clipping operations the gpu won't be able to do this optimization anymore. Note that on every gpu this results in a performance reduction because of early-Z since you can't determine which pixel should be culled before going through the pixel pipeline. But on powerVR chips this is even more of a problem due to the aforementioned "pixel overlap determination stage".

Why exactly alpha blend is faster in this case I'm not quite sure...my guess is that the blend operation in a tile-based-rendering environment is fairly fast since you don't blend into the actual framebuffer but the small on-chip-memory that holds the tile which as it seems may still be faster than opaque rendering without the hidden-surface-removal stage.

I hope I got all of this right since I'm still in the process of learning so if I made a mistake someone correct me please

Note that you may use alpha testing (clip / discard) with alpha blending, they aren't mutually exclusive.

Cheers!

discard is GLSL (openGL based shading language) / clip is HLSL (directX based shading language) -> both refer to the clipping operation that can be used for alpha testing.

The reason why alpha blend is "sometimes" the better choice is that for example powerVR gpus use so called "Deferred Tile-Based-Rendering". The gpu collects triangle data and at some point executes pixel processing. But before going there powerVR chips implement an additional optimization stage (this is what the "Deferred" part refers to) that determines which parts of the "Tile" should actually be drawn so we don't shade them multiple times for no reason aka overdraw (overdraw mostly refers to the redundant multiple framebuffer writes but shading is also part of this problem).

So when using clipping operations the gpu won't be able to do this optimization anymore. Note that on every gpu this results in a performance reduction because of early-Z since you can't determine which pixel should be culled before going through the pixel pipeline. But on powerVR chips this is even more of a problem due to the aforementioned "pixel overlap determination stage".

Why exactly alpha blend is faster in this case I'm not quite sure...my guess is that the blend operation in a tile-based-rendering environment is fairly fast since you don't blend into the actual framebuffer but the small on-chip-memory that holds the tile which as it seems may still be faster than opaque rendering without the hidden-surface-removal stage.

I hope I got all of this right since I'm still in the process of learning so if I made a mistake someone correct me please

Actually, I think that any sort of blending is just as damaging to the hidden-surface-removal techniques used by PowerVR chips as discard is.

I believe the key reason alpha blending can be more efficient than alpha testing is to do with when the z-test/z-write is done.

With alpha blending, the z-testing and any z-write can be done before the fragment shader is run.

With alpha testing, the z-write can't be done until after the fragment shader is run, because the fragment shader needs to be executed before the GPU knows whether the z-write is needed or not. I believe the GPU will defer both the z-test and the z-write until after the fragment shader, which means that a lot more fragments have to be processed with alpha test on, which can be quite damaging for chips with relatively poor fill-rates.

I can't remember the exact mechanism, but I do also remember reading what lipsryme is saying -- that alpha testing in particular is a special case that screws with the PowerVR tiled architectures, and that it's often better to instead just blend with alpha=0.

If anyone's got a link to an explanation, I'd be interested in (re)reading it, because this seems quite unintuitive...

[edit] From memory:

-Opaque geometry uses some clever hidden-surface-removal algorithm to completely avoid overdraw.

-Alpha blending is done separately, and is much faster than regular GPUs due to only working with an on-chip tile of the frame-buffer, rather than using the frame-buffer in RAM.

-If you use discard in any opaque geometry, then the clever hidden-surface-removal algorithm is disabled for all opaque geometry.

[edit2] Ah - alpha test means that you're not certain about a depth value until after the pixel shader executes, which probably messes with HSR. Alpha blending always writes the depth value even when alpha=0, so depth sorting can still occur before the pixel shader.

Alpha testing hasn't been supported in OpenGL ES since 2.0 anyway; you're required to implement it manually using the discard operation. Discard will essentially force that draw call to slow path, just like alpha blend. In those cases, no hidden surface removal is available. You may want to review the Smedberg recommendations about how to handle the various cases.

Like
5Likes 6Likes
Like

Posted Yesterday, 01:28 PM

discard is GLSL (openGL based shading language) / clip is HLSL (directX based shading language) -> both refer to the clipping operation that can be used for alpha testing.

not true, discard and clip is in HLSL (they do little different things)

discard :

http://msdn.microsoft.com/en-us/library/windows/desktop/bb943995%28v=vs.85%29.aspx

clip:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb204826%28v=vs.85%29.aspx