summaryrefslogtreecommitdiffstats
path: root/video/out/gpu
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | This resolves prefixes such as "~/" and "~~/" at the caller, instead of relying on stream_read_file() to do it. One of the following commits will remove this from stream_read_file() itself. Untested.
* vo_gpu: fix green shit with float yuv inputwm42020-05-093-12/+23
| | | | | | | | | | | | This was incorrect at least because the colorspace matrix attempted to center chroma at (conceptually) 0.5, instead of 0. Also, it tried to apply the fixed point shift logic for component sizes > 8 bit. There is no float yuv format in mpv/ffmpeg yet, but see next commit, which enables zimg to output it. I'm assuming zimg defines this format such that luma is in range [0,1] and chroma in range [-0.5,0.5], with the levels flag being ignored. This is consistent with H264/5 Annex E (I think...), and it sort of seems to look right, so that's it.
* vo_gpu: enable frame caching for still framesNiklas Haas2020-04-301-3/+3
| | | | | | | | | | For some reason this was never done? Looking through the code, it was never the case that the frame cache was hit for still frames. I have no idea why not. It makes a lot of sense to do so. Notably, this massively improves the performance of updating the OSC when viewing e.g. large still images, or while paused. (Tested on a 4000x8000 image, the OSC now responds smoothly to user input)
* video: add alpha type metadatawm42020-04-241-2/+4
| | | | | | | | | This is mostly for testing. It adds passing through the metadata through the video chain. The metadata can be manipulated with vf_format. Support for zimg alpha conversion (if built with zimg after it gained alpha support) is implemented. Support premultiplied input in vo_gpu. Some things still seem to be buggy.
* video: change chroma_w/chroma_h fields to use shift instead of sizewm42020-04-231-2/+2
| | | | | | | | | | When I added mp_regular_imgfmt, I made the chroma subsampling use the actual chroma division factor, instead of a shift (log2 of the actual value). I had some ideas about how this was (probably?) more intuitive and general. But nothing ever uses non-power of 2 subsampling (except jpeg in rare cases apparently, because the world is a bad place). Change the fields back to use shifts and rename them to avoid mistakes.
* options: change option macros and all option declarationswm42020-03-184-119/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* vo_gpu: warn if correct-downscaling is ignoredAvi Halachmi (:avih)2020-03-141-0/+11
| | | | And document that it's ignored with bilinear scaler.
* vo_gpu: generally allow non-storable FBOsNiklas Haas2020-03-082-3/+12
| | | | | | | | | | | | | We have this cap now thanks to e2976e662, but we don't actually make sure our FBOs are storable before we blindly attempt using them with compute shaders. There's no more need to unconditionally set `storage_dst = true` as long as we make sure to include an extra condition on the `fbo_format` selection to prevent users from accidentally enabling compute-shader-only features with non-storable FBOs, alongside some other miscellaneous adjustments to eliminate instances of "assumed storability" from vo_gpu.
* vo_gpu: avoid error spam when ra_fbo fmt is non-storableNiklas Haas2020-03-081-0/+2
| | | | | | | | | | | This simply makes the "is the destination FBO format bad?" check a tiny bit less awful, by making sure we prefer storable FBO formats over non-storable FBO formats. I'd love to make this also conditional on whether or not we actually *need* a storable FBO format, but that logic is decided later, in `pass_draw_to_screen`, and I don't want to replicate the logic. Fixes #7017.
* Remove remains of Libav compatibilitywm42020-02-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Libav seems rather dead: no release for 2 years, no new git commits in master for almost a year (with one exception ~6 months ago). From what I can tell, some developers resigned themselves to the horrifying idea to post patches to ffmpeg-devel instead, while the rest of the developers went on to greener pastures. Libav was a better project than FFmpeg. Unfortunately, FFmpeg won, because it managed to keep the name and website. Libav was pushed more and more into obscurity: while there was initially a big push for Libav, FFmpeg just remained "in place" and visible for most people. FFmpeg was slowly draining all manpower and energy from Libav. A big part of this was that FFmpeg stole code from Libav (regular merges of the entire Libav git tree), making it some sort of Frankenstein mirror of Libav, think decaying zombie with additional legs ("features") nailed to it. "Stealing" surely is the wrong word; I'm just aping the language that some of the FFmpeg members used to use. All that is in the past now, I'm probably the only person left who is annoyed by this, and with this commit I'm putting this decade long problem finally to an end. I just thought I'd express my annoyance about this fucking shitshow one last time. The most intrusive change in this commit is the resample filter, which originally used libavresample. Since the FFmpeg developer refused to enable libavresample by default for drama reasons, and the API was slightly different, so the filter used some big preprocessor mess to make it compatible to libswresample. All that falls away now. The simplification to the build system is also significant.
* vo_gpu: fix crash if dither texture fails to allocatewm42020-01-081-0/+3
| | | | | | | Theoretically possible (and quite unlikely due to the small texture size). The code was originally written with the assumption that texture allocations can't fail, and it was never updated out of laziness. Untested.
* Revert "vo_gpu: move wayland below X11 in autoprobe order"Dudemanguy2020-01-011-6/+6
| | | | This reverts commit a6d8e9b7ff0166ee6db69c41c0cfc319e03f4c80.
* vo_gpu: move wayland below X11 in autoprobe orderwm42019-12-301-6/+6
| | | | | | | I'm sick of mpv being accused of not doing it right. You can't do it right on Wayland? Long live X11. Fixes: #7307
* video: cuda: add explicit context creation for copy hwaccelsPhilip Langdale2019-12-291-1/+1
| | | | | | | | | | | | | | | | | | | | | In the distant past, the cuviddec backed copy hwaccel could be configured directly using lavc options. However, since that time, we gained support for automatic hw ctx creation which ended up bypassing the lavc options. Rather than trying to find a way to pass those options again, a better idea is to make the 'cuda-decode-device' option, used by the interop hwaccels, work for the copy hwaccels too. And that's pretty simple: we have to add a create function that checks the option and passes it on to ffmpeg. Note that this does require a slight re-jig to the configuration flags, as we now have a scenario where we want to build with support for the cuda copy hwaccels but not the interop ones. So we need a distinct configuration flag for that combination. Fixes #7295.
* vo_gpu: hwdec_vdpau: remove direct_modePhilip Langdale2019-12-282-46/+0
| | | | | | | | | | | | | | | | | | | | | | | | As we are less and less interested in vpdpau, with nvdec and vaapi being better choices in general on nvidia and AMD respectively, we might consider removing direct_mode, where we bypass the vdpau mixer and work directly with yuv textures. Normally, working with yuv textures would be great, but vdpau built in an assumption that all frames are delivered as separate fields, causing us to have to re-interleave them. nvidia then introduces a new OpenGL extension that can return the yuv frames as frames, but we can't just unconditionally switch to that as we'd want to keep supporting older hardware where the drivers are no longer getting new features. The end result is that we wouldn't be able to get rid of the old code paths. Removing direct_mode means we always use the mixer, and work with rgba frame textures. There are some theoretical limitations to this, but in practice they probably don't matter much - unsupported colourspaces don't matter because without 10bit decoding support, we can't use them anyway, and apparently we're not doing separate chroma scaling these days, so scaling the rbga doesn't really lose anything (and the vdpau hq scaling option remains available).
* vf_gpu: render subtitleswm42019-11-302-8/+13
| | | | | | | Pretty annoying affair. The vo_gpu code could of course not trigger rendering from filters yet, so it needed to be extended. Also, this uses some icky stuff made for vf_sub (and this was the reason I marked vf_sub as deprecated), so everything is terrible.
* vo_gpu: fix infinite scaler reinit spamNiklas Haas2019-11-231-8/+9
| | | | | | | | | Handling the window with this function makes no sense, since windows and kernels are not the same thing and don't share the same option list. The only reason it's done is to make sure the char* points at the static string rather than the dynamically allocated one, which we can do manually in this function. Rewrite a bit for clarity/quality.
* video/out/gpu: Remove stray top-level ';'Michael Forney2019-11-182-2/+2
|
* vo_gpu: sync duplicated condition on peak computationwm42019-11-161-0/+2
| | | | | | | | | | | | | | | | | | | | pass_color_map() (in video_shaders.c) and pass_colormanage() (video.c) both duplicate the condition on whether to do peak computation. Peak computation requires a compute shader, so if the duplicated conditions don't match, video_shaders.c will generate a compute shader, but video.c will try to run it as fragment shader. This leads to a "blue screen". This can be reproduced by playing a HDTV video with --target-peak=99. It's not clear how to fix this. Should pass_tone_map() be only invoked if mp_trc_is_hdr() == true (what pass_colormanage() uses to decide whether to enable peak computation), or should pass_colormanage() just tell pass_color_map() to skip peak computation? Decide for the latter, as it's more robust. Even if not correct, at least it gets rid of the blue shit. Fixes: #7149
* vo_gpu: yuv alpha is always full rangewm42019-11-091-8/+6
| | | | | | | | | | | | | | Probably. It's not like these pixel formats are formally specified - FFmpeg added them because _some_ file format or decoder supports it, and while that format/codec may define it precisely, the pixel format is sort of disconnected and just a FFmpeg thing. In any case, the yuva sample I had at hand uses the full range the component data type can provide. The old code used the same "shifted" range as for Y/U/V components, which must have been wrong. This will not work correctly for packed YUVA formats, but fortunately they matter even less.
* vo_gpu: unconditionally clear framebuffer on start of framewm42019-11-061-5/+3
| | | | | | | | | | | | | | | | | | | | | | For some reason, the first frame displayed on X11 with amdgpu and OpenGL will be garbled. This is especially visible if the player starts, displays a frame, but then still takes a while to properly start playback. With --interpolation, the behavior somehow changes (usually gets worse). I'm not sure what exactly is going on, and the code in video.c is way too abstruse. Maybe there is some slight possibility that a frame with uncleared contents gets displayed, which somehow also corrupts another frame that is displayed immediately after that. If clear is unconditionally run, this somehow doesn't happen, and you see a video frame. By any logic this shouldn't happen: a video frame should always overwrite the background. So I can't exclude that this isn't some sort of driver bug, or at least very obscure interaction. Clearing should be practically free anyway, so always do it. Fixes: #7105
* Replace uses of FFMIN/MAX with MPMIN/MAXwm42019-10-311-4/+2
| | | | And remove libavutil includes where possible.
* vo_gpu/d3d11: add support for configuring swap chain color spaceJan Ekström2019-10-302-5/+171
| | | | | | | | | | | | | | | | By default utilizes the color space of the desktop on which the swap chain is located. If a specific value is defined, it will be instead be utilized. Enables configuration of the PQ color space (BT.2020 primaries, PQ transfer function) for HDR. Additionally, signals the swap chain color space to the renderer, so that the render looks correct without having to specify target-trc or target-prim manually. Due to all of the APIs being Win10+ only, will only work starting with Windows 10.
* vo_gpu/d3d11: add helpers for getting names for DXGI formats & CSPsJan Ekström2019-10-302-4/+178
| | | | | Additionally, define the few enum values that are currently missing in mingw-w64 headers.
* vo_gpu: add and utilize color space information from ra_fboJan Ekström2019-10-302-8/+40
| | | | | | | | This lets us set primaries, transfer function and the target peak based on what the presenting layer would want us to have. Now that this mechanism is available, warn if the user has overridden values such as primaries or transfer function.
* vo_gpu: log ra_format.storable with the other flagsJames Ross-Gowan2019-10-271-3/+5
| | | | | | This seems to have been missed when the storable flag was added, since all the other flags were logged here. It can be useful to know if an RA format is storable, so log it as well.
* vo_gpu: attempt to fix 0bgr formatwm42019-10-261-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | Using e.g. --vf=format=0bgr showed obviously wrong colors with --vo=gpu. The reason is that leading padding wasn't handled correctly. Try to hack fix it. While the code in copy_image() is somewhat reasonable, I can't tell what the fuck is going on with that HOOKED shit. For some reason this HOOKED shit doesn't use copy_image() (???), or uses it incorrectly. It affects debanding. --deband=no works correctly. If it's enabled, the crap in hook_prelude() is needed. I bet there are many more bugs with this. For example, the deband shader will try to deband the alpha channel if the format abgr is used (because the correct component order is only established later). This can be tested by inserting a "color.x = 0;" at the end of the deband shader, and using --vf=format=rgba vs. abgr. I cannot comprehend why it doesn't just store explicitly which components a texture contains, and why it doesn't just read the components always in an uniform way. There's a big chance this fix works only by coincidence. This shouldn't have been so hard either. Time for a complete rewrite?
* vo_gpu, options: don't return NaN through APIwm42019-10-251-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | Internally, vo_gpu uses NaN for some options to indicate a default value that is different depending on the context (e.g. different scalers). There are 2 problems with this: 1. you couldn't reset the options to their defaults 2. NaN is a damn mess and shouldn't be part of the API The option parser already rejected NaN explicitly, which is why 1. didn't work. Regarding 2., JSON might be a good example, and actually caused a bug report. Fix this by mapping NaN to the special value "default". I think I'd prefer other mechanisms (maybe just having every scaler expose separate options?), but for now this will do. See you in a future commit, which painfully deprecates this and replaces it with something else. I refrained from using "no" (my favorite magic value for "unset" etc.) because then I'd have e.g. make --no-scale-param1 work, which in addition to a lot of effort looks dumb and nobody will use it. Here's also an apology for the shitty added test script. Fixes: #6691
* vo_gpu: hwdec_d3d11eglrgb: remove thiswm42019-10-161-2/+0
| | | | | Finally. Since with the previous commit we can (probably) handle P010 directly, this hack isn't needed anymore.
* vo_gpu/d3d11: fix memleak of the adapter description stringJan Ekström2019-10-151-1/+5
|
* vo_gpu/d3d11: remove unnecessary nullptr checkJan Ekström2019-10-151-2/+2
| | | | mp_to_utf8 will abort in case of either invalid input or OOM.
* vo_gpu/d3d11: switch adapter selection to case-insensitive startswithJan Ekström2019-10-151-3/+4
| | | | | | This lets users set values such as "intel" or "nvidia" as the adapter vendor is generally noted in the beginning of the description string.
* vo_gpu/d3d11: fixup adapter selection by switching it all to bstrJan Ekström2019-10-152-11/+7
| | | | | I did ponder if I should have done this right away, and it seems like not doing it at first was a mistake.
* vo_gpu/d3d11: add support for configuring swap chain formatJan Ekström2019-10-132-1/+120
| | | | | | | Query information on the system output most linked to the swap chain, and either utilize a user-configured format, or either 8bit RGBA or 10bit RGB with 2bit alpha depending on the system output's bit depth.
* vo_gpu/d3d11: add adapter name validation and listing with "help"Jan Ekström2019-09-292-5/+37
| | | | Not the prettiest way to get it done, but seems to work.
* vo_gpu/d3d11: refactor pthread_once d3d11 loading to functionJan Ekström2019-09-291-6/+15
| | | | Lets us reuse this in the future.
* vo_gpu/d3d11: utilize the passed adapter nameJan Ekström2019-09-291-5/+77
| | | | | | Normalize nullptr and an empty string both to nullptr to simplify handling. API users cannot set a value back to nullptr, so both an empty string as well as nullptr should behave the same.
* vo_gpu/d3d11: add an option for the adapter nameJan Ekström2019-09-291-0/+5
| | | | Set it from the adapter name in the d3d11 options.
* vo_gpu/d3d11_helpers: also load up CreateDXGIFactory1Jan Ekström2019-09-291-4/+13
| | | | Just a factory, without a device, is required for listing of devices.
* vo: make swapchain-depth option generic for all VOsAnton Kindestam2019-09-281-1/+0
| | | | In preparation for making vo_drm able to use swapchain-depth
* video: add pure gamma TRC curves for 2.0, 2.4 and 2.6.Wessel Dankers2019-09-272-0/+21
|
* options: add M_OPT_FILE to some more options that take filesPhilip Sequeira2019-09-271-2/+2
|
* vo_gpu: vulkan: add Android contextsfan52019-09-271-0/+4
|
* rpi: Update for modern systemsCameron Cawley2019-09-201-1/+1
|
* vo_gpu: remove vdpau/GLX backendwm42019-09-191-4/+0
| | | | | | | Useless garbage. This was once added to test whether vdpau presentation feedback could be used. Results were always unsatisfactory, and now vdpau is dead.
* vo_gpu: remove mali-fbdevwm42019-09-191-4/+0
| | | | | Useless at this point, I don't even know if it still works, or how to test it.
* drm: fix libmpv ABI breakage introduced in ↵Anton Kindestam2019-09-181-4/+4
| | | | | | | | | | | | | | | 351c083487050c88adb0e3d60f2174850f869018 Extending the client-allocated mpv_opengl_drm_params struct constituted a break of ABI that could cause UB. Create a clean break by deprecating "drm_params" and related structs and enum values, and replacing it with "drm_params_v2". Also fix some comments and code that wrongly assumed that open could return any other negative number than -1 for failure. This commit updates the libmpv version to 1.104
* vo_gpu: hwdec_vaapi: Refactor Vulkan and OpenGL interops for VAAPIPhilip Langdale2019-09-151-1/+1
| | | | | | Like hwdec_cuda, you get a big #ifdef mess if you try and keep the OpenGL and Vulkan interops in the same file. So, I've refactored them into separate files in a similar way.
* vo_gpu: x11: remove special vdpau probing, use EGL by defaultwm42019-09-151-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally, vo_gpu/vo_opengl considered the case of Nvidia proprietary drivers, which required vdpau/GLX, and Intel open source drivers, which require vaapi/EGL. Since window creation and GPU context creation are inseparable in mpv's internal API, it had to pick the correct API very early, or hardware decoding wouldn't work. "x11probe" was introduced for this reason. It created a GLX context (without showing the window yet), and checked whether vdpau was available. If yes, it used GLX, if not, it continued probing x11/EGL. (Obviously it couldn't always fail on GLX without vdpau, which is why it was a separate "probe" backend.) Years passed, and now the situation is different. Vdpau is dead. Nvidia drivers and libavcodec now provide CUDA interop, which requires EGL, and fixes some of the vdpau problems. AMD drivers now provide vaapi, which generally works better than vdpau. Intel didn't change. In particular, vaapi provides working HEVC Main10 support. In theory, it should work on vdpau too, with quality reduction (no 10 bit surfaces), but I couldn't get it to work. So always prefer EGL. And suddenly hardware decoding works. This is actually rather important, because HEVC is unfortunately on the rise, despite shitty encoders and unoptimized decoders. The latter may mean that hardware decoding works better than libavcodec. This should have been done a long, long time ago.
* vo_gpu: correctly normalize src.sig_peakNiklas Haas2019-09-151-1/+4
| | | | | | | | | | | | | In some cases, src.sig_peak remains undefined as 0, which was definitely the case when using the OSD, since it never got passed through the usual color space normalization process. Most robust work-around is to simply force the normalization at the site where it's needed. This ensures this value is always valid and defined, to make the peak-dependent logic in these two functions always work. Fixes 4b25ec3a9d Fixes #6917 Fixes #6918
* vo/gpu: fix check on src/dst peak mismatchNiklas Haas2019-09-051-1/+1
| | | | | | |