From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Christian_K=c3=b6nig?= Subject: Re: [PATCH libdrm] amdgpu: add a faster BO list API Date: Wed, 9 Jan 2019 19:41:11 +0100 Message-ID: <7f85afd6-b17b-1c50-ba03-c03dd6e9a362@gmail.com> References: <20190107193104.4361-1-maraeo@gmail.com> <513ee137-7e99-c8fc-9e3b-e9077ead60a3@gmail.com> Reply-To: christian.koenig-5C7GfCeVMHo@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0218347674==" 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==?= , =?UTF-8?Q?Christian_K=c3=b6nig?= Cc: amd-gfx mailing list This is a multi-part message in MIME format. --===============0218347674== Content-Type: multipart/alternative; boundary="------------270B7C3EEF0DEBAB647D19FF" Content-Language: en-US This is a multi-part message in MIME format. --------------270B7C3EEF0DEBAB647D19FF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Am 09.01.19 um 17:14 schrieb Marek Olšák: > On Wed, Jan 9, 2019 at 8:09 AM Christian König > > wrote: > > Am 09.01.19 um 13:36 schrieb Marek Olšák: >> >> >> On Wed, Jan 9, 2019, 5:28 AM Christian König >> > 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 > 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. Christian. > > Marek > > _______________________________________________ > amd-gfx mailing list > amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx --------------270B7C3EEF0DEBAB647D19FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Am 09.01.19 um 17:14 schrieb Marek Olšák:
On Wed, Jan 9, 2019 at 8:09 AM Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Am 09.01.19 um 13:36 schrieb Marek Olšák:


On Wed, Jan 9, 2019, 5:28 AM Christian König <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 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.

Christian.


Marek

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

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