summaryrefslogtreecommitdiffstats
path: root/video/out/gpu
Commit message (Collapse)AuthorAgeFilesLines
* 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
* vo_gpu: add HOOKED_gatherNiklas Haas2022-01-151-0/+5
| | | | | Can be used conditionally (via #ifdef HOOKED_gather) to use textureGather in custom shaders.
* sub: rename SUBBITMAP_RGBA to SUBBITMAP_BGRANiklas Haas2022-01-111-3/+3
| | | | | This was a misnomer, the actual channel order is IMGFMT_BGRA (as the comment explicitly point out). Rename the enum for consistency.
* vo_gpu: add --tone-mapping-modeNiklas Haas2022-01-073-19/+47
| | | | | | | | | | | This merges the old desaturation control options into a single enumeration, with the goal of both simplifying how these options work and also making this list more extensible (including, notably, new options only supported by vo_gpu_next). For the hybrid option, I decided to port the (slightly tweaked) values from libplacebo's pre-refactor defaults, rather than the old values we had in mpv, to more visually match the look of the vo_gpu_next hybrid.
* vo_gpu: add --gamut-mapping-modeNiklas Haas2022-01-073-8/+32
| | | | | | | Merge --gamut-clipping and --gamut-warning into a single option, --gamut-mapping-mode, better corresponding to the new vo_gpu_next APIs and allowing us to easily extend this option as new modes are added in the future.
* vo_gpu_next: update for new tone mapping optionsNiklas Haas2022-01-073-12/+42
| | | | | | | This was significantly refactored upstream. Switch to new APIs and add new tone mapping curves and options. cf. https://code.videolan.org/videolan/libplacebo/-/merge_requests/212
* vo_gpu: move image2D precision qualifier to point of usesfan52022-01-021-3/+1
| | | | | | | image2D is only defined from GLSL ES 3.1 onwards, so those statements broke GLES 2.0. Move the qualifier to a place that is only reached with the right version requirements. fixes commit 584ab29c88d6c5ffa03666bffbbc93e4f0740f67
* vo_gpu: stop hard-coding max compute group threadsPhilip Langdale2021-12-192-6/+7
| | | | | | | | | | We've been assuming that maximum number of compute group threads is never less than the 1024 defined by the desktop GL spec. Given that we haven't had working compute shaders for GLES and I guess the Vulkan spec defines at least as high a value, we've gotten away with it so far. But we should really look the value up and respect it.
* {player,video}: remove references to obsolete opengl-cb APIsfan52021-12-151-2/+2
|
* vo_gpu: opengl: some fixes to make compute shaders work with GLESPhilip Langdale2021-12-124-10/+15
| | | | | | | | | It's supposed to work with GLES >= 3.1 but we had all sorts of bad assumptions in our version handling, and then our compute shaders turn out not to be GLSL-ES compliant. This change contains some necessary, but insufficient, tweaks to the shaders. Perhaps we'll make it actually work some day.
* osdep: rename MP_UNREACHABLENiklas Haas2021-11-031-1/+1
| | | | | It was pointed out on IRC that the name is misleading, since the actual semantics of the macro is to assert first.
* osdep: add MP_UNREACHABLENiklas Haas2021-11-031-1/+1
| | | | | | | | | This seems to work on gcc, clang and mingw as-is, but I made it conditional on __GNUC__ just in case, even though I can't figure out which compilers we care about that don't export this define. Also replace all instances of assert(0) in the code by MP_UNREACHABLE(), which is a strict improvement.
* vo_gpu: allow using bare windows as --(t)scaleNiklas Haas2021-11-031-0/+20
| | | | | | | | | | | A lot of people seem to do something like --tscale=box --tscale-window=<function>. Just let them use --tscale=<function> directly, by also accepting raw windows. Kinda hacky but needed for feature parity with vo_gpu_next, which no longer has `--tscale=box`. Note that because the option struct is still shared, vo_gpu_next inherits the same option handling code, so we have to export this feature for vo_gpu as well.
* vo_gpu: lift ra_ctx_* opts to a global structNiklas Haas2021-11-036-48/+55
| | | | So I can re-use them for vo_gpu_next.
* vo_gpu: fix rotated compute shader vertex simulationNiklas Haas2021-10-221-10/+2
| | | | | | | | Upon re-examination I have no idea why this code was ever written or what problem it was trying to solve. But, getting rid of it fixes #9291. It might be a remnant from before 2af2fa7a27. Who knows. This code will be replaced soon(tm) anyways.
* vo_gpu: vulkan: implement a VkDisplayKHR backed contextPhilip Langdale2021-06-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This is the Vulkan equivalent of the drm context for OpenGL, with the big difference that it's implemented purely in terms of Vulkan calls and doesn't actually require drm or kms. The basic idea is to identify a display, mode, and plane on a device, and then create a display backed surface for the swapchain. In theory, past that point, everything is the same, and this is in fact the case on Intel hardware. I can get a video playing on a vt. On nvidia, naturally, things don't work that way. Instead, nvidia only implemented the extension for scenarios where a VR application is stealing a display from a running window system, and not for standalone scenarios. With additional code, I've got this scenario to work but that's a separate incremental change. Other people have tested on AMD, and report roughly the same behaviour as on Intel. Note, that in this change, the VT will not be correctly restored after qutting. The only way to restore the VT is to introduce some drm specific code which I will illustrate in a separate change.
* vo_gpu: replace --icc-contrast by --icc-force-contrastNiklas Haas2021-05-261-41/+40
| | | | | | | | | | | | | | Not only does this have semantics that make far more sense, it also has a default that makes far more sense. (Equivalent to the old `icc-contrast=inf`) This removes the weird 1000:1 contrast default assumption which especially broke perceptual profiles and also screws things up for OLED/CRT/etc. Should probably close some issues but I honestly can't be bothered to figure out which of the thousands colorimetry-related issues are affected.
* vo_gpu: fix extreme clipping with --gamut-clipping for HDR outputsNiklas Haas2021-05-221-1/+2
| | | | | | Checking against 1.0 is wrong for this code, because it's in an absolute luminance scale relative to reference white. We should be normalizing this by `dst.sig_peak`.
* Revert "vo_gpu: revert 8a09299 and conditionally clear framebuffer again"Your Name2021-05-071-5/+3
| | | | | | | | | | This reverts commit b8156a9a86ae4ff087b1b255c68a3ca38ec2d086. Apparently there are two problems here. One on Linux (fixed by the original change and this revert) and one on alternative-medicine-Job's OS. Since the latter has deprecated OpenGL and OpenGL is a second-class citizen, I think it's better to prefer the fix for a platform that is still alive.
* vo_gpu: greatly increase maximum shader cache sizeNiklas Haas2021-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | See #8137 for justification. This is not ideal, because a large cache results in a lot of `strcmp` invocations for every single shader invocation. But it's way better than resulting in a lot of shader recompilations for every single shader invocation. The only reason I don't want to uncap it altogether is because there are conceivable edge cases in which users load dynamically generated shaders with updated parameters (indeed, I've seen IRC discussions to this effect), and in this case, we don't want to grow the cache infinitely as a result of something like a floating point parameter being continuously updated. (Never mind that this *would* actually trigger worst case behavior for the `strcmp`, since the updated float constant is likely to be near the bottom of the shader body) Whatever. vo_placebo will liberate us all in the end.
* vo_gpu: adjust interpolation_threshold's defaultLaserEyess2021-03-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When mpv attempts to play a video that is, on average, 60 FPS on a display that is not exactly 60.00 Hz, two options try to fight each other: `video-sync-max-video-change` and `interpolation-threshold`. Normally, container FPS in something such as an .mp4 or a .mkv is precise enough such that the video can be retimed exactly to the display Hz and interpolation is not activated. In the case of something like certain live streaming videos or other scenario where container FPS is not known, the default option of 0.0001 for `interpolation-threshold` is extremely low, and while `video-sync-max-video-change` retimes the video to what it approximately knows as the "real" FPS, this may or may not be outside of `interpolation-threshold`'s logic at any given time, which causes interpolation to be frequently flipped on and off giving an appearance of stuttering or repeated frames that is oftern quite jarring and makes a video unwatchable. This commit changes the default of `interpolation-threshold` to 0.01, which is the same value as `video-sync-max-video-change`, and guarantees that if the user accepts a video being retimed to match the display, they do not additionally have to worry about a much more precise interpolation threshold randomly flipping on or off. No internal logic is changed so setting `interpolation-threshold` to -1 will still disable this logic entirely and always enable interpolation. The documentation has been updated to reflect this change and give context to the user for which scenarios they might want to disable `interpolation-threshold` logic or change it to a smaller value.
* options: Make validation and help possible for all option typesPhilip Langdale2021-03-286-27/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: don't abort() if plane tex creation failsNiklas Haas2021-02-161-3/+4
| | | | | | | In this case, we just treat all uploads as automatically failing. That error path already exists and is already handled correctly. Fixes #8566
* vo_gpu: lower default deband thresholdMia Herkt2021-02-051-1/+1
| | | | | The previous default was found to be too aggressive for most video. Change to a lower value to prevent destroying too much detail.
* vo_gpu: don't segfault if 3DLUT texture fails uploadingNiklas Haas2021-01-011-0/+5
| | | | This failure path was never properly checked.
* vo_gpu: cast bvecN to vecN for mix() on older GLSLNiklas Haas2020-12-284-49/+85
| | | | Fixes https://github.com/mpv-player/mpv/issues/8415, among others
* vo_gpu: revert 8a09299 and conditionally clear framebuffer againder richter2020-12-061-3/+5
| | | | | | | | | | | | | | | | | | | | in the original commit, that removed the conditional clearing, an incorrect assumption was made that clearing "should be practically free" and can be done always. though, at least on macOS + intel this can have a performance impact of up to 50% increased usage. it might have an impact on other platforms and setups as well, but this is unconfirmed. the reason for removing the conditional clearing was to partially work around a driver bug on very specific setups, X11 with amdgpu and OpenGL, to clear garbled frames on start. though it still has issues with garbled frames in other situation like fullscreening. there is also an open bug report on the mesa bug tracker about this. setting the radeonsi_zerovram flag works around all of those issues. since the flag works around all these issues and the original fix doesn't work completely we revert it and keep our optimisation. Fixes #8273
* vo_gpu: improve gamut warning bounds checksNiklas Haas2020-10-211-2/+2
| | | | | | | Test for signals exceeding 0.5% of the permitted gamut, in either direction. (Before, it was 1% above and 0% below) Should fix https://github.com/mpv-player/mpv/issues/8161
* vo_gpu: update render options on runtimeDudemanguy2020-10-151-0/+1
| | | | | | | | | | | | 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.
* vo_gpu: clip highlights before tone-mappingNiklas Haas2020-07-191-4/+5
| | | | | | | | | | | | Rather than after tone-mapping. This prevents overflow when the pre-tonemapped signal contains inputs exceeding sig_peak. I also realized that with this clipping in place, post-clipping no longer needs to be done, so this isn't even particularly slower. The only two exceptions to the rule are "clip" and "linear", which relied on the post-clipping to do their tone mapping properly. Fixes #7929
* client API: add software rendering APIwm42020-07-081-1/+1
| | | | | | | | | | | | | | | | | This can be used to make vo_libmpv render video to a memory buffer. It only adds a new backend API that takes memory surfaces. All the render API (such as frame rendering control and so on) is reused. I'm not quite convinced of the usefulness of this, and until now I always resisted providing something like this. It only seems to facilitate inefficient implementation. But whatever. Unfortunately, this duplicates the software rendering glue code yet again (like it exists in vo_x11, vo_wlshm, vo_drm, and probably more). But in theory, these could reuse this backend in the future, just like vo_gpu could reuse the render_gl API. Fixes: #7852
* vo_gpu: fix typo in struct namesfan52020-06-241-1/+1
|
* vo_gpu: use highp float if available for GLESStephen Salerno2020-06-211-0/+5
| | | | | | Using mediump float on GLES causes problems with kernel resampling, PQ HDR, and possibly others. The issues are fixed by using highp, which is available when GL_FRAGMENT_PRECISION_HIGH is defined.
* vo_gpu: add better gamut clipping optionNiklas Haas2020-06-193-0/+14
| | | | | | See https://code.videolan.org/videolan/libplacebo/-/commit/d63eeb1ecc204 Enabled by default because I think it looks better. YMMV.
* vo_gpu: fix scaler/window validation to allow unsettingNiklas Haas2020-06-181-0/+4
| | | | | | | | | | --dscale= and --*scale-window= (i.e. an empty string) are respectively valid settings for their options (and, in fact, the defaults). This fixes the bug that it was impossible to reset e.g. tscale-window back to the default "unset" setting after setting it once. Credit goes to @CounterPillow for locating the cause of this bug.
* vo_gpu: add BT.2390 tone-mappingNiklas Haas2020-06-153-7/+58
| | | | | | | | | | | | Implementation copy/pasted from: https://code.videolan.org/videolan/libplacebo/-/commit/f793fc0480f This brings mpv's tone mapping more in line with industry standard practices, for a hopefully more consistent result across the board. Note that we ignore the black point adjustment of the tone mapping entirely. In theory we could revisit this, if we ever make black point compensation part of the mpv rendering pipeline.
* vo_gpu: reinterpret SDR white levels based on ITU-R BT.2408Niklas Haas2020-06-151-2/+4
| | | | | | | | | | | | This standard says we should use a value of 203 nits instead of 100 for mapping between SDR and HDR. Code copied from https://code.videolan.org/videolan/libplacebo/-/commit/9d9164773 In particular, that commit also includes a test case to make sure the implementation doesn't break roundtrips. Relevant to #4248 and #7357.
* vo_gpu: move coherent specifier to the correct locationNiklas Haas2020-06-102-2/+2
| | | | | | | | | | glslang accepted this, perhaps erronneously, but mesa does not. It seems to be incorrect. A caveat is that this means *all* SSBOs are now coherent, but since we only use SSBOs for peak detection, that's a non-issue. (And besides, marking something as coherent when we don't perform any synchronization commands on it should be a no-op anyway) Fixes #7823
* vo_gpu: fix display corruption with window screenshotswm42020-06-061-0/+1
| | | | | | | | | The "screenshot window" command (ctrl+s by default) somehow broke video colors with --gpu-api=vulkan --profile=gpu-hq when playback was paused. I don't know the cause, but the rest of the code seems to imply gl_video_reset_surfaces() needs to be called manually to flush some caches, and it fixes the issue, so I assume there's no great mystery here.
* vo_gpu: mark peak detection buffer coherentNiklas Haas2020-06-061-1/+1
| | | | This is required for buffer memory barriers to actually work
* vo_gpu: make storage images/buffers as restrictNiklas Haas2020-06-061-2/+2
| | | | | This informs the GPU that we don't alias it with any other descriptors (which we don't).
* vo_gpu: un-fix storable fbo format checkNiklas Haas2020-05-131-2/+1
| | | | | | | | | The original solution for #7017 was sort of a hack, but this hack is no longer needed because c05e5d9d fixed the underlying issue causing this error to be spammed in the first place. So just remove the "fix" that apparently introduced about as many issueas it fixed. Fixes #7719, hopefully.
* vo_gpu: manually resolve user shader prefixeswm42020-05-101-1/+4
| | |