<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">I don't think that is a good idea.<br>
<br>
Ideally GTT should now have the same performance as VRAM on APUs
and we should use VRAM only for things where we absolutely have to
and to actually use up the otherwise unused VRAM.<br>
<br>
Can you run some tests with all BOs forced to GTT and see if there
is any performance regression?<br>
<br>
Christian.<br>
<br>
Am 20.03.2018 um 15:51 schrieb Marek Olšák:<br>
</div>
<blockquote type="cite"
cite="mid:CAAxE2A7ffe2fkOQG0mFpPfP4uRKZ1BVTKWQ3Q+FhLWQnYU4nww@mail.gmail.com">
<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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">https://lists.freedesktop.org/<wbr>mailman/listinfo/amd-gfx</a>
</pre>
</span></blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
amd-gfx mailing list
<a class="moz-txt-link-abbreviated" href="mailto:amd-gfx@lists.freedesktop.org">amd-gfx@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/amd-gfx">https://lists.freedesktop.org/mailman/listinfo/amd-gfx</a>
</pre>
</blockquote>
<br>
</body>
</html>