Mesa (master): i965: Add ARB_occlusion_query support.
eric at anholt.net
Wed Oct 8 07:32:03 PDT 2008
On Wed, 2008-10-08 at 09:29 +0100, Keith Whitwell wrote:
> > + * We use before and after counts when drawing during a query so that
> > + * we don't pick up other clients' query data in ours. To reduce overhead,
> > + * a single BO is used to record the query data for all active queries at
> > + * once. This also gives us a simple bound on how much batchbuffer space is
> > + * required for handling queries, so that we can be sure that we won't
> > + * have to emit a batchbuffer without getting the ending PS_DEPTH_COUNT.
> Won't using a single BO undermine the ability to asynchronously issue
> new queries and read the results of old ones?
> IE. if I do something like:
> -- start A
> -- render 1
> -- end A
> ... time passes ...
> -- start B
> -- render 2
> -- end B
> -- read results of A
> Will the fact that B has been issued and refers to the same buffer as
> A mean that when you want to read the results of A, you'll end up
> waiting not just on render 1, but also render 2?
When you ended A you emitted the end of the query, flushed the
batchbuffer, and dereferenced the context's query BO for just this case.
I could have skipped emitting the query end, since flushing would also
emit the end. I also forgot that I had to squeeze the query end into
the batchbuffer pad, which I'll go fix.
However, I had also missed the feature of the spec that you can only
have one query of a certain type active at a time, so things are a bit
overcomplicated. For 220 lines of code, I'm not too bothered, but I'll
still go clean up my mess.
eric at anholt.net eric.anholt at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/mesa-commit/attachments/20081008/a1b82931/attachment-0001.pgp
More information about the mesa-commit