Using EGLImage textures imported via dma-buf with E3845 baytrail

Volker Vogelhuber v.vogelhuber at digitalendoscopy.de
Tue Apr 28 08:53:34 PDT 2015


I'm still fighting with the zero copy rendering of graphics data sent by 
an FPGA to my system memory.
Basically what I've done so far is writing a kernel module based on TI's 
CMEM only simpler, reserving
memory for that module during boot up using kernel command line parameter
memmap=256M$0x60000000 and provide a DMA-BUF implementation for 
accessing those buffers.

After allocation of a region within that area I created an EGLImage by 
using the DMA-BUF file
descriptor I got from my module. So far rendering of that EGLImage as a 
texture within OpenGL
seems to work OK. But of course one buffer is not enough as we have to 
get FPGA writes and
GPU reads in sync. Unfortunately here's where trouble starts.

I stripped down a test case as much as I could that allocates three 
textures bound to an EGLImage
Those textures are filled with a pattern in different colors. When I 
start rendering everything is ok.
By pressing 'R' key the next texture will be rendered. First also the 
second texture is rendered ok
and finally the third. But after switching from the third back to the 
first, it seems like it's rendering
always the third. In another test scenario in-house we had the effect 
that the GPU seemed to read
from the wrong address after one buffer cycle. But in that case only for 
the first texture.
So the effect might not directly relate to the root cause for that problem.
Using the same code with GPU allocated textures works as expected 
(switchable in the example
using preprocessor define EGL_TEXTURE)

Additionally if we bind an EGLImage from an DMA-BUF fd to a render 
buffer and want to render into
that buffer we got GPU hang errors. Changing the FBO to be bound to a 
normal texture allocated
by the GPU driver everything is OK. So something weird is going on for 
all access to DMA-BUF based
EGLImages.

We're currently using linux-stable 4.0 (but also tested that with 3.17 
and 3.19 with the same effects) and
mesa master rev 9143940da2c4f0deb07d01c1b48d16bb16022997. We first had 
used mesa 10.4.4
with a patch to allow writing into a EGLImage based on a DMA-BUF but 
this has been officially enabled
now in current master (see 
http://comments.gmane.org/gmane.comp.video.mesa3d.devel/100090).
But the problems seem to be unrelated to all those changes.

Attached is the demo code (including the kernel module and some CMake 
build files). Not in production
state but should be usable.

In case binary file attachments are stripped from the mailing list I 
also uploaded it under
http://expirebox.com/download/f618275a39ee118bf2f9d01645d23336.html
but this link expires in 48 hours.

I would be very grateful for any hint, what's going wrong.

Regards,
     Volker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: DRMTest.tar.gz
Type: application/gzip
Size: 28468 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150428/e78e7d14/attachment-0001.bin>


More information about the dri-devel mailing list