OpenGL context support for vo_gpu_next #9486
Conversation
This case was added in 662c793 for use in vo_gpu_next as a visibility test before rendering a frame. The OpenGL context doesn't have this so it just returns true.
|
Hi, as discussed on IRC, I think this needs to be moved into its own file. I don't want to keep growing I was thinking last night about how to do this and I think the correct way forward would be to come up with a new set of abstractions that are intrinsically libplacebo-centric, basically duplicating some logic from The internal implementation for platform specifics should be moved into RA/libplacebo-agnostic neutral helpers, which is mostly already the case. So the only thing that explicitly needs to be duplicated is wrapping code, but I think that's cleaner than trying to hack the ra context into bending over backwards to serve the needs of both. |
sfan5
force-pushed
the
gpunext_gl
branch
3 times, most recently
from
86ce68a
to
095e55c
Compare
There was a problem hiding this comment.
I'm not happy with the current status of this code, but it still represents an improvement to the status quo overall so I don't see any reason not to merge it.
As discussed on IRC I plan on refactoring this entire mechanism to avoid ra_ctx altogether, but until then, this should go in to enable users to test. It isn't any more of a hack than the existing hack.
This is done to avoid cluttering vo_gpu_next.c with more ifdeffery and context-specific code when additional backends are added in the near future. Eventually gpu_ctx is intended to take the place of ra_ctx to further separate gpu and gpu_next.
Wrapping the context is pretty straightforward. This is only complicated by needing to account for the upside-down framebuffer in a few places.
No description provided.