[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