From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Alan Previn Teres Alexis <alan.previn.teres.alexis@intel.com>,
Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915/selftests: Fix engine reset count storage for multi-tile
Date: Thu, 7 Dec 2023 13:45:56 +0000 [thread overview]
Message-ID: <8b4cec4c-8d39-4fd0-8e2d-f66f89527117@linux.intel.com> (raw)
In-Reply-To: <ZXGwjTj3vsI6NAcI@ashyti-mobl2.lan>
On 07/12/2023 11:46, Andi Shyti wrote:
> On Thu, Dec 07, 2023 at 11:43:28AM +0000, Tvrtko Ursulin wrote:
>>
>> On 07/12/2023 11:26, Andi Shyti wrote:
>>> Hi Tvrtko,
>>>
>>>> Engine->id namespace is per-tile so struct igt_live_test->reset_engine[]
>>>> needs to be two-dimensional so engine reset counts from all tiles can be
>>>> stored with no aliasing. With aliasing, if we had a real multi-tile
>>>> platform, the reset counts would be incorrect for same engine instance on
>>>> different tiles.
>>>>
>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>> Fixes: 0c29efa23f5c ("drm/i915/selftests: Consider multi-gt instead of to_gt()")
>>>> Reported-by: Alan Previn Teres Alexis <alan.previn.teres.alexis@intel.com>
>>>> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com>
>>>> Cc: Andi Shyti <andi.shyti@linux.intel.com>
>>>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>>>
>>> sorry for being late here... the patch makes sense to me and the
>>> CI failures don't look related.
>>>
>>> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
>>
>> Thanks pushed!
>>
>> There is more work to be done with the fact i915_reset_engine_count has it's
>> own aliasing when used like this, but I opted to leave that for some other
>> time.
>
> feel free to share if you have some preparatory work done already
> and I can try to help out. Otherwise I can take a look at it, as
> well.
I don't have any patches I was just noticed when doing this that even
though i915_reset_engine_count takes the engine as parameter, the
i915->gpu_error is a single gt construct and as such I think using
i915_reset_engine_count from per gt selftests is a mismatch.
I thought options were to add engine reset counts in the engine itself
and use that from selftests. Leaving i915_reset_engine_count to be used
from error capture paths. And it probably needs to be renamed
accordingly so it is not misleading.
But then there may be issues around virtual engines though which this
helper conveniently and quietly side stepped.
At that point I stopped thinking about it, given how real multi-tile for
i915 is not happening, I didn't see it worth the effort. Still the sour
taste of a mess remains so if you can think of an elegant and relatively
cheap solution I think it would be good to tidy.
Regards,
Tvrtko
prev parent reply other threads:[~2023-12-07 13:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-01 12:21 [Intel-gfx] [PATCH 1/2] drm/i915/selftests: Fix engine reset count storage for multi-tile Tvrtko Ursulin
2023-12-01 12:21 ` [Intel-gfx] [PATCH 2/2] drm/i915: Use internal class when counting engine resets Tvrtko Ursulin
2023-12-06 0:52 ` Daniele Ceraolo Spurio
2023-12-07 11:12 ` Tvrtko Ursulin
2023-12-01 23:08 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/selftests: Fix engine reset count storage for multi-tile Patchwork
2023-12-01 23:08 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-12-01 23:17 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-12-03 4:32 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-12-04 19:40 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/selftests: Fix engine reset count storage for multi-tile (rev2) Patchwork
2023-12-04 19:40 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-12-04 20:01 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-12-05 1:24 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-12-07 11:26 ` [PATCH 1/2] drm/i915/selftests: Fix engine reset count storage for multi-tile Andi Shyti
2023-12-07 11:43 ` Tvrtko Ursulin
2023-12-07 11:46 ` Andi Shyti
2023-12-07 13:45 ` Tvrtko Ursulin [this message]
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=8b4cec4c-8d39-4fd0-8e2d-f66f89527117@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=alan.previn.teres.alexis@intel.com \
--cc=andi.shyti@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=tvrtko.ursulin@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