Decouple surfaces from GL contexts
kvark opened this issue · 1 comments
Moved from pcwalton#65 (comment)
This is a blocker for proper GL support in gfx-rs/wgpu.
tl;dr: we might be able to lift the restriction that surfman
Surfaces
have an associated producerContext
that has draw access. This restriction was needed for GLX, but that's not a supported platform any more.
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
@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?