summaryrefslogtreecommitdiffstats
path: root/video/out/opengl
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: use textureGatherOffset for polar filtersNiklas Haas2017-07-055-44/+90
| | | | | | | | | | | | | | | | | | This is more efficient on my machine (nvidia), but only when applied to groups of exactly 4 texels. So we switch to the more efficient textureGather for groups of 4. Some notes: - textureGatherOffset seems to be faster than textureGather by a non-negligible amount, but for some reason, textureOffset is still slower than a straight-up texture - textureGather* requires GLSL 400; and at least on nvidia, this requires actually allocating a GL 4.0 context. - the code in opengl/common.c that clamped the GLSL version to 330 is deprecated, because the old user shader style has been removed completely in the meantime - To combat the growing complexity of the polar sampling code, we drop the antiringing functionality from EWA shaders completely, since it never really worked well for EWA to begin with. (Horrific artifacting)
* vo_opengl: make the pass info mechanism more robustNiklas Haas2017-07-031-17/+26
| | | | | | | | | | - change asserts to silent exits - check all pointers before use - move the p->pass initialization code to the right place This should hopefully cut down on the amount of crashing by making the code fundamentally more robust, while also fixing a concrete issue where opengl-cb failed to initialize p->pass.
* filter_kernels: add radius cutoff functionalityNiklas Haas2017-07-033-9/+18
| | | | | | | | This allows filter functions to be prematurely cut off once their contributions start becoming insignificant. This effectively prevents wasted GPU time sampling from parts of the function that are essentially reduced to zero by the window function, providing anywhere from a 10% to 20% speedup. (5700μs -> 4700μs for me)
* options: change everything againwm42017-07-022-7/+2
| | | | Fucking bullshit.
* vo_opengl: describe vdpau reinterleaving passNiklas Haas2017-07-011-0/+1
| | | | This shows up as (unknown pass) otherwise.
* vo_opengl: fix some more pass_info_reset issuesNiklas Haas2017-07-011-1/+10
| | | | | | | | | | | | 2f41c4e8 exposed some other edge cases as well. Globally resetting the pass info was not the right way to go about it, because we don't know in advance what the frame type is going to be - at least not with the current code structure. (In principle, we could separately indicate the frame type and the pass type and then only reset it on the first actual pass_describe call, but that's annoying as well) Also fixes a latent issue where p->pass was never initialized, which broke the MP_DBG debugging code in some cases.
* vo_opengl: call pass_info_reset earlierNiklas Haas2017-07-011-1/+1
| | | | | Omitting this call resulted in a crash when has_frame was false. But we can just call it way earlier, because there's really no reason not to.
* vo_opengl: merge uploading and renderingNiklas Haas2017-07-011-14/+14
| | | | | | Since all existing code does gl_video_upload immediately followed by pass_render_frame, we can just move the upload into pass_render_frame itself, which arguably makes more sense anyway.
* vo_opengl: refactor vo performance subsystemNiklas Haas2017-07-017-96/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This replaces `vo-performance` by `vo-passes`, bringing with it a number of changes and improvements: 1. mpv users can now introspect the vo_opengl passes, which is something that has been requested multiple times. 2. performance data is now measured per-pass, which helps both development and debugging. 3. since adding more passes is cheap, we can now report information for more passes (e.g. the blit pass, and the osd pass). Note: we also switch to nanosecond scale, to be able to measure these passes better. 4. `--user-shaders` authors can now describe their own passes, helping users both identify which user shaders are active at any given time as well as helping shader authors identify performance issues. 5. the timing data per pass is now exported as a full list of samples, so projects like Argon-/mpv-stats can immediately read out all of the samples and render a graph without having to manually poll this option constantly. Due to gl_timer's design being complicated (directly reading performance data would block, so we delay the actual read-back until the next _start command), it's vital not to conflate different passes that might be doing different things from one frame to another. To accomplish this, the actual timers are stored as part of the gl_shader_cache's sc_entry, which makes them unique for that exact shader. Starting and stopping the time measurement is easy to unify with the gl_sc architecture, because the existing API already relies on a "generate, render, reset" flow, so we can just put timer_start and timer_stop in sc_generate and sc_reset, respectively. The ugliest thing about this code is that due to the need to keep pass information relatively stable in between frames, we need to distinguish between "new" and "redrawn" frames, which bloats the code somewhat and also feels hacky and vo_opengl-specific. (But then again, this entire thing is vo_opengl-specific)
* d3d: UWP support for D3D11VAwm42017-06-301-9/+4
| | | | | | | For some braindead reason, Microsoft decided to prevent you from dynamically loading system libraries. This makes portability harder. And we're talking about portability between Microsoft OSes!
* d3d: make DXVA2 support optionalwm42017-06-302-4/+4
| | | | | | | | | | | | This partially reverts the change from a longer time ago to always build DXVA2 and D3D11VA together. To make it simpler, we change the following: - building with ANGLE headers is now required to build D3D hwaccels - if DXVA2 is enabled, D3D11VA is still forcibly built - the CLI vo_opengl ANGLE backend is now under --egl-angle-win32 This is done to reduce the dependency mess slightly.
* video: get rid of swapped packed YUVwm42017-06-301-6/+2
| | | | | | Another legacy annoyance. The only place where packed YUV is still important is slightly older Apple hardware or drivers, which require it for efficient hardware decoding.
* vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usagewm42017-06-303-35/+48
| | | | | These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
* vo_opengl: restructure format setupwm42017-06-307-131/+105
| | | | | | | | | | | | Instead of setting up a weird swizzle (which is linked to how the internal renderer code works, rather than the generic format code), add per-component mapping to gl_imgfmt_desc. The renderer still computes the weird swizzle, but at least it's confined to itself. Also, it appears the hwdec backends don't need this anymore. It's really nice that the messy init_format() goes away too.
* options: change path list options, and document list optionswm42017-06-302-1/+7
| | | | | | | | | | | | | | | | | | | | | | | The changes to path list options is basically getting rid of the need to pass multiple paths to a single option. Instead, you can use the option multiple times. The old behavior can be used by using the -set suffix with the option. Change some options to path lists. For example --script is now append by default, and if you use --script-set, you need to use ":"/";" as separator instead of ",". --sub-paths/--audio-file-paths is a deprecated alias now, and will break if the user tries to pass multiple paths to it. I'm assuming that if these are used, most users will pass only 1 path anyway. --opengl-shaders has more compatibility handling, since it's probably rather common that users pass multiple options to it. Also document all that in the manpage. I'll probably regret this later, as it somewhat increases the complexity of the option parser, rather than increasing it.
* vo_opengl: rely on FFmpeg pixdesc a bit morewm42017-06-291-80/+27
| | | | | | | | | | | | | Add something that allows is to extract the component order from various RGBA formats. In fact, also handle YUV, GBRP, and XYZ formats with this. It introduces a new struct mp_regular_imgfmt, that hopefully will eventually replace struct mp_imgfmt_desc. The latter is still needed by a lot of code though, especially generic code. Also vo_opengl still uses the old one, so this commit is sort of incomplete. Due to its genericness, it's also possible that this commit introduces rendering bugs, or accepts formats it shouldn't accept.
* vo_opengl: unify user_shaders constantsNiklas Haas2017-06-282-13/+10
| | | | | | | | | | | | | | | Commit 3fb6380 was supposed to increase MAX_TEXTURE_HOOKS but instead increased SHADER_MAX_HOOKS, since I forgot that they were separate (for whatever reason). To prevent this mistake from happening again, and to unify the location in which user_shader-specific #defines are placed, get rid of the two constants in opengl/video.c and move/reuse them from user_shaders.h instead. Also bump up MAX_SAVED_TEXTURES (now SHADER_MAX_SAVED) slightly as a precaution against adding more passes to vo_opengl. I think we're already flirting with the limit.
* vo_opengl: tone map using only luminance informationNiklas Haas2017-06-271-33/+24
| | | | | | | | | | | | | | | | | | | This is even better at preventing discoloration than tone mapping on the XYZ image. Partly inspired by the HLG OOTF. Also simplifies the way we tone map, and moves this logic to the pass_tone_map function where it belongs. This also fixes what could arguably be considered a bug in the HLG implementation when using HLG for non-BT.2020 colorspaces, which is not permitted by spec but thinkable in theory. Although in this case, I guess it will be arbitrary whether people use the BT.2020-normalized luma coefficients or change it to fit the colorspace, so I guess either way could be considered "right", depending on what people end up doing. Either way, in lieue of standard practice, we do what makes the most sense (to me), and hopefully others will follow. The downside is that we upload an extra vec3 uniform even if we don't use it, but eliminating that would be ugly.
* vo_opengl: silence -Wmaybe-uninitialized false positiveNiklas Haas2017-06-241-3/+3
| | | | | | | | | These can never be uninitialized because the enum cases are exhaustive and the fallback is in the correct order, but GCC is too dumb to understand this. Also explicitly initialize tex_type, because while GCC doesn't warn about it (for some reason), maybe it will in the future.
* vo_opengl: bump up SHADER_MAX_HOOKSNiklas Haas2017-06-241-1/+1
| | | | | Apparently people are running into the current limit. 64 ought to be enough for everybody.
* context_dxinterop: lock rendertarget after present when swapping buffersquilloss2017-06-181-7/+6
| | | | | | | | Moves the DXLockObjectsNV call to after PresentEx. This fixes an issue where the presented image is a single frame late. This may be due to DXLockObjectsNV locking the render target before StretchRect is done. The spec indicates that the lock call should provide synchronization for the resource, so this may be due to a driver bug.
* vo_opengl: implement sony s-log2 trcNiklas Haas2017-06-181-1/+18
| | | | | | | | Apparently this is virtually identical to Panasonic's V-Log, but using the constants from S-Log1 and an extra scaling coefficient to make the S-Log1 curve less limited. Whatever floats their NIH boat, I guess. Source: https://pro.sony.com/bbsccms/assets/files/micro/dmpc/training/S-Log2_Technical_PaperV1_0.pdf
* vo_opengl: implement sony s-log1 trcNiklas Haas2017-06-181-0/+14
| | | | | | | | Source: https://pro.sony.com/bbsccms/assets/files/mkt/cinema/solutions/slog_manual.pdf Not 100% confident in the implementation since the values from the spec seem to be very subtly off (~1%), but it should be close enough for practical purposes.
* vo_opengl: tone map in linear XYZ instead of RGBNiklas Haas2017-06-181-1/+19
| | | | | | | | | | | | | This preserves channel balance better and helps reduce discoloration due to nonlinear tone mapping. I wasn't sure whether to stuff this inside pass_color_manage or pass_tone_map but decided for the former because adding the extra mp_csp_prim would have made the signature of the latter longer than 80col, and also because the `mp_get_cms_matrix` below it basically does the same thing anyway, so it doesn't look that out of place. Also why is this justification longer than the actual description of the algorithm and what it's good for?
* vo_opengl: implement support for OOTFs and non-display referred contentNiklas Haas2017-06-183-8/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces (yet another..) mp_colorspace members, an enum `light` (for lack of a better name) which basically tells us whether we're dealing with scene-referred or display-referred light, but also a bit more metadata (in which way is the scene-referred light expected to be mapped to the display?). The addition of this parameter accomplishes two goals: 1. Allows us to actually support HLG more-or-less correctly[1] 2. Allows people playing back direct “camera” content (e.g. v-log or s-log2) to treat it as scene-referred instead of display-referred [1] Even better would be to use the display-referred OOTF instead of the idealized OOTF, but this would require either native HLG support in LittleCMS (unlikely) or more communication between lcms.c and video_shaders.c than I'm remotely comfortable with That being said, in principle we could switch our usage of the BT.1886 EOTF to the BT.709 OETF instead and treat BT.709 content as being scene-referred under application of the 709+1886 OOTF; which moves that particular conversion from the 3dlut to the shader code; but also allows a) users like UliZappe to turn it off and b) supporting the full HLG OOTF in the same framework. But I think I prefer things as they are right now.
* csputils: rename HDR curvesNiklas Haas2017-06-182-26/+22
| | | | | | | | | | st2084 and std-b67 are really weird names for PQ and HLG, which is what everybody else (including e.g. the ITU-R) calls them. Follow their example. I decided against naming them bt2020-pq and bt2020-hlg because it's not necessary in this case. The standard name is only used for the other colorspaces etc. because those literally have no other names.
* video: refactor HDR implementationNiklas Haas2017-06-183-73/+54
| | | | | | | | | | | | | | | List of changes: 1. Kill nom_peak, since it's a pointless non-field that stores nothing of value and is _always_ derived from ref_white anyway. 2. Kill ref_white/--target-brightness, because the only case it really existed for (PQ) actually doesn't need to be this general: According to ITU-R BT.2100, PQ *always* assumes a reference monitor with a white point of 100 cd/m². 3. Improve documentation and comments surrounding this stuff. 4. Clean up some of the code in general. Move stuff where it belongs.
* Drop/move img_fourcc.hwm42017-06-181-5/+5
| | | | | | | | | | | | | | | This file is an leftover from when img_format.h was changed from using the ancient FourCCs (based on Microsoft multimedia conventions) for pixel formats to a simple enum. The remaining cases still inherently used FourCCs for whatever reasons. Instead of worrying about residual copyrights in this file, just move it into code we don't want to relicense (the ancient Linux TV code). We have to fix some other code depending on it. For the most part, we just replace the MP_FOURCC macro with libavutil's MKTAG (although the macro definition is exactly the same). In demux_raw, we drop some pre-defined FourCCs, but it's not like it matters. (Instead of --demuxer-rawvideo-format use --demuxer-rawvideo-mp-format.)
* vo_opengl: fall back to ordered dither instead of blowing upwm42017-06-171-4/+9
| | | | | | | | | | | | | In GLES 2 mode, we can do dither, but "fruit" dithering is still out of the question, because it does not support any high depth textures. (Actually we probably could use an 8 bit texture too for this, at least with small matrix sizes, but it's still too much of a pain to convert the data, so why bother.) This is actually a regression; before this, forcibly enabling dumb mode due to low GL caps actually happened to avoid this case. Fixes #4519.
* vo_opengl: change default tone mapping algorithmNiklas Haas2017-06-101-1/+1
| | | | | d8a3b10f4 was supposed to change this (as reflected in the man page and commit message), I just forgot.
* vo_opengl: add new HDR tone mapping algorithmNiklas Haas2017-06-093-0/+17
| | | | | | | | | | | | | | | | | I call it `mobius` because apparently the form f(x) = (cx+a)/(dx+b) is called a Möbius transform, which is the algorithm this is based on. In the extremes it becomes `reinhard` (param=0.0 and `clip` (param=1.0), smoothly transitioning between the two depending on the parameter. This is a useful tone mapping algorithm since the tunable mobius transform allows the user to decide the trade-off between color accuracy and detail preservation on a continuous scale. The default of 0.3 is already far more accurate than `reinhard` while also being reasonably good at preserving highlights, without suffering from the overall brightness drop and color distortion of `hable`. For these reasons, make this the new default. Also expand and improve the documentation for these tone mapping functions.
* d3d: add support for new libavcodec hwaccel APIwm42017-06-084-0/+5
| | | | | | Unfortunately quite a mess, in particular due to the need to have some compatibility with the old API. (The old API will be supported only in short term.)
* vo_opengl: hwdec_cuda: Support separate decode and display devicesPhilip Langdale2017-06-032-12/+47
| | | | | | | | | | | | | | | | | In a multi GPU scenario, it may be desirable to use different GPUs for decode and display responsibilities. For example, if a secondary GPU has better video decoding capabilities. In such a scenario, we need to initialise a separate context for each GPU, and use the display context in hwdec_cuda, while passing the decode context to avcodec. Once that's done, the actually hand-off between the two GPUs is transparent to us (It happens during the cuMemcpy2D operation which copies the decoded frame from a cuda buffer to the OpenGL texture). In the end, the bulk of the work is around introducing a new configuration option to specify the decode device.
* videotoolbox: support new libavcodec APIwm42017-05-242-0/+24
| | | | | | | | | | | The new API has literally no advantages (other than that we can drop mp_vt_download_image and other things later), but it's sort-of uniform with the other hwaccels. "--videotoolbox-format=no" is not supported with the new API, because it doesn't "fit in". Probably could be added later again. The iOS code change is untested (no way to test).
* context_angle: fix fallback to D3D9 deviceJames Ross-Gowan2017-05-161-30/+56
| | | | | | | | | This was broken in e0250b9604b2. In some cases, device creation will succeed, but creating an EGL context on the device will fail. With --angle-renderer=auto, it should try to create the context again on a D3D9 device. This fixes mpv in Windows Vista on VirtualBox for me.
* vo_opengl: drop TLS usagewm42017-05-116-38/+32
| | | | | | | | | | | TLS is a headache. We should avoid it if we can. The involved mechanism is unfortunately entangled with the unfortunate libmpv API for returning pointers to host API objects. This has to be kept until we change the API somehow. Practically untested out of pure laziness. I'm sure I'll get a bunch of reports if it's broken.
* d3d11: change mp_image plane pointer semanticswm42017-05-042-3/+3
| | | | | | | | Until now, the texture pointer was stored in plane 1, and the texture array index was in plane 2. Move this down to plane 0 and plane 1. This is to align it to the new WIP D3D11 decoding API in Libav, where we decided that there is no reason to avoid setting plane 0, and that it would be less weird to start at plane 0.
* vo_opengl: another attempt at removing the overlay correctlywm42017-05-021-4/+12
| | | | | | | | This reverts commit 142b2f23d4293, and replaces it with another try. The previous attempt removed the overlay on every rendering, because the normal rendering path actually unrefs the mp_image. Consequently, unmap_current_image() was completely inappropriate for removing the overlay.
* vo_opengl: make sure overlays are removed on gl_video_config()wm42017-04-291-1/+4
| | | | | This should make vo_opengl_cb uninit remove the frame, even if the renderer and OpenGL state remains active.
* vo_opengl: context_drm_egl: remove unnecessary includewm42017-04-261-1/+0
| | | | | Could be broken after the previous commit removed finding the GL include dir.
* video: drop vaapi/vdpau hw decoding support with FFmpeg 3.2wm42017-04-231-47/+34
| | | | | | | | | | This drops support for the old libavcodec APIs. Now FFmpeg 3.3 or FFmpeg git is required. Libav has no release with the new APIs yet, so for Libav git as of a few weeks or months ago or so is required if you want to use Libav. Not much actually changes in hwdec_vaegl.c - some code is removed, but the reindentation inflates the diff.
* vo_opengl: fix crash by coping temporal_dither_period for dumb mode toowm42017-04-211-0/+1
| | | | | Specifically, this field must never be 0 (and the option can naturally not be 0 in any way, unless it wasn't initialized correctly).
* vo_opengl: move X11 backends before Waylandwm42017-04-161-3/+3
| | | | | | | | Wayland is still too amateurish, and multiple features don't work, including critical ones. There is no solution in sight, so prefer X11. (Which seems to mostly work ok via xwayland.) Once all problems are solved, the defaults can be switched back.
* vo_opengl: minor cosmeticswm42017-04-143-11/+13
|
* vo_opengl: add option for caching shaders on diskwm42017-04-086-12/+142
| | | | | | | | | | | | | Mostly because of ANGLE (sadly). The implementation became unpleasantly big, but at least it's relatively self-contained. I'm not sure to what degree shaders from different drivers are compatible as in whether a driver would randomly misbehave if it's fed a binary created by another driver. The useless binayFormat parameter won't help it, as they can probably easily clash. As usual, OpenGL is pretty shit here.
* vo_opengl: fix a confused commentwm42017-04-081-1/+1
|
* vo_opengl: remove two unused symbolswm42017-04-082-2/+0
|
* vo_opengl: add our own copy of OpenGL headerswm42017-04-077-170/+781
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gl_headers.h is basically header_fixes.h done consequently. It contains all OpenGL defines (and some typedefs) we need. We don't include GL headers provided by the system anymore. Some care has to be taken by certain windowing APIs including all of gl.h anyway. Then the definitions could clash. Fortunately, redefining preprocessor symbols to the same content is allowed and ignored. Also, redefining typedefs to the same thing is allowed in C11. Apparently the latter is not allowed in C99, so there is an imperfect attempt to avoid the typedefs if required API symbols are apparently present already. The nost risky part about this are the standard typedefs and GLAPIENTRY. The latter is different only on win32 (and at least consistently so). The typedefs are mostly based on stdint.h typedefs, which khrplatform.h clumsily emulates on platforms which don't have it. The biggest difference is that we define GLsizeiptr directly to ptrdiff_t, instead of checking for the _WIN64 symbol and defining it to long or long long. This also typedefs GLsync to __GLsync, just like the khronos headers. Although symbols prefixed with __ are implementation reserved, khronos also violates this rule, and having the same definition as khronos will avoid problems on duplicate definitions. We can simplify the build scripts too. The ios-gl check seems a bit wrong now (what we really want to test for is EAGLContext), but I can't test and thus can't improve it. cuda_dynamic.h redefined two GL symbols; just include the new headers directly instead.
*