Quoting Chad Versace (2017-07-14 23:36:43) > On Wed 12 Jul 2017, Jason Ekstrand wrote: > > Cc: Kenneth Graunke <kenn...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
