dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Emil Velikov <emil.l.velikov@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Colin Ian King <colin.king@canonical.com>,
	Mika Kuoppala <mika.kuoppala@intel.com>
Subject: Re: [PATCH 1/5] drm/i915: Remove unecessary dma_fence_ops
Date: Wed, 4 Jul 2018 18:22:57 +0100	[thread overview]
Message-ID: <CACvgo50nUOUXfkGn5KJZocCOXCLOROZEHzQt3oTYCUY3k4WB5A@mail.gmail.com> (raw)
In-Reply-To: <20180704123402.GC4693@phenom.ffwll.local>

On 4 July 2018 at 13:34, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Jul 04, 2018 at 01:03:18PM +0100, Emil Velikov wrote:
>> Hi Daniel,
>>
>> On 4 July 2018 at 10:29, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> > dma_fence_default_wait is the default now, same for the trivial
>> > enable_signaling implementation.
>> >
>> > v2: Also remove the relase hook, dma_fence_free is the default.
>> >
>> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
>> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> > Cc: Colin Ian King <colin.king@canonical.com>
>> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>> > Cc: Mika Kuoppala <mika.kuoppala@intel.com>
>> > Cc: intel-gfx@lists.freedesktop.org
>> > ---
>> >  drivers/gpu/drm/i915/i915_gem_clflush.c        | 7 -------
>> >  drivers/gpu/drm/i915/selftests/i915_sw_fence.c | 8 --------
>> >  2 files changed, 15 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_gem_clflush.c b/drivers/gpu/drm/i915/i915_gem_clflush.c
>> > index f5c570d35b2a..8e74c23cbd91 100644
>> > --- a/drivers/gpu/drm/i915/i915_gem_clflush.c
>> > +++ b/drivers/gpu/drm/i915/i915_gem_clflush.c
>> > @@ -45,11 +45,6 @@ static const char *i915_clflush_get_timeline_name(struct dma_fence *fence)
>> >         return "clflush";
>> >  }
>> >
>> > -static bool i915_clflush_enable_signaling(struct dma_fence *fence)
>> > -{
>> > -       return true;
>> > -}
>> > -
>> >  static void i915_clflush_release(struct dma_fence *fence)
>> >  {
>> >         struct clflush *clflush = container_of(fence, typeof(*clflush), dma);
>> > @@ -63,8 +58,6 @@ static void i915_clflush_release(struct dma_fence *fence)
>> >  static const struct dma_fence_ops i915_clflush_ops = {
>> >         .get_driver_name = i915_clflush_get_driver_name,
>> >         .get_timeline_name = i915_clflush_get_timeline_name,
>> > -       .enable_signaling = i915_clflush_enable_signaling,
>> From a quick look through drm-misc/drm-misc-next removing the
>> enable_signalling hook may cause functional changes.
>>
>> Namely:
>> A call to trace_dma_fence_enable_signal() (in
>> dma_fence_enable_sw_signaling(), dma_fence_add_callback() and others)
>> will be omitted.
>
> I'm not sure what this tracepoint is useful for in the absenve of a real
> signaling mechanism that must be enabled (like interrupts).
>
> For all the other bits (begin/end wait, fence signalling itsefl) we have
> tracepoints already, so I think we're all covered. What do you think will
> be lost with the tracepoint here? If there's a real need for it I think I
> can rework the already merged patch to still call the tracpoint, while
> avoiding everything else. I just don't see the use-case for that.

Nothing obvious comes to mind, yet again my knowledge of the fence API
is limited.
Was simply pointing out something that was removed without a small
note covering it.

A fraction of your explanation would have been great, but obviously
not a big deal either way.

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

  reply	other threads:[~2018-07-04 17:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-04  9:29 [PATCH 0/5] RESEND: dma-buf cleanup Daniel Vetter
2018-07-04  9:29 ` [PATCH 1/5] drm/i915: Remove unecessary dma_fence_ops Daniel Vetter
2018-07-04 12:03   ` Emil Velikov
2018-07-04 12:34     ` Daniel Vetter
2018-07-04 17:22       ` Emil Velikov [this message]
2018-07-04 20:03         ` Daniel Vetter
     [not found] ` <20180704092909.6599-1-daniel.vetter-/w4YWyX8dFk@public.gmane.org>
2018-07-04  9:29   ` [PATCH 2/5] drm/msm: " Daniel Vetter
2018-07-04  9:29   ` [PATCH 3/5] drm/nouveau: " Daniel Vetter
2018-07-04  9:29 ` [PATCH 4/5] drm/vgem: " Daniel Vetter
2018-08-09  8:33   ` Daniel Vetter
2018-08-09  8:38     ` Chris Wilson
2018-08-09 12:45   ` [PATCH] " Daniel Vetter
2018-08-09 12:48     ` Chris Wilson
2018-08-17  9:23       ` Daniel Vetter
2018-07-04  9:29 ` [PATCH 5/5] dma-fence: Polish kernel-doc for dma-fence.c Daniel Vetter
2018-07-04  9:36   ` Christian König

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=CACvgo50nUOUXfkGn5KJZocCOXCLOROZEHzQt3oTYCUY3k4WB5A@mail.gmail.com \
    --to=emil.l.velikov@gmail.com \
    --cc=colin.king@canonical.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mika.kuoppala@intel.com \
    --cc=rodrigo.vivi@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;
as well as URLs for NNTP newsgroup(s).