[Mesa-dev] EGLImage creation with exisiting memory block

[Volker Vogelhuber]

I'm currently trying to create an OpenGL texture from an existing memory 
block
I allocated using CMEM(TI module). I adjusted CMEM to work on an intel
baytrail CoM. The block is filled by an FPGA that does not support scatter
gather DMA. So I reserved an area within the baytrail's system memory using
Linux's memmap command line parameter and allocated a buffer for the FPGA
using CMEM later on. So what I've already working is transferring image 
data
from the FPGA to the system memory.

The rendering should be done using plain KMS/DRM/GBM handling without any
window manager. I got OpenGL rendering running, the only missing part is 
how
to use the memory block with the FPGA image data as an OpenGL texture. Of
course I don't want to use just the glTexImage2D way because I don't 
want to
copy the image data around. So I first thought using the eglCreateImageKHR
together with glEGLImageTargetTexture2DOES would be the way to go. But I
couldn't figure out, who I can create an EGLImage from the existing memory
block.

dri2_create_image_khr seems to support textures, renderbuffers, gbm
buffers, dma buffers but no pure physical memory address. And creating a
gbm buffer using gbm_bo_import does not seem to work either, because it
requires an EGL_Image itself.

The other thing I thought about is using  gbm_bo_create to allocate the
memory block instead of using CMEM. In case I'm doing it that way, is
there any possibility to use the allocated memory later for the FPGA. So is
it physically contiguous, and where do I get the physical address from.
I also suspect this buffer to be affected by possible reallocations, so it
might does not have a persistent address, does it?

Other topic: as glEGLImageTargetTexture2DOES does not create a normal
OpenGL texture but an external one that seems to be usable only using
samplerExternalOES, it there another possibility for my use case to get a
normal sampler2D object? It is not that important, but would make things
more convenient to handle.

Any informations about best efforts for realizing this
(probably not that unusual use case) would be appreciated.

Kind regards,
     Volker