Hi, Zack,
On 4/8/21 7:22 PM, Zack Rusin wrote:
Quite often it's a little hard to tell if reservations are already held
in code paths that unpin bo's. While our pinning/unpinning code should
be more explicit that requires a substential amount of work so instead
we can avoid the issues by making s
Hi, Zack,
On 4/10/21 8:59 PM, Zack Rusin wrote:
Quite often it's a little hard to tell if reservations are already held
in code paths that unpin bo's. While our pinning/unpinning code should
be more explicit that requires a substential amount of work so instead
we can avoid the issues by making
d-off-by: Zack Rusin
LGTM,
Reviewed-by: Thomas Hellström (Intel)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 4/15/21 3:37 PM, Daniel Vetter wrote:
On Tue, Apr 13, 2021 at 09:57:06AM +0200, Christian König wrote:
Am 13.04.21 um 09:50 schrieb Thomas Hellström:
Hi!
During the dma_resv conversion of the i915 driver, we've been using ww
transaction lock lists to keep track of ww_mutexes that are lock
On 4/15/21 4:40 PM, Daniel Vetter wrote:
On Thu, Apr 15, 2021 at 4:02 PM Thomas Hellström (Intel)
wrote:
On 4/15/21 3:37 PM, Daniel Vetter wrote:
On Tue, Apr 13, 2021 at 09:57:06AM +0200, Christian König wrote:
Am 13.04.21 um 09:50 schrieb Thomas Hellström:
Hi!
During the dma_resv
Hi,
On 8/3/21 7:26 PM, Matthew Brost wrote:
On Tue, Aug 03, 2021 at 02:15:13PM +0200, Daniel Vetter wrote:
On Tue, Aug 3, 2021 at 6:53 AM Matthew Brost wrote:
Minimum set of patches to enable GuC submission on DG1 and enable it by
default.
A little difficult to test as IGTs do not work with
On 8/6/21 1:34 PM, Thomas Hellström (Intel) wrote:
Hi,
On 8/3/21 7:26 PM, Matthew Brost wrote:
On Tue, Aug 03, 2021 at 02:15:13PM +0200, Daniel Vetter wrote:
On Tue, Aug 3, 2021 at 6:53 AM Matthew Brost
wrote:
Minimum set of patches to enable GuC submission on DG1 and enable
it by
On 8/6/21 1:34 PM, Thomas Hellström (Intel) wrote:
Hi,
On 8/3/21 7:26 PM, Matthew Brost wrote:
On Tue, Aug 03, 2021 at 02:15:13PM +0200, Daniel Vetter wrote:
On Tue, Aug 3, 2021 at 6:53 AM Matthew Brost
wrote:
Minimum set of patches to enable GuC submission on DG1 and enable
it by
Hi, Christian
On 3/12/21 10:38 AM, Christian König wrote:
We seem to have some more driver bugs than thought.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_api.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/
On 3/15/21 11:26 AM, Christian König wrote:
Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
Hi, Christian
On 3/12/21 10:38 AM, Christian König wrote:
We seem to have some more driver bugs than thought.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_api.h | 6
On 3/15/21 8:48 AM, Thomas Zimmermann wrote:
Hi
Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
Hi, Christian
On 3/12/21 10:38 AM, Christian König wrote:
We seem to have some more driver bugs than thought.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_api.h | 6
On 3/15/21 7:47 PM, Christian König wrote:
Am 15.03.21 um 18:08 schrieb Thomas Hellström (Intel):
On 3/15/21 11:26 AM, Christian König wrote:
Am 13.03.21 um 19:29 schrieb Thomas Hellström (Intel):
Hi, Christian
On 3/12/21 10:38 AM, Christian König wrote:
We seem to have some more
On 3/15/21 9:38 PM, Daniel Vetter wrote:
On Mon, Mar 15, 2021 at 6:57 PM Zack Rusin wrote:
On 3/12/21 5:06 AM, Thomas Hellström (Intel) wrote:
On 3/12/21 12:02 AM, Zack Rusin wrote:
On Mar 11, 2021, at 17:35, Thomas Hellström (Intel)
wrote:
Hi, Zack
On 3/11/21 10:07 PM, Zack Rusin wrote
Hi,
On 3/16/21 10:27 AM, Daniel Vetter wrote:
On Mon, Mar 15, 2021 at 08:00:30PM +0100, Thomas Hellström (Intel) wrote:
On 3/15/21 7:47 PM, Christian König wrote:
Am 15.03.21 um 18:08 schrieb Thomas Hellström (Intel):
On 3/15/21 11:26 AM, Christian König wrote:
Am 13.03.21 um 19:29
On 3/16/21 12:06 PM, Daniel Vetter wrote:
On Tue, Mar 16, 2021 at 11:38:53AM +0100, Thomas Hellström (Intel) wrote:
Hi,
On 3/16/21 10:27 AM, Daniel Vetter wrote:
On Mon, Mar 15, 2021 at 08:00:30PM +0100, Thomas Hellström (Intel) wrote:
On 3/15/21 7:47 PM, Christian König wrote:
Am 15.03.21
On 3/16/21 3:07 PM, Daniel Vetter wrote:
On Tue, Mar 16, 2021 at 12:24 PM Thomas Hellström (Intel)
wrote:
On 3/16/21 12:06 PM, Daniel Vetter wrote:
On Tue, Mar 16, 2021 at 11:38:53AM +0100, Thomas Hellström (Intel) wrote:
Hi,
On 3/16/21 10:27 AM, Daniel Vetter wrote:
On Mon, Mar 15, 2021
On 3/16/21 7:28 PM, Daniel Vetter wrote:
On Tue, Mar 16, 2021 at 7:18 PM Thomas Hellström (Intel)
wrote:
On 3/16/21 3:07 PM, Daniel Vetter wrote:
On Tue, Mar 16, 2021 at 12:24 PM Thomas Hellström (Intel)
wrote:
On 3/16/21 12:06 PM, Daniel Vetter wrote:
On Tue, Mar 16, 2021 at 11:38:53AM
patch makes sure we block normal gup by setting VM_PFNMAP
Cc: Christian Koenig
Cc: David Airlie
Cc: Daniel Vetter
Cc: Andrew Morton
Cc: Jason Gunthorpe
Cc: linux...@kvack.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Thomas Hellström (Intel
Cc: Jason Gunthorpe
Cc: linux...@kvack.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Thomas Hellström (Intel)
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 17 -
mm/gup.c| 21 +++--
mm/memremap.c
Cc: Jason Gunthorpe
Cc: linux...@kvack.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Thomas Hellström (Intel)
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 22 --
include/linux/mm.h | 5 +
mm/internal.h | 5 -
Hi!
On 3/22/21 8:47 AM, Christian König wrote:
Am 21.03.21 um 19:45 schrieb Thomas Hellström (Intel):
To block fast gup we need to make sure TTM ptes are always special.
With MIXEDMAP we, on architectures that don't support pte_special,
insert normal ptes, but OTOH on those architectures,
On 3/23/21 2:52 PM, Jason Gunthorpe wrote:
On Sun, Mar 21, 2021 at 07:45:28PM +0100, Thomas Hellström (Intel) wrote:
diff --git a/mm/gup.c b/mm/gup.c
index e40579624f10..1b6a127f0bdd 100644
+++ b/mm/gup.c
@@ -1993,6 +1993,17 @@ static void __maybe_unused undo_dev_pagemap(int *nr, int
nr_start
On 3/23/21 3:00 PM, Jason Gunthorpe wrote:
On Sun, Mar 21, 2021 at 07:45:29PM +0100, Thomas Hellström (Intel) wrote:
To block fast gup we need to make sure TTM ptes are always special.
With MIXEDMAP we, on architectures that don't support pte_special,
insert normal ptes, but OTOH on
On 3/23/21 3:04 PM, Jason Gunthorpe wrote:
On Tue, Mar 23, 2021 at 12:47:24PM +0100, Daniel Vetter wrote:
+static inline bool is_cow_mapping(vm_flags_t flags)
Bit a bikeshed, but I wonder whether the public interface shouldn't be
vma_is_cow_mapping. Or whether this shouldn't be rejected some
Hi,
On 3/23/21 12:34 PM, Daniel Vetter wrote:
On Sun, Mar 21, 2021 at 07:45:28PM +0100, Thomas Hellström (Intel) wrote:
TTM sets up huge page-table-entries both to system- and device memory,
and we don't want gup to assume there are always valid backing struct
pages for these. For PTEs th
On 3/23/21 5:37 PM, Jason Gunthorpe wrote:
On Tue, Mar 23, 2021 at 05:34:51PM +0100, Thomas Hellström (Intel) wrote:
@@ -210,6 +211,20 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault
*vmf,
if ((pfn & (fault_page_size - 1)) != 0)
goto out_fall
On 3/23/21 8:52 PM, Williams, Dan J wrote:
On Sun, 2021-03-21 at 19:45 +0100, Thomas Hellström (Intel) wrote:
TTM sets up huge page-table-entries both to system- and device
memory,
and we don't want gup to assume there are always valid backing struct
pages for these. For PTEs this is ha
On 3/24/21 10:58 AM, Daniel Vetter wrote:
On Tue, Mar 23, 2021 at 09:42:18PM +0100, Thomas Hellström (Intel) wrote:
On 3/23/21 8:52 PM, Williams, Dan J wrote:
On Sun, 2021-03-21 at 19:45 +0100, Thomas Hellström (Intel) wrote:
TTM sets up huge page-table-entries both to system- and device
your backing storage from the beginning and
pin
those pages if they are used by the device?
Yeah, that is exactly what the Intel guys are doing for their
integrated
GPUs :)
Problem is for TTM I need to be able to handle dGPUs and those have all
kinds of funny allocation restrictions. In other words I
a more uniform manner.
*/
- if (!pages && !i915_gem_object_needs_async_cancel(obj))
+ if (!pages)
pages = ERR_PTR(-EINVAL);
if (!IS_ERR(pages))
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
On 3/24/21 1:24 PM, Jason Gunthorpe wrote:
On Wed, Mar 24, 2021 at 10:56:43AM +0100, Daniel Vetter wrote:
On Tue, Mar 23, 2021 at 06:06:53PM +0100, Thomas Hellström (Intel) wrote:
On 3/23/21 5:37 PM, Jason Gunthorpe wrote:
On Tue, Mar 23, 2021 at 05:34:51PM +0100, Thomas Hellström (Intel
On 3/24/21 1:41 PM, Jason Gunthorpe wrote:
On Wed, Mar 24, 2021 at 01:35:17PM +0100, Thomas Hellström (Intel) wrote:
On 3/24/21 1:24 PM, Jason Gunthorpe wrote:
On Wed, Mar 24, 2021 at 10:56:43AM +0100, Daniel Vetter wrote:
On Tue, Mar 23, 2021 at 06:06:53PM +0100, Thomas Hellström (Intel
On 3/24/21 2:48 PM, Jason Gunthorpe wrote:
On Wed, Mar 24, 2021 at 02:35:38PM +0100, Thomas Hellström (Intel) wrote:
In an ideal world the creation/destruction of page table levels would
by dynamic at this point, like THP.
Hmm, but I'm not sure what problem we're trying to solve b
On 3/24/21 7:31 PM, Christian König wrote:
Am 24.03.21 um 17:38 schrieb Jason Gunthorpe:
On Wed, Mar 24, 2021 at 04:50:14PM +0100, Thomas Hellström (Intel)
wrote:
On 3/24/21 2:48 PM, Jason Gunthorpe wrote:
On Wed, Mar 24, 2021 at 02:35:38PM +0100, Thomas Hellström (Intel)
wrote:
In an
On 3/24/21 5:34 PM, Dave Hansen wrote:
On 3/24/21 3:05 AM, Thomas Hellström (Intel) wrote:
Yes, I agree. Seems like the special (SW1) is available also for huge
page table entries on x86 AFAICT, although just not implemented.
Otherwise the SW bits appear completely used up.
Although the
On 3/25/21 12:14 AM, Jason Gunthorpe wrote:
On Wed, Mar 24, 2021 at 09:07:53PM +0100, Thomas Hellström (Intel) wrote:
On 3/24/21 7:31 PM, Christian König wrote:
Am 24.03.21 um 17:38 schrieb Jason Gunthorpe:
On Wed, Mar 24, 2021 at 04:50:14PM +0100, Thomas Hellström (Intel)
wrote:
On 3/24
On 3/25/21 9:27 AM, Christian König wrote:
Am 25.03.21 um 08:48 schrieb Thomas Hellström (Intel):
On 3/25/21 12:14 AM, Jason Gunthorpe wrote:
On Wed, Mar 24, 2021 at 09:07:53PM +0100, Thomas Hellström (Intel)
wrote:
On 3/24/21 7:31 PM, Christian König wrote:
Am 24.03.21 um 17:38 schrieb
On 3/25/21 10:23 AM, Maarten Lankhorst wrote:
Instead of doing what we do currently, which will never work with
PROVE_LOCKING, do the same as AMD does, and something similar to
relocation slowpath. When all locks are dropped, we acquire the
pages for pinning. When the locks are taken, we transf
On 3/25/21 12:30 PM, Jason Gunthorpe wrote:
On Thu, Mar 25, 2021 at 10:51:35AM +0100, Thomas Hellström (Intel) wrote:
Please explain that further. Why do we need the mmap lock to insert PMDs
but not when insert PTEs?
We don't. But once you've inserted a PMD directory you can&#
On 3/25/21 1:09 PM, Christian König wrote:
Am 25.03.21 um 13:01 schrieb Jason Gunthorpe:
On Thu, Mar 25, 2021 at 12:53:15PM +0100, Thomas Hellström (Intel)
wrote:
Nope. The point here was that in this case, to make sure mmap uses the
correct VA to give us a reasonable chance of alignement
Hi,
On 3/25/21 2:02 PM, Christian König wrote:
Am 25.03.21 um 13:36 schrieb Thomas Hellström (Intel):
On 3/25/21 1:09 PM, Christian König wrote:
Am 25.03.21 um 13:01 schrieb Jason Gunthorpe:
On Thu, Mar 25, 2021 at 12:53:15PM +0100, Thomas Hellström (Intel)
wrote:
Nope. The point here
On 3/24/21 9:25 PM, Dave Hansen wrote:
On 3/24/21 1:22 PM, Thomas Hellström (Intel) wrote:
We also have not been careful at *all* about how _PAGE_BIT_SOFTW* are
used. It's quite possible we can encode another use even in the
existing bits.
Personally, I'd just try:
#define _PAGE_
On 3/25/21 6:55 PM, Jason Gunthorpe wrote:
On Thu, Mar 25, 2021 at 06:51:26PM +0100, Thomas Hellström (Intel) wrote:
On 3/24/21 9:25 PM, Dave Hansen wrote:
On 3/24/21 1:22 PM, Thomas Hellström (Intel) wrote:
We also have not been careful at *all* about how _PAGE_BIT_SOFTW* are
used. It&#
On 3/25/21 7:24 PM, Jason Gunthorpe wrote:
On Thu, Mar 25, 2021 at 07:13:33PM +0100, Thomas Hellström (Intel) wrote:
On 3/25/21 6:55 PM, Jason Gunthorpe wrote:
On Thu, Mar 25, 2021 at 06:51:26PM +0100, Thomas Hellström (Intel) wrote:
On 3/24/21 9:25 PM, Dave Hansen wrote:
On 3/24/21 1:22 PM
On 3/25/21 7:24 PM, Jason Gunthorpe wrote:
On Thu, Mar 25, 2021 at 07:13:33PM +0100, Thomas Hellström (Intel) wrote:
On 3/25/21 6:55 PM, Jason Gunthorpe wrote:
On Thu, Mar 25, 2021 at 06:51:26PM +0100, Thomas Hellström (Intel) wrote:
On 3/24/21 9:25 PM, Dave Hansen wrote:
On 3/24/21 1:22 PM
On 3/26/21 12:46 PM, Jason Gunthorpe wrote:
On Fri, Mar 26, 2021 at 10:08:09AM +0100, Thomas Hellström (Intel) wrote:
On 3/25/21 7:24 PM, Jason Gunthorpe wrote:
On Thu, Mar 25, 2021 at 07:13:33PM +0100, Thomas Hellström (Intel) wrote:
On 3/25/21 6:55 PM, Jason Gunthorpe wrote:
On Thu, Mar
On 2/23/21 11:59 AM, Daniel Vetter wrote:
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, wh
On 2/3/21 4:29 PM, Daniel Vetter wrote:
Recently there was a fairly long thread about recoreable hardware page
faults, how they can deadlock, and what to do about that.
While the discussion is still fresh I figured good time to try and
document the conclusions a bit. This documentation section
On 2/24/21 9:45 AM, Daniel Vetter wrote:
On Wed, Feb 24, 2021 at 8:46 AM Thomas Hellström (Intel)
wrote:
On 2/23/21 11:59 AM, Daniel Vetter wrote:
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
On 2/24/21 10:26 AM, Daniel Vetter wrote:
On Wed, Feb 24, 2021 at 9:47 AM Thomas Hellström (Intel)
wrote:
On 2/3/21 4:29 PM, Daniel Vetter wrote:
Recently there was a fairly long thread about recoreable hardware page
faults, how they can deadlock, and what to do about that.
While the
On 2/25/21 4:49 PM, Daniel Vetter wrote:
On Thu, Feb 25, 2021 at 11:44 AM Daniel Vetter wrote:
On Thu, Feb 25, 2021 at 11:28:31AM +0100, Christian König wrote:
Am 24.02.21 um 10:31 schrieb Daniel Vetter:
On Wed, Feb 24, 2021 at 10:16 AM Thomas Hellström (Intel)
wrote:
On 2/24/21 9:45 AM
On 2/26/21 2:28 PM, Daniel Vetter wrote:
On Fri, Feb 26, 2021 at 10:41 AM Thomas Hellström (Intel)
wrote:
On 2/25/21 4:49 PM, Daniel Vetter wrote:
On Thu, Feb 25, 2021 at 11:44 AM Daniel Vetter wrote:
On Thu, Feb 25, 2021 at 11:28:31AM +0100, Christian König wrote:
Am 24.02.21 um 10:31
Hi,
On 3/1/21 9:28 AM, Daniel Vetter wrote:
On Sat, Feb 27, 2021 at 9:06 AM Thomas Hellström (Intel)
wrote:
On 2/26/21 2:28 PM, Daniel Vetter wrote:
So I think it stops gup. But I haven't verified at all. Would be good
if Christian can check this with some direct io to a buffer in s
On 3/1/21 9:32 AM, Daniel Vetter wrote:
On Wed, Jan 06, 2021 at 10:01:09PM -0500, Felix Kuehling wrote:
From: Philip Yang
Register vram memory as MEMORY_DEVICE_PRIVATE type resource, to
allocate vram backing pages for page migration.
Signed-off-by: Philip Yang
Signed-off-by: Felix Kuehling
On 3/1/21 10:05 AM, Daniel Vetter wrote:
On Mon, Mar 01, 2021 at 09:39:53AM +0100, Thomas Hellström (Intel) wrote:
Hi,
On 3/1/21 9:28 AM, Daniel Vetter wrote:
On Sat, Feb 27, 2021 at 9:06 AM Thomas Hellström (Intel)
wrote:
On 2/26/21 2:28 PM, Daniel Vetter wrote:
So I think it stops gup
On 3/1/21 9:58 AM, Daniel Vetter wrote:
On Mon, Mar 01, 2021 at 09:46:44AM +0100, Thomas Hellström (Intel) wrote:
On 3/1/21 9:32 AM, Daniel Vetter wrote:
On Wed, Jan 06, 2021 at 10:01:09PM -0500, Felix Kuehling wrote:
From: Philip Yang
Register vram memory as MEMORY_DEVICE_PRIVATE type
On 2/3/21 4:29 PM, Daniel Vetter wrote:
Recently there was a fairly long thread about recoreable hardware page
faults, how they can deadlock, and what to do about that.
While the discussion is still fresh I figured good time to try and
document the conclusions a bit. This documentation section
On 3/1/21 3:09 PM, Daniel Vetter wrote:
On Mon, Mar 1, 2021 at 11:17 AM Christian König
wrote:
Am 01.03.21 um 10:21 schrieb Thomas Hellström (Intel):
On 3/1/21 10:05 AM, Daniel Vetter wrote:
On Mon, Mar 01, 2021 at 09:39:53AM +0100, Thomas Hellström (Intel)
wrote:
Hi,
On 3/1/21 9:28 AM
Hi,
I tried latest drm-fixes today and saw a lot of these: Fallout from ttm
rework?
/Thomas
[ 298.404788] WARNING: CPU: 1 PID: 3839 at
drivers/gpu/drm/ttm/ttm_bo.c:512 ttm_bo_release+0x2b5/0x300 [ttm]
[ 298.404795] Modules linked in: nls_utf8 isofs rfcomm tun bridge stp
llc ip6table_nat i
On 3/4/21 6:58 PM, Felix Kuehling wrote:
Am 2021-03-01 um 3:46 a.m. schrieb Thomas Hellström (Intel):
On 3/1/21 9:32 AM, Daniel Vetter wrote:
On Wed, Jan 06, 2021 at 10:01:09PM -0500, Felix Kuehling wrote:
From: Philip Yang
Register vram memory as MEMORY_DEVICE_PRIVATE type resource, to
experiment
with the fix for the huge page-table-entry issue.
/Thomas
Thanks,
Christian.
*Von:* Thomas Hellström (Intel)
*Gesendet:* Donnerstag, 11. März 2021 11:46
*An:* Daniel Vetter ; Koenig, Christian
; linux-graphi
Hi!
On 3/11/21 2:00 PM, Daniel Vetter wrote:
On Thu, Mar 11, 2021 at 11:22:06AM +0100, Thomas Hellström (Intel) wrote:
On 3/1/21 3:09 PM, Daniel Vetter wrote:
On Mon, Mar 1, 2021 at 11:17 AM Christian König
wrote:
Am 01.03.21 um 10:21 schrieb Thomas Hellström (Intel):
On 3/1/21 10:05 AM
On 3/11/21 2:17 PM, Daniel Vetter wrote:
On Thu, Mar 11, 2021 at 2:12 PM Thomas Hellström (Intel)
wrote:
Hi!
On 3/11/21 2:00 PM, Daniel Vetter wrote:
On Thu, Mar 11, 2021 at 11:22:06AM +0100, Thomas Hellström (Intel) wrote:
On 3/1/21 3:09 PM, Daniel Vetter wrote:
On Mon, Mar 1, 2021 at 11
Hi, Zack
On 3/11/21 10:07 PM, Zack Rusin wrote:
On Mar 11, 2021, at 05:46, Thomas Hellström (Intel)
wrote:
Hi,
I tried latest drm-fixes today and saw a lot of these: Fallout from ttm rework?
Yes, I fixed this in d1a73c641afd2617bd80bce8b71a096fc5b74b7e it was in
drm-misc-next in the drm
On 3/12/21 12:02 AM, Zack Rusin wrote:
On Mar 11, 2021, at 17:35, Thomas Hellström (Intel)
wrote:
Hi, Zack
On 3/11/21 10:07 PM, Zack Rusin wrote:
On Mar 11, 2021, at 05:46, Thomas Hellström (Intel)
wrote:
Hi,
I tried latest drm-fixes today and saw a lot of these: Fallout from ttm
On 5/11/21 3:58 PM, Christian König wrote:
Am 11.05.21 um 15:25 schrieb Thomas Hellström:
Most logical place to introduce TTM buffer objects is as an i915
gem object backend. We need to add some ops to account for added
functionality like delayed delete and LRU list manipulation.
Initially we
On 5/18/21 1:18 PM, Maarten Lankhorst wrote:
Op 18-05-2021 om 10:26 schreef Thomas Hellström:
We are currently sharing the VM reservation locks across a number of
gem objects with page-table memory. Since TTM will individiualize the
reservation locks when freeing objects, including accessing t
;t work because there are active maps with conflicting
caching attributes. I think the history here is that that was assumed to
be OK for integrated graphics that ran only on Intel processors that
promise to never write back unmodified cache lines resulting from
prefetching, like some AMD processo
ffer.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
new file mode 100644
index ..6f6dd4f1ce7e
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -0,0 +1,398 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright
Jason, Christian
In most implementations of the callback mentioned in the subject there's
a fence wait.
What exactly is it needed for?
Thanks,
Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailma
On 12/9/20 5:37 PM, Jason Gunthorpe wrote:
On Wed, Dec 09, 2020 at 05:36:16PM +0100, Thomas Hellström (Intel) wrote:
Jason, Christian
In most implementations of the callback mentioned in the subject there's a
fence wait.
What exactly is it needed for?
Invalidate must stop DMA b
Hi, Christian
Thanks for the reply.
On 12/10/20 11:53 AM, Christian König wrote:
Am 09.12.20 um 17:46 schrieb Thomas Hellström (Intel):
On 12/9/20 5:37 PM, Jason Gunthorpe wrote:
On Wed, Dec 09, 2020 at 05:36:16PM +0100, Thomas Hellström (Intel)
wrote:
Jason, Christian
In most
On 12/11/20 9:57 AM, Christian König wrote:
Am 11.12.20 um 08:50 schrieb Thomas Hellström (Intel):
Hi, Christian
Thanks for the reply.
On 12/10/20 11:53 AM, Christian König wrote:
Am 09.12.20 um 17:46 schrieb Thomas Hellström (Intel):
On 12/9/20 5:37 PM, Jason Gunthorpe wrote:
On Wed, Dec
Cheng wrote:
+Daniel for additional feedback!
On 2022-03-14 4:06 p.m., Michael Cheng wrote:
On 2022-03-08 10:58 a.m., Lucas De Marchi wrote:
On Tue, Feb 22, 2022 at 08:24:31PM +0100, Thomas Hellström (Intel)
wrote:
Hi, Michael,
On 2/22/22 18:26, Michael Cheng wrote:
This patch removes logi
On 3/21/22 23:44, Ramalingam C wrote:
Move the static calculations out of the loops for copy and clear.
Signed-off-by: Ramalingam C
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 44 -
1 file changed, 21 insertions(+), 23 deletions
Hi, Ram
On 3/21/22 23:44, Ramalingam C wrote:
Xe-HP and latest devices support Flat CCS which reserved a portion of
the device memory to store compression metadata, during the clearing of
device memory buffer object we also need to clear the associated
CCS buffer.
XY_CTRL_SURF_COPY_BLT is a BLT
On 3/21/22 23:44, Ramalingam C wrote:
Handle the src and dst chunk offsets for different instances of the copy
engines.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/
On 3/28/22 21:07, Ramalingam C wrote:
Consider the possible round up happened at obj size alignment to
min_page_size during the obj allocation.
Signed-off-by: Ramalingam C
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/selftest_migrate.c | 3 +++
1 file changed, 3 insertio
Hi, Michael,
On 2/22/22 18:26, Michael Cheng wrote:
This patch removes logic for wbinvd_on_all_cpus and brings in
drm_cache.h. This header has the logic that outputs a warning
when wbinvd_on_all_cpus when its being used on a non-x86 platform.
Signed-off-by: Michael Cheng
Linus has been prett
On 3/3/22 11:02, Matthew Auld wrote:
Currently this will enforce both 2M alignment and padding for any LMEM
pages inserted into the GGTT. However, this was only meant to be applied
to the compact-pt layout with the ppGTT. For the GGTT we can reduce the
alignment and padding to 64K.
Bspec: 4501
Hi, Jason,
A quick question below:
On 7/23/21 7:21 PM, Jason Ekstrand wrote:
From: Thomas Hellström
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also lo
On 9/29/21 10:59, Maarten Lankhorst wrote:
Ensure i915_vma_pin_iomap and vma_unpin are done with dpt->obj lock held.
I don't think there's much of a point in merging intel_dpt_pin() with
intel_pin_fb_obj_dpt(), they touch different objects.
Changes since v1:
- Fix using the wrong pointer to r
On 1/14/22 14:23, 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 1/20/22 14:27, Christian König wrote:
Consolidate the wrapper functions to check for dma_fence
subclasses in the dma_fence header.
This makes it easier to document and also check the different
requirements for fence containers in the subclasses.
Signed-off-by: Christian König
---
includ
mgblt fb_sys_fops prime_numbers intel_lpss_pci smsc75xx usbnet mii
<4> [184.578349] CPU: 6 PID: 5544 Comm: kms_addfb_basic Not tainted
5.16.0-CI-Patchwork_22006+ #1
<4> [184.578351] Hardware name: Intel Corporation Alder Lake Client
Platform/AlderLake-P DDR4 RVP, BIOS ADL
On 1/24/22 14:03, Christian König wrote:
Drivers should not add containers as shared fences to the dma_resv
object, instead each fence should be added individually.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Reviewed-by: Thomas Hellström
Is there any indication that this t
On 1/25/22 20:35, Robert Beckett wrote:
From: Ramalingam C
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for d
On 1/25/22 20:35, Robert Beckett wrote:
add test to check handling of misaligned offsets and sizes
v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot
Signed-off-by: Robert Beckett
---
dr
On 1/25/22 20:35, Robert Beckett wrote:
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less
On 1/25/22 20:35, Robert Beckett wrote:
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update
On 1/26/22 18:11, Robert Beckett wrote:
On 26/01/2022 13:49, Thomas Hellström (Intel) wrote:
On 1/25/22 20:35, Robert Beckett wrote:
From: Ramalingam C
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages
On 1/28/22 09:57, Maarten Lankhorst wrote:
i915_gem_vm_close may take the lock, and we currently have no better way
of handling this. At least for now, allow a path in which holding vm->mutex
is sufficient. This is the case, because the object destroy path will
forcefully take vm->mutex now.
S
On 12/1/21 08:05, Christian König wrote:
Am 30.11.21 um 20:27 schrieb Thomas Hellström:
On 11/30/21 19:12, Thomas Hellström wrote:
On Tue, 2021-11-30 at 16:02 +0100, Christian König wrote:
Am 30.11.21 um 15:35 schrieb Thomas Hellström:
On Tue, 2021-11-30 at 14:26 +0100, Christian König wro
On 12/1/21 09:36, Christian König wrote:
Am 01.12.21 um 09:23 schrieb Thomas Hellström (Intel):
[SNIP]
Jason and I came up with a deep dive iterator for his use case,
but I
think we don't want to use that any more after my dma_resv rework.
In other words when you need to create
On 12/1/21 11:32, Christian König wrote:
Am 01.12.21 um 11:15 schrieb Thomas Hellström (Intel):
[SNIP]
What we could do is to avoid all this by not calling the callback
with the lock held in the first place.
If that's possible that might be a good idea, pls also see below.
The pr
On 12/1/21 12:25, Christian König wrote:
Am 01.12.21 um 12:04 schrieb Thomas Hellström (Intel):
On 12/1/21 11:32, Christian König wrote:
Am 01.12.21 um 11:15 schrieb Thomas Hellström (Intel):
[SNIP]
What we could do is to avoid all this by not calling the callback
with the lock held in
On 12/3/21 16:00, Christian König wrote:
Am 03.12.21 um 15:50 schrieb Thomas Hellström:
On 12/3/21 15:26, Christian König wrote:
[Adding Daniel here as well]
Am 03.12.21 um 15:18 schrieb Thomas Hellström:
[SNIP]
Well that's ok as well. My question is why does this single dma_fence
then sh
Hi,
On 12/7/21 17:51, Ramalingam C wrote:
From: Stuart Summers
Add a new platform flag, has_64k_pages, for platforms supporting
base page sizes of 64k.
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_drv.h | 2
On 12/7/21 17:51, Ramalingam C wrote:
From: Matthew Auld
LMEM should be allocated at 64K granularity, since 4K page support will
eventually be dropped for LMEM when using the PPGTT.
Signed-off-by: Matthew Auld
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Cc: Joonas Lahtinen
On 12/8/21 13:59, Matthew Auld wrote:
On Wed, 8 Dec 2021 at 12:43, Thomas Hellström (Intel)
wrote:
Hi,
On 12/7/21 17:51, Ramalingam C wrote:
From: Stuart Summers
Add a new platform flag, has_64k_pages, for platforms supporting
base page sizes of 64k.
Signed-off-by: Stuart Summers
1 - 100 of 218 matches
Mail list logo
