Yes, that's definetely wrong with the newer query types.
And I agree that for most query types, the situation of nothing being drawned
inside the query is too rare to be of concern.
Though I wonder if we should do better in a follow on patch for time queries --
which applications might emit indiscriminately and in huge quantity. Maybe a
shortcut to avoid the overhead of setting up a scene, switch to the rasterizer
threads, wait, etc, will help getting better values. I'm not really sure it is
relevant -- I suppose that a quick experiment with glretrace -pgpu might tell
you whether it makes a difference or not.
Eitherway, should get this in as is for now.
Jose
----- Original Message -----
> From: Roland Scheidegger <srol...@vmware.com>
>
> The result isn't always 0 in this case (depends on query type),
> so instead of special casing this just use the ordinary path (should result
> in correct values thanks to initialization in query_begin/end), just
> skipping the fence wait.
> ---
> src/gallium/drivers/llvmpipe/lp_query.c | 21 +++++++++------------
> 1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_query.c
> b/src/gallium/drivers/llvmpipe/lp_query.c
> index 386639e..1d3edff 100644
> --- a/src/gallium/drivers/llvmpipe/lp_query.c
> +++ b/src/gallium/drivers/llvmpipe/lp_query.c
> @@ -100,20 +100,17 @@ llvmpipe_get_query_result(struct pipe_context *pipe,
> uint64_t *result = (uint64_t *)vresult;
> int i;
>
> - if (!pq->fence) {
> - /* no fence because there was no scene, so results is zero */
> - *result = 0;
> - return TRUE;
> - }
> -
> - if (!lp_fence_signalled(pq->fence)) {
> - if (!lp_fence_issued(pq->fence))
> - llvmpipe_flush(pipe, NULL, __FUNCTION__);
> + if (pq->fence) {
> + /* only have a fence if there was a scene */
> + if (!lp_fence_signalled(pq->fence)) {
> + if (!lp_fence_issued(pq->fence))
> + llvmpipe_flush(pipe, NULL, __FUNCTION__);
>
> - if (!wait)
> - return FALSE;
> + if (!wait)
> + return FALSE;
>
> - lp_fence_wait(pq->fence);
> + lp_fence_wait(pq->fence);
> + }
> }
>
> /* Sum the results from each of the threads:
> --
> 1.7.9.5
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
