Update front buffer without CPU interaction?

Volker Vogelhuber v.vogelhuber at digitalendoscopy.de
Mon Feb 23 00:22:56 PST 2015


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




More information about the dri-devel mailing list