You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered:
@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?
Moved from pcwalton#65 (comment)
This is a blocker for proper GL support in gfx-rs/wgpu.
@asajeffrey
@pcwalton
The text was updated successfully, but these errors were encountered: