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
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 40
On 11/14/21 22:19, Linus Torvalds wrote:
On Sun, Nov 14, 2021 at 1:00 PM Dave Airlie wrote:
i915 will no longer be x86-64 only in theory, since Intel now produces
PCIe graphics cards using the same hw designs.
Well, at least in my tree, it still has the "depends on X86", along
with several
On 11/15/21 13:39, Matthew Auld wrote:
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
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 by having the fence in ttm_bo->moving,
w
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
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 40 ++--
drivers/gpu/drm
ing a cpu map will only work after
the moving fence signals.
This should close all holes where userspace can read a buffer
before it's fully migrated.
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_fbde
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
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 37 ++
: Add functions to set/get moving fence
drm/i915: Add support for asynchronous moving fence waiting
Thomas Hellström (4):
drm/i915/ttm: Move the i915_gem_obj_copy_ttm() function
drm/i915/ttm: Break refcounting loops at device region unref time
drm/i915/ttm: Implement asynchronous TTM moves
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
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 47 ---
drivers/gpu/drm/i915/gem/i915_gem_ttm.h
missing for fully asynchronous operation is asynchronous vma
unbinding, which is still to be implemented.
This commit substantially reduces execution time in the gem_lmem_swapping
test.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 10 +
drivers/gpu/drm/i915
ice takedown while the region is still present.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 1 +
drivers/gpu/drm/i915/intel_memory_region.c | 5 +++-
drivers/gpu/drm/i915/intel_memory_region.h | 1 +
drivers/
On 11/15/21 14:13, Matthew Auld wrote:
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
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
Hi, Matthew
Finally got some time to look at this more in-depth, please see below.
On Mon, 2021-11-15 at 17:16 +, Matthew Auld wrote:
> On 14/11/2021 11:12, Thomas Hellström wrote:
> > Don't wait sync while migrating, but rather make the GPU blit await
> > the
> >
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
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 47 ---
drivers/gpu/drm/i915
.
- Break what is now patch 4 out of patch 5. Add support for avoiding
waiting for gpu when shrinking.
- A number of changes in patch 5. See the commit message for details.
Maarten Lankhorst (1):
drm/i915: Add support for moving fence waiting
Thomas Hellström (5):
drm/i915/ttm: Move
ace 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.
Co-developed-by: Thomas Hellström
Signed-off-by: Tho
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/i915/gem/i915_gem_ttm.h | 2 +-
drivers/gpu
ect,
drm_i915_gem_object may hold a reference to intel_memory_region.
Break this loop by dropping region reference counting.
In addition, Have regions with a manager moving fence make sure
that all region objects are released before freeing the region.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/
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
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 40 ++--
drivers/gpu/drm
in the shrinker_release_pages() op and an
argument to that function indicating whether the shrinker expects it
to not wait for gpu. In the latter case the shrinker_release_pages()
op will return -EBUSY if the object is not idle.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem
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
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 40 ++--
drivers/gpu/drm
missing for fully asynchronous operation is asynchronous vma
unbinding, which is still to be implemented.
This commit substantially reduces execution time in the gem_lmem_swapping
test.
v2:
- Make a couple of functions static.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem
ing a cpu map will only work after
the moving fence signals.
This should close all holes where userspace can read a buffer
before it's fully migrated.
v2:
- Fix a couple of SPARSE warnings
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Signed-off-by: Maarten Lankho
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
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 47 ---
drivers/gpu/drm/i915/gem/i915_gem_ttm.h
ice takedown while the region is still present.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 1 +
drivers/gpu/drm/i915/intel_memory_region.c | 5 +++-
drivers/gpu/drm/i915/intel_memory_region.h | 1 +
drivers/
warnings.
Maarten Lankhorst (2):
drm/i915: Add functions to set/get moving fence
drm/i915: Add support for asynchronous moving fence waiting
Thomas Hellström (4):
drm/i915/ttm: Move the i915_gem_obj_copy_ttm() function
drm/i915/ttm: Break refcounting loops at device region unref time
drm/i915
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
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 37 ++
of a newly allocated TTM resource. It aborts and
leaves the memory uninitialized.
b) Something wedges the GT while a migration blit is submitted. It ends up
never executed and TTM can fault user-space cpu-ptes into uninitialized
memory.
Thomas Hellström (2):
drm/i915/ttm: Reorganize the ttm
dma_fence_work, now that's
opencoded which adds more code but might lower the latency
somewhat in the common non-error case.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 322 +++---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h | 5 +
.../drm/i915/gem
-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 328 +++
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 35 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 308 +
drivers/gpu/drm/i915/gem
- Fix compilation error in the !CONFIG_DRM_I915_CAPTURE_ERROR case
(kernel test robot)
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 135 ++---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +-
.../drm/i915/gt/inte
13: R14: 7ffd14d79b60 R15: 0005
v5:
- Use __GFP_KSWAPD_RECLAIM rather than __GFP_NOWAIT for clarity.
(Daniel Vetter)
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
for rebinding the same vma with different I915_VMA_*_BIND flags
v3:
- Some style fixups.
- Move the sync fence wait to __i915_vma_evict instead of __i915_vma_unbind
to catch also the evict case on suspend.
v4:
- Remove a minor fix that incorrectly landed in this patch.
Signed-off-by: Thomas
evicting for suspend on gen6.
- Minor cleanups on patch 3.
v4:
- Break out patch 2 from patch 1.
v5:
- Ditch a patch from the since it's already commited.
- Use __GFP_KSWAPD_RECLAIM rather than GFP_NOWAIT in patch 2.
Thomas Hellström (3):
drm/i915: Update error capture code to avoid using the current
Thanks for reviewing Matt,
On 11/2/21 14:55, Matthew Auld wrote:
On 01/11/2021 18:38, Thomas Hellström wrote:
If the initial fill blit or copy blit of an object fails, the old
content of the data might be exposed and read as soon as either CPU- or
GPU PTEs are set up to point at the pages
On 11/2/21 16:50, Matthew Auld wrote:
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
of a newly allocated TTM resource. It aborts and
leaves the memory uninitialized.
b) Something wedges the GT while a migration blit is submitted. It ends up
never executed and TTM can fault user-space cpu-ptes into uninitialized
memory.
v3:
- Style fixes in second patch (Matthew Auld)
Thomas
-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 328 +++
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 35 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 308
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)
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 322 +++---
drivers/gpu
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 data might be exposed and read as soon as either CPU- or
GPU PTEs are set up to point at the pages.
Intercept the blit
On 10/27/21 22:34, John Harrison wrote:
On 10/26/2021 23:36, Thomas Hellström wrote:
Hi, John,
On 10/26/21 21:55, John Harrison wrote:
On 10/21/2021 23:23, Thomas Hellström wrote:
On 10/21/21 22:37, Matthew Brost wrote:
On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote:
Hi
On 10/28/21 11:58, Matthew Auld wrote:
On 28/10/2021 10:35, Thomas Hellström wrote:
On 10/28/21 10:47, Matthew Auld wrote:
On 28/10/2021 08:04, Thomas Hellström wrote:
On Wed, 2021-10-27 at 19:03 +0100, Matthew Auld wrote:
On 27/10/2021 11:52, Thomas Hellström wrote:
As we start
On 10/28/21 10:47, Matthew Auld wrote:
On 28/10/2021 08:04, Thomas Hellström wrote:
On Wed, 2021-10-27 at 19:03 +0100, Matthew Auld wrote:
On 27/10/2021 11:52, Thomas Hellström wrote:
As we start to introduce asynchronous failsafe object migration,
where we update the object state
On Wed, 2021-10-27 at 19:03 +0100, Matthew Auld wrote:
> On 27/10/2021 11:52, Thomas Hellström wrote:
> > As we start to introduce asynchronous failsafe object migration,
> > where we update the object state and then submit asynchronous
> > commands we need to record
On 10/29/21 14:21, Matthew Auld wrote:
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 Ve
(Matthew Auld)
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 49 +++--
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 187 ++
drivers
.
Finally, correct lockdep annotation would reveal that error capture is
typically done in the fence signalling critical path. Alter the
error capture memory allocation mode accordingly.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915
From: Thomas Hellström
The vma resource are needed for asynchronous bind management and are
similar to TTM resources. They contain the data needed for
asynchronous unbinding (typically the vm range, any backend
private information and a means to do refcounting and to hold
the unbinding for error
during capture.
v2:
- Mostly Fixes for selftests and rebinding. See patch 3.
v3:
- Honor the unbind fence also when evicting for suspend on gen6.
- Cleanups on patch 1
- Minor cleanups on patch 3.
Thomas Hellström (3):
drm/i915: Introduce refcounted sg-tables
drm/i915: Update error capture code
On 10/22/21 18:48, Matthew Auld wrote:
The scratch page is directly visible in the users address space, and
while this is forced as CACHE_LLC, by the kernel, we still have to
contend with things like "Bypass-LLC" MOCS. So just flush no matter
what.
Signed-off-by: Matthew Auld
On 10/22/21 18:48, Matthew Auld wrote:
Normal users shouldn't be hitting this, likely this would indicate a
userspace bug. So don't bother caching, which should be safe now that we
manually flush the page.
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc
Cc: Thomas Hellström
Cc: Chris Wilson
Cc: Ramalingam C
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 67d14afa6623..b6c088423
Hi, John,
On 10/26/21 21:55, John Harrison wrote:
On 10/21/2021 23:23, Thomas Hellström wrote:
On 10/21/21 22:37, Matthew Brost wrote:
On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote:
Hi, Matthew,
On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote:
The hangcheck
GPU relocs are gone. There should be no need for this workaround anymore.
Remove it.
Signed-off-by: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem
On 10/23/21 20:18, Matthew Brost wrote:
On Sat, Oct 23, 2021 at 07:46:48PM +0200, Thomas Hellström wrote:
On 10/22/21 20:09, John Harrison wrote:
And to be clear, the engine reset is not supposed to fail. Whether
issued by GuC or i915, the GDRST register is supposed to self clear
according
On 10/22/21 20:09, John Harrison wrote:
And to be clear, the engine reset is not supposed to fail. Whether
issued by GuC or i915, the GDRST register is supposed to self clear
according to the bspec. If we are being sent the G2H notification for
an engine reset failure then the assumption is
during capture.
v2: Mostly Fixes for selftests and rebinding. See patch 3.
Thomas Hellström (3):
drm/i915: Introduce refcounted sg-tables
drm/i915: Update error capture code to avoid using the current vma
state
drm/i915: Initial introduction of vma resources
drivers/gpu/drm/i915/Makefile
From: Thomas Hellström
The vma resource are needed for asynchronous bind management and are
similar to TTM resources. They contain the data needed for
asynchronous unbinding (typically the vm range, any backend
private information and a means to do refcounting and to hold
the unbinding for error
to the design direction chosen for ttm resource managers that would
lead to diamond-style inheritance, the LMEM resources may sometimes be
prematurely freed, and finally the subclassed struct ttm_resource would
have to bleed into the asynchronous vma bind code.
Signed-off-by: Thomas Hellström
---
drivers
.
Finally, correct lockdep annotation would reveal that error capture is
typically done in the fence signalling critical path. Alter the
error capture memory allocation mode accordingly.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915
be
allocated in device local-memory anyway, so there should in theory be no
conceivable reason to ever call i915_gem_clflush_object() on discrete.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/4320
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
On 10/21/21 13:44, Matthew Auld wrote:
Move it next to its partner in crime; gpu_write_needs_clflush.
A motivation in the commit message?
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Otherwise:
Reviewed-by: Thomas Hellström
On 10/21/21 13:44, Matthew Auld wrote:
Should not be needed. Even with non-coherent display, we should be using
device local-memory there, and not system memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
intel_user_framebuffer_dirty() can arrive here before the
pages are populated.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
b/drivers/gpu
change of allocation mode to the separate patch.
- Commit message rework due to patch reordering.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 135 +++---
drivers/gpu/drm/i915/gt/intel_engine_cs.c
00014
[ 234.843121] R13: R14: 7ffd14d79b60 R15: 0005
v5:
- Use __GFP_KSWAPD_RECLAIM rather than __GFP_NOWAIT for clarity.
(Daniel Vetter)
v6:
- Include an instance in execlists_capture_work().
- Rework the commit message due to patch reordering.
Signed-off-by: Thomas Hellstr
for rebinding the same vma with different I915_VMA_*_BIND flags
v3:
- Some style fixups.
- Move the sync fence wait to __i915_vma_evict instead of __i915_vma_unbind
to catch also the evict case on suspend.
v4:
- Remove a minor fix that incorrectly landed in this patch.
Signed-off-by: Thomas
of the allocation succeeding.
In particular large contigous allocations like the coredump page
vector.
Remove the page vector in favor of a linked list of single pages.
Use the page lru list head as the list link, as the page owner is
allowed to do that.
Signed-off-by: Thomas Hellström
introduction of
patch 2/4.
- Use #if IS_ENABLED() rather than #ifdef similar to the rest of the
driver
Thomas Hellström (4):
drm/i915: Avoid allocating a page array for the gpu coredump
drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code
drm/i915: Update error capture code to avoid
that.
For such objects, identified by having the
_SELF_MANAGED_SHRINK_LIST set, make sure they end up on the
correct list and defer purging to the shrinker.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
style fixes in second patch (Matthew Auld)
Thomas Hellström (2):
drm/i915/ttm: Reorganize the ttm move code
drm/i915/ttm: Failsafe migration blits
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 328 ++-
drivers/gpu/drm/i915/gem
-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 328 +++
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 35 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 308
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)
v4:
- Use "#if IS_ENABLED()" instead of #ifdef (Matthew Auld)
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gp
t
end up waiting for a memcpy fence that would never signal.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 324 +++---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h | 5 +
.../drm/i915/gem/selftests/i915_gem_migrate.c |
style fixes in second patch (Matthew Auld)
v5:
- Fix an issue where we might end up waiting for a fence that would
never signal.
Thomas Hellström (2):
drm/i915/ttm: Reorganize the ttm move code
drm/i915/ttm: Failsafe migration blits
drivers/gpu/drm/i915/Makefile | 1
-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 328 +++
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 35 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 308
never waking up. Regardless whether that will be
the final solution for GuC, use clear_and_wake_up_bit() pending a more
thorough investigation on how this should be handled moving forward.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 8
drivers/gpu
On 11/8/21 09:08, Thomas Hellström wrote:
On 11/5/21 16:18, Matthew Auld wrote:
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
On 11/5/21 16:18, Matthew Auld wrote:
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
on the
correct list.
v2:
- Revert a change that made swapped-out objects inaccessible for
truncating. (Matthew Auld)
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm
(Matthew Auld)
v4:
- Dont check for st->sgl being NULL in i915_ttm_tt__shmem_unpopulate(),
that should never happen. (Matthew Auld)
v5:
- Fix a Potential double-free (Matthew Auld)
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.h|
Hi, Tvrtko
On Mon, 2021-11-01 at 13:14 +, Tvrtko Ursulin wrote:
>
> On 01/11/2021 12:24, Thomas Hellström wrote:
> > As we start to introduce asynchronous failsafe object migration,
> > where we update the object state and then submit asynchronous
> > commands we ne
Hi,
On 11/1/21 15:50, Tvrtko Ursulin wrote:
On 01/11/2021 13:51, Thomas Hellström wrote:
Hi, Tvrtko
On Mon, 2021-11-01 at 13:14 +, Tvrtko Ursulin wrote:
On 01/11/2021 12:24, Thomas Hellström wrote:
As we start to introduce asynchronous failsafe object migration,
where we update
-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.h| 4 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 16 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 188 +++---
drivers/gpu/drm/i915
From: Thomas Hellström
The vma resource are needed for asynchronous bind management and are
similar to TTM resources. They contain the data needed for
asynchronous unbinding (typically the vm range, any backend
private information and a means to do refcounting and to hold
the unbinding for error
during capture.
Thomas Hellström (3):
drm/i915: Introduce refcounted sg-tables
drm/i915: Update error capture code to avoid using the current vma
state
drm/i915: Initial introduction of vma resources
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gem
.
Finally, correct lockdep annotation would reveal that error capture is
typically done in the fence signalling critical path. Alter the
error capture memory allocation mode accordingly.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915
Hi,
On 10/21/21 22:37, Matthew Brost wrote:
On Thu, Oct 21, 2021 at 08:15:49AM +0200, Thomas Hellström wrote:
Hi, Matthew,
On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote:
The hangcheck selftest blocks per engine resets by setting magic bits
in
the reset flags. This is incorrect
From: Thomas Hellström
The vma resource are needed for asynchronous bind management and are
similar to TTM resources. They contain the data needed for
asynchronous unbinding (typically the vm range, any backend
private information and a means to do refcounting and to hold
the unbinding for error
to patch 1.
Thomas Hellström (4):
drm/i915: Introduce refcounted sg-tables
drm/i915: Update error capture code to avoid using the current vma
state
drm/i915: Use GFP_NOWAIT in the capture code
drm/i915: Initial introduction of vma resources
drivers/gpu/drm/i915/Makefile
fd14d79ab0
[ 234.843119] R10: R11: 0246 R12: 0014
[ 234.843121] R13: R14: 7ffd14d79b60 R15: 0005
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
08: R09: 7ffd14d79ab0
[ 234.843119] R10: R11: 0246 R12: 0014
[ 234.843121] R13: R14: 7ffd14d79b60 R15: 0005
v4:
- Break out the capture allocation mode change to a separate patch.
Signed-off-by: Thomas Hellstr
(Matthew Auld)
v4:
- Dont check for st->sgl being NULL in i915_ttm_tt__shmem_unpopulate(),
that should never happen. (Matthew Auld)
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +-
drivers/gpu/drm/i
On 10/29/21 00:55, Matthew Brost wrote:
On Thu, Oct 28, 2021 at 02:01:27PM +0200, Thomas Hellström wrote:
With asynchronous migrations, the vma state may be several migrations
ahead of the state that matches the request we're capturing.
Address that by introducing an i915_vma_snapshot
On 11/30/21 13:25, Maarten Lankhorst wrote:
On 30-11-2021 13:19, Thomas Hellström wrote:
The locking order for taking two fence locks is implicitly defined in
at least two ways in the code:
1) Fence containers first and other fences next, which is defined by
the enable_signaling() callbacks
On 11/30/21 13:19, Thomas Hellström wrote:
The locking order for taking two fence locks is implicitly defined in
at least two ways in the code:
1) Fence containers first and other fences next, which is defined by
the enable_signaling() callbacks of dma_fence_chain and
dma_fence_array.
2
On 11/30/21 13:42, Christian König wrote:
Am 30.11.21 um 13:31 schrieb Thomas Hellström:
[SNIP]
Other than that, I didn't investigate the nesting fails enough to
say I can accurately review this. :)
Basically the problem is that within enable_signaling() which is
called with the dma_fence
necessary.
Cc: Christian König
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Thomas Hellström
---
drivers/dma-buf/dma-fence-array.c | 12 +++-
drivers/dma-buf/dma-fence-chain.c | 9 +
include/linux/dma-fence.h | 1 +
3 files changed
excessive recursive locking in these containers
(patch 2)
Thomas Hellström (2):
dma-fence: Avoid establishing a locking order between fence classes
dma-fence: Avoid excessive recursive fence locking from
enable_signaling() callbacks
drivers/dma-buf/dma-fence-array.c | 23
701 - 800 of 1444 matches
Mail list logo
