On 03.08.2022 17:22, Jani Nikula wrote:
>On Tue, 02 Aug 2022, Adrian Larumbe wrote:
>> Introduces a new module parameter, 'use_pool_alloc', which defaults to
>> 'false'. Its goal is to make the driver fall back on TTM for setting up
>> the system memory region, so t
i965gm devices cannot relocate objects above 4GiB. This situation was
already being handled in the older shmem GEM object backend, but not in TTM
for BO's that are allocated in system memory.
Borrow the code from shmem so that TTM handles them in the same way.
Signed-off-by: Adrian Larumbe
From: Robert Beckett
By default i915_ttm_cache_level() decides I915_CACHE_LLC if HAS_SNOOP.
This is divergent from existing backends code which only considers
HAS_LLC.
Testing shows that trusting snooping on gen5- is unreliable and bsw via
ggtt mappings, so limit DGFX for now and maintain
.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c| 21 ++-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_phys.c| 127 -
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 +-
drivers/gpu/drm/i915/gem
kernel module param, which will be
used by successive commits.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/i915_params.c | 6 ++
drivers/gpu/drm/i915/i915_params.h | 3 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers
From: Robert Beckett
i965G[M] cannot relocate objects above 4GiB.
Ensure ttm uses dma32 on these systems.
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/intel_region_ttm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
m_tt_populate in __i915_ttm_get_pages, which eventually led to a warning
in DGFX platforms.
Make sure it's not set in DGFX platforms.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu
From: Robert Beckett
Various places within the driver override the default chosen cache_level.
Before ttm, these overrides were permanent until explicitly changed again
or for the lifetime of the buffer.
TTM movement code came along and decided that it could make that
decision at that time,
and coherence for sysmem-allocated objects too.
Adrian Larumbe (4):
drm/i915/ttm: don't overwrite cache_dirty after setting coherency
drm/i915: Pick the right memory allocation flags for older devices
drm/i915: Add module param for enabling TTM in sysmem region
drm/i915: Optionally manage system memory
...@collabora.com
Adrian Larumbe (2):
drm/i915: Change semantics of context isolation reporting to UM
drm/i915: force getparam ioctl return bool for HAS_CONTEXT_ISOLATION
drivers/gpu/drm/i915/gt/intel_engine_user.c | 14 ++
drivers/gpu/drm/i915/gt/intel_engine_user.h | 1 +
drivers/gpu/drm
In a previous commit, the uAPI documentation for this param was updated
to reflect the actual usage expected by Iris. Now make sure the driver
does indeed return a boolean value rather than an engine bitmask.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 14
isolation is supported, and IGT gem_ctx_isolation was
exploiting this wrong semantics when making decisions about which
engines support it.
This is a uAPI documentation change that precedes the actual change in
the getparam ioctl.
Signed-off-by: Adrian Larumbe
---
include/uapi/drm/i915_drm.h
Various places within the driver override the default chosen cache_level.
Before ttm, these overrides were permanent until explicitly changed again or
for the lifetime of the buffer.
TTM movement code came along and decided that it could make that
decision at that time, which is usually well
in
https://lists.freedesktop.org/archives/intel-gfx/2022-May/298082.html.
Adrian Larumbe (3):
drm/i915/ttm: dont trample cache_level overrides during ttm move
drm/i915/ttm: don't overwrite cache_dirty after setting coherency
drm/i915/ttm: remove shmem memory region and gem object backend
through the old phys backend.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 14 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 6 +-
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 29 +-
drivers/gpu/drm
ove statement altogether.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 3e5d6057b3ef..b2c9e16bfa55 100644
On 01.06.2022 19:43, Ruhl, Michael J wrote:
>>-Original Message-
>>From: Adrian Larumbe
>>Sent: Friday, May 27, 2022 12:08 PM
>>To: Ruhl, Michael J
>>Cc: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org
>>Subject: Re: [Intel-gfx] [RFC PATCH v2 1/1] drm
On 17.05.2022 21:39, Ruhl, Michael J wrote:
> >-Original Message-
> >From: Intel-gfx On Behalf Of
> >Adrian Larumbe
> >Sent: Tuesday, May 17, 2022 4:45 PM
> >To: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org
> >Cc: adrian.laru...@collabora.com
>
On 18.05.2022 16:00, Matthew Auld wrote:
> On Tue, 17 May 2022 at 21:45, Adrian Larumbe
> wrote:
> >
> > This patch is a second attempt at eliminating the old shmem memory region
> > and GEM object backend, in favour of a TTM-based one that is able to manage
> >
TTM backend code
I've tried to handle object creation and getting its pages with the same
set of caching and coherency properties as in the old shmem backend.
Adrian Larumbe (1):
drm/i915: Replace shmem memory region and object backend with TTM
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c |
a TTM shmem object has no struct
page.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 12 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 32 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 32
Hi, Tvrtko
On 03.05.2022 15:44, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 29/04/2022 16:11, Adrian Larumbe wrote:
> > I915_PARAM_HAS_CONTEXT_ISOLATION was already being used as a boolean by
> > both Iris and Vulkan , and stood for the guarantee that, when creating a
> &
engine support was added to the
driver in commit 944823c9463916dd53f3 ("drm/i915/xehp: Define compute class
and engine") because no context isolation can be assumed on any device with
both RCS annd CCS engines.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gt/intel_engine_u
engine support was added to the
driver in commit 944823c9463916dd53f3 ("drm/i915/xehp: Define compute class
and engine") because no context isolation can be assumed on any device with
both RCS annd CCS engines.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gt/intel_engine_u
getting its pages beforehand, unlike in the old shmem backend.
Expand TTM BO creation by handling devices with no LLC so that their
caching and coherency properties are set accordingly.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 12 +-
drivers/gpu/drm/i915
, I haven't yet implemented the pread callback for TTM
object backend, as it seems CI's BAT test list doesn't include it.
Adrian Larumbe (1):
drm/i915: Replace shmem memory region and object backend with TTM
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 12 +-
drivers/gpu/drm/i915/gem/i915_gem_mma
When a flat-CCS aware bo is evicted from lmem, its control surface will be
written out into smem. This will be done in the shape of a kernel-only bo
attached to the original bo.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 10 ++
1 file changed
when the original TTM object
reaches the end of its life.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 11 +++
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 78 +++-
2 files changed, 87 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu
It has to be used by other files other than low-level migration code.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 1 -
drivers/gpu/drm/i915/i915_drv.h | 5 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt
Adds frame buffer support code for flat-CCS devices, like DG2. A flat-CCS
modifier is attached to a fb object that contains the original bo by means
of the drmModeAddFB2WithModifiers drm API call.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/display/intel_fb.c | 36
Because the smem-evicted bo that holds the CCS block has to be blitted
separately from the original compressed bo, two sets of PTEs have to
be emitted for every bo copy.
This commit is partially based off another commit from Ramalingam C
, currently under discussion.
Signed-off-by: Adrian
a slightly
different approach.
For testing, a flat-CCS driver self-test is under preparation.
Adrian Larumbe (5):
drm/i915/flat-CCS: Add GEM BO structure fields for flat-CCS
drm/i915/flat-CCS: Add flat CCS plane capabilities and modifiers
drm/i915/flat-CCS: move GET_CCS_SIZE macro into d
Beginning with DG2, all successive devices will require GuC FW to be
present and loaded at probe() time. This change alters error handling in
the FW init and load functions so that the driver's probe() function will
fail if GuC could not be loaded.
Signed-off-by: Adrian Larumbe
---
drivers/gpu
33 matches
Mail list logo
