Skip to content
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

Closed
bl4ckb0ne opened this issue Aug 4, 2022 · 12 comments · May be fixed by #165
Closed

eglCreateImage for cubemap textures #164

bl4ckb0ne opened this issue Aug 4, 2022 · 12 comments · May be fixed by #165

Comments

@bl4ckb0ne
Copy link
Contributor

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.

@stonesthrow
Copy link
Contributor

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.

@cubanismo
Copy link
Contributor

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?

@bl4ckb0ne
Copy link
Contributor Author

@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.

@bl4ckb0ne
Copy link
Contributor Author

@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.

@cubanismo
Copy link
Contributor

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.

@stonesthrow
Copy link
Contributor

The wiki has instructions: https://github.com/KhronosGroup/EGL-Registry/wiki

@bl4ckb0ne
Copy link
Contributor Author

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

@stonesthrow
Copy link
Contributor

@cubanismo
Copy link
Contributor

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.

@bl4ckb0ne
Copy link
Contributor Author

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?

@stonesthrow
Copy link
Contributor

Merged patch, sufficient to close issue?

@bl4ckb0ne
Copy link
Contributor Author

#165 is still pending review but I think having the MR open is sufficient enough to close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants