All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Matthew Auld <matthew.auld@intel.com>
Subject: Re: [Intel-gfx] dg1 flag for userspace to allocate contig resources
Date: Fri, 11 Sep 2020 15:31:28 +0300	[thread overview]
Message-ID: <20200911123128.GG6112@intel.com> (raw)
In-Reply-To: <159982722697.15554.10447903613389770525@jlahtine-mobl.ger.corp.intel.com>

On Fri, Sep 11, 2020 at 03:27:07PM +0300, Joonas Lahtinen wrote:
> + Jani and Ville
> 
> Quoting Matthew Auld (2020-09-11 11:56:56)
> > On 11/09/2020 06:42, Dave Airlie wrote:
> > > I've just been looking at the current DG1 uapi, and I can't see any
> > > flag to allow userspace to upfront say it was a contiguous vram BO.
> > > 
> > > I think you'd really want this for scanout, since otherwise you'll
> > > have to migrate any non-contig to contig when it transitions to
> > > scanout, and cause an extra set of copies.
> > 
> > Hmm, why do we need physically contiguous memory for scanout? From hw 
> > pov it's seen through the GTT.
> 
> That's correct. On both discrete (and integrated) platforms the scan-out
> addresses on Intel GPUs are programmed to targer Global GTT managed by
> kernel. So no need to have the backing storage contiguous.

The only exception being the ye olde gen2/3 physical cursor stuff :)

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-09-11 12:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-11  5:42 [Intel-gfx] dg1 flag for userspace to allocate contig resources Dave Airlie
2020-09-11  8:56 ` Matthew Auld
2020-09-11 12:27   ` Joonas Lahtinen
2020-09-11 12:31     ` Ville Syrjälä [this message]
2020-09-13 21:53     ` Dave Airlie

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=20200911123128.GG6112@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=matthew.auld@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.