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.xmlHi 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
