All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v4 8/8] hack: align dumb buffer stride to 4k to allow for gtt remapping
Date: Wed, 30 Jan 2019 19:26:37 +0100	[thread overview]
Message-ID: <20190130182637.GJ3271@phenom.ffwll.local> (raw)
In-Reply-To: <20190130153803.GO20097@intel.com>

On Wed, Jan 30, 2019 at 05:38:03PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 30, 2019 at 11:06:07AM +0100, Daniel Vetter wrote:
> > On Wed, Jan 30, 2019 at 10:54:15AM +0100, Daniel Vetter wrote:
> > > On Fri, Jan 18, 2019 at 07:11:06PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > 
> > > > v2: Leave the stride alone for buffers that look to be for the cursor
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_gem.c | 7 ++++++-
> > > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > > > index 1e7c95d0fea1..b4b34519af80 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > > @@ -745,7 +745,12 @@ i915_gem_dumb_create(struct drm_file *file,
> > > >  		     struct drm_mode_create_dumb *args)
> > > >  {
> > > >  	/* have to work out size/pitch and return them */
> > > > -	args->pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 64);
> > > > +	if (args->bpp == 32 && (args->width == 64 ||
> > > > +				args->width == 128 ||
> > > > +				args->width == 256))
> > > > +		args->pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 64);
> > > > +	else
> > > > +		args->pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 4096);
> > > 
> > > Shouldn't we convert this into a non-hack and just do it anytime the pitch
> > > is too wide for the display to handle?
> > > 
> > > Or am I missing something somewhere? -modesetting et all will dtrt
> > > because tiling, but this should help with boot splashes and stuff like
> > > that (but those tend to not do side-by-side, so maybe that's why the get
> > > away with it).
> > 
> > Correction: We need this, and before we start bumping the limits. Any dumb
> > buffer you create (within the limits) we must be able to scan out. So we
> > definitely need to have this for super-big buffers on gen7+. Even if it's
> > fairly theoretical.
> 
> Is there some userpsace that actually wants to create a huge dumb
> buffer like that?

Given that the core drm_mode_dumb_create doesn't check anything, I guess
not. Would be good to add.

> Looks like we don't even check against the max fb dimensions in
> dumb_create so you can create any sized dumb buffer you want.
> So even now there is no guarantee that the addfb will actually
> succeed.

Well we do tell userspace up to what limit we expect it to succeed, and
dumb_create is supposed to come up with the correct stride. I think
there's no good reason to give userspace a stride that doesn't work at
all, and it's essentially this patch, but with a slightly different if
condition.
-Daniel

> 
> > 
> > I think we should even have an igt which creates a max size buffer (using
> > dumb create) and then makes sure we can scan that out.
> > -Daniel
> > 
> > > -Daniel
> > > 
> > > >  	args->size = args->pitch * args->height;
> > > >  	return i915_gem_create(file, to_i915(dev),
> > > >  			       args->size, &args->handle);
> > > > -- 
> > > > 2.19.2
> > > > 
> > > > _______________________________________________
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > 
> > > -- 
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> 
> -- 
> Ville Syrjälä
> Intel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-01-30 18:26 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 15:27 [PATCH v3 0/8] drm/i915: GTT remapping for display Ville Syrjala
2019-01-18 15:27 ` [PATCH v3 1/8] drm/i915: Add a new "remapped" gtt_view Ville Syrjala
2019-01-30 19:06   ` Daniel Vetter
2019-01-18 15:27 ` [PATCH v3 2/8] drm/i915/selftests: Add mock selftest for remapped vmas Ville Syrjala
2019-01-24 18:58   ` [PATCH v4 " Ville Syrjala
2019-01-24 23:22     ` Chris Wilson
2019-01-18 15:27 ` [PATCH v3 3/8] drm/i915/selftests: Add live vma selftest Ville Syrjala
2019-01-24 19:11   ` [PATCH v4 " Ville Syrjala
2019-01-24 23:20     ` Chris Wilson
2019-01-18 15:27 ` [PATCH v3 4/8] drm/i915: Overcome display engine stride limits via GTT remapping Ville Syrjala
2019-01-24 18:58   ` [PATCH v4 " Ville Syrjala
2019-01-30 19:01     ` Daniel Vetter
2019-01-30 20:59       ` Ville Syrjälä
2019-01-30 21:55         ` Daniel Vetter
2019-01-18 15:27 ` [PATCH v3 5/8] drm/i915: Bump gen4+ fb stride limit to 256KiB Ville Syrjala
2019-01-24 18:59   ` [PATCH v4 " Ville Syrjala
2019-01-30  9:58     ` Daniel Vetter
2019-01-30 10:01       ` Chris Wilson
2019-01-30 14:33         ` Ville Syrjälä
2019-01-18 15:27 ` [PATCH v3 6/8] drm/i915: Bump gen7+ fb size limits to 16kx16k Ville Syrjala
2019-01-30 10:01   ` Daniel Vetter
2019-01-30 14:35     ` Ville Syrjälä
2019-01-18 15:27 ` [PATCH v3 7/8] hack: drm/i915: Always remap gtt Ville Syrjala
2019-01-24 19:31   ` [PATCH v4 " Ville Syrjala
2019-01-30  9:58     ` Daniel Vetter
2019-01-18 15:27 ` [PATCH v3 8/8] hack: align dumb buffer stride to 4k to allow for gtt remapping Ville Syrjala
2019-01-18 17:11   ` [PATCH v4 " Ville Syrjala
2019-01-30  9:54     ` Daniel Vetter
2019-01-30 10:06       ` Daniel Vetter
2019-01-30 15:38         ` Ville Syrjälä
2019-01-30 18:26           ` Daniel Vetter [this message]
2019-01-18 15:41 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: GTT remapping for display Patchwork
2019-01-18 15:44 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-01-18 16:05 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-01-18 17:18 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: GTT remapping for display (rev2) Patchwork
2019-01-18 17:21 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-01-18 17:51 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-01-24 19:03 ` ✗ Fi.CI.BAT: failure for drm/i915: GTT remapping for display (rev5) Patchwork
2019-01-24 19:28 ` ✗ Fi.CI.BAT: failure for drm/i915: GTT remapping for display (rev6) Patchwork
2019-01-24 19:48 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: GTT remapping for display (rev7) Patchwork
2019-01-24 19:52 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-01-24 20:16 ` ✓ Fi.CI.BAT: success " Patchwork
2019-01-24 21:09 ` ✓ Fi.CI.IGT: " Patchwork

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=20190130182637.GJ3271@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.