[Mesa-dev] DMA_BUF render targets disabled for intel

[Volker Vogelhuber]

We currently want to stream OpenGL output to an FPGA that does not provide
a SG controller and should manage the transfers from the CPU memory to it's
own hardware. For that reason we want to have the OpenGL driver (intel 
baytrail)
to render at a specific memory area within the CPU system. Render to 
texture as
it is possible e.g. on the PowerVR 530 seems not to be possible, as
GL_TEXTURE_EXTERNAL_OES is not valid for glFrameBufferTexture2D and
in contrast to the PowerVR OpenGL implementation, Mesa seems to prohibit the
use of GL_TEXTURE_2D for textures created by glEGLImageTargetTexture2DOES
(there is a check within Mesa where  glEGLImageTargetTexture2DOES's 
target has
to be equal to the target of the texture => GL_TEXTURE_EXTERNAL_OES != 
GL_TEXTURE_2D).

So the only possible way to render to an EGLImage with memory allocated 
by myself
seems to be the use of glEGLImageTargetRenderbufferStorageOES and bind this
render buffer using glFramebufferRenderbuffer to the FBO.

But for some reason, it seems to be forbidden to use an EGLImage 
imported from
a dmabuf as render buffer. At least within 
src/mesa/drivers/dri/i965/intel_fbo.c there
is a check:

/* Buffers originating from outside are for read-only. */
    if (image->dma_buf_imported) {
       _mesa_error(ctx, GL_INVALID_OPERATION,
             "glEGLImageTargetRenderbufferStorage(dma buffers are 
read-only)");
      return;
}

This prevents me from doing what I wanted to do and I googled a bit.
I found someone else that just removed that check:

https://github.com/kalyankondapally/Chromium-OzoneGBM/blob/master/0010-i965-remove-read-only-restriction-of-imported-buffer.patch

and after I did so myself, it just worked as I wanted it to work. I only 
wonder why this
limitation has been added. Is it just for some pedantic reasons or is 
there any good reason
why EGLImages imported from dmabuf descriptors shouldn't be used for 
render targets?

--
      Volker