All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Matthew Auld <matthew.auld@intel.com>
Subject: Re: [PATCH 15/16] drm/i915/gem: Distinguish each object type
Date: Mon, 4 Nov 2019 18:51:35 +0100	[thread overview]
Message-ID: <20191104175135.GN10326@phenom.ffwll.local> (raw)
In-Reply-To: <CAM0jSHPom-2SKVrOZ4FCvu8D6upmjTF_dHudkS0gYsLt4fhKTQ@mail.gmail.com>

On Tue, Oct 22, 2019 at 03:30:13PM +0100, Matthew Auld wrote:
> On Mon, 21 Oct 2019 at 09:03, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> >
> > Separate each object class into a separate lock type to avoid lockdep
> > cross-contamination between paths (i.e. userptr!).
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Matthew Auld <matthew.auld@intel.com>
> 
> As per the explanation you gave on IRC, makes sense.
> Reviewed-by: Matthew Auld <matthew.auld@intel.com>

It would be really lovely if such explanations would make it from
ephemeral irc onto something more permanent like mailing lists, or even
better, commit messages :-)

So, why do we need this?

I'm wondering since aside from userptr we'll have to unify how locking for
bo works longer term (with all the dma_buf/ww_mutex stuff going on), not
make it more distinct.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Matthew Auld <matthew.auld@intel.com>
Subject: Re: [Intel-gfx] [PATCH 15/16] drm/i915/gem: Distinguish each object type
Date: Mon, 4 Nov 2019 18:51:35 +0100	[thread overview]
Message-ID: <20191104175135.GN10326@phenom.ffwll.local> (raw)
Message-ID: <20191104175135.UXijfewvcqT6eJPY5_jF2M-PrbSRs9r55jmYemAqcX8@z> (raw)
In-Reply-To: <CAM0jSHPom-2SKVrOZ4FCvu8D6upmjTF_dHudkS0gYsLt4fhKTQ@mail.gmail.com>

On Tue, Oct 22, 2019 at 03:30:13PM +0100, Matthew Auld wrote:
> On Mon, 21 Oct 2019 at 09:03, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> >
> > Separate each object class into a separate lock type to avoid lockdep
> > cross-contamination between paths (i.e. userptr!).
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Matthew Auld <matthew.auld@intel.com>
> 
> As per the explanation you gave on IRC, makes sense.
> Reviewed-by: Matthew Auld <matthew.auld@intel.com>

It would be really lovely if such explanations would make it from
ephemeral irc onto something more permanent like mailing lists, or even
better, commit messages :-)

So, why do we need this?

I'm wondering since aside from userptr we'll have to unify how locking for
bo works longer term (with all the dma_buf/ww_mutex stuff going on), not
make it more distinct.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-11-04 17:51 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-21  8:02 [PATCH 01/16] drm/i915: Don't set queue_priority_hint if we don't kick the submission Chris Wilson
2019-10-21  8:02 ` [PATCH 02/16] drm/i915: Drop assertion that ce->pin_mutex guards state updates Chris Wilson
2019-10-22 12:25   ` Mika Kuoppala
2019-10-21  8:02 ` [PATCH 03/16] drm/i915/selftests: Add coverage of mocs registers Chris Wilson
2019-10-21  8:02 ` [PATCH 04/16] drm/i915/selftests: Teach igt_flush_test and igt_live_test to take intel_gt Chris Wilson
2019-10-21  8:02 ` [PATCH 05/16] drm/i915/selftests: Force ordering of context switches Chris Wilson
2019-10-21  8:02 ` [PATCH 06/16] drm/i915: Expose engine properties via sysfs Chris Wilson
2019-10-21  8:02 ` [PATCH 07/16] drm/i915: Expose engine->mmio_base " Chris Wilson
2019-10-21  8:02 ` [PATCH 08/16] drm/i915: Expose timeslice duration to sysfs Chris Wilson
2019-10-21  8:02 ` [PATCH 09/16] drm/i915/execlists: Force preemption Chris Wilson
2019-10-21  8:02 ` [PATCH 10/16] drm/i915/gt: Introduce barrier pulses along engines Chris Wilson
2019-10-21  8:02 ` [PATCH 11/16] drm/i915/execlists: Cancel banned contexts on schedule-out Chris Wilson
2019-10-21  8:02 ` [PATCH 12/16] drm/i915/gem: Cancel contexts when hangchecking is disabled Chris Wilson
2019-10-21  8:02 ` [PATCH 13/16] drm/i915: Replace hangcheck by heartbeats Chris Wilson
2019-10-21  8:02 ` [PATCH 14/16] drm/i915/gem: Make context persistence optional Chris Wilson
2019-10-21  8:02 ` [PATCH 15/16] drm/i915/gem: Distinguish each object type Chris Wilson
2019-10-22 14:30   ` Matthew Auld
2019-11-04 17:51     ` Daniel Vetter [this message]
2019-11-04 17:51       ` [Intel-gfx] " Daniel Vetter
2019-10-21  8:02 ` [PATCH 16/16] drm/i915: Flush idle barriers when waiting Chris Wilson
2019-10-21  8:54 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/16] drm/i915: Don't set queue_priority_hint if we don't kick the submission Patchwork
2019-10-21  9:01 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-10-21  9:18 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-10-21  9:49 ` [PATCH 01/16] " Mika Kuoppala
2019-10-21  9:56   ` Chris Wilson
2019-10-21 10:01     ` Mika Kuoppala

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=20191104175135.GN10326@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=matthew.william.auld@gmail.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.