Well, given that Matt said that sorting the polygons in the driver would be a drag I doubt the NV20 will do it. And for those of you who insist that there is a way to do transparency without sorting transparent polygons:
Blending modes can be thought of as binary operations on RGBA values. The specific operation to be performed is determined by glBlendFunc but in the end you have some operation,say # that is used to blend as:
dest = dest # source
Where opaque blending is the obvious operation
dest = source
And drawing a pixel of value source1 and then one of value source2 gives
dest = (dest # source1) # source2
wheras if we draw in the opposite order:
Hopefull it is clear that the order objects are drawn in, in general, matters since the operation # isn’t always (and rarely is) commutative (commutative means a#b=b#a). Additive blending and modulation (componentwise multiplication) are the only two commutative blend modes in common use. Alpha blending is neither commutative nor associative, making it extremely nasty. That means that if we just have a framebuffer, some blending ops and some fragments to draw we’d better make sure we submit them in the order we want them draw (back to front). That’s what the painter’s algorithm and most every software renderer is all about. This is true even if we are doing opaque blending since a#b=b for opaque blending, obviously not a commutative op.
The z-buffer is a special case, in effect, to remove the need to sort opaque objects. It works on the realization that in opaque blending only the frontmost fragment matters at each pixel. Transparency is, almost by definition, the case where more that just the frontmost pixel matters.
A z-buffer-like mechanism that can properly resolve arbitrary blend modes per-pixel would have to store all the fragments that would contribute to a pixel, and once rendering was finished it would have to composite them to the framebuffer, each with its own blend function, in back to front order. This requires potentially unbounded storage per-pixel however (potentially proportional to the depth complexity of non-opaque objects at that pixel). Doing things at the pixel level doesn’t remove the need to depth-sort, it just burdens the harware with doing it per-pixel, and today’s hardware can’t cope just yet. The solution for now is to keep depth-sorting, or to restrict yourself to opaque and commutative blend modes.