All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/ttm: Adjust gem flags and caching settings after a move
Date: Sat, 12 Jun 2021 10:23:34 +0200	[thread overview]
Message-ID: <a7941cc1de789afe7ea66dd75e3abb46f45dc67d.camel@linux.intel.com> (raw)
In-Reply-To: <CAM0jSHNdwG0WcGNUV01JV2r5SXdxQPN4Oz+wLJrBs=7yZrCz0g@mail.gmail.com>

On Fri, 2021-06-11 at 17:29 +0100, Matthew Auld wrote:
> On Fri, 11 Jun 2021 at 15:55, Thomas Hellström
> <thomas.hellstrom@linux.intel.com> wrote:
> > 
> > After a TTM move we need to update the i915 gem flags and caching
> > settings to reflect the new placement.
> > Also introduce gpu_binds_iomem() and cpu_maps_iomem() to clean up
> > the
> > various ways we previously used to detect this.
> > Finally, initialize the TTM object reserved to be able to update
> > flags and caching before anyone else gets hold of the object.
> 
> Hmm, why do we need to update it after a move? Is it not static? i.e
> we just consider the mm.placements/region to determine the correct
> domain and cache tracking? Or maybe it doesn't really matter either
> way?

Flags are not static, currently. If migrating from LMEM to SYSTEM, they
need to be updated. Caching and domains should remain unchanged for now
because of the rule that we don't want to change caching mode when
migrating from LMEM to SYSTEM for buffers that support both, and that
rule is enforced by setting the ttm_tt caching mode accordingly.
However, I figure if we need to change that rule moving forward because
we decide we can't rely on the TTM shinker for WC system pages, or
because allocating WC system pages is too expensive, It would be good
if we don't need to audit all the code to find places where an updated
caching policy needs changes.

/Thomas





WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/ttm: Adjust gem flags and caching settings after a move
Date: Sat, 12 Jun 2021 10:23:34 +0200	[thread overview]
Message-ID: <a7941cc1de789afe7ea66dd75e3abb46f45dc67d.camel@linux.intel.com> (raw)
In-Reply-To: <CAM0jSHNdwG0WcGNUV01JV2r5SXdxQPN4Oz+wLJrBs=7yZrCz0g@mail.gmail.com>

On Fri, 2021-06-11 at 17:29 +0100, Matthew Auld wrote:
> On Fri, 11 Jun 2021 at 15:55, Thomas Hellström
> <thomas.hellstrom@linux.intel.com> wrote:
> > 
> > After a TTM move we need to update the i915 gem flags and caching
> > settings to reflect the new placement.
> > Also introduce gpu_binds_iomem() and cpu_maps_iomem() to clean up
> > the
> > various ways we previously used to detect this.
> > Finally, initialize the TTM object reserved to be able to update
> > flags and caching before anyone else gets hold of the object.
> 
> Hmm, why do we need to update it after a move? Is it not static? i.e
> we just consider the mm.placements/region to determine the correct
> domain and cache tracking? Or maybe it doesn't really matter either
> way?

Flags are not static, currently. If migrating from LMEM to SYSTEM, they
need to be updated. Caching and domains should remain unchanged for now
because of the rule that we don't want to change caching mode when
migrating from LMEM to SYSTEM for buffers that support both, and that
rule is enforced by setting the ttm_tt caching mode accordingly.
However, I figure if we need to change that rule moving forward because
we decide we can't rely on the TTM shinker for WC system pages, or
because allocating WC system pages is too expensive, It would be good
if we don't need to audit all the code to find places where an updated
caching policy needs changes.

/Thomas




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

  reply	other threads:[~2021-06-12  8:23 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-11 14:54 [PATCH v2 0/4] drm/i915: Move system memory to TTM for discrete Thomas Hellström
2021-06-11 14:54 ` [Intel-gfx] " Thomas Hellström
2021-06-11 14:54 ` [PATCH v2 1/4] drm/i915: Update object placement flags to be mutable Thomas Hellström
2021-06-11 14:54   ` [Intel-gfx] " Thomas Hellström
2021-06-11 16:14   ` Matthew Auld
2021-06-11 16:14     ` [Intel-gfx] " Matthew Auld
2021-06-11 14:54 ` [PATCH v2 2/4] drm/i915/ttm: Adjust gem flags and caching settings after a move Thomas Hellström
2021-06-11 14:54   ` [Intel-gfx] " Thomas Hellström
2021-06-11 16:29   ` Matthew Auld
2021-06-11 16:29     ` Matthew Auld
2021-06-12  8:23     ` Thomas Hellström [this message]
2021-06-12  8:23       ` Thomas Hellström
2021-06-11 14:54 ` [PATCH v2 3/4] drm/i915/ttm: Calculate the object placement at get_pages time Thomas Hellström
2021-06-11 14:54   ` [Intel-gfx] " Thomas Hellström
2021-06-11 15:42   ` Matthew Auld
2021-06-11 15:42     ` [Intel-gfx] " Matthew Auld
2021-06-11 14:54 ` [PATCH v2 4/4] drm/i915/ttm: Use TTM for system memory Thomas Hellström
2021-06-11 14:54   ` [Intel-gfx] " Thomas Hellström
2021-06-11 16:34   ` Matthew Auld
2021-06-11 16:34     ` Matthew Auld
2021-06-11 17:11 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Move system memory to TTM for discrete (rev2) Patchwork
2021-06-11 17:40 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-06-11 19:32 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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=a7941cc1de789afe7ea66dd75e3abb46f45dc67d.camel@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.william.auld@gmail.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.