AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: "Liu, Monk" <Monk.Liu@amd.com>,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
	"Olsak, Marek" <Marek.Olsak@amd.com>
Subject: Re: Gang submit
Date: Tue, 6 Sep 2022 11:02:16 +0200	[thread overview]
Message-ID: <eae05187-67a4-d159-79fb-c82cec0a5d2b@amd.com> (raw)
In-Reply-To: <BL1PR12MB52691BCF633B4F87318AE9CC847E9@BL1PR12MB5269.namprd12.prod.outlook.com>

Hi Monk,

> If one gfx ib and one compute ib are in a gang, can they run literally  in parallel on GPU ?

Yes, that is essentially the functionality of gang submit.

The driver stack must guarantee that those IBs run at the same time 
because they use a ring buffer to communicate with each other.

> if one gfx ib and one compute ib are belong to two gang, they will be put to the gfx and compute ring one by one (e.g:  gang1-gfx-ib scheduled and signaled, and then gang2-compute-ib scheduled )

Yes, gang submission should never overlap or otherwise you can run into 
lockups.

Regards,
Christian.

Am 06.09.22 um 03:43 schrieb Liu, Monk:
> [AMD Official Use Only - General]
>
> Hi Christian
>
>
>> A gang submission guarantees that multiple IBs can run on different engines at the same time.
>> The effect is that as long as members of a gang are waiting to be submitted no other gang can start pushing jobs to the hardware and so deadlocks are effectively prevented.
> Could you please help to explain or confirm:
>
> 1) If one gfx ib and one compute ib are in a gang, can they run literally  in parallel on GPU ?
> 2) if one gfx ib and one compute ib are belong to two gang, they will be put to the gfx and compute ring one by one (e.g:  gang1-gfx-ib scheduled and signaled, and then gang2-compute-ib scheduled )
>
> Thanks
> -------------------------------------------------------------------
> Monk Liu | Cloud GPU & Virtualization Solution | AMD
> -------------------------------------------------------------------
> we are hiring software manager for CVS core team
> -------------------------------------------------------------------
>
> -----Original Message-----
> From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> On Behalf Of Christian König
> Sent: 2022年3月3日 16:23
> To: amd-gfx@lists.freedesktop.org; Olsak, Marek <Marek.Olsak@amd.com>
> Subject: Gang submit
>
> Hi guys,
>
> this patch set implements the the requirement for so called gang submissions in the CS interface.
>
> A gang submission guarantees that multiple IBs can run on different engines at the same time.
>
> This is implemented by keeping a global per-device gang around represented by a dma_fence which signals as soon as all jobs in a gang are pushed to the hardware.
>
> The effect is that as long as members of a gang are waiting to be submitted no other gang can start pushing jobs to the hardware and so deadlocks are effectively prevented.
>
> The whole set is based on top of my dma_resv_usage work and a few patches merged over from amd-staging-drm-next, so it won't easily apply anywhere.
>
> Please review and comment,
> Christian.
>


      reply	other threads:[~2022-09-06  9:02 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-03  8:22 Gang submit Christian König
2022-03-03  8:22 ` [PATCH 01/10] drm/amdgpu: install ctx entities with cmpxchg Christian König
2022-03-03 19:52   ` Andrey Grodzovsky
2022-03-03  8:23 ` [PATCH 02/10] drm/amdgpu: header cleanup Christian König
2022-03-03 19:56   ` Andrey Grodzovsky
2022-03-03  8:23 ` [PATCH 03/10] drm/amdgpu: cleanup and reorder amdgpu_cs.c Christian König
2022-03-03  8:23 ` [PATCH 04/10] drm/amdgpu: remove SRIOV and MCBP dependencies from the CS Christian König
2022-03-03  8:23 ` [PATCH 05/10] drm/amdgpu: use job and ib structures directly in CS parsers Christian König
2022-03-03 20:16   ` Andrey Grodzovsky
2022-03-03  8:23 ` [PATCH 06/10] drm/amdgpu: properly imbed the IBs into the job Christian König
2022-03-03 20:25   ` Andrey Grodzovsky
2022-03-03  8:23 ` [PATCH 07/10] drm/amdgpu: move setting the job resources Christian König
2022-03-03  8:23 ` [PATCH 08/10] drm/amdgpu: initialize the vmid_wait with the stub fence Christian König
2022-03-03 20:31   ` Andrey Grodzovsky
2022-03-03  8:23 ` [PATCH 09/10] drm/amdgpu: add gang submit backend Christian König
2022-03-04 17:10   ` Andrey Grodzovsky
2022-03-05 18:40     ` Christian König
2022-03-07 15:40       ` Andrey Grodzovsky
2022-03-07 15:59         ` Christian König
2022-03-07 16:02           ` Andrey Grodzovsky
2022-03-03  8:23 ` [PATCH 10/10] drm/amdgpu: add gang submit frontend Christian König
2022-03-07 17:02   ` Andrey Grodzovsky
2022-06-01 12:09   ` Mohan Marimuthu, Yogesh
2022-06-01 12:11     ` Christian König
2022-06-01 13:21       ` Mohan Marimuthu, Yogesh
2022-09-06  1:43 ` Gang submit Liu, Monk
2022-09-06  9:02   ` Christian König [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eae05187-67a4-d159-79fb-c82cec0a5d2b@amd.com \
    --to=christian.koenig@amd.com \
    --cc=Marek.Olsak@amd.com \
    --cc=Monk.Liu@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox