[Mesa-dev] [PATCH 9/9] st/mesa: add query buffer support

Ilia Mirkin imirkin at alum.mit.edu
Sun Jan 10 08:51:36 PST 2016


On Sun, Jan 10, 2016 at 8:49 AM, Marek Olšák <maraeo at gmail.com> wrote:
> On Sun, Jan 10, 2016 at 6:14 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>> ---
>>  src/mesa/state_tracker/st_cb_bufferobjects.c  |   3 +
>>  src/mesa/state_tracker/st_cb_queryobj.c       | 100 +++++++++++++++++++++++++-
>>  src/mesa/state_tracker/st_cb_texturebarrier.c |   3 +
>>  src/mesa/state_tracker/st_extensions.c        |   1 +
>>  4 files changed, 105 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c b/src/mesa/state_tracker/st_cb_bufferobjects.c
>> index 8ca7e4c..86a09fe 100644
>> --- a/src/mesa/state_tracker/st_cb_bufferobjects.c
>> +++ b/src/mesa/state_tracker/st_cb_bufferobjects.c
>> @@ -231,6 +231,9 @@ st_bufferobj_data(struct gl_context *ctx,
>>     case GL_PARAMETER_BUFFER_ARB:
>>        bind = PIPE_BIND_COMMAND_ARGS_BUFFER;
>>        break;
>> +   case GL_QUERY_BUFFER:
>> +      bind = PIPE_BIND_QUERY_BUFFER;
>> +      break;
>>     default:
>>        bind = 0;
>>     }
>> diff --git a/src/mesa/state_tracker/st_cb_queryobj.c b/src/mesa/state_tracker/st_cb_queryobj.c
>> index aafae16..e39341c 100644
>> --- a/src/mesa/state_tracker/st_cb_queryobj.c
>> +++ b/src/mesa/state_tracker/st_cb_queryobj.c
>> @@ -39,9 +39,11 @@
>>  #include "pipe/p_context.h"
>>  #include "pipe/p_defines.h"
>>  #include "pipe/p_screen.h"
>> +#include "util/u_inlines.h"
>>  #include "st_context.h"
>>  #include "st_cb_queryobj.h"
>>  #include "st_cb_bitmap.h"
>> +#include "st_cb_bufferobjects.h"
>>
>>
>>  static struct gl_query_object *
>> @@ -94,7 +96,8 @@ st_BeginQuery(struct gl_context *ctx, struct gl_query_object *q)
>>     switch (q->Target) {
>>     case GL_ANY_SAMPLES_PASSED:
>>     case GL_ANY_SAMPLES_PASSED_CONSERVATIVE:
>> -      /* fall-through */
>> +      type = PIPE_QUERY_OCCLUSION_PREDICATE;
>> +      break;
>>     case GL_SAMPLES_PASSED_ARB:
>>        type = PIPE_QUERY_OCCLUSION_COUNTER;
>>        break;
>> @@ -271,7 +274,7 @@ st_WaitQuery(struct gl_context *ctx, struct gl_query_object *q)
>>     {
>>        /* nothing */
>>     }
>> -
>> +
>>     q->Ready = GL_TRUE;
>>  }
>>
>> @@ -303,6 +306,98 @@ st_GetTimestamp(struct gl_context *ctx)
>>     }
>>  }
>>
>> +static void
>> +st_StoreQueryResult(struct gl_context *ctx, struct gl_query_object *q,
>> +                    struct gl_buffer_object *buf, intptr_t offset,
>> +                    GLenum pname, GLenum ptype)
>> +{
>> +   struct pipe_context *pipe = st_context(ctx)->pipe;
>> +   struct st_query_object *stq = st_query_object(q);
>> +   struct st_buffer_object *stObj = st_buffer_object(buf);
>> +   boolean wait = pname == GL_QUERY_RESULT;
>> +   unsigned result_type;
>> +   int index;
>> +
>> +   /* GL_QUERY_TARGET is a bit of an extension since it has nothing to
>> +    * do with the GPU end of the query. Write it in "by hand".
>> +    */
>> +   if (pname == GL_QUERY_TARGET) {
>> +      /* Assume that the data must be LE. The endianness situation wrt CPU and
>> +       * GPU is incredibly confusing, but the vast majority of GPUs are
>> +       * LE. When a BE one comes along, this needs some form of resolution.
>> +       */
>> +      unsigned data[2] = { CPU_TO_LE32(q->Target), 0 };
>> +      pipe_buffer_write(pipe, stObj->buffer, offset,
>> +                        (ptype == GL_INT64_ARB ||
>> +                         ptype == GL_UNSIGNED_INT64_ARB) ? 8 : 4,
>> +                        data);
>
> It would be better to use clear_buffer here, which would also avoid CPU_TO_LE32.

Would it? You could argue that the driver should byteswap the data
when receiving R32_INT data, but there is no R64_INT format, so it
wouldn't work for the 64-bit value case. (And if I say it's RG32_INT,
it won't realize that it's a single value rather than 2, again ending
up with the wrong data.)

>
> Other than that, this series looks good.

Huh... I was expecting more pushback on esp the gallium interface...
Oh well, I'll take it.

Thanks!

  -ilia


More information about the mesa-dev mailing list