When modeling something like a hair or foliage using textures with alpha value for offline or real-time rendering, it seems to be common practice among computer modelers to try to minimize the amount of alpha in the textures, referring to it being very GPU intensive. I wonder if this is true for both alpha testing and alpha blending techniques? With alpha blending it's pretty clear that the additional alpha would result in more fragments having to be alpha blended. Also if order-independent transparency techniques are used, I imagine more alpha would make it slower (?). With alpha testing however we just discard fragments based on an alpha threshold. But I wonder if this process is GPU intensive?
I would say the reason for reducing cases of alpha blending (or testing) has less to do with the cost of the actual read-modify-write but more to do with increasing the use of early Z testing that's available in either, say, a TBDR system (eg PowerVR) or in systems with hierarchical Z.
For early Z, which can reject a significant amount of otherwise redundant work, the driver/API needs to know the geometry is 100% opaque. As soon as there is a chance of a blend, the early-Z probably needs to be disabled. Note that its not just the read-modify-write we should be concerned about - early-Z often avoids running potentially V. expensive shaders.
For cases where there is alpha tested geometry, e.g. a leaves of a tree, it may be beneficial to replace, say, every leaf that's modelled with a pair of alpha blended triangles with multiple triangles so that some of those tris are guaranteed to be 100% opaque. All the opaque tris should be batched together and rendered first as opaque.