memory for that module during boot up using kernel command line parametermemmap=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
Attachment:
DRMTest.tar.gz
Description: application/gzip
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
