[Mesa-dev] [PATCH v3 04/14] i965/bufmgr: Add a BO_ALLOC_ZEROED flag

Chris Wilson chris at chris-wilson.co.uk
Sat Jul 15 09:14:53 UTC 2017


Quoting Chad Versace (2017-07-14 23:36:43)
> On Wed 12 Jul 2017, Jason Ekstrand wrote:
> > Cc: Kenneth Graunke <kenneth at whitecape.org>
> > 
> > ---
> >  src/mesa/drivers/dri/i965/brw_bufmgr.c | 28 ++++++++++++++++++++++++++--
> >  src/mesa/drivers/dri/i965/brw_bufmgr.h |  1 +
> >  2 files changed, 27 insertions(+), 2 deletions(-)
> 
> 
> > +      /* All new BOs we get from the kernel are zeroed, so we don't need to
> > +       * worry about that here.
> > +       */
> 
> Assuming the above comment is true, then

It is. Strict policy that all new buffers handed back are zeroed. We've
proposed new interfaces that relax this policy when the user requests
private buffers returned, i.e. just moving the userspace bo cache into
the kernel as a page cache (primarily to keep WC pages around). There is
little incentive for gl/vk(client) as the caching there is pretty
effective, but not everything is as smart. There's also the issue that
most WC pages are shared and therefore not suitable for the private
pool, which kind of rules out the Android problem where it would pass a
stream of buffers from clients to the display server with no recycling.
Or it used to at least.

TLDR; all new buffers are zero and may still reside in the CPU cache.
-Chris


More information about the mesa-dev mailing list