From: Nirmoy Das <nirmoy.das@linux.intel.com>
To: "Souza, Jose" <jose.souza@intel.com>,
"Das, Nirmoy" <nirmoy.das@intel.com>,
"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH v5 5/5] drm/xe: Refactor default device atomic settings
Date: Mon, 29 Apr 2024 11:05:50 +0200 [thread overview]
Message-ID: <f68727e7-03db-44f8-b5eb-7ceed550eddc@linux.intel.com> (raw)
In-Reply-To: <ac8e78466a4a33e48f718781e47b15a7c5c73a1f.camel@intel.com>
Hi Jose,
On 4/26/2024 11:04 PM, Souza, Jose wrote:
> On Fri, 2024-04-26 at 12:56 +0200, 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 also on platforms
>> where we know device atomics doesn't on work on particular
>> allocations types.
>>
>> v2: Fix platform checks to correct atomics behaviour on PVC.
>>
>> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
>> ---
>> drivers/gpu/drm/xe/xe_pt.c | 27 ++++++++++++++++++++++++---
>> drivers/gpu/drm/xe/xe_vm.c | 2 +-
>> 2 files changed, 25 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c
>> index 5b7930f46cf3..237e4a4985a4 100644
>> --- a/drivers/gpu/drm/xe/xe_pt.c
>> +++ b/drivers/gpu/drm/xe/xe_pt.c
>> @@ -619,9 +619,30 @@ xe_pt_stage_bind(struct xe_tile *tile, struct xe_vma *vma,
>> struct xe_pt *pt = xe_vma_vm(vma)->pt_root[tile->id];
>> int ret;
>>
>> - if ((vma->gpuva.flags & XE_VMA_ATOMIC_PTE_BIT) &&
>> - (is_devmem || !IS_DGFX(xe)))
>> - xe_walk.default_pte |= XE_USM_PPGTT_PTE_AE;
>> + /**
>> + * Default atomic expectations for different allocation scenarios are as follows:
>> + *
>> + * 1. Traditional API: When the VM is not in fault mode or LR mode:
>> + * - Device atomics are expected to function with all allocations.
>> + *
>> + * 2. Compute/SVM API: When the VM is either in fault mode or LR mode:
>> + * - Device atomics are the default behavior when the bo is placed in a single region.
>> + * - In all other cases device atomics will be disabled with AE=0 until an application
>> + * request differently using a ioctl like madvise.
>> + */
>> + if (vma->gpuva.flags & XE_VMA_ATOMIC_PTE_BIT) {
>> + if (xe_vm_in_fault_mode(xe_vma_vm(vma)) ||
>> + xe_vm_in_lr_mode(xe_vma_vm(vma))) {
> nit: xe_vm_in_fault_mode requires xe_vm_in_lr_mode, so you can just check for the later.
Will do that. I think scratch page is also part of non-traditional API,
I will confirm that and add that if needed.
Thanks,
Nirmoy
>
>> + if (bo && xe_bo_has_single_placement(bo))
>> + xe_walk.default_pte |= XE_USM_PPGTT_PTE_AE;
>> + } else {
>> + xe_walk.default_pte |= XE_USM_PPGTT_PTE_AE;
>> + }
>> +
>> + /* Unset AE if the platform(PVC) doesn't support it */
>> + if (!xe->info.has_device_atomics_on_smem && !is_devmem)
>> + xe_walk.default_pte &= ~XE_USM_PPGTT_PTE_AE;
>> + }
>>
>> if (is_devmem) {
>> xe_walk.default_pte |= XE_PPGTT_PTE_DM;
>> diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
>> index 8fc37c5a0196..f795016a80d5 100644
>> --- a/drivers/gpu/drm/xe/xe_vm.c
>> +++ b/drivers/gpu/drm/xe/xe_vm.c
>> @@ -805,7 +805,7 @@ static struct xe_vma *xe_vma_create(struct xe_vm *vm,
>> for_each_tile(tile, vm->xe, id)
>> vma->tile_mask |= 0x1 << id;
>>
>> - if (GRAPHICS_VER(vm->xe) >= 20 || vm->xe->info.platform == XE_PVC)
>> + if (vm->xe->info.has_atomic_enable_pte_bit)
>> vma->gpuva.flags |= XE_VMA_ATOMIC_PTE_BIT;
>>
>> vma->pat_index = pat_index;
next prev parent reply other threads:[~2024-04-29 9:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 10:56 [PATCH v5 0/5] Refactor default device atomic settings Nirmoy Das
2024-04-26 10:56 ` [PATCH v5 1/5] drm/xe: Introduce has_atomic_enable_pte_bit device info Nirmoy Das
2024-04-26 10:56 ` [PATCH v5 2/5] drm/xe: Move vm bind bo validation to a helper function Nirmoy Das
2024-04-26 10:56 ` [PATCH v5 3/5] drm/xe: Introduce has_device_atomics_on_smem device info Nirmoy Das
2024-04-26 10:56 ` [PATCH v5 4/5] drm/xe: Add function to check if BO has single placement Nirmoy Das
2024-04-26 10:56 ` [PATCH v5 5/5] drm/xe: Refactor default device atomic settings Nirmoy Das
2024-04-26 21:04 ` Souza, Jose
2024-04-29 9:05 ` Nirmoy Das [this message]
2024-04-29 13:46 ` Souza, Jose
2024-04-29 14:15 ` Nirmoy Das
2024-04-26 12:49 ` ✓ CI.Patch_applied: success for Refactor default device atomic settings (rev3) Patchwork
2024-04-26 12:49 ` ✓ CI.checkpatch: " Patchwork
2024-04-26 12:50 ` ✓ CI.KUnit: " Patchwork
2024-04-26 13:05 ` ✓ CI.Build: " Patchwork
2024-04-26 13:08 ` ✓ CI.Hooks: " Patchwork
2024-04-26 13:09 ` ✓ CI.checksparse: " Patchwork
2024-04-26 13:40 ` ✓ CI.BAT: " Patchwork
2024-04-26 16:26 ` ✗ CI.FULL: failure " Patchwork
2024-04-26 20:41 ` ✓ CI.Patch_applied: success for Refactor default device atomic settings (rev4) Patchwork
2024-04-26 20:42 ` ✓ CI.checkpatch: " Patchwork
2024-04-26 20:43 ` ✓ CI.KUnit: " Patchwork
2024-04-29 9:11 ` ✗ CI.Patch_applied: failure for Refactor default device atomic settings (rev5) Patchwork
2024-04-29 15:43 ` [PATCH v5 0/5] Refactor default device atomic settings Mrozek, Michal
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=f68727e7-03db-44f8-b5eb-7ceed550eddc@linux.intel.com \
--to=nirmoy.das@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jose.souza@intel.com \
--cc=nirmoy.das@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.