From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Matthew Auld <matthew.auld@intel.com>, intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/gem: only allow WC for lmem
Date: Mon, 28 Jun 2021 09:31:54 +0200 [thread overview]
Message-ID: <8b41b974-9470-c82e-1450-a5c2e3ad4874@linux.intel.com> (raw)
In-Reply-To: <20210625122751.590289-1-matthew.auld@intel.com>
On 6/25/21 2:27 PM, Matthew Auld wrote:
> This is already the case for our kernel internal mappings, and since we
> now only support a single mode this should always be WC if the object
> can be placed in lmem.
>
> v2: rebase and also update set_domain
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
A couple of questions:
1) Since this now becomes uapi, are we completely sure that we are not
going to want to map these bos cached when they are evicted or migrated.
If we think we are going to want to do that, we should probably just
silently accept any mapping mode user-space wants and then have the
kernel override user-space's wishes.
Ping Daniel about this as well.
2) How are we going to handle kernel maps to make sure we don't use a
different kernel map caching mode to these objects. Will that be a later
series? Seems like we at least need to modify "i915_coherent_map_type"
Apart from this, code looks good to me.
/Thomas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2021-06-28 7:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-25 12:27 [Intel-gfx] [PATCH v2 1/2] drm/i915/gem: only allow WC for lmem Matthew Auld
2021-06-25 12:27 ` [Intel-gfx] [PATCH v2 2/2] drm/i915/gem: only allow WB for smem only placements Matthew Auld
2021-06-28 7:41 ` Thomas Hellström
2021-06-28 9:12 ` Matthew Auld
2021-06-28 9:38 ` Thomas Hellström
2021-06-28 10:20 ` Matthew Auld
2021-06-28 10:55 ` Thomas Hellström
2021-06-25 13:18 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/gem: only allow WC for lmem Patchwork
2021-06-25 13:20 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-06-25 13:49 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-06-25 16:45 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2021-06-28 7:31 ` Thomas Hellström [this message]
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=8b41b974-9470-c82e-1450-a5c2e3ad4874@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox