From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: "Christian König" <christian.koenig@amd.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 08/15] drm/i915/ttm Add a generic TTM memcpy move for page-based iomem
Date: Tue, 18 May 2021 14:04:48 +0200 [thread overview]
Message-ID: <45054121-954d-f20c-52b5-f375db7096e0@linux.intel.com> (raw)
In-Reply-To: <6149ee00-fa4a-3757-117a-8d622eb42070@amd.com>
On 5/18/21 1:55 PM, Christian König wrote:
>
>
> Am 18.05.21 um 10:26 schrieb Thomas Hellström:
>> The internal ttm_bo_util memcpy uses vmap functionality, and while it
>> probably might be possible to use it for copying in- and out of
>> sglist represented io memory, using io_mem_reserve() / io_mem_free()
>> callbacks, that would cause problems with fault().
>> Instead, implement a method mapping page-by-page using kmap_local()
>> semantics. As an additional benefit we then avoid the occasional global
>> TLB flushes of vmap() and consuming vmap space, elimination of a
>> critical
>> point of failure and with a slight change of semantics we could also
>> push
>> the memcpy out async for testing and async driver develpment purposes.
>> Pushing out async can be done since there is no memory allocation
>> going on
>> that could violate the dma_fence lockdep rules.
>>
>> For copies from iomem, use the WC prefetching memcpy variant for
>> additional speed.
>>
>> Note that drivers that don't want to use struct io_mapping but relies on
>> memremap functionality, and that don't want to use scatterlists for
>> VRAM may well define specialized (hopefully reusable) iterators for
>> their
>> particular environment.
>
> In general yes please since I have that as TODO for TTM for a very
> long time.
>
> But I would prefer to fix the implementation in TTM instead and give
> it proper cursor handling.
>
> Amdgpu is also using page based iomem and we are having similar
> workarounds in place there as well.
>
> I think it makes sense to unify this inside TTM and remove the old
> memcpy util function when done.
>
> Regards,
> Christian.
Christian,
I was thinking when we replace the bo.mem with a pointer (and perhaps
have a driver callback to allocate the bo->mem,
we could perhaps embed a struct ttm_kmap_iter and use it for all mapping
in one way or another). That would mean perhaps land this is i915 now
and sort out the unification once the struct ttm_resource, struct
ttm_buffer_object separation has landed?
/Thomas
WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: "Christian König" <christian.koenig@amd.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/ttm Add a generic TTM memcpy move for page-based iomem
Date: Tue, 18 May 2021 14:04:48 +0200 [thread overview]
Message-ID: <45054121-954d-f20c-52b5-f375db7096e0@linux.intel.com> (raw)
In-Reply-To: <6149ee00-fa4a-3757-117a-8d622eb42070@amd.com>
On 5/18/21 1:55 PM, Christian König wrote:
>
>
> Am 18.05.21 um 10:26 schrieb Thomas Hellström:
>> The internal ttm_bo_util memcpy uses vmap functionality, and while it
>> probably might be possible to use it for copying in- and out of
>> sglist represented io memory, using io_mem_reserve() / io_mem_free()
>> callbacks, that would cause problems with fault().
>> Instead, implement a method mapping page-by-page using kmap_local()
>> semantics. As an additional benefit we then avoid the occasional global
>> TLB flushes of vmap() and consuming vmap space, elimination of a
>> critical
>> point of failure and with a slight change of semantics we could also
>> push
>> the memcpy out async for testing and async driver develpment purposes.
>> Pushing out async can be done since there is no memory allocation
>> going on
>> that could violate the dma_fence lockdep rules.
>>
>> For copies from iomem, use the WC prefetching memcpy variant for
>> additional speed.
>>
>> Note that drivers that don't want to use struct io_mapping but relies on
>> memremap functionality, and that don't want to use scatterlists for
>> VRAM may well define specialized (hopefully reusable) iterators for
>> their
>> particular environment.
>
> In general yes please since I have that as TODO for TTM for a very
> long time.
>
> But I would prefer to fix the implementation in TTM instead and give
> it proper cursor handling.
>
> Amdgpu is also using page based iomem and we are having similar
> workarounds in place there as well.
>
> I think it makes sense to unify this inside TTM and remove the old
> memcpy util function when done.
>
> Regards,
> Christian.
Christian,
I was thinking when we replace the bo.mem with a pointer (and perhaps
have a driver callback to allocate the bo->mem,
we could perhaps embed a struct ttm_kmap_iter and use it for all mapping
in one way or another). That would mean perhaps land this is i915 now
and sort out the unification once the struct ttm_resource, struct
ttm_buffer_object separation has landed?
/Thomas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-05-18 12:04 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-18 8:26 [PATCH v2 00/15] drm/i915: Move LMEM (VRAM) management over to TTM Thomas Hellström
2021-05-18 8:26 ` [Intel-gfx] " Thomas Hellström
2021-05-18 8:26 ` [PATCH v2 01/15] drm/i915: Untangle the vma pages_mutex Thomas Hellström
2021-05-18 8:26 ` [Intel-gfx] " Thomas Hellström
2021-05-18 11:12 ` Maarten Lankhorst
2021-05-18 11:12 ` [Intel-gfx] " Maarten Lankhorst
2021-05-18 11:28 ` Thomas Hellström
2021-05-18 11:28 ` [Intel-gfx] " Thomas Hellström
2021-05-18 8:26 ` [PATCH v2 02/15] drm/i915: Don't free shared locks while shared Thomas Hellström
2021-05-18 8:26 ` [Intel-gfx] " Thomas Hellström
2021-05-18 11:18 ` Maarten Lankhorst
2021-05-18 11:18 ` [Intel-gfx] " Maarten Lankhorst
2021-05-18 11:30 ` Thomas Hellström (Intel)
2021-05-18 11:30 ` Thomas Hellström (Intel)
2021-05-18 8:26 ` [PATCH v2 03/15] drm/i915: Fix i915_sg_page_sizes to record dma segments rather than physical pages Thomas Hellström
2021-05-18 8:26 ` [Intel-gfx] " Thomas Hellström
2021-05-18 8:46 ` Matthew Auld
2021-05-18 8:46 ` Matthew Auld
2021-05-18 8:26 ` [PATCH v2 04/15] drm/ttm: Export functions to initialize and finalize the ttm range manager standalone Thomas Hellström
2021-05-18 8:26 ` [Intel-gfx] " Thomas Hellström
2021-05-18 9:03 ` Daniel Vetter
2021-05-18 9:03 ` [Intel-gfx] " Daniel Vetter
2021-05-18 11:51 ` Christian König
2021-05-18 11:51 ` [Intel-gfx] " Christian König
2021-05-18 13:06 ` Thomas Hellström
2021-05-18 13:06 ` [Intel-gfx] " Thomas Hellström
2021-05-18 13:11 ` Christian König
2021-05-18 13:11 ` [Intel-gfx] " Christian König
2021-05-18 8:26 ` [PATCH v2 05/15] drm/i915/ttm Initialize the ttm device and memory managers Thomas Hellström
2021-05-18 8:26 ` [Intel-gfx] " Thomas Hellström
2021-05-18 9:05 ` Matthew Auld
2021-05-18 9:05 ` Matthew Auld
2021-05-18 9:09 ` Matthew Auld
2021-05-18 9:09 ` Matthew Auld
2021-05-18 9:12 ` Thomas Hellström
2021-05-18 9:12 ` Thomas Hellström
2021-05-18 8:26 ` [PATCH v2 06/15] drm/i915/ttm: Embed a ttm buffer object in the i915 gem object Thomas Hellström
2021-05-18 8:26 ` [Intel-gfx] " Thomas Hellström
2021-05-18 11:44 ` Maarten Lankhorst
2021-05-18 11:44 ` [Intel-gfx] " Maarten Lankhorst
2021-05-18 8:26 ` [PATCH v2 07/15] drm/ttm: Export ttm_bo_tt_destroy() Thomas Hellström
2021-05-18 8:26 ` [Intel-gfx] " Thomas Hellström
2021-05-18 11:46 ` Maarten Lankhorst
2021-05-18 11:46 ` [Intel-gfx] " Maarten Lankhorst
2021-05-18 12:01 ` Christian König
2021-05-18 12:01 ` [Intel-gfx] " Christian König
2021-05-18 8:26 ` [PATCH v2 08/15] drm/i915/ttm Add a generic TTM memcpy move for page-based iomem Thomas Hellström
2021-05-18 8:26 ` [Intel-gfx] " Thomas Hellström
2021-05-18 11:55 ` Christian König
2021-05-18 11:55 ` [Intel-gfx] " Christian König
2021-05-18 12:04 ` Thomas Hellström [this message]
2021-05-18 12:04 ` Thomas Hellström
2021-05-18 12:09 ` Christian König
2021-05-18 12:09 ` [Intel-gfx] " Christian König
2021-05-18 12:52 ` Thomas Hellström
2021-05-18 12:52 ` [Intel-gfx] " Thomas Hellström
2021-05-18 13:08 ` Christian König
2021-05-18 13:08 ` [Intel-gfx] " Christian König
2021-05-18 13:24 ` Thomas Hellström
2021-05-18 13:24 ` [Intel-gfx] " Thomas Hellström
2021-05-18 13:26 ` Christian König
2021-05-18 13:26 ` [Intel-gfx] " Christian König
2021-05-18 8:26 ` [PATCH v2 09/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping Thomas Hellström
2021-05-18 8:26 ` [Intel-gfx] " Thomas Hellström
2021-05-18 12:19 ` Maarten Lankhorst
2021-05-18 12:19 ` Maarten Lankhorst
2021-05-18 15:15 ` Thomas Hellström
2021-05-18 15:15 ` [Intel-gfx] " Thomas Hellström
2021-05-18 15:18 ` Christian König
2021-05-18 15:18 ` [Intel-gfx] " Christian König
2021-05-18 15:20 ` Thomas Hellström
2021-05-18 15:20 ` [Intel-gfx] " Thomas Hellström
2021-05-18 15:28 ` Christian König
2021-05-18 15:28 ` [Intel-gfx] " Christian König
2021-05-18 15:38 ` Thomas Hellström
2021-05-18 15:38 ` [Intel-gfx] " Thomas Hellström
2021-05-18 15:42 ` Christian König
2021-05-18 15:42 ` [Intel-gfx] " Christian König
2021-05-18 16:07 ` Thomas Hellström
2021-05-18 16:07 ` [Intel-gfx] " Thomas Hellström
2021-05-18 16:30 ` Christian König
2021-05-18 16:30 ` [Intel-gfx] " Christian König
2021-05-19 6:27 ` Thomas Hellström
2021-05-19 6:27 ` [Intel-gfx] " Thomas Hellström
2021-05-19 10:43 ` Christian König
2021-05-19 10:43 ` [Intel-gfx] " Christian König
2021-05-18 8:26 ` [PATCH v2 10/15] drm/i915/ttm: Introduce a TTM i915 gem object backend Thomas Hellström
2021-05-18 8:26 ` [Intel-gfx] " Thomas Hellström
2021-05-19 9:53 ` Matthew Auld
2021-05-19 9:53 ` Matthew Auld
2021-05-19 11:29 ` Thomas Hellström
2021-05-19 11:29 ` Thomas Hellström
2021-05-18 8:26 ` [PATCH v2 11/15] drm/i915/lmem: Verify checks for lmem residency Thomas Hellström
2021-05-18 8:26 ` [Intel-gfx] " Thomas Hellström
2021-05-19 10:04 ` Matthew Auld
2021-05-19 10:04 ` Matthew Auld
2021-05-18 8:26 ` [PATCH v2 12/15] drm/i915: Disable mmap ioctl for gen12+ Thomas Hellström
2021-05-18 8:26 ` [Intel-gfx] " Thomas Hellström
2021-05-18 8:41 ` Thomas Hellström
2021-05-18 8:41 ` Thomas Hellström
2021-05-18 8:26 ` [PATCH v2 13/15] drm/ttm: Add BO and offset arguments for vm_access and vm_fault ttm handlers Thomas Hellström
2021-05-18 8:26 ` [Intel-gfx] " Thomas Hellström
2021-05-18 8:59 ` Thomas Hellström
2021-05-18 8:59 ` Thomas Hellström
2021-05-18 11:59 ` Christian König
2021-05-18 11:59 ` Christian König
2021-05-18 14:59 ` Thomas Hellström
2021-05-18 14:59 ` Thomas Hellström
2021-05-18 8:27 ` [PATCH v2 14/15] drm/i915: Use ttm mmap handling for ttm bo's Thomas Hellström
2021-05-18 8:27 ` [Intel-gfx] " Thomas Hellström
2021-05-18 9:17 ` Thomas Hellström
2021-05-18 9:17 ` Thomas Hellström
2021-05-18 8:27 ` [PATCH v2 15/15] drm/i915/ttm: Add io sgt caching to i915_ttm_io_mem_pfn Thomas Hellström
2021-05-18 8:27 ` [Intel-gfx] " Thomas Hellström
2021-05-18 9:33 ` Thomas Hellström
2021-05-18 9:33 ` Thomas Hellström
2021-05-18 8:44 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Move LMEM (VRAM) management over to TTM (rev2) Patchwork
2021-05-18 8:47 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-05-18 9:14 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-05-18 17:02 ` [Intel-gfx] ✓ Fi.CI.IGT: success " 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=45054121-954d-f20c-52b5-f375db7096e0@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.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 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.