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, 9 Jan 2019 18:39:31 -0500 Message-ID: References: <20190107193104.4361-1-maraeo@gmail.com> <513ee137-7e99-c8fc-9e3b-e9077ead60a3@gmail.com> <7f85afd6-b17b-1c50-ba03-c03dd6e9a362@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1208134913==" Return-path: In-Reply-To: <7f85afd6-b17b-1c50-ba03-c03dd6e9a362-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 --===============1208134913== Content-Type: multipart/alternative; boundary="0000000000007a2198057f0efbc3" --0000000000007a2198057f0efbc3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 9, 2019 at 1:41 PM Christian K=C3=B6nig < ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > Am 09.01.19 um 17:14 schrieb Marek Ol=C5=A1=C3=A1k: > > On Wed, Jan 9, 2019 at 8:09 AM Christian K=C3=B6nig < > ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> Am 09.01.19 um 13:36 schrieb Marek Ol=C5=A1=C3=A1k: >> >> >> >> On Wed, Jan 9, 2019, 5:28 AM Christian K=C3=B6nig < >> ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote: >> >>> Looks good, but I'm wondering what's the actual improvement? >>> >> >> No malloc calls and 1 less for loop copying the bo list. >> >> >> Yeah, but didn't we want to get completely rid of the bo list? >> > > If we have multiple IBs (e.g. gfx + compute) that share a BO list, I thin= k > it's faster to send the BO list to the kernel only once. > > > That's not really faster. > > The only thing we safe us is a single loop over all BOs to lockup the > handle into a pointer and that is only a tiny fraction of the overhead. > > The majority of the overhead is locking the BOs and reserving space for > the submission. > > What could really help here is to submit gfx+comput together in just one > CS IOCTL. This way we would need the locking and space reservation only > once. > > It's a bit of work in the kernel side, but certainly doable. > OK. Any objections to this patch? Thanks, Marek --0000000000007a2198057f0efbc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 9, 2019 at 1:41 PM Christian K=C3=B6nig <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org<= /a>> wrote:
=20 =20 =20
Am 09.01.19 = um 17:14 schrieb Marek Ol=C5=A1=C3=A1k:
=20
Am 09.01.19 um 13:36 schrieb Marek Ol=C5=A1=C3=A1k:


On Wed, Jan 9, 2019, 5:28 AM Christian K=C3=B6nig <ckoenig.leichtzumerken@gmail.= com wrote:
L= ooks good, but I'm wondering what's the actual improvement?

No malloc calls and 1 less for loop copying the bo list.

Yeah, but didn't we want to get completely rid of the b= o list?

If we have multiple IBs (e.g. gfx + compute) that share a BO list, I think it's faster to send the BO list to the kernel only once.

That's not really faster.

The only thing we safe us is a single loop over all BOs to lockup the handle into a pointer and that is only a tiny fraction of the overhead.

The majority of the overhead is locking the BOs and reserving space for the submission.

What could really help here is to submit gfx+comput together in just one CS IOCTL. This way we would need the locking and space reservation only once.

It's a bit of work in the kernel side, but certainly doable.

OK. Any objections to this patch?
=

Thanks,
Marek
--0000000000007a2198057f0efbc3-- --===============1208134913== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KYW1kLWdmeCBt YWlsaW5nIGxpc3QKYW1kLWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5m cmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9hbWQtZ2Z4Cg== --===============1208134913==--