From: Matthew Auld <matthew.auld@intel.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/gem/mman: only allow WC for lmem
Date: Tue, 8 Jun 2021 10:57:13 +0100 [thread overview]
Message-ID: <f009f03e-ec03-e180-ac25-fff2e0ceb856@intel.com> (raw)
In-Reply-To: <3af30ebb-a46b-2b21-57b0-988b2400ac08@linux.intel.com>
On 02/06/2021 13:00, Thomas Hellström wrote:
> Hi,
>
> On 6/2/21 11:36 AM, Matthew Auld wrote:
>> For dgfx where we now have lmem and ttm, we can only support single mmap
>> mode for the lifetime of the object, and for lmem objects this should be
>> WC, so reject all other mapping modes for mmap_offset, including if the
>> object can be placed in both smem and lmem.
>>
>> 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>
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 4 ++++
>> drivers/gpu/drm/i915/gem/i915_gem_object.c | 22 ++++++++++++++++++++++
>> drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 ++++
>> 3 files changed, 30 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> index fd1c9714f8d8..32f88f236771 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> @@ -689,6 +689,10 @@ __assign_mmap_offset(struct drm_file *file,
>> goto out;
>> }
>> + if (mmap_type != I915_MMAP_TYPE_WC &&
>> + i915_gem_object_placements_contain_type(obj,
>> INTEL_MEMORY_LOCAL))
>> + return -ENODEV;
>> +
>
> I think we will also have the restriction that any other objects on DGFX
> can only be mapped cached? At least that's what the TTM code is
> implementing currently.
Yeah, with this patch the caching mode should now at least be consistent
for lmem objects, for smem we still need more patches.
>
>
>> mmo = mmap_offset_attach(obj, mmap_type, file);
>> if (IS_ERR(mmo)) {
>> err = PTR_ERR(mmo);
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> index 2be6109d0093..d4b0da8ed969 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> @@ -403,6 +403,28 @@ int i915_gem_object_read_from_page(struct
>> drm_i915_gem_object *obj, u64 offset,
>> return 0;
>> }
>> +/**
>> + * i915_gem_object_placements_contain_type - Check whether the object
>> can be
>> + * placed at certain memory type
>> + * @obj: Pointer to the object
>> + * @type: The memory type to check
>> + *
>> + * Return: True if the object can be placed in @type. False otherwise.
>> + */
>> +bool i915_gem_object_placements_contain_type(struct
>> drm_i915_gem_object *obj,
>> + enum intel_memory_type type)
>> +{
>> + unsigned int i;
>> +
>> + /* TODO: consider maybe storing as a mask when doing
>> gem_create_ext */
>> + for (i = 0; i < obj->mm.n_placements; i++) {
>> + if (obj->mm.placements[i]->type == type)
>> + return true;
>> + }
>> +
>> + return false;
>> +}
>> +
>
> Do we need something for the in-kernel mappings as well? Or just return
> a mapping with the only allowed caching mode?
For lmem everything should already be WC for in-kernel mappings. For
everything else which uses pin_map() we will need to default to cached.
I guess just add a different helper for this? We should probably also
adjust the obj->cache_level for dg1.
>
> /Thomas
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Auld <matthew.auld@intel.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/gem/mman: only allow WC for lmem
Date: Tue, 8 Jun 2021 10:57:13 +0100 [thread overview]
Message-ID: <f009f03e-ec03-e180-ac25-fff2e0ceb856@intel.com> (raw)
In-Reply-To: <3af30ebb-a46b-2b21-57b0-988b2400ac08@linux.intel.com>
On 02/06/2021 13:00, Thomas Hellström wrote:
> Hi,
>
> On 6/2/21 11:36 AM, Matthew Auld wrote:
>> For dgfx where we now have lmem and ttm, we can only support single mmap
>> mode for the lifetime of the object, and for lmem objects this should be
>> WC, so reject all other mapping modes for mmap_offset, including if the
>> object can be placed in both smem and lmem.
>>
>> 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>
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 4 ++++
>> drivers/gpu/drm/i915/gem/i915_gem_object.c | 22 ++++++++++++++++++++++
>> drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 ++++
>> 3 files changed, 30 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> index fd1c9714f8d8..32f88f236771 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> @@ -689,6 +689,10 @@ __assign_mmap_offset(struct drm_file *file,
>> goto out;
>> }
>> + if (mmap_type != I915_MMAP_TYPE_WC &&
>> + i915_gem_object_placements_contain_type(obj,
>> INTEL_MEMORY_LOCAL))
>> + return -ENODEV;
>> +
>
> I think we will also have the restriction that any other objects on DGFX
> can only be mapped cached? At least that's what the TTM code is
> implementing currently.
Yeah, with this patch the caching mode should now at least be consistent
for lmem objects, for smem we still need more patches.
>
>
>> mmo = mmap_offset_attach(obj, mmap_type, file);
>> if (IS_ERR(mmo)) {
>> err = PTR_ERR(mmo);
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> index 2be6109d0093..d4b0da8ed969 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> @@ -403,6 +403,28 @@ int i915_gem_object_read_from_page(struct
>> drm_i915_gem_object *obj, u64 offset,
>> return 0;
>> }
>> +/**
>> + * i915_gem_object_placements_contain_type - Check whether the object
>> can be
>> + * placed at certain memory type
>> + * @obj: Pointer to the object
>> + * @type: The memory type to check
>> + *
>> + * Return: True if the object can be placed in @type. False otherwise.
>> + */
>> +bool i915_gem_object_placements_contain_type(struct
>> drm_i915_gem_object *obj,
>> + enum intel_memory_type type)
>> +{
>> + unsigned int i;
>> +
>> + /* TODO: consider maybe storing as a mask when doing
>> gem_create_ext */
>> + for (i = 0; i < obj->mm.n_placements; i++) {
>> + if (obj->mm.placements[i]->type == type)
>> + return true;
>> + }
>> +
>> + return false;
>> +}
>> +
>
> Do we need something for the in-kernel mappings as well? Or just return
> a mapping with the only allowed caching mode?
For lmem everything should already be WC for in-kernel mappings. For
everything else which uses pin_map() we will need to default to cached.
I guess just add a different helper for this? We should probably also
adjust the obj->cache_level for dg1.
>
> /Thomas
>
>
next prev parent reply other threads:[~2021-06-08 9:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-02 9:36 [Intel-gfx] [PATCH] drm/i915/gem/mman: only allow WC for lmem Matthew Auld
2021-06-02 9:36 ` Matthew Auld
2021-06-02 10:39 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2021-06-02 12:00 ` [Intel-gfx] [PATCH] " Thomas Hellström
2021-06-02 12:00 ` Thomas Hellström
2021-06-08 9:57 ` Matthew Auld [this message]
2021-06-08 9:57 ` Matthew Auld
2021-06-08 10:06 ` [Intel-gfx] " Thomas Hellström
2021-06-08 10:06 ` Thomas Hellström
2021-06-02 18:42 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " 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=f009f03e-ec03-e180-ac25-fff2e0ceb856@intel.com \
--to=matthew.auld@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=thomas.hellstrom@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.