On Wed, Oct 26, 2016 at 05:42:23PM +0100, Robert Bragg wrote:
> 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@xxxxxxxxx> 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.
I use a mix of mutt+gmail web interface, since each has their upsides.
Haven't yet seen badly misquoted stuff, I think it mostly seems to work
for me. And there's lots of kernel folks who use gmail too afaik.
-Daniel
>
>
>
> >
> > > > > > +
> > > > > > + 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@xxxxxxxxxxxxxxxxxxxxx
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >
> > --
> > Ville Syrjälä
> > Intel OTC
> >
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
