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. > > Eric, > > 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 Anholt [EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-commit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-commit
