From: Christian König
That should not be necessary any more when drivers should at least be
able to handle the move without a resource.
Signed-off-by: Christian König
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 ---
1 file changed, 7
From: Christian König
That should not be necessary any more when drivers should at least be
able to handle a move without a resource.
Signed-off-by: Christian König
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 15 ++-
1 file
: kernel test robot
Signed-off-by: Matthew Auld
Cc: Christian König
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_ge
ial ttm_tt would be created in
ttm_bo_validate() with the clear parameter always set to true.
Signed-off-by: Matthew Auld
Cc: Christian König
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/
On Mon, 30 Jan 2023 at 11:00, Andrzej Hajda wrote:
>
> On 30.01.2023 11:12, Matthew Auld wrote:
> > In the near future TTM will have NULL bo->resource when the object is
> > initially created, plus after calling into pipeline-gutting. Try to
> > handle the remaining
From: Christian König
That should not be necessary any more when drivers should at least be
able to handle the move without a resource.
Signed-off-by: Christian König
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 ---
1 file changed, 7
ial ttm_tt would be created in
ttm_bo_validate() with the clear parameter always set to true.
Signed-off-by: Matthew Auld
Cc: Christian König
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/
-by: Christian König
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4
drivers/gpu/drm/nouveau/nouveau_bo.c| 3 ---
drivers/gpu/drm/radeon/radeon_ttm.c | 4
drivers/gpu/drm/ttm/ttm_bo.c| 20
From: Christian König
That should not be necessary any more when drivers should at least be
able to handle a move without a resource.
Signed-off-by: Christian König
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 15 ++-
1 file
: kernel test robot
Signed-off-by: Matthew Auld
Cc: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 7420276827a5..4758f2
5: audit bo->resource usage v3")
Signed-off-by: Matthew Auld
Cc: Christian König
Cc: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 12 +---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 7 ++-
drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 7 +--
> which changed significantly how this works, perhaps there is something
> still somewhat easily retrievable from your memory lanes to help with this?
Sorry for the delay. Fix looks good to me,
Reviewed-by: Matthew Auld
Looking at the git history, the fixes tag I think needs to be:
Fixes: 9e
On Wed, 25 Jan 2023 at 16:15, Christian König wrote:
>
> Am 25.01.23 um 17:13 schrieb Matthew Auld:
> > On Wed, 25 Jan 2023 at 15:50, Christian König
> > wrote:
> >> This reverts commit 00984ad39599bb2a1e6ec5d4e9c75a749f7f45c9.
> >>
> >> It seems to
On Wed, 25 Jan 2023 at 15:50, Christian König
wrote:
>
> This reverts commit 00984ad39599bb2a1e6ec5d4e9c75a749f7f45c9.
>
> It seems to still breka i915.
We also need to revert the third patch:
b49323aa35d5 drm/ttm: prevent moving of pinned BOs
It introduces the side effect of no longer calling
On Wed, 25 Jan 2023 at 14:20, Christian König
wrote:
>
> Am 25.01.23 um 13:53 schrieb Matthew Auld:
> > On Wed, 25 Jan 2023 at 11:35, Christian König
> > wrote:
> >> Am 25.01.23 um 11:21 schrieb Matthew Auld:
> >>> On Wed, 25 Jan 2023 at 10:07, Christian Kö
On Wed, 25 Jan 2023 at 11:35, Christian König
wrote:
>
> Am 25.01.23 um 11:21 schrieb Matthew Auld:
> > On Wed, 25 Jan 2023 at 10:07, Christian König
> > wrote:
> >> Am 25.01.23 um 10:56 schrieb Matthew Auld:
> >>> On Tue, 24 Jan 2023 at 17:15, Matthew A
On Wed, 25 Jan 2023 at 10:07, Christian König
wrote:
>
>
>
> Am 25.01.23 um 10:56 schrieb Matthew Auld:
> > On Tue, 24 Jan 2023 at 17:15, Matthew Auld
> > wrote:
> >> On Tue, 24 Jan 2023 at 13:48, Matthew Auld
> >> wrote:
> >>> On T
On Tue, 24 Jan 2023 at 17:15, Matthew Auld
wrote:
>
> On Tue, 24 Jan 2023 at 13:48, Matthew Auld
> wrote:
> >
> > On Tue, 24 Jan 2023 at 12:57, Christian König
> > wrote:
> > >
> > > From: Christian König
> > >
> > > Make sure
On Tue, 24 Jan 2023 at 13:48, Matthew Auld
wrote:
>
> On Tue, 24 Jan 2023 at 12:57, Christian König
> wrote:
> >
> > From: Christian König
> >
> > Make sure we can at least move and alloc TT objects without backing store.
> >
> > v2: clear the
n_busy = domain;
domain |= busy;
....
if (domain & VRAM) {
if (non_busy & VRAM)
flags = 0
else
flags = FLAG_BUSY
}
Otherwise if VRAM is set in both "busy" and "domain", it will only try
VRAM when all non-busy first fails, which looks like a change in
behaviour?
The rest of the patch looks good to me, so with the above fixed or explained,
Reviewed-by: Matthew Auld
gt; any more after removing the extra checks in vmwgfx.
>
> Signed-off-by: Christian König
Idea seems reasonable to me,
Reviewed-by: Matthew Auld
On Tue, 24 Jan 2023 at 12:57, Christian König
wrote:
>
> That should not be necessary any more when drivers should at least be
> able to handle a move without a resource.
>
> Signed-off-by: Christian König
Reviewed-by: Matthew Auld
On Tue, 24 Jan 2023 at 12:57, Christian König
wrote:
>
> That should not be necessary any more when drivers should at least be
> able to handle the move without a resource.
>
> Signed-off-by: Christian König
Reviewed-by: Matthew Auld
t; Signed-off-by: Christian König
Reviewed-by: Matthew Auld
On Tue, 24 Jan 2023 at 09:51, Christian König
wrote:
>
> Am 11.01.23 um 14:17 schrieb Matthew Auld:
> > On Wed, 11 Jan 2023 at 11:43, Christian König
> > wrote:
> >> We have checks for this in the individual drivers move callback, but
> >> it's
offset = 0;
+ if (!length)
+ break;
+ }
+ WARN_ON_ONCE(length);
+
+ return nents;
+}
+
+static noinline struct sg_table *
Not sure why this noinline is needed here?
Reviewed-by: Matthew Auld
+intel_persistent_partial_pages(const
On 18/01/2023 07:16, Niranjana Vishwanathapura wrote:
Support dump capture of persistent mappings upon user request.
Capture of a mapping is requested with the VM_BIND ioctl and
processed during the GPU error handling. They are synchronously
unbound during eviction so that no additional vma
On 13/01/2023 12:02, Das, Nirmoy wrote:
Thanks Matt, I missed the Fixes tag so resent it with fixes and Cc to
stable.
I don't think kernel selftests are really stable material. AFAIK it's
not something normal users care about.
On 1/13/2023 12:51 PM, Matthew Auld wrote:
On 13/01/2023 11
On 13/01/2023 11:49, Nirmoy Das wrote:
From: Chris Wilson
Make sure that upon error after we have acquired the wakeref we do
release it again.
Signed-off-by: Chris Wilson
Signed-off-by: Nirmoy Das
Reviewed-by: Matthew Auld
On Wed, 11 Jan 2023 at 14:43, Christian König
wrote:
>
> Am 11.01.23 um 14:03 schrieb Matthew Auld:
> > On Wed, 11 Jan 2023 at 11:43, Christian König
> > wrote:
> >> Instead of a list of separate busy placement add flags which indicate
> >> that a placement sh
On Wed, 11 Jan 2023 at 11:43, Christian König
wrote:
>
> We have checks for this in the individual drivers move callback, but
> it's probably better to generally forbit that on a higher level.
>
> Also stops exporting ttm_resource_compat() since that's not necessary
> any more after removing the
On Wed, 11 Jan 2023 at 11:43, Christian König
wrote:
>
> Instead of a list of separate busy placement add flags which indicate
> that a placement should only be used when there is room or if we need to
> evict.
>
> Signed-off-by: Christian König
> ---
>
On 10/01/2023 12:02, Matthew Auld wrote:
On 07/01/2023 15:15, Arunpravin Paneer Selvam wrote:
As we are observing low numbers in viewperf graphics benchmark, we
are strictly not allowing the top down flag enabled allocations
to steal the memory space from cpu visible region.
The approach
On 07/01/2023 15:15, Arunpravin Paneer Selvam wrote:
As we are observing low numbers in viewperf graphics benchmark, we
are strictly not allowing the top down flag enabled allocations
to steal the memory space from cpu visible region.
The approach is, we are sorting each order list entries in
On 13/12/2022 12:00, Nirmoy Das wrote:
Use MI_USE_GGTT instead of hardcoded value.
Signed-off-by: Nirmoy Das
Reviewed-by: Matthew Auld
On 12/12/2022 23:15, Niranjana Vishwanathapura wrote:
Support dump capture of persistent mappings upon user request.
Capture of a mapping is requested with the VM_BIND ioctl and
processed during the GPU error handling, thus not adding any
additional latency to the submission path.
A list of
On 29/11/2022 07:26, Niranjana Vishwanathapura wrote:
Properly build the sg table for persistent mapping which can
be partial map of the underlying object. Ensure the sg pages
are properly set for page backed regions. The dump capture
support requires this for page backed regions.
On 05/12/2022 19:58, Christian König wrote:
Am 30.11.22 um 15:06 schrieb Daniel Vetter:
On Wed, 30 Nov 2022 at 14:03, Tvrtko Ursulin
wrote:
On 29/11/2022 18:05, Matthew Auld wrote:
On Fri, 25 Nov 2022 at 11:14, Tvrtko Ursulin
wrote:
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM
On 01/12/2022 18:43, Niranjana Vishwanathapura wrote:
On Thu, Dec 01, 2022 at 07:27:31AM -0800, Niranjana Vishwanathapura wrote:
On Thu, Dec 01, 2022 at 10:49:15AM +, Matthew Auld wrote:
On 29/11/2022 07:26, Niranjana Vishwanathapura wrote:
Support dump capture of persistent mappings upon
On 29/11/2022 07:26, Niranjana Vishwanathapura wrote:
Support dump capture of persistent mappings upon user request.
Signed-off-by: Brian Welty
Signed-off-by: Niranjana Vishwanathapura
---
.../drm/i915/gem/i915_gem_vm_bind_object.c| 11 +++
drivers/gpu/drm/i915/gt/intel_gtt.c
On 29/11/2022 23:26, Niranjana Vishwanathapura wrote:
On Wed, Nov 23, 2022 at 11:42:58AM +, Matthew Auld wrote:
On 16/11/2022 00:37, Niranjana Vishwanathapura wrote:
On Tue, Nov 15, 2022 at 03:15:03PM -0800, Niranjana Vishwanathapura
wrote:
On Tue, Nov 15, 2022 at 08:33:47AM -0800
On Fri, 25 Nov 2022 at 11:14, Tvrtko Ursulin
wrote:
>
>
> + Matt
>
> On 25/11/2022 10:21, Christian König wrote:
> > TTM is just wrapping core DMA functionality here, remove the mid-layer.
> > No functional change.
> >
> > Signed-off-by: Christian König
> > ---
> >
On Thu, 24 Nov 2022 at 10:03, Christian König
wrote:
>
> Those functions never worked correctly since it is still perfectly
> possible that a buffer object is released and the background worker
> restarted even after calling them.
>
> Signed-off-by: Christian König
I know you usually do, but
On 16/11/2022 00:37, Niranjana Vishwanathapura wrote:
On Tue, Nov 15, 2022 at 03:15:03PM -0800, Niranjana Vishwanathapura wrote:
On Tue, Nov 15, 2022 at 08:33:47AM -0800, Niranjana Vishwanathapura
wrote:
On Tue, Nov 15, 2022 at 04:20:54PM +, Matthew Auld wrote:
On 15/11/2022 16:15
On Thu, 13 Oct 2022 at 09:40, Nirmoy Das wrote:
>
> Add a function for ratelimitted debug print.
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Nirmoy Das
Reviewed-by: Matthew
On 13/10/2022 09:40, Nirmoy Das wrote:
Test like i915_gem_mman_live_selftests/igt_mmap_migrate can cause
dmesg spamming. Use ratelimit api to reduce log rate.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/7038
Cc: Matthew Auld
Signed-off-by: Nirmoy Das
Reviewed-by: Matthew
On 15/11/2022 16:15, Niranjana Vishwanathapura wrote:
On Tue, Nov 15, 2022 at 11:05:21AM +, Matthew Auld wrote:
On 13/11/2022 07:57, Niranjana Vishwanathapura wrote:
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind
and user need not try to sequence any
operation with the unbind completion.
v2: use i915_vma_destroy_async in vm_unbind ioctl
Signed-off-by: Niranjana Vishwanathapura
This only does it for non-partial vma, right? Or was that changed somewhere?
Reviewed-by: Matthew Auld
---
.../drm/i915/gem
On 10/11/2022 14:47, Tvrtko Ursulin wrote:
On 10/11/2022 05:49, Niranjana Vishwanathapura wrote:
On Wed, Nov 09, 2022 at 04:16:25PM -0800, Zanoni, Paulo R wrote:
On Mon, 2022-11-07 at 00:51 -0800, Niranjana Vishwanathapura wrote:
DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind
On 10/11/2022 05:31, Mani Milani wrote:
At present, the gpu thread crashes at times when grab_vma() attempts to
acquire a gem object lock when in a deadlock state.
Problems:
I identified the following 4 issues in the current code:
1. Since grab_vma() calls i915_gem_object_trylock(), which
On Mon, 7 Nov 2022 at 08:53, Niranjana Vishwanathapura
wrote:
>
> Asynchronously unbind the vma upon vm_unbind call.
> Fall back to synchronous unbind if backend doesn't support
> async unbind or if async unbind fails.
>
> No need for vm_unbind out fence support as i915 will internally
> handle
On 25/10/2022 07:59, Niranjana Vishwanathapura wrote:
Update i915 documentation to include VM_BIND changes
and render all VM_BIND related documentation.
Signed-off-by: Niranjana Vishwanathapura
Thanks for adding this,
Reviewed-by: Matthew Auld
va->fence.flags & I915_TIMELINE_FENCE_WAIT)
+ ret = -EINVAL;
I guess also:
if (flags & __I915_TIMELINE_FENCE_UNKNOWN_FLAGS)
Reviewed-by: Matthew Auld
+
obj = i915_gem_object_lookup(file, va->handle);
if (!obj)
return -ENOENT;
@@ -237
ana Vishwanathapura
Signed-off-by: Andi Shyti
Reviewed-by: Matthew Auld
On 25/10/2022 07:59, Niranjana Vishwanathapura wrote:
Only support vm_bind mode with non-recoverable contexts.
With new vm_bind mode with eb3 submission path, we need not
support older recoverable contexts.
Signed-off-by: Niranjana Vishwanathapura
Reviewed-by: Matthew Auld
On Tue, 25 Oct 2022 at 16:51, Somalapuram Amaranath
wrote:
>
> Change ttm_resource structure from num_pages to size_t size in bytes.
> v1 -> v2: change PFN_UP(dst_mem->size) to ttm->num_pages
> v1 -> v2: change bo->resource->size to bo->base.size at some places
> v1 -> v2: remove the local
On 24/10/2022 15:45, Nirmoy Das wrote:
vm_fault_ttm() should not expect ttm ghost obj so remove that check.
Suggested-by: Matthew Auld
Signed-off-by: Nirmoy Das
Reviewed-by: Matthew Auld
On 20/10/2022 17:51, Niranjana Vishwanathapura wrote:
On Thu, Oct 20, 2022 at 10:16:06AM +0100, Matthew Auld wrote:
On 19/10/2022 19:28, Niranjana Vishwanathapura wrote:
On Wed, Oct 19, 2022 at 05:07:31PM +0100, Matthew Auld wrote:
On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:
Ensure
On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:
Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.
v2: Ensure requests wait for bindings to complete.
v3: Remove short term pinning with PIN_VALIDATE flag.
Individualize fences before adding to
to dma_resv obj.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
Reviewed-by: Matthew Auld
On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:
For persistent (vm_bind) vmas of userptr BOs, handle the user
page pinning by using the i915_gem_object_userptr_submit_init()
/done() functions
v2: Do not double add vma to vm->userptr_invalidated_list
Signed-off-by: Niranjana
On 19/10/2022 19:28, Niranjana Vishwanathapura wrote:
On Wed, Oct 19, 2022 at 05:07:31PM +0100, Matthew Auld wrote:
On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:
Ensure i915_vma_verify_bind_complete() handles case where bind
is not initiated. Also make it non static, add documentation
ete() - Check for the bind completion of the vma
+ * @vma: vma to check for bind completion
Maybe mention the locking since this is now more than just DEBUG_GEM
stuff. I assume we need the object lock or otherwise some guarantee that
the vma is pinned?
Reviewed-by: Matthew Auld
+ *
+ * Retu
;
/* do not reserve memory to prevent deadlocks */
#define __EXEC_OBJECT_NO_RESERVE BIT(31)
+static inline int
+i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)
Some kernel doc might be good?
Reviewed-by: Matthew Auld
+{
+ return __i915_request_await_exclusive(rq
On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects
On 19/10/2022 03:43, Niranjana Vishwanathapura wrote:
On Tue, Oct 18, 2022 at 04:28:07PM +0100, Matthew Auld wrote:
On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:
Add support for handling out fence for vm_bind call.
v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
of vm_b
On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:
Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.
v2: Ensure requests wait for bindings to complete.
v3: Remove short term pinning with PIN_VALIDATE flag.
Individualize fences before adding to
xt specified by @ctx_id.
+*/
+ __u32 engine_idx;
+
+ /**
+* @batch_address: Batch gpu virtual address/es.
+*
+* For normal submission, it is the gpu virtual address of the batch
+* buffer. For parallel submission, it is a pointer to an array of
+* batch b
check with i915_gem_vm_is_vm_bind_mode()
Reviewed-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 25 +++--
drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 +--
drivers/gpu/drm/i915/gt/intel
On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:
Add support for handling out fence for vm_bind call.
v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
of vm_bind call.
v3: Remove vm_unbind out fence uapi which is not supported yet.
Signed-off-by: Niranjana Vishwanathapura
On 14/10/2022 07:48, Niranjana Vishwanathapura wrote:
On Sun, Oct 09, 2022 at 11:58:18PM -0700, Niranjana Vishwanathapura wrote:
Add support for handling out fence for vm_bind call.
v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
of vm_bind call.
Signed-off-by: Niranjana
On 14/10/2022 17:51, Jordan Justen wrote:
On 2022-10-14 03:58:12, Matthew Auld wrote:
On 14/10/2022 08:20, Jordan Justen wrote:
Acked-by: Jordan Justen
Thanks. Can I take that as ack for merging the series from Mesa POV? I
think Lionel was going to test this, but I think keeps getting
l_wakeref_t wakeref = 0;
vm_fault_t ret;
int idx;
- obj = i915_ttm_to_gem(bo);
- if (!obj)
+ if (i915_ttm_is_ghost_object(bo))
return VM_FAULT_SIGBUS;
I think this one can be dropped, maybe in a separate patch?
Otherwise looks good to me,
Reviewe
04:49:15, Matthew Auld wrote:
On some platforms we potentially have different alignment restrictions
depending on the memory type. We also now have different alignment
restrictions for the same region across different kernel versions.
Extend the region query to return the minimum required GTT
On 10/10/2022 07:58, Niranjana Vishwanathapura wrote:
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects
On 11/10/2022 17:27, Matthew Auld wrote:
On 10/10/2022 07:58, Niranjana Vishwanathapura wrote:
Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage as it
requires a single dma_resv object update for all private
ing with PIN_VALIDATE flag.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Andi Shyti
Reviewed-by: Matthew Auld
On 10/10/2022 07:58, Niranjana Vishwanathapura wrote:
Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage as it
requires a single dma_resv object update for all private BOs vs list of
dma_resv objects update for
On 11/10/2022 01:55, Niranjana Vishwanathapura wrote:
On Mon, Oct 10, 2022 at 05:43:47PM -0700, Niranjana Vishwanathapura wrote:
On Mon, Oct 10, 2022 at 06:15:02PM +0100, Matthew Auld wrote:
On 10/10/2022 17:11, Niranjana Vishwanathapura wrote:
On Mon, Oct 10, 2022 at 02:30:49PM +0100
On 10/10/2022 17:11, Niranjana Vishwanathapura wrote:
On Mon, Oct 10, 2022 at 02:30:49PM +0100, Matthew Auld wrote:
On 10/10/2022 07:58, Niranjana Vishwanathapura wrote:
Support eviction by maintaining a list of evicted persistent vmas
for rebinding during next submission. Ensure the list do
__i915_vma_unbind_async() case.
Acked-by: Matthew Auld
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
.../drm/i915/gem/i915_gem_vm_bind_object.c| 6
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 ++
drivers/gpu/drm/i915/gt/intel_gtt.h | 4
ktop.org/patch/msgid/20220912121957.31310-1-thomas.hellst...@linux.intel.com
Cc: Matthew Auld
Cc: intel-...@lists.freedesktop.org
Cc: # v5.18+
Reported-and-tested-by: Kevin Boulain
Tested-by: David de Sousa
Reviewed-by: Matthew Auld
@gem_create@create-ext-placement-alignment
Testcase: igt@i915_query@query-regions-sanity-check
Suggested-by: Lionel Landwerlin
Signed-off-by: Matthew Auld
Cc: Michal Mrozek
Cc: Thomas Hellström
Cc: Stuart Summers
Cc: Jordan Justen
Cc: Yang A Shi
Cc: Nirmoy Das
Cc: Niranjana Vishwanathapura
restrictions, as documented in:
commit caa574ffc4aaf4f29b890223878c63e2e7772f62
Author: Matthew Auld
Date: Sat Feb 19 00:17:49 2022 +0530
drm/i915/uapi: document behaviour for DG2 64K support
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing
On 03/10/2022 07:12, Niranjana Vishwanathapura wrote:
Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.
v2: Ensure requests wait for bindings to complete.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
On 02/10/2022 07:28, Niranjana Vishwanathapura wrote:
On Fri, Sep 30, 2022 at 10:47:48AM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.
Signed-off-by: Niranjana
Touching bo->resource looks like it should require first locking the
object, since this state is dynamic and could potentially change from
under us. It looks we can just use obj->base.size here, which avoids any
issues with locking, since this is immutable state.
Signed-off-by: Matthew Au
Touching bo->resource looks like it should require first locking the
object, since this state is dynamic and could potentially change from
under us.
Signed-off-by: Matthew Auld
Cc: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deleti
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Update the execbuf path to use common execbuf functions to
reduce code duplication with the newer execbuf3 path.
Signed-off-by: Niranjana Vishwanathapura
Acked-by: Matthew Auld
specified fence
+ * @signal: signal the specified fence
+ *
+ * Add the fence specified by drm_syncobj @handle at specified @point in the
+ * timeline to the Execbuffer fence array @f. If @wait is specified, it is an
+ * input fence and if @signal is specified it is an output fence.
+ *
+ * Returns 0 upon success, -ve error upon failure.
Also can return 1, which also means success. Also maybe clarify that
zero here is special.
Acked-by: Matthew Auld
/** @extensions: Zero-terminated chain of extensions. */
__u64 extensions;
- /** @flags: reserved for future usage, currently MBZ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1u << 0)
Some kernel-doc for that would be good, even if it's kind of obvious.
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Handle persistent (VM_BIND) mappings during the request submission
in the execbuf3 path.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
.../gpu/drm/i915/gem/i915_gem_execbuffer3.c | 188 +-
1
On 29/09/2022 17:38, Niranjana Vishwanathapura wrote:
On Thu, Sep 29, 2022 at 11:49:30AM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode
Acked-by: Matthew Auld
---
.../drm/i915/gem/i915_gem_vm_bind_object.c| 6 ++
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 ++
drivers/gpu/drm/i915/gt/intel_gtt.h | 4
drivers/gpu/drm/i915/i915_vma.c | 19 +++
drivers/gpu/drm
. ie., multiple
mappings (at different VA) point to the same gtt_view of object.
Skip vma_lookup for persistent vmas to support aliasing.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
Acked-by: Matthew Auld
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects
On 29/09/2022 10:03, Matthew Auld wrote:
On 29/09/2022 06:24, Niranjana Vishwanathapura wrote:
On Wed, Sep 28, 2022 at 06:52:21PM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.
Signed-off-by:
On 29/09/2022 06:24, Niranjana Vishwanathapura wrote:
On Wed, Sep 28, 2022 at 06:52:21PM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage as it
requires a single dma_resv object update for all private BOs vs list of
dma_resv objects update for
101 - 200 of 1542 matches
Mail list logo
