Hi, Christian
On Fri, 2024-02-23 at 15:30 +0100, Christian König wrote:
> Am 06.02.24 um 13:56 schrieb Christian König:
> > Am 06.02.24 um 13:53 schrieb Thomas Hellström:
> > > Hi, Christian,
> > >
> > > On Fri, 2024-01-26 at 15:09 +0100, Christian König wrot
by Matthew
>
> Signed-off-by: Christian König
> Reviewed-by: Zack Rusin v3
Now Xe CI passes \o/
Still some checkpatch.pl warnings on both these lines.
For the first line I think it uses From: in the email as the author and
when that doesn't match the SOB, it becomes unhapp
corrective action can be taken at
the driver level.
The first patch deals with a ttm_device_init() interface change,
The Second patch adds the actual functionality.
A follow-up will be posted for Xe once this is merged / backmerged.
Thomas Hellström (2):
drm/ttm: Change ttm_device_init to use a
-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: spice-de...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: Zack Rusin
Cc:
Cc: Sui Jingfeng
Cc:
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 --
drivers
corrective action can be taken at
the driver level.
Cc: Christian König
Cc: Matthew Brost
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
drivers/gpu/drm/ttm/ttm_device.c | 1 +
include/drm/ttm/ttm_device.h | 13 +
3 files changed, 15 insertions(+), 1
On 2014-07-09 14:29, Maarten Lankhorst wrote:
This series applies on top of the driver-core-next branch of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
Before converting ttm to the new fence interface I had to fix some
drivers to require a reservation before poking with
Hi, Pekka!
I'm sorry for this breakage. I thought drm master was currently used
only for libdrm development, but
I see now that I didn't pay enough attention. Just prior to the commit I
sent out a message explaining what I was going to do and why, but
apparently it didn't make it to the list (w
Michel Dänzer skrev:
On Wed, 2009-06-24 at 19:26 +0200, Thomas Hellström wrote:
Just prior to the commit I sent out a message explaining what I was
going to do and why, but apparently it didn't make it to the list
(which seems to be the case of quite a few mails these days).
Wha
Jerome Glisse wrote:
> On Thu, 2009-11-05 at 20:04 +0200, Pekka Paalanen wrote:
>
>> On Wed, 4 Nov 2009 17:42:26 +
>> Jakob Bornecrantz wrote:
>>
>>
>>> Hi Jerome
>>>
>>> On 4 nov 2009, at 15.58, Jerome Glisse wrote:
>>>
Note: For reference my issue is with cursor on old ra
On 8/31/23 18:53, Thomas Hellström (Intel) wrote:
Hi,
On 8/31/23 13:18, Danilo Krummrich wrote:
On Thu, Aug 31, 2023 at 11:04:06AM +0200, Thomas Hellström (Intel)
wrote:
Hi!
On 8/30/23 17:00, Danilo Krummrich wrote:
On Wed, Aug 30, 2023 at 03:42:08PM +0200, Thomas Hellström (Intel)
wrote
Hi, Danilo
On 9/9/23 17:31, Danilo Krummrich wrote:
This patch adds an abstraction layer between the drm_gpuva mappings of
a particular drm_gem_object and this GEM object itself. The abstraction
represents a combination of a drm_gem_object and drm_gpuvm. The
drm_gem_object holds a list of drm_gp
On 9/11/23 19:49, Danilo Krummrich wrote:
Hi Thomas,
On 9/11/23 19:19, Thomas Hellström wrote:
Hi, Danilo
On 9/9/23 17:31, Danilo Krummrich wrote:
This patch adds an abstraction layer between the drm_gpuva mappings of
a particular drm_gem_object and this GEM object itself. The abstraction
Hi, Danilo
On 9/11/23 19:49, Danilo Krummrich wrote:
Hi Thomas,
On 9/11/23 19:19, Thomas Hellström wrote:
Hi, Danilo
On 9/9/23 17:31, Danilo Krummrich wrote:
This patch adds an abstraction layer between the drm_gpuva mappings of
a particular drm_gem_object and this GEM object itself. The
On 9/12/23 12:06, Danilo Krummrich wrote:
On Tue, Sep 12, 2023 at 09:42:44AM +0200, Thomas Hellström wrote:
Hi, Danilo
On 9/11/23 19:49, Danilo Krummrich wrote:
Hi Thomas,
On 9/11/23 19:19, Thomas Hellström wrote:
Hi, Danilo
On 9/9/23 17:31, Danilo Krummrich wrote:
This patch adds an
Hi, Danilo,
On 9/9/23 17:31, Danilo Krummrich wrote:
So far the DRM GPUVA manager offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and perform more complex mapping operations on the GPU VA
space.
However, there a
On 9/12/23 18:50, Danilo Krummrich wrote:
On Tue, Sep 12, 2023 at 06:20:32PM +0200, Thomas Hellström wrote:
Hi, Danilo,
On 9/9/23 17:31, Danilo Krummrich wrote:
So far the DRM GPUVA manager offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA
Hi!
On Wed, 2023-09-13 at 01:36 +0200, Danilo Krummrich wrote:
> On Tue, Sep 12, 2023 at 09:23:08PM +0200, Thomas Hellström wrote:
> >
> > On 9/12/23 18:50, Danilo Krummrich wrote:
> > > On Tue, Sep 12, 2023 at 06:20:32PM +0200, Thomas Hellström wrote:
> > > >
Hi,
On 9/13/23 09:19, Boris Brezillon wrote:
On Wed, 13 Sep 2023 17:05:42 +1000
Dave Airlie wrote:
On Wed, 13 Sept 2023 at 17:03, Boris Brezillon
wrote:
On Tue, 12 Sep 2023 18:20:32 +0200
Thomas Hellström wrote:
+/**
+ * get_next_vm_bo_from_list() - get the next vm_bo element
On 9/13/23 13:33, Boris Brezillon wrote:
On Wed, 13 Sep 2023 12:39:01 +0200
Thomas Hellström wrote:
Hi,
On 9/13/23 09:19, Boris Brezillon wrote:
On Wed, 13 Sep 2023 17:05:42 +1000
Dave Airlie wrote:
On Wed, 13 Sept 2023 at 17:03, Boris Brezillon
wrote:
On Tue, 12 Sep 2023 18:20:32
On 9/13/23 16:01, Boris Brezillon wrote:
On Wed, 13 Sep 2023 15:22:56 +0200
Thomas Hellström wrote:
On 9/13/23 13:33, Boris Brezillon wrote:
On Wed, 13 Sep 2023 12:39:01 +0200
Thomas Hellström wrote:
Hi,
On 9/13/23 09:19, Boris Brezillon wrote:
On Wed, 13 Sep 2023 17:05:42 +1000
ional
locks / locking mechanisms. But this code doesn't do that yet. Is your
concern that these particular spinlocks for these lists are indeed needed?
/Thomas
Regards,
Christian.
On Wed, Sep 13, 2023 at 11:14:46AM +0200, Thomas Hellström wrote:
Hi!
On Wed, 2023-09-13 at 01:36 +02
On 9/14/23 10:20, Boris Brezillon wrote:
On Wed, 13 Sep 2023 15:22:56 +0200
Thomas Hellström wrote:
On 9/13/23 13:33, Boris Brezillon wrote:
On Wed, 13 Sep 2023 12:39:01 +0200
Thomas Hellström wrote:
Hi,
On 9/13/23 09:19, Boris Brezillon wrote:
On Wed, 13 Sep 2023 17:05:42 +1000
On 9/14/23 12:57, Danilo Krummrich wrote:
On 9/13/23 14:16, Danilo Krummrich wrote:
And validate() can remove it while still holding all dma-resv locks,
neat!
However, what if two tasks are trying to lock the VA space
concurrently? What
do we do when the drm_gpuvm_bo's refcount drops to zer
Hi, Danilo
Some additional minor comments as xe conversion progresses.
On 9/9/23 17:31, Danilo Krummrich wrote:
So far the DRM GPUVA manager offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and perform more compl
Hi,
On 9/14/23 13:54, Boris Brezillon wrote:
On Thu, 14 Sep 2023 12:45:44 +0200
Thomas Hellström wrote:
On 9/14/23 10:20, Boris Brezillon wrote:
On Wed, 13 Sep 2023 15:22:56 +0200
Thomas Hellström wrote:
On 9/13/23 13:33, Boris Brezillon wrote:
On Wed, 13 Sep 2023 12:39:01 +0200
On Thu, 2023-09-14 at 17:27 +0200, Danilo Krummrich wrote:
> On 9/14/23 13:32, Thomas Hellström wrote:
> >
> > On 9/14/23 12:57, Danilo Krummrich wrote:
> > > On 9/13/23 14:16, Danilo Krummrich wrote:
> > >
> > >
> > >
> > > &g
On Thu, 2023-09-14 at 18:36 +0200, Danilo Krummrich wrote:
> On 9/14/23 15:48, Thomas Hellström wrote:
> > Hi, Danilo
> >
> > Some additional minor comments as xe conversion progresses.
> >
> > On 9/9/23 17:31, Danilo Krummrich wrote:
> > >
On Thu, 2023-09-14 at 19:25 +0200, Danilo Krummrich wrote:
> On 9/14/23 19:21, Thomas Hellström wrote:
> > On Thu, 2023-09-14 at 18:36 +0200, Danilo Krummrich wrote:
> > > On 9/14/23 15:48, Thomas Hellström wrote:
> > > > Hi, Danilo
> > > >
> > >
at least not in Xe, since evicting we
wait for VM idle, and it cant access anything through the stale vmas
until they have been revalidated and rebound.
/Thomas
Regards,
Christian.
Regards,
Christian.
On Wed, Sep 13, 2023 at 11:14:46AM +0200, Thomas Hellström wrote:
Hi!
On Wed
On 9/19/23 17:16, Danilo Krummrich wrote:
On 9/19/23 14:21, Thomas Hellström wrote:
Hi Christian
On 9/19/23 14:07, Christian König wrote:
Am 13.09.23 um 17:46 schrieb Danilo Krummrich:
On 9/13/23 17:33, Christian König wrote:
Am 13.09.23 um 17:15 schrieb Danilo Krummrich:
On 9/13/23 16
Hi,
On 9/20/23 07:37, Christian König wrote:
Am 19.09.23 um 17:23 schrieb Thomas Hellström:
On 9/19/23 17:16, Danilo Krummrich wrote:
On 9/19/23 14:21, Thomas Hellström wrote:
Hi Christian
On 9/19/23 14:07, Christian König wrote:
Am 13.09.23 um 17:46 schrieb Danilo Krummrich:
On 9/13/23
On 9/20/23 09:44, Thomas Hellström wrote:
Hi,
On 9/20/23 07:37, Christian König wrote:
Am 19.09.23 um 17:23 schrieb Thomas Hellström:
On 9/19/23 17:16, Danilo Krummrich wrote:
On 9/19/23 14:21, Thomas Hellström wrote:
Hi Christian
On 9/19/23 14:07, Christian König wrote:
Am 13.09.23 um
On 9/20/23 12:51, Christian König wrote:
Am 20.09.23 um 09:44 schrieb Thomas Hellström:
Hi,
On 9/20/23 07:37, Christian König wrote:
Am 19.09.23 um 17:23 schrieb Thomas Hellström:
On 9/19/23 17:16, Danilo Krummrich wrote:
On 9/19/23 14:21, Thomas Hellström wrote:
Hi Christian
On 9/19
On 9/20/23 15:06, Christian König wrote:
Am 20.09.23 um 14:06 schrieb Thomas Hellström:
On 9/20/23 12:51, Christian König wrote:
Am 20.09.23 um 09:44 schrieb Thomas Hellström:
Hi,
On 9/20/23 07:37, Christian König wrote:
Am 19.09.23 um 17:23 schrieb Thomas Hellström:
On 9/19/23 17:16
Hi
On 9/20/23 15:48, Christian König wrote:
Am 20.09.23 um 15:38 schrieb Thomas Hellström:
On 9/20/23 15:06, Christian König wrote:
Am 20.09.23 um 14:06 schrieb Thomas Hellström:
On 9/20/23 12:51, Christian König wrote:
Am 20.09.23 um 09:44 schrieb Thomas Hellström:
Hi,
On 9/20/23 07
Hi, Danilo,
On 9/28/23 21:16, Danilo Krummrich wrote:
Currently the DRM GPUVM offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and perform more complex mapping operations on the GPU VA
space.
However, there are m
Hi Again,
On 10/3/23 10:36, Thomas Hellström wrote:
Hi, Danilo,
On 9/28/23 21:16, Danilo Krummrich wrote:
Currently the DRM GPUVM offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and perform more complex
Hi, Boris,
On Tue, 2023-10-03 at 12:05 +0200, Boris Brezillon wrote:
> Hello Thomas,
>
> On Tue, 3 Oct 2023 10:36:10 +0200
> Thomas Hellström wrote:
>
> > > +/**
> > > + * get_next_vm_bo_from_list() - get the next vm_bo element
> > > + * @__gpuvm: The
ase let me know what you think, and, of course, other ideas than
> the
> mentioned ones above are still welcome.
Personally, after converting xe to version 5, I think it's pretty
convenient for the driver, (although had to add the evict trick), so I
think I'd vote for this, even if
On 10/3/23 18:55, Danilo Krummrich wrote:
It seems like we're mostly aligned on this series, except for the key
controversy we're discussing for a few versions now: locking of the internal
lists. Hence, let's just re-iterate the options we have to get this out of the
way.
(1) The spinlock danc
On Wed, 2023-10-04 at 14:57 +0200, Danilo Krummrich wrote:
> On 10/3/23 11:11, Thomas Hellström wrote:
>
>
>
> > > > +
> > > > +/**
> > > > + * drm_gpuvm_bo_evict() - add / remove a &drm_gpuvm_bo to /
> > > > from the &drm_g
On Wed, 2023-10-04 at 19:17 +0200, Danilo Krummrich wrote:
> On 10/4/23 17:29, Thomas Hellström wrote:
> >
> > On Wed, 2023-10-04 at 14:57 +0200, Danilo Krummrich wrote:
> > > On 10/3/23 11:11
Hi, Danilo
On 9/28/23 21:16, Danilo Krummrich wrote:
Currently GPUVM offers common infrastructure to track GPU VA allocations
and mappings, generically connect GPU VA mappings to their backing
buffers and perform more complex mapping operations on the GPU VA space.
However, there are more desig
Hi,
On 9/28/23 21:16, Danilo Krummrich wrote:
This patch adds an abstraction layer between the drm_gpuva mappings of
NIT: imperative: s/This patch adds/Add/
a particular drm_gem_object and this GEM object itself. The abstraction
represents a combination of a drm_gem_object and drm_gpuvm. The
On 9/28/23 21:16, Danilo Krummrich wrote:
Currently the DRM GPUVM offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and perform more complex mapping operations on the GPU VA
space.
However, there are more design
On 10/9/23 01:32, Danilo Krummrich wrote:
Currently the DRM GPUVM offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and perform more complex mapping operations on the GPU VA
space.
However, there are more design
On 10/9/23 16:45, Danilo Krummrich wrote:
On 10/9/23 15:36, Thomas Hellström wrote:
On 10/9/23 01:32, Danilo Krummrich wrote:
Currently the DRM GPUVM offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and
On 10/9/23 01:32, Danilo Krummrich wrote:
Currently the DRM GPUVM offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and perform more complex mapping operations on the GPU VA
space.
However, there are more design
On Wed, 2023-10-11 at 06:23 +1000, Dave Airlie wrote:
> > I think we're then optimizing for different scenarios. Our compute
> > driver will use mostly external objects only, and if shared, I
> > don't
> > forsee them bound to many VMs. What saves us currently here is that
> > in
> > compute mode w
t drm_gem_object *
> +drm_gpuvm_root_object_alloc(struct drm_device *drm);
> +
> +/**
> + * drm_gpuvm_resv() - returns the &drm_gpuvm's &dma_resv
> + * @gpuvm__: the &drm_gpuvm
> + *
> + * Returns: a pointer to the &drm_gpuvm's shared &dma_resv
> + */
> +#define drm_gpuvm_resv(gpuvm__) ((gpuvm__)->r_obj->resv)
> +
> +/**
> + * drm_gpuvm_resv_obj() - returns the &drm_gem_object holding the
> &drm_gpuvm's
> + * &dma_resv
> + * @gpuvm__: the &drm_gpuvm
> + *
> + * Returns: a pointer to the &drm_gem_object holding the
> &drm_gpuvm's shared
> + * &dma_resv
> + */
> +#define drm_gpuvm_resv_obj(gpuvm__) ((gpuvm__)->r_obj)
> +
> +#define drm_gpuvm_resv_held(gpuvm__) \
> + dma_resv_held(drm_gpuvm_resv(gpuvm__))
> +
> +#define drm_gpuvm_resv_assert_held(gpuvm__) \
> + dma_resv_assert_held(drm_gpuvm_resv(gpuvm__))
> +
> static inline struct drm_gpuva *
> __drm_gpuva_next(struct drm_gpuva *va)
> {
Reviewed-by: Thomas Hellström
};
>
> void drm_gpuvm_init(struct drm_gpuvm *gpuvm, struct drm_gem_object
> *r_obj,
> - const char *name,
> + const char *name, enum drm_gpuvm_flags flags,
> u64 start_offset, u64 range,
> u64 reserve_offset, u64 reserve_range,
> const struct drm_gpuvm_ops *ops);
Reviewed-by: Thomas Hellström
On Mon, 2023-10-09 at 01:32 +0200, Danilo Krummrich wrote:
> Add an abstraction layer between the drm_gpuva mappings of a
> particular
> drm_gem_object and this GEM object itself. The abstraction represents
> a
> combination of a drm_gem_object and drm_gpuvm. The drm_gem_object
> holds
> a list of
On Mon, 2023-10-09 at 01:32 +0200, Danilo Krummrich wrote:
> Add an abstraction layer between the drm_gpuva mappings of a
> particular
> drm_gem_object and this GEM object itself. The abstraction represents
> a
> combination of a drm_gem_object and drm_gpuvm. The drm_gem_object
> holds
> a list of
On Fri, 2023-10-13 at 13:51 +0200, Danilo Krummrich wrote:
> On 10/13/23 13:38, Thomas Hellström wrote:
> > On Mon, 2023-10-09 at 01:32 +0200, Danilo Krummrich wrote:
> > > Provide a common dma-resv for GEM objects not being used outside
> > > of
> > >
On Fri, 2023-10-13 at 14:04 +0200, Danilo Krummrich wrote:
> On 10/10/23 08:26, Thomas Hellström wrote:
> >
> > On 10/9/23 16:45, Danilo Krummrich wrote:
> > > On 10/9/23 15:36, Thomas Hellström wrote:
> > > >
> > > > On 10/9/23 01:32, Danilo Kr
Hi,
On Mon, 2023-10-09 at 01:32 +0200, Danilo Krummrich wrote:
> Currently the DRM GPUVM offers common infrastructure to track GPU VA
> allocations and mappings, generically connect GPU VA mappings to
> their
> backing buffers and perform more complex mapping operations on the
> GPU VA
> space.
>
On 10/13/23 15:37, Thomas Hellström wrote:
Hi,
On Mon, 2023-10-09 at 01:32 +0200, Danilo Krummrich wrote:
Currently the DRM GPUVM offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to
their
backing buffers and perform more complex
Hi,
On 10/17/23 11:58, Danilo Krummrich wrote:
On Fri, Oct 13, 2023 at 02:30:29PM +0200, Thomas Hellström wrote:
On Mon, 2023-10-09 at 01:32 +0200, Danilo Krummrich wrote:
Add an abstraction layer between the drm_gpuva mappings of a
particular
drm_gem_object and this GEM object itself. The
de/drm/drm_gpuvm.h
> @@ -29,6 +29,7 @@
> #include
> #include
>
> +#include
> #include
>
> struct drm_gpuvm;
> @@ -201,6 +202,11 @@ struct drm_gpuvm {
> */
> const char *name;
>
> + /**
> + * @drm: the &drm_device this VM lives in
> + */
Could a one-liner do?
/** */
> + struct drm_device *drm;
> +
> /**
> * @mm_start: start of the VA space
> */
> @@ -241,6 +247,7 @@ struct drm_gpuvm {
> };
>
> void drm_gpuvm_init(struct drm_gpuvm *gpuvm, const char *name,
> + struct drm_device *drm,
> u64 start_offset, u64 range,
> u64 reserve_offset, u64 reserve_range,
> const struct drm_gpuvm_ops *ops);
I figure Christian's commend can be addressed in a follow-up patch if
neeed.
Reviewed-by: Thomas Hellström
On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> Add an abstraction layer between the drm_gpuva mappings of a
> particular
> drm_gem_object and this GEM object itself. The abstraction represents
> a
> combination of a drm_gem_object and drm_gpuvm. The drm_gem_object
> holds
> a list of
On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> Add an abstraction layer between the drm_gpuva mappings of a
> particular
> drm_gem_object and this GEM object itself. The abstraction represents
> a
> combination of a drm_gem_object and drm_gpuvm. The drm_gem_object
> holds
> a list of
On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> Currently the DRM GPUVM offers common infrastructure to track GPU VA
> allocations and mappings, generically connect GPU VA mappings to
> their
> backing buffers and perform more complex mapping operations on the
> GPU VA
> space.
>
> Ho
On Tue, 2023-10-31 at 17:39 +0100, Danilo Krummrich wrote:
> On 10/31/23 12:25, Thomas Hellström wrote:
> > On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> > > Add an abstraction layer between the drm_gpuva mappings of a
> > > particular
> > > drm_g
On Tue, 2023-10-31 at 17:30 +0100, Danilo Krummrich wrote:
> On 10/31/23 12:45, Jani Nikula wrote:
> > On Tue, 31 Oct 2023, Thomas Hellström
> > wrote:
> > > On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> > > > + * Returns: a pointer to t
On Tue, 2023-10-31 at 17:41 +0100, Danilo Krummrich wrote:
> On 10/31/23 12:34, Thomas Hellström wrote:
> > On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> > > Currently the DRM GPUVM offers common infrastructure to track GPU
> > > VA
> > > a
Hi, Danilo,
On Tue, 2023-10-31 at 18:52 +0100, Danilo Krummrich wrote:
> On 10/31/23 17:45, Thomas Hellström wrote:
> > On Tue, 2023-10-31 at 17:39 +0100, Danilo Krummrich wrote:
> > > On 10/31/23 12:25, Thomas Hellström wrote:
> > > > On Mon, 2023-10-23 at 22:16
On Wed, 2023-11-01 at 10:41 +0100, Thomas Hellström wrote:
> Hi, Danilo,
>
> On Tue, 2023-10-31 at 18:52 +0100, Danilo Krummrich wrote:
> > On 10/31/23 17:45, Thomas Hellström wrote:
> > > On Tue, 2023-10-31 at 17:39 +0100, Danilo Krummrich wrote:
> > > > On 10
On Tue, 2023-10-31 at 18:38 +0100, Danilo Krummrich wrote:
> On 10/31/23 11:32, Thomas Hellström wrote:
> > On Mon, 2023-10-23 at 22:16 +0200, Danilo Krummrich wrote:
> > > Add an abstraction layer between the drm_gpuva mappings of a
> > > particular
> > > drm_g
On Wed, 2023-11-01 at 18:21 +0100, Danilo Krummrich wrote:
> On 11/1/23 17:38, Thomas Hellström wrote:
> > On Tue, 2023-10-31 at 18:38 +0100, Danilo Krummrich wrote:
> > > On 10/31/23 11:32, Thomas Hellström wrote:
> > > > On Mon, 2023-10-23 at 22:16 +0200, Danilo Kru
On Thu, 2023-11-02 at 00:31 +0100, Danilo Krummrich wrote:
> GPUVM provides common infrastructure to track external and evicted
> GEM
> objects as well as locking and validation helpers.
>
> Especially external and evicted object tracking is a huge improvement
> compared to the current brute force
alid userspace requests.
>
> Signed-off-by: Danilo Krummrich
Reviewed-by: Thomas Hellström
> ---
> drivers/gpu/drm/drm_gpuvm.c | 20 +---
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gpuvm.c
> b/drivers/gpu/drm/drm_gp
On Thu, 2023-11-02 at 00:30 +0100, Danilo Krummrich wrote:
> Drivers may use this function to validate userspace requests in
> advance,
> hence export it.
>
> Signed-off-by: Danilo Krummrich
Reviewed-by: Thomas Hellström
> ---
> drivers/gpu/drm/drm_gpuvm.c | 14
On Thu, 2023-11-02 at 00:31 +0100, Danilo Krummrich wrote:
> Implement reference counting for struct drm_gpuvm.
>
> Signed-off-by: Danilo Krummrich
Will port the Xe series over to check that it works properly and get
back with review on this one.
> ---
> drivers/gpu/drm/drm_gpuvm.c
and extend the structure to easily represent
> driver specific states of a BO for a certain GPUVM.
>
> The idea of this abstraction was taken from amdgpu, hence the credit
> for
> this idea goes to the developers of amdgpu.
>
> Cc: Christian König
> Revi
On Thu, 2023-11-02 at 00:31 +0100, Danilo Krummrich wrote:
> Implement reference counting for struct drm_gpuvm.
>
> Signed-off-by: Danilo Krummrich
> ---
> drivers/gpu/drm/drm_gpuvm.c | 44 +++-
> --
> drivers/gpu/drm/nouveau/nouveau_uvmm.c | 20 +---
> inc
*vm_bo = container_of(kref, struct
> drm_gpuvm_bo,
> + kref);
> + struct drm_gpuvm *gpuvm = vm_bo->vm;
> + const struct drm_gpuvm_ops *ops = gpuvm->ops;
> + struct drm_gem_object *obj = vm_bo->obj;
> + bool lock = !drm_gpuvm_resv_protected(gpuvm);
> +
> + if (!lock)
> + drm_gpuvm_resv_assert_held(gpuvm);
> +
> + drm_gem_gpuva_assert_lock_held(obj);
> + list_del(&vm_bo->list.entry.gem);
> +
> + if (ops && ops->vm_bo_free)
> + ops->vm_bo_free(vm_bo);
> + else
> + kfree(vm_bo);
> +
> + drm_gpuvm_put(gpuvm);
> + drm_gem_object_put(obj);
> +}
> +
> +/**
> + * drm_gpuvm_bo_put() - drop a struct drm_gpuvm_bo reference
> + * @vm_bo: the &drm_gpuvm_bo to release the reference of
> + *
> + * This releases a reference to @vm_bo.
> + *
> + * If the reference count drops to zero, the &gpuvm_bo is destroyed,
> which
> + * includes removing it from the GEMs gpuva list. Hence, if a call
> to this
> + * function can potentially let the reference count to zero the
> caller must
> + * hold the dma-resv or driver specific GEM gpuva lock.
Should Ideally document the context for this function as well, to avoid
future pitfalls and arguments, and also potentially a might_sleep().
Reviewed-by: Thomas Hellström
On Thu, 2023-11-02 at 18:32 +0100, Danilo Krummrich wrote:
> Hi Thomas,
>
> thanks for your timely response on that!
>
> On 11/2/23 18:09, Thomas Hellström wrote:
> > On Thu, 2023-11-02 at 00:31 +0100, Danilo Krummrich wrote:
> > > Implement reference
Danilo, Christian
On 11/6/23 17:42, Danilo Krummrich wrote:
On Mon, Nov 06, 2023 at 04:10:50PM +0100, Christian König wrote:
Am 06.11.23 um 15:11 schrieb Danilo Krummrich:
On Mon, Nov 06, 2023 at 02:05:13PM +0100, Christian König wrote:
Am 06.11.23 um 13:16 schrieb Danilo Krummrich:
[SNIP]
T
On 11/10/23 09:50, Christian König wrote:
Am 09.11.23 um 19:34 schrieb Danilo Krummrich:
On 11/9/23 17:03, Christian König wrote:
Am 09.11.23 um 16:50 schrieb Thomas Hellström:
[SNIP]
Did we get any resolution on this?
FWIW, my take on this is that it would be possible to get GPUVM to
On 11/8/23 01:12, Danilo Krummrich wrote:
Implement reference counting for struct drm_gpuvm.
Signed-off-by: Danilo Krummrich
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/drm_gpuvm.c| 56 +-
drivers/gpu/drm/nouveau/nouveau_uvmm.c | 20
On 11/10/23 11:42, Christian König wrote:
Am 10.11.23 um 10:39 schrieb Thomas Hellström:
[SNIP]
I was thinking more of the general design of a base-class that needs
to be refcounted. Say a driver vm that inherits from gpu-vm,
gem_object and yet another base-class that supplies its own
Hi, Christian
On Tue, 2024-01-09 at 08:47 +0100, Christian König wrote:
> Hi guys,
>
> I'm trying to make this functionality a bit more useful for years now
> since we multiple reports that behavior of drivers can be suboptimal
> when multiple placements be given.
>
> So basically instead of hac
On Tue, 2024-01-09 at 08:47 +0100, Christian König wrote:
> Only convert it to ENOMEM in ttm_bo_validate.
>
Could we have a more elaborate commit description here, (why is this
change needed)?
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 5 -
> 1 file changed, 4
propagated back to drivers as
well at some point, but then perhaps guarded with a flag in the
operation context.
In any case
Reviewed-by: Thomas Hellström
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a
Hi, Christian
Xe changes look good. Will send the series to xe ci to check for
regressions.
/Thomas
On 1/12/24 13:51, Christian König wrote:
From: Somalapuram Amaranath
Instead of a list of separate busy placement add flags which indicate
that a placement should only be used when there is
On 1/17/24 11:47, Thomas Hellström wrote:
Hi, Christian
Xe changes look good. Will send the series to xe ci to check for
regressions.
Hmm, there are some checkpatch warnings about author / SOB email mismatch,
But worserthere are some regressions in the dma-buf ktest (it tests
evicting of
On Fri, 2024-01-12 at 13:51 +0100, Christian König wrote:
> Previously we would never try to move a BO into the preferred
> placements
> when it ever landed in a busy placement since those were considered
> compatible.
>
> Rework the whole handling and finally unify the idle and busy
> handling.
>
On 1/17/24 13:27, Thomas Hellström wrote:
On 1/17/24 11:47, Thomas Hellström wrote:
Hi, Christian
Xe changes look good. Will send the series to xe ci to check for
regressions.
Hmm, there are some checkpatch warnings about author / SOB email
mismatch,
With those fixed, this patch is
On 1/18/24 15:24, Thomas Hellström wrote:
On Fri, 2024-01-12 at 13:51 +0100, Christian König wrote:
Previously we would never try to move a BO into the preferred
placements
when it ever landed in a busy placement since those were considered
compatible.
Rework the whole handling and finally
On Fri, 2024-01-26 at 16:22 -0600, Lucas De Marchi wrote:
> On Fri, Jan 26, 2024 at 04:16:58PM -0600, Lucas De Marchi wrote:
> > On Thu, Jan 18, 2024 at 05:38:16PM +0100, Thomas Hellström wrote:
> > >
> > > On 1/17/24 13:27, Thomas Hellström wrote:
> > >
Hi, Christian,
On Fri, 2024-01-26 at 15:09 +0100, Christian König wrote:
> Previously we would never try to move a BO into the preferred
> placements
> when it ever landed in a busy placement since those were considered
> compatible.
>
> Rework the whole handling and finally unify the idle and bu
On Sat, 2024-10-05 at 04:14 +, Matthew Brost wrote:
> On Fri, Oct 04, 2024 at 04:28:29PM +0200, Thomas Hellström wrote:
> > On Wed, 2024-10-02 at 14:54 +0200, Thomas Hellström wrote:
> > > On Wed, 2024-10-02 at 14:45 +0200, Christian König wrote:
> > > > Am 02
-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: spice-de...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: Zack Rusin
Cc:
Cc: Sui Jingfeng
Cc:
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 --
drivers
corrective action can be taken at
the driver level.
The first patch deals with a ttm_device_init() interface change,
The Second patch adds the actual functionality.
A follow-up will be posted for Xe once this is merged / backmerged.
Thomas Hellström (2):
drm/ttm: Change ttm_device_init to use a
corrective action can be taken at
the driver level.
Cc: Christian König
Cc: Matthew Brost
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
drivers/gpu/drm/ttm/ttm_device.c | 1 +
include/drm/ttm/ttm_device.h | 13 +
3 files changed, 15 insertions(+), 1
On Thu, 2024-10-03 at 00:28 -0400, Zack Rusin wrote:
> On Wed, Oct 2, 2024 at 8:24 AM Thomas Hellström
> wrote:
> >
> > The ttm_device_init funcition uses multiple bool arguments. That
> > means
> > readability in the caller becomes poor, and all callers need to
On Wed, 2024-10-02 at 14:54 +0200, Thomas Hellström wrote:
> On Wed, 2024-10-02 at 14:45 +0200, Christian König wrote:
> > Am 02.10.24 um 14:24 schrieb Thomas Hellström:
> > > The ttm_device_init funcition uses multiple bool arguments. That
> > > means
> > > re
On Wed, 2024-10-02 at 14:45 +0200, Christian König wrote:
> Am 02.10.24 um 14:24 schrieb Thomas Hellström:
> > The ttm_device_init funcition uses multiple bool arguments. That
> > means
> > readability in the caller becomes poor, and all callers need to
> > change if
&g
On Tue, 2025-02-04 at 09:26 -0400, Jason Gunthorpe wrote:
> On Tue, Feb 04, 2025 at 10:32:32AM +0100, Thomas Hellström wrote:
> >
>
> > 1) Existing users would never use the callback. They can still rely
> > on
> > the owner check, only if that fails we check for
On Tue, 2025-02-04 at 15:16 -0400, Jason Gunthorpe wrote:
> On Tue, Feb 04, 2025 at 03:29:48PM +0100, Thomas Hellström wrote:
> > On Tue, 2025-02-04 at 09:26 -0400, Jason Gunthorpe wrote:
> > > On Tue, Feb 04, 2025 at 10:32:32AM +0100, Thomas Hellström wrote:
> > > &g
1 - 100 of 105 matches
Mail list logo
