; Wentland, Harry
Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
Mhm, I'm not aware of any let over pointer between TTM and GEM and we
worked quite hard on reducing the size of the amdgpu_bo, so another
extra pointer just for that corner case would suck quite
/12] drm: Add dummy page per device or
GEM object
Mhm, I'm not aware of any let over pointer between TTM and GEM
and we
worked quite hard on reducing the size of the amdgpu_bo, so another
extra pointer just for that corner case would suck quite a bit.
We have a ton of other pointers in s
...@lists.freedesktop.org ;
daniel.vet...@ffwll.ch ; r...@kernel.org
; l.st...@pengutronix.de ;
yuq...@gmail.com ; e...@anholt.net ;
Deucher, Alexander ;
gre...@linuxfoundation.org ;
ppaala...@gmail.com ; Wentland, Harry
Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
So - basically allocate the page and pass it as void* pointer to drmm_add_action
with a release function which will do the free page, right ?
Andrey
On 1/12/21 4:10 AM, Daniel Vetter wrote:
drm_add_action_or_reset (for better control flow) has both a void * data
and a cleanup function (and it i
; r...@kernel.org ; l.st...@pengutronix.de
; yuq...@gmail.com ; e...@anholt.net ; Deucher, Alexander
; gre...@linuxfoundation.org ; ppaala...@gmail.com
; Wentland, Harry
Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
Mhm, I'm not aware of any let over po
>> dri-de...@lists.freedesktop.org ;
> >> daniel.vet...@ffwll.ch ; r...@kernel.org
> >> ; l.st...@pengutronix.de ;
> >> yuq...@gmail.com ; e...@anholt.net ;
> >> Deucher, Alexander ; gre...@linuxfoundation.org
> >> ; ppaala...@gmail.com ;
&
; ; l.st...@pengutronix.de ;
> > > > yuq...@gmail.com ; e...@anholt.net ;
> > > > Deucher, Alexander ;
> > > > gre...@linuxfoundation.org ;
> > > > ppaala...@gmail.com ; Wentland, Harry
> > > >
> > > > Subject: Re: [PATCH v3 01/12] drm
Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
Mhm, I'm not aware of any let over pointer between TTM and GEM and we
worked quite hard on reducing the size of the amdgpu_bo, so another
extra pointer just for that corner case would suck quite a bit.
We have a t
...@linuxfoundation.org ; ppaala...@gmail.com
; Wentland, Harry
Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
Mhm, I'm not aware of any let over pointer between TTM and GEM and we
worked quite hard on reducing the size of the amdgpu_bo, so another
extra pointer jus
...@linuxfoundation.org ; ppaala...@gmail.com
; Wentland, Harry
Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
Mhm, I'm not aware of any let over pointer between TTM and GEM and we
worked quite hard on reducing the size of the amdgpu_bo, so another
extra pointer jus
ernel.org
> > ; l.st...@pengutronix.de ;
> > yuq...@gmail.com ; e...@anholt.net ;
> > Deucher, Alexander ; gre...@linuxfoundation.org
> > ; ppaala...@gmail.com ;
> > Wentland, Harry
> > Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
> &g
ala...@gmail.com ;
> Wentland, Harry
> Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
>
> Mhm, I'm not aware of any let over pointer between TTM and GEM and we
> worked quite hard on reducing the size of the amdgpu_bo, so another
> extra poin
...@ffwll.ch ; r...@kernel.org
; l.st...@pengutronix.de ;
yuq...@gmail.com ; e...@anholt.net ;
Deucher, Alexander ; gre...@linuxfoundation.org
; ppaala...@gmail.com ;
Wentland, Harry
Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
Mhm, I'm not aware of any let
Mhm, I'm not aware of any let over pointer between TTM and GEM and we
worked quite hard on reducing the size of the amdgpu_bo, so another
extra pointer just for that corner case would suck quite a bit.
Christian.
Am 08.01.21 um 15:46 schrieb Andrey Grodzovsky:
Daniel had some objections to thi
Daniel had some objections to this (see bellow) and so I guess I need you both
to agree on the approach before I proceed.
Andrey
On 1/8/21 9:33 AM, Christian König wrote:
Am 08.01.21 um 15:26 schrieb Andrey Grodzovsky:
Hey Christian, just a ping.
Was there any question for me here?
As far
Am 08.01.21 um 15:26 schrieb Andrey Grodzovsky:
Hey Christian, just a ping.
Was there any question for me here?
As far as I can see the best approach would still be to fill the VMA
with a single dummy page and avoid pointers in the GEM object.
Christian.
Andrey
On 1/7/21 11:37 AM, Andre
Hey Christian, just a ping.
Andrey
On 1/7/21 11:37 AM, Andrey Grodzovsky wrote:
On 1/7/21 11:30 AM, Daniel Vetter wrote:
On Thu, Jan 07, 2021 at 11:26:52AM -0500, Andrey Grodzovsky wrote:
On 1/7/21 11:21 AM, Daniel Vetter wrote:
On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wr
On 1/7/21 11:30 AM, Daniel Vetter wrote:
On Thu, Jan 07, 2021 at 11:26:52AM -0500, Andrey Grodzovsky wrote:
On 1/7/21 11:21 AM, Daniel Vetter wrote:
On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wrote:
On 11/23/20 3:01 AM, Christian König wrote:
Am 23.11.20 um 05:54 schrieb And
On Thu, Jan 07, 2021 at 11:26:52AM -0500, Andrey Grodzovsky wrote:
>
> On 1/7/21 11:21 AM, Daniel Vetter wrote:
> > On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wrote:
> > > On 11/23/20 3:01 AM, Christian König wrote:
> > > > Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky:
> > > > >
Typo Correction bellow
On 1/7/21 11:26 AM, Andrey Grodzovsky wrote:
Or is the idea to save the struct page * pointer? That feels a bit like
over-optimizing stuff. Better to have a simple implementation first and
then tune it if (and only if) any part of it becomes a problem for normal
usage.
On 1/7/21 11:21 AM, Daniel Vetter wrote:
On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wrote:
On 11/23/20 3:01 AM, Christian König wrote:
Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky:
On 11/21/20 9:15 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wrote:
>
> On 11/23/20 3:01 AM, Christian König wrote:
> > Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky:
> > >
> > > On 11/21/20 9:15 AM, Christian König wrote:
> > > > Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
> > > > > Will be
On 11/23/20 3:01 AM, Christian König wrote:
Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky:
On 11/21/20 9:15 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Uff, one page for each exporte
Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky:
On 11/21/20 9:15 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Uff, one page for each exported DMA-buf? That's not something we can do.
We
On 11/21/20 9:15 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Uff, one page for each exported DMA-buf? That's not something we can do.
We need to find a different approach here.
Can't w
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Uff, one page for each exported DMA-buf? That's not something we can do.
We need to find a different approach here.
Can't we call alloc_page() on each fault and link the
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_file.c | 8
drivers/gpu/drm/drm_prime.c | 10 ++
include/drm/drm_file.h | 2 ++
include/drm/drm_gem.h | 2 ++
4 files changed, 22 i
27 matches
Mail list logo
