From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
To: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Chris Wilson <chris.p.wilson@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Use i915_gem_object_pin_map_unlocked function for lmem allocation
Date: Tue, 18 Jan 2022 17:15:57 +0200 [thread overview]
Message-ID: <20220118151557.GA15803@intel.com> (raw)
In-Reply-To: <CAM0jSHPXSMQ83TRi2kygb5W7HGxvO1daB2GU9+CJUEJ4NtSewQ@mail.gmail.com>
On Tue, Jan 18, 2022 at 01:45:10PM +0000, Matthew Auld wrote:
> On Fri, 14 Jan 2022 at 08:25, Stanislav Lisovskiy
> <stanislav.lisovskiy@intel.com> wrote:
> >
> > Using i915_gem_object_pin_map_unlocked instead of
> > i915_gem_object_lmem_io_map, would eliminate the need
> > of using I915_BO_ALLOC_CONTIGUOUS, when calling
> > i915_vma_pin_iomap, because it supports non-contiguous
> > allocation as well.
> >
> > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_vma.c | 27 ++++++++++++++++++++-------
> > 1 file changed, 20 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> > index 1f15c3298112..194ad92013f6 100644
> > --- a/drivers/gpu/drm/i915/i915_vma.c
> > +++ b/drivers/gpu/drm/i915/i915_vma.c
> > @@ -547,10 +547,16 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
> > * of pages, that way we can also drop the
> > * I915_BO_ALLOC_CONTIGUOUS when allocating the object.
> > */
>
> Remove the TODO above also?
Yep, should remove
>
> > - if (i915_gem_object_is_lmem(vma->obj))
> > - ptr = i915_gem_object_lmem_io_map(vma->obj, 0,
> > - vma->obj->base.size);
> > - else
> > + if (i915_gem_object_is_lmem(vma->obj)) {
> > + ptr = (void __iomem *)
> > + i915_gem_object_pin_map_unlocked(vma->obj,
> > + I915_MAP_WC);
>
> Do you know if we need some kind of sanity check here to ensure that
> the vma->pages == obj->mm.pages, when dealing with LMEM? AFAIK the vma
> could in theory remap the pages, and here pin_map only cares about the
> obj->mm.pages? Maybe check if the vma is VIEW_NORMAL or something?
As I see i915_gem_object_pin_map_unlocked is basically just
calling i915_gem_object_pin_pages, which is also being called
by i915_vma_get_pages, which handles this by calling __i915_vma_get_pages.
It then checks if those need to be remapped based on ggtt_view.type.
So wondering if I just need to call __i915_vma_get_pages as well,
afterwards.
>
> > + if (IS_ERR(ptr)) {
> > + err = PTR_ERR(ptr);
> > + goto err;
> > + }
> > + ptr = page_pack_bits(ptr, 1);
>
> AFAIK, the guidance is to move away from pointer packing. Can we just
> make the iounmap check for is_lmem()?
Yes, will check this.
Stan
>
> > + } else
> > ptr = io_mapping_map_wc(&i915_vm_to_ggtt(vma->vm)->iomap,
> > vma->node.start,
> > vma->node.size);
> > @@ -560,7 +566,10 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
> > }
> >
> > if (unlikely(cmpxchg(&vma->iomap, NULL, ptr))) {
> > - io_mapping_unmap(ptr);
> > + if (page_unmask_bits(ptr))
> > + __i915_gem_object_release_map(vma->obj);
> > + else
> > + io_mapping_unmap(ptr);
> > ptr = vma->iomap;
> > }
> > }
> > @@ -574,7 +583,7 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
> > i915_vma_set_ggtt_write(vma);
> >
> > /* NB Access through the GTT requires the device to be awake. */
> > - return ptr;
> > + return page_mask_bits(ptr);
> >
> > err_unpin:
> > __i915_vma_unpin(vma);
> > @@ -1687,7 +1696,11 @@ static void __i915_vma_iounmap(struct i915_vma *vma)
> > if (vma->iomap == NULL)
> > return;
> >
> > - io_mapping_unmap(vma->iomap);
> > + if (page_unmask_bits(vma->iomap))
> > + __i915_gem_object_release_map(vma->obj);
> > + else
> > + io_mapping_unmap(vma->iomap);
> > +
> > vma->iomap = NULL;
> > }
> >
> > --
> > 2.24.1.485.gad05a3d8e5
> >
next prev parent reply other threads:[~2022-01-18 15:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-14 8:25 [Intel-gfx] [PATCH] drm/i915: Use i915_gem_object_pin_map_unlocked function for lmem allocation Stanislav Lisovskiy
2022-01-14 8:59 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2022-01-14 9:34 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-01-14 10:47 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-01-18 13:45 ` [Intel-gfx] [PATCH] " Matthew Auld
2022-01-18 15:15 ` Lisovskiy, Stanislav [this message]
2022-02-27 9:39 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Use i915_gem_object_pin_map_unlocked function for lmem allocation (rev2) Patchwork
2022-02-27 10:13 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-02-27 11:58 ` [Intel-gfx] ✗ Fi.CI.IGT: 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=20220118151557.GA15803@intel.com \
--to=stanislav.lisovskiy@intel.com \
--cc=chris.p.wilson@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.william.auld@gmail.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.