-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
eglCreateImage for cubemap textures #164
Comments
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 |
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 ( |
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: |
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. |
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. |
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 toadd a
EGL_GL_TEXTURE_CUBE_MAP
target would be a start.The text was updated successfully, but these errors were encountered: