[Mesa-dev] [PATCH v2 0/9] Add ARB_query_buffer_object (swrast)

[Rafał Mielniczuk]

On 28.03.2014 07:51, Kenneth Graunke wrote:
> 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!
Hi Kenneth! :)
> 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?
 From my understanding it only matters at glGetQueryObject time:

Spec says:
"if a non-zero buffer object is bound as the current query result buffer
then <params> is treated as an offset into the designated buffer object"

It doesn't specifically says when the query buffer object should be bound.

On the other hand some of the examples in the specs bind the buffer two 
times,
first time before the query to set the buffer data, second time before
the glGetQueryObject, which was kind of confusing and seemed redundant,
but I believe it was just made for the clarity of example.
> 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.
We could use intel_emit_linear_blit for DEPTH_COUNT and
think on some other way for TIMESTAMP, or even allow CPU roundtrip for it,
if there is really no other way?
> 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...
Maybe that's the only way for older gen hardware.
> 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.
Thanks for the detailed overview. I will play with it, look into intel 
gpu specs
and try to make it work without roundtrip for some of the querieson my 
Ivy Bridge.
That should make me busy for a couple of days. :)

Thanks!
Rafal
>
> --Ken
>