Re: [Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed, Oct 26, 2016 at 4:37 PM, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote:
On Wed, Oct 26, 2016 at 04:17:45PM +0100, Robert Bragg wrote:
> On 26 Oct 2016 9:54 a.m., "Chris Wilson" <chris@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Wed, Oct 26, 2016 at 12:51:58AM +0100, Robert Bragg wrote:
> > >    On Tue, Oct 25, 2016 at 10:35 PM, Matthew Auld
> > >    <[1]matthew.william.auld@gmail.com> wrote:
> > >
> > >      On 25 October 2016 at 00:19, Robert Bragg <[2]robert@xxxxxxxxxxxxx>
> > >      wrote:
> > >
> > >
> > >
> > >      > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > >      b/drivers/gpu/drm/i915/i915_drv.h
> > >      > index 3448d05..ea24814 100644
> > >      > --- a/drivers/gpu/drm/i915/i915_drv.h
> > >      > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > >      > @@ -1764,6 +1764,11 @@ struct intel_wm_config {
> > >
> > >      >
> > >      >  struct drm_i915_private {
> > >      > @@ -2149,16 +2164,46 @@ struct drm_i915_private {
> > >      >
> > >      >         struct {
> > >      >                 bool initialized;
> > >      > +
> > >      >                 struct mutex lock;
> > >      >                 struct list_head streams;
> > >      >
> > >      > +               spinlock_t hook_lock;
> > >      > +
> > >      >                 struct {
> > >      > -                       u32 metrics_set;
> > >      > +                       struct i915_perf_stream
> *exclusive_stream;

OT:
What kind of MUA are you using that mangles quoted mails like this? I've
not seen it on intel-gfx before. mesa-dev seems rife with it, but as I
rarely read that in any great detail I've managed to ignore it there.
Anyways, it makes it espesially hard to navigate long mails since mutt's
'S' (skip quoted text) no longer works correctly.

Not sure I want to say, and get booted out the door :-)

I've heard that gmail has an annoying habit of forcibly wrapping plain text emails like this, and a lot of people have complained that there's no way to disable that 'feature' :-/

I used to use Mutt, but I don't think I could really bare to go back to it any more. Last time I was using it I found myself spending too much time patching it to try and make it work how I'd like, but can't say I got much enjoyment from that process.

I've tried most MUA options available, and can't say any of them make me very happy - I think these days it's just not something developers are very interesting in working on.

I'm a sell out and just use Gmail... sorry. I can't really see myself changing, though I do wish Google weren't so pedantic about forcing wrapping without any option to change that behaviour. I suspect you wouldn't be happy with me sending html emails, which has been Google's default response to this complaint afik.

Maybe it's gmail users causing trouble on the Mesa list too.

- Robert

P.S please don't think lesser of me due to my misguided MUA choices.

 

> > >      > +
> > >      > +                       u32 specific_ctx_id;
> > >      Can we just get rid of this, now that the vma remains pinned we can
> > >      simply get the ggtt address at the time of configuring the
> OA_CONTROL
> > >      register ?
> > >
> > >    I considered that, but would ideally prefer to keep it considering
> the
> > >    gen8+ patches to come. For gen8+ (with execlists) the context ID
> isn't a
> > >    gtt offset.
> >
> > In terms of symmetry, keeping the vma you pinned and unpinning the same
> > later makes its ownership much clearer. (And I do want the owner of each
> > pin to be clear, for when we start enabling debug to catch the VMA
> > leaks.)
>
> Keeping our own pointer to the pinned vma could be a clarification.
>
> Considering Matt's comments too, I'm thinking I'll put the pinning and
> specific_ctx_id initialization together with setting stream->ctx, keeping
> the state together under the stream. It's going to potentially mean
> redundantly pinning the ctx for the sake of the ID in the future for
> streams that don't really need it, but I think it's probably not worth
> worrying about that.
>
> - Robert
>
> > -Chris
> >
> > --
> > Chris Wilson, Intel Open Source Technology Centre

> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


--
Ville Syrjälä
Intel OTC

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux