From: Francisco Jerez <currojerez@riseup.net>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Disable atomics in L3 for gen9
Date: Tue, 23 Jul 2019 15:19:13 -0700 [thread overview]
Message-ID: <87pnm0qtr2.fsf@riseup.net> (raw)
In-Reply-To: <156388293186.31349.1576327527372090940@skylake-alporthouse-com>
[-- Attachment #1.1.1: Type: text/plain, Size: 2755 bytes --]
Chris Wilson <chris@chris-wilson.co.uk> writes:
> Quoting Tvrtko Ursulin (2019-07-22 12:41:36)
>>
>> On 20/07/2019 15:31, Chris Wilson wrote:
>> > Enabling atomic operations in L3 leads to unrecoverable GPU hangs, as
>> > the machine stops responding milliseconds after receipt of the reset
>> > request [GDRT]. By disabling the cached atomics, the hang do not occur
>> > and we presume the GPU would reset normally for similar hangs.
>> >
>> > Reported-by: Jason Ekstrand <jason@jlekstrand.net>
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110998
>> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> > Cc: Jason Ekstrand <jason@jlekstrand.net>
>> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>> > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> > ---
>> > Jason reports that Windows is not clearing L3SQCREG4:22 and does not
>> > suffer the same GPU hang so it is likely some other w/a that interacts
>> > badly. Fwiw, these 3 are the only registers I could find that mention
>> > atomic ops (and appear to be part of the same chain for memory access).
>>
>> Bit-toggling itself looks fine to me and matches what I could find in
>> the docs. (All three bits across three registers should be equal.)
>>
>> What I am curious about is what are the other consequences of disabling
>> L3 atomics? Performance drop somewhere?
>
> The test I have where it goes from dead to passing, that's a considerable
> performance improvement ;)
>
> I imagine not being able to use L3 for atomics is pretty dire, whether that
> has any impact, I have no clue.
>
> It is still very likely that we see this because we are doing something
> wrong elsewhere.
This reminds me of f3fc4884ebe6ae649d3723be14b219230d3b7fd2 followed by
d351f6d94893f3ba98b1b20c5ef44c35fc1da124 due to the massive impact (of
the order of 20x IIRC) using the L3 turned out to have on the
performance of HDC atomics, on at least that platform. It seems
unfortunate that we're going to lose L3 atomics on Gen9 now, even though
it's only buffer atomics which are broken IIUC, and even though the
Windows driver is somehow getting away without disabling them. Some of
our setup must be wrong either in the kernel or in userspace... Are
these registers at least whitelisted so userspace can re-enable L3
atomics once the problem is addressed? Wouldn't it be a more specific
workaround for userspace to simply use a non-L3-cacheable MOCS for
(rarely used) buffer surfaces, so it could benefit from L3 atomics
elsewhere?
> -Chris
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-07-23 22:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-20 14:31 [PATCH] drm/i915: Disable atomics in L3 for gen9 Chris Wilson
2019-07-20 15:10 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-07-20 16:23 ` ✓ Fi.CI.IGT: " Patchwork
2019-07-22 11:41 ` [PATCH] " Tvrtko Ursulin
2019-07-23 11:55 ` Chris Wilson
2019-07-23 22:19 ` Francisco Jerez [this message]
2019-07-24 14:34 ` Chris Wilson
2019-07-24 20:02 ` Francisco Jerez
2020-11-09 19:52 ` [Intel-gfx] " Jason Ekstrand
2020-11-09 20:15 ` Chris Wilson
2020-11-09 20:48 ` Ville Syrjälä
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=87pnm0qtr2.fsf@riseup.net \
--to=currojerez@riseup.net \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=tvrtko.ursulin@linux.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.