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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
