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
