Mir

Code review comment for lp:~vanvugt/mir/unocclude

Revision history for this message
Alberto Aguirre (albaguirre) wrote :

 A small renderable hidden behind a larger one
> does not get its texture uploaded on that frame. However this benefit only
> applies to software surfaces where there is an actual "upload", and is
> irrelevant if the foreground is fullscreen because that's already optimized by
> bypass. The benefit of occlusion detection in the non-blocking world seems
> negligible.

A "small" renderable could be simply one pixel less in width and height than the one that occludes it, which could be 2559x1599 in a nexus 10 for example.
It used to be that qualcomm chipsets were all direct rendering implementations, so it WOULD read that texture since we are drawing back to front. Now it seems it can switch between direct and deferred rendering so maybe it's smart enough not to do that anymore.
The Nexus 10 Mali does tile-based deferred rendering (as does the PowerVR stuff) so I suspect it's not a huge impact there either.

You could also get the additional hit of programming the GPU MMU - some architectures will lazily do that (i.e. they will not "upload" program the mmu until a draw command references it).

But we are both speculating - I would like to see some evidence that the occlusion optimization is negligible.

« Back to merge proposal