EGL_EXT_image_dma_buf_import doesn't impose particular restrictions on the usage of the imported EGLImage. However on i965 (gallium drivers don't have this issue), there is no way to bind the image to a texture under GL. glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, image) will fail. Run with MESA_DEBUG, the following message appear: Mesa: User error: GL_INVALID_OPERATION in glEGLImageTargetTexture2DOES(dma buffers can be used with GL_OES_EGL_image_external only Problem is that GL_OES_EGL_image_external is a GLES only extension. Thus glEGLImageTargetTexture2DOES(GL_ TEXTURE_EXTERNAL_OES, image) fails too with INVALID_ENUM (the exact error may need recheck, this is from memory) I suggest that EGL_EXT_image_dma_buf_import should not put restrictions on RGBA formats at all for i965, and that it would fail to import YUV formats if not using GLES. Gallium drivers, glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, image) will work (I haven't tested what it does for YUV, I only tested for RGBA)
Looks like Topi added this restriction in commit 3a52cd351af6ad834fa6205ec03a82559d1cea92 Author: Topi Pohjolainen <topi.pohjolainen@intel.com> Date: Tue Jun 18 13:47:43 2013 +0300 intel: restrict dma-buf-import images to external sampling only Memory originating outside mesa stack is meant to be for reading only. In addition, the restrictions imposed by the image external extension should apply. For example, users shouldn't be allowed to generare mip-trees based on these images. v2 (Chad): document using full extension names, fix the comment style itself and emit description of error Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com> Reviewed-by: Chad Versace <chad.versace@linux.intel.com> Assigning to him and Cc'ing Chad.
Up. We use the extension for Gallium Nine DRI2 fallback. We have had at least two people complaining of not managing to use Gallium Nine on intel + dedicated card, because of this bug.
While the patch is indeed written by me, the reasoning behind is not originally mine. I simply did what others wanted. I recall at least Ian, Eric and Chad arguing in favour for this patch. If they (and other people of course) are fine in reverting the patch I for sure don't have any problem with it. However, I'd prefer somebody that benefits from the revert to do it instead. There is the potential for further bug reports when somebody binds dma-buffers via textures for 3D rendering.
Not all the reasoning is visible in the mailing list, but here's some of it: http://lists.freedesktop.org/archives/mesa-dev/2013-June/040117.html
One reason that i965 imposes restrictions on dma_buf-EGLImages is to prevent bugs due to missing compression resolves and mishandling of image orphaning rules. Chrome OS also wants to remove some restrictions. It wants to use the EGLImage for renderbuffer storage with glEGLImageTargetRenderbufferStorageOES. I think it's time that we start removing i965's restrictions, but do so carefully without introducing subtle bugs. To allow glEGLImageTargetRenderbufferStorageOES with dma_buf-EGLImages, all I think is needed is that i965 disable allocation of auxillary compression buffers (MCS and HiZ) for such renderbuffers. To allow glEGLImageTargetTexture2DOES, auxillary surfaces must be disabled as for renderbuffers. More safeguards are probably needed for textures to implement orphaning rules, but I can't think of them off the cuff.
Pardon for dropping in without an invite, allow me share my 2c fwiw. Removing this check will also be beneficial for Android-x86/Android-ia. Currently things fails rather annoyingly: [BootAnimation] bindTextureImage: error binding external texture image 0xN 0x502 Seemingly things "just work" without (m)any fireworks if one omits the check. That aside, can anyone mention if they are (or planning to) work on the tasks Chad mentioned ? If not, please spare a bit more description so that someone else can take a look (btw I'm not volunteering). Thanks
Emil, me and Tapani are working on the tasks I mentioned in comment #5. I pushed a personal branch that accomplishes the first task: disabling creation of auxiliary buffers for EGLImage-backed textures and renderbuffers. The branch builds and should be complete, but is still untested. git://github.com/chadversary/mesa i965-disable-aux-buffers-for-EGLImages I need to test the branch on X11-less Chrome OS before submitting it mesa-dev.
*** Bug 89870 has been marked as a duplicate of this bug. ***
Thanks for the notification of Tapani. I marked bug #89870 is duplicate with this bug since they have the same root cause.
(In reply to Chad Versace from comment #7) > Emil, me and Tapani are working on the tasks I mentioned in comment #5. > > I pushed a personal branch that accomplishes the first task: disabling > creation of auxiliary buffers for EGLImage-backed textures and > renderbuffers. The branch builds and should be complete, but is still > untested. > > git://github.com/chadversary/mesa i965-disable-aux-buffers-for-EGLImages > > I need to test the branch on X11-less Chrome OS before submitting it > mesa-dev. Chad, isn't this now fixed with this commit? commit 2943b15ce7ce1bc29424949124a69538253008f7 Author: Chad Versace <chad.versace@intel.com> Date: Mon Apr 6 08:07:27 2015 -0700 i965: Disable aux buffers for EGLImage-backed miptrees If so, please confirm and close.
Fixed by commit a76dc15b2b37db18151b42be63b49438588a92fe Author: Chad Versace <chad.versace@intel.com> Date: Thu Apr 9 20:29:59 2015 -0700 i965: Lift some restrictions on dma_buf EGLImages
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.