Update front buffer without CPU interaction?

Update front buffer without CPU interaction?

[Volker Vogelhuber]

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.

Kind regards,
     Volker


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Update front buffer without CPU interaction?

[Daniel Vetter]

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Update front buffer without CPU interaction?

[Volker Vogelhuber]

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

Re: Update front buffer without CPU interaction?

[Daniel Vetter]

On Mon, Feb 23, 2015 at 09:22:56AM +0100, Volker Vogelhuber wrote:
> 
> 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?

It should work even in practice ;-) And yeah description of the dance
looks complete.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Update front buffer without CPU interaction?

[Volker Vogelhuber]

On 23.02.2015 10:18, Daniel Vetter wrote:
> On Mon, Feb 23, 2015 at 09:22:56AM +0100, Volker Vogelhuber wrote:
>> 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?
> It should work even in practice ;-) And yeah description of the dance
> looks complete.
>
>
I haven't implemented all of the proposed flow (only did a quick writing 
test into the framebuffer from within the FPGA driver using the CPU) but 
it worked more or less without any problems when using an intel 
baytrail. On an AMD G-Series GX-412HC the API seems to be implemented as 
well, but during the call of dma_buf_map_attachment there is a NULL 
pointer exception within the call to radeon_gem_prime_get_sg_table. It 
seems like bo->tbo is a null pointer (used kernel 3.19). Do I have to do 
anything differently when using the radeon driver, or isn't it supported 
at all for this card?



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel