From: Jesse Barnes <jbarnes@virtuousgeek.org>
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>,
John Harrison <john.c.harrison@intel.com>,
gpudriverdevsupport@amd.com
Subject: Re: Question on UAPI for fences
Date: Fri, 12 Sep 2014 09:45:10 -0700 [thread overview]
Message-ID: <20140912094510.0dc5e9c9@jbarnes-desktop> (raw)
In-Reply-To: <54131A77.3030003@amd.com>
On Fri, 12 Sep 2014 18:08:23 +0200
Christian König <christian.koenig@amd.com> wrote:
> > As Daniel said using fd is most likely the way we want to do it but this
> > remains vague.
> Separating the discussion if it should be an fd or not. Using an fd
> sounds fine to me in general, but I have some concerns as well.
>
> For example what was the maximum number of opened FDs per process again?
> Could that become a problem? etc...
You can check out the i915 patches I posted if you want to see
examples. Max fds may be an issue if userspace doesn't clean up its
fences. The implementation is pretty easy with the stuff Maarten has
done recently.
The changes I still need to make to mine:
- sit on top of Chris's request/seqno changes (driver internals
really)
- switch over to execbuf as the main API on the render side (like
you're doing)
- add support for display and other timelines
As far as compat goes, I don't think it should be too hard. Even with
GPU scheduling, a given context's buffers should all be in-order with
respect to one another, so we ought to be able to mix & match clients
using explicit fencing and implicit fencing. Though in Mesa I still
haven't looked at how to handle server vs client side arb_sync with the
scheduler and explicit fencing in place; might need some extra work
there...
--
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
prev parent reply other threads:[~2014-09-12 16:51 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
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 [this message]
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=20140912094510.0dc5e9c9@jbarnes-desktop \
--to=jbarnes@virtuousgeek.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gpudriverdevsupport@amd.com \
--cc=john.c.harrison@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox