<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 26, 2016 at 4:37 PM, Ville Syrjälä <span dir="ltr"><<a href="mailto:ville.syrjala@linux.intel.com" target="_blank">ville.syrjala@linux.intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Oct 26, 2016 at 04:17:45PM +0100, Robert Bragg wrote:<br>
> On 26 Oct 2016 9:54 a.m., "Chris Wilson" <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> wrote:<br>
> ><br>
> > On Wed, Oct 26, 2016 at 12:51:58AM +0100, Robert Bragg wrote:<br>
> > >    On Tue, Oct 25, 2016 at 10:35 PM, Matthew Auld<br>
> > >    <[1]<a href="mailto:matthew.william.auld@gmail.com">matthew.william.auld@<wbr>gmail.com</a>> wrote:<br>
> > ><br>
> > >      On 25 October 2016 at 00:19, Robert Bragg <[2]<a href="mailto:robert@sixbynine.org">robert@sixbynine.org</a>><br>
> > >      wrote:<br>
> > ><br>
> > ><br>
> > ><br>
> > >      > diff --git a/drivers/gpu/drm/i915/i915_<wbr>drv.h<br>
> > >      b/drivers/gpu/drm/i915/i915_<wbr>drv.h<br>
> > >      > index 3448d05..ea24814 100644<br>
> > >      > --- a/drivers/gpu/drm/i915/i915_<wbr>drv.h<br>
> > >      > +++ b/drivers/gpu/drm/i915/i915_<wbr>drv.h<br>
> > >      > @@ -1764,6 +1764,11 @@ struct intel_wm_config {<br>
> > ><br>
> > >      ><br>
> > >      >  struct drm_i915_private {<br>
> > >      > @@ -2149,16 +2164,46 @@ struct drm_i915_private {<br>
> > >      ><br>
> > >      >         struct {<br>
> > >      >                 bool initialized;<br>
> > >      > +<br>
> > >      >                 struct mutex lock;<br>
> > >      >                 struct list_head streams;<br>
> > >      ><br>
> > >      > +               spinlock_t hook_lock;<br>
> > >      > +<br>
> > >      >                 struct {<br>
> > >      > -                       u32 metrics_set;<br>
> > >      > +                       struct i915_perf_stream<br>
> *exclusive_stream;<br>
<br>
</div></div>OT:<br>
What kind of MUA are you using that mangles quoted mails like this? I've<br>
not seen it on intel-gfx before. mesa-dev seems rife with it, but as I<br>
rarely read that in any great detail I've managed to ignore it there.<br>
Anyways, it makes it espesially hard to navigate long mails since mutt's<br>
'S' (skip quoted text) no longer works correctly.<br></blockquote><div><br></div><div>Not sure I want to say, and get booted out the door :-)<br><br></div><div>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' :-/<br></div><div><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>Maybe it's gmail users causing trouble on the Mesa list too.<br></div><div><br></div><div>- Robert<br><br></div><div>P.S please don't think lesser of me due to my misguided MUA choices.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5"><br>
> > >      > +<br>
> > >      > +                       u32 specific_ctx_id;<br>
> > >      Can we just get rid of this, now that the vma remains pinned we can<br>
> > >      simply get the ggtt address at the time of configuring the<br>
> OA_CONTROL<br>
> > >      register ?<br>
> > ><br>
> > >    I considered that, but would ideally prefer to keep it considering<br>
> the<br>
> > >    gen8+ patches to come. For gen8+ (with execlists) the context ID<br>
> isn't a<br>
> > >    gtt offset.<br>
> ><br>
> > In terms of symmetry, keeping the vma you pinned and unpinning the same<br>
> > later makes its ownership much clearer. (And I do want the owner of each<br>
> > pin to be clear, for when we start enabling debug to catch the VMA<br>
> > leaks.)<br>
><br>
> Keeping our own pointer to the pinned vma could be a clarification.<br>
><br>
> Considering Matt's comments too, I'm thinking I'll put the pinning and<br>
> specific_ctx_id initialization together with setting stream->ctx, keeping<br>
> the state together under the stream. It's going to potentially mean<br>
> redundantly pinning the ctx for the sake of the ID in the future for<br>
> streams that don't really need it, but I think it's probably not worth<br>
> worrying about that.<br>
><br>
> - Robert<br>
><br>
> > -Chris<br>
> ><br>
> > --<br>
> > Chris Wilson, Intel Open Source Technology Centre<br>
<br>
</div></div>> ______________________________<wbr>_________________<br>
> Intel-gfx mailing list<br>
> <a href="mailto:Intel-gfx@lists.freedesktop.org">Intel-gfx@lists.freedesktop.<wbr>org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/intel-gfx" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/intel-gfx</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Ville Syrjälä<br>
Intel OTC<br>
</font></span></blockquote></div><br></div></div>