From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>,
Michael Cheng <michael.cheng@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
Matthew Auld <matthew.auld@intel.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2 1/1] i915/gem: drop wbinvd_on_all_cpus usage
Date: Mon, 20 Jun 2022 09:22:41 +0200 [thread overview]
Message-ID: <69097036fb05d93b0f4cbf96e49df55aad26df79.camel@linux.intel.com> (raw)
In-Reply-To: <20220617233023.6y4itjzycqjcoqfa@ldmartin-desk2>
Hi,
On Fri, 2022-06-17 at 16:30 -0700, Lucas De Marchi wrote:
> On Thu, Apr 14, 2022 at 11:19:23AM -0700, Michael Cheng wrote:
> > Previous concern with using drm_clflush_sg was that we don't know
> > what the
> > sg_table is pointing to, thus the usage of wbinvd_on_all_cpus to
> > flush
> > everything at once to avoid paranoia.
>
> humn... and now we know it is backed by struct pages? I'm not sure I
> follow what we didn't know before and now we do.
>
> Thomas / Matthew, could you take another look herer if it seems
> correct
> to you.
>
>
No, this isn't correct. A dma-buf sg-table may not be backed by struct
pages, and AFAIK, there is no way for the importer to tell, whether
that's the case or not.
If we need to get rid of the wbinvd_on_all_cpus here, we need to use
the dma_buf_vmap() function to obtain a virtual address and then use
drm_clflush_virt_range() on that address. After that clflush, we can
call dma_buf_vunmap(). This should work since x86 uses PIPT caches and
a flush to a virtual range should flush all other virtual ranges
pointing to the same pages as well.
/Thomas
> thanks
> Lucas De Marchi
>
>
> > To make i915 more architecture-neutral and be less paranoid, lets
> > attempt to
> > use drm_clflush_sg to flush the pages for when the GPU wants to
> > read
> > from main memory.
> >
> > Signed-off-by: Michael Cheng <michael.cheng@intel.com>
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 ++-------
> > 1 file changed, 2 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > index f5062d0c6333..b0a5baaebc43 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > @@ -8,6 +8,7 @@
> > #include <linux/highmem.h>
> > #include <linux/dma-resv.h>
> > #include <linux/module.h>
> > +#include <drm/drm_cache.h>
> >
> > #include <asm/smp.h>
> >
> > @@ -250,16 +251,10 @@ static int
> > i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
> > * DG1 is special here since it still snoops transactions
> > even with
> > * CACHE_NONE. This is not the case with other HAS_SNOOP
> > platforms. We
> > * might need to revisit this as we add new discrete
> > platforms.
> > - *
> > - * XXX: Consider doing a vmap flush or something, where
> > possible.
> > - * Currently we just do a heavy handed wbinvd_on_all_cpus()
> > here since
> > - * the underlying sg_table might not even point to struct
> > pages, so we
> > - * can't just call drm_clflush_sg or similar, like we do
> > elsewhere in
> > - * the driver.
> > */
> > if (i915_gem_object_can_bypass_llc(obj) ||
> > (!HAS_LLC(i915) && !IS_DG1(i915)))
> > - wbinvd_on_all_cpus();
> > + drm_clflush_sg(pages);
> >
> > sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
> > __i915_gem_object_set_pages(obj, pages, sg_page_sizes);
> > --
> > 2.25.1
> >
next prev parent reply other threads:[~2022-06-20 7:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-14 18:19 [Intel-gfx] [PATCH v2 0/1] Drop wbinvd_on_all_cpus usage Michael Cheng
2022-04-14 18:19 ` [Intel-gfx] [PATCH v2 1/1] i915/gem: drop " Michael Cheng
2022-06-17 23:30 ` Lucas De Marchi
2022-06-20 7:22 ` Thomas Hellström [this message]
2022-04-14 21:22 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Drop " Patchwork
2022-04-14 21:42 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-04-15 3:28 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2022-04-14 18:10 [Intel-gfx] [PATCH v2 0/1] Michael Cheng
2022-04-14 18:10 ` [Intel-gfx] [PATCH v2 1/1] i915/gem: drop wbinvd_on_all_cpus usage Michael Cheng
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=69097036fb05d93b0f4cbf96e49df55aad26df79.camel@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.auld@intel.com \
--cc=michael.cheng@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