From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= Subject: Re: [PATCH libdrm] amdgpu: add a faster BO list API Date: Wed, 16 Jan 2019 12:39:48 -0500 Message-ID: References: <20190107193104.4361-1-maraeo@gmail.com> <74054b1e-5211-3bfc-ab0f-27e8604759d1@gmail.com> <3d525127-825b-efab-b0c8-76550634d1c1@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2004302084==" Return-path: In-Reply-To: <3d525127-825b-efab-b0c8-76550634d1c1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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?Q?Christian_K=C3=B6nig?= Cc: amd-gfx mailing list , Bas Nieuwenhuizen --===============2004302084== Content-Type: multipart/alternative; boundary="000000000000f2c833057f96c5eb" --000000000000f2c833057f96c5eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 16, 2019 at 9:43 AM Christian K=C3=B6nig < ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > Am 16.01.19 um 15:39 schrieb Marek Ol=C5=A1=C3=A1k: > > > > On Wed, Jan 16, 2019, 9:34 AM Koenig, Christian wrote: > >> Am 16.01.19 um 15:31 schrieb Marek Ol=C5=A1=C3=A1k: >> >> >> >> On Wed, Jan 16, 2019, 7:55 AM Christian K=C3=B6nig < >> ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote: >> >>> Well if you ask me we should have the following interface for >>> negotiating memory management with the kernel: >>> >>> 1. We have per process BOs which can't be shared between processes. >>> >>> Those are always valid and don't need to be mentioned in any BO list >>> whatsoever. >>> >>> If we knew that a per process BO is currently not in use we can >>> optionally tell that to the kernel to make memory management more >>> efficient. >>> >>> In other words instead of a list of stuff which is used we send down to >>> the kernel a list of stuff which is not used any more and that only whe= n >>> we know that it is necessary, e.g. when a game or application >>> overcommits. >>> >> >> Radeonsi doesn't use this because this approach caused performance >> degradation and also drops BO priorities. >> >> >> The performance degradation where mostly shortcomings with the LRU which >> by now have been fixed. >> >> BO priorities are a different topic, but could be added to per VM BOs as >> well. >> > > What's the minimum drm version that contains the fixes? > > > I've pushed the last optimization this morning. No idea when it really > became useful, but the numbers from the closed source clients now look mu= ch > better. > > We should probably test and bump the drm version when we are sure that > this now works as expected. > We should, but AMD Mesa guys don't have any time. Marek --000000000000f2c833057f96c5eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 16, 2019 at 9:43 AM Christian K=C3=B6nig <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
=20 =20 =20
Am 16.01.19 u= m 15:39 schrieb Marek Ol=C5=A1=C3=A1k:
=20


Am 16.01.19 um 15:31 schrieb Marek Ol=C5=A1=C3=A1k:


On Wed, Jan 16, 2019, 7:55 AM Christian K=C3=B6nig <ckoenig.le= ichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
Well if you ask me we should have the following interface for
negotiating memory management with the kernel:
1. We have per process BOs which can't be shared between processes.

Those are always valid and don't need to be mentioned in any BO list
whatsoever.

If we knew that a per process BO is currently not in use we can
optionally tell that to the kernel to make memory management more efficient.

In other words instead of a list of stuff which is used we send down to
the kernel a list of stuff which is not used any more and that only when
we know that it is necessary, e.g. when a game or application overcommits.

Radeonsi doesn't use this because this approach caused performance degradation and also drops BO priorities.

The performance degradation where mostly shortcomings with the LRU which by now have been fixed.

BO priorities are a different topic, but could be added to per VM BOs as well.

What's the minimum drm version that contains = the fixes?

I've pushed the last optimization this morning. No idea when it really became useful, but the numbers from the closed source clients now look much better.

We should probably test and bump the drm version when we are sure that this now works as expected.

<= div>We should, but AMD Mesa guys don't have any time.

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