From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: "Souza, Jose" <jose.souza@intel.com>,
"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [Intel-xe] [PATCH 2/3] drm/xe: Add missing TLB invalidation to emit_pipe_invalidate()
Date: Wed, 31 May 2023 10:46:20 +0200 [thread overview]
Message-ID: <2aee91cb-d377-476d-dd82-65236a7ac9c7@linux.intel.com> (raw)
In-Reply-To: <faf59c70a4e046654d734fa77629971595dd7331.camel@intel.com>
On 5/30/23 20:40, Souza, Jose wrote:
> On Mon, 2023-05-29 at 17:07 +0200, Thomas Hellström wrote:
>> On 5/29/23 16:56, Thomas Hellström wrote:
>>> On 5/29/23 16:48, Souza, Jose wrote:
>>>> On Mon, 2023-05-29 at 11:08 +0200, Thomas Hellström wrote:
>>>>> On Fri, 2023-05-26 at 12:06 -0700, José Roberto de Souza wrote:
>>>>>> i915 invalidates TLB before emit BB start, so doing the same in Xe.
>>>>> Hi, José,
>>>>>
>>>>> Do you see an issue because of missing TLB flushes? In that case that
>>>>> needs to be added to the commit message. We do TLB flushes on unbind,
>>>>> but not sure if we do them on rebind, so if that's the issue we need to
>>>>> figure out whether we should do them also on rebind or, like in this
>>>>> patch, on each exec.
>>>> I have a group of tests that results flips randomly. It fails when
>>>> the rendered buffer is compared to expected result.
>>>> Anything that add a bit of delay after the exec fixes those tests so
>>>> I was looking for any missing flush in Xe KMD and Mesa.
>>>>
>>>> This one did not fixed it but as i915 was doing it I thought would be
>>>> good to do in Xe too.
>>> I think missing TLB invalidations are more likely to cause random
>>> overwrites of freed memory. Let me do a quick check on these. But the
>>> problem you're describing indeed sounds more like a missing render
>>> cache flush.
>>>
>> It indeed looks like we're doing proper TLB invalidation on both rebind
>> and unbind, so this patch shouldn't really be needed.
>>
>> (look for "invalidation_fence_init()")
> With this patch + PIPE_CONTROL flush at the end of batch buffer in Mesa, fixed the groups of the tests that were flipping results.
> Do a XE_GUC_ACTION_TLB_INVALIDATION is the same as a PIPE_CONTROL_TLB_INVALIDATE?
I would think so, yes, except that the GUC TLB invalidation is GT-wide
and I'm not sure whether PIPE_CONTROL_TLB_INVALIDATE is per hw engine or
per-GT.
But given this really has an impact, it might be that we need to
invalidate TLB also after a bind where we previously pointed to the
scratch page.
If that's indeed the culprit we should look at issuing a
PIPE_CONTROL_TLB_INVALIDATE on the exec following a bind or rebind, and
leave the GuC TLB invalidations for unbinds, and then this patch makes
sense as a start.
>
> Do you see any PIPE_CONTROL flush at the end of batch buffers that i915 does but Xe don't?
The emit_fini_breadcrumb() called from __i915_request_submit() indeed
seems to emit the flushes needed, whereas the corresponding
emit_pipe_imm_ggtt() in xe doesn't.
/Thomas
>
>> /Thomas
>>
>>> /Thomas
>>>
>>>>> Thanks,
>>>>> Thomas
>>>>>
>>>>>
>>>>>> Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
>>>>>> ---
>>>>>> drivers/gpu/drm/xe/regs/xe_gpu_commands.h | 1 +
>>>>>> drivers/gpu/drm/xe/xe_ring_ops.c | 6 ++++--
>>>>>> 2 files changed, 5 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/xe/regs/xe_gpu_commands.h
>>>>>> b/drivers/gpu/drm/xe/regs/xe_gpu_commands.h
>>>>>> index 0f9c5b0b8a3ba..7c7320efea739 100644
>>>>>> --- a/drivers/gpu/drm/xe/regs/xe_gpu_commands.h
>>>>>> +++ b/drivers/gpu/drm/xe/regs/xe_gpu_commands.h
>>>>>> @@ -73,6 +73,7 @@
>>>>>> #define
>>>>>> PIPE_CONTROL_STORE_DATA_INDEX (1<<21)
>>>>>> #define
>>>>>> PIPE_CONTROL_CS_STALL (1<<20)
>>>>>> #define PIPE_CONTROL_GLOBAL_SNAPSHOT_RESET (1<<19)
>>>>>> +#define PIPE_CONTROL_TLB_INVALIDATE (1<<18)
>>>>>> #define
>>>>>> PIPE_CONTROL_PSD_SYNC (1<<17)
>>>>>> #define
>>>>>> PIPE_CONTROL_QW_WRITE (1<<14)
>>>>>> #define PIPE_CONTROL_DEPTH_STALL (1<<13)
>>>>>> diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c
>>>>>> b/drivers/gpu/drm/xe/xe_ring_ops.c
>>>>>> index d2fa0b4c8bcc0..4f3ef39109b9b 100644
>>>>>> --- a/drivers/gpu/drm/xe/xe_ring_ops.c
>>>>>> +++ b/drivers/gpu/drm/xe/xe_ring_ops.c
>>>>>> @@ -37,7 +37,8 @@
>>>>>> PIPE_CONTROL_INDIRECT_STATE_DISABLE | \
>>>>>> PIPE_CONTROL_FLUSH_ENABLE | \
>>>>>> PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE | \
>>>>>> - PIPE_CONTROL_DC_FLUSH_ENABLE)
>>>>>> + PIPE_CONTROL_DC_FLUSH_ENABLE | \
>>>>>> + PIPE_CONTROL_TLB_INVALIDATE)
>>>>>> static u32 preparser_disable(bool state)
>>>>>> {
>>>>>> @@ -117,7 +118,8 @@ static int emit_pipe_invalidate(u32 mask_flags,
>>>>>> u32 *dw, int i)
>>>>>> PIPE_CONTROL_CONST_CACHE_INVALIDATE |
>>>>>> PIPE_CONTROL_STATE_CACHE_INVALIDATE |
>>>>>> PIPE_CONTROL_QW_WRITE |
>>>>>> - PIPE_CONTROL_STORE_DATA_INDEX;
>>>>>> + PIPE_CONTROL_STORE_DATA_INDEX |
>>>>>> + PIPE_CONTROL_TLB_INVALIDATE;
>>>>>> flags &= ~mask_flags;
next prev parent reply other threads:[~2023-05-31 8:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-26 19:06 [Intel-xe] [PATCH 1/3] drm/xe: Disable interruptable wait on xe_bo_move() José Roberto de Souza
2023-05-26 19:06 ` [Intel-xe] [PATCH 2/3] drm/xe: Add missing TLB invalidation to emit_pipe_invalidate() José Roberto de Souza
2023-05-29 9:08 ` Thomas Hellström
2023-05-29 14:48 ` Souza, Jose
2023-05-29 14:56 ` Thomas Hellström
2023-05-29 15:07 ` Thomas Hellström
2023-05-30 18:40 ` Souza, Jose
2023-05-31 8:46 ` Thomas Hellström [this message]
2023-06-01 19:26 ` Matt Roper
2023-06-01 21:09 ` Souza, Jose
2023-06-02 8:20 ` Lionel Landwerlin
[not found] ` <1ac84b94994b26ee20881de276d6349f16907716.camel@intel.com>
2023-06-02 8:36 ` [Intel-xe] Render cache flushes WAS " Thomas Hellström
2023-05-26 19:06 ` [Intel-xe] [PATCH 3/3] drm/xe: Replace PVC check by engine type check José Roberto de Souza
2023-05-29 9:10 ` Thomas Hellström
2023-05-26 19:08 ` [Intel-xe] ✓ CI.Patch_applied: success for series starting with [1/3] drm/xe: Disable interruptable wait on xe_bo_move() Patchwork
2023-05-26 19:10 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-05-26 19:14 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-05-26 19:42 ` [Intel-xe] ○ CI.BAT: info " Patchwork
2023-05-29 8:59 ` [Intel-xe] [PATCH 1/3] " Thomas Hellström
2023-05-29 10:31 ` Thomas Hellström
2023-05-29 14:40 ` Souza, Jose
2023-05-29 14:46 ` Thomas Hellström
2023-05-29 16:48 ` Souza, Jose
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=2aee91cb-d377-476d-dd82-65236a7ac9c7@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jose.souza@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