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

egl: Add bindings for EGLImage #1713

Open
MarijnS95 opened this issue Nov 2, 2024 · 2 comments
Open

egl: Add bindings for EGLImage #1713

MarijnS95 opened this issue Nov 2, 2024 · 2 comments

Comments

@MarijnS95
Copy link
Member

MarijnS95 commented Nov 2, 2024

After adding a DRM example in #1691 I've on-and-off been using raw DRM as a base to allocate and present/flip GBM images (gbm_bo) by creating a gbm_surface (some sort of swapchain containing multiple gbm_bo's) that one can import into an EGLSurface (already supported in glutin), and once surface.swap_buffers() is called after rendering a new gbm_surface::lock_front_buffer() becomes available to flip to DRM (or to give to a compositor?) 1.

However, OpenGL via EGL also support rendering to individual gbm_bos, by importing them into an EGLImage via EGL_KHR_image_pixmap (iirc resummarized in EGL_KHR_image), and subsequently binding that to a new framebuffer via OES_EGL_image.

I've written some code to test this out successfully, and would like to ask before stuffing this into a PR: should we add an EGLImage representation to glutin's EGL backend (even though the code can already be written in "user code" against egl_display.raw_display() and egl_display.egl())? Furthermore, is there a similarity in other context APIs?

Note that eglCreateImage() can also be used to create EGLImages from/for various GL_TEXTURE_..., if I read it correctly.

Footnotes

  1. I'd like to submit these as extra glutin_examples at some point.

@kchibisov kchibisov changed the title egl: Add bindings for EGLImage? egl: Add bindings for EGLImage Nov 2, 2024
@MarijnS95
Copy link
Member Author

@kchibisov you removing the ? from this title counts as a "yes, it's okay to add an Image wrapper to the EGL backend" answer?

If so, I'll open a PR with what I've been writing thus far.

@kchibisov
Copy link
Member

I don't see why not, if there's a EGL api that could be wrapped, then I don't see why shouldn't we.

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

No branches or pull requests

2 participants