Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 18/29] drm/i915: Delay allocation of stolen space for FBC
Date: Mon, 20 Aug 2012 21:51:42 +0200	[thread overview]
Message-ID: <20120820195142.GG5170@phenom.ffwll.local> (raw)
In-Reply-To: <1344696088-24760-19-git-send-email-chris@chris-wilson.co.uk>

On Sat, Aug 11, 2012 at 03:41:17PM +0100, Chris Wilson wrote:
> As we may wish to wrap regions preallocated by the BIOS, we need to do
> that before carving out contiguous chunks of stolen space for FBC.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Some comments inline below.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_drv.h        |    1 +
>  drivers/gpu/drm/i915/i915_gem_stolen.c |  114 +++++++++++++++++---------------
>  drivers/gpu/drm/i915/intel_display.c   |    3 +
>  drivers/gpu/drm/i915/intel_pm.c        |   13 ++--
>  4 files changed, 70 insertions(+), 61 deletions(-)
> 

[snip]

> +int i915_gem_stolen_setup_compression(struct drm_device *dev)
> +{
> +	struct drm_i915_private *dev_priv = dev->dev_private;
> +	struct drm_mm_node *entry;
> +	unsigned long size;
> +
> +	if (dev_priv->mm.stolen_base == 0)
> +		return 0;
> +
> +	if (dev_priv->cfb_size)
> +		return dev_priv->cfb_size;
> +
> +	/* Try to set up FBC with a reasonable compressed buffer size */
> +	size = 0;
> +	list_for_each_entry(entry, &dev_priv->mm.stolen.hole_stack, hole_stack) {
> +		unsigned long hole_start = entry->start + entry->size;
> +		unsigned long hole_end = list_entry(entry->node_list.next,
> +						    struct drm_mm_node,
> +						    node_list)->start;
> +		unsigned long hole_size = hole_end - hole_start;

This feels a bit to much munging around in drm_mm internals. What about a
drm_mm_for_each_hole(entry, mm, hole_start, hole_end)
#define helper?

> +		if (hole_size > size)
> +			size = hole_size;
> +	}
> +
> +	/* Try to get a 32M buffer... */
> +	if (size > (36*1024*1024))
> +		size = 32*1024*1024;
> +	else /* fall back to 3/4 of the stolen space */
> +		size = size * 3 / 4;
> +
> +	return i915_setup_compression(dev, size);
>  }
>  
>  void intel_modeset_gem_init(struct drm_device *dev)

[snap]

> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 3021c18..6f0f498 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -438,12 +438,6 @@ void intel_update_fbc(struct drm_device *dev)
>  		dev_priv->no_fbc_reason = FBC_MODULE_PARAM;
>  		goto out_disable;
>  	}
> -	if (intel_fb->obj->base.size > dev_priv->cfb_size) {
> -		DRM_DEBUG_KMS("framebuffer too large, disabling "
> -			      "compression\n");
> -		dev_priv->no_fbc_reason = FBC_STOLEN_TOO_SMALL;
> -		goto out_disable;
> -	}
>  	if ((crtc->mode.flags & DRM_MODE_FLAG_INTERLACE) ||
>  	    (crtc->mode.flags & DRM_MODE_FLAG_DBLSCAN)) {
>  		DRM_DEBUG_KMS("mode incompatible with compression, "
> @@ -477,6 +471,13 @@ void intel_update_fbc(struct drm_device *dev)
>  	if (in_dbg_master())
>  		goto out_disable;
>  
> +	if (intel_fb->obj->base.size > i915_gem_stolen_setup_compression(dev)) {
> +		DRM_DEBUG_KMS("framebuffer too large, disabling "
> +			      "compression\n");
> +		dev_priv->no_fbc_reason = FBC_STOLEN_TOO_SMALL;
> +		goto out_disable;
> +	}

I couldn't figure out why this block here had to move ... please enlighten
me.

> +
>  	/* If the scanout has not changed, don't modify the FBC settings.
>  	 * Note that we make the fundamental assumption that the fb->obj
>  	 * cannot be unpinned (and have its GTT offset and fence revoked)
> -- 
> 1.7.10.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

  reply	other threads:[~2012-08-20 19:51 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-11 14:40 Stolen pages, with a little surprise Chris Wilson
2012-08-11 14:41 ` [PATCH 01/29] drm/i915: Track unbound pages Chris Wilson
2012-08-20  9:00   ` [PATCH 1/2] drm/i915: move functions around Daniel Vetter
2012-08-20  9:00     ` [PATCH 2/2] drm/i915: Track unbound pages Daniel Vetter
2012-08-20  9:23       ` [PATCH] Add some sanity checks to unbound tracking Chris Wilson
2012-08-20  9:36       ` [PATCH 2/2] drm/i915: Track unbound pages Chris Wilson
2012-08-20  9:42         ` Daniel Vetter
2012-08-11 14:41 ` [PATCH 02/29] drm/i915: Show (count, size) of purgeable objects in i915_gem_objects Chris Wilson
2012-08-20  9:04   ` Daniel Vetter
2012-08-20  9:17     ` Chris Wilson
2012-08-11 14:41 ` [PATCH 03/29] drm/i915: Show pin count in debugfs Chris Wilson
2012-08-11 14:41 ` [PATCH 04/29] drm/i915: Try harder to allocate an mmap_offset Chris Wilson
2012-08-20  9:37   ` Daniel Vetter
2012-08-20 11:31     ` Chris Wilson
2012-08-11 14:41 ` [PATCH 05/29] drm/i915: Only pwrite through the GTT if there is space in the aperture Chris Wilson
2012-08-11 14:41 ` [PATCH 06/29] drm/i915: Protect private gem objects from truncate (such as imported dmabuf) Chris Wilson
2012-08-11 14:41 ` [PATCH 07/29] drm/i915: Extract general object init routine Chris Wilson
2012-08-24  0:05   ` Daniel Vetter
2012-08-11 14:41 ` [PATCH 08/29] drm/i915: Introduce drm_i915_gem_object_ops Chris Wilson
2012-08-20 19:35   ` Daniel Vetter
2012-08-11 14:41 ` [PATCH 09/29] drm/i915: Pin backing pages whilst exporting through a dmabuf vmap Chris Wilson
2012-08-11 14:41 ` [PATCH 10/29] drm/i915: Pin backing pages for pwrite Chris Wilson
2012-08-11 14:41 ` [PATCH 11/29] drm/i915: Pin backing pages for pread Chris Wilson
2012-08-11 14:41 ` [PATCH 12/29] drm/i915: Replace the array of pages with a scatterlist Chris Wilson
2012-08-11 14:41 ` [PATCH 13/29] drm/i915: Convert the dmabuf object to use the new i915_gem_object_ops Chris Wilson
2012-08-11 14:41 ` [PATCH 14/29] drm: Introduce drm_mm_create_block() Chris Wilson
2012-08-11 14:41 ` [PATCH 15/29] drm/i915: Fix detection of stolen base for gen2 Chris Wilson
2012-08-11 14:41 ` [PATCH 16/29] drm/i915: Fix location of stolen memory register for SandyBridge+ Chris Wilson
2012-08-20 19:38   ` Daniel Vetter
2012-08-22 15:54     ` Chris Wilson
2012-08-11 14:41 ` [PATCH 17/29] drm/i915: Avoid clearing preallocated regions from the GTT Chris Wilson
2012-08-11 14:41 ` [PATCH 18/29] drm/i915: Delay allocation of stolen space for FBC Chris Wilson
2012-08-20 19:51   ` Daniel Vetter [this message]
2012-08-22 15:51     ` Chris Wilson
2012-08-11 14:41 ` [PATCH 19/29] drm/i915: Allow objects to be created with no backing pages, but stolen space Chris Wilson
2012-08-11 14:41 ` [PATCH 20/29] drm/i915: Differentiate between prime and stolen objects Chris Wilson
2012-08-11 14:41 ` [PATCH 21/29] drm/i915: Support readback of stolen objects upon error Chris Wilson
2012-08-11 14:41 ` [PATCH 22/29] drm/i915: Handle stolen objects in pwrite Chris Wilson
2012-08-20 19:56   ` Daniel Vetter
2012-08-22 15:47     ` Chris Wilson
2012-08-30 15:09     ` Chris Wilson
2012-08-11 14:41 ` [PATCH 23/29] drm/i915: Handle stolen objects for pread Chris Wilson
2012-08-11 14:41 ` [PATCH 24/29] drm/i915: Introduce i915_gem_object_create_stolen() Chris Wilson
2012-08-11 14:41 ` [PATCH 25/29] drm/i915: Allocate fbcon from stolen memory Chris Wilson
2012-08-11 14:41 ` [PATCH 26/29] drm/i915: Allocate ringbuffers " Chris Wilson
2012-08-11 14:41 ` [PATCH 27/29] drm/i915: Allocate overlay registers " Chris Wilson
2012-08-20 21:17   ` Daniel Vetter
2012-08-22 15:45     ` Chris Wilson
2012-08-22 16:26       ` Daniel Vetter
2012-08-11 14:41 ` [PATCH 28/29] drm/i915: Use a slab for object allocation Chris Wilson
2012-08-11 14:41 ` [PATCH 29/29] drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl Chris Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120820195142.GG5170@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox