2025-03-28 00:26:29 +01:00
|
|
|
// SPDX-License-Identifier: MIT
|
2019-05-28 10:29:48 +01:00
|
|
|
/*
|
|
|
|
* Copyright © 2014-2016 Intel Corporation
|
|
|
|
*/
|
|
|
|
|
2021-01-19 14:49:11 +00:00
|
|
|
#include "gt/intel_gt.h"
|
2019-06-13 11:44:16 +03:00
|
|
|
|
2019-05-28 10:29:48 +01:00
|
|
|
#include "i915_drv.h"
|
|
|
|
#include "i915_gem_clflush.h"
|
2022-02-10 17:45:43 +02:00
|
|
|
#include "i915_gem_domain.h"
|
2019-05-28 10:29:48 +01:00
|
|
|
#include "i915_gem_gtt.h"
|
|
|
|
#include "i915_gem_ioctls.h"
|
2019-11-05 20:14:14 +05:30
|
|
|
#include "i915_gem_lmem.h"
|
2019-12-04 12:00:32 +00:00
|
|
|
#include "i915_gem_mman.h"
|
2022-02-10 17:45:43 +02:00
|
|
|
#include "i915_gem_object.h"
|
2023-08-30 11:51:27 +03:00
|
|
|
#include "i915_gem_object_frontbuffer.h"
|
2022-02-10 17:45:43 +02:00
|
|
|
#include "i915_vma.h"
|
2019-05-28 10:29:48 +01:00
|
|
|
|
2021-01-19 14:49:11 +00:00
|
|
|
static bool gpu_write_needs_clflush(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
2021-10-27 17:18:13 +01:00
|
|
|
struct drm_i915_private *i915 = to_i915(obj->base.dev);
|
|
|
|
|
|
|
|
if (IS_DGFX(i915))
|
|
|
|
return false;
|
|
|
|
|
drm/i915: use pat_index instead of cache_level
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, having to translate
between i915_cache_level and PAT index is not reliable, and makes the code
more complicated.
From UMD's perspective there is also a necessity to set caching policy for
performance fine tuning. It's much easier for the UMD to directly use PAT
index because the behavior of each PAT index is clearly defined in Bspec.
Having the abstracted i915_cache_level sitting in between would only cause
more ambiguity. PAT is expected to work much like MOCS already works today,
and by design userspace is expected to select the index that exactly
matches the desired behavior described in the hardware specification.
For these reasons this patch replaces i915_cache_level with PAT index. Also
note, the cache_level is not completely removed yet, because the KMD still
has the need of creating buffer objects with simple cache settings such as
cached, uncached, or writethrough. For kernel objects, cache_level is used
for simplicity and backward compatibility. For Pre-gen12 platforms PAT can
have 1:1 mapping to i915_cache_level, so these two are interchangeable. see
the use of LEGACY_CACHELEVEL.
One consequence of this change is that gen8_pte_encode is no longer working
for gen12 platforms due to the fact that gen12 platforms has different PAT
definitions. In the meantime the mtl_pte_encode introduced specfically for
MTL becomes generic for all gen12 platforms. This patch renames the MTL
PTE encode function into gen12_pte_encode and apply it to all gen12. Even
though this change looks unrelated, but separating them would temporarily
break gen12 PTE encoding, thus squash them in one patch.
Special note: this patch changes the way caching behavior is controlled in
the sense that some objects are left to be managed by userspace. For such
objects we need to be careful not to change the userspace settings.There
are kerneldoc and comments added around obj->cache_coherent, cache_dirty,
and how to bypass the checkings by i915_gem_object_has_cache_level. For
full understanding, these changes need to be looked at together with the
two follow-up patches, one disables the {set|get}_caching ioctl's and the
other adds set_pat extension to the GEM_CREATE uAPI.
Bspec: 63019
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Signed-off-by: Fei Yang <fei.yang@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230509165200.1740-3-fei.yang@intel.com
2023-05-09 09:52:00 -07:00
|
|
|
/*
|
|
|
|
* For objects created by userspace through GEM_CREATE with pat_index
|
|
|
|
* set by set_pat extension, i915_gem_object_has_cache_level() will
|
|
|
|
* always return true, because the coherency of such object is managed
|
|
|
|
* by userspace. Othereise the call here would fall back to checking
|
|
|
|
* whether the object is un-cached or write-through.
|
|
|
|
*/
|
|
|
|
return !(i915_gem_object_has_cache_level(obj, I915_CACHE_NONE) ||
|
|
|
|
i915_gem_object_has_cache_level(obj, I915_CACHE_WT));
|
2021-01-19 14:49:11 +00:00
|
|
|
}
|
|
|
|
|
2021-10-27 17:18:12 +01:00
|
|
|
bool i915_gem_cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
2021-10-27 17:18:13 +01:00
|
|
|
struct drm_i915_private *i915 = to_i915(obj->base.dev);
|
|
|
|
|
2021-10-27 17:18:12 +01:00
|
|
|
if (obj->cache_dirty)
|
|
|
|
return false;
|
|
|
|
|
2021-10-27 17:18:13 +01:00
|
|
|
if (IS_DGFX(i915))
|
|
|
|
return false;
|
|
|
|
|
2022-06-22 16:59:19 +01:00
|
|
|
if (!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE))
|
|
|
|
return true;
|
|
|
|
|
2021-10-27 17:18:12 +01:00
|
|
|
/* Currently in use by HW (display engine)? Keep flushed. */
|
|
|
|
return i915_gem_object_is_framebuffer(obj);
|
|
|
|
}
|
|
|
|
|
2021-01-19 14:49:11 +00:00
|
|
|
static void
|
|
|
|
flush_write_domain(struct drm_i915_gem_object *obj, unsigned int flush_domains)
|
|
|
|
{
|
|
|
|
struct i915_vma *vma;
|
|
|
|
|
|
|
|
assert_object_held(obj);
|
|
|
|
|
|
|
|
if (!(obj->write_domain & flush_domains))
|
|
|
|
return;
|
|
|
|
|
|
|
|
switch (obj->write_domain) {
|
|
|
|
case I915_GEM_DOMAIN_GTT:
|
|
|
|
spin_lock(&obj->vma.lock);
|
2023-07-21 14:07:41 +01:00
|
|
|
for_each_ggtt_vma(vma, obj)
|
|
|
|
i915_vma_flush_writes(vma);
|
2021-01-19 14:49:11 +00:00
|
|
|
spin_unlock(&obj->vma.lock);
|
|
|
|
|
|
|
|
i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case I915_GEM_DOMAIN_WC:
|
|
|
|
wmb();
|
|
|
|
break;
|
|
|
|
|
|
|
|
case I915_GEM_DOMAIN_CPU:
|
|
|
|
i915_gem_clflush_object(obj, I915_CLFLUSH_SYNC);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case I915_GEM_DOMAIN_RENDER:
|
|
|
|
if (gpu_write_needs_clflush(obj))
|
|
|
|
obj->cache_dirty = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
obj->write_domain = 0;
|
|
|
|
}
|
|
|
|
|
2019-05-28 10:29:48 +01:00
|
|
|
static void __i915_gem_object_flush_for_display(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We manually flush the CPU domain so that we can override and
|
|
|
|
* force the flush for the display, and perform it asyncrhonously.
|
|
|
|
*/
|
2021-01-19 14:49:11 +00:00
|
|
|
flush_write_domain(obj, ~I915_GEM_DOMAIN_CPU);
|
2019-05-28 10:29:48 +01:00
|
|
|
if (obj->cache_dirty)
|
|
|
|
i915_gem_clflush_object(obj, I915_CLFLUSH_FORCE);
|
|
|
|
obj->write_domain = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void i915_gem_object_flush_if_display(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
2019-09-02 05:02:47 +01:00
|
|
|
if (!i915_gem_object_is_framebuffer(obj))
|
2019-05-28 10:29:48 +01:00
|
|
|
return;
|
|
|
|
|
2020-08-19 16:08:45 +02:00
|
|
|
i915_gem_object_lock(obj, NULL);
|
2019-05-28 10:29:48 +01:00
|
|
|
__i915_gem_object_flush_for_display(obj);
|
2019-05-28 10:29:51 +01:00
|
|
|
i915_gem_object_unlock(obj);
|
2019-05-28 10:29:48 +01:00
|
|
|
}
|
|
|
|
|
2020-08-19 16:09:03 +02:00
|
|
|
void i915_gem_object_flush_if_display_locked(struct drm_i915_gem_object *obj)
|
|
|
|
{
|
|
|
|
if (i915_gem_object_is_framebuffer(obj))
|
|
|
|
__i915_gem_object_flush_for_display(obj);
|
|
|
|
}
|
|
|
|
|
2019-05-28 10:29:48 +01:00
|
|
|
/**
|
2023-03-31 10:25:56 +01:00
|
|
|
* i915_gem_object_set_to_wc_domain - Moves a single object to the WC read, and
|
|
|
|
* possibly write domain.
|
2019-05-28 10:29:48 +01:00
|
|
|
* @obj: object to act on
|
|
|
|
* @write: ask for write access or read only
|
|
|
|
*
|
|
|
|
* This function returns when the move is complete, including waiting on
|
|
|
|
* flushes to occur.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object *obj, bool write)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2019-05-28 10:29:51 +01:00
|
|
|
assert_object_held(obj);
|
2019-05-28 10:29:48 +01:00
|
|
|
|
|
|
|
ret = i915_gem_object_wait(obj,
|
|
|
|
I915_WAIT_INTERRUPTIBLE |
|
|
|
|
(write ? I915_WAIT_ALL : 0),
|
|
|
|
MAX_SCHEDULE_TIMEOUT);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
if (obj->write_domain == I915_GEM_DOMAIN_WC)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Flush and acquire obj->pages so that we are coherent through
|
|
|
|
* direct access in memory with previous cached writes through
|
|
|
|
* shmemfs and that our cache domain tracking remains valid.
|
|
|
|
* For example, if the obj->filp was moved to swap without us
|
|
|
|
* being notified and releasing the pages, we would mistakenly
|
|
|
|
* continue to assume that the obj remained out of the CPU cached
|
|
|
|
* domain.
|
|
|
|
*/
|
|
|
|
ret = i915_gem_object_pin_pages(obj);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2021-01-19 14:49:11 +00:00
|
|
|
flush_write_domain(obj, ~I915_GEM_DOMAIN_WC);
|
2019-05-28 10:29:48 +01:00
|
|
|
|
|
|
|
/* Serialise direct access to this object with the barriers for
|
|
|
|
* coherent writes from the GPU, by effectively invalidating the
|
|
|
|
* WC domain upon first access.
|
|
|
|
*/
|
|
|
|
if ((obj->read_domains & I915_GEM_DOMAIN_WC) == 0)
|
|
|
|
mb();
|
|
|
|
|
|
|
|
/* It should now be out of any other write domains, and we can update
|
|
|
|
* the domain values for our changes.
|
|
|
|
*/
|
|
|
|
GEM_BUG_ON((obj->write_domain & ~I915_GEM_DOMAIN_WC) != 0);
|
|
|
|
obj->read_domains |= I915_GEM_DOMAIN_WC;
|
|
|
|
if (write) {
|
|
|
|
obj->read_domains = I915_GEM_DOMAIN_WC;
|
|
|
|
obj->write_domain = I915_GEM_DOMAIN_WC;
|
|
|
|
obj->mm.dirty = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
i915_gem_object_unpin_pages(obj);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2023-03-31 10:25:56 +01:00
|
|
|
* i915_gem_object_set_to_gtt_domain - Moves a single object to the GTT read,
|
|
|
|
* and possibly write domain.
|
2019-05-28 10:29:48 +01:00
|
|
|
* @obj: object to act on
|
|
|
|
* @write: ask for write access or read only
|
|
|
|
*
|
|
|
|
* This function returns when the move is complete, including waiting on
|
|
|
|
* flushes to occur.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2019-05-28 10:29:51 +01:00
|
|
|
assert_object_held(obj);
|
2019-05-28 10:29:48 +01:00
|
|
|
|
|
|
|
ret = i915_gem_object_wait(obj,
|
|
|
|
I915_WAIT_INTERRUPTIBLE |
|
|
|
|
(write ? I915_WAIT_ALL : 0),
|
|
|
|
MAX_SCHEDULE_TIMEOUT);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
if (obj->write_domain == I915_GEM_DOMAIN_GTT)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Flush and acquire obj->pages so that we are coherent through
|
|
|
|
* direct access in memory with previous cached writes through
|
|
|
|
* shmemfs and that our cache domain tracking remains valid.
|
|
|
|
* For example, if the obj->filp was moved to swap without us
|
|
|
|
* being notified and releasing the pages, we would mistakenly
|
|
|
|
* continue to assume that the obj remained out of the CPU cached
|
|
|
|
* domain.
|
|
|
|
*/
|
|
|
|
ret = i915_gem_object_pin_pages(obj);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2021-01-19 14:49:11 +00:00
|
|
|
flush_write_domain(obj, ~I915_GEM_DOMAIN_GTT);
|
2019-05-28 10:29:48 +01:00
|
|
|
|
|
|
|
/* Serialise direct access to this object with the barriers for
|
|
|
|
* coherent writes from the GPU, by effectively invalidating the
|
|
|
|
* GTT domain upon first access.
|
|
|
|
*/
|
|
|
|
if ((obj->read_domains & I915_GEM_DOMAIN_GTT) == 0)
|
|
|
|
mb();
|
|
|
|
|
|
|
|
/* It should now be out of any other write domains, and we can update
|
|
|
|
* the domain values for our changes.
|
|
|
|
*/
|
|
|
|
GEM_BUG_ON((obj->write_domain & ~I915_GEM_DOMAIN_GTT) != 0);
|
|
|
|
obj->read_domains |= I915_GEM_DOMAIN_GTT;
|
|
|
|
if (write) {
|
2019-11-19 11:25:15 +00:00
|
|
|
struct i915_vma *vma;
|
|
|
|
|
2019-05-28 10:29:48 +01:00
|
|
|
obj->read_domains = I915_GEM_DOMAIN_GTT;
|
|
|
|
obj->write_domain = I915_GEM_DOMAIN_GTT;
|
|
|
|
obj->mm.dirty = true;
|
2019-11-19 11:25:15 +00:00
|
|
|
|
|
|
|
spin_lock(&obj->vma.lock);
|
|
|
|
for_each_ggtt_vma(vma, obj)
|
|
|
|
if (i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND))
|
|
|
|
i915_vma_set_ggtt_write(vma);
|
|
|
|
spin_unlock(&obj->vma.lock);
|
2019-05-28 10:29:48 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
i915_gem_object_unpin_pages(obj);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2023-03-31 10:25:56 +01:00
|
|
|
* i915_gem_object_set_cache_level - Changes the cache-level of an object across all VMA.
|
2019-05-28 10:29:48 +01:00
|
|
|
* @obj: object to act on
|
|
|
|
* @cache_level: new cache level to set for the object
|
|
|
|
*
|
|
|
|
* After this function returns, the object will be in the new cache-level
|
|
|
|
* across all GTT and the contents of the backing storage will be coherent,
|
|
|
|
* with respect to the new cache-level. In order to keep the backing storage
|
|
|
|
* coherent for all users, we only allow a single cache level to be set
|
|
|
|
* globally on the object and prevent it from being changed whilst the
|
|
|
|
* hardware is reading from the object. That is if the object is currently
|
|
|
|
* on the scanout it will be set to uncached (or equivalent display
|
|
|
|
* cache coherency) and all non-MOCS GPU access will also be uncached so
|
|
|
|
* that all direct access to the scanout remains coherent.
|
|
|
|
*/
|
|
|
|
int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
|
|
|
|
enum i915_cache_level cache_level)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
drm/i915: use pat_index instead of cache_level
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, having to translate
between i915_cache_level and PAT index is not reliable, and makes the code
more complicated.
From UMD's perspective there is also a necessity to set caching policy for
performance fine tuning. It's much easier for the UMD to directly use PAT
index because the behavior of each PAT index is clearly defined in Bspec.
Having the abstracted i915_cache_level sitting in between would only cause
more ambiguity. PAT is expected to work much like MOCS already works today,
and by design userspace is expected to select the index that exactly
matches the desired behavior described in the hardware specification.
For these reasons this patch replaces i915_cache_level with PAT index. Also
note, the cache_level is not completely removed yet, because the KMD still
has the need of creating buffer objects with simple cache settings such as
cached, uncached, or writethrough. For kernel objects, cache_level is used
for simplicity and backward compatibility. For Pre-gen12 platforms PAT can
have 1:1 mapping to i915_cache_level, so these two are interchangeable. see
the use of LEGACY_CACHELEVEL.
One consequence of this change is that gen8_pte_encode is no longer working
for gen12 platforms due to the fact that gen12 platforms has different PAT
definitions. In the meantime the mtl_pte_encode introduced specfically for
MTL becomes generic for all gen12 platforms. This patch renames the MTL
PTE encode function into gen12_pte_encode and apply it to all gen12. Even
though this change looks unrelated, but separating them would temporarily
break gen12 PTE encoding, thus squash them in one patch.
Special note: this patch changes the way caching behavior is controlled in
the sense that some objects are left to be managed by userspace. For such
objects we need to be careful not to change the userspace settings.There
are kerneldoc and comments added around obj->cache_coherent, cache_dirty,
and how to bypass the checkings by i915_gem_object_has_cache_level. For
full understanding, these changes need to be looked at together with the
two follow-up patches, one disables the {set|get}_caching ioctl's and the
other adds set_pat extension to the GEM_CREATE uAPI.
Bspec: 63019
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Signed-off-by: Fei Yang <fei.yang@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230509165200.1740-3-fei.yang@intel.com
2023-05-09 09:52:00 -07:00
|
|
|
/*
|
|
|
|
* For objects created by userspace through GEM_CREATE with pat_index
|
|
|
|
* set by set_pat extension, simply return 0 here without touching
|
|
|
|
* the cache setting, because such objects should have an immutable
|
2025-01-20 13:45:12 +05:30
|
|
|
* cache setting by design and always managed by userspace.
|
drm/i915: use pat_index instead of cache_level
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, having to translate
between i915_cache_level and PAT index is not reliable, and makes the code
more complicated.
From UMD's perspective there is also a necessity to set caching policy for
performance fine tuning. It's much easier for the UMD to directly use PAT
index because the behavior of each PAT index is clearly defined in Bspec.
Having the abstracted i915_cache_level sitting in between would only cause
more ambiguity. PAT is expected to work much like MOCS already works today,
and by design userspace is expected to select the index that exactly
matches the desired behavior described in the hardware specification.
For these reasons this patch replaces i915_cache_level with PAT index. Also
note, the cache_level is not completely removed yet, because the KMD still
has the need of creating buffer objects with simple cache settings such as
cached, uncached, or writethrough. For kernel objects, cache_level is used
for simplicity and backward compatibility. For Pre-gen12 platforms PAT can
have 1:1 mapping to i915_cache_level, so these two are interchangeable. see
the use of LEGACY_CACHELEVEL.
One consequence of this change is that gen8_pte_encode is no longer working
for gen12 platforms due to the fact that gen12 platforms has different PAT
definitions. In the meantime the mtl_pte_encode introduced specfically for
MTL becomes generic for all gen12 platforms. This patch renames the MTL
PTE encode function into gen12_pte_encode and apply it to all gen12. Even
though this change looks unrelated, but separating them would temporarily
break gen12 PTE encoding, thus squash them in one patch.
Special note: this patch changes the way caching behavior is controlled in
the sense that some objects are left to be managed by userspace. For such
objects we need to be careful not to change the userspace settings.There
are kerneldoc and comments added around obj->cache_coherent, cache_dirty,
and how to bypass the checkings by i915_gem_object_has_cache_level. For
full understanding, these changes need to be looked at together with the
two follow-up patches, one disables the {set|get}_caching ioctl's and the
other adds set_pat extension to the GEM_CREATE uAPI.
Bspec: 63019
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Signed-off-by: Fei Yang <fei.yang@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230509165200.1740-3-fei.yang@intel.com
2023-05-09 09:52:00 -07:00
|
|
|
*/
|
|
|
|
if (i915_gem_object_has_cache_level(obj, cache_level))
|
2019-05-28 10:29:48 +01:00
|
|
|
return 0;
|
|
|
|
|
2019-12-13 22:31:40 +00:00
|
|
|
ret = i915_gem_object_wait(obj,
|
|
|
|
I915_WAIT_INTERRUPTIBLE |
|
|
|
|
I915_WAIT_ALL,
|
|
|
|
MAX_SCHEDULE_TIMEOUT);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2019-12-06 10:55:27 +00:00
|
|
|
/* Always invalidate stale cachelines */
|
drm/i915: use pat_index instead of cache_level
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, having to translate
between i915_cache_level and PAT index is not reliable, and makes the code
more complicated.
From UMD's perspective there is also a necessity to set caching policy for
performance fine tuning. It's much easier for the UMD to directly use PAT
index because the behavior of each PAT index is clearly defined in Bspec.
Having the abstracted i915_cache_level sitting in between would only cause
more ambiguity. PAT is expected to work much like MOCS already works today,
and by design userspace is expected to select the index that exactly
matches the desired behavior described in the hardware specification.
For these reasons this patch replaces i915_cache_level with PAT index. Also
note, the cache_level is not completely removed yet, because the KMD still
has the need of creating buffer objects with simple cache settings such as
cached, uncached, or writethrough. For kernel objects, cache_level is used
for simplicity and backward compatibility. For Pre-gen12 platforms PAT can
have 1:1 mapping to i915_cache_level, so these two are interchangeable. see
the use of LEGACY_CACHELEVEL.
One consequence of this change is that gen8_pte_encode is no longer working
for gen12 platforms due to the fact that gen12 platforms has different PAT
definitions. In the meantime the mtl_pte_encode introduced specfically for
MTL becomes generic for all gen12 platforms. This patch renames the MTL
PTE encode function into gen12_pte_encode and apply it to all gen12. Even
though this change looks unrelated, but separating them would temporarily
break gen12 PTE encoding, thus squash them in one patch.
Special note: this patch changes the way caching behavior is controlled in
the sense that some objects are left to be managed by userspace. For such
objects we need to be careful not to change the userspace settings.There
are kerneldoc and comments added around obj->cache_coherent, cache_dirty,
and how to bypass the checkings by i915_gem_object_has_cache_level. For
full understanding, these changes need to be looked at together with the
two follow-up patches, one disables the {set|get}_caching ioctl's and the
other adds set_pat extension to the GEM_CREATE uAPI.
Bspec: 63019
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Signed-off-by: Fei Yang <fei.yang@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230509165200.1740-3-fei.yang@intel.com
2023-05-09 09:52:00 -07:00
|
|
|
i915_gem_object_set_cache_coherency(obj, cache_level);
|
|
|
|
obj->cache_dirty = true;
|
2019-05-28 10:29:48 +01:00
|
|
|
|
2019-12-06 10:55:27 +00:00
|
|
|
/* The cache-level will be applied when each vma is rebound. */
|
2019-12-08 16:12:51 +00:00
|
|
|
return i915_gem_object_unbind(obj,
|
|
|
|
I915_GEM_OBJECT_UNBIND_ACTIVE |
|
|
|
|
I915_GEM_OBJECT_UNBIND_BARRIER);
|
2019-05-28 10:29:48 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
int i915_gem_get_caching_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_i915_gem_caching *args = data;
|
|
|
|
struct drm_i915_gem_object *obj;
|
|
|
|
int err = 0;
|
|
|
|
|
2021-07-15 11:15:33 +01:00
|
|
|
if (IS_DGFX(to_i915(dev)))
|
|
|
|
return -ENODEV;
|
|
|
|
|
2019-05-28 10:29:48 +01:00
|
|
|
rcu_read_lock();
|
|
|
|
obj = i915_gem_object_lookup_rcu(file, args->handle);
|
|
|
|
if (!obj) {
|
|
|
|
err = -ENOENT;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
drm/i915: use pat_index instead of cache_level
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, having to translate
between i915_cache_level and PAT index is not reliable, and makes the code
more complicated.
From UMD's perspective there is also a necessity to set caching policy for
performance fine tuning. It's much easier for the UMD to directly use PAT
index because the behavior of each PAT index is clearly defined in Bspec.
Having the abstracted i915_cache_level sitting in between would only cause
more ambiguity. PAT is expected to work much like MOCS already works today,
and by design userspace is expected to select the index that exactly
matches the desired behavior described in the hardware specification.
For these reasons this patch replaces i915_cache_level with PAT index. Also
note, the cache_level is not completely removed yet, because the KMD still
has the need of creating buffer objects with simple cache settings such as
cached, uncached, or writethrough. For kernel objects, cache_level is used
for simplicity and backward compatibility. For Pre-gen12 platforms PAT can
have 1:1 mapping to i915_cache_level, so these two are interchangeable. see
the use of LEGACY_CACHELEVEL.
One consequence of this change is that gen8_pte_encode is no longer working
for gen12 platforms due to the fact that gen12 platforms has different PAT
definitions. In the meantime the mtl_pte_encode introduced specfically for
MTL becomes generic for all gen12 platforms. This patch renames the MTL
PTE encode function into gen12_pte_encode and apply it to all gen12. Even
though this change looks unrelated, but separating them would temporarily
break gen12 PTE encoding, thus squash them in one patch.
Special note: this patch changes the way caching behavior is controlled in
the sense that some objects are left to be managed by userspace. For such
objects we need to be careful not to change the userspace settings.There
are kerneldoc and comments added around obj->cache_coherent, cache_dirty,
and how to bypass the checkings by i915_gem_object_has_cache_level. For
full understanding, these changes need to be looked at together with the
two follow-up patches, one disables the {set|get}_caching ioctl's and the
other adds set_pat extension to the GEM_CREATE uAPI.
Bspec: 63019
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Signed-off-by: Fei Yang <fei.yang@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230509165200.1740-3-fei.yang@intel.com
2023-05-09 09:52:00 -07:00
|
|
|
/*
|
|
|
|
* This ioctl should be disabled for the objects with pat_index
|
|
|
|
* set by user space.
|
|
|
|
*/
|
|
|
|
if (obj->pat_set_by_user) {
|
|
|
|
err = -EOPNOTSUPP;
|
|
|
|
goto out;
|
|
|
|
}
|
2019-05-28 10:29:48 +01:00
|
|
|
|
drm/i915: use pat_index instead of cache_level
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, having to translate
between i915_cache_level and PAT index is not reliable, and makes the code
more complicated.
From UMD's perspective there is also a necessity to set caching policy for
performance fine tuning. It's much easier for the UMD to directly use PAT
index because the behavior of each PAT index is clearly defined in Bspec.
Having the abstracted i915_cache_level sitting in between would only cause
more ambiguity. PAT is expected to work much like MOCS already works today,
and by design userspace is expected to select the index that exactly
matches the desired behavior described in the hardware specification.
For these reasons this patch replaces i915_cache_level with PAT index. Also
note, the cache_level is not completely removed yet, because the KMD still
has the need of creating buffer objects with simple cache settings such as
cached, uncached, or writethrough. For kernel objects, cache_level is used
for simplicity and backward compatibility. For Pre-gen12 platforms PAT can
have 1:1 mapping to i915_cache_level, so these two are interchangeable. see
the use of LEGACY_CACHELEVEL.
One consequence of this change is that gen8_pte_encode is no longer working
for gen12 platforms due to the fact that gen12 platforms has different PAT
definitions. In the meantime the mtl_pte_encode introduced specfically for
MTL becomes generic for all gen12 platforms. This patch renames the MTL
PTE encode function into gen12_pte_encode and apply it to all gen12. Even
though this change looks unrelated, but separating them would temporarily
break gen12 PTE encoding, thus squash them in one patch.
Special note: this patch changes the way caching behavior is controlled in
the sense that some objects are left to be managed by userspace. For such
objects we need to be careful not to change the userspace settings.There
are kerneldoc and comments added around obj->cache_coherent, cache_dirty,
and how to bypass the checkings by i915_gem_object_has_cache_level. For
full understanding, these changes need to be looked at together with the
two follow-up patches, one disables the {set|get}_caching ioctl's and the
other adds set_pat extension to the GEM_CREATE uAPI.
Bspec: 63019
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Signed-off-by: Fei Yang <fei.yang@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230509165200.1740-3-fei.yang@intel.com
2023-05-09 09:52:00 -07:00
|
|
|
if (i915_gem_object_has_cache_level(obj, I915_CACHE_LLC) ||
|
|
|
|
i915_gem_object_has_cache_level(obj, I915_CACHE_L3_LLC))
|
|
|
|
args->caching = I915_CACHING_CACHED;
|
|
|
|
else if (i915_gem_object_has_cache_level(obj, I915_CACHE_WT))
|
2019-05-28 10:29:48 +01:00
|
|
|
args->caching = I915_CACHING_DISPLAY;
|
drm/i915: use pat_index instead of cache_level
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, having to translate
between i915_cache_level and PAT index is not reliable, and makes the code
more complicated.
From UMD's perspective there is also a necessity to set caching policy for
performance fine tuning. It's much easier for the UMD to directly use PAT
index because the behavior of each PAT index is clearly defined in Bspec.
Having the abstracted i915_cache_level sitting in between would only cause
more ambiguity. PAT is expected to work much like MOCS already works today,
and by design userspace is expected to select the index that exactly
matches the desired behavior described in the hardware specification.
For these reasons this patch replaces i915_cache_level with PAT index. Also
note, the cache_level is not completely removed yet, because the KMD still
has the need of creating buffer objects with simple cache settings such as
cached, uncached, or writethrough. For kernel objects, cache_level is used
for simplicity and backward compatibility. For Pre-gen12 platforms PAT can
have 1:1 mapping to i915_cache_level, so these two are interchangeable. see
the use of LEGACY_CACHELEVEL.
One consequence of this change is that gen8_pte_encode is no longer working
for gen12 platforms due to the fact that gen12 platforms has different PAT
definitions. In the meantime the mtl_pte_encode introduced specfically for
MTL becomes generic for all gen12 platforms. This patch renames the MTL
PTE encode function into gen12_pte_encode and apply it to all gen12. Even
though this change looks unrelated, but separating them would temporarily
break gen12 PTE encoding, thus squash them in one patch.
Special note: this patch changes the way caching behavior is controlled in
the sense that some objects are left to be managed by userspace. For such
objects we need to be careful not to change the userspace settings.There
are kerneldoc and comments added around obj->cache_coherent, cache_dirty,
and how to bypass the checkings by i915_gem_object_has_cache_level. For
full understanding, these changes need to be looked at together with the
two follow-up patches, one disables the {set|get}_caching ioctl's and the
other adds set_pat extension to the GEM_CREATE uAPI.
Bspec: 63019
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Signed-off-by: Fei Yang <fei.yang@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230509165200.1740-3-fei.yang@intel.com
2023-05-09 09:52:00 -07:00
|
|
|
else
|
2019-05-28 10:29:48 +01:00
|
|
|
args->caching = I915_CACHING_NONE;
|
|
|
|
out:
|
|
|
|
rcu_read_unlock();
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = to_i915(dev);
|
|
|
|
struct drm_i915_gem_caching *args = data;
|
|
|
|
struct drm_i915_gem_object *obj;
|
|
|
|
enum i915_cache_level level;
|
|
|
|
int ret = 0;
|
|
|
|
|
2021-07-15 11:15:33 +01:00
|
|
|
if (IS_DGFX(i915))
|
|
|
|
return -ENODEV;
|
|
|
|
|
2023-05-18 22:11:02 -07:00
|
|
|
if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
2019-05-28 10:29:48 +01:00
|
|
|
switch (args->caching) {
|
|
|
|
case I915_CACHING_NONE:
|
|
|
|
level = I915_CACHE_NONE;
|
|
|
|
break;
|
|
|
|
case I915_CACHING_CACHED:
|
|
|
|
/*
|
|
|
|
* Due to a HW issue on BXT A stepping, GPU stores via a
|
|
|
|
* snooped mapping may leave stale data in a corresponding CPU
|
|
|
|
* cacheline, whereas normally such cachelines would get
|
|
|
|
* invalidated.
|
|
|
|
*/
|
|
|
|
if (!HAS_LLC(i915) && !HAS_SNOOP(i915))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
level = I915_CACHE_LLC;
|
|
|
|
break;
|
|
|
|
case I915_CACHING_DISPLAY:
|
|
|
|
level = HAS_WT(i915) ? I915_CACHE_WT : I915_CACHE_NONE;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
obj = i915_gem_object_lookup(file, args->handle);
|
|
|
|
if (!obj)
|
|
|
|
return -ENOENT;
|
|
|
|
|
drm/i915: use pat_index instead of cache_level
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, having to translate
between i915_cache_level and PAT index is not reliable, and makes the code
more complicated.
From UMD's perspective there is also a necessity to set caching policy for
performance fine tuning. It's much easier for the UMD to directly use PAT
index because the behavior of each PAT index is clearly defined in Bspec.
Having the abstracted i915_cache_level sitting in between would only cause
more ambiguity. PAT is expected to work much like MOCS already works today,
and by design userspace is expected to select the index that exactly
matches the desired behavior described in the hardware specification.
For these reasons this patch replaces i915_cache_level with PAT index. Also
note, the cache_level is not completely removed yet, because the KMD still
has the need of creating buffer objects with simple cache settings such as
cached, uncached, or writethrough. For kernel objects, cache_level is used
for simplicity and backward compatibility. For Pre-gen12 platforms PAT can
have 1:1 mapping to i915_cache_level, so these two are interchangeable. see
the use of LEGACY_CACHELEVEL.
One consequence of this change is that gen8_pte_encode is no longer working
for gen12 platforms due to the fact that gen12 platforms has different PAT
definitions. In the meantime the mtl_pte_encode introduced specfically for
MTL becomes generic for all gen12 platforms. This patch renames the MTL
PTE encode function into gen12_pte_encode and apply it to all gen12. Even
though this change looks unrelated, but separating them would temporarily
break gen12 PTE encoding, thus squash them in one patch.
Special note: this patch changes the way caching behavior is controlled in
the sense that some objects are left to be managed by userspace. For such
objects we need to be careful not to change the userspace settings.There
are kerneldoc and comments added around obj->cache_coherent, cache_dirty,
and how to bypass the checkings by i915_gem_object_has_cache_level. For
full understanding, these changes need to be looked at together with the
two follow-up patches, one disables the {set|get}_caching ioctl's and the
other adds set_pat extension to the GEM_CREATE uAPI.
Bspec: 63019
Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
Signed-off-by: Fei Yang <fei.yang@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230509165200.1740-3-fei.yang@intel.com
2023-05-09 09:52:00 -07:00
|
|
|
/*
|
|
|
|
* This ioctl should be disabled for the objects with pat_index
|
|
|
|
* set by user space.
|
|
|
|
*/
|
|
|
|
if (obj->pat_set_by_user) {
|
|
|
|
ret = -EOPNOTSUPP;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2019-05-28 10:29:48 +01:00
|
|
|
/*
|
|
|
|
* The caching mode of proxy object is handled by its generator, and
|
|
|
|
* not allowed to be changed by userspace.
|
|
|
|
*/
|
|
|
|
if (i915_gem_object_is_proxy(obj)) {
|
2021-03-23 16:50:02 +01:00
|
|
|
/*
|
|
|
|
* Silently allow cached for userptr; the vulkan driver
|
|
|
|
* sets all objects to cached
|
|
|
|
*/
|
|
|
|
if (!i915_gem_object_is_userptr(obj) ||
|
|
|
|
args->caching != I915_CACHING_CACHED)
|
|
|
|
ret = -ENXIO;
|
|
|
|
|
2019-05-28 10:29:48 +01:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2020-08-19 16:09:03 +02:00
|
|
|
ret = i915_gem_object_lock_interruptible(obj, NULL);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
|
2019-12-06 10:55:27 +00:00
|
|
|
ret = i915_gem_object_set_cache_level(obj, level);
|
2020-08-19 16:09:03 +02:00
|
|
|
i915_gem_object_unlock(obj);
|
2019-05-28 10:29:48 +01:00
|
|
|
|
|
|
|
out:
|
|
|
|
i915_gem_object_put(obj);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prepare buffer for display plane (scanout, cursors, etc). Can be called from
|
|
|
|
* an uninterruptible phase (modesetting) and allows any flushes to be pipelined
|
|
|
|
* (for pageflips). We only flush the caches while preparing the buffer for
|
|
|
|
* display, the callers are responsible for frontbuffer flush.
|
|
|
|
*/
|
|
|
|
struct i915_vma *
|
|
|
|
i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
|
2021-03-23 16:50:11 +01:00
|
|
|
struct i915_gem_ww_ctx *ww,
|
2025-01-22 17:17:53 +02:00
|
|
|
u32 alignment, unsigned int guard,
|
2022-09-01 11:38:54 -07:00
|
|
|
const struct i915_gtt_view *view,
|
2019-05-28 10:29:48 +01:00
|
|
|
unsigned int flags)
|
|
|
|
{
|
2019-11-05 20:14:14 +05:30
|
|
|
struct drm_i915_private *i915 = to_i915(obj->base.dev);
|
2019-05-28 10:29:48 +01:00
|
|
|
struct i915_vma *vma;
|
|
|
|
int ret;
|
|
|
|
|
2021-06-29 17:12:03 +02:00
|
|
|
/* Frame buffer must be in LMEM */
|
2019-11-05 20:14:14 +05:30
|
|
|
if (HAS_LMEM(i915) && !i915_gem_object_is_lmem(obj))
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
2019-09-02 05:02:47 +01:00
|
|
|
/*
|
|
|
|
* The display engine is not coherent with the LLC cache on gen6. As
|
2019-05-28 10:29:48 +01:00
|
|
|
* a result, we make sure that the pinning that is about to occur is
|
|
|
|
* done with uncached PTEs. This is lowest common denominator for all
|
|
|
|
* chipsets.
|
|
|
|
*
|
|
|
|
* However for gen6+, we could do better by using the GFDT bit instead
|
|
|
|
* of uncaching, which would allow us to flush all the LLC-cached data
|
|
|
|
* with that bit in the PTE to main memory with just one PIPE_CONTROL.
|
|
|
|
*/
|
|
|
|
ret = i915_gem_object_set_cache_level(obj,
|
2019-11-05 20:14:14 +05:30
|
|
|
HAS_WT(i915) ?
|
2019-05-28 10:29:48 +01:00
|
|
|
I915_CACHE_WT : I915_CACHE_NONE);
|
2019-09-02 05:02:47 +01:00
|
|
|
if (ret)
|
2021-03-23 16:50:11 +01:00
|
|
|
return ERR_PTR(ret);
|
2019-05-28 10:29:48 +01:00
|
|
|
|
drm/i915: Refine VT-d scanout workaround
VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 168 PTE,
warning that the accesses will wrap around the ends of the GGTT.
Currently, we fill the entire GGTT with scratch pages when using VT-d to
always ensure there are valid entries around every vma, including
scanout. However, writing every PTE is slow as on recent devices we
perform 8MiB of uncached writes, incurring an extra 100ms during resume.
If instead we focus on only putting guard pages around scanout, we can
avoid touching the whole GGTT. To avoid having to introduce extra nodes
around each scanout vma, we adjust the scanout drm_mm_node to be smaller
than the allocated space, and fixup the extra PTE during dma binding.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221130235805.221010-5-andi.shyti@linux.intel.com
2022-12-01 00:58:04 +01:00
|
|
|
/* VT-d may overfetch before/after the vma, so pad with scratch */
|
2025-01-22 17:17:53 +02:00
|
|
|
if (guard)
|
|
|
|
flags |= PIN_OFFSET_GUARD | (guard * I915_GTT_PAGE_SIZE);
|
drm/i915: Refine VT-d scanout workaround
VT-d may cause overfetch of the scanout PTE, both before and after the
vma (depending on the scanout orientation). bspec recommends that we
provide a tile-row in either directions, and suggests using 168 PTE,
warning that the accesses will wrap around the ends of the GGTT.
Currently, we fill the entire GGTT with scratch pages when using VT-d to
always ensure there are valid entries around every vma, including
scanout. However, writing every PTE is slow as on recent devices we
perform 8MiB of uncached writes, incurring an extra 100ms during resume.
If instead we focus on only putting guard pages around scanout, we can
avoid touching the whole GGTT. To avoid having to introduce extra nodes
around each scanout vma, we adjust the scanout drm_mm_node to be smaller
than the allocated space, and fixup the extra PTE during dma binding.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221130235805.221010-5-andi.shyti@linux.intel.com
2022-12-01 00:58:04 +01:00
|
|
|
|
2019-09-02 05:02:47 +01:00
|
|
|
/*
|
|
|
|
* As the user may map the buffer once pinned in the display plane
|
2019-05-28 10:29:48 +01:00
|
|
|
* (e.g. libkms for the bootup splash), we have to ensure that we
|
|
|
|
* always use map_and_fenceable for all scanout buffers. However,
|
|
|
|
* it may simply be too big to fit into mappable, in which case
|
|
|
|
* put it anyway and hope that userspace can cope (but always first
|
|
|
|
* try to preserve the existing ABI).
|
|
|
|
*/
|
|
|
|
vma = ERR_PTR(-ENOSPC);
|
|
|
|
if ((flags & PIN_MAPPABLE) == 0 &&
|
2022-09-01 11:38:54 -07:00
|
|
|
(!view || view->type == I915_GTT_VIEW_NORMAL))
|
2021-03-23 16:50:11 +01:00
|
|
|
vma = i915_gem_object_ggtt_pin_ww(obj, ww, view, 0, alignment,
|
2020-08-19 16:09:03 +02:00
|
|
|
flags | PIN_MAPPABLE |
|
|
|
|
PIN_NONBLOCK);
|
|
|
|
if (IS_ERR(vma) && vma != ERR_PTR(-EDEADLK))
|
2021-03-23 16:50:11 +01:00
|
|
|
vma = i915_gem_object_ggtt_pin_ww(obj, ww, view, 0,
|
2020-08-19 16:09:03 +02:00
|
|
|
alignment, flags);
|
2021-03-23 16:50:11 +01:00
|
|
|
if (IS_ERR(vma))
|
|
|
|
return vma;
|
2019-05-28 10:29:48 +01:00
|
|
|
|
2022-12-01 00:58:01 +01:00
|
|
|
vma->display_alignment = max(vma->display_alignment, alignment);
|
2021-01-19 21:43:35 +00:00
|
|
|
i915_vma_mark_scanout(vma);
|
2019-05-28 10:29:48 +01:00
|
|
|
|
2020-08-19 16:09:03 +02:00
|
|
|
i915_gem_object_flush_if_display_locked(obj);
|
|
|
|
|
2019-05-28 10:29:48 +01:00
|
|
|
return vma;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2023-03-31 10:25:56 +01:00
|
|
|
* i915_gem_object_set_to_cpu_domain - Moves a single object to the CPU read,
|
|
|
|
* and possibly write domain.
|
2019-05-28 10:29:48 +01:00
|
|
|
* @obj: object to act on
|
|
|
|
* @write: requesting write or read-only access
|
|
|
|
*
|
|
|
|
* This function returns when the move is complete, including waiting on
|
|
|
|
* flushes to occur.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
i915_gem_object_set_to_cpu_domain(struct drm_i915_gem_object *obj, bool write)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2019-05-28 10:29:51 +01:00
|
|
|
assert_object_held(obj);
|
2019-05-28 10:29:48 +01:00
|
|
|
|
|
|
|
ret = i915_gem_object_wait(obj,
|
|
|
|
I915_WAIT_INTERRUPTIBLE |
|
|
|
|
(write ? I915_WAIT_ALL : 0),
|
|
|
|
MAX_SCHEDULE_TIMEOUT);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2021-01-19 14:49:11 +00:00
|
|
|
flush_write_domain(obj, ~I915_GEM_DOMAIN_CPU);
|
2019-05-28 10:29:48 +01:00
|
|
|
|
|
|
|
/* Flush the CPU cache if it's still invalid. */
|
|
|
|
if ((obj->read_domains & I915_GEM_DOMAIN_CPU) == 0) {
|
|
|
|
i915_gem_clflush_object(obj, I915_CLFLUSH_SYNC);
|
|
|
|
obj->read_domains |= I915_GEM_DOMAIN_CPU;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* It should now be out of any other write domains, and we can update
|
|
|
|
* the domain values for our changes.
|
|
|
|
*/
|
|
|
|
GEM_BUG_ON(obj->write_domain & ~I915_GEM_DOMAIN_CPU);
|
|
|
|
|
|
|
|
/* If we're writing through the CPU, then the GPU read domains will
|
|
|
|
* need to be invalidated at next use.
|
|
|
|
*/
|
|
|
|
if (write)
|
|
|
|
__start_cpu_write(obj);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2023-03-31 10:25:56 +01:00
|
|
|
* i915_gem_set_domain_ioctl - Called when user space prepares to use an
|
|
|
|
* object with the CPU, either
|
2019-05-28 10:29:48 +01:00
|
|
|
* through the mmap ioctl's mapping or a GTT mapping.
|
|
|
|
* @dev: drm device
|
|
|
|
* @data: ioctl data blob
|
|
|
|
* @file: drm file
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_i915_gem_set_domain *args = data;
|
|
|
|
struct drm_i915_gem_object *obj;
|
|
|
|
u32 read_domains = args->read_domains;
|
|
|
|
u32 write_domain = args->write_domain;
|
|
|
|
int err;
|
|
|
|
|
2021-07-15 11:15:36 +01:00
|
|
|
if (IS_DGFX(to_i915(dev)))
|
|
|
|
return -ENODEV;
|
|
|
|
|
2019-05-28 10:29:48 +01:00
|
|
|
/* Only handle setting domains to types used by the CPU. */
|
|
|
|
if ((write_domain | read_domains) & I915_GEM_GPU_DOMAINS)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Having something in the write domain implies it's in the read
|
|
|
|
* domain, and only that read domain. Enforce that in the request.
|
|
|
|
*/
|
|
|
|
if (write_domain && read_domains != write_domain)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!read_domains)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
obj = i915_gem_object_lookup(file, args->handle);
|
|
|
|
if (!obj)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try to flush the object off the GPU without holding the lock.
|
|
|
|
* We will repeat the flush holding the lock in the normal manner
|
|
|
|
* to catch cases where we are gazumped.
|
|
|
|
*/
|
|
|
|
err = i915_gem_object_wait(obj,
|
|
|
|
I915_WAIT_INTERRUPTIBLE |
|
|
|
|
I915_WAIT_PRIORITY |
|
|
|
|
(write_domain ? I915_WAIT_ALL : 0),
|
|
|
|
MAX_SCHEDULE_TIMEOUT);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v7.
Instead of doing what we do currently, which will never work with
PROVE_LOCKING, do the same as AMD does, and something similar to
relocation slowpath. When all locks are dropped, we acquire the
pages for pinning. When the locks are taken, we transfer those
pages in .get_pages() to the bo. As a final check before installing
the fences, we ensure that the mmu notifier was not called; if it is,
we return -EAGAIN to userspace to signal it has to start over.
Changes since v1:
- Unbinding is done in submit_init only. submit_begin() removed.
- MMU_NOTFIER -> MMU_NOTIFIER
Changes since v2:
- Make i915->mm.notifier a spinlock.
Changes since v3:
- Add WARN_ON if there are any page references left, should have been 0.
- Return 0 on success in submit_init(), bug from spinlock conversion.
- Release pvec outside of notifier_lock (Thomas).
Changes since v4:
- Mention why we're clearing eb->[i + 1].vma in the code. (Thomas)
- Actually check all invalidations in eb_move_to_gpu. (Thomas)
- Do not wait when process is exiting to fix gem_ctx_persistence.userptr.
Changes since v5:
- Clarify why check on PF_EXITING is (temporarily) required.
Changes since v6:
- Ensure userptr validity is checked in set_domain through a special path.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Dave Airlie <airlied@redhat.com>
[danvet: s/kfree/kvfree/ in i915_gem_object_userptr_drop_ref in the
previous review round, but which got lost. The other open questions
around page refcount are imo better discussed in a separate series,
with amdgpu folks involved].
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-17-maarten.lankhorst@linux.intel.com
2021-03-23 16:50:05 +01:00
|
|
|
if (i915_gem_object_is_userptr(obj)) {
|
|
|
|
/*
|
|
|
|
* Try to grab userptr pages, iris uses set_domain to check
|
|
|
|
* userptr validity
|
|
|
|
*/
|
|
|
|
err = i915_gem_object_userptr_validate(obj);
|
|
|
|
if (!err)
|
|
|
|
err = i915_gem_object_wait(obj,
|
|
|
|
I915_WAIT_INTERRUPTIBLE |
|
|
|
|
I915_WAIT_PRIORITY |
|
|
|
|
(write_domain ? I915_WAIT_ALL : 0),
|
|
|
|
MAX_SCHEDULE_TIMEOUT);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2019-05-28 10:29:48 +01:00
|
|
|
/*
|
|
|
|
* Proxy objects do not control access to the backing storage, ergo
|
|
|
|
* they cannot be used as a means to manipulate the cache domain
|
|
|
|
* tracking for that backing storage. The proxy object is always
|
|
|
|
* considered to be outside of any cache domain.
|
|
|
|
*/
|
drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v7.
Instead of doing what we do currently, which will never work with
PROVE_LOCKING, do the same as AMD does, and something similar to
relocation slowpath. When all locks are dropped, we acquire the
pages for pinning. When the locks are taken, we transfer those
pages in .get_pages() to the bo. As a final check before installing
the fences, we ensure that the mmu notifier was not called; if it is,
we return -EAGAIN to userspace to signal it has to start over.
Changes since v1:
- Unbinding is done in submit_init only. submit_begin() removed.
- MMU_NOTFIER -> MMU_NOTIFIER
Changes since v2:
- Make i915->mm.notifier a spinlock.
Changes since v3:
- Add WARN_ON if there are any page references left, should have been 0.
- Return 0 on success in submit_init(), bug from spinlock conversion.
- Release pvec outside of notifier_lock (Thomas).
Changes since v4:
- Mention why we're clearing eb->[i + 1].vma in the code. (Thomas)
- Actually check all invalidations in eb_move_to_gpu. (Thomas)
- Do not wait when process is exiting to fix gem_ctx_persistence.userptr.
Changes since v5:
- Clarify why check on PF_EXITING is (temporarily) required.
Changes since v6:
- Ensure userptr validity is checked in set_domain through a special path.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Dave Airlie <airlied@redhat.com>
[danvet: s/kfree/kvfree/ in i915_gem_object_userptr_drop_ref in the
previous review round, but which got lost. The other open questions
around page refcount are imo better discussed in a separate series,
with amdgpu folks involved].
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-17-maarten.lankhorst@linux.intel.com
2021-03-23 16:50:05 +01:00
|
|
|
if (i915_gem_object_is_proxy(obj)) {
|
2019-05-28 10:29:48 +01:00
|
|
|
err = -ENXIO;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2021-01-28 17:25:37 +01:00
|
|
|
err = i915_gem_object_lock_interruptible(obj, NULL);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
2019-05-28 10:29:48 +01:00
|
|
|
/*
|
|
|
|
* Flush and acquire obj->pages so that we are coherent through
|
|
|
|
* direct access in memory with previous cached writes through
|
|
|
|
* shmemfs and that our cache domain tracking remains valid.
|
|
|
|
* For example, if the obj->filp was moved to swap without us
|
|
|
|
* being notified and releasing the pages, we would mistakenly
|
|
|
|
* continue to assume that the obj remained out of the CPU cached
|
|
|
|
* domain.
|
|
|
|
*/
|
|
|
|
err = i915_gem_object_pin_pages(obj);
|
|
|
|
if (err)
|
2021-01-28 17:25:37 +01:00
|
|
|
goto out_unlock;
|
2019-05-28 10:29:48 +01:00
|
|
|
|
2020-10-19 21:38:25 +01:00
|
|
|
/*
|
|
|
|
* Already in the desired write domain? Nothing for us to do!
|
|
|
|
*
|
|
|
|
* We apply a little bit of cunning here to catch a broader set of
|
|
|
|
* no-ops. If obj->write_domain is set, we must be in the same
|
|
|
|
* obj->read_domains, and only that domain. Therefore, if that
|
|
|
|
* obj->write_domain matches the request read_domains, we are
|
|
|
|
* already in the same read/write domain and can skip the operation,
|
|
|
|
* without having to further check the requested write_domain.
|
|
|
|
*/
|
|
|
|
if (READ_ONCE(obj->write_domain) == read_domains)
|
|
|
|
goto out_unpin;
|
|
|
|
|
2019-05-28 10:29:48 +01:00
|
|
|
if (read_domains & I915_GEM_DOMAIN_WC)
|
|
|
|
err = i915_gem_object_set_to_wc_domain(obj, write_domain);
|
|
|
|
else if (read_domains & I915_GEM_DOMAIN_GTT)
|
|
|
|
err = i915_gem_object_set_to_gtt_domain(obj, write_domain);
|
|
|
|
else
|
|
|
|
err = i915_gem_object_set_to_cpu_domain(obj, write_domain);
|
|
|
|
|
2021-01-28 17:25:37 +01:00
|
|
|
out_unpin:
|
|
|
|
i915_gem_object_unpin_pages(obj);
|
|
|
|
|
|
|
|
out_unlock:
|
2019-05-28 10:29:51 +01:00
|
|
|
i915_gem_object_unlock(obj);
|
2019-05-28 10:29:48 +01:00
|
|
|
|
2021-01-28 17:25:37 +01:00
|
|
|
if (!err && write_domain)
|
2019-12-18 10:40:43 +00:00
|
|
|
i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
|
2019-05-28 10:29:48 +01:00
|
|
|
|
|
|
|
out:
|
|
|
|
i915_gem_object_put(obj);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Pins the specified object's pages and synchronizes the object with
|
|
|
|
* GPU accesses. Sets needs_clflush to non-zero if the caller should
|
|
|
|
* flush the object from the CPU cache.
|
|
|
|
*/
|
|
|
|
int i915_gem_object_prepare_read(struct drm_i915_gem_object *obj,
|
|
|
|
unsigned int *needs_clflush)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
*needs_clflush = 0;
|
|
|
|
if (!i915_gem_object_has_struct_page(obj))
|
|
|
|
return -ENODEV;
|
|
|
|
|
2020-08-19 16:08:46 +02:00
|
|
|
assert_object_held(obj);
|
2019-05-28 10:29:51 +01:00
|
|
|
|
2019-05-28 10:29:48 +01:00
|
|
|
ret = i915_gem_object_wait(obj,
|
2019-05-28 10:29:51 +01:00
|
|
|
I915_WAIT_INTERRUPTIBLE,
|
2019-05-28 10:29:48 +01:00
|
|
|
MAX_SCHEDULE_TIMEOUT);
|
|
|
|
if (ret)
|
2020-08-19 16:08:46 +02:00
|
|
|
return ret;
|
2019-05-28 10:29:48 +01:00
|
|
|
|
|
|
|
ret = i915_gem_object_pin_pages(obj);
|
|
|
|
if (ret)
|
2020-08-19 16:08:46 +02:00
|
|
|
return ret;
|
2019-05-28 10:29:48 +01:00
|
|
|
|
|
|
|
if (obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ ||
|
|
|
|
!static_cpu_has(X86_FEATURE_CLFLUSH)) {
|
|
|
|
ret = i915_gem_object_set_to_cpu_domain(obj, false);
|
|
|
|
if (ret)
|
|
|
|
goto err_unpin;
|
|
|
|
else
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2021-01-19 14:49:11 +00:00
|
|
|
flush_write_domain(obj, ~I915_GEM_DOMAIN_CPU);
|
2019-05-28 10:29:48 +01:00
|
|
|
|
|
|
|
/* If we're not in the cpu read domain, set ourself into the gtt
|
|
|
|
* read domain and manually flush cachelines (if required). This
|
|
|
|
* optimizes for the case when the gpu will dirty the data
|
|
|
|
* anyway again before the next pread happens.
|
|
|
|
*/
|
|
|
|
if (!obj->cache_dirty &&
|
|
|
|
!(obj->read_domains & I915_GEM_DOMAIN_CPU))
|
|
|
|
*needs_clflush = CLFLUSH_BEFORE;
|
|
|
|
|
|
|
|
out:
|
|
|
|
/* return with the pages pinned */
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_unpin:
|
|
|
|
i915_gem_object_unpin_pages(obj);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int i915_gem_object_prepare_write(struct drm_i915_gem_object *obj,
|
|
|
|
unsigned int *needs_clflush)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
*needs_clflush = 0;
|
|
|
|
if (!i915_gem_object_has_struct_page(obj))
|
|
|
|
return -ENODEV;
|
|
|
|
|
2020-08-19 16:08:46 +02:00
|
|
|
assert_object_held(obj);
|
2019-05-28 10:29:51 +01:00
|
|
|
|
2019-05-28 10:29:48 +01:00
|
|
|
ret = i915_gem_object_wait(obj,
|
|
|
|
I915_WAIT_INTERRUPTIBLE |
|
|
|
|
I915_WAIT_ALL,
|
|
|
|
MAX_SCHEDULE_TIMEOUT);
|
|
|
|
if (ret)
|
2020-08-19 16:08:46 +02:00
|
|
|
return ret;
|
2019-05-28 10:29:48 +01:00
|
|
|
|
|
|
|
ret = i915_gem_object_pin_pages(obj);
|
|
|
|
if (ret)
|
2020-08-19 16:08:46 +02:00
|
|
|
return ret;
|
2019-05-28 10:29:48 +01:00
|
|
|
|
|
|
|
if (obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE ||
|
|
|
|
!static_cpu_has(X86_FEATURE_CLFLUSH)) {
|
|
|
|
ret = i915_gem_object_set_to_cpu_domain(obj, true);
|
|
|
|
if (ret)
|
|
|
|
goto err_unpin;
|
|
|
|
else
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2021-01-19 14:49:11 +00:00
|
|
|
flush_write_domain(obj, ~I915_GEM_DOMAIN_CPU);
|
2019-05-28 10:29:48 +01:00
|
|
|
|
|
|
|
/* If we're not in the cpu write domain, set ourself into the
|
|
|
|
* gtt write domain and manually flush cachelines (as required).
|
|
|
|
* This optimizes for the case when the gpu will use the data
|
|
|
|
* right away and we therefore have to clflush anyway.
|
|
|
|
*/
|
|
|
|
if (!obj->cache_dirty) {
|
|
|
|
*needs_clflush |= CLFLUSH_AFTER;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Same trick applies to invalidate partially written
|
|
|
|
* cachelines read before writing.
|
|
|
|
*/
|
|
|
|
if (!(obj->read_domains & I915_GEM_DOMAIN_CPU))
|
|
|
|
*needs_clflush |= CLFLUSH_BEFORE;
|
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
2019-12-18 10:40:43 +00:00
|
|
|
i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
|
2019-05-28 10:29:48 +01:00
|
|
|
obj->mm.dirty = true;
|
|
|
|
/* return with the pages pinned */
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_unpin:
|
|
|
|
i915_gem_object_unpin_pages(obj);
|
|
|
|
return ret;
|
|
|
|
}
|