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. 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>; Li, Samuel >> <Samuel.Li at amd.com>; Alex Deucher <alexdeucher at gmail.com> >> Cc: amd-gfx list <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.
