eglCreateImage for cubemap textures
bl4ckb0ne opened this issue · comments
I'm trying to share a cubemap texture between two processes using
DMABUFs.
The current approach, using EGLImage, imples the creation of 6 EGLImage
representing the 6 faces of the cubemap, making 6 distinct DMA-BUF.
Reassembling the cubemap on the other process (see 1) doesn't seems to be
doable for the moment, so I'd like to discuss about extending the API to
generate an EGLImage in a single DMABUF for cubemap textures.
Discussions on the #dri-devel IRC channel pointed out that this is
theoritically possible, but that the current DMABUF api doesn't allow it.
I believe extending the EGL_KHR_gl_texture_cubemap_image extension to
add a EGL_GL_TEXTURE_CUBE_MAP target would be a start.
You should be able to create EGLImages in second process with https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
But
https://registry.khronos.org/OpenGL/extensions/OES/OES_EGL_image.txt
and
https://registry.khronos.org/OpenGL/extensions/EXT/EXT_EGL_image_array.txt
Don't allow you to target a cubmap/face.
So a new extension would need to be crafted. It needs interest enough to create a proposal and draft extension. If you get support from other companies it can be a EXT extension.
Extending OES_EGL_image.txt to add more targets seems like the simple way. But you need to get support from driver implementers to get this added to platform you need.
As usual, I have to ask, why can't you use the Vulkan+GL interop extensions, which already support arbitrary texture types, instead of trying to force something through EGLImage?
@cubanismo the reason is the same as #133 (same project), I'd like to avoid Vulkan because the whole project is already heavily using OpenGL and it would be a lot of work to rewrite everything for this particular case. I'm already able to exchange regular 2D textures using the same process, I'd prefer to work towards being able to do the same with cubemap.
@stonesthrow I don't mind going with a MESA extension at first, as it is my main target.
If I get everything correctly, I would need to draft an extension for EGL (EGL_MESA_gl_texture_cubemap_image) to transform a given cubemap texture into an EGLImage, and an extension for GL (MESA_EGL_image_cubemap) to import the EGLImage into a GL_TEXTURE_CUBE_MAP texture. Prefixes might change depending on the feedback from vendors.
You don't have to rewrite everything in Vulkan to use the GL memory object extension. It just means using GL memory objects instead of EGLImage. Vulkan's the best way to allocate memory objects, but you don't have to rewrite any of your GL code.
The wiki has instructions: https://github.com/KhronosGroup/EGL-Registry/wiki
@cubanismo I'm already heavily depending on EGL for both process, and bound to wayland to exchange buffers. Can the GL memory objects can be sent through DMABUFs?
Memory Objects as per suggested by Cubanismo:
https://registry.khronos.org/OpenGL/extensions/EXT/EXT_external_objects.txt
https://registry.khronos.org/OpenGL/extensions/EXT/EXT_external_objects_fd.txt
I was not familiar either
Memory object FDs are not necessarily dma-bufs (They can be), but they can be sent through protocol just like any other FD. If both consumer and producer are GL/EGL and you're using memory objects on both sides, does it matter what type of FD they are?
If, for some reason, they really have to be a dma-buf FD, you can extend memory objects to add a dma-buf handle type much easier than you can extend EGLImage to support cube maps.
If both consumer and producer are GL/EGL and you're using memory objects on both sides, does it matter what type of FD they are?
I'm bound to Wayland so I'm using the linux-dmabuf protocol to exchange between the two process. I could use something else but the regular GL_TEXTURE_2D are using this already.
What are the other options for memory allocation to use the memory objects? To use Vulkan I would need a whole setup (instance/physical device/device) right?
Merged patch, sufficient to close issue?
#165 is still pending review but I think having the MR open is sufficient enough to close.