amd-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Marek Olšák" <maraeo@gmail.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: "Lazar, Lijo" <lijo.lazar@amd.com>,
	amd-gfx mailing list <amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/3] drm/amdgpu: add AMDGPU_VM_NOALLOC
Date: Mon, 16 May 2022 07:06:13 -0400	[thread overview]
Message-ID: <CAAxE2A5yVDo-6HW9Jt_pO-VwnBFQXQJP9-r0kNThP5XO1KWkFw@mail.gmail.com> (raw)
In-Reply-To: <CAAxE2A4P1avEwz0cniZupD9ZkXfnxKJY+1OzAOPRQqnOUcE5OQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6028 bytes --]

FYI, I think it's time to merge this because the Mesa commits are going to
be merged in ~30 minutes if Gitlab CI is green, and that includes updated
amdgpu_drm.h.

Marek

On Wed, May 11, 2022 at 2:55 PM Marek Olšák <maraeo@gmail.com> wrote:

> Ok sounds good.
>
> Marek
>
> On Wed., May 11, 2022, 03:43 Christian König, <
> ckoenig.leichtzumerken@gmail.com> wrote:
>
>> It really *is* a NOALLOC feature. In other words there is no latency
>> improvement on reads because the cache is always checked, even with the
>> noalloc flag set.
>>
>> The only thing it affects is that misses not enter the cache and so don't
>> cause any additional pressure on evicting cache lines.
>>
>> You might want to double check with the hardware guys, but I'm something
>> like 95% sure that it works this way.
>>
>> Christian.
>>
>> Am 11.05.22 um 09:22 schrieb Marek Olšák:
>>
>> Bypass means that the contents of the cache are ignored, which decreases
>> latency at the cost of no coherency between bypassed and normal memory
>> requests. NOA (noalloc) means that the cache is checked and can give you
>> cache hits, but misses are not cached and the overall latency is higher. I
>> don't know what the hw does, but I hope it was misnamed and it really means
>> bypass because there is no point in doing cache lookups on every memory
>> request if the driver wants to disable caching to *decrease* latency in the
>> situations when the cache isn't helping.
>>
>> Marek
>>
>> On Wed, May 11, 2022 at 2:15 AM Lazar, Lijo <lijo.lazar@amd.com> wrote:
>>
>>>
>>>
>>> On 5/11/2022 11:36 AM, Christian König wrote:
>>> > Mhm, it doesn't really bypass MALL. It just doesn't allocate any MALL
>>> > entries on write.
>>> >
>>> > How about AMDGPU_VM_PAGE_NO_MALL ?
>>>
>>> One more - AMDGPU_VM_PAGE_LLC_* [ LLC = last level cache, * = some sort
>>> of attribute which decides LLC behaviour]
>>>
>>> Thanks,
>>> Lijo
>>>
>>> >
>>> > Christian.
>>> >
>>> > Am 10.05.22 um 23:21 schrieb Marek Olšák:
>>> >> A better name would be:
>>> >> AMDGPU_VM_PAGE_BYPASS_MALL
>>> >>
>>> >> Marek
>>> >>
>>> >> On Fri, May 6, 2022 at 7:23 AM Christian König
>>> >> <ckoenig.leichtzumerken@gmail.com> wrote:
>>> >>
>>> >>     Add the AMDGPU_VM_NOALLOC flag to let userspace control MALL
>>> >>     allocation.
>>> >>
>>> >>     Only compile tested!
>>> >>
>>> >>     Signed-off-by: Christian König <christian.koenig@amd.com>
>>> >>     ---
>>> >>      drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 ++
>>> >>      drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c  | 3 +++
>>> >>      drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c  | 3 +++
>>> >>      include/uapi/drm/amdgpu_drm.h           | 2 ++
>>> >>      4 files changed, 10 insertions(+)
>>> >>
>>> >>     diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> >>     b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> >>     index bf97d8f07f57..d8129626581f 100644
>>> >>     --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> >>     +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>>> >>     @@ -650,6 +650,8 @@ uint64_t amdgpu_gem_va_map_flags(struct
>>> >>     amdgpu_device *adev, uint32_t flags)
>>> >>                     pte_flag |= AMDGPU_PTE_WRITEABLE;
>>> >>             if (flags & AMDGPU_VM_PAGE_PRT)
>>> >>                     pte_flag |= AMDGPU_PTE_PRT;
>>> >>     +       if (flags & AMDGPU_VM_PAGE_NOALLOC)
>>> >>     +               pte_flag |= AMDGPU_PTE_NOALLOC;
>>> >>
>>> >>             if (adev->gmc.gmc_funcs->map_mtype)
>>> >>                     pte_flag |= amdgpu_gmc_map_mtype(adev,
>>> >>     diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
>>> >>     b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
>>> >>     index b8c79789e1e4..9077dfccaf3c 100644
>>> >>     --- a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
>>> >>     +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
>>> >>     @@ -613,6 +613,9 @@ static void gmc_v10_0_get_vm_pte(struct
>>> >>     amdgpu_device *adev,
>>> >>             *flags &= ~AMDGPU_PTE_MTYPE_NV10_MASK;
>>> >>             *flags |= (mapping->flags & AMDGPU_PTE_MTYPE_NV10_MASK);
>>> >>
>>> >>     +       *flags &= ~AMDGPU_PTE_NOALLOC;
>>> >>     +       *flags |= (mapping->flags & AMDGPU_PTE_NOALLOC);
>>> >>     +
>>> >>             if (mapping->flags & AMDGPU_PTE_PRT) {
>>> >>                     *flags |= AMDGPU_PTE_PRT;
>>> >>                     *flags |= AMDGPU_PTE_SNOOPED;
>>> >>     diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c
>>> >>     b/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c
>>> >>     index 8d733eeac556..32ee56adb602 100644
>>> >>     --- a/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c
>>> >>     +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c
>>> >>     @@ -508,6 +508,9 @@ static void gmc_v11_0_get_vm_pte(struct
>>> >>     amdgpu_device *adev,
>>> >>             *flags &= ~AMDGPU_PTE_MTYPE_NV10_MASK;
>>> >>             *flags |= (mapping->flags & AMDGPU_PTE_MTYPE_NV10_MASK);
>>> >>
>>> >>     +       *flags &= ~AMDGPU_PTE_NOALLOC;
>>> >>     +       *flags |= (mapping->flags & AMDGPU_PTE_NOALLOC);
>>> >>     +
>>> >>             if (mapping->flags & AMDGPU_PTE_PRT) {
>>> >>                     *flags |= AMDGPU_PTE_PRT;
>>> >>                     *flags |= AMDGPU_PTE_SNOOPED;
>>> >>     diff --git a/include/uapi/drm/amdgpu_drm.h
>>> >>     b/include/uapi/drm/amdgpu_drm.h
>>> >>     index 57b9d8f0133a..9d71d6330687 100644
>>> >>     --- a/include/uapi/drm/amdgpu_drm.h
>>> >>     +++ b/include/uapi/drm/amdgpu_drm.h
>>> >>     @@ -533,6 +533,8 @@ struct drm_amdgpu_gem_op {
>>> >>      #define AMDGPU_VM_MTYPE_UC             (4 << 5)
>>> >>      /* Use Read Write MTYPE instead of default MTYPE */
>>> >>      #define AMDGPU_VM_MTYPE_RW             (5 << 5)
>>> >>     +/* don't allocate MALL */
>>> >>     +#define AMDGPU_VM_PAGE_NOALLOC         (1 << 9)
>>> >>
>>> >>      struct drm_amdgpu_gem_va {
>>> >>             /** GEM object handle */
>>> >>     --
>>> >>     2.25.1
>>> >>
>>> >
>>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 10235 bytes --]

  reply	other threads:[~2022-05-16 11:06 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-06 11:23 [PATCH 1/3] drm/amdgpu: add AMDGPU_GEM_CREATE_DISCARDABLE Christian König
2022-05-06 11:23 ` [PATCH 2/3] drm/amdgpu: add AMDGPU_VM_NOALLOC Christian König
2022-05-10 21:21   ` Marek Olšák
2022-05-11  6:06     ` Christian König
2022-05-11  6:15       ` Lazar, Lijo
2022-05-11  7:22         ` Marek Olšák
2022-05-11  7:43           ` Christian König
2022-05-11 18:55             ` Marek Olšák
2022-05-16 11:06               ` Marek Olšák [this message]
2022-05-16 11:10                 ` Marek Olšák
2022-05-16 11:53                   ` Christian König
2022-05-16 12:56                     ` Marek Olšák
2022-05-16 16:13                       ` Christian König
2022-05-17  0:12                         ` Marek Olšák
2022-05-17  6:33                           ` Christian König
2022-05-18  8:28                             ` Christian König
2022-05-06 11:23 ` [PATCH 3/3] drm/amdgpu: bump minor version number Christian König
2022-05-06 13:34   ` Alex Deucher
2022-05-12  2:38     ` Marek Olšák
2022-05-06 15:04 ` [PATCH 1/3] drm/amdgpu: add AMDGPU_GEM_CREATE_DISCARDABLE Felix Kuehling
2022-05-10 20:13 ` Marek Olšák
2022-05-10 20:43   ` Marek Olšák
2022-05-11  6:04     ` Christian König
2022-05-11  7:08       ` Marek Olšák
2022-05-11 21:58         ` Marek Olšák
2022-05-11 22:06           ` Marek Olšák
2022-05-12  7:25             ` Christian König
2022-05-12 22:17               ` Marek Olšák
2022-05-13 11:24                 ` Christian König
     [not found]                 ` <62165c7c-892a-5b35-79dd-b90414ccb5cd@damsy.net>
2022-05-13 11:26                   ` Christian König
2022-07-08 14:58                     ` Marek Olšák
2022-07-11 10:15                       ` Christian König

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=CAAxE2A5yVDo-6HW9Jt_pO-VwnBFQXQJP9-r0kNThP5XO1KWkFw@mail.gmail.com \
    --to=maraeo@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=lijo.lazar@amd.com \
    /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;
as well as URLs for NNTP newsgroup(s).