[Mesa-dev] [PATCH v2 0/9] Add ARB_query_buffer_object (swrast)
Kenneth Graunke
kenneth at whitecape.org
Thu Mar 27 23:51:11 PDT 2014
On 03/27/2014 01:59 PM, Rafal Mielniczuk wrote:
> Hello,
>
> This is the second version of the series implementing
> ARB_query_buffer_object in mesa.
>
> Main changes to the first version are:
> - Enable extension only for software driver
> - Fix possible segfault in patch #7
> - Fix typos and comment style issues
>
> Drivers, which are not able to implement it without
> CPU roundtrip can just mark extension flag as true
> and use software fallback.
>
> I did not add any ctx.Driver callback for now, as I was
> not sure what would be the required api there.
> Perhaps it would be better to add this while implementing
> gpu acceleration in driver?
>
> I tested the extension by enabling software fallback in i965 driver.
> This is not included in this series.
>
> Thanks,
> Rafal Mielniczuk (9):
> glapi: Add xml infrastructure for ARB_query_buffer_object
> mesa: Add ARB_query_buffer_object extension flag
> mesa: Add QueryBuffer to context
> mesa: Handle QUERY_BUFFER_BINDING in GetIntegerv
> mesa: Handle QUERY_RESULT_NO_WAIT in GetQueryObject{ui64}v
> mesa: Fix typos in function names in queryobj
> mesa: Implement software fallback for ARB_query_buffer_object
> mesa: Enable GL_ARB_query_buffer_object for software drivers
> doc: mark GL_ARB_query_buffer_object as done for swrast
>
> docs/GL3.txt | 2 +-
> src/mapi/glapi/gen/ARB_query_buffer_object.xml | 18 ++++
> src/mapi/glapi/gen/Makefile.am | 1 +
> src/mapi/glapi/gen/gl_API.xml | 4 +
> src/mesa/main/bufferobj.c | 5 ++
> src/mesa/main/extensions.c | 2 +
> src/mesa/main/get.c | 5 ++
> src/mesa/main/get_hash_params.py | 3 +
> src/mesa/main/mtypes.h | 3 +
> src/mesa/main/queryobj.c | 109 +++++++++++++++++++++----
> 10 files changed, 135 insertions(+), 17 deletions(-)
> create mode 100644 src/mapi/glapi/gen/ARB_query_buffer_object.xml
Hi Rafal!
Thanks for doing this! Looking through the spec, I had a few questions.
Are applications required to bind GL_QUERY_BUFFER buffer before starting
a query (and keep it bound for the duration of the query)? Or, does it
only matter at glGetQueryObject time?
I'm guessing it's the latter - otherwise, it sure seems like the spec
would have had to answer what happens if you change/delete it while the
query is active...i.e.
glBindBuffer(GL_QUERY_BUFFER, queryBuffer);
glBeginQuery(GL_SAMPLES_PASSED, queryId);
...
glBindBuffer(GL_QUERY_BUFFER, 0); /* or some other buffer... */
...
glEndQuery(GL_SAMPLES_PASSED);
In i965, we use a buffer object (query->bo - see brw_context.h:846)
during the query. We take an initial snapshot of some counter (i.e.
PS_DEPTH_COUNT for occlusion queries, TIMESTAMP for timer queries) at
BeginQuery time, and a second snapshot at EndQuery time. Both get
stored in query->bo at offsets 0 and 8 (1*sizeof(uint64_t)).
When they ask for the results, we map that buffer and use the CPU to
subtract the two values. So, avoiding a CPU round trip seems tricky.
If we instead zeroed the counters at BeginQuery time, we would have a
single counter that we could possibly blit from query->bo to the
currently bound GL_QUERY_BUFFER via intel_emit_linear_blit. But I don't
think we can do that for the TIMESTAMP register, and doing so would make
implementing some upcoming GL extensions harder.
So, maybe we could bind query->bo as a UBO or TexBO, bind a shader that
would read from there, subtract the two values, and write that to the
GL_QUERY_BUFFER object. This could probably be done by drawing a single
point primitive with a vertex shader and rasterizer discard. This could
work, but it seems pretty ugly...
We might also be able to use
MI_LOAD_REGISTER_MEM/MI_MATH/MI_STORE_REGISTER_MEM on Haswell, but I
don't know how that works yet.
--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140327/e826d28c/attachment.sig>
More information about the mesa-dev
mailing list