From: Thomas Hellström
The hwsp_gtt object is used for sub-allocation and could therefore
be shared by many contexts causing unnecessary contention during
concurrent context pinning.
However since we're currently locking it only for pinning, it remains
resident until we unpin it, and therefore
ation: update api and add some helpers")
Cc: # v3.17+
Reported-by: Niranjana Vishwanathapura
Signed-off-by: Maarten Lankhorst
---
drivers/dma-buf/dma-resv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Thomas Hellström
___
++-
drivers/gpu/drm/i915/i915_vma.c | 5
5 files changed, 56 insertions(+), 3 deletions(-)
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
---
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
Quick fix, just use the unlocked version.
Signed-off-by: Maarten Lankhorst
---
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
Instead of multiple lockings, lock the object once,
and perform the ww dance around attach_phys and pin_pages.
Signed-off-by: Maarten Lankhorst
---
Not familiar with the code, but looks good from what I can tell.
Reviewed-by: Thomas Hellström
manually. It should be similarly fast.
This has the added benefit of being able to catch all memory allocation
errors before the point of no return, and return -ENOMEM safely to the
execbuf submitter.
Signed-off-by: Maarten Lankhorst
Acked-by: Thomas Hellström
+---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
13 files changed, 53 insertions(+), 89 deletions(-)
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
Straightforward conversion, just convert a bunch of calls to
unlocked versions.
Signed-off-by: Maarten Lankhorst
---
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx
.
Signed-off-by: Maarten Lankhorst
For this and the patches in the series that start with
drm/i915/selftests:
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo
On 11/3/20 2:27 PM, Thomas Hellström wrote:
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
We need to lock the global gtt dma_resv, use i915_vm_lock_objects
to handle this correctly. Add ww handling for this where required.
Add the object lock around unpin/put pages, and use the unlocked
, but we should probably fix that up afterwards.
Reviewed-by: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 24 ++-
drivers/gpu/drm/i915/i915_active.c| 20
drivers/gpu/drm/i915/i915_vma.c | 8 ---
drivers/gpu
ten Lankhorst
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
x held.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
there is such an ack,
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
/i915/gt/intel_lrc.c | 107 +-
2 files changed, 62 insertions(+), 58 deletions(-)
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel
On 10/16/20 12:43 PM, Maarten Lankhorst wrote:
Doesn't need the full ww lock, only checking if pages are bound.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https
On 10/16/20 12:43 PM, Maarten Lankhorst wrote:
i915_vma_pin may fail with -EDEADLK when we start locking page tables,
so ensure we handle this correctly.
Signed-off-by: Maarten Lankhorst
When previous review comments addressed,
Reviewed-by: Thomas Hellström
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
Take a simple lock so we hold ww around (un)pin_pages as needed.
Signed-off-by: Maarten Lankhorst
---
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
This should be done as part of the ww loop, in order to remove a
i915_vma_pin that needs ww held.
Now only i915_ggtt_pin() callers remaining.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
insertions(+), 10 deletions(-)
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
Pin in the caller, not in the work itself. This should also
work better for dma-fence annotations.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 15 +++
1 file changed, 7 insertions(+), 8
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
We previously complained when ww == NULL.
This function is now only used in selftests to pin an object,
and ww locking is now fixed.
Signed-off-by: Maarten Lankhorst
---
Reviewed-by: Thomas Hellström
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
We need to lock the object to move it to the correct domain,
add the missing lock.
Signed-off-by: Maarten Lankhorst
---
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx
/selftest_workarounds.c| 76 ---
3 files changed, 64 insertions(+), 27 deletions(-)
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
We need to take the obj lock to pin pages, so wait until the callers
have done so, before making the object unshrinkable.
Signed-off-by: Maarten Lankhorst
---
Reviewed-by: Thomas Hellström
___
Intel
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
From: Thomas Hellström
Stolen objects need to lock, and we may call put_pages when
refcount drops to 0, ensure all calls are handled correctly.
Idea-from: Thomas Hellström
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem
On 11/2/20 9:48 AM, Maarten Lankhorst wrote:
Op 30-10-2020 om 16:08 schreef Thomas Hellström:
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
Pin in the caller, not in the work itself. This should also
work better for dma-fence annotations.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu
ict with fence annotations,
because of memory allocations done when pagefaulting inside copy_*_user.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
If needed, in the future we might want to look at a way to keep the
object lock around the short-term pinning. At least for the
non-p
On 11/2/20 10:22 AM, Thomas Hellström wrote:
On 11/2/20 9:48 AM, Maarten Lankhorst wrote:
Op 30-10-2020 om 16:08 schreef Thomas Hellström:
On 10/16/20 12:44 PM, Maarten Lankhorst wrote:
Pin in the caller, not in the work itself. This should also
work better for dma-fence annotations
On 1/18/21 2:22 PM, Thomas Hellström wrote:
On 1/18/21 1:01 PM, Maarten Lankhorst wrote:
Op 18-01-2021 om 12:11 schreef Thomas Hellström:
On 1/5/21 4:35 PM, Maarten Lankhorst wrote:
We get a lockdep splat when the reset mutex is held, because it can be
taken from fence_wait. This conflicts
On 1/18/21 3:46 PM, Maarten Lankhorst wrote:
Op 18-01-2021 om 14:28 schreef Thomas Hellström:
On 1/18/21 2:22 PM, Thomas Hellström wrote:
On 1/18/21 1:01 PM, Maarten Lankhorst wrote:
Op 18-01-2021 om 12:11 schreef Thomas Hellström:
On 1/5/21 4:35 PM, Maarten Lankhorst wrote:
We get
On 1/18/21 1:01 PM, Maarten Lankhorst wrote:
Op 18-01-2021 om 12:11 schreef Thomas Hellström:
On 1/5/21 4:35 PM, Maarten Lankhorst wrote:
We get a lockdep splat when the reset mutex is held, because it can be
taken from fence_wait. This conflicts with the mmu notifier we have,
because we
is not available, which means for new kernels
you will need CONFIG_I915_USERPTR.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel
On 1/5/21 4:35 PM, Maarten Lankhorst wrote:
We get a lockdep splat when the reset mutex is held, because it can be
taken from fence_wait. This conflicts with the mmu notifier we have,
because we recurse between reset mutex and mmap lock -> mmu notifier.
Remove this recursion by calling
, reported by kbuild.
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel
On 1/5/21 4:35 PM, Maarten Lankhorst wrote:
Now that unsynchronized mappings are removed, the only time userptr
works is when the MMU notifier is enabled. Put all of the userptr
code behind a mmu notifier ifdef.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
Lankhorst
Reviewed-by: Thomas Hellström
---
LGTM.
Thomas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
r.
>
> Signed-off-by: Chris Wilson
> Cc: Thomas Hellström
LGTM. Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, 2021-02-02 at 15:43 +, Chris Wilson wrote:
> After calling lock_set_subclass() the lock _must_ be used, or else
> lockdep's internal nr_used_locks becomes unbalanced. Extract the
> little
> utility function to i915_utils.c
>
> Signed-off-by: Chris Wilson
>
the last patch (migration) It needs selftests and some additional work.
- Unconditionally add VM_IO at mmap time.
Thomas Hellström (4):
drm/i915: Update object placement flags to be mutable
drm/i915/ttm: Adjust gem flags and caching settings after a move
drm/i915/ttm: Calculate the object placement
. The flags
will change during migration under the object lock.
Signed-off-by: Thomas Hellström
v2:
- Unconditionally set VM_IO on our VMAs in line with the rest core gem
and TTM. Since the bo might be migrated while the VMA is still alive,
there is no sense, whether or not it maps iomem might
and caching before anyone else gets hold of the object.
Signed-off-by: Thomas Hellström
---
v2:
- Style fixes (Reported by Matthew Auld)
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 112 +++-
1 file changed, 90 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem
elaborate shrinker for that memory.
Signed-off-by: Thomas Hellström
---
v2:
- Fix IS_ERR_OR_NULL() check to IS_ERR() (Reported by Matthew Auld)
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 22 ++
drivers/gpu/drm/i915/i915_drv.h| 3 ---
drivers/gpu/drm/i915
Instead of relying on a static placement, calculate at get_pages() time.
This should work for LMEM regions and system for now. For stolen we need
to take preallocated range into account. That well be added later.
Signed-off-by: Thomas Hellström
---
v2:
- Fixed a style issue (Reported by Matthew
On 6/14/21 12:20 PM, Matthew Auld wrote:
On Mon, 14 Jun 2021 at 10:53, Thomas Hellström
wrote:
After a TTM move or object init we need to update the i915 gem flags and
caching settings to reflect the new placement. Currently caching settings
are not changed during the lifetime of an object
the last patch (migration) It needs selftests and some additional work.
- Unconditionally add VM_IO at mmap time.
v3:
- More style fixes (reported by Matthew Auld)
- Don't overfill the busy placement vector (reported by Mattew Auld)
Thomas Hellström (4):
drm/i915: Update object placement flags
. The flags
will change during migration under the object lock.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2:
- Unconditionally set VM_IO on our VMAs in line with the rest core gem
and TTM. Since the bo might be migrated while the VMA is still alive,
there is no sense
page allocations.
Also introduce gpu_binds_iomem() and cpu_maps_iomem() to clean up the
various ways we previously used to detect this.
Finally, initialize the TTM object reserved to be able to update
flags and caching before anyone else gets hold of the object.
Signed-off-by: Thomas Hellström
Instead of relying on a static placement, calculate at get_pages() time.
This should work for LMEM regions and system for now. For stolen we need
to take preallocated range into account. That will if needed be added
later.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2
elaborate shrinker for that memory.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2:
- Fix IS_ERR_OR_NULL() check to IS_ERR() (Reported by Matthew Auld)
v3:
- Commit message typo fix
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 22 ++
drivers/gpu/drm/i915
On 6/14/21 3:48 PM, Matthew Auld wrote:
On Mon, 14 Jun 2021 at 12:54, Thomas Hellström
wrote:
After a TTM move or object init we need to update the i915 gem flags and
caching settings to reflect the new placement. Currently caching settings
are not changed during the lifetime of an object
On 6/14/21 12:49 PM, Matthew Auld wrote:
On Mon, 14 Jun 2021 at 11:32, Thomas Hellström
wrote:
On 6/14/21 12:20 PM, Matthew Auld wrote:
On Mon, 14 Jun 2021 at 10:53, Thomas Hellström
wrote:
After a TTM move or object init we need to update the i915 gem flags and
caching settings
CONFIG_BROKEN.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: Dave Airlie
Reviewed-by: Thomas Hellström
+ CC: Christian König,
With this in place, I think The mock memory_region and hugepages
selftests will be sensitive to changes in TTM on most intel platforms
Auld)
Thomas Hellström (4):
drm/i915: Update object placement flags to be mutable
drm/i915/ttm: Adjust gem flags and caching settings after a move
drm/i915/ttm: Calculate the object placement at get_pages time
drm/i915/ttm: Use TTM for system memory
drivers/gpu/drm/i915/gem
. The flags
will change during migration under the object lock.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2:
- Unconditionally set VM_IO on our VMAs in line with the rest core gem
and TTM. Since the bo might be migrated while the VMA is still alive,
there is no sense
page allocations.
Also introduce gpu_binds_iomem() and cpu_maps_iomem() to clean up the
various ways we previously used to detect this.
Finally, initialize the TTM object reserved to be able to update
flags and caching before anyone else gets hold of the object.
Signed-off-by: Thomas Hellström
Instead of relying on a static placement, calculate at get_pages() time.
This should work for LMEM regions and system for now. For stolen we need
to take preallocated range into account. That will if needed be added
later.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2
elaborate shrinker for that memory.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2:
- Fix IS_ERR_OR_NULL() check to IS_ERR() (Reported by Matthew Auld)
v3:
- Commit message typo fix
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 22 ++
drivers/gpu/drm/i915
As we're about to add more ww-related functionality,
break out the dma_resv ww locking utilities to their own files
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2:
- Make sure filenames are sorted in include file lists and Makefile
(Reported by Matthew Auld)
---
drivers/gpu
Introduce a for_i915_gem_ww(){} utility to help make the code
around a ww transaction more readable.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_ww.h | 31 +-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git
and destructor
drm/i915/gt: Pipelined page migration
drm/i915/gt: Pipelined clear
drm/i915/gt: Setup a default migration context on the GT
Ramalingam C (1):
drm/i915/ttm: accelerated move implementation
Thomas Hellström (5):
drm/i915: Reference objects on the ww object list
drm/i915: Break out
From: Ramalingam C
Invokes the pipelined page migration through blt, for
i915_ttm_move requests of eviction and also obj clear.
Signed-off-by: Ramalingam C
---
v2:
- subfunction for accel_move (Thomas)
- engine_pm_get/put around context_move/clear (Thomas)
- Invalidation at accel_clear
It's not used anywhere.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 -
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 355 -
.../gpu/drm/i915/gem/i915_gem_client_blt.h| 21 -
.../i915/gem/selftests/i915_gem_client_blt.c | 704
From: Chris Wilson
Update the PTE and emit a clear within a single unpreemptible packet
such that we can schedule and pipeline clears.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
---
v3:
- Handle engine instances correctly (Reported
reschedule individual operations however we see fit.
And most importantly, we do not need to take a global lock on the shared
vm, and wait until the operation is complete before releasing the lock
for others to claim the PTE for themselves.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
From: Chris Wilson
Set up a default migration context on the GT and use it from the
selftests.
Add a perf selftest and make sure we exercise LMEM if available.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v3
It's unused with the exception of selftest. Replace a call in the
memory_region live selftest with a call into a corresponding
function in the new migrate code.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 -
.../gpu/drm/i915/gem/i915_gem_object_blt.c
From: Chris Wilson
In the next patch, we will want to look at the dma addresses of
individual page tables, so add a routine to iterate over them.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 49
From: Chris Wilson
Allow internal clients to create and destroy a pinned context.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
v2:
- (Thomas) Export also the pinned context destructor
---
drivers/gpu/drm/i915/gt/intel_engine.h| 11 +
this
is really needed. But I think this is motivated by the fact that locking
is typically difficult to get right, and whatever we can do to make it
simpler for developers moving forward should be done, unless the
performance impact is far too high.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew
From: Chris Wilson
In the next patch, we will want to write a PTE for an explicit
dma address, outside of the usual vma.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 19 +++
1 file changed, 19 insertions(+)
diff --git
On 6/14/21 6:26 PM, Thomas Hellström wrote:
From: Ramalingam C
Invokes the pipelined page migration through blt, for
i915_ttm_move requests of eviction and also obj clear.
Signed-off-by: Ramalingam C
---
v2:
- subfunction for accel_move (Thomas)
- engine_pm_get/put around context_move
On 6/14/21 6:33 PM, Matthew Auld wrote:
On 14/06/2021 17:26, Thomas Hellström wrote:
It's not used anywhere.
Signed-off-by: Thomas Hellström
We do have to keep igt_client_tiled_blits subtest, it's not related to
the client blitting code and was added afterwards. Not completely sure
why
Instead of relying on a static placement, calculate at get_pages() time.
This should work for LMEM regions and system for now. For stolen we need
to take preallocated range into account. That will if needed be added
later.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2
elaborate shrinker for that memory.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2:
- Fix IS_ERR_OR_NULL() check to IS_ERR() (Reported by Matthew Auld)
v3:
- Commit message typo fix
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 22 ++
drivers/gpu/drm/i915
. The flags
will change during migration under the object lock.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2:
- Unconditionally set VM_IO on our VMAs in line with the rest core gem
and TTM. Since the bo might be migrated while the VMA is still alive,
there is no sense
page allocations.
Also introduce gpu_binds_iomem() and cpu_maps_iomem() to clean up the
various ways we previously used to detect this.
Finally, initialize the TTM object reserved to be able to update
flags and caching before anyone else gets hold of the object.
Signed-off-by: Thomas Hellström
Auld)
v5:
- Remove confusion around shrinkable objects again, but this time in the
correct patch. (reported by Matthew Auld)
Thomas Hellström (4):
drm/i915: Update object placement flags to be mutable
drm/i915/ttm: Adjust gem flags and caching settings after a move
drm/i915/ttm: Calculate
On 6/16/21 1:00 PM, Maarten Lankhorst wrote:
Op 15-06-2021 om 15:14 schreef Thomas Hellström:
Introduce a for_i915_gem_ww(){} utility to help make the code
around a ww transaction more readable.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915
Instead of relying on a static placement, calculate at get_pages() time.
This should work for LMEM regions and system for now. For stolen we need
to take preallocated range into account. That will if needed be added
later.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2
Instead of relying on a static placement, calculate at get_pages() time.
This should work for LMEM regions and system for now. For stolen we need
to take preallocated range into account. That will if needed be added
later.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2
On Tue, 2021-06-08 at 17:18 +0100, Matthew Auld wrote:
> On Tue, 8 Jun 2021 at 10:29, Thomas Hellström
> wrote:
> >
> > From: Chris Wilson
> >
> > If we pipeline the PTE updates and then do the copy of those pages
> > within a single unpreemptible command
On Tue, 2021-06-08 at 11:28 +0200, Thomas Hellström wrote:
> From: Chris Wilson
>
> If we pipeline the PTE updates and then do the copy of those pages
> within a single unpreemptible command packet, we can submit the
> copies
> and leave them to be scheduled without having to
On Tue, 2021-06-08 at 18:17 +0100, Matthew Auld wrote:
> On Tue, 8 Jun 2021 at 10:29, Thomas Hellström
> wrote:
> >
> > Introduce a for_i915_gem_ww(){} utility to help make the code
> > around a ww transaction more readable.
> >
> > Signed-off-by: Thomas Hel
this
is really needed. But I think this is motivated by the fact that locking
is typically difficult to get right, and whatever we can do to make it
simpler for developers moving forward should be done, unless the
performance impact is far too high.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew
As we're about to add more ww-related functionality,
break out the dma_resv ww locking utilities to their own files
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2:
- Make sure filenames are sorted in include file lists and Makefile
(Reported by Matthew Auld)
---
drivers/gpu
a default migration context on the GT
Thomas Hellström (3):
drm/i915: Reference objects on the ww object list
drm/i915: Break out dma_resv ww locking utilities to separate files
drm/i915: Introduce a ww transaction helper
drivers/gpu/drm/i915/Makefile | 2 +
drivers/gpu/drm
reschedule individual operations however we see fit.
And most importantly, we do not need to take a global lock on the shared
vm, and wait until the operation is complete before releasing the lock
for others to claim the PTE for themselves.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
From: Chris Wilson
Update the PTE and emit a clear within a single unpreemptible packet
such that we can schedule and pipeline clears.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_migrate.c| 141
From: Chris Wilson
Set up a default migration context on the GT and use it from the
selftests.
Add a perf selftest and make sure we exercise LMEM if available.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt
Introduce a for_i915_gem_ww(){} utility to help make the code
around a ww transaction more readable.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_ww.h | 31 +-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git
From: Chris Wilson
In the next patch, we will want to write a PTE for an explicit
dma address, outside of the usual vma.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 19 +++
1 file changed, 19 insertions(+)
diff --git
From: Chris Wilson
Allow internal clients to create and destroy a pinned context.
Signed-off-by: Chris Wilson
---
v2:
- (Thomas) Export also the pinned context destructor
---
drivers/gpu/drm/i915/gt/intel_engine.h| 11 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 27
From: Chris Wilson
In the next patch, we will want to look at the dma addresses of
individual page tables, so add a routine to iterate over them.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 49
drivers/gpu/drm/i915/gt/intel_gtt.h | 7
On 6/9/21 1:48 PM, Daniel Vetter wrote:
On Wed, Jun 09, 2021 at 08:34:27AM +0200, Thomas Hellström wrote:
A couple of patches from Chris which implement pipelined migration and
clears by atomically writing the PTEs in place before performing the
actual blit.
Some ww utilities mainly
On 6/9/21 2:20 PM, Matthew Auld wrote:
On 09/06/2021 13:16, Thomas Hellström wrote:
On 6/9/21 1:48 PM, Daniel Vetter wrote:
On Wed, Jun 09, 2021 at 08:34:27AM +0200, Thomas Hellström wrote:
A couple of patches from Chris which implement pipelined migration and
clears by atomically writing
On 6/9/21 3:08 PM, Thomas Hellström wrote:
On 6/9/21 2:20 PM, Matthew Auld wrote:
On 09/06/2021 13:16, Thomas Hellström wrote:
On 6/9/21 1:48 PM, Daniel Vetter wrote:
On Wed, Jun 09, 2021 at 08:34:27AM +0200, Thomas Hellström wrote:
A couple of patches from Chris which implement pipelined
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
> We need to be able to build an sg table from our list of buddy
> blocks,
> so that we can later plug this into our ttm backend, and replace our
> use
> of the range manager.
>
> Signed-off-by: Matthew Auld
> Cc: Tho
1 - 100 of 1196 matches
Mail list logo
