; case to allow i915_gem_evict_vm to evict locked objects as well.
>
> This might also allow multiple objects sharing the same resv to be evicted.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Do we need similar treatment for stuff like evict_for_node etc?
&g
On Wed, 8 Dec 2021 at 11:49, Matthew Auld
wrote:
>
> On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
> wrote:
> >
> > Now that we require locking to evict, multiple vmas from the same object
> > might not be evicted. This is expected and required, because execbuf
On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
wrote:
>
> Now that we require locking to evict, multiple vmas from the same object
> might not be evicted. This is expected and required, because execbuf will
> move to short-term pinning by using the lock only. This will cause these
> tests to
that the memory is functional.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: CQ Tang
Signed-off-by: Ramalingam C
For the series, assuming CI is happy now,
Reviewed-by: Matthew Auld
Also patch 3 should be moved to the start of the series.
---
drivers/gpu/drm/i915/intel_memory_region.c
the current ww context.
>
> On top of that, this slightly improves ww handling because the locked
> objects are marked as locked by the correct ww.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
On 07/12/2021 13:10, Tvrtko Ursulin wrote:
On 18/10/2021 10:10, Matthew Auld wrote:
For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such objects. For now this is still disabled
On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
wrote:
>
> Now that freeing objects takes the object lock when destroying the
> backing pages, we can confidently take the object lock even for dead
> objects.
That looks to be a future patch, at least with non-TTM backend? Does
something need to
On Tue, 7 Dec 2021 at 10:06, Maarten Lankhorst
wrote:
>
> On 06-12-2021 18:10, Matthew Auld wrote:
> > On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
> > wrote:
> >> Big delta, but boils down to moving set_pages to i915_vma.c, and removing
> >> the special ha
u32),
> alignof_dword);
>
> - err = write_to_scratch(ctx_a, engine,
> + err = write_to_scratch(ctx_a, engine, obj_a,
>offset, 0xdeadbeef);
> if (err == 0)
> -
On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
wrote:
>
> Big delta, but boils down to moving set_pages to i915_vma.c, and removing
> the special handling, all callers use the defaults anyway. We only remap
> in ggtt, so default case will fall through.
>
> Because we still don't require locking
On Mon, 6 Dec 2021 at 15:18, Maarten Lankhorst
wrote:
>
> On 06-12-2021 14:13, Matthew Auld wrote:
> > On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
> > wrote:
> >> Big delta, but boils down to moving set_pages to i915_vma.c, and removing
> >> the special ha
On 06/12/2021 14:49, Daniel Stone wrote:
Hi Matthew,
On Mon, 6 Dec 2021 at 13:32, Matthew Auld wrote:
Enable accelerated moves and clearing on DG2. On such HW we have minimum page
size restrictions when accessing LMEM from the GTT, where we now have to use 64K
GTT pages or larger
This is all kinds of awkward since we now have to contend with using 64K
GTT pages when mapping anything in LMEM(including the page-tables
themselves).
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 189
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index fb658ae70a8d..0fb83d0bec91 100644
If this is LMEM then we get a 32 entry PT, with each PTE pointing to
some 64K block of memory, otherwise it's just the usual 512 entry PT.
This very much assumes the caller knows what they are doing.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
Reviewed-by: Ramalingam C
On some platforms we have alignment restrictions when accessing LMEM
from the GTT. In the next patch few patches we need to be able to modify
the page-tables directly via the GTT itself.
Suggested-by: Ramalingam C
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers
Ensure we account for any object rounding due to min_page_size
restrictions.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
Reviewed-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/selftest_migrate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt
No need to insert PTEs for the PTE window itself, also foreach expects a
length not an end offset, which could be gigantic here with a second
engine.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
Reviewed-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 2
Ensure we add the engine base only after we calculate the qword offset
into the PTE window.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
Reviewed-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
The scratch page might not be allocated in LMEM(like on DG2), so instead
of using that as the deciding factor for where the paging structures
live, let's just query the pt before mapping it.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
Reviewed-by: Ramalingam C
to be applied on top of the DG2 enabling branch:
https://cgit.freedesktop.org/~ramaling/linux/log/?h=dg2_enabling_ww49.3
Matthew Auld (8):
drm/i915/migrate: don't check the scratch page
drm/i915/migrate: fix offset calculation
drm/i915/migrate: fix length calculation
drm/i915/selftests: handle
On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
wrote:
>
> i915_vma_wait_for_bind needs the vma lock held, fix the caller.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
wrote:
>
> Big delta, but boils down to moving set_pages to i915_vma.c, and removing
> the special handling, all callers use the defaults anyway. We only remap
> in ggtt, so default case will fall through.
>
> Because we still don't require locking
On 03/12/2021 17:30, Ramalingam C wrote:
On 2021-12-03 at 12:24:22 +, Matthew Auld wrote:
Ensure we add the engine base only after we calculate the qword offset
into the PTE window.
So we didn't hit this issue because we were always using the
engine->instance 0!?
Yes, AFAIK.
Lo
On 03/12/2021 17:25, Ramalingam C wrote:
On 2021-12-03 at 12:24:21 +, Matthew Auld wrote:
With object clearing/copying we need to be able to modify the PTEs on
the fly via some batch buffer, which means we need to be able to map the
paging structures(or at the very least the PT, but being
On 03/12/2021 16:59, Ramalingam C wrote:
On 2021-12-03 at 12:24:20 +, Matthew Auld wrote:
If this is LMEM then we get a 32 entry PT, with each PTE pointing to
some 64K block of memory, otherwise it's just the usual 512 entry PT.
This very much assumes the caller knows what they are doing
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index a804c57b61df..0da27ec808dc 100644
This is all kinds of awkward since we now have to contend with using 64K
GTT pages when mapping anything in LMEM(including the page-tables
themselves).
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 186
No need to insert PTEs for the PTE window itself, also foreach expects a
length not an end offset, which could be gigantic here with a second
engine.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +-
1 file changed, 1
Ensure we account for any object rounding due to min_page_size
restrictions.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/selftest_migrate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c
b
Ensure we add the engine base only after we calculate the qword offset
into the PTE window.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt
-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++--
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.c| 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c| 3 ++-
drivers
If this is LMEM then we get a 32 entry PT, with each PTE pointing to
some 64K block of memory, otherwise it's just the usual 512 entry PT.
This very much assumes the caller knows what they are doing.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt
The scratch page might not be allocated in LMEM(like on DG2), so instead
of using that as the deciding factor for where the paging structures
live, let's just query the pt before mapping it.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt
to be applied on top of the DG2 enabling branch:
https://cgit.freedesktop.org/~ramaling/linux/log/?h=dg2_enabling_ww49.3
Patches 2, 7 and 8 have a dependency on patches in that branch, but the rest can
likely already land if the direction makes sense.
Matthew Auld (8):
drm/i915/migrate: don't check
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index a804c57b61df..0da27ec808dc 100644
Ensure we account for any object rounding due to min_page_size
restrictions.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/selftest_migrate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c
b
This is all kinds of awkward since we now have to contend with using 64K
GTT pages when mapping anything in LMEM(including the page-tables
themselves).
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 186
No need to insert PTEs for the PTE window itself, also foreach expects a
length not an end offset, which could be gigantic here with a second
engine.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +-
1 file changed, 1
Ensure we add the engine base only after we calculate the qword offset
into the PTE window.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt
-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++--
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.c| 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c| 3 ++-
drivers
If this is LMEM then we get a 32 entry PT, with each PTE pointing to
some 64K block of memory, otherwise it's just the usual 512 entry PT.
This very much assumes the caller knows what they are doing.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt
The scratch page might not be allocated in LMEM(like on DG2), so instead
of using that as the deciding factor for where the paging structures
live, let's just query the pt before mapping it.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt
err = i915_gem_object_lock(obj, );
> + if (err)
> + continue;
> +
> + ret = i915_gem_object_ggtt_pin_ww(obj, , view, size,
> + alignment, flags);
> + if (IS_ERR(
On 23/11/2021 22:39, Arunpravin wrote:
On 18/11/21 12:09 am, Matthew Auld wrote:
On 16/11/2021 20:18, Arunpravin wrote:
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
: warning: No description found for return value of
'i915_gem_object_read_from_page'
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: intel-...@lists.freedesktop.org
-2021-11-12' of git://anongit.freedesktop.org/drm/drm").
Signed-off-by: Tvrtko Ursulin
Fixes: 777226dac058 ("drm/i915/dmabuf: fix broken build")
Cc: Matthew Auld
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Jani Nikula
Acked-by: Matthew
On 22/11/2021 07:41, Dan Carpenter wrote:
This function returns a bool type so returning -EBUSY is equivalent to
returning true. It should return false instead.
Fixes: 7ae034590cea ("drm/i915/ttm: add tt shmem backend")
Signed-off-by: Dan Carpenter
Reviewed-by: Matthew Auld
On 18/11/2021 13:02, Thomas Hellström wrote:
Update the copy function i915_gem_obj_copy_ttm() to be asynchronous for
future users and update the only current user to sync the objects
as needed after this function.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
issues (Matthew Auld)
- Audit and add more checks for ghost objects (Matthew Auld)
- Add more documentation for the i915_deps utility (Mattew Auld)
- Simplify the i915_deps_sync() function
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 32 +-
drivers/gpu/drm
Reviewed-by: Matthew Auld
off-by: Thomas Hellström
Reviewed-by: Matthew Auld
nce waiting for i915_vma_pin_iomap() and
replace with a verification that the vma is already bound.
(Matthew Auld)
- Squash with a previous patch introducing moving fence waiting and
accessing interfaces (Matthew Auld)
- Rename to indicated that we also add support for sync waiting.
On 18/11/2021 06:57, Thomas Hellström wrote:
On Wed, 2021-11-17 at 19:49 +0100, Thomas Hellström wrote:
On 11/17/21 15:20, Matthew Auld wrote:
In intel_context_do_pin_ww, when calling into the pre_pin
hook(which is
passed the ww context) it could in theory return -EDEADLK(which is
very
likely
On 16/11/2021 20:18, Arunpravin wrote:
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
v2(Matthew Auld):
- replace function name 'drm_buddy_free_unused_pages' with
drm_buddy_block_trim
to i915 driver
v3(Matthew Auld):
- Fix alignment issues and remove unnecessary list_empty check
- add more validation checks for input arguments
- make alloc_range() block allocations as bottom-up
- optimize order computation logic
- replace uint64_t with u64, which is preferred
On 16/11/2021 20:18, Arunpravin wrote:
Move the base i915 buddy allocator code into drm
- Move i915_buddy.h to include/drm
- Move i915_buddy.c to drm root folder
- Rename "i915" string with "drm" string wherever applicable
- Rename "I915" string with "DRM" string wherever applicable
- Fix header
From: Maarten Lankhorst
Lets be thorough here. Users of the TTM backend would likely expect this
behaviour.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers
From: Maarten Lankhorst
It's just an alias to vma->obj->base.resv, no need to duplicate it.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Niranjana Vishwanathapura
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/i915
From: Maarten Lankhorst
vma->obj and vma->resv are now never NULL, and some checks can be removed.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submis
ect is created. It just has to look real enough.
Also kill pin_mutex, it's not compatible with ww locking,
and we can use the vm lock instead.
v2:
- Drop IS_SHRINKABLE and shorten overly long line
v3:
- Checkpatch fix for alignment
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-
hew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/mock_engine.c | 38 ---
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c
b/drivers/gpu/drm/i915/gt/mock_engine.c
index 8b89215afe46..bb99fc03f503 100
-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 5634d14052bc
On 14/11/2021 11:12, Thomas Hellström wrote:
Don't wait sync while migrating, but rather make the GPU blit await the
dependencies and add a moving fence to the object.
This also enables asynchronous VRAM management in that on eviction,
rather than waiting for the moving fence to expire before
On 15/11/2021 12:42, Thomas Hellström wrote:
On 11/15/21 13:36, Matthew Auld wrote:
On 14/11/2021 11:12, Thomas Hellström wrote:
From: Maarten Lankhorst
For now, we will only allow async migration when TTM is used,
so the paths we care about are related to TTM.
The mmap path is handled
On 14/11/2021 11:12, Thomas Hellström wrote:
From: Maarten Lankhorst
We want to get rid of i915_vma tracking to simplify the code and
lifetimes. Add a way to set/put the moving fence, in preparation for
removing the tracking.
Signed-off-by: Maarten Lankhorst
---
On 14/11/2021 11:12, Thomas Hellström wrote:
From: Maarten Lankhorst
For now, we will only allow async migration when TTM is used,
so the paths we care about are related to TTM.
The mmap path is handled by having the fence in ttm_bo->moving,
when pinning, the binding only becomes available
On 14/11/2021 11:12, Thomas Hellström wrote:
There is an interesting refcounting loop:
struct intel_memory_region has a struct ttm_resource_manager,
ttm_resource_manager->move may hold a reference to i915_request,
i915_request may hold a reference to intel_context,
intel_context may hold a
On 14/11/2021 11:12, Thomas Hellström wrote:
Move the i915_gem_obj_copy_ttm() function to i915_gem_ttm_move.h.
This will help keep a number of functions static when introducing
async moves.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
i915_disable_error_state when wedging on init/fini.
v3:
* Handle mock tests.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Matthew Auld # v1
Assuming this works locally, r-b still stands.
---
drivers/gpu/drm/i915/gt/intel_reset.c| 2 ++
drivers/gpu/drm/i915/selftests/mock_gem_device.c
From: Maarten Lankhorst
Lets be thorough here. Users of the TTM backend would likely expect this
behaviour.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers
From: Maarten Lankhorst
It's just an alias to vma->obj->base.resv, no need to duplicate it.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Niranjana Vishwanathapura
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/i915
.
For normal user contexts this shouldn't be a concern, since we should
already have the default_state ready when initialising the lrc state,
and so there should be no concern with active_release somehow
prematurely setting the CONTEXT_VALID_BIT.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc
ect is created. It just has to look real enough.
Also kill pin_mutex, it's not compatible with ww locking,
and we can use the vm lock instead.
v2:
- Drop IS_SHRINKABLE and shorten overly long line
v3:
- Checkpatch fix for alignment
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-
From: Maarten Lankhorst
vma->obj and vma->resv are now never NULL, and some checks can be removed.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submis
hew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/mock_engine.c | 38 ---
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c
b/drivers/gpu/drm/i915/gt/mock_engine.c
index 8b89215afe46..bb99fc03f503 100
or wedging on init.
>
> Signed-off-by: Tvrtko Ursulin
This fixes the issue with missing GuC wedging the GPU and then blowing
up when trying to use the driver?
Reviewed-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_gpu_error.c | 10 +++---
> 1 file changed, 7 insertions(
have a GEM refcount.
Fixes: ebd4a8ec7799 ("drm/i915/ttm: move shrinker management into adjust_lru")
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
the
_SELF_MANAGED_SHRINK_LIST set, make sure they end up on the
correct list.
v2:
- Revert a change that made swapped-out objects inaccessible for
truncating. (Matthew Auld)
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
1 file changed, 2 insertions
On 05/11/2021 13:03, Thomas Hellström wrote:
Gem-TTM objects that are backed by shmem might have populated
page-vectors without having the Gem pages set. Those objects
aren't moved to the correct shrinker / purge list by the
gem_madvise. Furthermore they are purged directly on
MADV_DONTNEED
On 04/11/2021 07:34, Christian König wrote:
Am 03.11.21 um 20:25 schrieb Matthew Auld:
On 25/10/2021 14:00, Arunpravin wrote:
- Remove drm_mm references and replace with drm buddy functionalities
- Add res cursor support for drm buddy
Signed-off-by: Arunpravin
+ spin_lock(>l
On 25/10/2021 14:00, Arunpravin wrote:
- Remove drm_mm references and replace with drm buddy functionalities
- Add res cursor support for drm buddy
Signed-off-by: Arunpravin
+ spin_lock(>lock);
+ r = drm_buddy_alloc(mm, (uint64_t)place->fpfn << PAGE_SHIFT,
+
On 25/10/2021 14:00, Arunpravin wrote:
add drm_buddy_free_unused_pages() support on
contiguous allocation
Signed-off-by: Arunpravin
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
On 25/10/2021 14:00, Arunpravin wrote:
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
Signed-off-by: Arunpravin
Ideally this gets added with some user, so we can see it in action?
Maybe
On 25/10/2021 14:00, Arunpravin wrote:
Implemented a function which walk through the order list,
compares the offset and returns the maximum offset block,
this method is unpredictable in obtaining the high range
address blocks which depends on allocation and deallocation.
for instance, if driver
On 25/10/2021 14:00, Arunpravin wrote:
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation
On Tue, 2 Nov 2021 at 17:55, Thomas Hellström
wrote:
>
>
> On 11/2/21 18:40, Matthew Auld wrote:
> > On Tue, 2 Nov 2021 at 16:39, Thomas Hellström
> > wrote:
> >> If the initial fill blit or copy blit of an object fails, the old
> >> content of the
failures and failure to allocate
> the async dma_fence_work.
>
> A previous version of this pach used dma_fence_work, now that's
> opencoded which adds more code but might lower the latency
> somewhat in the common non-error case.
>
> v3:
> - Style fixes (Matthew Auld)
&g
On Thu, 21 Oct 2021 at 11:37, Maarten Lankhorst
wrote:
>
> Resetting will clear the CONTEXT_VALID_BIT, so wait until after that to test.
>
AFAIK this seems to be fixing something earlier in the series(maybe
patch 7?) i.e without this patch we seem to trigger the BUG_ON. If so,
this needs to be
dma_fence_wait expects a boolean for whether it should be interruptible,
not a timeout value.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/i915_vma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu
g to system, TTM or shmem will provide us with
+* cleared pages.
+*/
+ if (!IS_ERR(fence) && !i915_ttm_gtt_binds_lmem(dst_mem) &&
+ !I915_SELFTEST_ONLY(fail_gpu_migration ||
+ fail
be
no functional change.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
ematurely freed, and finally the subclassed struct ttm_resource would
> have to bleed into the asynchronous vma bind code.
>
> v3:
> - Address a number of style issues (Matthew Auld)
> v4:
> - Dont check for st->sgl being NULL in i915_ttm_tt__shmem_unpopulate(),
> that shou
We were overzealous here; even though discrete is non-LLC, it should
still be always coherent.
v2(Thomas & Daniel)
- Be extra cautious and limit to DG1
- Add some more commentary
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Daniel Vetter
---
drivers/gpu/drm/i915
From: Maarten Lankhorst
TTM already requires this, and we require it for delayed destroy.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers
From: Maarten Lankhorst
Lets be thorough here. Users of the TTM backend would likely expect this
behaviour.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers
subtest starts with a clean slate, and a
clean address space.
v2:
- Make hugepage_ctx static. Reported-by: kernel test robot
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 128 +++---
1
From: Maarten Lankhorst
It's just an alias to vma->obj->base.resv, no need to duplicate it.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Niranjana Vishwanathapura
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/i915
ect is created. It just has to look real enough.
Also kill pin_mutex, it's not compatible with ww locking,
and we can use the vm lock instead.
v2:
- Drop IS_SHRINKABLE and shorten overly long line
v3:
- Checkpatch fix for alignment
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-
From: Maarten Lankhorst
vma->obj and vma->resv are now never NULL, and some checks can be removed.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submis
601 - 700 of 1542 matches
Mail list logo
