linux-kernel - Re: [RFC 0/6] drm/fences: add in-fences to DRM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 29 Mar 2016 09:23:53 -0400
From:	Rob Clark <robdclark@...il.com>
To:	Inki Dae <inki.dae@...sung.com>
Cc:	Daniel Stone <daniel@...ishbar.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Riley Andrews <riandrews@...roid.com>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	John Harrison <John.C.Harrison@...el.com>
Subject: Re: [RFC 0/6] drm/fences: add in-fences to DRM

On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae <inki.dae@...sung.com> wrote:
>
> In addition, I wonder how explicit and implicit fences could coexist together.
> Rob said,
> "Implicit sync ofc remains the default, but userspace could opt-in to explicit sync instead"
>
> This would mean that if we use explicit sync for user-space then it coexists with implicit sync. However, these two sync fences can't see same DMA buffer because explicit fence has a different file object from implicit one.
> So in this case, I think explicit fence would need to be hung up on the reservation object of dmabuf object somehow. Otherwise, although they coexist together, are these fences - explicit and implicit - used for differenct purpose separately?
>

I'm not entirely sure about coexistance at the same time.  It ofc
shouldn't be a problem for one kernel to support both kinds of
userspace (pure explicit and pure implicit).  And how this would work
on kms atomic ioctl (compositor/consumer) side seems clear enough..
ie. some sort of flag, which if set user provides an explicit fence
fd, and if not set we fall back to current behaviour (ie. get fences
from resv object).

On the gpu/producer side, I think what makes sense is to both attach
the fence to the resv objects and (optionally, specified by an submit
ioctl flag) return a fence fd.  The other option is to add a new ioctl
to convert an internal per-ring fence/seqno (that is already returned
by submit ioctl) to a fence fd.. but I think that would end up with
duplicate 'struct fence' objects on the kernel side (not sure if that
would cause issues somehow), and might be unneeded since with
EGL_ANDROID_native_fence_sync since we should know before glFlush() is
called whether we want an fd or not.  But main thing I'm pondering
here is how to sanely support the old way of userspace gl driver
internal synchronization with new userspace on old kernel, but also
conditionally support EGL_ANDROID_native_fence_sync if you have a new
enough kernel.

BR,
-R