summaryrefslogtreecommitdiffstats
path: root/video/out/gpu
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu_next: add missing --gamut-mapping-mode optionsNiklas Haas2023-06-212-3/+13
| | | | | Adds the missing upstream values that were exposed by the new gamut mapping API.
* hwdec_vulkan: add Vulkan HW InteropPhilip Langdale2023-05-281-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vulkan Video Decoding has finally become a reality, as it's now showing up in shipping drivers, and the ffmpeg support has been merged. With that in mind, this change introduces HW interop support for ffmpeg Vulkan frames. The implementation is functionally complete - it can display frames produced by hardware decoding, and it can work with ffmpeg vulkan filters. There are still various caveats due to gaps and bugs in drivers, so YMMV, as always. Primary testing has been done on Intel, AMD, and nvidia hardware on Linux with basic Windows testing on nvidia. Notable caveats: * Due to driver bugs, video decoding on nvidia does not work right now, unless you use the Vulkan Beta driver. It can be worked around, but requires ffmpeg changes that are not considered acceptable to merge. * Even if those work-arounds are applied, Vulkan filters will not work on video that was decoded by Vulkan, due to additional bugs in the nvidia drivers. The filters do work correctly on content decoded some other way, and then uploaded to Vulkan (eg: Decode with nvdec, upload with --vf=format=vulkan) * Vulkan filters can only be used with drivers that support VK_EXT_descriptor_buffer which doesn't include Intel ANV as yet. There is an MR outstanding for this. * When dealing with 1080p content, there may be some visual distortion in the bottom lines of frames due to chroma scaling incorporating the extra hidden lines at the bottom of the frame (1080p content is actually stored as 1088 lines), depending on the hardware/driver combination and the scaling algorithm. This cannot be easily addressed as the mechanical fix for it violates the Vulkan spec, and probably requires a spec change to resolve properly. All of these caveats will be fixed in either drivers or ffmpeg, and so will not require mpv changes (unless something unexpected happens) If you want to run on nvidia with the non-beta drivers, you can this ffmpeg tree with the work-around patches: * https://github.com/philipl/FFmpeg/tree/vulkan-nvidia-workarounds
* vo: hwdec: Pass the ra_ctx to hwdecs instead of just the raPhilip Langdale2023-05-286-17/+22
| | | | | | 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.
* vo: make mp_frame_perf thread safeKacper Michajłow2023-05-251-1/+3
| | | | | | | It was unsafe to return pointer to memory that was freed on another thread, just copy the string to caller owned sturcture. Fixes crashes when displaying passes stats with gpu-next.
* vo_gpu_next: remove --tone-mapping-crosstalkNiklas Haas2023-05-242-4/+1
| | | | Removed upstream, to be replaced by constant 0.04.
* vo_gpu_next: allow to use ICC profile luminance valueKacper Michajłow2023-05-132-0/+2
| | | | | | Also while at it respect target-peak option when ICC profile is used. Fixes #11449
* player: use XDG_CACHE_HOME by defaultDudemanguy2023-05-096-6/+21
| | | | | | | | | | | | This adds cache as a possible path for mpv to internally pick (~/.cache/mpv for non-darwin unix-like systems, the usual config directory for everyone else). For gpu shader cache and icc cache, controlling whether or not to write such files is done with the new --gpu-shader-cache and --icc-cache options respectively. Additionally, --cache-on-disk no longer requires explicitly setting the --cache-dir option. The old options, --cache-dir, --gpu-shader-cache-dir, and --icc-cache-dir simply set an override for the directory to save cache files. If unset, then the cache is saved in XDG_CACHE_HOME.
* video/out/gpu: Fix compilation warning of out of bound accessMika Kuoppala2023-04-101-7/+9
| | | | | | Make the index into the arrays in copy_image() unsigned to make compiler trust that we dont access out of bounds.
* d3d11: retry device creation without debug, if SDK is not availableKacper Michajłow2023-04-021-1/+10
| | | | Fixes #11512
* various: fix various typos in the code baseAlexander Seiler2023-03-281-1/+1
| | | | Signed-off-by: Alexander Seiler <seileralex@gmail.com>
* various: fix typosHarri Nieminen2023-03-282-2/+2
| | | | Found by codespell
* test: integrate unittests with mesonDudemanguy2023-03-023-15/+18
| | | | | | | | | | | | This reworks all of mpv's unit tests so they are compiled as separate executables (optional) and run via meson test. Because most of the tests are dependant on mpv's internals, existing compiled objects are leveraged to create static libs and used when necessary. As an aside, a function was moved into video/out/gpu/utils for sanity's sake (otherwise most of vo would have been needed). As a plus, meson multithreads running tests automatically and also the output no longer pollutes the source directory. There are tests that can break due to ffmpeg changes, so they require a specific minimum libavutil version to be built.
* vo_gpu: improve XYZ conversionKacper Michajłow2023-03-021-1/+8
| | | | Fixes #4925
* csputils: add MP_CSP_TRC_ST428 as defined in ST 428-1Kacper Michajłow2023-03-021-0/+6
|
* ra: assert when using params with dimensionsDudemanguy2023-03-021-0/+10
| | | | | | | | | | This came up in #9828. According to the header comments, creating a 1D ra_tex requires height and depth to be set to 1. For a 2D texture, it requires depth be set to 1. There were a couple of spots in mpv's code where this wasn't being followed. Although there was no known bug from this, the rest of the code works like this so it was a good idea to go ahead and sync it up. As a followup, let's just add some simple asserts to ra.c to enforce this so it doesn't go unnoticed in the future.
* wayland: use bool type for alpha framebuffer trackingRay Smith2023-02-281-1/+1
| | | | | | | | | ra_ctx_opts.want_alpha and vo_wayland_set_opaque_region's alpha argument are only used as bool but both are ints. Particularly for the function argument, passing a 0 or 1 is confusing - at first glance it looks like you're specifying an alpha value of 0 or 1. Since they're only used as bools, make them bools.
* vo_gpu: d3d11_helpers: prefer DXGI_SWAP_EFFECT_FLIP_DISCARD if possiblemsoxzw2023-02-281-2/+8
| | | | | | | Similar to libplacebo[1], DXGI_SWAP_EFFECT_FLIP_DISCARD is used instead of DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL starting with Windows 10. [1]: https://github.com/haasn/libplacebo/blob/master/src/d3d11/swapchain.c
* video: initialize depth=1 on screenshot texturesaverne2023-02-281-0/+1
| | | | | According to internal documentation, 2D textures should have d=1. This fixes the correctness of the API usage, not any bug.
* vo_gpu: fix newline in log messagesfan52023-02-241-1/+1
|
* options: transition commands from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-212-1/+1
|
* options: transition options from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-217-38/+38
| | | | | | c78482045444c488bb7948305d583a55d17cd236 introduced a bool option type as a replacement for the flag type, but didn't actually transition and remove the flag type because it would have been too much mundane work.
* various: drop unused #include "config.h"Thomas Weißschuh2023-02-201-1/+0
| | | | | | Most sources don't need config.h. The inclusion only leads to lots of unneeded recompilation if the configuration is changed.
* Vulkan: add configure check for VK_KHR_display extensionrcombs2023-02-201-0/+2
| | | | This allows building directly against ICDs that don't implement this extension.
* vo_gpu_next: add --tone-mapping-visualizeNiklas Haas2023-02-192-0/+2
|
* vo_gpu_next: expose --tone-mapping=st2094-40 and st2094-10Niklas Haas2023-02-132-1/+5
|
* osdep: add MP_FALLTHROUGHKacper Michajłow2023-02-021-1/+1
|
* vo_gpu: implement VO_DR_FLAG_HOST_CACHEDsfan52023-01-232-0/+8
| | | | | | | | For OpenGL, this is based on simply comparing GL_VENDOR strings against a list of allowed vendors. Co-authored-by: Nicolas F. <ovdev@fratti.ch> Co-authored-by: Niklas Haas <git@haasn.dev>
* vo: add `int flags` to the get_image signatureNiklas Haas2023-01-233-4/+4
| | | | | This is a huge disgusting mess to thread through everywhere. Maybe I'm stupid for attempting to solve the problem this way.
* various: replace abort() with MP_ASSERT_UNREACHABLE() where appropriatesfan52023-01-124-7/+6
| | | | | | | | In debug mode the macro causes an assertion failure. In release mode it works differently and tells the compiler that it can assume the codepath will never execute. For this reason I was conversative in replacing it, e.g. in mpv-internal code that exhausts all valid values of an enum or when a condition is clear from directly preceding code.
* various: replace if + abort() with MP_HANDLE_OOM()sfan52023-01-122-6/+3
| | | | | MP_HANDLE_OOM also aborts but calls assert() first, which will result in an useful message if compiled in debug mode.
* lcms: fix validate_3dlut_size_optNiklas Haas2022-11-211-4/+1
| | | | | Not only was this function needlessly convoluted, it was also broken - since it returned a bool value where an error code was expected.
* lcms: always parse lcms2-related optionsNiklas Haas2022-11-211-40/+34
| | | | | | | | | | | | | | Currently, the lcms-related options are only defined when lcms2 is enabled at build time. However, this causes issues (e.g. segfault) for vo_gpu_next, which relies on the presence of these options (to forward them to libplacebo). (That libplacebo internally depends on lcms2 as well is an implementation detail - compiling mpv *without* lcms against libplacebo *with* lcms should be possible in principle) Fixes: #10891 Closes: #10856
* vo: hwdec: remove legacy_namesPhilip Langdale2022-11-152-13/+0
| | | | | These were introduced for configuration compatibility in 0.35 but we don't want to retain them past that point.
* vo_gpu_next: add tunable shader parametersNiklas Haas2022-11-112-0/+2
| | | | | | | | | | | This is a very simple but easy way of doing it. Ideally, it would be nice if we could also add some sort of introspection about shader parameters at runtime, ideally exposing the entire list of parameters as a custom property dict. But that is a lot of effort for dubious gain. It's worth noting that, as currently implemented, re-setting `glsl-shader-opts` to a new value doesn't reset back previously mutated values to their defaults.
* vo_gpu: mark --gamma-factor and --gamma-auto with deprecation warningssfan52022-11-101-2/+4
| | | | This was forgotten in commit 2207236aaae54f32c1861c6fd77219e28139dc78.
* gpu/context: properly guard wldmabuf contextDudemanguy2022-11-031-1/+1
| | | | | This should only be added if the build has dmabuf-wayland enabled. This fixes #10828.
* vo_dmabuf_wayland: use special ra_ctx_create_by_nameDudemanguy2022-10-282-6/+39
| | | | | | | | | | | | | | | | | | | vo_dmabuf_wayland has its own ra and context so it can handle all the different hwdec correctly. Unfortunately, this API was pretty clearly designed with vo_gpu/vo_gpu_next in mind and has a lot of concepts that don't make sense for vo_dmabuf_wayland. We still want to bolt on a ra_ctx, but instead let's rework the ra_ctx logic a little bit. First, this introduces a hidden bool within the ra_ctx_fns that is used to hide the wldmabuf context from users as an option (unlike the other usual contexts). We also want to make sure that hidden contexts wouldn't be autoprobed in the usual ra_ctx_create, so we be sure to skip those in that function. Additionally, let's create a new ra_ctx_create_by_name function which does exactly what says. It specifically selects a context based on a passed string. This function has no probing or option logic is simplified just for what vo_dmabuf_wayland needs. The api/context validations functions are modified just a little bit to make sure hidden contexts are skipped and the documentation is updated to remove this entries. Fixes #10793.
* vo_dmabuf_wayland: wayland VO displaying dmabuf buffersAaron Boxer2022-10-261-0/+7
| | | | | | | | | | | | | Wayland VO that can display images from either vaapi or drm hwdec The PR adds the following changes: 1. a context_wldmabuf context with no gl dependencies 2. no-op ra_wldmabuf and dmabuf_interop_wldmabuf objects no-op because there is no need to map/unmap the drmprime buffer, and there is no need to manage any textures. Tested on both x86_64 and rk3399 AArch64
* vo_gpu/hwdec: add NULL check for legacy_namePhilip Langdale2022-10-221-1/+1
|
* vo_gpu/hwdec: rename and introduce legacy names for some interopsPhilip Langdale2022-10-112-4/+17
| | | | | | | | | | | | We've had some annoying names for interops, which we can't simply rename because that would break config files and command lines. So we need to put a little more effort in and add a concept of legacy names that allow us to continue loading them, but with a warning. The two I'm renaming here are: * vaapi-egl -> vaapi (vaapi works with Vulkan too) * drmprime-drm -> drmprime-overlay (actually describes what it does) * cuda-nvdec -> cuda (cuda interop is not nvdec specific)
* vo_gpu: hwdec: add Android hwdec utilizing AImageReadersfan52022-10-021-0/+4
|
* filters: lavfi: allow hwdec_interop selection for filtersPhilip Langdale2022-09-212-10/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Today, lavfi filters are provided a hw_device from the first hwdec_interop that was loaded, regardless of whether it's the right one or not. In most situations where a hardware based filter is used, we need more control over the device. In this change, a `hwdec_interop` option is added to the lavfi wrapper filter configuration and this is used to pick the correct hw_device to inject into the filter or graph (in the case of a graph, all filters get the same device). Note that this requires the use of the explicit lavfi syntax to allow for the extra configuration. eg: ``` mpv --vf=hwupload ``` becomes ``` mpv --vf=lavfi=[hwupload]:hwdec_interop=cuda-nvdec ``` or ``` mpv --vf=lavfi-bridge=[hwupload]:hwdec_interop=cuda-nvdec ```
* filters: support loading new hwdec_interops from filtersPhilip Langdale2022-09-211-1/+1
| | | | | | | | | | | | | | | | | | | | If we want to be able to handle conversion between hw formats in filter chains, then we need to be able to load hwdec_interops from filters, as the VO is only ever going to initialise one interop, based on its configuration. That means that in almost all situations, only one of the required interops will be loaded at the time the filter is initialised. The existing code has some assumptions that new hwdec_interops will not be loaded after the vo has picked one to use. This change fixes two instances: * Refusing to load a new hwdec_interop if there is at least one loaded already. * Not recalculating the set of formats known to the autoconvert filter when a new output format shows up. This leads to autoconvert not knowing that a new format is supported when the hwdec interop is lazily loaded.
* gpu/hwdec: reorder `drmprime` below `drmprime_drm`Philip Langdale2022-08-091-1/+1
| | | | | | | | | | | | | | The older overlay based drmprime hwdec should be preferred to the new texture mapping one. This is for a few reasons: 1. In any situation where both hwdecs work, it's probably right to use the more mature one by default, for now. 2. It seems like the overlay path primarily works on older SoCs where the texture path is less performant, and in at least one tested case is visually buggy, so you definitely want it to be tried first. 3. In situations where the old hwdec doesn't work, it will fall through to the new one.
* hwdec/drmprime: add drmprime hwdec-interopPhilip Langdale2022-08-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the confusing landscape of hardware video decoding APIs, we have had a long standing support gap for the v4l2 based APIs implemented for the various SoCs from Rockship, Amlogic, Allwinner, etc. While VAAPI is the defacto default for desktop GPUs, the developers who work on these SoCs (who are not the vendors!) have preferred to implement kernel APIs rather than maintain a userspace driver as VAAPI would require. While there are two v4l2 APIs (m2m and requests), and multiple forks of ffmpeg where support for those APIs languishes without reaching upstream, we can at least say that these APIs export frames as DRMPrime dmabufs, and that they use the ffmpeg drm hwcontext. With those two constants, it is possible for us to write a hwdec-interop without worrying about the mess underneath - for the most part. Accordingly, this change implements a hwdec-interop for any decoder that produces frames as DRMPrime dmabufs. The bulk of the heavy lifting is done by the dmabuf interop code we already had from supporting vaapi, and which I refactored for reusability in a previous set of changes. When we combine that with the fact that we can't probe for supported formats, the new code in this change is pretty simple. This change also includes the hwcontext_fns that are required for us to be able to configure the hwcontext used by `hwdec=drm-copy`. This is technically unrelated, but it seemed a good time to fill this gap. From a testing perspective, I have directly tested on a RockPRO64, while others have tested with different flavours of Rockchip and on Amlogic, providing m2m coverage. I have some other SoCs that I need to spin up to test with, but I don't expect big surprises, and when we inevitably need to account for new special cases down the line, we can do so - we won't be able to support every possible configuration blindly.
* vo_gpu: fix 3DLUT precisionNiklas Haas2022-07-151-2/+3
| | | | | | | | | | | | | Using cmsFLAGS_HIGHRESPRECALC results in Little-CMS generating an internal 49x49x49 3DLUT, from which it then samples our own 3DLUT. This is completely pointless and not only destroys the accuracy of the 3DLUT, but also results in no additional gain from increasing the 3DLUT precision further. The correct flag for us to be using is cmsFLAGS_NOOPTIMIZE, which suppresses this internal 3DLUT generation and gives us the full precision. We can also specify cmsFLAGS_NOCACHE, which is negligible but in theory prevents Little-CMS from unnecessary pixel equality tests.
* various: remove trailing whitespaceGuido Cella2022-05-141-1/+1
|
* various: fix typosCœur2022-04-253-3/+3
|
* vo_gpu_next: switch to unpooled hwdec mappingNiklas Haas2022-04-112-2/+2
| | | | | | | | | | | | This makes use of the new frame acquire/release callbacks to hold on to hwdec images only as long as necessary. This should greatly improve the smoothness/efficiency of hwdec interop, by not holding on to them for longer than needed. This also avoids the need to pool hwdec mappers altogether. Should fix #10067 as well, since frames are now only mapped when we actually use them.
* vo_gpu[_next]: hwdec: fix logging regression when probingPhilip Langdale2022-03-214-8/+9
| | | | | | | | | 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.
* hwdec: fix out-of-date preprocessor variable nameNiklas Haas2022-03-041-1/+1
| | | | This was renamed to HAVE_VAAPI_LIBPLACEBO.
* vo_gpu: move hwdec loading code to common helperNiklas Haas2022-03-035-152/+192
| | | | | | | 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.
* hwdec: release images as soon as possible after mappingNiklas Haas2022-03-031-0/+2
| | | | | | | | | | We don't need to hold on to buffers longer than necessary. Doesn't matter for vo_gpu but greatly matters for vo_gpu_next, since it persists hwdec mapped textures for longer periods. Unfortunately, only provides benefits for hwdecs which do explicit copies in their decode path, which currently just means cuda and d3d11va.
* vo_gpu: hwdec: load hwdec interops on-demand by defaultPhilip Langdale2022-02-172-7/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: d3d11_helpers: don't create UNORDERED_ACCESS backbuffers in Win7James Ross-Gowan2022-02-091-0/+10
| | | | | | | | | | | | | | We're getting bug reports that the recent change to add extra usage flags to swapchain buffers (for gpu-next) breaks mpv on some Windows 7 systems, and it seems like this is only happening with flip-model swapchains. Creating swapchains with DXGI_USAGE_UNORDERED_ACCESS should be valid. At least, it's not specifically disallowed, unlike some other flags[1]. So, just disable it for flip-model swapchains in Windows 7, rather than disabling it everywhere. [1]: https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-usage
*