[Mesa-dev] [PATCH 7/9] gallium: add a way to store query result into buffer
Ilia Mirkin
imirkin at alum.mit.edu
Mon Jan 11 11:01:42 PST 2016
On Mon, Jan 11, 2016 at 1:53 PM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> On 10.01.2016 00:14, Ilia Mirkin wrote:
>>
>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>> ---
>> src/gallium/docs/source/context.rst | 5 +++++
>> src/gallium/include/pipe/p_context.h | 24 ++++++++++++++++++++++++
>> src/gallium/include/pipe/p_defines.h | 2 ++
>> 3 files changed, 31 insertions(+)
>>
>> diff --git a/src/gallium/docs/source/context.rst
>> b/src/gallium/docs/source/context.rst
>> index 9a32716..a97308a 100644
>> --- a/src/gallium/docs/source/context.rst
>> +++ b/src/gallium/docs/source/context.rst
>> @@ -325,6 +325,11 @@ returned). Otherwise, if the ``wait`` parameter is
>> FALSE, the call
>> will not block and the return value will be TRUE if the query has
>> completed or FALSE otherwise.
>>
>> +``get_query_result_resource`` is used to store the result of a query into
>> +a resource without synchronizing with the CPU. This write will optionally
>> +wait for the query to complete, and will optionally write whether the
>> value
>> +is available instead of the value itself.
>> +
>> The interface currently includes the following types of queries:
>>
>> ``PIPE_QUERY_OCCLUSION_COUNTER`` counts the number of fragments which
>> diff --git a/src/gallium/include/pipe/p_context.h
>> b/src/gallium/include/pipe/p_context.h
>> index be7447d..4f21d37 100644
>> --- a/src/gallium/include/pipe/p_context.h
>> +++ b/src/gallium/include/pipe/p_context.h
>> @@ -150,6 +150,30 @@ struct pipe_context {
>> struct pipe_query *q,
>> boolean wait,
>> union pipe_query_result *result);
>> +
>> + /**
>> + * Get results of a query, storing into resource.
>> + * \param wait if true, this query will block until the result is
>> ready
>> + * \param result_type the type of the value being stored:
>> + * 0 - i32
>> + * 1 - u32
>> + * 2 - i64
>> + * 3 - u64
>
>
> Magic numbers :(
Documented! :)
> Maybe use an enum? Or maybe the signed vs. unsigned distinction isn't really
> needed and you can go with the pipe_index_buffer precedence of using
> result_size instead (4 for i32, 8 for i64).
Seemed overkill to create defines or an enum for this. But I suppose I
can if others also like having enums for small lists of values used in
just a handful of places.
The GL logic clamps i32 and u32 to their respective ranges (on the
upper end). I suspect this is done for a reason and a similar clamping
should be done by this function as well. If we all collectively agree
that we don't care about clamping, result_size sounds good to me.
-ilia
More information about the mesa-dev
mailing list