From: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>
To: <John.C.Harrison@Intel.com>, <Intel-GFX@Lists.FreeDesktop.Org>
Cc: DRI-Devel@Lists.FreeDesktop.Org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Don't use stolen memory for ring buffers
Date: Tue, 14 Feb 2023 17:56:47 -0800 [thread overview]
Message-ID: <e07ec6ca-dbd7-2f17-a99f-7b91a530d359@intel.com> (raw)
In-Reply-To: <20230214234856.744573-1-John.C.Harrison@Intel.com>
On 2/14/2023 3:48 PM, John.C.Harrison@Intel.com wrote:
> From: John Harrison <John.C.Harrison@Intel.com>
>
> Direction from hardware is that stolen memory should never be used for
> ring buffer allocations. There are too many caching pitfalls due to the
> way stolen memory accesses are routed. So it is safest to just not use
> it.
I'm wondering if this applies to machines in ringbuffer mode as well, as
some of the caching stuff that according to the HW team may not work
properly with stolen mem accesses from the CS (mocs, ppat) came with
gen8/gen9.
Maybe limit this change to gen8+, to avoid changing the behavior for
very old platforms?
>
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> ---
> drivers/gpu/drm/i915/gt/intel_ring.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c b/drivers/gpu/drm/i915/gt/intel_ring.c
> index 15ec64d881c44..d1a47e1ae6452 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring.c
> @@ -116,8 +116,6 @@ static struct i915_vma *create_ring_vma(struct i915_ggtt *ggtt, int size)
>
> obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE |
> I915_BO_ALLOC_PM_VOLATILE);
> - if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt))
> - obj = i915_gem_object_create_stolen(i915, size);
There is code in ring_pin/unpin() that only applies to rings in stolen
memory, so you need to remove that as well if you drop stolen for rings
on all platforms.
Daniele
> if (IS_ERR(obj))
> obj = i915_gem_object_create_internal(i915, size);
> if (IS_ERR(obj))
next prev parent reply other threads:[~2023-02-15 1:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-14 23:48 [Intel-gfx] [PATCH] drm/i915: Don't use stolen memory for ring buffers John.C.Harrison
2023-02-15 0:31 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2023-02-15 1:56 ` Ceraolo Spurio, Daniele [this message]
2023-02-15 12:30 ` [Intel-gfx] [PATCH] " Tvrtko Ursulin
2023-02-15 12:06 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " 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=e07ec6ca-dbd7-2f17-a99f-7b91a530d359@intel.com \
--to=daniele.ceraolospurio@intel.com \
--cc=DRI-Devel@Lists.FreeDesktop.Org \
--cc=Intel-GFX@Lists.FreeDesktop.Org \
--cc=John.C.Harrison@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