On 02/26/2015 05:24 AM, Chris Wilson wrote:
> When rendering to an fbo, even though it may be acting as a winsys
> frontbuffer or just generally, we never throttle. However, when rendering
> to an fbo, there is no natural frame boundary. Conventionally we use
> SwapBuffers and glFinish, but potential callers avoid often glFinish for
> being too heavy handed (waiting on all outstanding rendering to complete).
> The kernel provides a soft-throttling option for this case that waits for
> rendering older than 20ms to be complete (that's a little too lax to be
> used for swapbuffers, but is here a useful safety net). The remaining
> choice is then either never to throttle, throttle after every draw call,
> or at an intermediate user defined point such as glFlush and thus all the
> implied flushes. This patch opts for the latter.
> 
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
> Cc: Kenneth Graunke <kenn...@whitecape.org>
> Cc: Ben Widawsky <b...@bwidawsk.net>
> Cc: Kristian Høgsberg <k...@bitplanet.net>
> ---
>  src/mesa/drivers/dri/i965/brw_context.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index c844888..f190df1 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -229,11 +229,14 @@ static void
>  intel_glFlush(struct gl_context *ctx)
>  {
>     struct brw_context *brw = brw_context(ctx);
> +   __DRIscreen *psp = brw->intelScreen->driScrnPriv;
>  
>     intel_batchbuffer_flush(brw);
>     intel_flush_front(ctx);
>     if (brw_is_front_buffer_drawing(ctx->DrawBuffer))
>        brw->need_throttle = true;
> +
> +   drmCommandNone(psp->fd, DRM_I915_GEM_THROTTLE);
>  }
>  
>  static void
> 

glFlush should not wait for previous rendering to complete. It's not supposed
to be a blocking operation.

Why this patch? What are you trying to fix?
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to