From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E43D2C77B61 for ; Thu, 13 Apr 2023 09:21:56 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 91B0510E28D; Thu, 13 Apr 2023 09:21:56 +0000 (UTC) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2DE0410E28D for ; Thu, 13 Apr 2023 09:21:55 +0000 (UTC) Received: by mail-ej1-x62c.google.com with SMTP id f26so29660201ejb.1 for ; Thu, 13 Apr 2023 02:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681377713; x=1683969713; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YWEhAdKcSLZm2Mnl9kUAGm2biGRf66BEyi8ZVc4dnxQ=; b=fwpjSynmIlQNWSgretXS39urbRL1JRAhywDsAX2bpaI2QGA48TV52Cbt38GxqkMj8D AfSVzaRseSGXX5UEjPk+0jqD6OzQFq5/YcxlBfEc0AvPEbEd/VlwXPXzSgjRVe7imNqp ckK9mNxlSKlBBu2czNBMMvlhvOAAw34zo6Oyvqwlfn9YiqVu2vAEPGynTerBCDEMT6/x MudI2j/zrOYIBltUZ1u0ZqOzpmCytyFTYIgDvHaAyCXlV2SaLkld6JdIB5+oW7au5AgN ZhHkNKVrvaw2Y24Nqjn0KO8wUn61y2SweurUGHk7x46MtOMtj7qfF4Z+TPh83C7OKXrW vscg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681377713; x=1683969713; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YWEhAdKcSLZm2Mnl9kUAGm2biGRf66BEyi8ZVc4dnxQ=; b=fxTeow8yIiiXYHdVk3oBHjkzC2V6Gxp+MukWIMgy8VGGLSe0Zqz0zP0IjjEUWXa//f ECVZLWy4AOY6PeVydVs968NsV2v/Lf8R/aH+IAzQAW/SS70SMpdp0ZPtsWCYH91av4h3 LHNFpfQgEVGmWh6jV3IPNrFaQddgiGxPwgqYz/6QQ9KjBFCTrbCdK4HYB/lqF1WXWyK1 8oSRk/KGm4DTPIM780VaLbLIsU7uEF66tbQmvfa/N+7M8n73piUMBtlxpkU0IRK/3W1N nWOEg94npdBlzbtDnjGqFvKXw19OxeI86YN1JtJRYJ/vI/7XRoh72+SNOQ1KeDI8vdEE MCrA== X-Gm-Message-State: AAQBX9eGQOq1mULqi/pszRIusUNM/HBoKiHJ2n0M+S/trfeOO0kyIKwB 85lOx0iSVj6O9oMyx7GoOWBhs91/qSGujC9v3y0= X-Google-Smtp-Source: AKy350ZIf6NF04xUmQZrVhNa+R771ZGB9XDZl20lNVuSQRkUptAm99apKRaPVtchokgb5GSX0YiaZWXA6fngokqzv68= X-Received: by 2002:a17:906:78e:b0:8eb:27de:447e with SMTP id l14-20020a170906078e00b008eb27de447emr887406ejc.7.1681377713110; Thu, 13 Apr 2023 02:21:53 -0700 (PDT) MIME-Version: 1.0 References: <20230330191750.1134210-1-alexander.deucher@amd.com> <20230330191750.1134210-4-alexander.deucher@amd.com> <8a98b160-5276-54f5-d166-e12a572892e9@amd.com> <2897fa79-f0ef-1ddb-dc38-05ef429fe0d9@gmail.com> In-Reply-To: <2897fa79-f0ef-1ddb-dc38-05ef429fe0d9@gmail.com> From: =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= Date: Thu, 13 Apr 2023 05:21:39 -0400 Message-ID: Subject: Re: [PATCH 03/13] drm/amdgpu/UAPI: add new CS chunk for GFX shadow buffers To: =?UTF-8?Q?Christian_K=C3=B6nig?= Content-Type: multipart/alternative; boundary="00000000000052c2ef05f93441b7" X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alex Deucher , amd-gfx mailing list Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" --00000000000052c2ef05f93441b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's not why it was removed. It was removed because userspace doesn't use GDS memory and gds_va is always going to be 0. Firmware shouldn't use it because using it would increase preemption latency. Marek On Sun, Apr 9, 2023, 11:21 Christian K=C3=B6nig wrote: > We removed the GDS information because they were unnecessary. The GDS siz= e > was already part of the device info before we added the shadow info. > > But as far as I know the firmware needs valid VAs for all three buffers o= r > won't work correctly. > > Christian. > > Am 06.04.23 um 17:01 schrieb Marek Ol=C5=A1=C3=A1k: > > There is no GDS shadowing info in the device info uapi, so userspace can'= t > create any GDS buffer and thus can't have any GDS va. It's a uapi issue, > not what firmware wants to do. > > Marek > > On Thu, Apr 6, 2023 at 6:31=E2=80=AFAM Christian K=C3=B6nig < > ckoenig.leichtzumerken@gmail.com> wrote: > >> That's what I thought as well, but Mitch/Hans insisted on that. >> >> We should probably double check internally. >> >> Christian. >> >> Am 06.04.23 um 11:43 schrieb Marek Ol=C5=A1=C3=A1k: >> >> GDS memory isn't used on gfx11. Only GDS OA is used. >> >> Marek >> >> On Thu, Apr 6, 2023 at 5:09=E2=80=AFAM Christian K=C3=B6nig >> wrote: >> >>> Why that? >>> >>> This is the save buffer for GDS, not the old style GDS BOs. >>> >>> Christian. >>> >>> Am 06.04.23 um 09:36 schrieb Marek Ol=C5=A1=C3=A1k: >>> >>> gds_va is unnecessary. >>> >>> Marek >>> >>> On Thu, Mar 30, 2023 at 3:18=E2=80=AFPM Alex Deucher >>> wrote: >>> >>>> For GFX11, the UMD needs to allocate some shadow buffers >>>> to be used for preemption. The UMD allocates the buffers >>>> and passes the GPU virtual address to the kernel since the >>>> kernel will program the packet that specified these >>>> addresses as part of its IB submission frame. >>>> >>>> v2: UMD passes shadow init to tell kernel when to initialize >>>> the shadow >>>> >>>> Reviewed-by: Christian K=C3=B6nig >>>> Signed-off-by: Alex Deucher >>>> --- >>>> include/uapi/drm/amdgpu_drm.h | 10 ++++++++++ >>>> 1 file changed, 10 insertions(+) >>>> >>>> diff --git a/include/uapi/drm/amdgpu_drm.h >>>> b/include/uapi/drm/amdgpu_drm.h >>>> index b6eb90df5d05..3d9474af6566 100644 >>>> --- a/include/uapi/drm/amdgpu_drm.h >>>> +++ b/include/uapi/drm/amdgpu_drm.h >>>> @@ -592,6 +592,7 @@ struct drm_amdgpu_gem_va { >>>> #define AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES 0x07 >>>> #define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT 0x08 >>>> #define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL 0x09 >>>> +#define AMDGPU_CHUNK_ID_CP_GFX_SHADOW 0x0a >>>> >>>> struct drm_amdgpu_cs_chunk { >>>> __u32 chunk_id; >>>> @@ -708,6 +709,15 @@ struct drm_amdgpu_cs_chunk_data { >>>> }; >>>> }; >>>> >>>> +#define AMDGPU_CS_CHUNK_CP_GFX_SHADOW_FLAGS_INIT_SHADOW 0x1 >>>> + >>>> +struct drm_amdgpu_cs_chunk_cp_gfx_shadow { >>>> + __u64 shadow_va; >>>> + __u64 csa_va; >>>> + __u64 gds_va; >>>> + __u64 flags; >>>> +}; >>>> + >>>> /* >>>> * Query h/w info: Flag that this is integrated (a.h.a. fusion) GPU >>>> * >>>> -- >>>> 2.39.2 >>>> >>>> >>> >> > --00000000000052c2ef05f93441b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's not why it was removed. It was removed be= cause userspace doesn't use GDS memory and gds_va is always going to be= 0.

Firmware shouldn'= ;t use it because using it would increase preemption latency.

Marek

On Sun, Apr 9, 2023, = 11:21 Christian K=C3=B6nig <ckoenig.leichtzumerken@gmail.com> wrote:
=20 =20 =20
We removed the GDS information because they were unnecessary. The GDS size was already part of the device info before we added the shadow info.

But as far as I know the firmware needs valid VAs for all three buffers or won't work correctly.

Christian.

Am 06.04.23 um 17:01 schrieb Marek Ol=C5=A1=C3=A1k:
=20
There is no GDS shadowing info in the device info uapi, so userspace can't create any GDS buffer and thus can't have= any GDS va. It's a uapi issue, not what firmware wants to do.

Marek

On Thu, Apr 6, 2023 at 6:31= =E2=80=AFAM Christian K=C3=B6nig <ckoenig.leichtzumerken@gma= il.com> wrote:
That's what I thought as well, but Mitch/Hans insisted on that.

We should probably double check internally.

Christian.

Am 06.04.23 um 11:43 schrieb Marek Ol=C5=A1=C3=A1k:
GDS memory isn't used on gfx11. Only GDS OA is used.

Marek

On Thu, Apr 6, 2023 a= t 5:09=E2=80=AFAM Christian K=C3=B6nig <christian.= koenig@amd.com> wrote:
Why that?

This is the save buffer for GDS, not the old style GDS BOs.

Christian.

Am 06.04.23 um 09:36 schrieb Marek Ol=C5=A1=C3=A1k= :
gds_va is unnecessary.

Marek

On Thu, Mar 30, 2023 at 3:18=E2=80=AFPM Alex Deucher <alexander.deucher@amd.com> wrote:
F= or GFX11, the UMD needs to allocate some shadow buffers
to be used for preemption.=C2=A0 The UMD allocate= s the buffers
and passes the GPU virtual address to the kernel since the
kernel will program the packet that specified these
addresses as part of its IB submission frame.

v2: UMD passes shadow init to tell kernel when to initialize
=C2=A0 =C2=A0 the shadow

Reviewed-by: Christian K=C3=B6nig <chris= tian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.= deucher@amd.com>
---
=C2=A0include/uapi/drm/amdgpu_drm.h | 10 ++++++++= ++
=C2=A01 file changed, 10 insertions(+)

diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index b6eb90df5d05..3d9474af6566 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -592,6 +592,7 @@ struct drm_amdgpu_gem_va { =C2=A0#define AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES 0x07
=C2=A0#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT=C2=A0 =C2= =A0 0x08
=C2=A0#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL=C2=A0 0x0= 9
+#define AMDGPU_CHUNK_ID_CP_GFX_SHADOW=C2=A0 =C2= =A00x0a

=C2=A0struct drm_amdgpu_cs_chunk {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __u32=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0chunk_id;
@@ -708,6 +709,15 @@ struct drm_amdgpu_cs_chunk_data {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 };
=C2=A0};

+#define AMDGPU_CS_CHUNK_CP_GFX_SHADOW_FLAGS_INIT_SHADOW= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x1
+
+struct drm_amdgpu_cs_chunk_cp_gfx_shadow {
+=C2=A0 =C2=A0 =C2=A0 =C2=A0__u64 shadow_va;
+=C2=A0 =C2=A0 =C2=A0 =C2=A0__u64 csa_va;
+=C2=A0 =C2=A0 =C2=A0 =C2=A0__u64 gds_va;
+=C2=A0 =C2=A0 =C2=A0 =C2=A0__u64 flags;
+};
+
=C2=A0/*
=C2=A0 *=C2=A0 Query h/w info: Flag that this is integrated (a.h.a. fusion) GPU
=C2=A0 *
--
2.39.2




--00000000000052c2ef05f93441b7--