From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <christian.koenig@amd.com>
Cc: Maarten Lankhorst <m.b.lankhorst@gmail.com>,
Zach Pfeffer <zpfeffer@audience.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
gpudriverdevsupport@amd.com
Subject: Re: Question on UAPI for fences
Date: Fri, 12 Sep 2014 16:09:23 +0200 [thread overview]
Message-ID: <CAKMK7uHr0Eu0nWn1TzWSpi6fEudyGoTqWOEVR-Jo_f9eZXk9mA@mail.gmail.com> (raw)
In-Reply-To: <5412F3CA.9060306@amd.com>
On Fri, Sep 12, 2014 at 03:23:22PM +0200, Christian König wrote:
> Hello everyone,
>
> to allow concurrent buffer access by different engines beyond the multiple
> readers/single writer model that we currently use in radeon and other
> drivers we need some kind of synchonization object exposed to userspace.
>
> My initial patch set for this used (or rather abused) zero sized GEM buffers
> as fence handles. This is obviously isn't the best way of doing this (to
> much overhead, rather ugly etc...), Jerome commented on this accordingly.
>
> So what should a driver expose instead? Android sync points? Something else?
I think actually exposing the struct fence objects as a fd, using android
syncpts (or at least something compatible to it) is the way to go. Problem
is that it's super-hard to get the android guys out of hiding for this :(
Adding a bunch of people in the hopes that something sticks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-09-12 14:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-12 13:23 Question on UAPI for fences Christian König
2014-09-12 14:09 ` Daniel Vetter [this message]
2014-09-12 14:43 ` Daniel Vetter
2014-09-12 14:50 ` Jerome Glisse
2014-09-12 15:13 ` Daniel Vetter
2014-09-12 15:25 ` Alex Deucher
2014-09-12 15:33 ` Jerome Glisse
2014-09-12 15:38 ` Alex Deucher
2014-09-12 15:42 ` Christian König
2014-09-12 15:48 ` Jerome Glisse
2014-09-12 15:58 ` Christian König
2014-09-12 16:03 ` Jerome Glisse
2014-09-12 16:08 ` Christian König
2014-09-12 16:38 ` John Harrison
2014-09-13 12:25 ` Christian König
2014-09-14 0:32 ` Marek Olšák
2014-09-14 10:36 ` Christian König
2014-09-15 8:46 ` Daniel Vetter
2014-09-12 16:45 ` Jesse Barnes
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=CAKMK7uHr0Eu0nWn1TzWSpi6fEudyGoTqWOEVR-Jo_f9eZXk9mA@mail.gmail.com \
--to=daniel@ffwll.ch \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gpudriverdevsupport@amd.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=m.b.lankhorst@gmail.com \
--cc=zpfeffer@audience.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.