<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 19, 2018 at 3:27 PM, Christian König <span dir="ltr"><<a href="mailto:christian.koenig@amd.com" target="_blank">christian.koenig@amd.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think that the consensus with Alex and me is that we should avoid exactly that.<br>
<br>
Overriding the preferred domain in the kernel is a no-go for that patch set, so please implement the discussed changes in Mesa.<br></blockquote><div><br></div><div>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.</div><div><br></div><div></div><div>Marek<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Christian.<div class="m_-5064514954187404218HOEnZb"><div class="m_-5064514954187404218h5"><br>
<br>
Am 19.03.2018 um 20:22 schrieb Li, Samuel:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree with Marek/Michel: since kernel sets the domain before scanning out, it shall update the preferred domain here too.<br>
<br>
Regards,<br>
Samuel Li<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----Original Message-----<br>
From: Koenig, Christian<br>
Sent: Thursday, March 08, 2018 4:07 AM<br>
To: Michel Dänzer <<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>>; Li, Samuel<br>
<<a href="mailto:Samuel.Li@amd.com" target="_blank">Samuel.Li@amd.com</a>>; Alex Deucher <<a href="mailto:alexdeucher@gmail.com" target="_blank">alexdeucher@gmail.com</a>><br>
Cc: amd-gfx list <<a href="mailto:amd-gfx@lists.freedesktop.org" target="_blank">amd-gfx@lists.freedesktop.org</a><wbr>><br>
Subject: Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support<br>
<br>
Am 08.03.2018 um 09:35 schrieb Michel Dänzer:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2018-03-07 10:47 AM, Christian König wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 07.03.2018 um 09:42 schrieb Michel Dänzer:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2018-03-06 07:23 PM, Christian König wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
E.g. the last time I tested it placing things into GTT still<br>
resulted in quite a performance penalty for rendering.<br>
</blockquote>
FWIW, I think the penalty is most likely IOMMU related. Last time I<br>
tested, I couldn't measure a big difference with IOMMU disabled.<br>
</blockquote>
No, the penalty I'm talking about came from the ping/pong we did with<br>
the scanout buffers.<br>
<br>
See when I tested this the DDX and Mesa where unmodified, so both<br>
still assumed VRAM as placement for scanout BOs, but the kernel<br>
forced scanout BOs into GTT for testing.<br>
<br>
So what happened was that on scanout we moved the VRAM BO to GTT<br>
</blockquote></blockquote>
and<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
after unpinning it on the first command submission which used the BO<br>
we moved it back to VRAM again.<br>
</blockquote>
In the meantime, I've had the same idea as Marek: Can't the kernel<br>
driver simply change the BO's preferred domain to GTT when scanning<br>
out from it? Then it won't move back to VRAM.<br>
</blockquote>
Yes, I've considered this as well.<br>
<br>
But I think making the decision in Mesa is the cleaner approach.<br>
<br>
E.g. so far we only override the placement decision of userspace for two<br>
reasons:<br>
1. We where running out of memory in VRAM.<br>
2. We have a hardware restriction which makes VRAM usage mandatory.<br>
<br>
And even then we never adjust the placement permanently, we just<br>
temporary moved the buffer where it was needed and moved it back after<br>
the operation completed.<br>
<br>
Additional to that Mesa might want to set even more flags and/or changes<br>
it's behavior. E.g. use a tilling mode which both importer and export in an<br>
A+A laptop understands etc...<br>
<br>
Regards,<br>
Christian.<br>
</blockquote></blockquote>
<br>
______________________________<wbr>_________________<br>
amd-gfx mailing list<br>
<a href="mailto:amd-gfx@lists.freedesktop.org" target="_blank">amd-gfx@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/amd-gfx" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/amd-gfx</a><br>
</div></div></blockquote></div><br></div></div>