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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] > *Sent:* Monday, March 19, 2018 3:39 PM > *To:* Koenig, Christian > *Cc:* Li, Samuel ; Michel Dänzer > ; 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ö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. > > 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 > > > > _______________________________________________ > amd-gfx mailing list > amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx