Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Auld <matthew.auld@intel.com>
To: Matthew Brost <matthew.brost@intel.com>
Cc: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	thomas.hellstrom@linux.intel.com
Subject: Re: [RFC PATCH 1/1] drm/ttm, drm/xe: Add ttm_bo_access
Date: Mon, 21 Oct 2024 09:49:20 +0100	[thread overview]
Message-ID: <cd1c5f3b-8e43-40e8-9bbf-9995e4ab2b97@intel.com> (raw)
In-Reply-To: <ZxKL/RbKwq8iJ/gm@DUT025-TGLU.fm.intel.com>

On 18/10/2024 17:25, Matthew Brost wrote:
> On Fri, Oct 18, 2024 at 10:08:06AM +0100, Matthew Auld wrote:
>> On 18/10/2024 00:39, Matthew Brost wrote:
>>> Non-contiguous VRAM cannot be mapped in Xe nor can non-visible VRAM
>>> easily be accessed. Add ttm_bo_access, which is similar to
>>> ttm_bo_vm_access, to access such memory.
>>
>> Is the plan to roll this out also to object error capture and clear color
>> access? Those places seem to be using ttm vmap/kmap which only seems to work
>> with contiguous VRAM, but in those cases we are mapping userspace objects
>> which are potentially not contiguous so I assume that stuff is also quite
>> broken atm?
>>
> 
> I quickly sent this out without checking the error capture code, but
> that seems to be broken but no one is complaining? Seems odd.

It looks like we are also missing some IGTs for the vma dumpable stuff.

> 
> Let me look into this a bit more before posting a proper series. Will
> also update the error capture if needed.
> 
>>>
>>> Visible VRAM access is only supported at the momement but a follow up
>>> can add GPU access to non-visible VRAM.
>>>
>>> Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>>> ---
>>>    drivers/gpu/drm/ttm/ttm_bo_vm.c | 20 +++++++++-----
>>>    drivers/gpu/drm/xe/xe_bo.c      | 48 +++++++++++++++++++++++++++++++++
>>>    include/drm/ttm/ttm_bo.h        |  2 ++
>>>    3 files changed, 64 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>> index 2c699ed1963a..b53cc064da44 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>> @@ -405,13 +405,9 @@ static int ttm_bo_vm_access_kmap(struct ttm_buffer_object *bo,
>>>    	return len;
>>>    }
>>> -int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr,
>>> -		     void *buf, int len, int write)
>>> +int ttm_bo_access(struct ttm_buffer_object *bo, unsigned long offset,
>>> +		  void *buf, int len, int write)
>>>    {
>>> -	struct ttm_buffer_object *bo = vma->vm_private_data;
>>> -	unsigned long offset = (addr) - vma->vm_start +
>>> -		((vma->vm_pgoff - drm_vma_node_start(&bo->base.vma_node))
>>> -		 << PAGE_SHIFT);
>>>    	int ret;
>>>    	if (len < 1 || (offset + len) > bo->base.size)
>>> @@ -439,6 +435,18 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr,
>>>    	return ret;
>>>    }
>>> +EXPORT_SYMBOL(ttm_bo_access);
>>> +
>>> +int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr,
>>> +		     void *buf, int len, int write)
>>> +{
>>> +	struct ttm_buffer_object *bo = vma->vm_private_data;
>>> +	unsigned long offset = (addr) - vma->vm_start +
>>> +		((vma->vm_pgoff - drm_vma_node_start(&bo->base.vma_node))
>>> +		 << PAGE_SHIFT);
>>> +
>>> +	return ttm_bo_access(bo, offset, buf, len, write);
>>> +}
>>>    EXPORT_SYMBOL(ttm_bo_vm_access);
>>>    static const struct vm_operations_struct ttm_bo_vm_ops = {
>>> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
>>> index 5b232f2951b1..267f3b03a6d0 100644
>>> --- a/drivers/gpu/drm/xe/xe_bo.c
>>> +++ b/drivers/gpu/drm/xe/xe_bo.c
>>> @@ -1111,6 +1111,53 @@ static void xe_ttm_bo_swap_notify(struct ttm_buffer_object *ttm_bo)
>>>    	}
>>>    }
>>> +static int xe_ttm_access_memory(struct ttm_buffer_object *ttm_bo,
>>> +				unsigned long offset, void *buf, int len,
>>> +				int write)
>>> +{
>>> +	struct xe_bo *bo = ttm_to_xe_bo(ttm_bo);
>>> +	struct xe_device *xe = ttm_to_xe_device(ttm_bo->bdev);
>>> +	struct iosys_map vmap;
>>> +	struct xe_res_cursor cursor;
>>> +	struct xe_mem_region *vram;
>>> +	void __iomem *virtual;
>>> +	int bytes_left = len;
>>> +
>>> +	xe_bo_assert_held(bo);
>>
>> I think we need rpm somewhere? Although bo lock might make this tricky.
>>
> 
> Do we? OFC if we interact with hardware we should but also if hardware
> is powered off a BO shouldn't be in VRAM.

There is also d3hot which doesn't kick stuff out to system memory, but 
VRAM is still inaccessible in that mode.

> 
> Maybe do a get_if_awake and bail otherwise?
> 
> Matt
> 
>>> +
>>> +	if (!mem_type_is_vram(ttm_bo->resource->mem_type))
>>> +		return -EIO;
>>> +
>>> +	/* FIXME: Use GPU for non-visible VRAM */
>>> +	if (!(bo->flags & XE_BO_FLAG_NEEDS_CPU_ACCESS))
>>> +		return -EINVAL;
>>> +
>>> +	vram = res_to_mem_region(ttm_bo->resource);
>>> +	xe_res_first(ttm_bo->resource, offset & ~PAGE_MASK, 0, &cursor);
>>> +
>>> +	do {
>>> +		int wcount = PAGE_SIZE - (offset & PAGE_MASK) > bytes_left ?
>>> +			bytes_left : PAGE_SIZE - (offset & PAGE_MASK);
>>> +
>>> +		virtual = (u8 __force *)vram->mapping + cursor.start;
>>> +
>>> +		iosys_map_set_vaddr_iomem(&vmap, (void __iomem *)virtual);
>>> +		if (write)
>>> +			xe_map_memcpy_to(xe, &vmap, offset & PAGE_MASK, buf,
>>> +					 wcount);
>>> +		else
>>> +			xe_map_memcpy_from(xe, buf, &vmap, offset & PAGE_MASK,
>>> +					   wcount);
>>> +
>>> +		offset += wcount;
>>> +		buf += wcount;
>>> +		bytes_left -= wcount;
>>> +		xe_res_next(&cursor, PAGE_SIZE);
>>> +	} while (bytes_left);
>>> +
>>> +	return len;
>>> +}
>>> +
>>>    const struct ttm_device_funcs xe_ttm_funcs = {
>>>    	.ttm_tt_create = xe_ttm_tt_create,
>>>    	.ttm_tt_populate = xe_ttm_tt_populate,
>>> @@ -1120,6 +1167,7 @@ const struct ttm_device_funcs xe_ttm_funcs = {
>>>    	.move = xe_bo_move,
>>>    	.io_mem_reserve = xe_ttm_io_mem_reserve,
>>>    	.io_mem_pfn = xe_ttm_io_mem_pfn,
>>> +	.access_memory = xe_ttm_access_memory,
>>>    	.release_notify = xe_ttm_bo_release_notify,
>>>    	.eviction_valuable = ttm_bo_eviction_valuable,
>>>    	.delete_mem_notify = xe_ttm_bo_delete_mem_notify,
>>> diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h
>>> index 5804408815be..8ea11cd8df39 100644
>>> --- a/include/drm/ttm/ttm_bo.h
>>> +++ b/include/drm/ttm/ttm_bo.h
>>> @@ -421,6 +421,8 @@ void ttm_bo_unpin(struct ttm_buffer_object *bo);
>>>    int ttm_bo_evict_first(struct ttm_device *bdev,
>>>    		       struct ttm_resource_manager *man,
>>>    		       struct ttm_operation_ctx *ctx);
>>> +int ttm_bo_access(struct ttm_buffer_object *bo, unsigned long offset,
>>> +		  void *buf, int len, int write);
>>>    vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
>>>    			     struct vm_fault *vmf);
>>>    vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,

  reply	other threads:[~2024-10-21  8:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-17 23:39 [RFC PATCH 0/1] Enable non-contiguous VRAM access in Xe Matthew Brost
2024-10-17 23:39 ` [RFC PATCH 1/1] drm/ttm, drm/xe: Add ttm_bo_access Matthew Brost
2024-10-18  7:27   ` Thomas Hellström
2024-10-18  8:11     ` Matthew Brost
2024-10-18  9:08   ` Matthew Auld
2024-10-18 16:25     ` Matthew Brost
2024-10-21  8:49       ` Matthew Auld [this message]
2024-10-17 23:44 ` ✓ CI.Patch_applied: success for Enable non-contiguous VRAM access in Xe Patchwork
2024-10-17 23:44 ` ✓ CI.checkpatch: " Patchwork
2024-10-17 23:45 ` ✓ CI.KUnit: " Patchwork
2024-10-17 23:57 ` ✓ CI.Build: " Patchwork
2024-10-17 23:59 ` ✓ CI.Hooks: " Patchwork
2024-10-18  0:01 ` ✗ CI.checksparse: warning " Patchwork
2024-10-18  0:26 ` ✓ CI.BAT: success " Patchwork
2024-10-18 16:50 ` ✗ CI.FULL: failure " Patchwork

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=cd1c5f3b-8e43-40e8-9bbf-9995e4ab2b97@intel.com \
    --to=matthew.auld@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@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