Quoting Kenneth Graunke (2018-10-06 02:57:29) > On Tuesday, October 2, 2018 11:06:23 AM PDT Chris Wilson wrote: > > Reuse the same query object buffer for multiple queries within the same > > batch. > > > > A task for the future is propagating the GL_NO_MEMORY errors. > > > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > > Cc: Kenneth Graunke <kenn...@whitecape.org> > > Cc: Matt Turner <matts...@gmail.com> > > --- > > src/mesa/drivers/dri/i965/brw_context.c | 3 ++ > > src/mesa/drivers/dri/i965/brw_context.h | 10 +++-- > > src/mesa/drivers/dri/i965/brw_queryobj.c | 16 +++---- > > src/mesa/drivers/dri/i965/gen6_queryobj.c | 51 ++++++++++++++++++----- > > 4 files changed, 59 insertions(+), 21 deletions(-) > > Don't want to do this. This means that WaitQuery will wait on the whole > group of packed queries instead of just the one the app asked about. > > Vulkan has to pack queries by design, and it turns out this was a real > issue there. See b2c97bc789198427043cd902bc76e194e7e81c7d. Jason ended > up making it busy-wait to avoid bo_waiting on the entire pool, and it > improved Serious Engine performance by 20%. > > We could busy-wait in GL too, for lower latency but more CPU waste, > but I think I prefer separate BOs + bo_wait.
It's the same latency for wait as a new BO is used for each batch, and waits are on the batch fence not the individual write into the query batch. (So no change whatsoever for waits from the current code.) Polling is improved as we there we can check the individual fence. Pipelined is unaffected. Now we could keep the query buffer across multiple batches and use fences (userspace seqno + batch handles) to poll or wait on the partial writes. -Chris _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
