From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Deucher, Alexander" Subject: Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support Date: Mon, 19 Mar 2018 20:13:05 +0000 Message-ID: References: <1520033110-29964-1-git-send-email-Samuel.Li@amd.com> <898d3377-ee2b-a33d-dbff-b4cb692d650d@amd.com> <6febc0d1-0171-3cc1-ff22-69aa4ef36036@daenzer.net> <12178e4c-6b48-2c3b-9970-2ca30624a5bb@gmail.com> <29dba5ab-f4f3-551b-ec94-2d6433e8aa21@daenzer.net> <1141c511-597e-c81b-6ffd-800ff846f2c1@gmail.com> <1b643a78-d86a-b3bf-5f92-089a43201dd5@daenzer.net> <06e9160c-b4d4-6c3a-ff9f-04b40b94c7a0@amd.com> <2c995c37-0d0b-8fde-0118-57d7a62630ef@amd.com> , , Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1097510139==" Return-path: In-Reply-To: Content-Language: en-US List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "amd-gfx" To: "Li, Samuel" , "Koenig, Christian" , =?Windows-1252?Q?Marek_Ol=9A=E1k?= Cc: Alex Deucher , =?Windows-1252?Q?Michel_D=E4nzer?= , amd-gfx list --===============1097510139== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BN6PR12MB180952A68A8AF256197D1177F7D40BN6PR12MB1809namp_" --_000_BN6PR12MB180952A68A8AF256197D1177F7D40BN6PR12MB1809namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'm not sure what you mean by the 3 scenarios. Generally userspace selects= what domains it wants a buffer to be in, vram, gtt, or both (don't care). = I'd rather not have the kernel second guess the UMDs if we can help it. I= 'd rather leave the kernel for cases where we have to force things due to h= w bugs, or hw restrictions, etc. If we force all display buffers to be in = gtt in the kernel, we have not excluded the possibility of ever setting dis= plays anywhere else without a kernel update. E.g., to my earlier point, th= ere may be cases where it is advantageous to put display buffers in vram ev= en if s/g display is supported. That was the point I was trying to make ab= out user mode selecting the domain (vram of gtt or vram|gtt). Say you have= a board with 2 GB of ram and 1 GB is carved out for "vram". In that case,= it would make sense to put the buffer in vram because otherwise you are wa= sting a comparatively scarce resource. Alex ________________________________ From: Li, Samuel Sent: Monday, March 19, 2018 3:58:52 PM To: Deucher, Alexander; Koenig, Christian; Marek Ol=9A=E1k Cc: Alex Deucher; Michel D=E4nzer; amd-gfx list Subject: RE: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support Alex, I assume you are talking the three scenarios here, 1)VRAM, 2)GTT, 3)VRAM/GT= T. But kernel will need the decision too(amdgpufb). I think it shall be better= to do it in kernel, instead of different clients(mesa, ddx, kernel =85) Regards, Samuel Li From: Deucher, Alexander Sent: Monday, March 19, 2018 3:54 PM To: Li, Samuel ; Koenig, Christian ; Marek Ol=9A=E1k Cc: Alex Deucher ; Michel D=E4nzer ; amd-gfx list Subject: Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support My personal preference is still to plumb this through to mesa rather than f= orcing it in the kernel. Alex ________________________________ From: amd-gfx > on behalf of Li, Samuel > Sent: Monday, March 19, 2018 3:50:34 PM To: Koenig, Christian; Marek Ol=9A=E1k Cc: Alex Deucher; Michel D=E4nzer; amd-gfx list Subject: RE: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support Christian, You misunderstood Alex=92s comments, >Regardless of which scenarios we need to support, I think we also need >to really plumb this through to mesa however since user space is who >ultimately requests the location. Overriding it in the kernel gets >tricky and can lead to ping-ponging as others have noted. Better to Here Alex mentioned the scenarios is 1)VRAM, 2)GTT, 3)VRAM/GTT. His concern is this might cause ping-pong, not about preferred domain. Sinc= e preferred domain can solve the ping-pong issue, it shall address his conc= ern here. Regards, Samuel Li From: Christian K=F6nig [mailto:ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] Sent: Monday, March 19, 2018 3:45 PM To: Li, Samuel >; Marek Ol=9A= =E1k >; Koenig, Christian > Cc: Alex Deucher >; Mic= hel D=E4nzer >; amd-gfx list = > Subject: Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support Quoting Alex: Regardless of which scenarios we need to support, I think we also need to really plumb this through to mesa however since user space is who ultimately requests the location. Overriding it in the kernel gets tricky and can lead to ping-ponging as others have noted. Better to have user space know what chips support it or not and request display buffers in GTT or VRAM from the start. And I completely agree with Alex here. So overriding the domain in the kern= el is a serious NAK from my side as well. Please implement the necessary bits in Mesa, shouldn't be more than a few l= ines of code anyway. Regards, Christian. Am 19.03.2018 um 20:42 schrieb Li, Samuel: Agreed. >I think that the consensus with Alex and me is that we should avoid exactl= y that. Christian, Alex=92s concern is about ping-pong, not about the preferred dom= ain. Regards, Samuel Li From: Marek Ol=9A=E1k [mailto:maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] Sent: Monday, March 19, 2018 3:39 PM To: Koenig, Christian Cc: Li, Samuel ; Michel D=E4nz= er ; Alex Deucher ; amd-gfx list Subject: Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support On Mon, Mar 19, 2018 at 3:27 PM, Christian K=F6nig > wrote: I think that the consensus with Alex and me is that we should avoid exactly= that. Overriding the preferred domain in the kernel is a no-go for that patch set= , so please implement the discussed changes in Mesa. I don't see how Mesa can make a smarter decision than the kernel. If you ov= erwrite the preferred domain of the buffer in the kernel, there will be no = ping-ponging between domains. Mesa never changes the initial preferred doma= in. Marek Regards, Christian. Am 19.03.2018 um 20:22 schrieb Li, Samuel: I agree with Marek/Michel: since kernel sets the domain before scanning out= , it shall update the preferred domain here too. Regards, Samuel Li -----Original Message----- From: Koenig, Christian Sent: Thursday, March 08, 2018 4:07 AM To: Michel D=E4nzer >; Li, Sa= muel >; Alex Deucher > Cc: amd-gfx list > Subject: Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support Am 08.03.2018 um 09:35 schrieb Michel D=E4nzer: On 2018-03-07 10:47 AM, Christian K=F6nig wrote: Am 07.03.2018 um 09:42 schrieb Michel D=E4nzer: On 2018-03-06 07:23 PM, Christian K=F6nig wrote: E.g. the last time I tested it placing things into GTT still resulted in quite a performance penalty for rendering. FWIW, I think the penalty is most likely IOMMU related. Last time I tested, I couldn't measure a big difference with IOMMU disabled. No, the penalty I'm talking about came from the ping/pong we did with the scanout buffers. See when I tested this the DDX and Mesa where unmodified, so both still assumed VRAM as placement for scanout BOs, but the kernel forced scanout BOs into GTT for testing. So what happened was that on scanout we moved the VRAM BO to GTT and after unpinning it on the first command submission which used the BO we moved it back to VRAM again. In the meantime, I've had the same idea as Marek: Can't the kernel driver simply change the BO's preferred domain to GTT when scanning out from it? Then it won't move back to VRAM. Yes, I've considered this as well. But I think making the decision in Mesa is the cleaner approach. E.g. so far we only override the placement decision of userspace for two reasons: 1. We where running out of memory in VRAM. 2. We have a hardware restriction which makes VRAM usage mandatory. And even then we never adjust the placement permanently, we just temporary moved the buffer where it was needed and moved it back after the operation completed. Additional to that Mesa might want to set even more flags and/or changes it's behavior. E.g. use a tilling mode which both importer and export in an A+A laptop understands etc... Regards, Christian. _______________________________________________ amd-gfx mailing list amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx --_000_BN6PR12MB180952A68A8AF256197D1177F7D40BN6PR12MB1809namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I'm not sure what you mean by the= 3 scenarios.  Generally userspace selects what domains it wants a buf= fer to be in, vram, gtt, or both (don't care).  I'd rather not ha= ve the kernel second guess the UMDs if we can help it.  I'd rather leave the kernel for cases where we have to force thi= ngs due to hw bugs, or hw restrictions, etc.  If we force all display = buffers to be in gtt in the kernel, we have not excluded the possibility of= ever setting displays anywhere else without a kernel update.  E.g., to my earlier point, there may be cases where= it is advantageous to put display buffers in vram even if s/g display is s= upported.  That was the point I was trying to make about user mode sel= ecting the domain (vram of gtt or vram|gtt).  Say you have a board with 2 GB of ram and 1 GB is carved out for "vra= m".  In that case, it would make sense to put the buffer in vram = because otherwise you are wasting a comparatively scarce resource.


Alex

From: Li, Samuel
Sent: Monday, March 19, 2018 3:58:52 PM
To: Deucher, Alexander; Koenig, Christian; Marek Ol=9A=E1k
Cc: Alex Deucher; Michel D=E4nzer; amd-gfx list
Subject: RE: [PATCH 1/2] drm/amdgpu: Enable scatter gather display s= upport
 

Alex,

 

I assume you are talking the thre= e scenarios here, 1)VRAM, 2)GTT, 3)VRAM/GTT.<= /span>

But kernel will need the decision= too(amdgpufb). I think it shall be better to do it in kernel, instead of d= ifferent clients(mesa, ddx, kernel =85)

 

Regards,

Samuel Li

 

From: Deucher, Alexander
Sent: Monday, March 19, 2018 3:54 PM
To: Li, Samuel <Samuel.Li-5C7GfCeVMHo@public.gmane.org>; Koenig, Christian <Chri= stian.Koenig-5C7GfCeVMHo@public.gmane.org>; Marek Ol=9A=E1k <maraeo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Alex Deucher <alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>; Michel D=E4nzer <= michel-otUistvHUpPR7s880joybQ@public.gmane.org>; amd-gfx list <amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org><= br> Subject: Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display s= upport

 

= My personal preference is still to plumb this through to mesa rather than f= orcing it in the kernel.

=  

= Alex

From: = amd-gfx <amd-gf= x-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf of Li, Samuel <Samuel.Li= @amd.com>
Sent: Monday, March 19, 2018 3:50:34 PM
To: Koenig, Christian; Marek Ol=9A=E1k
Cc: Alex Deucher; Michel D=E4nzer; amd-gfx list
Subject: RE: [PATCH 1/2] drm/amdgpu: Enable scatter gather display s= upport

 

Chris= tian,

 = ;

You m= isunderstood Alex=92s comments,

 = ;

>Regardless of which scenarios we need t=
o support, I think we also need
>to really plumb this through to mesa ho=
wever since user space is who
>ultimately requests the location. =
 Overriding it in the kernel gets
>tricky and can lead to ping-ponging as =
others have noted.  Better to

 = ;

Here = Alex mentioned the scenarios is 1)VRAM, 2)GTT, 3)VRAM/GTT.

His c= oncern is this might cause ping-pong, not about preferred domain. Since pre= ferred domain can solve the ping-pong issue, it shall address his concern here.

 = ;

Regar= ds,

Samue= l Li

 = ;

 

= Quoting Alex:

Regardless of which scenarios we need to su=
pport, I think we also need
to really plumb this through to mesa howeve=
r since user space is who
ultimately requests the location.  Ove=
rriding it in the kernel gets
tricky and can lead to ping-ponging as othe=
rs have noted.  Better to
have user space know what chips support it =
or not and request display
buffers in GTT or VRAM from the start.

And I completely agree= with Alex here. So overriding the domain in the kernel is a serious NAK fr= om my side as well.

Please implement the necessary bits in Mesa, shouldn't be more than a few l= ines of code anyway.

Regards,
Christian.

Am 19.03.2018 um 20:42 schrieb Li, Samuel:

Agree= d.

 = ;

= >I think that the consensus with Alex and me is that we should avoid exa= ctly that.
Christian, Alex=92s concern is about ping-pong, not about the preferred dom= ain.

Regar= ds,

Samue= l Li

 = ;

From:<= span style=3D"font-size:11.0pt; font-family:"Calibri",sans-serif"= > Marek Ol=9A=E1k [mailto:maraeo@gmail.= com]
Sent: Monday, March 19, 2018 3:39 PM
To: Koenig, Christian &l= t;Christian.Koenig-5C7GfCeVMHo@public.gmane.org>
Cc: Li, Samuel <Samuel.Li@am= d.com>; Michel D=E4nzer <michel-otUistvHUpPR7s880joybQ@public.gmane.org>; Alex = Deucher <alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>; amd-gfx list <amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display s= upport

 

On Mon, Mar 19, 2018 a= t 3:27 PM, Christian K=F6nig <christian.koenig-5C7GfCeVMHo@public.gmane.org> wrote:

I think that the conse= nsus with Alex and me is that we should avoid exactly that.

Overriding the preferred domain in the kernel is a no-go for that patch set= , so please implement the discussed changes in Mesa.

 

I don't see how Mesa c= an make a smarter decision than the kernel. If you overwrite the preferred = domain of the buffer in the kernel, there will be no ping-ponging between d= omains. Mesa never changes the initial preferred domain.

 

Marek

 

 


Regards,
Christian.



Am 19.03.2018 um 20:22 schrieb Li, Samuel:

= I agree with Marek/Michel: since kernel sets the domain before scanning out= , it shall update the preferred domain here too.

Regards,
Samuel Li

-----Original Message-= ----
From: Koenig, Christian
Sent: Thursday, March 08, 2018 4:07 AM
To: Michel D=E4nzer <michel-otUistvHUpPR7s880joybQ@public.gmane.org>; Li, Samuel
<Samuel.Li-urvtwAKJhsc@public.gmane.org= m>; Alex Deucher <alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: amd-gfx list <amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support<= br>
Am 08.03.2018 um 09:35 schrieb Michel D=E4nzer:

On 2018-03-07 10:47 AM= , Christian K=F6nig wrote:

Am 07.03.2018 um 09:42= schrieb Michel D=E4nzer:

= On 2018-03-06 07:23 PM, Christian K=F6nig wrote:

E.g. the last time I t= ested it placing things into GTT still
resulted in quite a performance penalty for rendering.

FWIW, I think the pena= lty is most likely IOMMU related. Last time I
tested, I couldn't measure a big difference with IOMMU disabled.

No, the penalty I'm ta= lking about came from the ping/pong we did with
the scanout buffers.

See when I tested this the DDX and Mesa where unmodified, so both
still assumed VRAM as placement for scanout BOs, but the kernel
forced scanout BOs into GTT for testing.

So what happened was that on scanout we moved the VRAM BO to GTT

and

after unpinning it on = the first command submission which used the BO
we moved it back to VRAM again.

In the meantime, I've = had the same idea as Marek: Can't the kernel
driver simply change the BO's preferred domain to GTT when scanning
out from it? Then it won't move back to VRAM.

Yes, I've considered t= his as well.

But I think making the decision in Mesa is the cleaner approach.

E.g. so far we only override the placement decision of userspace for two reasons:
1. We where running out of memory in VRAM.
2. We have a hardware restriction which makes VRAM usage mandatory.

And even then we never adjust the placement permanently, we just
temporary moved the buffer where it was needed and moved it back after
the operation completed.

Additional to that Mesa might want to set even more flags and/or changes it's behavior. E.g. use a tilling mode which both importer and export in an=
A+A laptop understands etc...

Regards,
Christian.


_______________________________________________
amd-gfx mailing list
amd-gfx@= lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

 

= 

___________________________________________=
____
amd-gfx mailing list
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
https://lists.freedesktop.org/mailman/listinfo/amd-=
gfx

 

--_000_BN6PR12MB180952A68A8AF256197D1177F7D40BN6PR12MB1809namp_-- --===============1097510139== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KYW1kLWdmeCBt YWlsaW5nIGxpc3QKYW1kLWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5m cmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9hbWQtZ2Z4Cg== --===============1097510139==--