I still would like to have this for color and combined depth-stencil clears. If either attachment can use pipe->clear, let's use it. I think the only disagreement is over what should happen if there is a partial stencil write mask. The following cases are still okay, aren't they?
1) pipe->clear(COLOR0); clear_with_quad(COLOR1); 2) pipe->clear(COLOR0 | DEPTH | STENCIL); clear_with_quad(COLOR1); 3) pipe->clear(COLOR0); clear_with_quad(COLOR1 | DEPTH | STENCIL); The point is pipe->clear is almost free on drivers which optimize it. clear_with_quad isn't. Marek On Wed, Dec 18, 2013 at 1:04 PM, Jose Fonseca <jfons...@vmware.com> wrote: > If this is such a corner case, that's not worth the diligence, then I think > it might be better to drop the change. > > If it was just software rendering (llvmpipe) I wouldn't mind, as bottlenecks > are elsewhere anyway. My concern is more of principle here: I'm assuming > there is other hardware we care about that has interleaved depth stencil (*), > and whatever the separate depth-stencil hardware has to gain with this > change, the former stands to lose. And this is the sort of precedent what I > want to prevent. > > If it was regressing hardware nobody cares for the sake of hardware that > people do, I'd be fine. What I really don't want is developer A commiting a > change that makes driver X faster but Y slower, then developer B commits a > change that makes Y faster and X slower, and we go around in circles instead > of moving all forward. > > But if I'm wrong -- nobody else cares -- I won't object further. > > Jose > > (*) I only recall AMD having them separate, so I assume e.g., NVIDIA has them > interleaved. And I'm not sure if all have use the fast clear optimization. > > ----- Original Message ----- >> José, is it really worth adding a new cap? The only way to hit both >> pipe->clear and clear_with_quad for depth and stencil, respectively, >> is to have a partial stencil writemask. >> >> Marek >> >> On Fri, Dec 13, 2013 at 5:46 PM, Jose Fonseca <jfons...@vmware.com> wrote: >> > >> > So, if this provides a significant performance difference, then I think the >> > only option to have everybody happy is to have cap to choose the optimal >> > behavior >> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev