AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Koenig, Christian" <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>
To: "Deucher,
	Alexander" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>,
	"Zeng, Oak" <Oak.Zeng-5C7GfCeVMHo@public.gmane.org>,
	"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Cc: "Kuehling, Felix" <Felix.Kuehling-5C7GfCeVMHo@public.gmane.org>,
	"Keely, Sean" <Sean.Keely-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH 1/5] drm/amdgpu: Extends amdgpu vm definitions
Date: Thu, 8 Aug 2019 16:28:47 +0000	[thread overview]
Message-ID: <7525d869-18ef-ee5a-b80f-cb986a1e5aa2@amd.com> (raw)
In-Reply-To: <BN6PR12MB1809D2F0A97155733CA3FC6EF7D70-/b2+HYfkarSEx6ez0IUAagdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 4702 bytes --]

Yeah, exactly. This is controlling PCIe bus request behavior and routing.

That is something we never ever want to expose to userspace.

Christian.

Am 08.08.19 um 18:09 schrieb Deucher, Alexander:
The snoop bit is for snooping the CPU cache by the GPU when doing system memory mappings.

Alex
________________________________
From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org><mailto:amd-gfx-bounces@lists.freedesktop.org> on behalf of Zeng, Oak <Oak.Zeng@amd.com><mailto:Oak.Zeng@amd.com>
Sent: Thursday, August 8, 2019 12:02 PM
To: Koenig, Christian <Christian.Koenig@amd.com><mailto:Christian.Koenig@amd.com>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org> <amd-gfx@lists.freedesktop.org><mailto:amd-gfx@lists.freedesktop.org>
Cc: Kuehling, Felix <Felix.Kuehling@amd.com><mailto:Felix.Kuehling@amd.com>; Keely, Sean <Sean.Keely@amd.com><mailto:Sean.Keely@amd.com>
Subject: RE: [PATCH 1/5] drm/amdgpu: Extends amdgpu vm definitions

Hi Christian,

My understanding of the snoop bit (C bit in the PTE definition) is to probe remote gpu's L2 cache after this gpu write remote gpu's vram. Is this correct? I am still checking this point with HW engineer.

If this is correct, then the snooping (or probing) is a way to maintain certain cache coherency when one memory is access by two masters (for example two gpu). With existing AMDGPU_VM_ definitions in amdgpu_drm.h, how does a user implement the request like: I want a trunk of vram physically in a remote gpu, I want to access it in a uncached way (AMDGPU_VM_MTYPE_UC) but I want to probe remote gpu's cache when I modify this vram.

From PTE's definition, both C bit and mtype and R/W/X bits are just flags to enable user to program page access behavior. Any detail reason why we shouldn't expose the snoop bit?

Regards,
Oak

-----Original Message-----
From: Christian König <ckoenig.leichtzumerken@gmail.com><mailto:ckoenig.leichtzumerken@gmail.com>
Sent: Wednesday, August 7, 2019 4:42 AM
To: Zeng, Oak <Oak.Zeng@amd.com><mailto:Oak.Zeng@amd.com>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Cc: Kuehling, Felix <Felix.Kuehling@amd.com><mailto:Felix.Kuehling@amd.com>; Koenig, Christian <Christian.Koenig@amd.com><mailto:Christian.Koenig@amd.com>; Keely, Sean <Sean.Keely@amd.com><mailto:Sean.Keely@amd.com>
Subject: Re: [PATCH 1/5] drm/amdgpu: Extends amdgpu vm definitions

Am 07.08.19 um 04:31 schrieb Zeng, Oak:
> Add definition of all supported mtypes. The RW mtype is recently
> introduced for arcturus. Also add definition for the
> cachable/snoopable bit, which will be used later in this series.
>
> Change-Id: I96fc9bb4b6b1e62bdc10b600d8aaa6a802128d6d
> Signed-off-by: Oak Zeng <Oak.Zeng@amd.com><mailto:Oak.Zeng@amd.com>
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 9 +++++++--
>   include/uapi/drm/amdgpu_drm.h          | 4 ++++
>   2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> index 2eda3a8..7a77477 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> @@ -80,8 +80,13 @@ struct amdgpu_bo_list_entry;
>   #define AMDGPU_PTE_MTYPE_VG10(a)    ((uint64_t)(a) << 57)
>   #define AMDGPU_PTE_MTYPE_VG10_MASK  AMDGPU_PTE_MTYPE_VG10(3ULL)
>
> -#define AMDGPU_MTYPE_NC 0
> -#define AMDGPU_MTYPE_CC 2
> +enum amdgpu_mtype {
> +     AMDGPU_MTYPE_NC = 0,
> +     AMDGPU_MTYPE_WC = 1,
> +     AMDGPU_MTYPE_CC = 2,
> +     AMDGPU_MTYPE_UC = 3,
> +     AMDGPU_MTYPE_RW = 4,
> +};
>
>   #define AMDGPU_PTE_DEFAULT_ATC  (AMDGPU_PTE_SYSTEM      \
>                                   | AMDGPU_PTE_SNOOPED    \
> diff --git a/include/uapi/drm/amdgpu_drm.h
> b/include/uapi/drm/amdgpu_drm.h index ca97b68..2889663 100644
> --- a/include/uapi/drm/amdgpu_drm.h
> +++ b/include/uapi/drm/amdgpu_drm.h
> @@ -503,6 +503,10 @@ struct drm_amdgpu_gem_op {
>   #define AMDGPU_VM_MTYPE_CC          (3 << 5)
>   /* Use UC MTYPE instead of default MTYPE */
>   #define AMDGPU_VM_MTYPE_UC          (4 << 5)
> +/* Use RW MTYPE instead of default MTYPE */
> +#define AMDGPU_VM_MTYPE_RW           (5 << 5)

> +/* Cacheable/snoopable */
> +#define AMDGPU_VM_PAGE_SNOOPED               (1 << 9)

That's a rather big NAK. Cache snooping is not something userspace is allowed to be aware of.

Christian.

>
>   struct drm_amdgpu_gem_va {
>        /** GEM object handle */

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[-- Attachment #1.2: Type: text/html, Size: 8075 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

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

  parent reply	other threads:[~2019-08-08 16:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-07  2:31 [PATCH 1/5] drm/amdgpu: Extends amdgpu vm definitions Zeng, Oak
     [not found] ` <1565145062-16674-1-git-send-email-Oak.Zeng-5C7GfCeVMHo@public.gmane.org>
2019-08-07  2:31   ` [PATCH 2/5] drm/amdgpu: Support new arcturus mtype Zeng, Oak
     [not found]     ` <1565145062-16674-2-git-send-email-Oak.Zeng-5C7GfCeVMHo@public.gmane.org>
2019-08-07  3:59       ` Kuehling, Felix
2019-08-07  2:31   ` [PATCH 3/5] drm/amdkfd: Postpone memory mapping flags calculation to mapping time Zeng, Oak
     [not found]     ` <1565145062-16674-3-git-send-email-Oak.Zeng-5C7GfCeVMHo@public.gmane.org>
2019-08-07  4:05       ` Kuehling, Felix
     [not found]         ` <ad0aa642-f275-a239-288f-6d83ed60f936-5C7GfCeVMHo@public.gmane.org>
2019-08-09  1:41           ` Zeng, Oak
2019-08-07  2:31   ` [PATCH 4/5] drm/amdgpu: Support snooped PTE flag Zeng, Oak
2019-08-07  2:31   ` [PATCH 5/5] amd/amdgpu: Introduce new page mapping scheme for arcturus Zeng, Oak
     [not found]     ` <1565145062-16674-5-git-send-email-Oak.Zeng-5C7GfCeVMHo@public.gmane.org>
2019-08-07  4:10       ` Kuehling, Felix
2019-08-07  8:41   ` [PATCH 1/5] drm/amdgpu: Extends amdgpu vm definitions Christian König
     [not found]     ` <3e4f2f68-8840-d85c-052e-fc54dbf45fd4-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-08-08 16:02       ` Zeng, Oak
     [not found]         ` <BL0PR12MB2580601F44DB50051768070080D70-b4cIHhjg/p/XzH18dTCKOgdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-08-08 16:09           ` Deucher, Alexander
     [not found]             ` <BN6PR12MB1809D2F0A97155733CA3FC6EF7D70-/b2+HYfkarSEx6ez0IUAagdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-08-08 16:23               ` Zeng, Oak
2019-08-08 16:28               ` Koenig, Christian [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-08-09  2:15 Zeng, Oak
     [not found] ` <1565316926-19516-1-git-send-email-Oak.Zeng-5C7GfCeVMHo@public.gmane.org>
2019-08-09 12:28   ` Koenig, Christian
     [not found]     ` <801142da-51cb-4efd-2cd6-860c65bfb311-5C7GfCeVMHo@public.gmane.org>
2019-08-09 13:50       ` Zeng, Oak

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=7525d869-18ef-ee5a-b80f-cb986a1e5aa2@amd.com \
    --to=christian.koenig-5c7gfcevmho@public.gmane.org \
    --cc=Alexander.Deucher-5C7GfCeVMHo@public.gmane.org \
    --cc=Felix.Kuehling-5C7GfCeVMHo@public.gmane.org \
    --cc=Oak.Zeng-5C7GfCeVMHo@public.gmane.org \
    --cc=Sean.Keely-5C7GfCeVMHo@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.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