Hi Sam, no that is seriously a no-go. The placement decision is done my userspace, not the kernel. The only time the kernel overrides that decision is a) hardware requirements (for example old UVD on AGP systems) and b) memory pressure. We are have actually pushed quite hard on avoiding and removing places where the kernel overrides the placement decision of userspace, so I don't think we should add any new ones. Regards, Christian. Am 19.03.2018 um 20:58 schrieb Li, Samuel: > > Alex, > > I assume you are talking the three scenarios here, 1)VRAM, 2)GTT, > 3)VRAM/GTT. > > 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 â?¦) > > Regards, > > Samuel Li > > *From:*Deucher, Alexander > *Sent:* Monday, March 19, 2018 3:54 PM > *To:* Li, Samuel <Samuel.Li at amd.com>; Koenig, Christian > <Christian.Koenig at amd.com>; Marek Olšák <maraeo at gmail.com> > *Cc:* Alex Deucher <alexdeucher at gmail.com>; Michel Dänzer > <michel at daenzer.net>; amd-gfx list <amd-gfx at lists.freedesktop.org> > *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 forcing it in the kernel. > > Alex > > ------------------------------------------------------------------------ > > *From:*amd-gfx <amd-gfx-bounces at lists.freedesktop.org > <mailto:amd-gfx-bounces at lists.freedesktop.org>> on behalf of Li, > Samuel <Samuel.Li at amd.com <mailto:Samuel.Li at amd.com>> > *Sent:* Monday, March 19, 2018 3:50:34 PM > *To:* Koenig, Christian; Marek Olšák > *Cc:* Alex Deucher; Michel Dänzer; amd-gfx list > *Subject:* RE: [PATCH 1/2] drm/amdgpu: Enable scatter gather display > support > > Christian, > > You misunderstood Alexâ??s 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. > Since preferred domain can solve the ping-pong issue, it shall address > his concern here. > > Regards, > > Samuel Li > > *From:*Christian König [mailto:ckoenig.leichtzumerken at gmail.com] > *Sent:* Monday, March 19, 2018 3:45 PM > *To:* Li, Samuel <Samuel.Li at amd.com <mailto:Samuel.Li at amd.com>>; Marek > Olšák <maraeo at gmail.com <mailto:maraeo at gmail.com>>; Koenig, Christian > <Christian.Koenig at amd.com <mailto:Christian.Koenig at amd.com>> > *Cc:* Alex Deucher <alexdeucher at gmail.com > <mailto:alexdeucher at gmail.com>>; Michel Dänzer <michel at daenzer.net > <mailto:michel at daenzer.net>>; amd-gfx list > <amd-gfx at lists.freedesktop.org <mailto:amd-gfx at lists.freedesktop.org>> > *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 > kernel is a serious NAK from my side as well. > > Please implement the necessary bits in Mesa, shouldn't be more than a > few lines 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 exactly that. > Christian, Alexâ??s concern is about ping-pong, not about the > preferred domain. > > Regards, > > Samuel Li > > *From:*Marek Olšák [mailto:maraeo at gmail.com] > *Sent:* Monday, March 19, 2018 3:39 PM > *To:* Koenig, Christian <Christian.Koenig at amd.com> > <mailto:Christian.Koenig at amd.com> > *Cc:* Li, Samuel <Samuel.Li at amd.com> <mailto:Samuel.Li at amd.com>; > Michel Dänzer <michel at daenzer.net> <mailto:michel at daenzer.net>; > Alex Deucher <alexdeucher at gmail.com> > <mailto:alexdeucher at gmail.com>; amd-gfx list > <amd-gfx at lists.freedesktop.org> <mailto:amd-gfx at lists.freedesktop.org> > *Subject:* Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather > display support > > On Mon, Mar 19, 2018 at 3:27 PM, Christian König > <christian.koenig at amd.com <mailto:christian.koenig at amd.com>> 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. > > 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 at daenzer.net > <mailto:michel at daenzer.net>>; Li, Samuel > <Samuel.Li at amd.com <mailto:Samuel.Li at amd.com>>; Alex > Deucher <alexdeucher at gmail.com > <mailto:alexdeucher at gmail.com>> > Cc: amd-gfx list <amd-gfx at lists.freedesktop.org > <mailto:amd-gfx at lists.freedesktop.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 at lists.freedesktop.org > <mailto:amd-gfx at lists.freedesktop.org> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > > > _______________________________________________ > > amd-gfx mailing list > > amd-gfx at lists.freedesktop.org <mailto:amd-gfx at lists.freedesktop.org> > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180319/74e4aa9e/attachment-0001.html>
