From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
To: Nirmoy Das <nirmoy.das@intel.com>, <intel-xe@lists.freedesktop.org>
Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>,
"Brian Welty" <brian.welty@intel.com>,
Fei Yang <fei.yang@intel.com>, Jose Souza <jose.souza@intel.com>,
Matt Roper <matthew.d.roper@intel.com>,
Matthew Brost <matthew.brost@intel.com>,
Michal Mrozek <michal.mrozek@intel.com>,
Oak Zeng <oak.zeng@intel.com>,
Thomas Hellstr_m <thomas.hellstrom@linux.intel.com>
Subject: Re: [PATCH v6 0/5] Refactor default device atomic settings
Date: Fri, 3 May 2024 12:47:54 +0300 [thread overview]
Message-ID: <6fbb932b-9525-4fce-9376-30f422da703d@intel.com> (raw)
In-Reply-To: <20240430162529.21588-1-nirmoy.das@intel.com>
Hi Nirmoy,
I've updated our Mesa MR for this :
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28823
But then I started to wonder if we needed to do anything at all with
this v6.
The only scenario I'm not sure about is this : a BO is created with 2
placements LMEM+SMEM. When Xe migrates the BO from LMEM to SMEM due to
LMEM pressure, does it set AE bit in the PTE?
And then if promoted back to LMEM, is the PTE config DM=1 and AE=0 again?
Thanks,
-Lionel
On 30/04/2024 19:25, Nirmoy Das wrote:
> The default behavior of device atomics depends on the
> VM type and buffer allocation types. Device atomics are
> expected to function with all types of allocations for
> traditional applications/APIs. Additionally, in compute/SVM
> API scenarios with fault mode or LR mode VMs, device atomics
> must work with single-region allocations. In all other cases
> device atomics should be disabled by default. PVC needs special
> care as it doesn't support device atomics on SMEM.
>
> v6: Only check LR mode to determine compute API as fault
> mode requires LR mode(Jose)
> Set AE=1 on SMEM+LMEM allocation when a buffer is migrated
> to LMEM from SMEM(Brian)
>
> v5: Fix broken atomics on PVC from v4 changes.
>
> v4: Previous assumption that device atomics should be disabled
> by default on SMEM only BO was wrong as traditional applications
> will not use such allocations for CPU atomics. So remove the
> VM bind flag and the query uAPI and instead refactor default device
> atomics settings as per VM type and buffer allocations.
>
>
> v3: Capture ret value of xe_vm_bind_ioctl_validate_bo(Matt B).
> Remove redundant coh_mode param from xe_vm_bind_ioctl_validate_bo().
> Remove has_device_atomics_on_smem from xe_graphics_desc(Jose).
> Replace DRM_XE_QUERY_CONFIG_SUPP_DEV_ATOMIC_ON_SMEM with
> config flag DRM_XE_QUERY_CONFIG_FLAG_HAS_DEV_ATOMIC_ON_SMEM(Jose).
> Mention that PTE_AE will not be applied to userptr(Matt R)
>
> v2: Add BO helper func in xe_vm_bind_ioctl()(Matt B).
> Use XE_IOCTL_DBG for checks(Matt B).
> Move platform checks with help of adding flags in
> intel_device_info(Matt B).
> Add document for DRM_XE_VM_BIND_FLAG_DEVICE_ATOMICS(Matt B).
> Create query uAPI for this newly added VM bind flag(Jose, Lionel).
>
> Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
> Cc: Brian Welty <brian.welty@intel.com>
> Cc: Fei Yang <fei.yang@intel.com>
> Cc: Jose Souza <jose.souza@intel.com>
> Cc: Lionel G Landwerlin <lionel.g.landwerlin@intel.com>
> Cc: Matt Roper <matthew.d.roper@intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: Michal Mrozek <michal.mrozek@intel.com>
> Cc: Oak Zeng <oak.zeng@intel.com>
> Cc: Thomas Hellstr_m <thomas.hellstrom@linux.intel.com>
>
> Nirmoy Das (5):
> drm/xe: Introduce has_atomic_enable_pte_bit device info
> drm/xe: Move vm bind bo validation to a helper function
> drm/xe: Introduce has_device_atomics_on_smem device info
> drm/xe: Add function to check if BO has single placement
> drm/xe: Refactor default device atomic settings
>
> drivers/gpu/drm/xe/xe_bo.c | 14 +++++
> drivers/gpu/drm/xe/xe_bo.h | 1 +
> drivers/gpu/drm/xe/xe_device_types.h | 4 ++
> drivers/gpu/drm/xe/xe_pci.c | 5 ++
> drivers/gpu/drm/xe/xe_pci_types.h | 1 +
> drivers/gpu/drm/xe/xe_pt.c | 37 +++++++++++--
> drivers/gpu/drm/xe/xe_vm.c | 79 ++++++++++++++++------------
> 7 files changed, 103 insertions(+), 38 deletions(-)
>
next prev parent reply other threads:[~2024-05-03 9:47 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 16:25 [PATCH v6 0/5] Refactor default device atomic settings Nirmoy Das
2024-04-30 16:25 ` [PATCH v6 1/5] drm/xe: Introduce has_atomic_enable_pte_bit device info Nirmoy Das
2024-04-30 16:25 ` [PATCH v6 2/5] drm/xe: Move vm bind bo validation to a helper function Nirmoy Das
2024-04-30 16:25 ` [PATCH v6 3/5] drm/xe: Introduce has_device_atomics_on_smem device info Nirmoy Das
2024-04-30 16:25 ` [PATCH v6 4/5] drm/xe: Add function to check if BO has single placement Nirmoy Das
2024-04-30 16:25 ` [PATCH v6 5/5] drm/xe: Refactor default device atomic settings Nirmoy Das
2024-05-03 15:39 ` Zeng, Oak
2024-05-03 16:00 ` Nirmoy Das
2024-05-03 16:11 ` Zeng, Oak
2024-05-03 16:30 ` Nirmoy Das
2024-04-30 18:47 ` ✓ CI.Patch_applied: success for Refactor default device atomic settings (rev6) Patchwork
2024-04-30 18:48 ` ✓ CI.checkpatch: " Patchwork
2024-04-30 18:49 ` ✓ CI.KUnit: " Patchwork
2024-04-30 19:00 ` ✓ CI.Build: " Patchwork
2024-04-30 19:03 ` ✓ CI.Hooks: " Patchwork
2024-04-30 19:04 ` ✓ CI.checksparse: " Patchwork
2024-04-30 19:28 ` ✓ CI.BAT: " Patchwork
2024-04-30 22:20 ` ✓ CI.FULL: " Patchwork
2024-05-03 9:47 ` Lionel Landwerlin [this message]
2024-05-03 9:54 ` [PATCH v6 0/5] Refactor default device atomic settings Nirmoy Das
2024-05-06 7:13 ` Lionel Landwerlin
2024-05-06 9:25 ` Lionel Landwerlin
2024-05-06 16:21 ` Nirmoy Das
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=6fbb932b-9525-4fce-9376-30f422da703d@intel.com \
--to=lionel.g.landwerlin@intel.com \
--cc=balasubramani.vivekanandan@intel.com \
--cc=brian.welty@intel.com \
--cc=fei.yang@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jose.souza@intel.com \
--cc=matthew.brost@intel.com \
--cc=matthew.d.roper@intel.com \
--cc=michal.mrozek@intel.com \
--cc=nirmoy.das@intel.com \
--cc=oak.zeng@intel.com \
--cc=thomas.hellstrom@linux.intel.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