From: Volker Vogelhuber <v.vogelhuber@digitalendoscopy.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: Update front buffer without CPU interaction?
Date: Mon, 23 Feb 2015 09:22:56 +0100 [thread overview]
Message-ID: <54EAE360.4040200@digitalendoscopy.de> (raw)
In-Reply-To: <20150222115242.GQ24485@phenom.ffwll.local>
On 22.02.2015 12:52, Daniel Vetter wrote:
> On Mon, Feb 16, 2015 at 01:43:07PM +0100, Volker Vogelhuber wrote:
>> I'm currently trying to setup a rendering pipe on an Intel Baytrail E3845
>> cpu.
>> In our product we want to have an FPGA streaming video images to a
>> predefined memory area using bus master dma and render those images using
>> OpenGL. So far this works in a preliminary state.
>> We now have the security requirement that in case the CPU (software/kernel
>> driver) crashes for what ever reason, the GPU display signal should still
>> output at least the video images (obviously any additional render stuff will
>> not be available anymore). My question is now, would it be possible to get
>> the physical address of the DRM front buffer, so that I can provide this
>> address to the FPGA (connected via PCIe) and is it possible to have the GPU
>> still reading the last front buffer for the display output while the FPGA
>> writes to that area. So I would think that the GPU has some kind of DMA
>> engine running, that continuously reading the last front buffer until
>> switched to another buffer by the CPU. So even if the CPU does not control
>> the GPU anymore, it might be possible to have the front buffer updated by
>> the FPGA directly. Of course there will be tearing artefacts as no VSYNC
>> will be available but that wouldn't be an issue so far.
> Just share buffers between your fpga driver and the i915 driver using
> prime/dma-buf and before each pageflip tell your fpga driver to render
> into the new buffer. We don't have any interfaces to tell userspace
> physical addresses of anything, and that's fairly intentional - the kernel
> is and must be in control of memory management.
> -Daniel
Thanks for the reply. I already stumbled across the PRIME way to get
access to the buffer within the source code but it wasn't totally clear
to me, how one would access this API.
I guess one have to call drmPrimeHandleToFD with the /dev/dri/card0 file
descriptor, a gem handle (probably retrieved using gbm_bo_get_handle),
DRM_CLOEXEC and some output variable.
The Prime file descriptor returned, should be usable with the dma-buf
API, right? So I can call dma_buf_get(prime_fd) within the FPGA driver
and pass the sg_table I get from dma_buf_map_attachment to the DMA
engine within the FPGA.
Does this concept work in theory? Or did I miss something?
Regards, Volker
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-02-23 8:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-16 12:43 Update front buffer without CPU interaction? Volker Vogelhuber
2015-02-22 11:52 ` Daniel Vetter
2015-02-23 8:22 ` Volker Vogelhuber [this message]
2015-02-23 9:18 ` Daniel Vetter
2015-03-24 7:51 ` Volker Vogelhuber
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=54EAE360.4040200@digitalendoscopy.de \
--to=v.vogelhuber@digitalendoscopy.de \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.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.