From: "Coelho, Luciano" <luciano.coelho@intel.com>
To: "ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>,
"Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
"Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [Intel-xe] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank
Date: Wed, 29 Nov 2023 08:22:55 +0000 [thread overview]
Message-ID: <2aa59475fa2c896cbe2719bfa85a23e34448f861.camel@intel.com> (raw)
In-Reply-To: <0830e5605419105eb649874b535735b0f0891384.camel@intel.com>
On Fri, 2023-11-17 at 17:15 +0000, Zanoni, Paulo R wrote:
> On Fri, 2023-11-17 at 11:50 -0500, Rodrigo Vivi wrote:
> > On Fri, Nov 17, 2023 at 11:26:44AM +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 17, 2023 at 10:41:43AM +0200, Ville Syrjälä wrote:
> > > > On Fri, Nov 17, 2023 at 08:05:21AM +0000, Coelho, Luciano wrote:
> > > > > Thanks for your comments, Ville!
> > > > >
> > > > > On Fri, 2023-11-17 at 09:19 +0200, Ville Syrjälä wrote:
> > > > > > On Thu, Nov 16, 2023 at 01:27:00PM +0200, Luca Coelho wrote:
> > > > > > > Since we're abstracting the display code from the underlying driver
> > > > > > > (i.e. i915 vs xe), we can't use the uncore's spinlock to protect
> > > > > > > critical sections of our code.
> > > > > > >
> > > > > > > After further inspection, it seems that the spinlock is not needed at
> > > > > > > all and this can be handled by disabling preemption and interrupts
> > > > > > > instead.
> > > > > >
> > > > > > uncore.lock has multiple purposes:
> > > > > > 1. serialize all register accesses to the same cacheline as on
> > > > > > certain platforms that can hang the machine
> > > > >
> > > > > Okay, do you remember which platforms?
> > > >
> > > > HSW is the one I remember for sure being affected.
> > > > Althoguh I don't recall if I ever managed to hang it
> > > > using display registers specifically. intel_gpu_top
> > > > certainly was very good at reproducing the problem.
> > > >
> > > > > I couldn't find any reference to
> > > > > this reason.
> > > >
> > > > If all else fails git log is your friend.
> > >
> > > It seems to be documented in intel_uncore.h. Though that one
> > > mentions IVB instead of HSW for some reason. I don't recall
> > > seeing it on IVB myself, but I suppose it might have been an
> > > issue there as well. How long the problem remained after HSW
> > > I have no idea.
> >
> > Paulo very recently told me that he could easily reproduce the issue
> > on IVB, simply by running 2 glxgears at the same time.
>
> Just a minor correction: I didn't give the degree of confidence in my
> answer that the sentence above suggests :). It's all "as far as I
> remember". This is all from like 10 years ago and I can't remember what
> I had for lunch yesterday. Maybe it was some other similar bug that I
> could reproduce with glxgears. Also, the way we used registers was
> different back then, maybe today glxgears is not enough to do it
> anymore. And I think it required vblank_mode=0.
Great, thanks for this information! It's good to know the actual facts
for this implementation. So, we'll keep things mostly as they are,
without removing any locking and go back to my original version of this
implementation, which keeps the locking with i915.
--
Cheers,
Luca.
prev parent reply other threads:[~2023-11-29 8:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-16 11:27 [Intel-gfx] [PATCH] drm/i915: don't use uncore spinlock to protect critical section in vblank Luca Coelho
2023-11-16 16:03 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for " Patchwork
2023-11-17 7:19 ` [Intel-gfx] [Intel-xe] [PATCH] " Ville Syrjälä
2023-11-17 8:05 ` Coelho, Luciano
2023-11-17 8:41 ` Ville Syrjälä
2023-11-17 8:46 ` Coelho, Luciano
2023-11-17 9:26 ` Ville Syrjälä
2023-11-17 12:21 ` Coelho, Luciano
2023-11-17 12:46 ` Tvrtko Ursulin
2023-11-29 8:20 ` Coelho, Luciano
2023-11-17 16:50 ` Rodrigo Vivi
2023-11-17 17:15 ` Zanoni, Paulo R
2023-11-29 8:22 ` Coelho, Luciano [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=2aa59475fa2c896cbe2719bfa85a23e34448f861.camel@intel.com \
--to=luciano.coelho@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=paulo.r.zanoni@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=ville.syrjala@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox