summaryrefslogtreecommitdiffstats
path: root/video/out/gpu
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu: support video-target-paramsnanahi2024-03-272-0/+22
|
* video/out/gpu/spirv: fix warning: zero size arrays are an extensionnanahi2024-03-191-0/+1
|
* d3d11: add mp_get_dxgi_output_descKacper Michajłow2024-03-172-22/+25
|
* vo_gpu: fix broken chroma plane for rotated semi-planar formatsnanahi2024-03-111-0/+19
| | | | | | | | | | | | | | | | | For image formats with 2 or more chroma planes such as YU12, there is a plane merging pass for these planes calling finish_pass_tex which does a format conversion. After this conversion, the cscale shader afterwards works properly. However, for image formats with only 1 chroma plane (semi-planar formats), including NV12 and P010, this merging pass is never called, which breaks the cscale shader afterwards if the video is rotated with subsampled chroma. Fix this by adding an explicit conversion pass if this situation is detected after the pre-scale hooks, so if there are shaders hooking on CHROMA (like the deband filter) and the conversion is done by pass_hook already, this conversion won't be called.
* mp_image: add mp_image_params_static_equal for finer comparisionKacper Michajłow2024-03-091-2/+2
| | | | In case of dynamic HDR metadata is present.
* vo_gpu: add missing PL_COLOR_TRC_ST428 case in lcmsKacper Michajłow2024-03-011-0/+5
|
* various: avoid function pointer castsKacper Michajłow2024-02-285-23/+9
| | | | | | | | | | | | | The opt validator functions are casted to generic validator, which has erased type for value. Calling function by pointer of different definition is an UB. Avoid that by generating wrapper function that does proper argument type conversion and calls validator function. Type erased functions have mangled type in the name. Fixes UBSAN failures on Clang 17, which enabled fsanitize=function by default.
* vo_gpu: pre-multiply alpha when dealing with background colorsDudemanguy2024-02-261-0/+4
| | | | This was simply wrong for who knows how long.
* vo_gpu/vo_gpu_next: rework --alpha into --background optionDudemanguy2024-02-262-22/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* player: rename --background to --background-colorDudemanguy2024-02-262-6/+6
| | | | | This better represents what it actually does. --background will be used for another, related option in the next commit.
* vo_gpu: use fbo texture height for fragment coordinate calculationnanahi2024-02-241-2/+2
| | | | | | | Previous fix only worked when the video output doesn't have vertical black bars. This fixes the cases like fullscreen, video-zoom etc. Fixes: https://github.com/mpv-player/mpv/pull/13528
* vo_gpu: fix fragment coordinate calculation when ditheringnanahi2024-02-221-3/+5
| | | | | | | | | | | | When doing the dithering pass, the fragment coordinate is queried, but doesn't take the fbo texture flipped property into account. This results in different dithering patterns when toggling between fbo flipped and non-flipped state. This can be reproduced with --vo=gpu --gpu-api=opengl and easily seen with --dither-depth=1 when toggling between playing and pausing. Fix this by flipping the fragment y coordinate if the fbo is flipped when calculating dithering coordinate.
* vo_gpu: fix fragment coordinate calculation when drawing checkerboardnanahi2024-02-221-1/+3
| | | | | | | | | | | | | | When redrawing cached frames while the fbo texture is flipped, the texture after drawing to screen pass will be flipped when blitting. However, when rendering the checkerboard, the fragment coordinate doesn't take this into account, so the coordinate before flipping is used, resulting in different checkerboard location when toggling between flipped and non-flipped state. This can be reproduced with --vo=gpu and --gpu-api=opengl: the checkerboard patterns when playing and pausing are different (vertically flipped). Fix this by flipping the fragment y coordinate if the fbo is flipped when calculating checkerboard coordinate.
* various: make mentions of macOS consistentder richter2024-02-211-2/+2
| | | | | change all mentions and variations of OSX, OS X, MacOSX, MacOS X, etc consistent. use the official naming macOS.
* various: replace dead links in commentsnanahi2024-02-112-2/+3
| | | | | Replace various dead links with live replacements or archives. Less friction for anyone who wants to look up these references.
* player: remove all rpi-specific codeDudemanguy2024-02-052-8/+0
| | | | | | | | | | | | | | | | | | | | | | vo_rpi and its related code has pretty much historically been a disaster in mpv. The build regularly gets broken and since nobody uses it, it takes months for anyone to notice. There was also that time where fullscreen was broken for about a year and a half. Also building in waf was entirely broken for about a couple of years or so due to mysterious reasons no one ever figured out (meson magically fixed it). Anyways, once again the build is broken due to rpi being forgotten about again, but instead of pretending to support this crap. Just drop it all. Nowadays, mmal hwdec is a relic since these devices are better off using the v4l2m2m ffmpeg fork instead which actually uses KMS properly. RPI 1 and 2 probably can't do this and will remain broken but oh well blame Broadcom for being special snowflakes and not using standard APIs (my rockpro worked out of the box; just saying). RPI 2 is nearly 10 years old anyways, so I think you can afford a new SBC by now. If we were nicer, there would be a deprecation period, but this is broken in the last major release anyway so too late. Closes #13402.
* player: ensure runtime updates of certain rendering optionsDudemanguy2024-02-051-0/+1
| | | | | | | | | | When adding things like brightness or gamma, the video obviously needs a redraw if paused. This happened to work in the normal case because the OSD notification triggered a redraw, but if you use no-osd the picture won't change. Fix this by adding another option flag, UPDATE_VIDEO, and simply signalling we want a redraw. This gets handled along with the normal osd redrawing check in the playloop so something like "no-osd add gamma 1" actually works.
* csputils: replace more primitives with pl_Kacper Michajłow2024-01-223-32/+33
| | | | | We can go deeper, but need to stop somewhere to not reimplement vo_gpu using libplacebo...
* csputils: replace mp_chroma_location with pl_chroma_locationKacper Michajłow2024-01-221-5/+5
|
* csputils: replace mp_alpha_type with pl_alpha_modeKacper Michajłow2024-01-221-1/+1
|
* csputils: replace mp_colorspace with pl_color_spaceKacper Michajłow2024-01-229-167/+160
|
* command: export current-gpu-context propertynanahi2024-01-201-0/+1
| | | | | | | This exports `current-gpu-context` property, which is the string description of the current active GPU context. This allows scripts to uniquely identify the platform and backend used for --vo=gpu and --vo=gpu-next.
* vo_gpu: fix ra_fbo stack-use-after-scopeDudemanguy2023-11-281-9/+6
| | | | | | | | 281b1d89994e3e3a9950d32fc451dff990c2320d introduced a stack use after scope because dest_fbo can be reassigned a new pointer and then be used by pass_draw_to_screen outside of that scope where the pointer is no longer valid. Fix this by rearranging the variables so the assignment is done in the same scope as the pass_draw_to_screen call instead.
* vo_gpu: don't pass gl_user_shader_hook by valueKacper Michajłow2023-11-283-12/+10
|
* vo_gpu: don't pass mp_pass_perf by valueKacper Michajłow2023-11-281-8/+14
|
* vo_gpu: don't pass ra_fbo by valueKacper Michajłow2023-11-287-36/+36
| | | | Make it easier on compiler, no need to alloca and copy things around.
* d3d11: expose mp_get_dxgi_adapter and mp_dxgi_validate_adapterKacper Michajłow2023-11-222-5/+44
| | | | To be able to reuse them in other parts of code.
* d3d11: rename d3d11 adapter to DXGI adapterKacper Michajłow2023-11-222-11/+11
| | | | There is nothing d3d11 about those adapters.
* various: add some missing error checksKacper Michajłow2023-11-181-2/+3
|
* hwdec: support videotoolbox with libplaceborcombs2023-11-161-1/+1
|
* cocoa: remove OpenGL cocoa backendder richter2023-11-101-4/+0
| | | | | | the OpenGL cocoa backend was deprecated in 0.29, it has lot of bugs, is completely unmaintained and can't properly playback anything anymore on the newest macOS. it is time to remove it.
* vo_gpu_next: add --target-gamut optionNiklas Haas2023-11-082-0/+2
| | | | Fixes: https://github.com/mpv-player/mpv/issues/12777
* vo_gpu: apply ICC profile and dithering only to window screenshotssfan52023-11-072-10/+14
|
* ALL: use pl_hdr_metadata and nuke sig_peakKacper Michajłow2023-11-052-16/+18
| | | | | | | | This commit replaces all uses of sig_peak and maps all HDR metadata. Form notable changes mixed usage of maxCLL and max_luma is resolved and not always max_luma is used which makes vo_gpu and vo_gpu_next behave the same way.
* ALL: use new mp_thread abstractionKacper Michajłow2023-11-051-3/+3
|
* meson: make libplacebo a required dependencyllyyr2023-10-231-1/+1
| | | | | | | Make it not possible to build mpv without the latest libplacebo anymore. This will allow for less code duplication between mpv and libplacebo, and in the future also let us delete legacy ifdefs and track libplacebo better.
* vo_gpu/vo_gpu_next: add vulkan support for macOSder richter2023-10-141-0/+4
| | | | | | | | add support for vulkan through metal and a translation layer like MoltenVK. also add the possibility to use different render timing modes for testing. i still consider this experimental atm.
* vo: change vo->driver->wait_events to nanosecondsDudemanguy2023-10-101-1/+1
| | | | | | | | | | | | 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_gpu: remove --scaler-lut-sizeNiklas Haas2023-09-253-13/+9
| | | | | | | Pointless bloat option, hard-coded as 256 now in libplacebo and no reason not to also hard-code in mpv. See-Also: haasn/libplacebo@64d7c5aab06766a9492d3cfffd35333792052cd9
* vo_gpu: remove --scale-cutoff etcNiklas Haas2023-09-252-10/+4
| | | | | | | Pointless bloat option, hard-coded as 1e-3 now in libplacebo and no reason not to also hard-code in mpv. See-Also: haasn/libplacebo@64d7c5aab06766a9492d3cfffd35333792052cd9
* video/out/gpu: replace mp_read_option_raw callDudemanguy2023-09-221-3/+3
|
* vo_gpu: don't override scaler options with default onesKacper Michajłow2023-09-211-2/+10
| | | | | | | There was assumption in the code that default settings are compatible with dumb mode and are only one that should be used in this case. Force bilinear if dumb mode is enabled.
* vo_gpu: allow deband-iterations to be 0llyyr2023-09-211-1/+1
| | | | | THis allows adding grain without debanding. libplacebo already supported this, so no changes are required there.
* options: remove ancient option fallbacks/deprecationDudemanguy2023-09-212-15/+0
| | | | | | | | | | | | | We've got an ungodly amount of OPT_REPLACED and OPT_REMOVED sitting around in the code. This is harmless, but the vast majority of these are ancient. 26f4f18c0629998a9b91e94722d166866d8b80a3 is the last commit that touched the majority of these and of course that only changed how options were declared so all of this stuff was deprecated even before that. No use in keeping these, so just delete them all. As an aside, there was actually a cocoa_opts but it had only a single option which was replaced by something else and empty otherwise. So that entire thing was just simply removed. OPT_REPLACED/OPT_REMOVED declarations that were added in 0.35 or later were kept as is.
* vo_gpu: match libplacebo debanding defaultsNiklas Haas2023-09-201-2/+2
| | | | | | | | | The defaults were awful and horribly regressed many files while also not fixing banding on files that actually needed it, sometimes even *increasing* banding due to the low threshold. Fixes: 12ffce0f224056f91a20c9f0b197f4973931efbe See-Also: haasn/libplacebo@e1e43376d16d5112ee1254534664b0b85110139b
* vo_gpu: match libplacebo peak detection defaultsNiklas Haas2023-09-201-3/+3
| | | | | | | | | This probably makes `vo_gpu` tone mapping worse, or something, but who cares. The status quo for a while now has been to use `vo_gpu_next` if you care about HDR rendering at all. See-Also: haasn/libplacebo@ec60dd156b82753a2e2d8a399899244605f4d1bf See-Also: haasn/libplacebo@0903cbd05d7fc0391cbd99954924a39b855c8a1b
* vo_gpu: default to dscale=hermiteNiklas Haas2023-09-201-1/+1
| | | | | | | | | | This new filter is slightly sharper, and significantly faster, than mitchell. It also tends to preserve detail better. All in all, there is no reason not to use it by default, especially from a performance PoV. (In vo_gpu_next, hermite is implemented efficiently using hardware accelerated bilinear interpolation) See-Also: https://code.videolan.org/videolan/libplacebo/-/commit/75b3947b2c07803456483ec6976c037bad91b5dd
* builtin.conf: modernize internal profilesKacper Michajłow2023-09-191-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal is to provide simple to understand quality/performance level profiles for the users. Instead of default and gpu-hq profile. There main profiles were added: - fast: can run on any hardware - default: balanced profile between quality and performance - high-quality: out of the box high quality experience. Intended mostly for dGPU. Summary of three profiles, including default one: [fast] scale=bilinear cscale=bilinear (implicit) dscale=bilinear dither=no correct-downscaling=no linear-downscaling=no sigmoid-upscaling=no hdr-compute-peak=no [default] (implicit mpv defaults) scale=lanczos cscale=lanczos dscale=mitchell dither-depth=auto correct-downscaling=yes linear-downscaling=yes sigmoid-upscaling=yes hdr-compute-peak=yes [high-quality] (inherits default options) scale=ewa_lanczossharp cscale=ewa_lanczossharp (implicit) hdr-peak-percentile=99.995 hdr-contrast-recovery=0.30 allow-delayed-peak-detect=no deband=yes scaler-lut-size=8
* vo: change tscale to oversample by defaultKacper Michajłow2023-09-191-2/+1
| | | | Keep it sharp, let users opt-in more blurry result.
* vo: make cscale follow scale by defaultKacper Michajłow2023-09-191-1/+16
|
* vo: enable correct-downscaling, linear-downscaling, sigmoid-upscalingKacper Michajłow2023-09-191-0/+3
|
* vo_gpu: remove --scale-wblur etcNiklas Haas2023-09-161-1/+1
| | | | | | | | | | No need for this since it's entirely redundant with just changing the filter radius directly. In fact, that's the whole *point* of the filter radius - it does not modify the filter, it modifies the scaling of the window. Of course, this does not work for non-resizable kernels. But, really, who cares?
* filter_kernels: properly sharpen/blur filter radiusNiklas Haas2023-09-161-1/+1
| | | | | | | | | | | | | We currently always scaled the window to the size of the configured radius. However, this is wrong - we should instead be scaling it to the size of the sharpened/blurred kernel. Since the window is always stretched to the configured size of the filter, we can accomplish this easily by just multiplying the blur value into the filter radius directly, and then using that adjusted radius in place of `f.radius` everywhere. On a side note, this gives a very minor performance boost to ewa_lanczossharp for no downside.
* vo_gpu: slight bump to hard-coded option size limitsNiklas Haas2023-09-161-3/+3
| | | | ewa_lanczos4sharpest, for example, overflows this buffer.
* vo_gpu: vo_gpu_next: support --icc-3dlut-size=autoNiklas Haas2023-09-152-1/+11
| | | | | | | | | | | | And make it the default. In libplacebo, this uses internal heuristics to pick a good size based on the actual ICC characteristics. This is significantly less wasteful than always generating a 64x64x64 3DLUT (the old status quo). In vo_gpu, for simplicity, just default to 65x65x65. Note that this provides slightly better accuracy than the old default of 64x64x64 for technical reasons, and matches what libplacebo defaults to for typical display profiles.
* vo_gpu: support crop in gl_video_screenshotKacper Michajłow2023-09-091-3/+13
|
* vo_gpu: remove --tone-mapping-modeNiklas Haas2023-09-013-46/+7
| | | | | | | | | `--vo=gpu-next` no longer uses this option, being replaced entirely by a luminance-based approach internally. And even for `--vo=gpu`, the values other than 'hybrid' are universally inferior in quality. In the interest of gradually reducing the amount of option bloat here, remove this mostly-pointless option.
* vo_gpu: allow --hdr-peak-decay-rate=0.0Niklas Haas2023-08-182-4/+7
| | | | | | | | | | | | | | This completely disables all smoothing. Despite what the manual claims, a decay rate of 1.0 does *not*. It's worth pointing out that this depends on the following commit to work properly in --vo=gpu-next, but I don't think working around such a minor detail is worth the trouble, considering people building nightly mpv are probably also building nightly libplacebo it should just work (tm). See-Also: https://github.com/haasn/libplacebo/commit/1c464baaf4c6228dcfac87f19db1dafc22e328c8 See-Also: https://github.com/haasn/libplacebo/commit/83af2d4ebd5086a56f7b1a2f86628ada3612ee7c
* vo_gpu/vo_gpu_next: fix setting an empty dscaleDudemanguy2023-08-051-0/+6
| | | | | | | | | The manual currently says that if dscale is unset, --scale will be applied. However, this only works at init time. If you change the dscale filter to be empty later, vo_gpu will segfault and vo_gpu_next will throw an error and refuse the changes. That's because when the option is unset at runtime, the value becomes "" not NULL and the vo's never accounted for this. Fixes #12031.
* vo_gpu_next: add --hdr-peak-percentileNiklas Haas2023-08-042-0/+3
|
* build: internally rename gl-wayland to egl-waylandDudemanguy2023-07-231-1/+1
| | | | | | This has always been a pet peeve of mine and in fact I named the option in meson "egl-wayland" with the intention of finally doing this. We call everything that's egl "egl-foo" internally except for wayland.
* vo_gpu_next: add --hdr-contrast-recovery/smoothnessNiklas Haas2023-07-182-0/+7
| | | | New upstream feature. Disabled by default.
* vo_gpu_next: add --target-contrast optionKacper Michajłow2023-07-172-0/+3
| | | | For better control over target display levels.
* various: correctly ignore cache files with --no-configDudemanguy2023-07-061-6/+7
| | | | | | | | | | | | --no-config should prevent loading user files of any type: configs, cache, etc. For cache files, this case wasn't properly handled and it was assumed they would always get something. vo_gpu's shader cache actually already handles this, so it was left untouched. In theory, demuxer cache should never have this issue because saving it to disk is disabled by default (and likely that will never change), but go ahead and change it for consistency's sake. Fixes some segfaults with --no-config and various combinations of settings (particularly --vo=gpu-next).
* vo_gpu/vo_gpu_next: enabl