summaryrefslogtreecommitdiffstats
path: root/video/out/vo_gpu.c
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu: support video-target-paramsnanahi2024-03-271-0/+5
|
* vo_gpu/vo_gpu_next: fix transparency in glxDudemanguy2024-03-131-8/+9
| | | | | | | It seems that GLX requires us to explicitly set opts.want alpha before ra_ctx_create is called. b7fd232524bc213df91fa77ca0261ff514fad1e4 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.
* vo_gpu/vo_gpu_next: rework --alpha into --background optionDudemanguy2024-02-261-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | The --alpha option currently covers two related but different concepts: whether or not to ignore the alpha component and possibly blending it with a background. Because of the way the option currently works, it is impossible to have a transparent window (which requires setting --alpha=yes) while blending it with the background at the same time. To solve this, let's rework it so it it superseded by the background option. --background controls what kind of background to set for the image if possible. It can be blended with the set background color, with tiles, or not blended at all (the last one is still broken on X11/mesa except for GLX, *sigh*). In this new paradigm, --alpha=no has no real purpose because you can simply set the background to color and whatever color you want for exactly the same effect. So the option is removed. Instead, the hint set by windowing backends (i.e. setting ra_ctx->opts.want_alpha) can by done with the --background option. As an aside, the colors in vo_gpu are currently bugged due to not pre-multiplying the alpha and it seems no one ever noticed. The next commit fixes that. vo_gpu_next support happens latter since it requires new things from libplacebo. Fixes #9615.
* vo_gpu/vo_gpu_next: set ctx->opts.want_alpha in specific functionsDudemanguy2024-02-261-5/+2
| | | | | | | | | | | 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.
* vo: remove VOCTRL_SET_EQUALIZER and simplify into UPDATE_VIDEODudemanguy2024-02-171-3/+0
| | | | | | | | | | | | | | | Since 03cf150ff3516789d581214177f291d46310aaf4, the only purpose of this VOCTRL was to signal a redraw to the vo. It actualy could have been removed in 531868fe0d2a35fbbff78d9a9ff8f96df73e69fd, but this was missed. The UPDATE_VIDEO flag is better anyway because it allows us to handle a wide variety of options scattered around that require the VO to update itself and redraw. We can remove both of the custom callbacks in vo.c and only leave the VOCTRL_VO_OPTS_CHANGED one. Additionally, that commit also introduced vo_set_want_redraw, but this is redundant and not needed. The VOs that use VOCTRL_UPDATE_RENDER_OPTS already set vo->want_redraw, and those are the only VOs where these options are relevant in the first place. So we can remove this as well and just let the big callback in player/command do everything.
* vo_gpu: don't pass ra_fbo by valueKacper Michajłow2023-11-281-1/+1
| | | | Make it easier on compiler, no need to alloca and copy things around.
* vo: change vo->driver->wait_events to nanosecondsDudemanguy2023-10-101-3/+3
| | | | | | | | | | | | In many cases, this is purely cosmetic because poll still only accepts microseconds. There's still a gain here however since pthread_cond_timedwait can take a realtime ts now. Additionally, 37d6604d70c8c594de2817db26356c4c950ac0fd changed the value added to timeout_ms in X11 and Wayland to ensure that it would never be 0 and rounded up. This was both incomplete, several other parts of the player have this same problem like drm, and not really needed. Instead the MPCLAMP is just adjusted to have a min of 1.
* vo: hwdec: Pass the ra_ctx to hwdecs instead of just the raPhilip Langdale2023-05-281-1/+1
| | | | | | We will need the full ra_ctx to be able to look up all the state required to initialise an ffmpeg vulkan hwcontext, so pass let's pass the ra_ctx instead of just the ra.
* various: drop unused #include "config.h"Thomas Weißschuh2023-02-201-2/+0
| | | | | | Most sources don't need config.h. The inclusion only leads to lots of unneeded recompilation if the configuration is changed.
* vo: add `int flags` to the get_image signatureNiklas Haas2023-01-231-2/+2
| | | | | This is a huge disgusting mess to thread through everywhere. Maybe I'm stupid for attempting to solve the problem this way.
* vo_gpu[_next]: hwdec: fix logging regression when probingPhilip Langdale2022-03-211-6/+4
| | | | | | | | | When I introduced the concept of lazy loading of hwdecs by img format, I did not propagate the probing flag correctly, leading to the new normal loading path not runnng with probing set, meaning that any errors would show up, creating unnecessary noise. This change fixes this regression.
* vo_gpu: move hwdec loading code to common helperNiklas Haas2022-03-031-1/+1
| | | | | | | So I can reuse it in vo_gpu_next without having to reinvent the wheel. In theory, a lot of the stuff could be made more private inside the hwdec code itself, but for the time being I don't care about refactoring this code, merely sharing it.
* vo_gpu: hwdec: load hwdec interops on-demand by defaultPhilip Langdale2022-02-171-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* vo_gpu: lift ra_ctx_* opts to a global structNiklas Haas2021-11-031-20/+5
| | | | So I can re-use them for vo_gpu_next.
* vo_gpu: fix trivial memory leakYour Name2021-05-071-1/+3
| | | | Nobody noticed this? Seriously?
* options: Make validation and help possible for all option typesPhilip Langdale2021-03-281-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Today, validation is only possible for string type options. But there's no particular reason why it needs to be restricted in this way, and there are potential uses, to allow other options to be validated without forcing the option to have to reimplement parsing from scratch. The first part, simply making the validation function an explicit field instead of overloading priv is simple enough. But if we only do that, then the validation function still needs to deal with the raw pre-parsed string. Instead, we want to allow the value to be parsed before it is validated. That in turn leads to us having validator functions that should be type aware. Unfortunately, that means we need to keep the explicit macro like OPT_STRING_VALIDATE() as a way to enforce the correct typing of the function. Otherwise, we'd have to have the validator take a void * and hope the implementation can cast it correctly. For help, we don't have this problem, as help doesn't look at the value. Then, we turn validators that are really help generators into explicit help functions and where a validator is help + validation, we split them into two parts. I have, however, left functions that need to query information for both help and validation as single functions to avoid code duplication. In this change, I have not added an other OPT_FOO_VALIDATE() macros as they are not needed, but I will add some in a separate change to illustrate the pattern.
* vo_gpu: fix segfault when updating render optsDudemanguy2020-10-151-1/+2
| | | | | | VOCTRL_UPDATE_RENDER_OPTS is supposed to be optional so check if it actually exists before executing the function. Fixes a segfault when changing the alpha value at runtime on non-wayland platforms.
* vo_gpu: update render options on runtimeDudemanguy2020-10-151-4/+13
| | | | | | | | | | | | vo_gpu has a small set of options for ra_ctx that can be set. In practice, runtime toggling doesn't matter for most of these as they have no effect while a video is playing. However, changing the alpha option during runtime can actually work depending on the backend used. mpv already detected when one of these options changed, but it made no attempt to update the options in the ra_ctx accordingly (likely because nothing made any use of this information). Another related change is to add an update_render_opts to the fns and allow invidiual backends to (optionally) use it.
* options: change option macros and all option declarationswm42020-03-181-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change all OPT_* macros such that they don't define the entire m_option initializer, and instead expand only to a part of it, which sets certain fields. This requires changing almost every option declaration, because they all use these macros. A declaration now always starts with {"name", ... followed by designated initializers only (possibly wrapped in macros). The OPT_* macros now initialize the .offset and .type fields only, sometimes also .priv and others. I think this change makes the option macros less tricky. The old code had to stuff everything into macro arguments (and attempted to allow setting arbitrary fields by letting the user pass designated initializers in the vararg parts). Some of this was made messy due to C99 and C11 not allowing 0-sized varargs with ',' removal. It's also possible that this change is pointless, other than cosmetic preferences. Not too happy about some things. For example, the OPT_CHOICE() indentation I applied looks a bit ugly. Much of this change was done with regex search&replace, but some places required manual editing. In particular, code in "obscure" areas (which I didn't include in compilation) might be broken now. In wayland_common.c the author of some option declarations confused the flags parameter with the default value (though the default value was also properly set below). I fixed this with this change.
* Revert "vo: add support for externally driven renderloop and make wayland ↵dudemanguy2019-10-101-1/+1
| | | | | | | | | | use it" The externally driven renderloop was originally added for the wayland context (to make display sync somewhat work), but it has a lot of issues with mpv's internal structure. A different approach should be used. This reverts commit a743fef837bcab206b1e576db7e7a64b02890449.
* vo: make swapchain-depth option generic for all VOsAnton Kindestam2019-09-281-6/+0
| | | | In preparation for making vo_drm able to use swapchain-depth
* vo: use a struct for vsync feedback stuffwm42018-12-061-3/+4
| | | | So new useless stuff can be easily added.
* vo_gpu: glx: use GLX_OML_sync_control for better vsync reportingwm42018-12-061-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the extension to compute the (hopefully correct) video delay and vsync phase. This is very fuzzy, because the latency will suddenly be applied after some frames have already been shown. This means there _will_ be "jumps" in the time accounting, which can lead to strange effects at start of playback (such as making initial "dropped" etc. frames worse). The only reasonable way to fix this would be running a few dummy frame swaps at start of playback until the latency is known. The same happens when unpausing. This only affects display-sync mode. Correct function was not confirmed. It only "looks right". I don't have the equipment to make scientifically correct measurements. A potentially bad thing is that we trust the timestamps we're receiving. Out of bounds timestamps could wreak havoc. On the other hand, this will probably cause the higher level code to panic and just disable DS. As a further caveat, this makes a bunch of assumptions about UST timestamps. If there are delayed frames (i.e. we skipped one or more vsyncs), the latency logic is mostly reset. There is no attempt to make the vo.c skipped vsync logic to use this. Also, the latency computation determines a vsync duration, and there's no effort to reconcile or share the vo.c logic for determining vsync duration.
* vo_gpu: move some extra code for screenshot to video.cwm42018-04-201-8/+1
| | | | | This also happens to fix some UB on the error path (target being declared after the first "goto done;").
* vo_gpu: remove old window screenshot glue code and GL implementationwm42018-02-131-12/+0
| | | | | | | | | | | There is now a better way. Reading the font framebuffer was always a hack. The new code via VOCTRL_SCREENSHOT renders it into a FBO, which does not come with the disadvantages of reading the front buffer (like not being supported by GLES, possibly black regions due to overlapping windows on some systems). For now keep VOCTRL_SCREENSHOT_WIN on the VO level, because there are still some lesser VOs and backends that use it.
* vo_gpu: make screenshots use the GL rendererwm42018-02-111-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | Using the GL renderer for color conversion will make sure screenshots will use the same conversion as normal video rendering. It can do this for all types of screenshots. The logic when to write 16 bit PNGs changes. To approximate the old behavior, we decide by looking whether the source video format has more than 8 bits per component. We apply this logic even for window screenshots. Also, 16 bit PNGs now always include an unused alpha channel. The reason is that FFmpeg has RGB48 and RGBA64 formats, but no RGB064. RGB48 is 3 bytes and usually not supported by GPUs for rendering, so we have to use RGBA64, which forces an alpha channel. Will break for users who use --target-trc and similar options. I considered creating a new gl_video context, but it could double GPU memory use, so I didn't. This uses FBOs instead of glGetTexImage(), because that increases the chance it could work on GLES (e.g. ANGLE). Untested. No support for the Vulkan and D3D11 backends yet. Fixes #5498. Also fixes #5240, because the code for reading back is not used with the new code path.
* vo_gpu: add internal ability to skip osd/subs for renderingwm42018-02-111-1/+1
| | | | Needed for the following commit.
* player: add internal `vo-resize` commandsfan52017-12-271-0/+4
| | | | Intended to be used with the properties from previous commit.
* vo: add support for externally driven renderloop and make wayland use itRostislav Pehlivanov2017-12-051-1/+1
| | | | | | | | | | | Fixes display-sync (though if you change virtual desktops you'll need to seek to re-enable display-sync) partially under wayland. As an advantage, rendering is completely disabled if you change desktops or alt+tab so you lose no performance if you leave mpv running elsewhere as long as it isn't visible. This could also be ported to other VOs which supports it.
* vo_gpu: make it possible to load multiple hwdec interop driverswm42017-12-011-16/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
* vo_gpu: potentially fix icc-profile-auto updatingwm42017-11-011-1/+1
| | | | | | | | | | | vo_gpu.c will call gl_video_icc_auto_enabled() to check whether it should retrieve the ICC profile. But the value returned by this function will be outdated, because gl_video_update_options() is not called yet. Change the order of function calls so that this is done after updating the options. (This is fairly chaotic, but I guess this code will be refactored a dozen of times anyway in the future.)
* vo_gpu: remove weird p->vo indirectionwm42017-10-171-11/+9
| | | | That's just unnecessary.
* vo_gpu: fix video sometimes not being rerendered on equalizer changewm42017-10-171-1/+0
| | | | | | | | | | | | | | With video paused, changing the brightness controls (or similar) would sometimes not rerender the video frame. So the OSD would redraw, but the video wouldn't change. This is caused by output caching, and a redraw request is free to return the cached frame. Change it such to invalidate the cached frame if any of the options or the equalizer change. In theory, gl_video_reset_surfaces() could be called if the equalizer changes - this would apparently force interpolatzion to redraw all frames. But this looks kind of crappy when changing the equalizer during playback. It'll "eventually" use the correct settings anyway, and when paused interpolation is off.
* vo_gpu: remove some minor dead codewm42017-10-161-3/+1
| | | | | This was for the "opengl" compat VO entry, which is now handled differently.
* vo_gpu: simplify opengl aliaswm42017-10-091-28/+0
| | | | | This makes the replacement warning message worse, but I don't think I care enough.
* vo_gpu: remove duplicated optionswm42017-10-091-1/+0
| | | | | All these options (like --gpu-context etc.) were duplicated. It's amazing that it didn't cause more problems than it did.
* vo_gpu: vulkan: initial implementationNiklas Haas2017-09-261-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This time based on ra/vo_gpu. 2017 is the year of the vulkan desktop! Current problems / limitations / improvement opportunities: 1. The swapchain/flipping code violates the vulkan spec, by assuming that the presentation queue will be bounded (in cases where rendering is significantly faster than vsync). But apparently, there's simply no better way to do this right now, to the point where even the stupid cube.c examples from LunarG etc. do it wrong. (cf. https://github.com/KhronosGroup/Vulkan-Docs/issues/370) 2. The memory allocator could be improved. (This is a universal constant) 3. Could explore using push descriptors instead of descriptor sets, especially since we expect to switch descriptors semi-often for some passes (like interpolation). Probably won't make a difference, but the synchronization overhead might be a factor. Who knows. 4. Parallelism across frames / async transfer is not well-defined, we either need to use a better semaphore / command buffer strategy or a resource pooling layer to safely handle cross-frame parallelism. (That said, I gave resource pooling a try and was not happy with the result at all - so I'm still exploring the semaphore strategy) 5. We aggressively use pipeline barriers where events would offer a much more fine-grained synchronization mechanism. As a result of this, we might be suffering from GPU bubbles due to too-short dependencies on objects. (That said, I'm also exploring the use of semaphores as a an ordering tactic which would allow cross-frame time slicing in theory) Some minor changes to the vo_gpu and infrastructure, but nothing consequential. NOTE: For safety, all use of asynchronous commands / multiple command pools is currently disabled completely. There are some left-over relics of this in the code (e.g. the distinction between dev_poll and pool_poll), but that is kept in place mostly because this will be re-extended in the future (vulkan rev 2). The queue count is also currently capped to 1, because of the lack of cross-frame semaphores means we need the implicit synchronization from the same-queue semantics to guarantee a correct result.
* vo_gpu: simplify structs / namesNiklas Haas2017-09-221-10/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
* vo_gpu: fix vo=opengl legacy aliasNiklas Haas2017-09-211-2/+4
| | | | | | | Turns out the option code apparently tries to directly talloc_free() the allocated strings, instead of going through a tactx wrapper or something. So we can't directly overwrite it. Do something else instead..
* vo_opengl: refactor into vo_gpuNiklas Haas2017-09-211-0/+385
This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-04 02:46:07 +0000