On 12/11/20 1:46 PM, Jason Gunthorpe wrote:
On Fri, Dec 11, 2020 at 08:50:53AM +0100, Thomas Hellström (Intel) wrote:
My understanding of this particular case is that hardware would continue to
DMA to orphaned pages that are pinned until the driver is done with
DMA,
mmu notifier replaces
On 12/22/21 16:56, Maarten Lankhorst wrote:
Convert free_work into delayed_work, similar to ttm to allow converting the
blocking lock in __i915_gem_free_objects to a trylock.
Unlike ttm, the object should already be idle, as it's kept alive
by a reference through struct i915_vma->active, which
Hi, Matthew
On 12/15/21 12:07, Matthew Auld wrote:
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
LGTM.
Reviewed-by: Thomas Hellström
On 1/13/22 12:44, Maarten Lankhorst wrote:
i915_gem_evict_vm will need to be able to evict objects that are
locked by the current ctx. By testing if the current context already
locked the object, we can do this correctly. This allows us to
evict the entire vm even if we already hold some object
On 5/25/22 20:43, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Tho
On 5/25/22 20:43, Matthew Auld wrote:
A non-recoverable context must be used if the user wants proper error
capture on discrete platforms. In the future the kernel may want to blit
the contents of some objects when later doing the capture stage.
Testcase: igt@gem_exec_capture@capture-recoverab
On 5/25/22 20:43, Matthew Auld wrote:
Skip capturing any lmem pages that can't be copied using the CPU. This
in now only best effort on platforms that have small BAR.
Testcase: igt@gem-exec-capture@capture-invisible
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc:
On 5/25/22 20:43, Matthew Auld wrote:
If set, force the allocation to be placed in the mappable portion of
I915_MEMORY_CLASS_DEVICE. One big restriction here is that system memory
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the
object, that way we can always spill
Hi, Ram,
On 2/7/22 10:37, Ramalingam C wrote:
While evicting the local memory data on flat-ccs capable platform we
need to evict the ccs data associated to the data.
For this, we are
adding extra pages ((size / 256) >> PAGE_SIZE) into the ttm_tt.
To achieve this we are adding a new param
On 4/25/22 22:31, Zack Rusin wrote:
From: Zack Rusin
There's no point in explicitly trying to align virtual memory to
facilitate huge page table entries or huge page memory in buffer objects
given that they're not being used.
Transparent hugepages support for vram allocations has been gradua
Hi, Christian,
On 8/19/22 10:52, Christian König wrote:
Hi Thomas,
IIRC we intentionally dropped that approach of balancing
ttm_mem_io_reserve()/ttm_mem_io_free().
Instead the results from ttm_mem_io_reserve() are cached and that
cached information is freed by ttm_mem_io_free(). In other wo
Hi,
On 5/27/22 01:50, Dmitry Osipenko wrote:
Use ww_acquire_fini() in the error code paths. Otherwise lockdep
thinks that lock is held when lock's memory is freed after the
drm_gem_lock_reservations() error. The WW needs to be annotated
as "freed"
s /WW/ww_acquire_context/ ?
s /"freed"/"releas
On 5/30/22 15:57, Dmitry Osipenko wrote:
On 5/30/22 16:41, Christian König wrote:
Hi Dmitry,
Am 30.05.22 um 15:26 schrieb Dmitry Osipenko:
Hello Christian,
On 5/30/22 09:50, Christian König wrote:
Hi Dmitry,
First of all please separate out this patch from the rest of the series,
since th
On 6/29/22 01:35, Rob Clark wrote:
From: Rob Clark
drive-by cleanup
Signed-off-by: Rob Clark
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
On 5/27/22 01:50, Dmitry Osipenko wrote:
Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
handle imported dma-bufs properly, which results in mapping of something
else than the imported dma-buf. For example, on NVIDIA Tegra we get a hard
lockup when userspace writes to the m
On 5/27/22 01:50, Dmitry Osipenko wrote:
Unlock reservations on dma_resv_reserve_fences() error to fix recursive
locking of the reservations when this error happens.
Fixes:
Cc: sta...@vger.kernel.org
With that fixed,
Reviewed-by: Thomas Hellström
Signed-off-by: Dmitry Osipenko
---
d
On 6/29/22 10:22, Dmitry Osipenko wrote:
On 6/29/22 09:40, Thomas Hellström (Intel) wrote:
On 5/27/22 01:50, Dmitry Osipenko wrote:
Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
handle imported dma-bufs properly, which results in mapping of something
else tha
Hi, Dmitry,
On 6/30/22 22:04, Dmitry Osipenko wrote:
Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
handle imported dma-bufs properly, which results in mapping of something
else than the imported dma-buf. On NVIDIA Tegra we get a hard lockup when
userspace writes to the mem
On 6/30/22 22:22, Dmitry Osipenko wrote:
Hello Thomas,
On 6/30/22 23:15, Thomas Hellström (Intel) wrote:
Hi, Dmitry,
On 6/30/22 22:04, Dmitry Osipenko wrote:
Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
handle imported dma-bufs properly, which results in mappi
On 4/5/22 17:08, Ramalingam C wrote:
When emit_pte doesn't update any PTE with return value as 0, interpret
it as -EINVAL.
v2:
Add missing goto [Thomas]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
d
On 3/14/22 19:20, Ramalingam C wrote:
From: Chris Wilson
In order to keep the context image parser simple, we assume that all
commands follow a similar format. A few, especially not MI commands on
the render engines, have fixed lengths not encoded in a length field.
This caused us to incorrec
On 5/26/21 1:32 PM, Thomas Hellström wrote:
From: Maarten Lankhorst
The paltform should exclusively use mmap_offset, one less path to worry
Hmm, Thought this was fixed, but s/paltform/platform/
Hi, Christian,
Thanks for reviewing.
On 5/26/21 3:26 PM, Christian König wrote:
Am 26.05.21 um 13:32 schrieb Thomas Hellström:
We are calling the eviction_valuable driver callback at eviction time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs t
Hi,
On 5/27/21 3:30 AM, Lang Yu wrote:
Make TTM_PL_FLAG_* start from zero and add
TTM_PL_FLAG_TEMPORARY flag for temporary
GTT allocation use.
GTT is a driver private acronym, right? And it doesn't look like
TTM_PL_FLAG_TEMPORARY will be used in core TTM, so should we instead set
aside a mas
Hi Maarten,
On 5/26/21 1:32 PM, Thomas Hellström wrote:
From: Maarten Lankhorst
This allows drivers to distinguish between different types of vma_node's.
The readonly flag was unused and is thus removed.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
This one was acked by
On 5/28/21 9:30 PM, Zack Rusin wrote:
On 5/22/21 3:13 AM, Christian König wrote:
Hi Zack,
IIRC that was for the VMW_PL_GMR type, wasn't it?
As far as I have seen that backend was just giving out unique numbers
and it looked questionable that we allocated pages for that.
E.g. when you set
Hi, Christian,
On 4/30/21 11:25 AM, Christian König wrote:
Start with the range manager to make the resource object the base
class for the allocated nodes.
While at it cleanup a lot of the code around that.
Could you briefly describe the design thoughts around this. While it's
clear to me th
On 5/30/21 6:51 PM, Christian König wrote:
Hi Thomas,
Am 29.05.21 um 17:48 schrieb Thomas Hellström (Intel):
Hi, Christian,
On 4/30/21 11:25 AM, Christian König wrote:
Start with the range manager to make the resource object the base
class for the allocated nodes.
While at it cleanup a
Hi, Lang,
On 5/31/21 10:19 AM, Yu, Lang wrote:
[Public]
Hi,
On 5/27/21 3:30 AM, Lang Yu wrote:
Make TTM_PL_FLAG_* start from zero and add
TTM_PL_FLAG_TEMPORARY flag for temporary
GTT allocation use.
GTT is a driver private acronym, right? And it doesn't look like
TTM_PL_FLAG_TEMPORARY will b
On 5/31/21 12:32 PM, Christian König wrote:
Am 31.05.21 um 11:52 schrieb Thomas Hellström (Intel):
Hi, Lang,
On 5/31/21 10:19 AM, Yu, Lang wrote:
[Public]
Hi,
On 5/27/21 3:30 AM, Lang Yu wrote:
Make TTM_PL_FLAG_* start from zero and add
TTM_PL_FLAG_TEMPORARY flag for temporary
GTT
On 5/31/21 12:56 PM, Christian König wrote:
Am 31.05.21 um 12:46 schrieb Thomas Hellström (Intel):
On 5/31/21 12:32 PM, Christian König wrote:
Am 31.05.21 um 11:52 schrieb Thomas Hellström (Intel):
Hi, Lang,
On 5/31/21 10:19 AM, Yu, Lang wrote:
[Public]
Hi,
On 5/27/21 3:30 AM, Lang Yu
On 5/31/21 2:02 PM, Christian König wrote:
Am 31.05.21 um 13:19 schrieb Thomas Hellström (Intel):
On 5/31/21 12:56 PM, Christian König wrote:
Am 31.05.21 um 12:46 schrieb Thomas Hellström (Intel):
On 5/31/21 12:32 PM, Christian König wrote:
Am 31.05.21 um 11:52 schrieb Thomas Hellström
On 5/31/21 2:19 PM, Thomas Hellström wrote:
From: Maarten Lankhorst
Use the ttm handlers for servicing page faults, and vm_access.
We do our own validation of read-only access, otherwise use the
ttm handlers as much as possible.
Because the ttm handlers expect the vma_node at vma->base, we
On 6/2/21 10:30 AM, Christian König wrote:
We discussed if that is really the right approach for quite a while now, but
digging deeper into a bug report on arm turned out that this is actually
horrible broken right now.
The reason for this is that vmf_insert_mixed_prot() always tries to grab
a
On 6/2/21 10:32 AM, Christian König wrote:
Uff I'm just waiting for feedback from Philip to merge a large patch
set for TTM through drm-misc-next.
I'm pretty sure we will run into merge conflicts if you try to push
your changes through the Intel tree.
Christian.
OK, so what wo
Hi,
On 6/2/21 12:03 PM, Christian König wrote:
Am 02.06.21 um 11:07 schrieb Thomas Hellström (Intel):
On 6/2/21 10:30 AM, Christian König wrote:
We discussed if that is really the right approach for quite a while
now, but
digging deeper into a bug report on arm turned out that this is
On 6/2/21 12:09 PM, Christian König wrote:
Start with the range manager to make the resource object the base
class for the allocated nodes.
While at it cleanup a lot of the code around that.
Signed-off-by: Christian König
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm
On 6/2/21 2:11 PM, Christian König wrote:
Am 02.06.21 um 13:44 schrieb Thomas Hellström (Intel):
On 6/2/21 12:09 PM, Christian König wrote:
Start with the range manager to make the resource object the base
class for the allocated nodes.
While at it cleanup a lot of the code around that
On 6/2/21 3:07 PM, Christian König wrote:
Am 02.06.21 um 14:33 schrieb Thomas Hellström (Intel):
On 6/2/21 2:11 PM, Christian König wrote:
Am 02.06.21 um 13:44 schrieb Thomas Hellström (Intel):
On 6/2/21 12:09 PM, Christian König wrote:
Start with the range manager to make the resource
Hi!
On 6/2/21 4:17 PM, Christian König wrote:
Am 02.06.21 um 16:13 schrieb Thomas Hellström (Intel):
On 6/2/21 3:07 PM, Christian König wrote:
Am 02.06.21 um 14:33 schrieb Thomas Hellström (Intel):
On 6/2/21 2:11 PM, Christian König wrote:
Am 02.06.21 um 13:44 schrieb Thomas Hellström
On 6/2/21 8:41 PM, Christian König wrote:
Am 02.06.21 um 17:28 schrieb Thomas Hellström (Intel):
Hi!
On 6/2/21 4:17 PM, Christian König wrote:
Am 02.06.21 um 16:13 schrieb Thomas Hellström (Intel):
On 6/2/21 3:07 PM, Christian König wrote:
Am 02.06.21 um 14:33 schrieb Thomas Hellström
On 6/2/21 8:36 PM, Daniel Vetter wrote:
On Wed, Jun 02, 2021 at 02:21:17PM +0200, Thomas Hellström wrote:
On 6/2/21 2:04 PM, Christian König wrote:
Am 02.06.21 um 13:24 schrieb Thomas Hellström (Intel):
[SNIP]
@@ -576,14 +565,10 @@ static void
ttm_bo_mmap_vma_setup(struct
Hi, Christian,
It looks like all patches in the series have been reviewed or acked by
Matthew,
and while still a little worried about the final outcome of embedding a
struct ttm_mem_resource, FWIW,
Acked-by: Thomas Hellström
/Thomas
On 6/2/21 12:09 PM, Christian König wrote:
To improve the
On 6/2/21 12:09 PM, Christian König wrote:
Instead of both driver and TTM allocating memory finalize embedding the
ttm_resource object as base into the driver backends.
v2: fix typo in vmwgfx grid mgr and double init in amdgpu_vram_mgr.c
Signed-off-by: Christian König
Reviewed-by: Matthew Au
On 6/7/21 12:37 PM, Christian König wrote:
Am 07.06.21 um 12:15 schrieb Thomas Hellström (Intel):
On 6/2/21 12:09 PM, Christian König wrote:
Instead of both driver and TTM allocating memory finalize embedding the
ttm_resource object as base into the driver backends.
v2: fix typo in vmwgfx
On 6/7/21 12:40 PM, Christian König wrote:
That somehow got missing.
Signed-off-by: Christian König
Fixes: cb1c81467af3 ("drm/ttm: flip the switch for driver allocated resources
v2")
Reported-by: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_range_manag
Sure. LGTM,
Reviewed-by: Thomas Hellström
On 6/7/21 2:36 PM, Christian König wrote:
Thomas any comments on this?
Is the purpose of this now clear enough?
Thanks,
Christian.
Am 01.06.21 um 14:25 schrieb Christian König:
From: Lang Yu
Sometimes drivers need to use bounce buffers to evict
On 6/7/21 3:58 PM, Christian König wrote:
We discussed if that is really the right approach for quite a while now, but
digging deeper into a bug report on arm turned out that this is actually
horrible broken right now.
The reason for this is that vmf_insert_mixed_prot() always tries to grab
a
On 6/2/21 12:09 PM, Christian König wrote:
...
@@ -728,14 +728,15 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object
*bo,
*/
static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
const struct ttm_place *place,
-
On 6/7/21 6:40 PM, Thomas Hellström (Intel) wrote:
On 6/2/21 12:09 PM, Christian König wrote:
...
@@ -728,14 +728,15 @@ static int ttm_bo_add_move_fence(struct
ttm_buffer_object *bo,
*/
static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
const struct
On 6/7/21 7:11 PM, Christian König wrote:
The resource is not allocated yet, so no chance that this will work.
Use the placement instead.
Signed-off-by: Christian König
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
On 6/7/21 7:54 PM, Christian König wrote:
Am 07.06.21 um 19:06 schrieb Thomas Hellström (Intel):
On 6/7/21 6:40 PM, Thomas Hellström (Intel) wrote:
On 6/2/21 12:09 PM, Christian König wrote:
...
@@ -728,14 +728,15 @@ static int ttm_bo_add_move_fence(struct
ttm_buffer_object *bo
On 6/7/21 7:57 PM, Christian König wrote:
After we moved the resource to the ghost the bo->resource pointer needs
to be resetted since the owner of the resource is now the ghost.
s/resetted/reset/
Signed-off-by: Christian König
Reviewed-by: Thomas Hellström
Hi,
On 6/7/21 7:59 PM, Christian König wrote:
Am 07.06.21 um 19:58 schrieb Thomas Hellström (Intel):
On 6/7/21 7:54 PM, Christian König wrote:
Am 07.06.21 um 19:06 schrieb Thomas Hellström (Intel):
On 6/7/21 6:40 PM, Thomas Hellström (Intel) wrote:
On 6/2/21 12:09 PM, Christian König
Hi,
On 6/8/21 9:14 AM, Christian König wrote:
Am 08.06.21 um 07:29 schrieb Thomas Hellström (Intel):
Hi,
On 6/7/21 7:59 PM, Christian König wrote:
Am 07.06.21 um 19:58 schrieb Thomas Hellström (Intel):
On 6/7/21 7:54 PM, Christian König wrote:
Am 07.06.21 um 19:06 schrieb Thomas
Hi,
On 6/9/21 7:23 PM, Zack Rusin wrote:
The has_dx variable was only set during the initialization which
meant that UPDATE_SUBRESOURCE was never used. We were emulating it
with UPDATE_GB_IMAGE but that's always been a stop-gap. Instead
of has_dx which has been deprecated a long time ago we need
Hi, Christian,
I know you have a lot on your plate, and that the drm community is a bit
lax about following the kernel patch submitting guidelines, but now that
we're also spinning up a number of Intel developers on TTM could we
please make a better effort with cover letters and c
On 2/23/23 17:22, Christian König wrote:
Am 23.02.23 um 15:29 schrieb Thomas Hellström:
On 2/23/23 12:15, Christian König wrote:
Am 23.02.23 um 11:57 schrieb Thomas Hellström:
From: Maarten Lankhorst
Now that we have a generic suballocation helper, Use it in amdgpu.
For lines that get mov
On 1/18/23 07:12, Danilo Krummrich wrote:
This commit provides the implementation for the new uapi motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion
On 1/19/23 05:58, Matthew Brost wrote:
On Thu, Jan 19, 2023 at 04:44:23AM +0100, Danilo Krummrich wrote:
On 1/18/23 21:37, Thomas Hellström (Intel) wrote:
On 1/18/23 07:12, Danilo Krummrich wrote:
This commit provides the implementation for the new uapi motivated by the
Vulkan API. It
On 10/17/22 21:54, Zack Rusin wrote:
From: Maaz Mombasawala
Vmwgfx's hashtab implementation needs to be replaced with linux/hashtable
to reduce maintenence burden.
As part of this effort, refactor the res_ht hashtable used for resource
validation during execbuf execution to use linux/hashtabl
Hi, Zack,
On 10/19/22 18:32, Zack Rusin wrote:
On Wed, 2022-10-19 at 12:21 +0200, Thomas Hellström (Intel) wrote:
⚠ External Email
On 10/17/22 21:54, Zack Rusin wrote:
From: Maaz Mombasawala
Vmwgfx's hashtab implementation needs to be replaced with linux/hashtable
to reduce mainte
On 4/28/23 07:47, fei.y...@intel.com wrote:
From: Fei Yang
The first three patches in this series are taken from
https://patchwork.freedesktop.org/series/116868/
These patches are included here because the last patch
has dependency on the pat_index refactor.
This series is focusing on uAPI c
On 4/28/23 17:19, Yang, Fei wrote:
> On 4/28/23 07:47, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> The first three patches in this series are taken from
>> https://patchwork.freedesktop.org/series/116868/
>> These patches are included here because the last patch
>> has dependency on the p
On 4/28/23 19:43, Yang, Fei wrote:
>> On 4/28/23 17:19, Yang, Fei wrote:
>>> On 4/28/23 07:47, fei.y...@intel.com wrote:
From: Fei Yang
The first three patches in this series are taken from
https://patchwork.freedesktop.org/series/116868/
These patches are included here
On 5/4/23 13:51, Christian König wrote:
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existing TTMs execbuf util and intended to replace
it in the long term.
The basic functionality is that we abstracts the necessary loop to lock
many different G
_fence_work for the actual work although it's completion fence is
a dma_fence.
Although that goes against the whole idea of a condition for merging the
xe driver would be that we implement some sort of minimal scaffolding
for long-running workloads in the drm scheduler, and the thinking be
On 3/8/23 10:10, Christian König wrote:
Am 08.03.23 um 06:14 schrieb Zack Rusin:
On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote:
VMWGFX is the only remaining user of this and should probably moved
over
to drm_exec when it starts using GEM as well.
Is this because vmwgfx piggybacks
Hi,
On 3/9/23 06:14, Zack Rusin wrote:
On Wed, 2023-03-08 at 10:10 +0100, Christian König wrote:
Am 08.03.23 um 06:14 schrieb Zack Rusin:
On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote:
VMWGFX is the only remaining user of this and should probably moved over
to drm_exec when it star
Hi Christian
On 2/28/23 09:33, Christian König wrote:
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existinc TTMs execbuf util and intended to replace
it in the long term.
The basic functionality is that we abstracts the necessary loop to lock
man
On 6/14/23 15:22, Tvrtko Ursulin wrote:
On 14/06/2023 13:35, Sumitra Sharma wrote:
Pages allocated with GFP_KERNEL cannot come from Highmem.
That is why there is no need to call kmap() on them.
Are you sure it is GFP_KERNEL backed and not tmpfs? I am not sure
myself so let me copy Matt and
On 6/18/23 20:11, Ira Weiny wrote:
Sumitra Sharma wrote:
kmap() has been deprecated in favor of the kmap_local_page()
due to high cost, restricted mapping space, the overhead of a
global lock for synchronization, and making the process sleep
in the absence of free slots.
kmap_local_page() is
On 6/17/23 13:54, Boris Brezillon wrote:
+Matthew who's been using drm_exec in Xe if I'm correct.
Hello Christian,
On Wed, 14 Jun 2023 15:02:52 +0200
Boris Brezillon wrote:
On Wed, 14 Jun 2023 14:30:53 +0200
Christian König wrote:
Am 14.06.23 um 14:23 schrieb Boris Brezillon:
Hi Christ
Hi!
On 6/19/23 11:20, Christian König wrote:
Hi guys,
Am 19.06.23 um 10:59 schrieb Thomas Hellström (Intel):
[SNIP]
I really need to find some time to work on that anyway.
I've been playing with drm_exec for a couple weeks now, and I wanted
to share something I hacked to try and mak
On 6/19/23 11:48, Christian König wrote:
Hi,
Am 19.06.23 um 11:33 schrieb Thomas Hellström (Intel):
[SNIP]
Sometimes you want to just drop the contended lock after the above
relaxation. (Eviction would be one example), and not add as
prelocked, if the contended object goes out of scope
On 6/20/23 20:07, Sumitra Sharma wrote:
On Tue, Jun 20, 2023 at 06:23:38AM -0700, Ira Weiny wrote:
Sumitra Sharma wrote:
On Sun, Jun 18, 2023 at 11:11:08AM -0700, Ira Weiny wrote:
Sumitra Sharma wrote:
kmap() has been deprecated in favor of the kmap_local_page()
due to high cost, restricted
On 6/21/23 15:36, Christian König wrote:
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existing TTMs execbuf util and intended to replace
it in the long term.
The basic functionality is that we abstracts the necessary loop to lock
many different
On 6/21/23 18:35, Ira Weiny wrote:
Thomas Hellström (Intel) wrote:
I think one thing worth mentioning in the context of this patch is that
IIRC kmap_local_page() will block offlining of the mapping CPU until
kunmap_local(), so while I haven't seen any guidelines around the usage
of thi
Hi, Danilo
Some review comments below:
On 6/30/23 00:25, Danilo Krummrich wrote:
Add infrastructure to keep track of GPU virtual address (VA) mappings
with a decicated VA space manager implementation.
New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers
start implementing, al
On 7/6/23 17:48, Danilo Krummrich wrote:
Hi Thomas,
On 7/6/23 10:49, Thomas Hellström (Intel) wrote:
Hi, Danilo
Some review comments below:
On 6/30/23 00:25, Danilo Krummrich wrote:
Add infrastructure to keep track of GPU virtual address (VA) mappings
with a decicated VA space manager
Hi,
On 7/9/20 2:33 PM, Daniel Vetter wrote:
Comes up every few years, gets somewhat tedious to discuss, let's
write this down once and for all.
What I'm not sure about is whether the text should be more explicit in
flat out mandating the amdkfd eviction fences for long running compute
workloads
On 7/21/20 9:45 AM, Christian König wrote:
Am 21.07.20 um 09:41 schrieb Daniel Vetter:
On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel)
wrote:
Hi,
On 7/9/20 2:33 PM, Daniel Vetter wrote:
Comes up every few years, gets somewhat tedious to discuss, let's
write this down
On 7/21/20 10:55 AM, Christian König wrote:
Am 21.07.20 um 10:47 schrieb Thomas Hellström (Intel):
On 7/21/20 9:45 AM, Christian König wrote:
Am 21.07.20 um 09:41 schrieb Daniel Vetter:
On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel)
wrote:
Hi,
On 7/9/20 2:33 PM, Daniel
On 7/21/20 11:50 AM, Daniel Vetter wrote:
On Tue, Jul 21, 2020 at 11:38 AM Thomas Hellström (Intel)
wrote:
On 7/21/20 10:55 AM, Christian König wrote:
Am 21.07.20 um 10:47 schrieb Thomas Hellström (Intel):
On 7/21/20 9:45 AM, Christian König wrote:
Am 21.07.20 um 09:41 schrieb Daniel
On 2020-07-21 15:59, Christian König wrote:
Am 21.07.20 um 12:47 schrieb Thomas Hellström (Intel):
...
Yes, we can't do magic. As soon as an indefinite batch makes it to
such hardware we've lost. But since we can break out while the batch
is stuck in the scheduler waiting, what I
On 2020-07-22 00:45, Dave Airlie wrote:
On Tue, 21 Jul 2020 at 18:47, Thomas Hellström (Intel)
wrote:
On 7/21/20 9:45 AM, Christian König wrote:
Am 21.07.20 um 09:41 schrieb Daniel Vetter:
On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel)
wrote:
Hi,
On 7/9/20 2:33 PM
On 2020-07-22 09:11, Daniel Vetter wrote:
On Wed, Jul 22, 2020 at 8:45 AM Thomas Hellström (Intel)
wrote:
On 2020-07-22 00:45, Dave Airlie wrote:
On Tue, 21 Jul 2020 at 18:47, Thomas Hellström (Intel)
wrote:
On 7/21/20 9:45 AM, Christian König wrote:
Am 21.07.20 um 09:41 schrieb Daniel
On 2020-07-22 11:45, Daniel Vetter wrote:
On Wed, Jul 22, 2020 at 10:05 AM Thomas Hellström (Intel)
wrote:
On 2020-07-22 09:11, Daniel Vetter wrote:
On Wed, Jul 22, 2020 at 8:45 AM Thomas Hellström (Intel)
wrote:
On 2020-07-22 00:45, Dave Airlie wrote:
On Tue, 21 Jul 2020 at 18:47
On 2020-07-22 13:39, Daniel Vetter wrote:
On Wed, Jul 22, 2020 at 12:31 PM Thomas Hellström (Intel)
wrote:
On 2020-07-22 11:45, Daniel Vetter wrote:
On Wed, Jul 22, 2020 at 10:05 AM Thomas Hellström (Intel)
wrote:
On 2020-07-22 09:11, Daniel Vetter wrote:
On Wed, Jul 22, 2020 at 8:45 AM
t. Not much feedback aside from amdgpu and
intel, and those two drivers pretty much need to sort out their memory
fence issues anyway (because of userptr and stuff like that).
The only other issues outside of these two drivers I'm aware of:
- various scheduler drivers doing allocations in t
On 2020-07-22 16:23, Christian König wrote:
Am 22.07.20 um 16:07 schrieb Daniel Vetter:
On Wed, Jul 22, 2020 at 3:12 PM Thomas Hellström (Intel)
wrote:
On 2020-07-22 14:41, Daniel Vetter wrote:
I'm pretty sure there's more bugs, I just haven't heard from them yet.
Also du
On 2020-07-22 09:46, Daniel Vetter wrote:
On Wed, Jul 22, 2020 at 9:19 AM Christian König
wrote:
Am 22.07.20 um 02:22 schrieb Gurchetan Singh:
Of the desktop GPU drivers, i915's shrinker certainly supports purging
to swap. TTM is a bit hard to follow. I can't really tell if amdgpu
or nouvea
On 7/28/20 3:58 PM, Daniel Vetter wrote:
GPU drivers need this in their shrinkers, to be able to throw out
mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
but that loop is resolved by trylocking in shrinkers.
So full hierarchy is now (ignore some of the other branches we al
On 7/30/20 3:17 PM, Daniel Vetter wrote:
On Thu, Jul 30, 2020 at 2:17 PM Thomas Hellström (Intel)
wrote:
On 7/28/20 3:58 PM, Daniel Vetter wrote:
GPU drivers need this in their shrinkers, to be able to throw out
mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
but
On 6/9/20 7:21 PM, Koenig, Christian wrote:
Am 09.06.2020 18:37 schrieb "Grodzovsky, Andrey"
:
On 6/5/20 2:40 PM, Christian König wrote:
> Am 05.06.20 um 16:29 schrieb Andrey Grodzovsky:
>>
>> On 5/11/20 2:45 AM, Christian König wrote:
>>> Am 09.05.20 um 20:51 schrieb A
On 5/9/20 8:51 PM, Andrey Grodzovsky wrote:
This will allow to invalidate, destroy backing storage and notify users
of BOs when device is unpluged.
Signed-off-by: Andrey Grodzovsky
Please add a motivation in the commit message and use imperative wording
("Allow to invalidate..." instead of
Hi, Daniel,
Please see below.
On 6/4/20 10:12 AM, Daniel Vetter wrote:
fs_reclaim_acquire/release nicely catch recursion issues when
allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
to use to keep the excessive caches in check). For mmu notifier
recursions we do have lockd
On 6/4/20 10:12 AM, Daniel Vetter wrote:
Just some tiny edits:
- fix link to struct dma_fence
- give slightly more meaningful title - the polling here is about
implicit fences, explicit fences (in sync_file or drm_syncobj) also
have their own polling
Signed-off-by: Daniel Vetter
Revie
On 6/10/20 3:54 PM, Andrey Grodzovsky wrote:
On 6/10/20 6:15 AM, Thomas Hellström (Intel) wrote:
On 6/9/20 7:21 PM, Koenig, Christian wrote:
Am 09.06.2020 18:37 schrieb "Grodzovsky, Andrey"
:
On 6/5/20 2:40 PM, Christian König wrote:
> Am 05.06.20 um 16:29 s
On 6/10/20 5:30 PM, Daniel Vetter wrote:
On Wed, Jun 10, 2020 at 04:05:04PM +0200, Christian König wrote:
Am 10.06.20 um 15:54 schrieb Andrey Grodzovsky:
On 6/10/20 6:15 AM, Thomas Hellström (Intel) wrote:
On 6/9/20 7:21 PM, Koenig, Christian wrote:
Am 09.06.2020 18:37 schrieb
101 - 200 of 218 matches
Mail list logo
