From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Christian_K=c3=b6nig?= Subject: Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support Date: Mon, 19 Mar 2018 20:41:56 +0100 Message-ID: <05512033-177f-f960-50bb-5db63adb8b36@amd.com> 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="===============1363364177==" 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: =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= Cc: Alex Deucher , =?UTF-8?Q?Michel_D=c3=a4nzer?= , amd-gfx list , "Li, Samuel" This is a multi-part message in MIME format. --===============1363364177== Content-Type: multipart/alternative; boundary="------------9E839B0C481E4268978555FD" Content-Language: en-US This is a multi-part message in MIME format. --------------9E839B0C481E4268978555FD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Am 19.03.2018 um 20:39 schrieb Marek Olšák: > On Mon, Mar 19, 2018 at 3:27 PM, Christian König > > 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 overwrite the preferred domain of the buffer in the kernel, there > will be no ping-ponging between domains. Mesa never changes the > initial preferred domain. Yeah, but it can set the initial domain based on what it knows how the buffer will be used. E.g. when scanout from GTT is supported we would like to always set the initial domain as GTT instead of VRAM. Christian. > > 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änzer >; Li, Samuel > >; 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änzer: > > On 2018-03-07 10:47 AM, Christian König wrote: > > Am 07.03.2018 um 09:42 schrieb Michel Dänzer: > > On 2018-03-06 07:23 PM, Christian König 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 > > > --------------9E839B0C481E4268978555FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 19.03.2018 um 20:39 schrieb Marek Olšák:
On Mon, Mar 19, 2018 at 3:27 PM, Christian König <christian.koenig-5C7GfCeVMHo@public.gmane.org> 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 overwrite the preferred domain of the buffer in the kernel, there will be no ping-ponging between domains. Mesa never changes the initial preferred domain.

Yeah, but it can set the initial domain based on what it knows how the buffer will be used.

E.g. when scanout from GTT is supported we would like to always set the initial domain as GTT instead of VRAM.

Christian.


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änzer <michel-otUistvHUpPR7s880joybQ@public.gmane.org>; Li, Samuel
<Samuel.Li-5C7GfCeVMHo@public.gmane.org>; 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

Am 08.03.2018 um 09:35 schrieb Michel Dänzer:
On 2018-03-07 10:47 AM, Christian König wrote:
Am 07.03.2018 um 09:42 schrieb Michel Dänzer:
On 2018-03-06 07:23 PM, Christian König 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


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