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

Decouple surfaces from GL contexts #202

Open
kvark opened this issue Sep 29, 2020 · 1 comment
Open

Decouple surfaces from GL contexts #202

kvark opened this issue Sep 29, 2020 · 1 comment

Comments

@kvark
Copy link
Member

kvark commented Sep 29, 2020

Moved from pcwalton#65 (comment)

This is a blocker for proper GL support in gfx-rs/wgpu.

@asajeffrey

tl;dr: we might be able to lift the restriction that surfman Surfaces have an associated producer Context that has draw access. This restriction was needed for GLX, but that's not a supported platform any more.

@pcwalton

it might be the case that we can drop the requirement that surfaces are tied to context now
because we're using DXGI to allocate WGL surfaces and we dropped GLX in favor of EGL
I would love to be able to drop that requirement, it's an artificial limitation that doesn't match how GPU hardware actually works obviously
it was purely the product of baroque APIs
this should be supported by the more modern versions of all the APIs were care about
IOSurface is internally completely decoupled from GL contexts, as are DXGI surfaces which are DirectX resources in the first place (not OpenGL)
in modern EGL, a combination of EGLImageKHR and this extension gives you decoupling as well https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_surfaceless_context.txt
the current design is me being a bit overly conservative -- I considered GLX support a requirement at first, and then eventually got fed up with it and found, happily, that I could just drop it
but didn't revisit the design

@kvark
Copy link
Member Author

kvark commented Nov 6, 2020

@pcwalton one thing is not clear to me here w.r.t suggested EGL implementation. So using one extension we can create and bind EGL contexts not backed by surfaces - good. Using another - we can bind GL textures or renderbuffers to EGLImage - ok. Now we have an EGLImage - how do we present it to a native window without copying?

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

No branches or pull requests

1 participant