[Mesa-dev] DMA_BUF render targets disabled for intel

[Chad Versace]

On Wed 08 Apr 2015, Volker Vogelhuber wrote:
>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.

Not X11, something else. The probability of render corruption is
proportional to the density of cleared pixels.  Specifically, when the
MCS buffer is present, the hardware groups the color buffer into blocks
of pixels.  If no pixel in a given block has been rendered since the
previous glClear, then the pixel data in the color buffer is undefined
for that block. The real data for the cleared block lives in the MCS.
So, when a non-GL consumer of the dma_buf reads the color buffer (in
Chrome OS's case, the consumer is Intel's display engine), it will read
undefined pixel data for that block. (If the dma_buf consumer writes
directly to the dma_buf, similar issues arise).

KMS-based Chrome OS renders correctly due to luck: it never calls
glClear on a dma_buf-backed renderbuffer. Chrome always renders to every
pixel in the buffer.

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

Soon. I'm going to validate the patches on an Ivybridge Chromebook today
and immediately submit them to mesa-dev if there are no regressions. (If
there are regressions, then hopefully I can iron them out before end of
week). I'll CC you on the patches.