All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Michael Cheng <michael.cheng@intel.com>, intel-gfx@lists.freedesktop.org
Cc: thomas.hellstrom@linux.intel.com, wayne.boyer@intel.com,
	daniel.vetter@ffwll.ch, casey.g.bowman@intel.com,
	lucas.demarchi@intel.com, dri-devel@lists.freedesktop.org,
	chris@chris-wilson.co.uk
Subject: Re: [PATCH 1/4] i915/gem: drop wbinvd_on_all_cpus usage
Date: Mon, 21 Mar 2022 10:30:18 +0000	[thread overview]
Message-ID: <fc7c729b-5c87-f046-04dd-7ca8296487dd@linux.intel.com> (raw)
In-Reply-To: <20220319194227.297639-2-michael.cheng@intel.com>


On 19/03/2022 19:42, 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.

And now we know, or we know it is not a concern?

> To make i915 more architecture-neutral and be less paranoid, lets attempt to

"Lets attempt" as we don't know if this will work and/or what can/will 
break?

> 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);

And as noticed before, drm_clfush_sg still can call wbinvd_on_all_cpus 
so are you just punting the issue somewhere else? How will it be solved 
there?

Regards,

Tvrtko

>   
>   	sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
>   	__i915_gem_object_set_pages(obj, pages, sg_page_sizes);

WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Michael Cheng <michael.cheng@intel.com>, intel-gfx@lists.freedesktop.org
Cc: thomas.hellstrom@linux.intel.com, daniel.vetter@ffwll.ch,
	lucas.demarchi@intel.com, dri-devel@lists.freedesktop.org,
	chris@chris-wilson.co.uk
Subject: Re: [Intel-gfx] [PATCH 1/4] i915/gem: drop wbinvd_on_all_cpus usage
Date: Mon, 21 Mar 2022 10:30:18 +0000	[thread overview]
Message-ID: <fc7c729b-5c87-f046-04dd-7ca8296487dd@linux.intel.com> (raw)
In-Reply-To: <20220319194227.297639-2-michael.cheng@intel.com>


On 19/03/2022 19:42, 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.

And now we know, or we know it is not a concern?

> To make i915 more architecture-neutral and be less paranoid, lets attempt to

"Lets attempt" as we don't know if this will work and/or what can/will 
break?

> 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);

And as noticed before, drm_clfush_sg still can call wbinvd_on_all_cpus 
so are you just punting the issue somewhere else? How will it be solved 
there?

Regards,

Tvrtko

>   
>   	sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
>   	__i915_gem_object_set_pages(obj, pages, sg_page_sizes);

  reply	other threads:[~2022-03-21 10:30 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-19 19:42 [PATCH 0/4] Drop wbinvd_on_all_cpus usage Michael Cheng
2022-03-19 19:42 ` [Intel-gfx] " Michael Cheng
2022-03-19 19:42 ` [PATCH 1/4] i915/gem: drop " Michael Cheng
2022-03-19 19:42   ` [Intel-gfx] " Michael Cheng
2022-03-21 10:30   ` Tvrtko Ursulin [this message]
2022-03-21 10:30     ` Tvrtko Ursulin
2022-03-21 11:07     ` Thomas Hellström
2022-03-21 11:07       ` [Intel-gfx] " Thomas Hellström
2022-03-21 18:51       ` Michael Cheng
2022-03-21 18:51         ` [Intel-gfx] " Michael Cheng
2022-03-21 16:31     ` Michael Cheng
2022-03-21 16:31       ` [Intel-gfx] " Michael Cheng
2022-03-21 17:28       ` Tvrtko Ursulin
2022-03-21 17:28         ` [Intel-gfx] " Tvrtko Ursulin
2022-03-21 17:42         ` Michael Cheng
2022-03-21 17:42           ` [Intel-gfx] " Michael Cheng
2022-03-22 14:35           ` Daniel Vetter
2022-03-22 14:35             ` Daniel Vetter
2022-03-21 17:51         ` Michael Cheng
2022-03-21 17:51           ` [Intel-gfx] " Michael Cheng
2022-03-19 19:42 ` [PATCH 2/4] Revert "drm/i915/gem: Almagamate clflushes on suspend" Michael Cheng
2022-03-19 19:42   ` [Intel-gfx] " Michael Cheng
2022-03-19 19:42 ` [PATCH 3/4] i915/gem: Revert i915_gem_freeze to previous logic Michael Cheng
2022-03-19 19:42   ` [Intel-gfx] " Michael Cheng
2022-03-19 19:42 ` [PATCH 4/4] drm/i915/gt: Revert ggtt_resume " Michael Cheng
2022-03-19 19:42   ` [Intel-gfx] " Michael Cheng
2022-03-19 20:15 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Drop wbinvd_on_all_cpus usage Patchwork
2022-03-19 20:16 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-03-19 20:45 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-19 22:04 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-03-21 10:27 ` [PATCH 0/4] " Tvrtko Ursulin
2022-03-21 10:27   ` [Intel-gfx] " Tvrtko Ursulin
2022-03-21 11:03   ` Thomas Hellström
2022-03-21 11:03     ` [Intel-gfx] " Thomas Hellström
2022-03-21 12:22     ` Tvrtko Ursulin
2022-03-21 12:22       ` [Intel-gfx] " Tvrtko Ursulin
2022-03-21 12:33       ` Thomas Hellström
2022-03-21 12:33         ` [Intel-gfx] " Thomas Hellström
2022-03-21 13:12         ` Tvrtko Ursulin
2022-03-21 13:12           ` [Intel-gfx] " Tvrtko Ursulin
2022-03-21 13:40           ` Thomas Hellström
2022-03-21 13:40             ` [Intel-gfx] " Thomas Hellström
2022-03-21 14:43             ` Tvrtko Ursulin
2022-03-21 14:43               ` [Intel-gfx] " Tvrtko Ursulin
2022-03-21 15:15               ` Thomas Hellström
2022-03-21 15:15                 ` [Intel-gfx] " Thomas Hellström
2022-03-22 10:13                 ` Tvrtko Ursulin
2022-03-22 10:13                   ` [Intel-gfx] " Tvrtko Ursulin
2022-03-22 10:26                   ` Thomas Hellström
2022-03-22 10:26                     ` [Intel-gfx] " Thomas Hellström
2022-03-22 10:41                     ` Thomas Hellström
2022-03-22 10:41                       ` [Intel-gfx] " Thomas Hellström
2022-03-22 11:20                     ` Tvrtko Ursulin
2022-03-22 11:20                       ` [Intel-gfx] " Tvrtko Ursulin
2022-03-22 11:37                       ` Thomas Hellström
2022-03-22 11:37                         ` [Intel-gfx] " Thomas Hellström
2022-03-22 12:53                         ` Tvrtko Ursulin
2022-03-22 12:53                           ` [Intel-gfx] " Tvrtko Ursulin
2022-03-22 15:07                           ` Thomas Hellström
2022-03-22 15:07                             ` [Intel-gfx] " Thomas Hellström

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=fc7c729b-5c87-f046-04dd-7ca8296487dd@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=casey.g.bowman@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=michael.cheng@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=wayne.boyer@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 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.