vo_gpu: hwdec: load hwdec interops on-demand by default#9842
vo_gpu: hwdec: load hwdec interops on-demand by default#9842philipl merged 1 commit intompv-player:masterfrom
Conversation
e436616 to
f5e3f30
Compare
f5e3f30 to
5b11abe
Compare
5b11abe to
bdb5d2b
Compare
|
Updated to ensure we check for already loaded hwdecs in all scenarios. |
jeeb
left a comment
There was a problem hiding this comment.
Generally looks good now.
gl_video_load_hwdecs still has the original interpretation of what hwdec_interop_loading_done means, but that just leads to a difference if a specific interop is selected. or if all interops are disabled with "no".
|
Thanks, I'll tweak that to make it more consistent. |
|
Finished my testing with:
Both seem to work :) |
For the record, I'm not sure if the inconsistency is a problem, since it just makes sure that what gets loaded by VO preinit (at least with the GPU and libmpv VOs) is then all that gets loaded in case an interop is specified or set to no. Just thought it was worth bringing up as a difference, though. |
True. I can document the behaviour more clearly if nothing else. |
Historically, we have treated hwdec interop loading as a completely separate step from loading the hwdecs themselves. Some hwdecs need an interop, and some don't, and users generally configure the exact hwdec they want, so interops that aren't relevant for that hwdec shouldn't be loaded to save time and avoid warning/error spam. The basic approach here is to recognise that interops are tied to hwdecs by imgfmt. The hwdec outputs some format, and an interop is needed to get that format to the vo without read back. So, when we try to load an hwdec, instead of just blindly loading all interops as we do today, let's pass the imgfmt in and only load interops that work for that format. If more than one interop is available for the format, the existing logic (whatever it is) will continue to be used to pick one. We also have one callsite in filters where we seem to pre-emptively load all the interops. It's probably possible to trace down a specific format but for now I'm just letting it keep loading all of them; it's no worse than before. You may notice there is no documentation update - and that's because the current docs say that when the interop mode is `auto`, the interop is loaded on demand. So reality now reflects the docs. How nice.
bdb5d2b to
832dbba
Compare
Historically, we have treated hwdec interop loading as a completely
separate step from loading the hwdecs themselves. Some hwdecs need an
interop, and some don't, and users generally configure the exact
hwdec they want, so interops that aren't relevant for that hwdec
shouldn't be loaded to save time and avoid warning/error spam.
The basic approach here is to recognise that interops are tied to
hwdecs by imgfmt. The hwdec outputs some format, and an interop is
needed to get that format to the vo without read back.
So, when we try to load an hwdec, instead of just blindly loading all
interops as we do today, let's pass the imgfmt in and only load
interops that work for that format. If more than one interop is
available for the format, the existing logic (whatever it is) will
continue to be used to pick one.
We also have one callsite in filters where we seem to pre-emptively
load all the interops. It's probably possible to trace down a specific
format but for now I'm just letting it keep loading all of them; it's
no worse than before.
You may notice there is no documentation update - and that's because
the current docs say that when the interop mode is
auto, the interopis loaded on demand. So reality now reflects the docs. How nice.
Fixes #8765
Fixes #9691