[Mesa-dev] DMA_BUF render targets disabled for intel

[Chad Versace]

On Thu 02 Apr 2015, Axel Davy wrote:
>Hi,
>
>you may be interesting look at this related bug report:
>https://bugs.freedesktop.org/show_bug.cgi?id=87452#c5
>
>Yours,
>
>Axel Davy
>
>On 02/04/2015 11:58, Volker Vogelhuber wrote :
>>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

That patch isn't safe for general renderbuffer usage... details below.
(As an aside, Chrome OS also has a similar patch in their Mesa tree. But
it's safe for Chrome OS, at least for now).

>>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?

There is a very good reason. It is not pedantic. And me and Tapani
(CC'd) are working on enabling this. See
[https://bugs.freedesktop.org/show_bug.cgi?id=87452#c7] for my
work-in-progress patches.

The reason is that, on Intel chipsets Ivybridge and newer, the i965
driver often expects each color buffer to have an auxiliary metadata
buffer that holds compresson information. If the aux buffer does not
exist, i965 will create it. If the metadata buffer and the real color
buffer become unsynchronized (which is *very* likey when using a dma_buf
as renderbuffer storage), you will get corrupt rendering. If you haven't
got corrupt rendering, it's solely due to luck (and that luck is
proportional to the density of cleared pixels exist in the buffer).

Therefore, i965 needs to be taught to disable aux buffers for
dma_buf-backed storage. Before that happens, you risk corrupted images
if you render to a dma_buf-backed renderbuffer.

If you apply Kalyan's patch on top of my (untested) patches, then
that should safely enable what you're doing with the FPGA. (There may be
still be bugs with EGLImage orphaning semantics, but that likely won't
affect you).