Re: [PATCHv2] drm/radeon: Move pageflip request from vblank IRQ to ioctl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mit, 2011-07-06 at 19:04 +0100, Simon Farnsworth wrote: 
> The radeon pageflip ioctl handler delayed submitting the pageflip to
> hardware until the vblank IRQ handler. On AMD Fusion (PALM GPU, G-T56N
> CPU), when using a reduced blanking CVT mode, a pageflip submitted to
> hardware in the IRQ handler failed to complete before the end of the
> vblank, resulting in a guaranteed halving of frame rate despite having
> plenty of spare CPU and GPU resource.
> 
> Fix this by moving the pageflip request to hardware into the pageflip
> ioctl, waiting until we are outside a vblank period so that pageflip
> timing is still accurate.
> 
> This doubles my frame rate in reduced blanking modes, and does not
> have an impact on CPU usage in normal blanking modes.
> 
> Signed-off-by: Simon Farnsworth <simon.farnsworth@xxxxxxxxxxxx>
> ---
> Changes from v1:
> 
>  * Replace the fence with a radeon_bo_wait on the new
>    frontbuffer. Discussions on #radeon suggest that this should be
>    good enough to wait for rendering to complete, while not stalling
>    other GPU users.
> 
>  * Change from msleep(), which can take 20ms on HZ=100 systems, to
>    usleep_range, and choose limits that are reasonable for 50Hz or
>    higher displays.
> 
>  drivers/gpu/drm/radeon/radeon.h         |    2 -
>  drivers/gpu/drm/radeon/radeon_display.c |   74 +++++++------------------------
>  drivers/gpu/drm/radeon/radeon_mode.h    |    1 -
>  3 files changed, 16 insertions(+), 61 deletions(-)

Basically looks great (less code that works better, good deal :), just
some nits.


> diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
> index 292f73f..1749239 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -348,27 +313,21 @@ static int radeon_crtc_page_flip(struct drm_crtc *crtc,
>  	struct radeon_framebuffer *new_radeon_fb;
>  	struct drm_gem_object *obj;
>  	struct radeon_bo *rbo;
> -	struct radeon_fence *fence;
>  	struct radeon_unpin_work *work;
> +
>  	unsigned long flags;

Drop this blank line.


> @@ -461,19 +415,24 @@ static int radeon_crtc_page_flip(struct drm_crtc *crtc,
>  		goto pflip_cleanup1;
>  	}
>  
> -	/* 32 ought to cover us */
> -	r = radeon_ring_lock(rdev, 32);
> +	r = radeon_bo_wait(rbo, NULL, false);
>  	if (r) {
> -		DRM_ERROR("failed to lock the ring before flip\n");
> +		DRM_ERROR("failed to wait for rendering to complete before flip\n");
>  		goto pflip_cleanup2;
>  	}

Not sure we should bail on radeon_bo_wait failure here. In the worst
case, an incomplete frame would be visible intermittently?

(Have you tested how userspace copes with bailing here? It actually
looks like the error paths may return 0 to userspace anyway despite not
actually flipping)


> +	/* Wait until we are out of vblank - for normal blanking, this
> +	 * takes a worst case of 0.7ms at 50Hz */
> +	/* Enhancement note: you could calculate how long to sleep
> +	 * for, based on vpos, and use this as the lower bound for
> +	 * usleep_range */
> +	while(radeon_get_crtc_scanoutpos(dev, radeon_crtc->crtc_id, &vpos, &hpos) & DRM_SCANOUTPOS_INVBL)
> +		usleep_range(100, 1000);

If vblank lasts up to on the order of 1ms, this could result in several
wakeups on a regular basis? How about something like usleep_range(1000,
4000), which should normally be longer than vblank but shorter than a
frame?


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux