All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: [PATCH 0/6] drm/nouveau: Support sync FDs and sync objects
Date: Wed, 23 Sep 2020 11:18:53 +0200	[thread overview]
Message-ID: <20200923091853.GA1229032@ulmo> (raw)
In-Reply-To: <20200828104016.1672195-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 1653 bytes --]

On Fri, Aug 28, 2020 at 12:40:10PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> Hi,
> 
> This series implements a new IOCTL to submit push buffers that can
> optionally return a sync FD or sync object to userspace. This is useful
> in cases where userspace wants to synchronize operations between the GPU
> and another driver (such as KMS for display). Among other things this
> allows extensions such as eglDupNativeFenceFDANDROID to be implemented.
> 
> Note that patch 4 modifies the ABI introduced in patch 3 by allowing DRM
> sync objects to be passed rather than only sync FDs. It also allows any
> number of sync FDs/objects to be passed in or emitted. I think those are
> useful features, but I left them in a separate patch in case everybody
> else thinks that this won't be needed. If we decide to merge the new ABI
> then patch 4 should be squashed into patch 3.
> 
> The corresponding userspace changes can be found here:
> 
>   libdrm: https://gitlab.freedesktop.org/tagr/drm/-/commits/nouveau-sync-fd-v2/
>   mesa: https://gitlab.freedesktop.org/tagr/mesa/-/commits/nouveau-sync-fd/
> 
> I've verified that this works with kmscube's --atomic mode and Weston.

Hi Ben,

any thoughts on this series? I realize that this is somewhat suboptimal
because we're effectively adding a duplicate of the existing IOCTL with
only the "minor" extension of adding sync FDs/objects, but at the same
time I don't have any good ideas on what else to add to make this more
appealing or if you have any plans of your own to address this in the
future.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 0/6] drm/nouveau: Support sync FDs and sync objects
Date: Wed, 23 Sep 2020 11:18:53 +0200	[thread overview]
Message-ID: <20200923091853.GA1229032@ulmo> (raw)
In-Reply-To: <20200828104016.1672195-1-thierry.reding@gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1624 bytes --]

On Fri, Aug 28, 2020 at 12:40:10PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> Hi,
> 
> This series implements a new IOCTL to submit push buffers that can
> optionally return a sync FD or sync object to userspace. This is useful
> in cases where userspace wants to synchronize operations between the GPU
> and another driver (such as KMS for display). Among other things this
> allows extensions such as eglDupNativeFenceFDANDROID to be implemented.
> 
> Note that patch 4 modifies the ABI introduced in patch 3 by allowing DRM
> sync objects to be passed rather than only sync FDs. It also allows any
> number of sync FDs/objects to be passed in or emitted. I think those are
> useful features, but I left them in a separate patch in case everybody
> else thinks that this won't be needed. If we decide to merge the new ABI
> then patch 4 should be squashed into patch 3.
> 
> The corresponding userspace changes can be found here:
> 
>   libdrm: https://gitlab.freedesktop.org/tagr/drm/-/commits/nouveau-sync-fd-v2/
>   mesa: https://gitlab.freedesktop.org/tagr/mesa/-/commits/nouveau-sync-fd/
> 
> I've verified that this works with kmscube's --atomic mode and Weston.

Hi Ben,

any thoughts on this series? I realize that this is somewhat suboptimal
because we're effectively adding a duplicate of the existing IOCTL with
only the "minor" extension of adding sync FDs/objects, but at the same
time I don't have any good ideas on what else to add to make this more
appealing or if you have any plans of your own to address this in the
future.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

  parent reply	other threads:[~2020-09-23  9:18 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-28 10:40 [PATCH 0/6] drm/nouveau: Support sync FDs and sync objects Thierry Reding
2020-08-28 10:40 ` Thierry Reding
     [not found] ` <20200828104016.1672195-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-08-28 10:40   ` [PATCH 1/6] drm/nouveau: Split nouveau_fence_sync() Thierry Reding
2020-08-28 10:40     ` Thierry Reding
2020-08-28 10:40   ` [PATCH 2/6] drm/nouveau: Add nouveau_fence_ref() Thierry Reding
2020-08-28 10:40     ` Thierry Reding
2020-08-28 10:40   ` [PATCH 3/6] drm/nouveau: Support fence FDs at kickoff Thierry Reding
2020-08-28 10:40     ` Thierry Reding
2020-08-28 10:40   ` [PATCH 4/6] drm/nouveau: Support sync FDs and syncobjs Thierry Reding
2020-08-28 10:40     ` Thierry Reding
2020-08-31 12:27     ` Dan Carpenter
2020-08-31 12:27       ` Dan Carpenter
2020-08-28 10:40   ` [PATCH 5/6] drm/nouveau: Support DMA fence arrays Thierry Reding
2020-08-28 10:40     ` Thierry Reding
2020-08-28 10:40   ` [PATCH 6/6] drm/nouveau: Allow zero pushbuffer submits Thierry Reding
2020-08-28 10:40     ` Thierry Reding
2020-09-23  9:18   ` Thierry Reding [this message]
2020-09-23  9:18     ` [PATCH 0/6] drm/nouveau: Support sync FDs and sync objects Thierry Reding
2020-09-23 15:21     ` Daniel Vetter
2020-09-23 15:21       ` [Nouveau] " Daniel Vetter
     [not found]       ` <20200923152124.GO438822-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2020-09-24 10:05         ` Thierry Reding
2020-09-24 10:05           ` [Nouveau] " Thierry Reding
2020-09-24 11:16           ` Daniel Vetter
2020-09-24 11:16             ` [Nouveau] " Daniel Vetter

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=20200923091853.GA1229032@ulmo \
    --to=thierry.reding-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    /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.