From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Sumit Semwal <sumit.semwal@linaro.org>, rob.clark@linaro.org
Cc: linaro-mm-sig@lists.linaro.org, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
patches@linaro.org
Subject: Re: [PATCH 1/3] dma-fence: dma-buf synchronization (v7)
Date: Tue, 07 Aug 2012 20:47:51 +0200 [thread overview]
Message-ID: <502162D7.9090809@canonical.com> (raw)
In-Reply-To: <20120807175330.18745.81293.stgit@patser.local>
Op 07-08-12 19:53, Maarten Lankhorst schreef:
> A dma-fence can be attached to a buffer which is being filled or consumed
> by hw, to allow userspace to pass the buffer without waiting to another
> device. For example, userspace can call page_flip ioctl to display the
> next frame of graphics after kicking the GPU but while the GPU is still
> rendering. The display device sharing the buffer with the GPU would
> attach a callback to get notified when the GPU's rendering-complete IRQ
> fires, to update the scan-out address of the display, without having to
> wake up userspace.
I implemented this for intel and debugged it with intel <-> nouveau
interaction. Unfortunately the nouveau patches aren't ready at this point,
but the git repo I'm using is available at:
http://cgit.freedesktop.org/~mlankhorst/linux/
It has the patch series and a sample implementation for intel, based on
drm-intel-next tree.
I tried to keep it deadlock and race condition free as much as possible,
but locking gets complicated enough that if I'm unlucky something might
have slipped through regardless.
Especially the locking in i915_gem_reset_requests, is screwed up.
This shows what a real PITA it is to abort callbacks prematurely while
keeping everything stable. As such, aborting requests should only be done
in exceptional circumstances, in this case hardware died and things are
already locked up anyhow..
~Maarten
next prev parent reply other threads:[~2012-08-07 18:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-07 17:53 [PATCH 1/3] dma-fence: dma-buf synchronization (v7) Maarten Lankhorst
2012-08-07 17:54 ` [PATCH 2/3] dma-bikeshed-fence: Hardware dma-buf implementation of fencing Maarten Lankhorst
2012-08-07 17:54 ` [PATCH 3/3] dma-buf-mgr: multiple dma-buf synchronization (v3) Maarten Lankhorst
2012-08-07 18:47 ` Maarten Lankhorst [this message]
2012-08-08 6:35 ` [PATCH 1/3] dma-fence: dma-buf synchronization (v7) Sumit Semwal
2012-08-09 9:39 ` Maarten Lankhorst
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=502162D7.9090809@canonical.com \
--to=maarten.lankhorst@canonical.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=patches@linaro.org \
--cc=rob.clark@linaro.org \
--cc=sumit.semwal@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).