All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gustavo Padovan <gustavo@padovan.org>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: "Daniel Stone" <daniels@collabora.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Arve Hjønnevåg" <arve@android.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	"Riley Andrews" <riandrews@android.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>,
	"John Harrison" <John.C.Harrison@Intel.com>
Subject: Re: [RFC 0/6] drm/fences: add in-fences to DRM
Date: Thu, 24 Mar 2016 11:31:53 -0300	[thread overview]
Message-ID: <20160324143153.GA4781@joana> (raw)
In-Reply-To: <56F3954D.8000308@linux.intel.com>

Hi Maarten,

2016-03-24 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>:

> Hey,
> 
> Op 23-03-16 om 19:47 schreef Gustavo Padovan:
> > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> >
> > Hi,
> >
> > This is a first proposal to discuss the addition of in-fences support
> > to DRM. It adds a new struct to fence.c to abstract the use of sync_file
> > in DRM drivers. The new struct fence_collection contains a array with all
> > fences that a atomic commit needs to wait on
> >
> > /**
> >  * struct fence_collection - aggregate fences together
> >  * @num_fences: number of fence in the collection.
> >  * @user_data: user data.
> >  * @func: user callback to put user data.
> >  * @fences: array of @num_fences fences.
> >  */
> > struct fence_collection {
> >        int num_fences;
> >        void *user_data;
> >        collection_put_func_t func;
> >        struct fence *fences[];
> > };
> >
> >
> > The fence_collection is allocated and filled by sync_file_fences_get() and
> > atomic_commit helpers can use fence_collection_wait() to wait the fences to
> > signal.
> >
> > These patches depends on the sync ABI rework:
> >
> > https://www.spinics.net/lists/dri-devel/msg102795.html
> >
> > and the patch to de-stage the sync framework:
> >
> > https://www.spinics.net/lists/dri-devel/msg102799.html
> >
> >
> > I also hacked together some sync support into modetest for testing:
> >
> > https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic
> >
> Why did you choose to add fence_collection, rather than putting sync_file in state?
> 
> There used to be a sync_fence_wait function, which would mean you'd have everything you need.

We discussed this on #dri-devel a few days ago. The idea behind this is
to abstract sync_file from any drm driver and let only drm core deal
with sync_file. 

In the next iteration even fence_collection will be gone, so the driver
we deal only with struct fence and the fence_collection will be a
subclass of fence.

	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: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	"Daniel Stone" <daniels@collabora.com>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Riley Andrews" <riandrews@android.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Rob Clark" <robdclark@gmail.com>,
	"Greg Hackmann" <ghackmann@google.com>,
	"John Harrison" <John.C.Harrison@Intel.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>
Subject: Re: [RFC 0/6] drm/fences: add in-fences to DRM
Date: Thu, 24 Mar 2016 11:31:53 -0300	[thread overview]
Message-ID: <20160324143153.GA4781@joana> (raw)
In-Reply-To: <56F3954D.8000308@linux.intel.com>

Hi Maarten,

2016-03-24 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>:

> Hey,
> 
> Op 23-03-16 om 19:47 schreef Gustavo Padovan:
> > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> >
> > Hi,
> >
> > This is a first proposal to discuss the addition of in-fences support
> > to DRM. It adds a new struct to fence.c to abstract the use of sync_file
> > in DRM drivers. The new struct fence_collection contains a array with all
> > fences that a atomic commit needs to wait on
> >
> > /**
> >  * struct fence_collection - aggregate fences together
> >  * @num_fences: number of fence in the collection.
> >  * @user_data: user data.
> >  * @func: user callback to put user data.
> >  * @fences: array of @num_fences fences.
> >  */
> > struct fence_collection {
> >        int num_fences;
> >        void *user_data;
> >        collection_put_func_t func;
> >        struct fence *fences[];
> > };
> >
> >
> > The fence_collection is allocated and filled by sync_file_fences_get() and
> > atomic_commit helpers can use fence_collection_wait() to wait the fences to
> > signal.
> >
> > These patches depends on the sync ABI rework:
> >
> > https://www.spinics.net/lists/dri-devel/msg102795.html
> >
> > and the patch to de-stage the sync framework:
> >
> > https://www.spinics.net/lists/dri-devel/msg102799.html
> >
> >
> > I also hacked together some sync support into modetest for testing:
> >
> > https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic
> >
> Why did you choose to add fence_collection, rather than putting sync_file in state?
> 
> There used to be a sync_fence_wait function, which would mean you'd have everything you need.

We discussed this on #dri-devel a few days ago. The idea behind this is
to abstract sync_file from any drm driver and let only drm core deal
with sync_file. 

In the next iteration even fence_collection will be gone, so the driver
we deal only with struct fence and the fence_collection will be a
subclass of fence.

	Gustavo

  parent reply	other threads:[~2016-03-24 14:32 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-23 18:47 [RFC 0/6] drm/fences: add in-fences to DRM Gustavo Padovan
2016-03-23 18:47 ` Gustavo Padovan
2016-03-23 18:47 ` [RFC 1/6] drm/fence: add FENCE_FD property to planes Gustavo Padovan
2016-03-23 18:47   ` Gustavo Padovan
2016-03-24  7:52   ` Inki Dae
2016-04-05 12:36   ` Rob Clark
2016-04-05 12:57     ` Daniel Stone
2016-04-05 12:57       ` Daniel Stone
2016-04-05 14:04       ` Rob Clark
2016-04-05 14:04         ` Rob Clark
2016-04-05 14:19         ` Daniel Stone
2016-04-05 14:19           ` Daniel Stone
2016-04-05 15:23           ` Rob Clark
2016-04-05 15:23             ` Rob Clark
2016-03-23 18:47 ` [RFC 2/6] dma-buf/fence: add struct fence_collection Gustavo Padovan
2016-03-23 18:47   ` Gustavo Padovan
2016-03-23 18:47 ` [RFC 3/6] dma-buf/sync_file: add sync_file_fences_get() Gustavo Padovan
2016-03-23 18:47   ` Gustavo Padovan
2016-03-23 18:47 ` [RFC 4/6] dma-buf/fence: add fence_collection_put() Gustavo Padovan
2016-03-23 18:47   ` Gustavo Padovan
2016-03-23 18:47 ` [RFC 5/6] dma-buf/fence: add fence_collection_wait() Gustavo Padovan
2016-03-23 18:47 ` [RFC 6/6] drm/fence: support fence_collection on atomic commit Gustavo Padovan
2016-03-23 18:47   ` Gustavo Padovan
2016-03-24  7:20 ` [RFC 0/6] drm/fences: add in-fences to DRM Maarten Lankhorst
2016-03-24  7:20   ` Maarten Lankhorst
2016-03-24  8:13   ` zhoucm1
2016-03-24 14:31   ` Gustavo Padovan [this message]
2016-03-24 14:31     ` Gustavo Padovan
2016-03-24  8:18 ` Inki Dae
2016-03-24  8:18   ` Inki Dae
2016-03-24 14:39   ` Gustavo Padovan
2016-03-24 14:39     ` Gustavo Padovan
2016-03-24 23:03     ` Inki Dae
2016-03-24 23:03       ` Inki Dae
2016-03-24 15:40   ` Rob Clark
2016-03-24 15:40     ` Rob Clark
2016-03-24 23:49     ` Inki Dae
2016-03-24 23:49       ` Inki Dae
2016-03-25 11:58       ` Rob Clark
2016-03-25 11:58         ` Rob Clark
2016-03-25 12:10         ` Daniel Stone
2016-03-25 12:10           ` Daniel Stone
2016-03-28  1:26           ` Inki Dae
2016-03-28  1:26             ` Inki Dae
2016-03-28 13:26             ` Daniel Stone
2016-03-29  2:18               ` Inki Dae
2016-03-29  2:18                 ` Inki Dae
2016-03-29 13:23                 ` Rob Clark
2016-03-29 13:23                   ` Rob Clark
2016-03-31  7:45                   ` Inki Dae
2016-03-31  7:45                     ` Inki Dae
2016-03-31  9:35                     ` Daniel Stone
2016-03-31  9:35                       ` Daniel Stone
2016-03-31 10:04                       ` Daniel Vetter
2016-03-31 10:04                         ` Daniel Vetter
2016-03-31 11:40                         ` Inki Dae
2016-03-31 11:40                           ` Inki Dae
2016-03-31 10:05                       ` Inki Dae
2016-03-31 10:05                         ` Inki Dae
2016-03-31 10:56                         ` Daniel Stone
2016-03-31 10:56                           ` Daniel Stone
2016-03-31 11:26                           ` Inki Dae
2016-03-31 11:26                             ` Inki Dae
2016-03-31 11:41                             ` Daniel Stone
2016-03-31 11:41                               ` Daniel Stone
2016-03-31 14:10                             ` Rob Clark
2016-03-31 14:10                               ` Rob Clark
2016-04-04  0:14                               ` Inki Dae
2016-04-04  0:14                                 ` Inki Dae
2016-04-04 15:41                                 ` Rob Clark
2016-04-04 15:41                                   ` Rob Clark
2016-04-04 15:46                                   ` Rob Clark
2016-04-04 15:46                                     ` Rob Clark

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=20160324143153.GA4781@joana \
    --to=gustavo@padovan.org \
    --cc=John.C.Harrison@Intel.com \
    --cc=arve@android.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo.padovan@collabora.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=riandrews@android.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.