From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Christian_K=c3=b6nig?= Subject: Re: [PATCH 1/2] drm/amdgpu: Enable scatter gather display support Date: Tue, 20 Mar 2018 14:55:10 +0100 Message-ID: <13996c5e-dc4c-5a9a-b6c3-7fe6bb63ec5d@gmail.com> References: <1520033110-29964-1-git-send-email-Samuel.Li@amd.com> Reply-To: christian.koenig-5C7GfCeVMHo@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0326218772==" Return-path: In-Reply-To: Content-Language: en-US List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "amd-gfx" To: =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= , Alex Deucher Cc: "Deucher, Alexander" , =?UTF-8?Q?Michel_D=c3=a4nzer?= , "Li, Samuel" , "Koenig, Christian" , amd-gfx list This is a multi-part message in MIME format. --===============0326218772== Content-Type: multipart/alternative; boundary="------------E68D74931A319D90A144AA46" Content-Language: en-US This is a multi-part message in MIME format. --------------E68D74931A319D90A144AA46 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Yes, exactly. And if I remember correctly Mesa used to always set GTT as fallback on APUs, correct? The problem seems to be that this fallback isn't set for displayable BOs. So what needs to be done is to just enable this fallback for displayable BOs as well if the kernel can handle it. Christian. Am 20.03.2018 um 00:01 schrieb Marek Olšák: > 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. > > 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. > > Marek > > On Mon, Mar 19, 2018 at 5:12 PM, Alex Deucher > wrote: > > On Mon, Mar 19, 2018 at 4:29 PM, Li, Samuel > wrote: > >>to my earlier point, there may be cases where it is advantageous > to put > >> display buffers in vram even if s/g display is supported > > > > Agreed. That is also why the patch has the options to let user > select where > > to put display buffers. > > > > As whether to put the option in Mesa or kernel, it seems the > difference is > > not much. Also, since amdgpufb can request even without mesa, > kernel might > > be a better choice. In addition, putting in the kernel can save > client’s > > duplicate work(mesa, ogl, vulkan, 2d, kernel…) > > Why do we even expose different memory pools to the UMDs in the first > place ;)  Each pool has performance characteristics that may be > relevant for a particular work load.  Only the UMDs really know the > finer points of those workloads. In general, you don't want the kernel > dictating policy if you can avoid it.  The kernel exposes > functionality and userspace sets the policy.  With the location set in > userspace, each app/user can have whatever policy makes sense for > their use case all at the same time without needing to tweak their > kernel for every use case. > > Alex > > > > _______________________________________________ > amd-gfx mailing list > amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx --------------E68D74931A319D90A144AA46 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Yes, exactly. And if I remember correctly Mesa used to always set GTT as fallback on APUs, correct?

The problem seems to be that this fallback isn't set for displayable BOs.

So what needs to be done is to just enable this fallback for displayable BOs as well if the kernel can handle it.

Christian.

Am 20.03.2018 um 00:01 schrieb Marek Olšák:
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.

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.

Marek

On Mon, Mar 19, 2018 at 5:12 PM, Alex Deucher <alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Mon, Mar 19, 2018 at 4:29 PM, Li, Samuel <Samuel.Li-5C7GfCeVMHo@public.gmane.org> wrote:
>>to my earlier point, there may be cases where it is advantageous to put
>> display buffers in vram even if s/g display is supported
>
> Agreed. That is also why the patch has the options to let user select where
> to put display buffers.
>
> As whether to put the option in Mesa or kernel, it seems the difference is
> not much. Also, since amdgpufb can request even without mesa, kernel might
> be a better choice. In addition, putting in the kernel can save client’s
> duplicate work(mesa, ogl, vulkan, 2d, kernel…)

Why do we even expose different memory pools to the UMDs in the first
place ;)  Each pool has performance characteristics that may be
relevant for a particular work load.  Only the UMDs really know the
finer points of those workloads. In general, you don't want the kernel
dictating policy if you can avoid it.  The kernel exposes
functionality and userspace sets the policy.  With the location set in
userspace, each app/user can have whatever policy makes sense for
their use case all at the same time without needing to tweak their
kernel for every use case.

Alex


_______________________________________________
amd-gfx mailing list
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

--------------E68D74931A319D90A144AA46-- --===============0326218772== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KYW1kLWdmeCBt YWlsaW5nIGxpc3QKYW1kLWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5m cmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9hbWQtZ2Z4Cg== --===============0326218772==--