intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Paulo Zanoni <paulo.r.zanoni@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/7] drm/i915: don't allocate fbcon from stolen memory if it's too big
Date: Thu, 8 Oct 2015 13:19:27 -0700	[thread overview]
Message-ID: <5616CFCF.7070100@virtuousgeek.org> (raw)
In-Reply-To: <1443023547-19896-4-git-send-email-paulo.r.zanoni@intel.com>

On 09/23/2015 08:52 AM, Paulo Zanoni wrote:
> Technology has evolved and now we have eDP panels with 3200x1800
> resolution. In the meantime, the BIOS guys didn't change the default
> 32mb for stolen memory. On top of that, we can't assume our users will
> be able to increase the default stolen memory size to more than 32mb -
> I'm not even sure all BIOSes allow that.
> 
> So just the fbcon buffer alone eats 22mb of my stolen memroy, and due
> to the BDW/SKL restriction of not using the last 8mb of stolen memory,
> all that's left for FBC is 2mb! Since fbcon is not the coolest feature
> ever, I think it's better to save our precious stolen resource to FBC
> and the other guys.
> 
> On the other hand, we really want to use as much stolen memory as
> possible, since on some older systems the stolen memory may be a
> considerable percentage of the total available memory.
> 
> This patch tries to achieve a little balance using a simple heuristic:
> if the fbcon wants more than half of the available stolen memory,
> don't use stolen memory in order to leave some for FBC and the other
> features.
> 
> The long term plan should be to implement a way to set priorities for
> stolen memory allocation and then evict low priority users when the
> high priority ones need the memory. While we still don't have that,
> let's try to make FBC usable with the simple solution.
> 
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c |  7 +++++++
>  drivers/gpu/drm/i915/intel_fbdev.c   | 10 ++++++++--
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 2a1fab3..24b8a72 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2486,6 +2486,7 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
>  			      struct intel_initial_plane_config *plane_config)
>  {
>  	struct drm_device *dev = crtc->base.dev;
> +	struct drm_i915_private *dev_priv = to_i915(dev);
>  	struct drm_i915_gem_object *obj = NULL;
>  	struct drm_mode_fb_cmd2 mode_cmd = { 0 };
>  	struct drm_framebuffer *fb = &plane_config->fb->base;
> @@ -2498,6 +2499,12 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
>  	if (plane_config->size == 0)
>  		return false;
>  
> +	/* If the FB is too big, just don't use it since fbdev is not very
> +	 * important and we should probably use that space with FBC or other
> +	 * features. */
> +	if (size_aligned * 2 > dev_priv->gtt.stolen_usable_size)
> +		return false;
> +
>  	obj = i915_gem_object_create_stolen_for_preallocated(dev,
>  							     base_aligned,
>  							     base_aligned,
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
> index 6532912..4fd5fdf 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -121,8 +121,9 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
>  		container_of(helper, struct intel_fbdev, helper);
>  	struct drm_framebuffer *fb;
>  	struct drm_device *dev = helper->dev;
> +	struct drm_i915_private *dev_priv = to_i915(dev);
>  	struct drm_mode_fb_cmd2 mode_cmd = {};
> -	struct drm_i915_gem_object *obj;
> +	struct drm_i915_gem_object *obj = NULL;
>  	int size, ret;
>  
>  	/* we don't do packed 24bpp */
> @@ -139,7 +140,12 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
>  
>  	size = mode_cmd.pitches[0] * mode_cmd.height;
>  	size = PAGE_ALIGN(size);
> -	obj = i915_gem_object_create_stolen(dev, size);
> +
> +	/* If the FB is too big, just don't use it since fbdev is not very
> +	 * important and we should probably use that space with FBC or other
> +	 * features. */
> +	if (size * 2 < dev_priv->gtt.stolen_usable_size)
> +		obj = i915_gem_object_create_stolen(dev, size);
>  	if (obj == NULL)
>  		obj = i915_gem_alloc_object(dev, size);
>  	if (!obj) {
> 

I agree with Chris that we should make this smarter too, but I don't
think this hurts in the meantime, so:

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>

Might be nice to macro-ize the size comparison too, both for readability
and to change our threshold in one place if we ever need to.

Thanks,
Jesse
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2015-10-08 20:18 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-23 15:52 [PATCH 0/7] FBC again: stolen + SKL fixes Paulo Zanoni
2015-09-23 15:52 ` [PATCH 1/7] drm/i915: fix CFB size calculation Paulo Zanoni
2015-09-23 16:58   ` Chris Wilson
2015-09-24 17:07   ` Ville Syrjälä
2015-09-23 15:52 ` [PATCH 2/7] drm/i915: don't use the first stolen page on Broadwell Paulo Zanoni
2015-09-23 16:55   ` Chris Wilson
2015-09-28  8:51     ` Daniel Vetter
2015-09-23 15:52 ` [PATCH 3/7] drm/i915: don't allocate fbcon from stolen memory if it's too big Paulo Zanoni
2015-09-23 16:54   ` Chris Wilson
2015-09-28  8:54     ` Daniel Vetter
2015-09-28  9:09       ` Chris Wilson
2015-09-29 14:26         ` Daniel Vetter
2015-10-08 20:19   ` Jesse Barnes [this message]
2015-10-09  7:34     ` Daniel Vetter
2015-09-23 15:52 ` [PATCH 4/7] drm/i915: export size_is_valid() from __intel_fbc_update() Paulo Zanoni
2015-09-23 17:09   ` Chris Wilson
2015-09-28  8:59     ` Daniel Vetter
2015-09-28 12:47       ` Ville Syrjälä
2015-09-28 13:13         ` Paulo Zanoni
2015-09-28 13:38           ` Ville Syrjälä
2015-09-28 13:32         ` Daniel Vetter
2015-09-23 15:52 ` [PATCH 5/7] drm/i915: fix FBC buffer size checks Paulo Zanoni
2015-09-23 16:59   ` Chris Wilson
2015-09-30 20:10     ` Zanoni, Paulo R
2015-09-23 15:52 ` [PATCH 6/7] drm/i915: use compute_page_offset() on SKL too Paulo Zanoni
2015-09-23 17:03   ` Chris Wilson
2015-09-24  9:55     ` Tvrtko Ursulin
2015-09-24 10:16       ` Chris Wilson
2015-09-24 17:10   ` Ville Syrjälä
2015-10-12 18:19     ` Hindman, Gavin
2015-10-12 21:01       ` Ville Syrjälä
2015-09-23 15:52 ` [PATCH 7/7] drm/i915: extract fbc_supported() Paulo Zanoni
2015-09-23 17:01   ` Chris Wilson
2015-09-28  8:57     ` Daniel Vetter
2015-09-30 20:05 ` [PATCH 1/3] drm/i915: remove pre-atomic check from SKL update_primary_plane Paulo Zanoni
2015-09-30 20:05   ` [PATCH 2/3] drm/i915: fix CFB size calculation Paulo Zanoni
2015-10-01 12:14     ` Ville Syrjälä
2015-10-01 12:23       ` Ville Syrjälä
2015-10-01 17:47         ` Zanoni, Paulo R
2015-10-01 18:11           ` Ville Syrjälä
2015-10-01 22:54             ` Zanoni, Paulo R
2015-10-01 22:55               ` Paulo Zanoni
2015-10-08 21:29                 ` Ville Syrjälä
2015-09-30 20:05   ` [PATCH 3/3] drm/i915: fix FBC buffer size checks Paulo Zanoni
2015-10-01 12:22     ` Ville Syrjälä
2015-10-01 18:04       ` Zanoni, Paulo R
2015-10-01 22:57         ` Paulo Zanoni
2015-10-09  7:36           ` Daniel Vetter
2015-10-01 12:07   ` [PATCH 1/3] drm/i915: remove pre-atomic check from SKL update_primary_plane Ville Syrjälä

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=5616CFCF.7070100@virtuousgeek.org \
    --to=jbarnes@virtuousgeek.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.com \
    /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;
as well as URLs for NNTP newsgroup(s).