Draft: opengl: refactor API to provide execution context
Disclaimer: the work is not finished yet. OpenGL providers like EGL need the addition of a thread. The new API is not pretty yet and a lot could be factored together. The clients are not using the new API. The old API still exists though some providers cannot implement it. The Core animation macosx display has not been ported too, but we might just remove it if needed. The EGL code is also not behaving correctly for Swap() because the context is not current. OSX should enable HAVE_GL from the configure.ac.
This merge request brings the last part to unify every OpenGL implementation in the tree and future ones.
OpenGL contexts providers are dependant on their execution context. Most implementations are capable of executing code from any thread as long as the context is made current to the thread and only this thread. However, it can have consequences like VSYNC being applied multiple times (see #23566 for instqnce).
Some other implementations strongly require that the code is executed from the correct thread, or even stronger for the web typically, the correct process-like.
Still, OpenGL clients expect to be able to signal when a new frame needs to be drawn and when a new rendered frame needs to be presented.
By providing a way for the OpenGL provider to control the execution context, we can be compatible with every possible context and use client code like opengl/display.c for every provider.
Merge request reports
Activity
changed milestone to %4.0
added Component::Video: misc. plugins Type::feature labels
requested review from @rom1v
assigned to @alexandre-janniaux
mentioned in merge request !1315 (closed)
A lot of unrelated commits, I published early to be sure my work can be reviewed against !1315 (closed) fix.
added 22 commits
- 1701158d - egl: allow swapping without current context
- 8eacb982 - opengl: remove glwin32 OpenGL display
- a409f69e - opengl: display: load glFlush from context
- 374f4cc5 - opengl: move vlc_gl_Swap() to display
- edcce1c5 - opengl: display: move render code to prepare()
- e996a43a - opengl: vout_helper: remove obsolete comment
- a8349710 - opengl: display: TODO
- 813f39ab - include: opengl: add operation structure for vlc_gl_t
- a1cd2dc5 - opengl: implement operation structure
- 6eeaf936 - opengl: add vlc_gl_callbacks for render
- a5b84f63 - opengl: add init to callbacks
- 0d67bca0 - opengl: display: refactor with new render API
- 5805bd83 - opengl: display: move Open to the end of the file
- dcd0aae2 - opengl: forward owner to clients
- 3ce30432 - opengl: add vlc_gl_RenderNext
- 0f2fafa4 - opengl: display: use vlc_gl_RenderFrame dispatcher
- 0cefa7c2 - glspectrum: use new OpenGL API
- e3749a6e - configure.ac: enable GL for macosx
- dbb494ef - macosx: rewrite as OpenGL provider module
- c8517a74 - egl_pbuffer: expose render_next
- db2e76c0 - opengl: add owner to offscreen GL
- ff70c18d - filter: opengl: add support for new OpenGL API
Toggle commit list
238 227 sys->place_changed = false; 239 228 } 240 229 vout_display_opengl_Display(sys->vgl); 241 vlc_gl_Swap(sys->glà; 230 sys->vt.Flush(); 242 231 } 243 232 } 244 233 234 static void PictureDisplay (vout_display_t *vd, picture_t *pic) 235 { 236 vout_display_sys_t *sys = vd->sys; 237 VLC_UNUSED(pic); 238 239 /* Present on screen */ 240 vlc_gl_Swap(sys->gl); 241 vlc_gl_ReleaseCurrent (sys->gl); -
Imbalance.
Note that there are no codified guarantees that
prepareanddisplayoccur in the same thread and with nothing between them, even if it just so happens at this time.In fact, it is very plausible that the eventual solution for the display lock latency problem would have
prepareanddisplayoccasionally on different threads. Yes, sorry the MR is a mess and quite drafty as-is.
The ReleaseCurrent shouldn't be necessary here, I had it back then because it was needed by EGL android, but it's not needed anymore after the more recent EGL patch, without relying on display threading. The whole MR goal is to avoid threading, and even more generally execution context hypothesis as needed with WASM workers so I agree with you.
I'm not fond of the current flow of this MR. I made it working on most platforms but there might be a bit more work to reorganize in the end.
In fact, it is very plausible that the eventual solution for the display lock latency problem would have
prepareanddisplayoccasionally on different threads.TBH, I'm not sure what it has to do with this problem and how it would solve it, but that's a discussion for the matching issue and not here.
68 68 struct vlc_decoder_device *device; 69 69 union { 70 70 struct { /* on-screen */ 71 void (*swap)(vlc_gl_t *); 46 46 }; 47 47 48 48 struct vlc_gl_callbacks { 49 void (*init)(struct vlc_gl_t *gl, void *data); 155 159 return gl->ops->get_proc_address(gl, name); 156 160 } 157 161 158 VLC_API vlc_gl_t *vlc_gl_surface_Create(vlc_object_t *, 159 const struct vout_window_cfg_t *, 160 struct vout_window_t **) VLC_USED; 162 VLC_API vlc_gl_t *vlc_gl_surface_Create( 163 vlc_object_t *obj, const struct vout_window_cfg_t *cfg, 164 const struct vlc_gl_callbacks *cbs, void *owner, 165 struct vout_window_t **) VLC_USED; 166 #define vlc_gl_surface_Create(o,c,w) \ 167 (vlc_gl_surface_Create)(o,c,NULL,NULL,w) mentioned in merge request !1383 (closed)
mentioned in issue #25858
mentioned in merge request !1758
mentioned in merge request !1813 (merged)
mentioned in merge request !1814 (merged)
mentioned in merge request !1820 (merged)
