All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gustavo Padovan <gustavo@padovan.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "Stéphane Marchesin" <marcheu@google.com>,
	"Daniel Stone" <daniels@collabora.com>,
	"Sean Paul" <seanpaul@google.com>,
	"Arve Hjønnevåg" <arve@android.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Riley Andrews" <riandrews@android.com>,
	m.chehab@samsung.com,
	"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>,
	"Christian König" <christian.koenig@amd.com>,
	"John Harrison" <John.C.Harrison@intel.com>,
	"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>
Subject: Re: [RFC 1/8] dma-buf/fence: add fence_collection fences
Date: Fri, 15 Apr 2016 11:29:34 -0700	[thread overview]
Message-ID: <20160415182934.GB23954@joana> (raw)
In-Reply-To: <CAKMK7uFXE4P2xhQce=CAkOzWJbS2CjzEadu0tQ8chL9pU6aUcg@mail.gmail.com>

2016-04-15 Daniel Vetter <daniel@ffwll.ch>:

> On Fri, Apr 15, 2016 at 11:03 AM, Christian König
> <christian.koenig@amd.com> wrote:
> > Might be that how amdgpu uses the fence context and sequence number is a bit
> > questionable, but this will completely break it.
> 
> You mean it tries to qualesce fences in the same context down to just
> the last one? That's how it's supposed to be done, and
> fence_collections do break this somewhat. Without fixing up
> fence_is_later and friends. Sounds like amdgpu is a good use case to
> make sure the changes in semantics in these functions result in
> sensible code. In a way a fence_collection is a fence where the
> timeline never matches with any other timeline (since it's a
> combiation).
> 
> And yeah I think fence_collection should probably compress down the
> fences to 1 per timeline. But then that's just an implementation
> detail we can fix later on.

You mean asking for a new context for every collection?

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

WARNING: multiple messages have this Message-ID (diff)
From: Gustavo Padovan <gustavo@padovan.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "Christian König" <christian.koenig@amd.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Daniel Stone" <daniels@collabora.com>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Riley Andrews" <riandrews@android.com>,
	"Rob Clark" <robdclark@gmail.com>,
	"Greg Hackmann" <ghackmann@google.com>,
	"John Harrison" <John.C.Harrison@intel.com>,
	"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
	"Sean Paul" <seanpaul@google.com>,
	"Stéphane Marchesin" <marcheu@google.com>,
	m.chehab@samsung.com,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>
Subject: Re: [RFC 1/8] dma-buf/fence: add fence_collection fences
Date: Fri, 15 Apr 2016 11:29:34 -0700	[thread overview]
Message-ID: <20160415182934.GB23954@joana> (raw)
In-Reply-To: <CAKMK7uFXE4P2xhQce=CAkOzWJbS2CjzEadu0tQ8chL9pU6aUcg@mail.gmail.com>

2016-04-15 Daniel Vetter <daniel@ffwll.ch>:

> On Fri, Apr 15, 2016 at 11:03 AM, Christian König
> <christian.koenig@amd.com> wrote:
> > Might be that how amdgpu uses the fence context and sequence number is a bit
> > questionable, but this will completely break it.
> 
> You mean it tries to qualesce fences in the same context down to just
> the last one? That's how it's supposed to be done, and
> fence_collections do break this somewhat. Without fixing up
> fence_is_later and friends. Sounds like amdgpu is a good use case to
> make sure the changes in semantics in these functions result in
> sensible code. In a way a fence_collection is a fence where the
> timeline never matches with any other timeline (since it's a
> combiation).
> 
> And yeah I think fence_collection should probably compress down the
> fences to 1 per timeline. But then that's just an implementation
> detail we can fix later on.

You mean asking for a new context for every collection?

	Gustavo

  reply	other threads:[~2016-04-15 18:29 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-15  1:29 [RFC 0/8] drm: explicit fencing support Gustavo Padovan
2016-04-15  1:29 ` Gustavo Padovan
2016-04-15  1:29 ` [RFC 1/8] dma-buf/fence: add fence_collection fences Gustavo Padovan
2016-04-15  1:29   ` Gustavo Padovan
2016-04-15  8:02   ` Daniel Vetter
2016-04-15  8:02     ` Daniel Vetter
2016-04-15  9:03     ` Christian König
2016-04-15  9:03       ` Christian König
2016-04-15 11:44       ` Daniel Vetter
2016-04-15 11:44         ` Daniel Vetter
2016-04-15 18:29         ` Gustavo Padovan [this message]
2016-04-15 18:29           ` Gustavo Padovan
2016-04-15 19:23           ` Daniel Vetter
2016-04-15 19:23             ` Daniel Vetter
2016-04-15 18:27       ` Gustavo Padovan
2016-04-15 18:27         ` Gustavo Padovan
2016-04-15 19:25         ` Daniel Vetter
2016-04-15 19:25           ` Daniel Vetter
2016-05-18  7:07           ` Christian König
2016-05-18  7:07             ` Christian König
2016-05-18 14:30             ` Gustavo Padovan
2016-04-15  1:29 ` [RFC 2/8] dma-buf/sync_file: add sync_file_fences_get() Gustavo Padovan
2016-04-15  1:29   ` Gustavo Padovan
2016-04-15  7:56   ` Daniel Vetter
2016-04-15  7:56     ` Daniel Vetter
2016-04-15  1:29 ` [RFC 3/8] drm/fence: allow fence waiting to be interrupted by userspace Gustavo Padovan
2016-04-15  1:29   ` Gustavo Padovan
2016-04-15  7:47   ` Daniel Vetter
2016-04-15  7:47     ` Daniel Vetter
2016-04-15  1:29 ` [RFC 4/8] drm/fence: add in-fences support Gustavo Padovan
2016-04-15  1:29   ` Gustavo Padovan
2016-04-15  8:05   ` Daniel Vetter
2016-04-15  8:05     ` Daniel Vetter
2016-04-15 18:40     ` Gustavo Padovan
2016-04-15 18:40       ` Gustavo Padovan
2016-04-15  8:11   ` Daniel Vetter
2016-04-15  8:11     ` Daniel Vetter
2016-04-15  1:29 ` [RFC 5/8] drm/fence: add fence to drm_pending_event Gustavo Padovan
2016-04-15  1:29   ` Gustavo Padovan
2016-04-15  8:09   ` Daniel Vetter
2016-04-15  8:09     ` Daniel Vetter
2016-04-15 18:59     ` Gustavo Padovan
2016-04-15 18:59       ` Gustavo Padovan
2016-04-15 19:31       ` Daniel Vetter
2016-04-15 19:31         ` Daniel Vetter
2016-04-15  1:29 ` [RFC 6/8] drm/fence: create DRM_MODE_ATOMIC_OUT_FENCE flag Gustavo Padovan
2016-04-15  1:29   ` Gustavo Padovan
2016-04-15  1:40   ` Rob Clark
2016-04-15  1:40     ` Rob Clark
2016-04-15 19:05     ` Gustavo Padovan
2016-04-15 19:05       ` Gustavo Padovan
2016-04-15  1:29 ` [RFC 7/8] drm/fence: create per-crtc sync_timeline Gustavo Padovan
2016-04-15  1:29   ` Gustavo Padovan
2016-04-15  1:29 ` [RFC 8/8] drm/fence: add out-fences support Gustavo Padovan
2016-04-15  1:29   ` Gustavo Padovan
2016-04-15  8:18   ` Daniel Vetter
2016-04-15  8:18     ` Daniel Vetter
2016-04-15 19:15     ` Gustavo Padovan
2016-04-15 19:15       ` Gustavo Padovan

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=20160415182934.GB23954@joana \
    --to=gustavo@padovan.org \
    --cc=John.C.Harrison@intel.com \
    --cc=arve@android.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo.padovan@collabora.co.uk \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=marcheu@google.com \
    --cc=riandrews@android.com \
    --cc=seanpaul@google.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.