[Mesa-dev] DMA_BUF render targets disabled for intel

[Volker Vogelhuber]

On 07.04.2015 21:54, Chad Versace wrote:
> 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).
Why it's safe only for ChromeOS? Do you mean it's not safe for X11 or
is there something else, I should be aware of. Actually we're not using 
X11 ourselfs,
but only raw DRM/KMS infrastructure.
>
>>> 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).
Based on your patches I had a quick look in the source code for creating MCS
buffers, but without knowing details about the intel GPUs I doubt it 
makes much
sense for me to dive too deep into it.

> 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).
Thanks again. Are there any forecasts when it will be available upstream?

Regards,
     Volker