<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">That's what I meant with use up the
otherwise unused VRAM. I don't see any disadvantage of always
setting GTT as second domain on APUs.<br>
<br>
My assumption was that we dropped this in userspace for
displayable surfaces, but Marek proved that wrong.<br>
<br>
So what we should do is actually to add GTT as fallback to all BOs
on APUs in Mesa and only make sure that the kernel is capable of
handling GTT with optimal performance (e.g. have user huge pages
etc..).<br>
<br>
Christian.<br>
<br>
Am 20.03.2018 um 21:04 schrieb Deucher, Alexander:<br>
</div>
<blockquote type="cite"
cite="mid:DM5PR12MB18205326885F0857CEC4FAA6F7AB0@DM5PR12MB1820.namprd12.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper"
style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;"
dir="ltr">
<p style="margin-top:0;margin-bottom:0">I think we can also have
the case of systems with similar amounts of carve out and
system ram. E.g., on a system with 4 GB of system memory with
1 GB carved out for vram. It would be a big waste not to use
VRAM. We'll probably need a heuristic at some point.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">Alex<br>
</p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b>
Christian König <a class="moz-txt-link-rfc2396E" href="mailto:ckoenig.leichtzumerken@gmail.com"><ckoenig.leichtzumerken@gmail.com></a><br>
<b>Sent:</b> Tuesday, March 20, 2018 2:32:49 PM<br>
<b>To:</b> Marek Olák; Koenig, Christian<br>
<b>Cc:</b> Alex Deucher; Deucher, Alexander; Michel Dänzer;
Li, Samuel; amd-gfx list<br>
<b>Subject:</b> Re: [PATCH 1/2] drm/amdgpu: Enable scatter
gather display support</font>
<div> </div>
</div>
<div style="background-color:#FFFFFF">
<div class="x_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">
<div dir="ltr">
<div class="x_gmail_extra">
<div class="x_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="x_gmail_quote" style="margin:0 0 0
.8ex; border-left:1px #ccc solid; padding-left:1ex">
<div bgcolor="#FFFFFF">
<div
class="x_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="x_gmail_quote" style="margin:0 0 0
.8ex; border-left:1px #ccc solid; padding-left:1ex">
<div bgcolor="#FFFFFF">
<div
class="x_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="x_m_-3838486020630618689HOEnZb"><font
color="#888888"><br>
<br>
Christian.</font></span>
<div>
<div class="x_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="x_m_-3838486020630618689h5">
<div dir="ltr">
<div class="x_gmail_extra">
<div class="x_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="x_gmail_quote"><br>
</div>
<div class="x_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="x_gmail_quote"><br>
</div>
<div class="x_gmail_quote">Marek<br>
</div>
<div class="x_gmail_quote"><br>
</div>
<div class="x_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="x_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 clients<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="x_m_-3838486020630618689m_8572536124089128592m_4947926278827078055HOEnZb"><font
color="#888888"><br>
Alex</font></span><br>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset
class="x_m_-3838486020630618689m_8572536124089128592mimeAttachmentHeader"></fieldset>
<br>
</div>
</div>
<span>
<pre>______________________________<wbr>_________________
amd-gfx mailing list
<a class="x_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="x_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="x_mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
amd-gfx mailing list
<a class="x_moz-txt-link-abbreviated" href="mailto:amd-gfx@lists.freedesktop.org" moz-do-not-send="true">amd-gfx@lists.freedesktop.org</a>
<a class="x_moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/amd-gfx" moz-do-not-send="true">https://lists.freedesktop.org/mailman/listinfo/amd-gfx</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
<br>
</body>
</html>