summaryrefslogtreecommitdiffstats
path: root/video/out/opengl/video.c
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: cut down on FBOTEX_FUZZY abuseNiklas Haas2017-07-241-4/+2
| | | | | | | | Don't use FBOTEX_FUZZY where the FBO is sized according to p->texture_w/h, since this changes infrequently (and when it does, we need to reset everything anyway). No real reason to make this change other than that it possibly prevents nasty surprises in the future, so I feel more comfortable about it.
* common, vo_opengl: add/use helper for formatted strings on the stackwm42017-07-241-8/+4
| | | | | | | | | | | Seems like I really like this C99 idiom. No reason not to generalize it do snprintf(). Introduce mp_tprintf(), which basically this idiom to snprintf(). This macro looks like it returns a string that was allocated with alloca() on the caller site, except it's portable C99/C11. (And unlike alloca(), the result is valid only within block scope.) Use it in 2 places in the vo_opengl code. But it has the potential to make a whole bunch of weird looking code look slightly nicer.
* vo_opengl: add direct rendering supportwm42017-07-241-4/+151
| | | | | | | | | | | | | | | | | | | | Can be enabled via --vd-lavc-dr=yes. See manpage additions for what it does. This reminds of the MPlayer -dr flag, but the implementation is completely different. It's the same basic concept: letting the decoder render into a GPU buffer to avoid a copy. Unlike MPlayer, this doesn't try to go through filters (libavfilter doesn't support this anyway). Unless a filter can work in-place, DR will be silently disabled. MPlayer had very complex semantics about buffer types and management (which apparently nobody ever understood) and weird restrictions that mostly limited it to mpeg2 style codecs. The mpv code does not do any of this, and just lets the decoder allocate an arbitrary number of untyped images. (No MPlayer code was used.) Parts of the code based on work by atomnuker (starting point for the generic code) and haasn (some GL definitions, some basic PBO code, and correct fencing).
* vo_opengl: add printf format checking to pass_describe()wm42017-07-221-0/+1
|
* vo_opengl: osd: use new VAO mechanismwm42017-07-221-22/+4
| | | | | | | In addition to using the new VAO mechanism introduced in the previous commit, this tries to keep the OSD code self-contained. This doesn't work all too well (because of the pass and CMS stuff), but it's still better than before.
* vo_opengl: add mechanism to create/cache VAO on the flywm42017-07-221-10/+3
| | | | | | This removes VAO handling from video.c. Instead the shader cache will create the VAO as needed. The consequence is that this creates a VAO per shader, which might be a bit wasteful, but doesn't matter anyway.
* vo_opengl: osd: refactor and simplifywm42017-07-221-1/+2
| | | | | | | | Reduce this to 1 draw call per OSD pass. This removes the need for some annoying special handling regarding 3D video support (we supported duplicating the OSD/subtitles for side-by-side 3D output etc.). Remove the unneeded texture sampler uniform thing.
* vo_opengl: avoid constant divisionsNiklas Haas2017-07-171-9/+10
| | | | | | | These are apparently expensive on some drivers which are not smart enough to turn x/42 into x*1.0/42. So, do it for them. My great test framework says it's okay
* vo_opengl: generalize --scale-clamp etc.Niklas Haas2017-07-121-1/+1
| | | | | This can help fight ringing without completely killing it, thus providing a middle-ground between ringing and aliasing.
* vo_opengl: remove redundant gl_video_setup_hooks callNiklas Haas2017-07-121-1/+0
| | | | | | | | This is unnecessary to call from gl_video_resize, because the hooks only (possibly) change when the actual vo_opengl options change. This used to be required back when mpv still had prescaling built in, but since that was all moved to user shaders and the code removed, this is a left-over artifact.
* vo_opengl: fix type of glsl variable frameAman Gupta2017-07-111-1/+1
|
* vo_opengl: don't make assumptions about plane orderwm42017-07-101-9/+30
| | | | | | | | | | | | | | | | | | | The renderer code doesn't list a fixed set of supported formats, but supports anything that is described by AVPixFmtDescriptor and follows a number of constraints. Plane order is not included in those constraints. This means the planes could be in random order, rather than what the vo_opengl renderer happens to assume. For example, it assumes that the 4th plane is alpha, even though alpha could be on any plane. Likewise it assumes that plane 0 was always luma, and planes 2/3 chroma. (In earlier iterations of format support, this was guaranteed by MP_IMGFLAG_YUV_P, but this is not used anymore.) Explicitly set the plane semantics (enum plane_type) by the component descriptors and the used colorspace. The behavior should mostly not change, but it's less likely to break when FFmpeg adds new pixel formats.
* vo_opengl: fix dumb_mode chroma transformation fixupNiklas Haas2017-07-101-2/+2
| | | | | | | | In commit 6eb0bbe this was changed from xs[n] to use gl_format.chroma_w indiscriminately, which broke chroma rendering when zooming/cropping. The solution is to only use chroma_w for chroma planes. Fixes #4592.
* vo_opengl: describe the remainder passes after user shadersNiklas Haas2017-07-091-0/+1
| | | | | | | | | | | | On optional hook points, we store to a temp FBO and then read from it again to complete any operations that may still be left (e.g. sigmoidization after MAIN/LINEAR). In theory this mechanism should be reworked to avoid the temporary FBO until the next time we actually need one - and also skip redundant passes if we the next thing we need *is* a FBO - but both are those are tricky. Anyway, in the meantime, at least we can label the (semi-)redundant passes that get generated when using user shaders.
* vo_opengl: rework --opengl-dumb-modeNiklas Haas2017-07-071-4/+9
| | | | | | | It's now possible to request non-dumb mode as a user, even when not using any non-dumb features. This change is mostly intended for testing, so I can easily switch between dumb and non-dumb mode on default settings. The default behavior is unaffected.
* vo_opengl: also expose NAME_mul for user shadersNiklas Haas2017-07-061-2/+3
| | | | | | | | | This is exposed so that bjin/mpv-prescalers can use textureGatherOffset for performance. Since there are now quite a lot of parameters where it isn't quite clear why they're all defined, add a paragraph to the man page that explains them a bit.
* vo_opengl: add --tone-mapping-desaturateNiklas Haas2017-07-061-1/+5
| | | | | | | This helps prevent unnaturally, weirdly colorized blown out highlights for direct images of the sunlit sky and other way-too-bright HDR content. I was debating whether to set the default at 1.0 or 2.0, but went with the more conservative option that preserves more detail/color.
* vo_opengl: get rid of weird double-bind in pass_read_fboNiklas Haas2017-07-051-4/+2
| | | | | | | | This logic doesn't really make sense. copy_img_tex already binds the texture, so why would we bind it a second time? Furthermore, nothing actually uses this return value. Must have been some left-over artifact of a previous iteration of this function. Anyway, it's harmless, just nonsensical. So remove it.
* vo_opengl: remove redundant left-over lineNiklas Haas2017-07-051-1/+0
| | | | The pass_read_fbo immediately below replaces it
* vo_opengl: use textureGatherOffset for polar filtersNiklas Haas2017-07-051-1/+1
| | | | | | | | | | | | | | | | | | 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-031-4/+9
| | | | | | | | 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-021-6/+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-011-58/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usagewm42017-06-301-35/+42
| | | | | 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-301-45/+54
| | | | | | | | | | | | 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-301-1/+6
| | | | | | | | | | | | | | | | | | | | | | | 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: unify user_shaders constantsNiklas Haas2017-06-281-13/+9
| | | | | | | | | | | | | | | 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: 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: implement support for OOTFs and non-display referred contentNiklas Haas2017-06-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-181-5/+1
| | | | | | | | | | 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-181-35/+5
| | | | | | | | | | | | | | | 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.
* 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-091-0/+1
| | | | | | | | | | | | | | | | | 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.
* 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: 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: add option for caching shaders on diskwm42017-04-081-1/+2
| | | | | | | | | | | | | 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: use 16 bit textures with anglewm42017-04-031-1/+0
| | | | | | Regression due to 03fe506. It accidentally changed the default value if glGetTexLevelParameteriv() is not available, which is the case with ANGLE.
* vo_opengl: replace uniform variable image_size with input_sizeigv2017-03-251-2/+5
| | | | | | input_size can be the size of a cropped image Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: add tex_offset uniform variable to user shadersigv2017-03-251-0/+5
|
* vo_opengl: make size of a cropped source image available to user shadersigv2017-03-251-0/+6
|
* vo_opengl: read framebuffer depth from actual FBO used for renderingwm42017-03-201-9/+11
| | | | | | | | | | | | In some cases, such as when using the libmpv opengl-cb API, or with certain vo_opengl backends, the main framebuffer is never accessed. Instead, rendering is done to a FBO that acts as back buffer. This meant an incorrect/broken bit depth could be used for dithering. Change it to read the framebuffer depth lazily on the first render call. Also move the main FBO field out of the GL struct to MPGLContext, because the renderer's init function does not need to access it anymore.
* vo_opengl: move some init_gl code to utility functionswm42017-03-201-50/+12
|
* vo_opengl: properly respect dither option if dumb mode is usedwm42017-03-201-1/+6
| | | | | | | When dumb mode is used (the "simple" rendering path), respect the dither options. Options should never be ignored (except in GLESv2 mode); either they should be respected in dumb mode, or they should disable dumb mode. In this case, the former applies.
* options: add M_OPT_FILE to some more file optionsPhilip Sequeira2017-03-061-1/+1
| | | | (Helps shell completion.)
* filter_kernels: Keep f.radius in terms of dest/filter coords.</