dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox