<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 20, 2018 at 9:55 AM, Christian König <span dir="ltr"><<a href="mailto:ckoenig.leichtzumerken@gmail.com" target="_blank">ckoenig.leichtzumerken@gmail.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="m_-3838486020630618689m_8572536124089128592moz-cite-prefix">Yes, exactly. And if I remember
correctly Mesa used to always set GTT as fallback on APUs,
correct?<br></div></div></blockquote><div><br></div><div>"used to" is the key part. Mesa doesn't force GTT on APUs anymore. It expects that the combination of BO priorities and BO move throttling will result in optimal BO placements over time.<br><br></div><div>Marek<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div class="m_-3838486020630618689m_8572536124089128592moz-cite-prefix">
<br>
The problem seems to be that this fallback isn't set for
displayable BOs.<br>
<br>
So what needs to be done is to just enable this fallback for
displayable BOs as well if the kernel can handle it.<span class="m_-3838486020630618689HOEnZb"><font color="#888888"><br>
<br>
Christian.</font></span><div><div class="m_-3838486020630618689h5"><br>
<br>
Am 20.03.2018 um 00:01 schrieb Marek Olšák:<br>
</div></div></div>
<blockquote type="cite"><div><div class="m_-3838486020630618689h5">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">In theory, Mesa doesn't have to do
anything. It can continue setting VRAM and if the kernel has
to put a display buffer into GTT, it doesn't matter (for
Mesa). Whether the VRAM placement is really used is largely
determined by BO priorities.<br>
</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">The way I understand scather/gather
is that it only allows the GTT placement. It doesn't force
the GTT placement. Mesa also doesn't force the GTT
placement.<br>
</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">Marek<br>
</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">On Mon, Mar 19, 2018 at 5:12 PM, Alex
Deucher <span dir="ltr"><<a href="mailto:alexdeucher@gmail.com" target="_blank">alexdeucher@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On
Mon, Mar 19, 2018 at 4:29 PM, Li, Samuel <<a href="mailto:Samuel.Li@amd.com" target="_blank">Samuel.Li@amd.com</a>>
wrote:<br>
>>to my earlier point, there may be cases where it
is advantageous to put<br>
>> display buffers in vram even if s/g display is
supported<br>
><br>
> Agreed. That is also why the patch has the options
to let user select where<br>
> to put display buffers.<br>
><br>
> As whether to put the option in Mesa or kernel, it
seems the difference is<br>
> not much. Also, since amdgpufb can request even
without mesa, kernel might<br>
> be a better choice. In addition, putting in the
kernel can save client’s<br>
> duplicate work(mesa, ogl, vulkan, 2d, kernel…)<br>
<br>
</span>Why do we even expose different memory pools to the
UMDs in the first<br>
place ;) Each pool has performance characteristics that
may be<br>
relevant for a particular work load. Only the UMDs really
know the<br>
finer points of those workloads. In general, you don't
want the kernel<br>
dictating policy if you can avoid it. The kernel exposes<br>
functionality and userspace sets the policy. With the
location set in<br>
userspace, each app/user can have whatever policy makes
sense for<br>
their use case all at the same time without needing to
tweak their<br>
kernel for every use case.<br>
<span class="m_-3838486020630618689m_8572536124089128592m_4947926278827078055HOEnZb"><font color="#888888"><br>
Alex</font></span><br>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset class="m_-3838486020630618689m_8572536124089128592mimeAttachmentHeader"></fieldset>
<br>
</div></div><span><pre>______________________________<wbr>_________________
amd-gfx mailing list
<a class="m_-3838486020630618689m_8572536124089128592moz-txt-link-abbreviated" href="mailto:amd-gfx@lists.freedesktop.org" target="_blank">amd-gfx@lists.freedesktop.org</a>
<a class="m_-3838486020630618689m_8572536124089128592moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/amd-gfx" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/amd-gfx</a>
</pre>
</span></blockquote>
<br>
</div>
</blockquote></div><br></div></div>