. Idling of the gt has to wait for all
this to complete which is taking ~3sec for this test.
Hence we are increasing the igt_flush_test's timeout for gt idling to
3Sec.
Signed-off-by: Ramalingam C
cc: Matthew Brost
Acked-by: Matthew Auld
On 28/01/2022 18:52, Ramalingam C wrote:
Align the plane vma size to the stolem memory regions' min_page_size.
Signed-off-by: Ramalingam C
cc: Matthew Auld
cc: Chris P Wilson
Reviewed-by: Matthew Auld
On Thu, 27 Jan 2022 at 14:11, Arunpravin
wrote:
>
> - Remove drm_mm references and replace with drm buddy functionalities
> - Add res cursor support for drm buddy
>
> v2(Matthew Auld):
> - replace spinlock with mutex as we call kmem_cache_zalloc
> (..., GFP_KERNE
Just for CI.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 5 ++---
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem
On platforms where there might be non-mappable LMEM, force userspace to
mark the buffers with the correct hint. When dumping the BO contents
during capture we need CPU access. Note this only applies to buffers
that can be placed in LMEM, and also doesn't impact DG1.
Signed-off-by: Matthew Auld
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-mappable.
It does leave open with what to do with stolen local-memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_region_lmem.c
IGTs. Including now just for the sake
of having more complete picture.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 28 ---
include/uapi/drm/i915_drm.h| 31 +-
2 files changed, 49 insertions
Check that mappable vs non-mappable matches our expectations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../drm/i915/selftests/intel_memory_region.c | 143 ++
1 file changed, 143 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
b
Exercise each of the migration scenarios, verifying that the final
placement and buffer contents match our expectations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../drm/i915/gem/selftests/i915_gem_mman.c| 306 ++
1 file changed, 306 insertions(+)
diff --git
will return -ENOMEM if the object can't be
placed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/selftests/intel_memory_region.c | 8 +++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers
we hopefully victimize these last.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 65 -
1 file changed, 63 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem
userspace will be able to provide a hint if CPU access
to the buffer is needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/dr
placements permit it.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 58 ++---
1 file changed, 52 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index
For some reason we are selecting PRIO_HAS_PAGES when we don't have
mm.pages, and vice versa. Perhaps something else is going on here.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff
Otherwise we get -EINVAL, instead of the more useful -E2BIG if the
allocation doesn't fit within the pfn range, like with mappable lmem.
The hugepages selftest, for example, needs this to know if a smaller
size is needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm
for when deciding if we should attempt to evict certain
buffers.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 55 ++-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 8 ++-
drivers/gpu/drm/i915/intel_region_ttm.c | 1
result in an actual move, instead of being turned into a noop.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/dr
If the user doesn't require CPU access for the buffer, then
ALLOC_TOPDOWN should be used, in order to prioritise allocating in the
non-mappable portion of LMEM.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 15 +++
drivers
this behaviour.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 4
drivers/gpu/drm/i915/intel_region_ttm.c | 5 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem
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 in the kernel
v4(Matthew Auld
From: Arunpravin
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
- replace input
and split up of larger blocks for a single page
request.
v2:
- Fix alignment issues(Matthew Auld)
- Remove unnecessary list_empty check(Matthew Auld)
- merged the below patch to see the feature in action
- add top-down alloc support to i915 driver
Signed-off-by: Arunpravin
---
drivers/gpu
With small LMEM-BAR we need to be able to differentiate between the
total size of LMEM, and how much of it is CPU mappable. The end goal is
to be able to utilize the entire range, even if part of is it not CPU
accessible.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm
Starting from DG2 we will have resizable BAR support for device local-memory,
but in some cases the final BAR size might still be smaller than the total
local-memory size. In such cases only part of local-memory will be CPU
accessible, while the remainder is only accessible via the GPU. This
Ensure we drop the reference to the last rq, otherwise we are leaking
the context etc. Also don't zero the previous valid context.
Signed-off-by: Matthew Auld
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
make the test pass on systems with a small LMEM
BAR(256M), where before it was just running out of memory,
Reviewed-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/s
drm_buddy_free()
request and split up of larger blocks for a single page
request.
v2:
- Fix alignment issues(Matthew Auld)
- Remove unnecessary list_empty check(Matthew Auld)
- merged the below patch to see the feature in action
- add top-down alloc support to i915 driver
Signed-off
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 19/01/2022 11:37, 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
On 20/01/2022 16:09, Robert Beckett wrote:
On 20/01/2022 15:58, Matthew Auld wrote:
On 20/01/2022 15:44, Robert Beckett wrote:
On 20/01/2022 14:59, Matthew Auld wrote:
On 20/01/2022 13:15, Robert Beckett wrote:
On 20/01/2022 11:46, Ramalingam C wrote:
On 2022-01-18 at 17:50:34 +
On 20/01/2022 15:44, Robert Beckett wrote:
On 20/01/2022 14:59, Matthew Auld wrote:
On 20/01/2022 13:15, Robert Beckett wrote:
On 20/01/2022 11:46, Ramalingam C wrote:
On 2022-01-18 at 17:50:34 +, Robert Beckett wrote:
From: Matthew Auld
For local-memory objects we need to align
On 20/01/2022 13:15, Robert Beckett wrote:
On 20/01/2022 11:46, Ramalingam C wrote:
On 2022-01-18 at 17:50:34 +, Robert Beckett wrote:
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm
On 19/01/2022 17:47, Thomas Hellström wrote:
In some cases we use leftover kfree() instead of i915_vma_resource_free().
Fix this.
Fixes: Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async unbinding")
Reported-by: Robert Beckett
Cc: Matthew Auld
Signed-off-by: Thomas
t;drm/i915: buddy allocator")
Signed-off-by: Matthew Auld
Cc: Arunpravin
Cc: Christian König
---
drivers/gpu/drm/i915/i915_buddy.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_buddy.c
b/drivers/gpu/drm/i915/i915_buddy.c
index 6e
On 10/01/2022 14:36, Thomas Hellström wrote:
On 1/10/22 14:59, Matthew Auld wrote:
On 07/01/2022 14:23, Thomas Hellström wrote:
Add a selftest to exercise asynchronous migration and -unbining.
Extend the gem_migrate selftest to perform the migrations while
depending on a spinner and a bound
tning vma_resource.
>
> This requires a couple of extra members in struct vma_resource but that's
> a small price to pay for the simplification.
>
> v2:
> - Fix a missing include and declaration (kernel test robot )
>
> Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
continue;
+ if (!vma) {
+ err = igt_fill_check_buffer(obj, true);
+ if (err)
+ continue;
Don't we need some kind of sync in here?
Otherwise,
Reviewed-by: Matthew Auld
to the actual unbinding thread. Regardless
of whether the vm is closed, we need the unbind fence to properly wait
for capture.
- Clear vma_res::vm on unbind and update its documentation.
v4:
- Take cache coloring into account when searching for vma resources
pending unbind. (Matthew Auld)
v5
On 26/12/2021 22:24, 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
("drm/i915: Use ttm mmap handling for ttm bo's.")
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/dr
Don't attempt to fault and re-populate purged objects. By some fluke
this passes the dontneed-after-mmap IGT, but for the wrong reasons.
Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.")
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 3 +++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 6 ++
.../gpu/drm/i915/gem/selftests/i915_gem_mman.c | 18 -
/0x70 [i915]
<4> [749.063409] ? do_user_addr_fault+0x200/0x670
<4> [749.063415] __x64_sys_ioctl+0x6d/0xa0
<4> [749.063419] do_syscall_64+0x3a/0xb0
<4> [749.063423] entry_SYSCALL_64_after_hwframe+0x44/0xae
<4> [749.063428] RIP: 0033:0x7f6e5f100317
Testcase: igt
wed-by: Matthew Auld
+ * @start: Offset into the address space of bind range start.
+ * @node_size: Size of the allocated range manager node.
+ * @vma_size: Bind size.
+ * @page_sizes_gtt: Resulting page sizes from the bind operation.
+ * @bound_flags: Flags indicating binding status.
+ * @allocated: Backend private
and as such it
+ * is illegal to access this fence before scheduled unbind other than
+ * for refcounting.
+ * @lock: The @unbind_fence lock. We're also using it to protect the weak
+ * pointer to the struct i915_vma, @vma during lookup and takedown.
Not sure what the @vma here is referring to?
Otherwise,
Reviewed-by: Matthew Auld
to the actual unbinding thread. Regardless
of whether the vm is closed, we need the unbind fence to properly wait
for capture.
- Clear vma_res::vm on unbind and update its documentation.
v4:
- Take cache coloring into account when searching for vma resources
pending unbind. (Matthew Auld)
v5
("drm/i915: Use ttm mmap handling for ttm bo's.")
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/dr
Ensure we call ttm_bo_unmap_virtual when releasing the pages.
Importantly this should now handle the ttm swapping case, and all other
places that already call into i915_ttm_move_notify().
Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.")
Signed-off-by: Matthew Auld
Don't attempt to fault and re-populate purged objects. By some fluke
this passes the dontneed-after-mmap IGT, but for the wrong reasons.
Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.")
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas
/0x70 [i915]
<4> [749.063409] ? do_user_addr_fault+0x200/0x670
<4> [749.063415] __x64_sys_ioctl+0x6d/0xa0
<4> [749.063419] do_syscall_64+0x3a/0xb0
<4> [749.063423] entry_SYSCALL_64_after_hwframe+0x44/0xae
<4> [749.063428] RIP: 0033:0x7f6e5f100317
Testcase: igt
On 05/01/2022 15:46, Thomas Hellström wrote:
On Wed, 2022-01-05 at 14:58 +, Matthew Auld wrote:
The TTM backend is in theory the only user here(also purge should
only
be called once we have dropped the pages), where it is setup at
object
creation and is only removed once the object
to the actual unbinding thread. Regardless
of whether the vm is closed, we need the unbind fence to properly wait
for capture.
- Clear vma_res::vm on unbind and update its documentation.
v4:
- Take cache coloring into account when searching for vma resources
pending unbind. (Matthew Auld)
v5
Assuming we don't purge the pages, but instead swap them out then we
need to ensure we also unmap the object.
Fixes: 7ae034590cea ("drm/i915/ttm: add tt shmem backend")
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 ++
1 file
Purging can happen during swapping out, or directly invoked with the
madvise ioctl. In such cases this doesn't involve a ttm move, which
skips umapping the object.
Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.")
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
--
Don't attempt to fault and re-populate purged objects. By some fluke
this passes the dontneed-after-mmap IGT, but for the wrong reasons.
Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.")
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/dr
/0x70 [i915]
<4> [749.063409] ? do_user_addr_fault+0x200/0x670
<4> [749.063415] __x64_sys_ioctl+0x6d/0xa0
<4> [749.063419] do_syscall_64+0x3a/0xb0
<4> [749.063423] entry_SYSCALL_64_after_hwframe+0x44/0xae
<4> [749.063428] RIP: 0033:0x7f6e5f100317
Testcase: igt@gem_m
On 26/12/2021 22:24, 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 21/12/2021 16:07, Thomas Hellström wrote:
On Tue, 2021-12-21 at 14:02 +, Matthew Auld wrote:
On 17/12/2021 14:52, Thomas Hellström wrote:
Implement async (non-blocking) unbinding by not syncing the vma
before
calling unbind on the vma_resource.
Add the resulting unbind fence
On 17/12/2021 14:52, Thomas Hellström wrote:
Implement async (non-blocking) unbinding by not syncing the vma before
calling unbind on the vma_resource.
Add the resulting unbind fence to the object's dma_resv from where it is
picked up by the ttm migration code.
Ideally these unbind fences should
, but
at least on non-highmem systems that increase should be very small.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
On 17/12/2021 14:52, Thomas Hellström wrote:
Since it's starting to be used outside the i915 TTM move code, move it
to a separate set of files.
v2:
- Update the documentation.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
() function static. (kernel test robot )
- Update the struct i915_deps kerneldoc.
Fixes: 5652df829b3c ("drm/i915/ttm: Update i915_gem_obj_copy_ttm() to be
asynchronous")
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
t; from __i915_vma_get_pages(). (Matt)
> Changes since v2:
> - Free correct old pages in __i915_vma_get_pages(). (Matt)
> Remove race of clearing vma->pages accidentally from put,
> free it but leave it set, as only get has the lock.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
__i915_vma_pin(vma);
> - else
> + } else {
> list_del(>evict_link);
> + i915_gem_object_unlock(vma->obj);
> + }
> }
>
> /* Unbinding will emit any r
if (i915_vma_is_pinned(vma))
> continue;
>
> + /*
> +* If we already own the lock, trylock fails. In case
> the resv
> +* is shared among
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> This is required for i915_gem_evict_vm, to be able to evict the entire VM,
> including objects that are already locked to the current ww ctx.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> We're working on requiring the obj->resv lock during unbind, fix
> the shrinker to take the objectl ock.
lock
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
On Thu, 16 Dec 2021 at 14:28, Maarten Lankhorst
wrote:
>
> Now that we cannot unbind kill the currently locked object directly
"unbind kill"
> because we're removing short term pinning, we may have to unbind the
> object from gtt manually, using a i915_gem_evict_vm() call.
>
> Signed-off-by:
hese
> tests to fail, because they create a ton of vma's for the same object.
>
> Unbind manually to prevent spurious -ENOSPC in those mock tests.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
-EDEADLK handling.
>
> Signed-off-by: Maarten Lankhorst
Deja-vu,
Reviewed-by: Matthew Auld
On Thu, 16 Dec 2021 at 14:28, 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
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).
v2(Ram)
- Document the ppGTT layout and add a better description for the
different windows.
Signed-off-by: Matthew Auld
Cc: Thomas
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 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
Reviewed
letter
v3:
- Add some r-b tags
- Drop the GTT_MAPPABLE approach. We can instead simply pass along the
required size/alignment using alloc_pt().
v4:
- Drop already merged patches, and add some r-b tags
- Add some better docs to patch 3
Matthew Auld (3):
drm/i915/gtt: allow overriding
On 15/12/2021 20:46, Arunpravin wrote:
On 14/12/21 12:29 am, Matthew Auld wrote:
On 09/12/2021 15:47, Paneer Selvam, Arunpravin wrote:
[AMD Official Use Only]
Hi Matthew,
Ping on this?
No new comments from me :) I guess just a question of what we should do
with the selftests
On 15/12/2021 15:55, Tvrtko Ursulin wrote:
On 15/12/2021 11:07, Matthew Auld wrote:
Add some proper flags for the different modes, and shorten the name to
something more snappy.
Looks good to me - but since it touches TTM I leave for Thomas to approve.
Regards,
Tvrtko
P.S. I hope writing
Ditch the writeback hook and drop i915_gem_object_writeback(). We
already support the shrinker_release_pages hook which can just call
shmem_writeback directly.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Matthew Auld
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_object.h
Add some proper flags for the different modes, and shorten the name to
something more snappy.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Matthew Auld
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 23 ---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 8 +++
drivers
Ditch the writeback hook and drop i915_gem_object_writeback(). We
already support the shrinker_release_pages hook which can just call
shmem_writeback directly.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.h| 1 -
.../gpu/drm/i915
On Mon, 13 Dec 2021 at 13:03, Matthew Auld wrote:
>
> On 10/12/2021 19:50, Robert Beckett wrote:
> > ttm->num_pages is uint32_t which was causing very large buffers to
> > only populate a truncated size.
> >
> > This fixes gem_create@create-clear igt test on la
On 14/12/2021 10:56, Ramalingam C wrote:
On 2021-12-06 at 13:31:39 +, Matthew Auld wrote:
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
total device memory by Flat CCS memory size.
Cc: Matthew Auld
Signed-off-by: Abdiel Janulgue
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_gt.c | 19 ++
drivers/gpu/drm/i915/gt/intel_gt.h | 1 +
drivers/gpu/drm/i915/gt/intel_region_lmem.c
with a flat indexed region of
device memory for storing compression states.
Cc: Joonas Lahtinen
Cc: Matthew Auld
Signed-off-by: CQ Tang
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915
be removed
- enable ttm range allocation (fpfn / lpfn) support in i915 driver
- apply enhanced drm_buddy_alloc() function to i915 driver
v3(Matthew Auld):
- Fix alignment issues and remove unnecessary list_empty check
- add more validation checks for input arguments
- make
On 01/12/2021 16:39, 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
ff-by: Robert Beckett
Nice catch,
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 218a9b3037c7..923cc7
[ 2507.914857] i915_drop_caches_set+0x227/0x2c0 [i915]
Reported-by: Thomas Hellström
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index bafb902269de..359d8f
.
Fixes: ff20afc4cee7 ("drm/i915: Update error capture code to avoid using the current
vma state")
Cc: Ramalingam C
Cc: Matthew Auld
Cc: Maarten Lankhorst
Cc: John Harrison
Cc: Matthew Brost
Reported-by: John Harrison
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
using the current
vma state")
Cc: Ramalingam C
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
r batch buffer, instead be cautious when
> calling i915_gem_object_ggtt_pin_ww, and re-use the current batch vma
> if it's inside ggtt and map-and-fenceable.
> - Remove impossible condition check from eb_reserve. (Matt)
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
On Thu, 9 Dec 2021 at 13:25, Maarten Lankhorst
wrote:
>
> On 09-12-2021 14:05, Matthew Auld wrote:
> > On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
> > wrote:
> >> We want to remove more members of i915_vma, which requires the locking to
> >> be
&
On Mon, 29 Nov 2021 at 13:58, Maarten Lankhorst
wrote:
>
> We want to remove more members of i915_vma, which requires the locking to be
> held more often.
>
> Start requiring gem object lock for i915_vma_unbind, as it's one of the
> callers that may unpin pages.
>
> Some special care is needed
he
already locked object and then also any vma sharing the same dma-resv
object here? Or at least trying to nuke the entire vm, just for the
mappable portion seems maybe overkill? Or perhaps we never expect to
hit this in the real world?
Reviewed-by: Matthew Auld
> +
On Thu, 9 Dec 2021 at 13:46, Maarten Lankhorst
wrote:
>
> On 09-12-2021 14:40, Matthew Auld wrote:
> > On Thu, 9 Dec 2021 at 13:25, Maarten Lankhorst
> > wrote:
> >> On 09-12-2021 14:05, Matthew Auld wrote:
> >>> On Mon, 29 Nov 2021 at 13:58, Maarten
d-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
On Wed, 8 Dec 2021 at 14:16, Ramalingam C wrote:
>
> From: Matthew Auld
>
> LMEM should be allocated at 64K granularity, since 4K page support will
> eventually be dropped for LMEM when using the PPGTT.
s/will eventually be dropped/has been dropped/ as per Thomas' suggestion.
On Wed, 8 Dec 2021 at 12:43, Thomas Hellström (Intel)
wrote:
>
> Hi,
>
> On 12/7/21 17:51, Ramalingam C wrote:
> > From: Stuart Summers
> >
> > Add a new platform flag, has_64k_pages, for platforms supporting
> > base page sizes of 64k.
> >
> > Signed-off-by: Stuart Summers
> > Signed-off-by:
501 - 600 of 1542 matches
Mail list logo
