<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Yes, exactly. And if I remember
correctly Mesa used to always set GTT as fallback on APUs,
correct?<br>
<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.<br>
<br>
Christian.<br>
<br>
Am 20.03.2018 um 00:01 schrieb Marek Olšák:<br>
</div>
<blockquote type="cite"
cite="mid:CAAxE2A4fiM5KjfxOSTTT3Soew8S-EGE7OVWBh-7565+rahMaOg@mail.gmail.com">
<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_4947926278827078055HOEnZb"><font
color="#888888"><br>
Alex</font></span><br>
</blockquote>
</div>
</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>