It seems that GLX requires us to explicitly set opts.want alpha before
ra_ctx_create is called. b7fd232524
rearranged the function calls in a way made this not work. Fix this by
rearranging it again so the value is set before ra_ctx is created.
Currently this was being duplicated on init and on runtime updates
between both VOs. Since the conditions for setting this will get more
complicated in the future commits, it's better to just handle it in one
place. We could combine the vo_gpu and vo_gpu_next handling into one
single function but vo_gpu_next has an additional condition for
determining alpha that vo_gpu_does not, so we'll leave these separate
for simplicity. Also this technically fixes a memory leak where gl_opts
weren't being freed.
Currently, libplacebo always tries to reconfigure the d3d11 swapchain
to a 10-bit output format because disable_10bit_sdr isn't set to true,
even when an 8-bit format is explicitly requested via
--d3d11-output-format.
Fix this by passing the requested output format preference to libplacebo.
Document that this option may be ignored.
The new status quo is simple: all messages coming from libplacebo are
marked "vo/gpu{-next}/libplacebo", regardless of the backend API (vulkan
vs opengl/d3d11).
Messages coming from mpv's internal vulkan code will continue to come
from "vo/gpu{-next}/vulkan", and messages coming from the vo module
itself will be marked "vo/gpu{-next}".
This is significantly better than the old status quo of vulkan messages
coming from "vo/gpu{-next}/vulkan/libplacebo" whereas opengl/d3d11
messages simply came from "vo/gpu{-next}", even when those messages
originated from libplacebo.
(It's worth noting that the the destructor for the log is redundant
because it's attached to the ctx which is freed on uninit anyway)
Facing down the multitude of ways to somehow wrangle the get_fn pointer
out of the GL environment and into libplacebo, I decided the easiest is
to just store it inside the GL struct itself.
The lifetime of this get_fn function is a bit murky, since it's not
clear on whether or not it survives the VO init call (especially in the
case of the GL render API, which explicitly states that parameters do
not need to survive the call they're passed to), so just add a
disclaimer.
(It's fine for us to use like this because `gpu_ctx_create` is still
part of VO init)
Closes https://code.videolan.org/videolan/libplacebo/-/issues/216
By receiving the graphics API-specific contexts from the generic
pl_gpu instance, it is not necessary to store them separately.
As the current priv struct stores nothing else, this allows its
removal. This removal cleans up related compiler warnings regarding
unused variables in case of opengl and d3d11 being disabled in
mpv/libplacebo.
Functions to receive the underlying vulkan,gl,d3d11 structure were
added in libplacebo version 4.182. Our current requirement for
gpu-next is 4.190, and thus we can freely utilize these helper
functions.
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.