All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/9] Emulated coherent graphics memory v2
@ 2019-04-24 12:00 Thomas Hellstrom
  2019-04-24 12:00   ` Thomas Hellstrom
                   ` (8 more replies)
  0 siblings, 9 replies; 24+ messages in thread
From: Thomas Hellstrom @ 2019-04-24 12:00 UTC (permalink / raw)
  To: Linux-graphics-maintainer, dri-devel
  Cc: Pv-drivers, linux-kernel, Thomas Hellstrom, Andrew Morton,
	Matthew Wilcox, Will Deacon, Peter Zijlstra, Rik van Riel,
	Minchan Kim, Michal Hocko, Huang Ying, Souptick Joarder,
	Jérôme Glisse, Christian König, linux-mm

Graphics APIs like OpenGL 4.4 and Vulkan require the graphics driver
to provide coherent graphics memory, meaning that the GPU sees any
content written to the coherent memory on the next GPU operation that
touches that memory, and the CPU sees any content written by the GPU
to that memory immediately after any fence object trailing the GPU
operation has signaled.

Paravirtual drivers that otherwise require explicit synchronization
needs to do this by hooking up dirty tracking to pagefault handlers
and buffer object validation. This is a first attempt to do that for
the vmwgfx driver.

The mm patches has been out for RFC. I think I have addressed all the
feedback I got, except a possible softdirty breakage. But although the
dirty-tracking and softdirty may write-protect PTEs both care about,
that shouldn't really cause any operation interference. In particular
since we use the hardware dirty PTE bits and softdirty uses other PTE bits.

For the TTM changes they are hopefully in line with the long-term
strategy of making helpers out of what's left of TTM.

The code has been tested and excercised by a tailored version of mesa
where we disable all explicit synchronization and assume graphics memory
is coherent. The performance loss varies of course; a typical number is
around 5%.

Any feedback greatly appreciated.

Changes v1-v2:
- Addressed a number of typos and formatting issues.
- Added a usage warning for apply_to_pfn_range() and apply_to_page_range()
- Re-evaluated the decision to use apply_to_pfn_range() rather than
  modifying the pagewalk.c. It still looks like generically handling the
  transparent huge page cases requires the mmap_sem to be held at least
  in read mode, so sticking with apply_to_pfn_range() for now.
- The TTM page-fault helper vma copy argument was scratched in favour of
  a pageprot_t argument.
  
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Souptick Joarder <jrdr.linux@gmail.com>
Cc: "Jérôme Glisse" <jglisse@redhat.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: linux-mm@kvack.org

^ permalink raw reply	[flat|nested] 24+ messages in thread
* Re: [PATCH 4/9] drm/ttm: Allow the driver to provide the ttm struct vm_operations_struct
@ 2019-04-25  9:11 Koenig, Christian
  0 siblings, 0 replies; 24+ messages in thread
From: Koenig, Christian @ 2019-04-25  9:11 UTC (permalink / raw)
  To: Thomas Hellstrom
  Cc: Pv-drivers, Linux-graphics-maintainer, linux-kernel, dri-devel


[-- Attachment #1.1: Type: text/plain, Size: 4729 bytes --]



Am 25.04.2019 10:35 schrieb Thomas Hellstrom <thellstrom@vmware.com>:
Hi, Christian,

On Wed, 2019-04-24 at 16:20 +0200, Thomas Hellström wrote:
> On Wed, 2019-04-24 at 14:10 +0000, Koenig, Christian wrote:
> > Am 24.04.19 um 14:00 schrieb Thomas Hellstrom:
> > > Add a pointer to the struct vm_operations_struct in the
> > > bo_device,
> > > and
> > > assign that pointer to the default value currently used.
> > >
> > > The driver can then optionally modify that pointer and the new
> > > value
> > > can be used for each new vma created.
> > >
> > > Cc: "Christian König" <christian.koenig@amd.com>
> > >
> > > Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
> > > Reviewed-by: Christian König <christian.koenig@amd.com>
> >
> > Going to pick those two TTM patches up for amd-staging-drm-next.
>
> Will you be relying on either patch for related work? Otherwise it
> would be simpler for us to use vmwgfx-next for the whole series,
> targeting 5.3.
>
> Thomas

Is this OK with you?

I wanted to base some cleanup work on this, but this can wait as well.

So fine with me to merge this through vmwgfx-next.

Regards,
Christian.


Thanks,
Thomas



>
> > Christian.
> >
> > > ---
> > >   drivers/gpu/drm/ttm/ttm_bo.c    | 1 +
> > >   drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 +++---
> > >   include/drm/ttm/ttm_bo_driver.h | 6 ++++++
> > >   3 files changed, 10 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
> > > b/drivers/gpu/drm/ttm/ttm_bo.c
> > > index 3f56647cdb35..1c85bec00472 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > > @@ -1656,6 +1656,7 @@ int ttm_bo_device_init(struct ttm_bo_device
> > > *bdev,
> > >    mutex_lock(&ttm_global_mutex);
> > >    list_add_tail(&bdev->device_list, &glob->device_list);
> > >    mutex_unlock(&ttm_global_mutex);
> > > + bdev->vm_ops = &ttm_bo_vm_ops;
> > >
> > >    return 0;
> > >   out_no_sys:
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > index e86a29a1e51f..bfb25b81fed7 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > @@ -395,7 +395,7 @@ static int ttm_bo_vm_access(struct
> > > vm_area_struct *vma, unsigned long addr,
> > >    return ret;
> > >   }
> > >
> > > -static const struct vm_operations_struct ttm_bo_vm_ops = {
> > > +const struct vm_operations_struct ttm_bo_vm_ops = {
> > >    .fault = ttm_bo_vm_fault,
> > >    .open = ttm_bo_vm_open,
> > >    .close = ttm_bo_vm_close,
> > > @@ -445,7 +445,7 @@ int ttm_bo_mmap(struct file *filp, struct
> > > vm_area_struct *vma,
> > >    if (unlikely(ret != 0))
> > >            goto out_unref;
> > >
> > > - vma->vm_ops = &ttm_bo_vm_ops;
> > > + vma->vm_ops = bdev->vm_ops;
> > >
> > >    /*
> > >     * Note: We're transferring the bo reference to
> > > @@ -477,7 +477,7 @@ int ttm_fbdev_mmap(struct vm_area_struct
> > > *vma,
> > > struct ttm_buffer_object *bo)
> > >
> > >    ttm_bo_get(bo);
> > >
> > > - vma->vm_ops = &ttm_bo_vm_ops;
> > > + vma->vm_ops = bo->bdev->vm_ops;
> > >    vma->vm_private_data = bo;
> > >    vma->vm_flags |= VM_MIXEDMAP;
> > >    vma->vm_flags |= VM_IO | VM_DONTEXPAND;
> > > diff --git a/include/drm/ttm/ttm_bo_driver.h
> > > b/include/drm/ttm/ttm_bo_driver.h
> > > index cbf3180cb612..cfeaff5d9706 100644
> > > --- a/include/drm/ttm/ttm_bo_driver.h
> > > +++ b/include/drm/ttm/ttm_bo_driver.h
> > > @@ -443,6 +443,9 @@ extern struct ttm_bo_global {
> > >    * @driver: Pointer to a struct ttm_bo_driver struct setup by
> > > the
> > > driver.
> > >    * @man: An array of mem_type_managers.
> > >    * @vma_manager: Address space manager
> > > + * @vm_ops: Pointer to the struct vm_operations_struct used for
> > > this
> > > + * device's VM operations. The driver may override this before
> > > the
> > > first
> > > + * mmap() call.
> > >    * lru_lock: Spinlock that protects the buffer+device lru lists
> > > and
> > >    * ddestroy lists.
> > >    * @dev_mapping: A pointer to the struct address_space
> > > representing the
> > > @@ -461,6 +464,7 @@ struct ttm_bo_device {
> > >    struct ttm_bo_global *glob;
> > >    struct ttm_bo_driver *driver;
> > >    struct ttm_mem_type_manager man[TTM_NUM_MEM_TYPES];
> > > + const struct vm_operations_struct *vm_ops;
> > >
> > >    /*
> > >     * Protected by internal locks.
> > > @@ -489,6 +493,8 @@ struct ttm_bo_device {
> > >    bool no_retry;
> > >   };
> > >
> > > +extern const struct vm_operations_struct ttm_bo_vm_ops;
> > > +
> > >   /**
> > >    * struct ttm_lru_bulk_move_pos
> > >    *


[-- Attachment #1.2: Type: text/html, Size: 8246 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 24+ messages in thread
* [PATCH 0/9] Emulated coherent graphics memory
@ 2019-04-12 16:04 Thomas Hellstrom
  2019-04-12 16:04 ` [PATCH 4/9] drm/ttm: Allow the driver to provide the ttm struct vm_operations_struct Thomas Hellstrom
  0 siblings, 1 reply; 24+ messages in thread
From: Thomas Hellstrom @ 2019-04-12 16:04 UTC (permalink / raw)
  To: dri-devel, Linux-graphics-maintainer, linux-kernel
  Cc: Thomas Hellstrom, Andrew Morton, Matthew Wilcox, Will Deacon,
	Peter Zijlstra, Rik van Riel, Minchan Kim, Michal Hocko,
	Huang Ying, Souptick Joarder, Jérôme Glisse,
	Christian König, linux-mm

Graphics APIs like OpenGL 4.4 and Vulkan require the graphics driver
to provide coherent graphics memory, meaning that the GPU sees any
content written to the coherent memory on the next GPU operation that
touches that memory, and the CPU sees any content written by the GPU
to that memory immediately after any fence object trailing the GPU
operation has signaled.

Paravirtual drivers that otherwise require explicit synchronization
needs to do this by hooking up dirty tracking to pagefault handlers
and buffer object validation. This is a first attempt to do that for
the vmwgfx driver.

The mm patches has been out for RFC. I think I have addressed all the
feedback I got, except a possible softdirty breakage. But although the
dirty-tracking and softdirty may write-protect PTEs both care about,
that shouldn't really cause any operation interference. In particular
since we use the hardware dirty PTE bits and softdirty uses other PTE bits.

For the TTM changes they are hopefully in line with the long-term
strategy of making helpers out of what's left of TTM.

The code has been tested and excercised by a tailored version of mesa
where we disable all explicit synchronization and assume graphics memory
is coherent. The performance loss varies of course; a typical number is
around 5%.

Any feedback greatly appreciated.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Souptick Joarder <jrdr.linux@gmail.com>
Cc: "Jérôme Glisse" <jglisse@redhat.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: linux-mm@kvack.org

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2019-04-29 17:17 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-24 12:00 [PATCH 0/9] Emulated coherent graphics memory v2 Thomas Hellstrom
2019-04-24 12:00 ` [PATCH 1/9] mm: Allow the [page|pfn]_mkwrite callbacks to drop the mmap_sem v2 Thomas Hellstrom
2019-04-24 12:00   ` Thomas Hellstrom
2019-04-24 12:00 ` [PATCH 2/9] mm: Add an apply_to_pfn_range interface v2 Thomas Hellstrom
2019-04-24 12:00   ` Thomas Hellstrom
2019-04-24 12:00 ` [PATCH 3/9] mm: Add write-protect and clean utilities for address space ranges v2 Thomas Hellstrom
2019-04-27 15:01   ` [PATCH 3/9] mm: Add write-protect and clean utilities for address space ranges v3 Thomas Hellstrom
2019-04-27 15:01     ` Thomas Hellstrom
2019-04-29 17:17     ` Ralph Campbell
2019-04-24 12:00 ` [PATCH 4/9] drm/ttm: Allow the driver to provide the ttm struct vm_operations_struct Thomas Hellstrom
2019-04-24 12:00   ` Thomas Hellstrom
2019-04-24 14:10   ` Koenig, Christian
2019-04-24 14:20     ` Thomas Hellstrom
2019-04-25  8:35       ` Thomas Hellstrom
2019-04-24 12:00 ` [PATCH 5/9] drm/ttm: TTM fault handler helpers v2 Thomas Hellstrom
2019-04-24 12:00 ` [PATCH 6/9] drm/vmwgfx: Implement an infrastructure for write-coherent resources v2 Thomas Hellstrom
2019-04-24 12:00   ` Thomas Hellstrom
2019-04-24 12:00 ` [PATCH 7/9] drm/vmwgfx: Use an RBtree instead of linked list for MOB resources Thomas Hellstrom
2019-04-24 12:00 ` [PATCH 8/9] drm/vmwgfx: Implement an infrastructure for read-coherent resources v2 Thomas Hellstrom
2019-04-24 12:00 ` [PATCH 9/9] drm/vmwgfx: Add surface dirty-tracking callbacks v2 Thomas Hellstrom
  -- strict thread matches above, loose matches on Subject: below --
2019-04-25  9:11 [PATCH 4/9] drm/ttm: Allow the driver to provide the ttm struct vm_operations_struct Koenig, Christian
2019-04-12 16:04 [PATCH 0/9] Emulated coherent graphics memory Thomas Hellstrom
2019-04-12 16:04 ` [PATCH 4/9] drm/ttm: Allow the driver to provide the ttm struct vm_operations_struct Thomas Hellstrom
2019-04-13 18:39   ` Koenig, Christian
2019-04-13 18:39     ` Koenig, Christian

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.