RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2025-03-11 08:37:59 +00:00
Code Issues Releases Wiki Activity
e1b4e5e727
mpv/video/out/gpu/video.c

4040 lines
137 KiB
C
Raw Normal View History

vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
/*
* This file is part of mpv.
*
Change GPL/LGPL dual-licensed files to LGPL Do this to make the license situation less confusing. This change should be of no consequence, since LGPL is compatible with GPL anyway, and making it LGPL-only does not restrict the use with GPL code. Additionally, the wording implies that this is allowed, and that we can just remove the GPL part.
2016-01-19 17:36:34 +00:00
* mpv is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
*
* mpv is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
Change GPL/LGPL dual-licensed files to LGPL Do this to make the license situation less confusing. This change should be of no consequence, since LGPL is compatible with GPL anyway, and making it LGPL-only does not restrict the use with GPL code. Additionally, the wording implies that this is allowed, and that we can just remove the GPL part.
2016-01-19 17:36:34 +00:00
* GNU Lesser General Public License for more details.
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
*
Change GPL/LGPL dual-licensed files to LGPL Do this to make the license situation less confusing. This change should be of no consequence, since LGPL is compatible with GPL anyway, and making it LGPL-only does not restrict the use with GPL code. Additionally, the wording implies that this is allowed, and that we can just remove the GPL part.
2016-01-19 17:36:34 +00:00
* You should have received a copy of the GNU Lesser General Public
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
*/
#include <assert.h>
gl_video: add some missing includes On most platforms, they are recursively included, but not all.
2013-03-30 03:01:17 +00:00
#include <math.h>
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
#include <stdarg.h>
gl_video: add some missing includes On most platforms, they are recursively included, but not all.
2013-03-30 03:01:17 +00:00
#include <stdbool.h>
#include <string.h>
#include <assert.h>
#include <libavutil/common.h>
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
#include <libavutil/lfg.h>
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: remove gl_ prefixes from files in video/out/opengl This is a bit redundant with the name of the directory itself, and not in line with existing naming conventions.
2015-08-29 02:12:56 +00:00
#include "video.h"
gl_video: add some missing includes On most platforms, they are recursively included, but not all.
2013-03-30 03:01:17 +00:00
Move compat/ and bstr/ directory contents somewhere else bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
2014-08-29 10:09:04 +00:00
#include "misc/bstr.h"
vo_opengl: fix deband sub-option handling This all has to be done manually.
2015-09-09 18:40:04 +00:00
#include "options/m_config.h"
vo_opengl: warn if interpolation is enabled, but not display-sync Try to avoid user confusion. Reading the global options in this place is a pretty disgusting hack, but it's still the most robust way.
2015-11-28 18:59:11 +00:00
#include "common/global.h"
#include "options/options.h"
vo_opengl: remove gl_ prefixes from files in video/out/opengl This is a bit redundant with the name of the directory itself, and not in line with existing naming conventions.
2015-08-29 02:12:56 +00:00
#include "utils.h"
#include "hwdec.h"
#include "osd.h"
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
#include "ra.h"
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
#include "stream/stream.h"
vo_opengl: move self-contained shader routines to a separate file This is mostly to cut down somewhat on the amount of code bloat in video.c by moving out helper functions (including scaler kernels and color management routines) to a separate file. It would certainly be possible to move out more functions (eg. dithering or CMS code) with some extra effort/refactoring, but this is a start. Signed-off-by: wm4 <wm4@nowhere>
2015-09-05 12:03:00 +00:00
#include "video_shaders.h"
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
#include "user_shaders.h"
vo_opengl: move gl_* files to their own subdir This is mainly just to keep things a bit more organized and separated inside the codebase.
2015-08-28 23:10:30 +00:00
#include "video/out/filter_kernels.h"
#include "video/out/aspect.h"
#include "video/out/dither.h"
#include "video/out/vo.h"
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: rename all scale options to make more sense This emphasizes the fact that scale is used for *all* image upscaling, with cscale only serving a minor role for subsampled material.
2015-01-20 20:46:19 +00:00
// scale/cscale arguments that map directly to shader filter routines.
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
// Note that the convolution filters are not included in this list.
Add more const While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
2014-06-10 21:56:05 +00:00
static const char *const fixed_scale_filters[] = {
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
"bilinear",
"bicubic_fast",
vo_opengl: add oversample scaler This is like nearest neighbour, but the edges between pixels are linearly interpolating if needed, as if they had been (naively) oversampled.
2015-03-15 05:27:11 +00:00
"oversample",
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
NULL
};
vo_opengl: add oversample support for tscale This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
2015-03-15 06:11:51 +00:00
static const char *const fixed_tscale_filters[] = {
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
"oversample",
vo_opengl: add a tscale=linear direct implementation This uses GLSL mix() instead of going through an indirect texture access. Easy to implement and might require less resources on some devices, since the oversample code was already essentially just a special case of this. Could be made the new default (as per issue #2685), but that should be done in a separate commit.
2016-07-19 18:12:33 +00:00
"linear",
vo_opengl: add oversample support for tscale This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
2015-03-15 06:11:51 +00:00
NULL
};
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
// must be sorted, and terminated with 0
vo_opengl: use all filter sizes possible with the shaders Not all filter sizes the shaders could handle were in the filter_sizes list. The shader can handle any multiple of 4 (the sizes 2 and 6 are special-cased to keep it simple). Add all possible filter sizes, up to 64. 64 is ridiculously high anyway. Most of the larger filter sizes are completely useless for upscaling, but help with the fancy-downscaling option. (Although it would still be more efficient to use cascaded scalers to handle downscaling better.) I considered doing something less stupid than the hardcoded array, but it seems this is still the simplest solution.
2014-12-08 16:08:26 +00:00
int filter_sizes[] =
{2, 4, 6, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56, 60, 64, 0};
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
int tscale_sizes[] = {2, 4, 6, 8, 0};
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
struct vertex_pt {
float x, y;
};
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
struct texplane {
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
struct ra_tex *tex;
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
int w, h;
vo_opengl: support inconsistent negative strides per plane GL generally does not support flipping the image on upload, meaning negative strides are not supported. vo_opengl handles this by flipping rendering if the stride is inverted, and gl_pbo_upload() "ignores" negative strides by uploading without flipping the image. If individual planes had strides with different signs, this broke. The flipping affected the entire image, and only the sign of the first plane was respected. This is just a crazy corner case that will never happen, but it turns out this is quite simple to support, and actually improves the code somewhat.
2016-07-03 14:09:26 +00:00
bool flipped;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
};
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
struct video_image {
gl_video: always upload all planes When displaying YUV with alpha plane (an extremely rare special case), we didn't upload the alpha plane, because we don't do anything with it. This actually created some annoying special cases, so upload the alpha planes as well, even if they're unused.
2013-03-28 20:02:53 +00:00
struct texplane planes[4];
vo_opengl: simplify screenshot code Instead of reading back the image from textures, keep a reference to the original image, and return that. The main reason this was done this way was that originally, images weren't refcounted, and would be deallocated or overwritten as soon as the VO's draw call returned. But now there isn't really a good reason for this anymore. One possibly _could_ argue that it was better because other code could reuse the image sooner (e.g. for the cache), but on the other hand, the VO runs already on a different thread, and filtering and decoding each run on other threads too, so this argument probably wouldn't hold up.
2015-01-22 17:29:37 +00:00
struct mp_image *mpi; // original input image
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
uint64_t id; // unique ID identifying mpi contents
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
bool hwdec_mapped;
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
};
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
enum plane_type {
PLANE_NONE = 0,
PLANE_RGB,
PLANE_LUMA,
PLANE_CHROMA,
PLANE_ALPHA,
PLANE_XYZ,
vo_opengl: add smoothmotion frame blending SmoothMotion is a way to time and blend frames made popular by MadVR. It's intended behaviour is to remove stuttering caused by mismatches between the display refresh rate and the video fps, while preserving the video's original artistic qualities (no soap opera effect). It's supposed to make 24fps video playback on 60hz monitors as close as possible to a 24hz monitor. Instead of drawing a frame once once it's pts has passed the vsync time, we redraw at the display refresh rate, and if we detect the vsync is between two frames we interpolated them (depending on their position relative to the vsync). We actually interpolate as few frames as possible to avoid a blur effect as much as possible. For example, if we were to play back a 1fps video on a 60hz monitor, we would blend at most on 1 vsync for each frame (while the other 59 vsyncs would be rendered as is). Frame interpolation is always done before scaling and in linear light when possible (an ICC profile is used, or :srgb is used).
2014-11-23 19:06:05 +00:00
};
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
static const char *plane_names[] = {
[PLANE_NONE] = "unknown",
[PLANE_RGB] = "rgb",
[PLANE_LUMA] = "luma",
[PLANE_CHROMA] = "chroma",
[PLANE_ALPHA] = "alpha",
[PLANE_XYZ] = "xyz",
};
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
// A self-contained description of a source image which can be bound to a
// texture unit and sampled from. Contains metadata about how it's to be used
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct image {
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
enum plane_type type; // must be set to something non-zero
int components; // number of relevant coordinates
float multiplier; // multiplier to be used when sampling
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
struct ra_tex *tex;
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
int w, h; // logical size (after transformation)
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
struct gl_transform transform; // rendering transformation
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
};
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
// A named image, for user scripting purposes
struct saved_img {
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
const char *name;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct image img;
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
};
// A texture hook. This is some operation that transforms a named texture as
// soon as it's generated
struct tex_hook {
vo_opengl: slightly refactor user_shaders code - Each struct tex_hook now stores multiple hooks, this allows us to avoid the awkward way of the current code has to add the same pass multiple times. - As a consequence, SHADER_MAX_HOOKS was split up into SHADER_MAX_PASSES (number of tex_hooks) and SHADER_MAX_HOOKS (number of hooked textures per tex_hook), and both numbers decreased correspondingly. - Instead of having a weird free() callback, we can just leverage talloc's recursive free behavior. The only user is the user shaders code anyway.
2017-07-10 20:52:39 +00:00
const char *save_tex;
const char *hook_tex[SHADER_MAX_HOOKS];
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
const char *bind_tex[SHADER_MAX_BINDS];
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
int components; // how many components are relevant (0 = same as input)
vo_opengl: slightly refactor user_shaders code - Each struct tex_hook now stores multiple hooks, this allows us to avoid the awkward way of the current code has to add the same pass multiple times. - As a consequence, SHADER_MAX_HOOKS was split up into SHADER_MAX_PASSES (number of tex_hooks) and SHADER_MAX_HOOKS (number of hooked textures per tex_hook), and both numbers decreased correspondingly. - Instead of having a weird free() callback, we can just leverage talloc's recursive free behavior. The only user is the user shaders code anyway.
2017-07-10 20:52:39 +00:00
void *priv; // this gets talloc_freed when the tex_hook is removed
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
void (*hook)(struct gl_video *p, struct image img, // generates GLSL
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
struct gl_transform *trans, void *priv);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
bool (*cond)(struct gl_video *p, struct image img, void *priv);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
};
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct surface {
struct ra_tex *tex;
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
uint64_t id;
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
double pts;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
};
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
#define SURFACES_MAX 10
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
struct cached_file {
char *path;
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
struct bstr body;
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
};
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
struct pass_info {
struct bstr desc;
struct mp_pass_perf perf;
};
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
struct dr_buffer {
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
struct ra_buf *buf;
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
// The mpi reference will keep the data from being recycled (or from other
// references gaining write access) while the GPU is accessing the buffer.
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
struct mp_image *mpi;
};
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
struct gl_video {
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
struct ra *ra;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
struct mpv_global *global;
video/out: use new mp_msg stuff for vo.c and vo_opengl The first step; also serves as example.
2013-07-31 19:44:21 +00:00
struct mp_log *log;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
struct gl_video_opts opts;
vo_opengl: deprecate sub-options, add them as global options vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
2016-09-02 13:59:40 +00:00
struct m_config_cache *opts_cache;
vo_opengl: generate 3DLUT against source and use full BT.1886 This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
2016-02-13 14:33:00 +00:00
struct gl_lcms *cms;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: use standard functions to retrieve display depth Until now, we've used system-specific API (GLX, EGL, etc.) to retrieve the depth of the default framebuffer. (We equal this to display depth and use the determined depth for dithering.) We can actually retrieve this value through standard GL API, and it works everywhere (except GLES 2 of course). This simplifies everything a great deal. egl_helpers.c is empty now. But I expect that some EGL boilerplate will be moved to it, so don't remove it yet.
2016-06-14 08:35:43 +00:00
int fb_depth; // actual bits available in GL main framebuffer
rpi: fix build Runtime untested, because I get this: [vo/rpi] Could not get DISPMANX objects. This happened even when building older git versions, and on a RPI image that hasn't changed in the recent years. I don't know how to make this POS work again, so I guess if there's a bug in the new code, it will remain broken.
2017-08-11 11:02:13 +00:00
struct m_color clear_color;
bool force_clear_color;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
struct gl_shader_cache *sc;
video/out: change aspects of OSD handling Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
2014-06-15 18:46:57 +00:00
struct osd_state *osd_state;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
struct mpgl_osd *osd;
video/out: change aspects of OSD handling Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
2014-06-15 18:46:57 +00:00
double osd_pts;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: manage ICC LUT texture via ra Also move the capability check to gl_video_get_lut3d(), because it seems more convenient (ra won't have a _CAP_EXT16).
2017-07-29 19:22:11 +00:00
struct ra_tex *lut_3d_texture;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
bool use_lut_3d;
vo_opengl: increase 3DLUT accuracy at lower LUT sizes This code had the exact same texture indexing bug that the original scaler code had before the introduction of the LUT_POS macro to fix it. We can re-use this same macro here, and the performance drop is virtually entirely negligible. The benefit is greatly improved LUT accuracy as the 3DLUT size decreases - in particular, the old LUT started introducing more and more black crush the lower your LUT size is (because the error was essentially an over-contrast bias, with a magnitude linearly related to the lut size). The new code improves black stability as the LUT size decreases, and only at very low values (16 and below) do black levels start noticeably getting affected (due to crude linearization of the nonlinear response curve). The default value of 3dlut-size is definitely generous enough for this to make no difference out of the box, but it also causes no performance drop at all on my machine so I see no harm in improving the logic. Furthermore, this means we could easily decrease the default 3dlut size in a future commit, perhaps even down to 64x64x64 as a default. (But more testing is warranted here)
2016-07-25 08:18:41 +00:00
int lut_3d_size[3];
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: manage dither texture via ra Also add some more helpers. Fix the broken math.h include statement. utils.c uses ra_gl.h internals, which it shouldn't, and which will be removed again as soon as this code gets converted to ra fully.
2017-07-29 18:14:48 +00:00
struct ra_tex *dither_texture;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
struct mp_image_params real_image_params; // configured format
struct mp_image_params image_params; // texture format (mind hwdec case)
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
struct ra_imgfmt_desc ra_format; // texture format
vo_opengl: some minor cleanups default_tex_params() and texture_size() are each called only once, so move inline/reimplement them at the caller. image_dw/dh were unused. texture_w/h, image_format, and component_bits were rarely used, and can be replaced. Regroup some other fields. Rename surface_num to surface_idx, because the former sounded like a count, and not an index. Move fbosurface_next() closer to its callers too. Move the DebugMessageCallback() code to gl_utils.c (also simplify it by always setting the callback, instead of only when it changes).
2015-01-29 14:50:21 +00:00
int plane_count;
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
bool is_gray;
gl_video: add support for more rgb formats Until now, only formats directly supported by OpenGL were supported. This excludes various permutations of 8-bit RGB[A|0]. But we can simply permutate the color channels in the shader, so do that. This also adds support for all these weird RGB0 formats. Note that we could use libavutil's pixfmt list instead of the mp_packed_formats array, but trying to decrypt the pixfmt info would probably end in pain, so this array with duplicated information is actually better and shorter. Note: I didn't actually test whether the alpha components are reproduced correctly with alpha formats.
2013-07-18 11:52:38 +00:00
bool has_alpha;
char color_swizzle[5];
vo_opengl: support 10 bit support with ANGLE GLES does not support high bit depth fixed point textures for unknown reasons, so direct 10 bit input is not possible. But we can still use integer textures, which are supported by GLES 3.0. These store integer data just like the standard fixed point textures, except they are not normalized on sampling. They also don't support bilinear filtering, and require a special sampler ("usampler2D"). While these texture formats enable us to shuffle the data to the GPU, they're rather impractical with the requirements mentioned above and our current architecture. One problem is that most code assumes it can always use bilinear scaling (even if bilinear is never used when using appropriate scale/cscale options). Another is that we don't have any concept of running a function on a texture in an uniform way. So for now, run a simple conversion step through a FBO. The FBO will use the rgba16f format normally, which gives enough bits for 10 bit, and will at least gracefully degrade with higher depth input. This is bound to be much slower than a more "direct" method, but at least it works and is simple to implement. The odd change of function call order in init_video() is to properly disable "dumb mode" (no FBO use) if these texture formats are in use.
2016-01-26 19:47:32 +00:00
bool use_integer_conversion;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
struct video_image image;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
struct dr_buffer *dr_buffers;
int num_dr_buffers;
bool using_dr_path;
vo_opengl: enable dumb-mode automatically if possible I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
2015-11-19 20:22:24 +00:00
bool dumb_mode;
vo_opengl: support 10 bit support with ANGLE GLES does not support high bit depth fixed point textures for unknown reasons, so direct 10 bit input is not possible. But we can still use integer textures, which are supported by GLES 3.0. These store integer data just like the standard fixed point textures, except they are not normalized on sampling. They also don't support bilinear filtering, and require a special sampler ("usampler2D"). While these texture formats enable us to shuffle the data to the GPU, they're rather impractical with the requirements mentioned above and our current architecture. One problem is that most code assumes it can always use bilinear scaling (even if bilinear is never used when using appropriate scale/cscale options). Another is that we don't have any concept of running a function on a texture in an uniform way. So for now, run a simple conversion step through a FBO. The FBO will use the rgba16f format normally, which gives enough bits for 10 bit, and will at least gracefully degrade with higher depth input. This is bound to be much slower than a more "direct" method, but at least it works and is simple to implement. The odd change of function call order in init_video() is to properly disable "dumb mode" (no FBO use) if these texture formats are in use.
2016-01-26 19:47:32 +00:00
bool forced_dumb_mode;
vo_opengl: enable dumb-mode automatically if possible I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
2015-11-19 20:22:24 +00:00
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
// Cached vertex array, to avoid re-allocation per frame. For simplicity,
// our vertex format is simply a list of `vertex_pt`s, since this greatly
// simplifies offset calculation at the cost of (unneeded) flexibility.
struct vertex_pt *tmp_vertex;
struct ra_renderpass_input *vao;
int vao_len;
vo_opengl: make fbotex helper use ra Further work removing GL dependencies from the actual video renderer, and moving them into ra backends. Use of glInvalidateFramebuffer() falls away. I'd like to keep this, but it's better to readd it once shader runs are in ra.
2017-08-04 11:48:37 +00:00
const struct ra_format *fbo_format;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct ra_tex *merge_tex[4];
struct ra_tex *scale_tex[4];
struct ra_tex *integer_tex[4];
struct ra_tex *indirect_tex;
struct ra_tex *blend_subs_tex;
struct ra_tex *screen_tex;
struct ra_tex *output_tex;
struct ra_tex *vdpau_deinterleave_tex[2];
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
struct ra_tex **hook_textures;
int num_hook_textures;
int idx_hook_textures;
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
struct ra_buf *hdr_peak_ssbo;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct surface surfaces[SURFACES_MAX];
vo_opengl: add Super-xBR filter for upscaling Add the Super-xBR filter for image doubling, and the prescaling framework to support it. The shader code was ported from MPDN extensions project, with modification to process luma only. This commit is largely inspired by code from #2266, with `gl_transform_trans()` authored by @haasn taken directly.
2015-10-26 22:43:48 +00:00
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
// user pass descriptions and textures
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
struct tex_hook *tex_hooks;
int num_tex_hooks;
struct gl_user_shader_tex *user_textures;
int num_user_textures;
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
int surface_idx;
int surface_now;
vo_opengl: fix "freezes" after seeking with interpolation on When seeking to a different position, and seeking takes long, the OSD might get redrawn. This means that the VO will receive a request to redraw an old frame using whatever the previous PTS was. This breaks the interpolation logic: the old frame will be added to the queue, and then the next frames (with lower PTS if you seeked backwards) are not drawn as the logic assumes they're past frames. Fix this by using the non-interpolation code path when redrawing after a seek reset, and no "real" frame has been drawn yet. It's a recent regression caused by the redrawing code simplification. The old code simply sent a VOCTRL for redrawing the frame, and the VO had to deal with retaining the old frame on its own. This is a hack as in there's probably a better solution. Fixes #2097.
2015-07-02 11:17:20 +00:00
int frames_drawn;
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
bool is_interpolated;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
bool output_tex_valid;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: add macros for scaler units There was no real point in hard-coding these all over the place, especially since the order was sort of arbitrary and confusing.
2016-03-05 08:42:57 +00:00
// state for configured scalers
struct scaler scaler[SCALER_COUNT];
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
video: redo video equalizer option handling I really wouldn't care much about this, but some parts of the core code are under HAVE_GPL, so there's some need to get rid of it. Simply turn the video equalizer from its current fine-grained handling with vf/vo fallbacks into global options. This makes updating them much simpler. This removes any possibility of applying video equalizers in filters, which affects vf_scale, and the previously removed vf_eq. Not a big loss, since the preferred VOs have this builtin. Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and vo_xv. I'm not going to waste my time on these legacy VOs. vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which exists _only_ to trigger a redraw. This seems silly, but for now I feel like this is less of a pain. The rest of the equalizer using code is self-updating. See commit 96b906a51d5 for how some video equalizer code was GPL only. Some command line option names and ranges can probably be traced back to a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
struct mp_csp_equalizer_state *video_eq;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
struct mp_rect src_rect; // displayed part of the source video
struct mp_rect dst_rect; // video rectangle on output window
struct mp_osd_res osd_rect; // OSD size/margins
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
// temporary during rendering
vo_opengl: make compute shaders more flexible This allows users to do their own custom sample writing, mainly meant to address use cases such as RAVU. Also clean up the compute shader code a bit.
2017-07-29 18:41:50 +00:00
struct compute_info pass_compute; // compute shader metadata for this pass
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
struct image *pass_imgs; // bound images for this pass
int num_pass_imgs;
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
struct saved_img *saved_imgs; // saved (named) images for this frame
int num_saved_imgs;
// effective current texture metadata - this will essentially affect the
// next render pass target, as well as implicitly tracking what needs to
// be done with the image
vo_opengl: make image size dynamic during rendering This commit marks the image size variables temporary, and renames them in order to prevent any potential confusion in the future.
2015-10-23 17:52:03 +00:00
int texture_w, texture_h;
vo_opengl: add Super-xBR filter for upscaling Add the Super-xBR filter for image doubling, and the prescaling framework to support it. The shader code was ported from MPDN extensions project, with modification to process luma only. This commit is largely inspired by code from #2266, with `gl_transform_trans()` authored by @haasn taken directly.
2015-10-26 22:43:48 +00:00
struct gl_transform texture_offset; // texture transform without rotation
vo_opengl: refactor plane-skipping optimizations Instead of hard-coding the logic and planes to skip, factor this out to a reusible function, and instead add the number of relevant coordinates to the texture state.
2016-03-05 11:38:51 +00:00
int components;
vo_opengl: color manage after interpolation This moves the color management code out of pass_render_main (which is now dedicated solely to up/downscaling and hence renamed pass_scale_main) and into a new function, which gets called from pass_draw_to_screen instead. This makes more sense from a logical standpoint, and also means that we interpolate in linear RGB, before color management - rather than after it, which is significantly better for color accuracy and probably also interpolation quality.
2015-03-15 21:52:34 +00:00
bool use_linear;
vo_opengl: apply OSD color management
2015-03-15 23:09:36 +00:00
float user_gamma;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
// pass info / metrics
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
struct pass_info pass_fresh[VO_PASS_PERF_MAX];
struct pass_info pass_redraw[VO_PASS_PERF_MAX];
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
struct pass_info *pass;
int pass_idx;
vo_opengl: move timers to struct ra In order to prevent code duplication and keep the ra abstraction as small as possible, `ra` only implements the actual timer queries, it does not do pooling/averaging of the results. This is instead moved to a ra-neutral struct timer_pool in utils.c.
2017-08-05 16:20:45 +00:00
struct timer_pool *upload_timer;
struct timer_pool *blit_timer;
vo_opengl: measure pass_draw_osd as a whole In the past, this always measured the per-shader execution times of the individual OSD parts, which was thrown off because the shader was reused anyway. (And apparently recording the OSD shader execution times was removed completely, probably because of them being so unrealiably anyway) Since ra_timer no longer has the restriction of not allowing timers to run concurrently, we can just wrap the entire OSD block inside a single osd_timer now, and record that. (Technically, this can still be off when using --blend-subtitles=video/yes and showing a full-screen OSD at the same time. Maybe this can be done better?)
2017-08-05 16:59:28 +00:00
struct timer_pool *osd_timer;
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
int frames_uploaded;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
int frames_rendered;
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
AVLFG lfg;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
gl_video: improve dithering Use a different algorithm to generate the dithering matrix. This looks much better than the previous ordered dither matrix with its cross-hatch artifacts. The matrix generation algorithm as well as its implementation was contributed by Wessel Dankers aka Fruit. The code in dither.c is his implementation, reformatted and with static global variables removed by me. The new matrix is uploaded as float texture - before this commit, it was a normal integer fixed point matrix. This means dithering will be disabled on systems without float textures. The size of the dithering matrix can be configured, as the matrix is generated at runtime. The generation of the matrix can take rather long, and is already unacceptable with size 8. The default is at 6, which takes about 100 ms on a Core2 Duo system with dither.c compiled at -O2, which I consider just about acceptable. The old ordered dithering is still available and can be selected by putting the dither=ordered sub-option. The ordered dither matrix generation code was moved to dither.c. This function was originally written by Uoti Urpala.
2013-05-25 23:48:39 +00:00
// Cached because computing it can take relatively long
int last_dither_matrix_size;
float *last_dither_matrix;
vo_opengl: never clear file cache Make it dynamic and never remove entries from it. For now, this is better than possibly creating dangling pointers all over the place in the gl_user_shader struct. Untested.
2016-05-16 10:46:29 +00:00
struct cached_file *files;
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
int num_files;
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
bool hwdec_interop_loading_done;
struct ra_hwdec **hwdecs;
int num_hwdecs;
vo_opengl: separate hwdec context and mapping, port it to use ra This does two separate rather intrusive things: 1. Make the hwdec context (which does initialization, provides the device to the decoder, and other basic state) and frame mapping (getting textures from a mp_image) separate. This is more flexible, and you could map multiple images at once. It will help removing some hwdec special-casing from video.c. 2. Switch all hwdec API use to ra. Of course all code is still GL specific, but in theory it would be possible to support other backends. The most important change is that the hwdec interop returns ra objects, instead of anything GL specific. This removes the last dependency on GL-specific header files from video.c. I'm mixing these separate changes because both requires essentially rewriting all the glue code, so better do them at once. For the same reason, this change isn't done incrementally. hwdec_ios.m is untested, since I can't test it. Apart from superficial mistakes, this also requires dealing with Apple's texture format fuckups: they force you to use GL_LUMINANCE[_ALPHA] instead of GL_RED and GL_RG. We also need to report the correct format via ra_tex to the renderer, which is done by find_la_variant(). It's unknown whether this works correctly. hwdec_rpi.c as well as vo_rpi.c are still broken. (I need to pull my RPI out of a dusty pile of devices and cables, so, later.)
2017-08-10 15:48:33 +00:00
struct ra_hwdec_mapper *hwdec_mapper;
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
struct ra_hwdec *hwdec_overlay;
vo_opengl: add infrastructure for hardware decoding OpenGL interop Most hardware decoding APIs provide some OpenGL interop. This allows using vo_opengl, without having to read the video data back from GPU. This requires adding a backend for each hardware decoding API. (Each backend is an entry in gl_hwdec_vaglx[].) The backends expose video data as a set of OpenGL textures. Add infrastructure to support this. The next commit will add support for VA-API.
2013-11-03 23:00:18 +00:00
bool hwdec_active;
vo_opengl: warn if interpolation is enabled, but not display-sync Try to avoid user confusion. Reading the global options in this place is a pretty disgusting hack, but it's still the most robust way.
2015-11-28 18:59:11 +00:00
bool dsi_warned;
vo_opengl: change error state handling and fix hwdec crashes on errors gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
2016-05-19 10:18:48 +00:00
bool broken_frame; // temporary error state
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
};
vo_opengl: deprecate sub-options, add them as global options vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
2016-09-02 13:59:40 +00:00
static const struct gl_video_opts gl_video_opts_def = {
vo_opengl: use enums for choice options internally This is much more readable than hard-coding magic IDs all over the file, and removes the need for all the explanatory comments that were a direct result of this.
2016-05-15 22:14:02 +00:00
.dither_algo = DITHER_FRUIT,
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
.dither_depth = -1,
gl_video: improve dithering Use a different algorithm to generate the dithering matrix. This looks much better than the previous ordered dither matrix with its cross-hatch artifacts. The matrix generation algorithm as well as its implementation was contributed by Wessel Dankers aka Fruit. The code in dither.c is his implementation, reformatted and with static global variables removed by me. The new matrix is uploaded as float texture - before this commit, it was a normal integer fixed point matrix. This means dithering will be disabled on systems without float textures. The size of the dithering matrix can be configured, as the matrix is generated at runtime. The generation of the matrix can take rather long, and is already unacceptable with size 8. The default is at 6, which takes about 100 ms on a Core2 Duo system with dither.c compiled at -O2, which I consider just about acceptable. The old ordered dithering is still available and can be selected by putting the dither=ordered sub-option. The ordered dither matrix generation code was moved to dither.c. This function was originally written by Uoti Urpala.
2013-05-25 23:48:39 +00:00
.dither_size = 6,
vo_opengl: add temporal-dither-period option This was requested multiple times by users, and it's not hard to implement and/or maintain.
2015-07-20 17:09:22 +00:00
.temporal_dither_period = 1,
vo_opengl: make fbotex helper use ra Further work removing GL dependencies from the actual video renderer, and moving them into ra backends. Use of glInvalidateFramebuffer() falls away. I'd like to keep this, but it's better to readd it once shader runs are in ra.
2017-08-04 11:48:37 +00:00
.fbo_format = "auto",
video: Add sigmoidal upscaling to avoid ringing artifacts This avoids issues when upscaling directly in linear light, and is the recommended way to upscale images according to imagemagick. The default slope of 6.5 offers a reasonable compromise between ringing artifacts eliminated and ringing artifacts introduced by sigmoid-upscaling. Same goes for the default center of 0.75.
2015-01-06 09:47:26 +00:00
.sigmoid_center = 0.75,
.sigmoid_slope = 6.5,
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
.scaler = {
filter_kernels: add radius cutoff functionality 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)
2017-07-03 09:23:48 +00:00
{{"bilinear", .params={NAN, NAN}}, {.params = {NAN, NAN}},
.cutoff = 0.001}, // scale
{{NULL, .params={NAN, NAN}}, {.params = {NAN, NAN}},
.cutoff = 0.001}, // dscale
{{"bilinear", .params={NAN, NAN}}, {.params = {NAN, NAN}},
.cutoff = 0.001}, // cscale
{{"mitchell", .params={NAN, NAN}}, {.params = {NAN, NAN}},
vo_opengl: make tscale=mitchell:tscale-clamp the default Looks better than "oversample". tscale-clamp suggested by haasn.
2015-11-29 12:04:01 +00:00
.clamp = 1, }, // tscale
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
},
vo_opengl: default scaler-resizes-only sub-option to yes Often requested. The main argument, that prominent scalers like sharpen change the image even if no scaling happens, disappeared anyway. ("sharpen", unsharp masking, is neither prominent nor a scaler anymore. This is an artifact from MPlayer, which fuses unsharp masking with bilinear scaling in order to make it single-pass, or so.)
2016-01-25 20:35:39 +00:00
.scaler_resizes_only = 1,
vo_opengl: decrease default lookup texture size to 64 It turns out that with accurate lookup we can decrease the default size of texture now. Do it to compensate the performance loss introduced by the LUT_POS macro.
2015-12-06 16:22:41 +00:00
.scaler_lut_size = 6,
vo_opengl: replace tscale-interpolates-only with interpolation-threshold The previous approach was too naive, and can e.g. ruin playback if scheduling switches e.g. between 1 and 2 vsync per frame.
2016-01-27 20:07:17 +00:00
.interpolation_threshold = 0.0001,
vo_opengl: use enums for choice options internally This is much more readable than hard-coding magic IDs all over the file, and removes the need for all the explanatory comments that were a direct result of this.
2016-05-15 22:14:02 +00:00
.alpha_mode = ALPHA_BLEND_TILES,
vo_opengl: make background color configurable This mainly affects the black bars that are drawn if the window and video aspect ratios mismatch.
2014-12-09 20:34:01 +00:00
.background = {0, 0, 0, 255},
vo_opengl: change initialization of gamma option Make the lazy gamma initialization less weird, and make the default value of the "gamma" sub-option 1.0. This means --vo=opengl:help will list the actual default value. Also change the lower bound to 0.1 - avoids a division by zero (I don't know how shaders handle NaN, but it's probably not a good idea to give them this value).
2015-02-03 16:12:04 +00:00
.gamma = 1.0f,
vo_gpu: port HDR tone mapping algorithm from libplacebo The current peak detection algorithm was very bugged (which contributed to the excessive cross-frame flicker without long normalization) and also didn't take into account the frame average brightness level. The new algorithm both takes into account frame average brightness (in addition to peak brightness), and also computes the values in a more stable/correct way. (The old path was basically undefined behavior) In addition to improving the algorithm, we also switch to hable tone mapping by default, and try to enable peak computation automatically whever possible (compute shaders + SSBOs supported). We also make the desaturation milder, after extensive testing during libplacebo development. I also had to compensate a bit for the representational differences between mpv and libplacebo (libplacebo treats 1.0 as the reference peak, but mpv treats it as the nominal peak), but it shouldn't have caused any problems. This is still not quite the same as libplacebo, since libplacebo also allows tagging the desired scene average brightness on the output, and it also supports reading the scene average brightness from static metadata (MaxFALL) where available. But those changes are a bit more involved. It's possible we could also read this from metadata in the future, but we have problems communicating with AVFrames as it is and I don't want to touch the mpv colorimetry structs for the time being.
2018-02-03 13:45:01 +00:00
.tone_mapping = TONE_MAPPING_HABLE,
vo_opengl: implement more HDR tonemapping algorithms This is now a configurable option, with tunable parameters. I got inspiration for these algorithms off wikipedia. "simple" seems to work pretty well, but not well enough to make it a reasonable default. Some other notable candidates: - Local functions (e.g. based on local contrast or gradient) - Clamp with soft knee (linear up to a point) - Mapping in CIE L*Ch. Map L smoothly, clamp C and h. - Color appearance models These will have to be implemented some other time. Note that the parameter "peak_src" to pass_tone_map should, in principle, be auto-detected from the SEI information of the source file where available. This will also have to be implemented in a later commit.
2016-05-16 00:44:30 +00:00
.tone_mapping_param = NAN,
vo_gpu: port HDR tone mapping algorithm from libplacebo The current peak detection algorithm was very bugged (which contributed to the excessive cross-frame flicker without long normalization) and also didn't take into account the frame average brightness level. The new algorithm both takes into account frame average brightness (in addition to peak brightness), and also computes the values in a more stable/correct way. (The old path was basically undefined behavior) In addition to improving the algorithm, we also switch to hable tone mapping by default, and try to enable peak computation automatically whever possible (compute shaders + SSBOs supported). We also make the desaturation milder, after extensive testing during libplacebo development. I also had to compensate a bit for the representational differences between mpv and libplacebo (libplacebo treats 1.0 as the reference peak, but mpv treats it as the nominal peak), but it shouldn't have caused any problems. This is still not quite the same as libplacebo, since libplacebo also allows tagging the desired scene average brightness on the output, and it also supports reading the scene average brightness from static metadata (MaxFALL) where available. But those changes are a bit more involved. It's possible we could also read this from metadata in the future, but we have problems communicating with AVFrames as it is and I don't want to touch the mpv colorimetry structs for the time being.
2018-02-03 13:45:01 +00:00
.tone_mapping_desat = 0.5,
vo_opengl: partially re-enable glFlush() calls It turns out the glFlush() call really helps in some cases, though only in audio timing mode (where we render, then wait for a while, then display the frame). Add a --opengl-early-flush=auto mode, which does exactly that. It's unclear whether this is fine on OSX (strange things going on there), but it should be. See #3670.
2016-10-21 15:23:26 +00:00
.early_flush = -1,
video: properly initialize and set hwdec_interop Don't reset --gpu-hwdec-interop if vo_gpu uses dumb mode.
2017-12-10 21:54:32 +00:00
.hwdec_interop = "auto",
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
};
m_option: add mp_log callback to OPT_STRING_VALIDATE options And also convert a bunch of other code, especially ao_wasapi and ao_portaudio.
2013-12-21 19:03:36 +00:00
static int validate_scaler_opt(struct mp_log *log, const m_option_t *opt,
struct bstr name, struct bstr param);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
static int validate_window_opt(struct mp_log *log, const m_option_t *opt,
struct bstr name, struct bstr param);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
#define OPT_BASE_STRUCT struct gl_video_opts
vo_opengl: reduce code duplication for scaler options This simple refactor cuts down on the immense amount of overhead and duplication across all of the related scale-* options.
2015-08-29 01:24:15 +00:00
#define SCALER_OPTS(n, i) \
OPT_STRING_VALIDATE(n, scaler[i].kernel.name, 0, validate_scaler_opt), \
OPT_FLOAT(n"-param1", scaler[i].kernel.params[0], 0), \
OPT_FLOAT(n"-param2", scaler[i].kernel.params[1], 0), \
OPT_FLOAT(n"-blur", scaler[i].kernel.blur, 0), \
filter_kernels: add radius cutoff functionality 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)
2017-07-03 09:23:48 +00:00
OPT_FLOATRANGE(n"-cutoff", scaler[i].cutoff, 0, 0.0, 1.0), \
filter_kernels: add ability to taper kernels/windows This allows us to define the tukey window (and other tapered windows). Also add a missing option definition for `wblur` while we're at it, to make testing out window-related stuff easier.
2016-10-26 14:32:57 +00:00
OPT_FLOATRANGE(n"-taper", scaler[i].kernel.taper, 0, 0.0, 1.0), \
vo_opengl: reduce code duplication for scaler options This simple refactor cuts down on the immense amount of overhead and duplication across all of the related scale-* options.
2015-08-29 01:24:15 +00:00
OPT_FLOAT(n"-wparam", scaler[i].window.params[0], 0), \
filter_kernels: add ability to taper kernels/windows This allows us to define the tukey window (and other tapered windows). Also add a missing option definition for `wblur` while we're at it, to make testing out window-related stuff easier.
2016-10-26 14:32:57 +00:00
OPT_FLOAT(n"-wblur", scaler[i].window.blur, 0), \
OPT_FLOATRANGE(n"-wtaper", scaler[i].window.taper, 0, 0.0, 1.0), \
vo_opengl: generalize --scale-clamp etc. This can help fight ringing without completely killing it, thus providing a middle-ground between ringing and aliasing.
2017-07-12 17:08:58 +00:00
OPT_FLOATRANGE(n"-clamp", scaler[i].clamp, 0, 0.0, 1.0), \
vo_opengl: reduce code duplication for scaler options This simple refactor cuts down on the immense amount of overhead and duplication across all of the related scale-* options.
2015-08-29 01:24:15 +00:00
OPT_FLOATRANGE(n"-radius", scaler[i].radius, 0, 0.5, 16.0), \
OPT_FLOATRANGE(n"-antiring", scaler[i].antiring, 0, 0.0, 1.0), \
OPT_STRING_VALIDATE(n"-window", scaler[i].window.name, 0, validate_window_opt)
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
const struct m_sub_options gl_video_conf = {
Add more const While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
2014-06-10 21:56:05 +00:00
.opts = (const m_option_t[]) {
vo_opengl: refactor into vo_gpu This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
2017-09-14 06:04:55 +00:00
OPT_CHOICE("gpu-dumb-mode", dumb_mode, 0,
vo_opengl: rework --opengl-dumb-mode 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.
2017-07-07 12:46:46 +00:00
({"auto", 0}, {"yes", 1}, {"no", -1})),
vo_opengl: refactor into vo_gpu This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
2017-09-14 06:04:55 +00:00
OPT_FLOATRANGE("gamma-factor", gamma, 0, 0.1, 2.0),
vo_opengl: add gamma-auto option This automatically sets the gamma option depending on lighting conditions measured from the computer's ambient light sensor. sRGB – arguably the “sibling” to BT.709 for still images – has a reference viewing environment defined in its specification (IEC 61966-2-1:1999, see http://www.color.org/chardata/rgb/srgb.xalter). According to this data, the assumed ambient illuminance is 64 lux. This is the illuminance where the gamma that results from ICC color management is correct. On the other hand, BT.1886 formalizes that the gamma level for dim environments to be 2.40, and Apple resources (WWDC12: 2012 Session 523: Best practices for color management) define the BT.1886 dim at 16 lux. So the logic we apply is: * >= 64lux -> 1.961 gamma * =< 16lux -> 2.400 gamma * 16lux < x < 64lux -> logaritmic rescale of lux to gamma. The human perception of illuminance roughly follows a logaritmic scale of lux [1]. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/dd319008%28v=vs.85%29.aspx
2015-02-07 12:54:18 +00:00
OPT_FLAG("gamma-auto", gamma_auto, 0),
vo_opengl: make csp options consistent with vf_format
2015-03-31 05:31:35 +00:00
OPT_CHOICE_C("target-prim", target_prim, 0, mp_csp_prim_names),
OPT_CHOICE_C("target-trc", target_trc, 0, mp_csp_trc_names),
vo_gpu: introduce --target-peak This solves a number of problems simultaneously: 1. When outputting HLG, this allows tuning the OOTF based on the display characteristics. 2. When outputting PQ or other HDR curves, this allows soft-limiting the output brightness using the tone mapping algorithm. 3. When outputting SDR, this allows HDR-in-SDR style output, by controlling the output brightness directly. Closes #5521
2018-02-14 15:10:51 +00:00
OPT_INTRANGE("target-peak", target_peak, 0, 10, 10000),
vo_opengl: generalize HDR tone mapping to gamut mapping Since this code was already written for HDR, and is now per-channel (because it works better for HDR as well), we can actually reuse this to get very high quality gamut mapping without clipping. The only required change is to move the tone mapping from before the gamut map to after the gamut map. Additonally, we need to also account for changes in the signal range as a result of applying the CMS when we compute ref_peak, which is fortunately pretty easy because we only need to consider the case of primaries mapping to themselves. Since `HDR` no longer really makes sense as a label, rename it to `--tone-mapping` in general. Also fits better with `--tone-mapping-desat` etc. Arguably we could also rename `--hdr-compute-peak`, but that option is basically only useful for HDR content anyway because we don't need information about the signal range for gamut mapping. This (finally!) gives us reasonably high quality gamut mapping even in the absence of an ICC profile / 3DLUT.
2017-08-03 10:46:57 +00:00
OPT_CHOICE("tone-mapping", tone_mapping, 0,
vo_opengl: rename tone-mapping=simple to reinhard This is the canonical name for the algorithm. I simply didn't know it before.
2016-05-30 10:30:23 +00:00
({"clip", TONE_MAPPING_CLIP},
vo_opengl: add new HDR tone mapping algorithm 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.
2017-06-09 07:16:06 +00:00
{"mobius", TONE_MAPPING_MOBIUS},
vo_opengl: rename tone-mapping=simple to reinhard This is the canonical name for the algorithm. I simply didn't know it before.
2016-05-30 10:30:23 +00:00
{"reinhard", TONE_MAPPING_REINHARD},
vo_opengl: add hable tone-mapping algorithm Developed by John Hable for use in Uncharted 2. Also used by Frictional Games in SOMA. Originally inspired by a filmic tone mapping algorithm created by Kodak. From http://frictionalgames.blogspot.de/2012/09/tech-feature-hdr-lightning.html
2016-05-30 10:48:01 +00:00
{"hable", TONE_MAPPING_HABLE},
vo_opengl: rename tone-mapping=simple to reinhard This is the canonical name for the algorithm. I simply didn't know it before.
2016-05-30 10:30:23 +00:00
{"gamma", TONE_MAPPING_GAMMA},
{"linear", TONE_MAPPING_LINEAR})),
vo_gpu: port HDR tone mapping algorithm from libplacebo The current peak detection algorithm was very bugged (which contributed to the excessive cross-frame flicker without long normalization) and also didn't take into account the frame average brightness level. The new algorithm both takes into account frame average brightness (in addition to peak brightness), and also computes the values in a more stable/correct way. (The old path was basically undefined behavior) In addition to improving the algorithm, we also switch to hable tone mapping by default, and try to enable peak computation automatically whever possible (compute shaders + SSBOs supported). We also make the desaturation milder, after extensive testing during libplacebo development. I also had to compensate a bit for the representational differences between mpv and libplacebo (libplacebo treats 1.0 as the reference peak, but mpv treats it as the nominal peak), but it shouldn't have caused any problems. This is still not quite the same as libplacebo, since libplacebo also allows tagging the desired scene average brightness on the output, and it also supports reading the scene average brightness from static metadata (MaxFALL) where available. But those changes are a bit more involved. It's possible we could also read this from metadata in the future, but we have problems communicating with AVFrames as it is and I don't want to touch the mpv colorimetry structs for the time being.
2018-02-03 13:45:01 +00:00
OPT_CHOICE("hdr-compute-peak", compute_hdr_peak, 0,
({"auto", 0},
{"yes", 1},
{"no", -1})),
vo_opengl: implement more HDR tonemapping algorithms This is now a configurable option, with tunable parameters. I got inspiration for these algorithms off wikipedia. "simple" seems to work pretty well, but not well enough to make it a reasonable default. Some other notable candidates: - Local functions (e.g. based on local contrast or gradient) - Clamp with soft knee (linear up to a point) - Mapping in CIE L*Ch. Map L smoothly, clamp C and h. - Color appearance models These will have to be implemented some other time. Note that the parameter "peak_src" to pass_tone_map should, in principle, be auto-detected from the SEI information of the source file where available. This will also have to be implemented in a later commit.
2016-05-16 00:44:30 +00:00
OPT_FLOAT("tone-mapping-param", tone_mapping_param, 0),
vo_opengl: add --tone-mapping-desaturate 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.
2017-07-06 03:43:00 +00:00
OPT_FLOAT("tone-mapping-desaturate", tone_mapping_desat, 0),
vo_opengl: add a gamut warning feature This clearly highlights all out-of-gamut/clipped pixels. (Either too bright or too saturated) Has some (documented) caveats. Also make TONE_MAPPING_CLIP stop actually clamping the value range (it's unnecessary and breaks this feature).
2017-09-10 16:18:31 +00:00
OPT_FLAG("gamut-warning", gamut_warning, 0),
vo_opengl: deprecate sub-options, add them as global options vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
2016-09-02 13:59:40 +00:00
OPT_FLAG("opengl-pbo", pbo, 0),
vo_opengl: add macros for scaler units There was no real point in hard-coding these all over the place, especially since the order was sort of arbitrary and confusing.
2016-03-05 08:42:57 +00:00
SCALER_OPTS("scale", SCALER_SCALE),
SCALER_OPTS("dscale", SCALER_DSCALE),
SCALER_OPTS("cscale", SCALER_CSCALE),
SCALER_OPTS("tscale", SCALER_TSCALE),
vo_opengl: make LOOKUP_TEXTURE_SIZE configurable
2015-12-05 19:14:23 +00:00
OPT_INTRANGE("scaler-lut-size", scaler_lut_size, 0, 4, 10),
gl_video: add scaler-resizes-only sub-option This option disables the scaler set with lscale if the video image is not resized.
2013-05-25 21:47:55 +00:00
OPT_FLAG("scaler-resizes-only", scaler_resizes_only, 0),
vo_opengl: add support for linear scaling without CMS This introduces a new option linear-scaling, which is now implied by srgb, icc-profile and sigmoid-upscaling. Notably, this means (sigmoidized) linear upscaling is now enabled by default in opengl-hq mode. The impact should be negligible, and there has been no observation of negative side effects of sigmoidized scaling, so it feels safe to do so.
2015-02-06 02:37:21 +00:00
OPT_FLAG("linear-scaling", linear_scaling, 0),
vo_opengl: rename fancy-downscaling to correct-downscaling The old name was stupid. Very stupid.
2015-11-07 16:49:14 +00:00
OPT_FLAG("correct-downscaling", correct_downscaling, 0),
video: Add sigmoidal upscaling to avoid ringing artifacts This avoids issues when upscaling directly in linear light, and is the recommended way to upscale images according to imagemagick. The default slope of 6.5 offers a reasonable compromise between ringing artifacts eliminated and ringing artifacts introduced by sigmoid-upscaling. Same goes for the default center of 0.75.
2015-01-06 09:47:26 +00:00
OPT_FLAG("sigmoid-upscaling", sigmoid_upscaling, 0),
OPT_FLOATRANGE("sigmoid-center", sigmoid_center, 0, 0.0, 1.0),
OPT_FLOATRANGE("sigmoid-slope", sigmoid_slope, 0, 1.0, 20.0),
vo_opengl: refactor into vo_gpu This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
2017-09-14 06:04:55 +00:00
OPT_STRING("fbo-format", fbo_format, 0),
gl_video: use choice option type for dither-depth suboption Replaces the numeric magic values -1 and 0 with "no" and "auto". The numeric values are still allowed for compatibility.
2013-03-28 20:39:17 +00:00
OPT_CHOICE_OR_INT("dither-depth", dither_depth, 0, -1, 16,
({"no", -1}, {"auto", 0})),
gl_video: improve dithering Use a different algorithm to generate the dithering matrix. This looks much better than the previous ordered dither matrix with its cross-hatch artifacts. The matrix generation algorithm as well as its implementation was contributed by Wessel Dankers aka Fruit. The code in dither.c is his implementation, reformatted and with static global variables removed by me. The new matrix is uploaded as float texture - before this commit, it was a normal integer fixed point matrix. This means dithering will be disabled on systems without float textures. The size of the dithering matrix can be configured, as the matrix is generated at runtime. The generation of the matrix can take rather long, and is already unacceptable with size 8. The default is at 6, which takes about 100 ms on a Core2 Duo system with dither.c compiled at -O2, which I consider just about acceptable. The old ordered dithering is still available and can be selected by putting the dither=ordered sub-option. The ordered dither matrix generation code was moved to dither.c. This function was originally written by Uoti Urpala.
2013-05-25 23:48:39 +00:00
OPT_CHOICE("dither", dither_algo, 0,
vo_opengl: use enums for choice options internally This is much more readable than hard-coding magic IDs all over the file, and removes the need for all the explanatory comments that were a direct result of this.
2016-05-15 22:14:02 +00:00
({"fruit", DITHER_FRUIT},
{"ordered", DITHER_ORDERED},
{"no", DITHER_NONE})),
gl_video: improve dithering Use a different algorithm to generate the dithering matrix. This looks much better than the previous ordered dither matrix with its cross-hatch artifacts. The matrix generation algorithm as well as its implementation was contributed by Wessel Dankers aka Fruit. The code in dither.c is his implementation, reformatted and with static global variables removed by me. The new matrix is uploaded as float texture - before this commit, it was a normal integer fixed point matrix. This means dithering will be disabled on systems without float textures. The size of the dithering matrix can be configured, as the matrix is generated at runtime. The generation of the matrix can take rather long, and is already unacceptable with size 8. The default is at 6, which takes about 100 ms on a Core2 Duo system with dither.c compiled at -O2, which I consider just about acceptable. The old ordered dithering is still available and can be selected by putting the dither=ordered sub-option. The ordered dither matrix generation code was moved to dither.c. This function was originally written by Uoti Urpala.
2013-05-25 23:48:39 +00:00
OPT_INTRANGE("dither-size-fruit", dither_size, 0, 2, 8),
OPT_FLAG("temporal-dither", temporal_dither, 0),
vo_opengl: add temporal-dither-period option This was requested multiple times by users, and it's not hard to implement and/or maintain.
2015-07-20 17:09:22 +00:00
OPT_INTRANGE("temporal-dither-period", temporal_dither_period, 0, 1, 128),
options: handle choice -> flag fallback automatically In the past it happened quite often that flag options (yes/no) were changed to choice options (yes/no/some more). The problem with this was that while flag options don't need a parameter, this wasn't the case with choice options. A hack was introduced to compensate for this: setting M_OPT_OPTIONAL_PARAM on the option, and an empty string ("") was added as choice, so that the choice could be used like a flag. So, for example, "--mute" would set the choice "". Fix this by 1. not requiring a parameter if there's a "yes" choice, and 2. redirect an empty parameter to "yes". The effect is that a choice option with the choices ["yes", "no"] is pretty much equivalent to a flag option.
2015-02-27 17:31:24 +00:00
OPT_CHOICE("alpha", alpha_mode, 0,
vo_opengl: use enums for choice options internally This is much more readable than hard-coding magic IDs all over the file, and removes the need for all the explanatory comments that were a direct result of this.
2016-05-15 22:14:02 +00:00
({"no", ALPHA_NO},
{"yes", ALPHA_YES},
{"blend", ALPHA_BLEND},
{"blend-tiles", ALPHA_BLEND_TILES})),
vo_opengl: deprecate sub-options, add them as global options vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
2016-09-02 13:59:40 +00:00
OPT_FLAG("opengl-rectangle-textures", use_rectangle, 0),
vo_opengl: make background color configurable This mainly affects the black bars that are drawn if the window and video aspect ratios mismatch.
2014-12-09 20:34:01 +00:00
OPT_COLOR("background", background, 0),
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
OPT_FLAG("interpolation", interpolation, 0),
vo_opengl: replace tscale-interpolates-only with interpolation-threshold The previous approach was too naive, and can e.g. ruin playback if scheduling switches e.g. between 1 and 2 vsync per frame.
2016-01-27 20:07:17 +00:00
OPT_FLOAT("interpolation-threshold", interpolation_threshold, 0),
vo_opengl: unify blend-subtitles-res and blend-subtitles
2015-04-11 17:16:34 +00:00
OPT_CHOICE("blend-subtitles", blend_subs, 0,
vo_opengl: use enums for choice options internally This is much more readable than hard-coding magic IDs all over the file, and removes the need for all the explanatory comments that were a direct result of this.
2016-05-15 22:14:02 +00:00
({"no", BLEND_SUBS_NO},
{"yes", BLEND_SUBS_YES},
{"video", BLEND_SUBS_VIDEO})),
vo_opengl: refactor into vo_gpu This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
2017-09-14 06:04:55 +00:00
OPT_PATHLIST("glsl-shaders", user_shaders, 0),
OPT_CLI_ALIAS("glsl-shader", "glsl-shaders-append"),
vo_opengl: implement debanding (and remove source-shader) The removal of source-shader is a side effect, since this effectively replaces it - and the video-reading code has been significantly restructured to make more sense and be more readable. This means users no longer have to constantly download and maintain a separate deband.glsl installation alongside mpv, which was the only real use case for source-shader that we found either way.
2015-09-05 15:39:27 +00:00
OPT_FLAG("deband", deband, 0),
OPT_SUBSTRUCT("deband", deband_opts, deband_conf, 0),
vo_opengl: remove sharpen scalers, add sharpen sub-option This turns the old scalers (inherited from MPlayer) into a pre- processing step (after color conversion and before scaling). The code for the "sharpen5" scaler is reused for this. The main reason MPlayer implemented this as scalers was perhaps because FBOs were too expensive, and making it a scaler allowed to implement this in 1 pass. But unsharp masking is not really a scaler, and I would guess the result is more like combining bilinear scaling and unsharp masking.
2015-09-23 20:43:27 +00:00
OPT_FLOAT("sharpen", unsharp, 0),
vo_opengl: refactor into vo_gpu This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
2017-09-14 06:04:55 +00:00
OPT_INTRANGE("gpu-tex-pad-x", tex_pad_x, 0, 0, 4096),
OPT_INTRANGE("gpu-tex-pad-y", tex_pad_y, 0, 0, 4096),
vo_opengl: move all icc handling from vo_opengl.c to video.c Originally, video.c did not access any CMS things (other than lut3d being set on it), but this has changed. In practice, almost all accesses to it have moved to video.c. vo_opengl only created it, and set the auto icc profile path. Complete the move. Some things wrt. option handling are a bit fishy. (But when is this not the case.) icc-profile-auto was not tested, but the distributed human CI will take care of it.
2016-06-03 18:35:17 +00:00
OPT_SUBSTRUCT("", icc_opts, mp_icc_conf, 0),
vo_opengl: refactor into vo_gpu This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
2017-09-14 06:04:55 +00:00
OPT_STRING("gpu-shader-cache-dir", shader_cache_dir, 0),
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
OPT_STRING_VALIDATE("gpu-hwdec-interop", hwdec_interop, 0,
ra_hwdec_validate_opt),
OPT_REPLACED("opengl-hwdec-interop", "gpu-hwdec-interop"),
OPT_REPLACED("hwdec-preload", "opengl-hwdec-interop"),
vo_opengl: generalize HDR tone mapping to gamut mapping Since this code was already written for HDR, and is now per-channel (because it works better for HDR as well), we can actually reuse this to get very high quality gamut mapping without clipping. The only required change is to move the tone mapping from before the gamut map to after the gamut map. Additonally, we need to also account for changes in the signal range as a result of applying the CMS when we compute ref_peak, which is fortunately pretty easy because we only need to consider the case of primaries mapping to themselves. Since `HDR` no longer really makes sense as a label, rename it to `--tone-mapping` in general. Also fits better with `--tone-mapping-desat` etc. Arguably we could also rename `--hdr-compute-peak`, but that option is basically only useful for HDR content anyway because we don't need information about the signal range for gamut mapping. This (finally!) gives us reasonably high quality gamut mapping even in the absence of an ICC profile / 3DLUT.
2017-08-03 10:46:57 +00:00
OPT_REPLACED("hdr-tone-mapping", "tone-mapping"),
vo_opengl: refactor into vo_gpu This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
2017-09-14 06:04:55 +00:00
OPT_REPLACED("opengl-shaders", "glsl-shaders"),
options: properly handle deprecated options with CLI actions We want e.g. --opengl-shaders-append=foo to resolve to the new option, all while printing an option name. --opengl-shader is a similar case. These options are special, because they apply "actions" on actual options by specifying a suffix. So the alias/deprecation handling has to be part of resolving the actual option from prefix and suffix.
2017-09-22 09:31:03 +00:00
OPT_REPLACED("opengl-shader", "glsl-shader"),
vo_opengl: refactor into vo_gpu This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
2017-09-14 06:04:55 +00:00
OPT_REPLACED("opengl-shader-cache-dir", "gpu-shader-cache-dir"),
OPT_REPLACED("opengl-tex-pad-x", "gpu-tex-pad-x"),
OPT_REPLACED("opengl-tex-pad-y", "gpu-tex-pad-y"),
OPT_REPLACED("opengl-fbo-format", "fbo-format"),
OPT_REPLACED("opengl-dumb-mode", "gpu-dumb-mode"),
vo_gpu: fix --opengl-gamma redirect It still pointed at --gpu-gamma, but we decided on --gamma-factor instead.
2017-09-28 15:21:56 +00:00
OPT_REPLACED("opengl-gamma", "gamma-factor"),
vo_opengl: deprecate sub-options, add them as global options vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
2016-09-02 13:59:40 +00:00
{0}
},
.size = sizeof(struct gl_video_opts),
.defaults = &gl_video_opts_def,
};
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
static void uninit_rendering(struct gl_video *p);
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
static void uninit_scaler(struct gl_video *p, struct scaler *scaler);
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
static void check_gl_features(struct gl_video *p);
vo_opengl: merge uploading and rendering 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.
2017-06-29 15:09:11 +00:00
static bool pass_upload_image(struct gl_video *p, struct mp_image *mpi, uint64_t id);
vo_opengl: somewhat simplify suboption handling mess Enable m_sub_options_copy() to copy nested sub-options, and also enable it to create an option struct from defaults. We can get rid of most of the crap in assign_options() now. Calling handle_scaler_opt() to get a static allocation for scaler name is still needed. It's moved to reinit_scaler(), which seems to be a better place for it. Without it, dangling pointers could be created when options are changed. (And in fact, this fixes possible dangling pointers for window.name.) In theory we could create a dynamic copy, but that seemed even more messy. Chance of regressions.
2016-06-04 18:48:56 +00:00
static const char *handle_scaler_opt(const char *name, bool tscale);
vo_opengl: cleanup icc + runtime option changing behavior Commit 026b75e7 actually enabled changing icc options at runtime (via vo_cmdline), but it didn't quite work. In particular, changing the icc- profile option just kept the old profile, because it was cached accordingly. As part of this, change gl_lcms.opts from a struct to a pointer to a struct. We properly copy it, instead of allowing possibly dangling strings, like it was done in a working but unclean way before. Also, reinit the whole rendering chain when the auto icc profile changes, just like it's done when icc options are changed.
2016-06-04 15:52:10 +00:00
static void reinit_from_options(struct gl_video *p);
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
static void get_scale_factors(struct gl_video *p, bool transpose_rot, double xy[2]);
vo_opengl: fix/simplify reinitialization on dynamic reconfiguration With the new hooks mechanism, user shaders and such are actually loaded before rendering starts, instead of being loaded during rendering. This is used to cache them (instead of e.g. reparsing them every frame). The cached state wasn't cleared correctly in some situations. Namely, resizing didn't correctly enable/disable prescale hooks. Reorganize how these reinitializations are handled. Get rid of reinit_rendering(), whose meaning was pretty unclear. Call the required functions to reset or recreate state directly wherever they are needed.
2016-05-18 15:47:10 +00:00
static void gl_video_setup_hooks(struct gl_video *p);
vo_gpu: fix video sometimes not being rerendered on equalizer change With video paused, changing the brightness controls (or similar) would sometimes not rerender the video frame. So the OSD would redraw, but the video wouldn't change. This is caused by output caching, and a redraw request is free to return the cached frame. Change it such to invalidate the cached frame if any of the options or the equalizer change. In theory, gl_video_reset_surfaces() could be called if the equalizer changes - this would apparently force interpolatzion to redraw all frames. But this looks kind of crappy when changing the equalizer during playback. It'll "eventually" use the correct settings anyway, and when paused interpolation is off.
2017-10-17 07:07:35 +00:00
static void gl_video_update_options(struct gl_video *p);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
#define GLSL(x) gl_sc_add(p->sc, #x "\n");
#define GLSLF(...) gl_sc_addf(p->sc, __VA_ARGS__)
vo_opengl: remove redundant code
2016-02-27 22:56:33 +00:00
#define GLSLHF(...) gl_sc_haddf(p->sc, __VA_ARGS__)
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
#define PRELUDE(...) gl_sc_paddf(p->sc, __VA_ARGS__)
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
static struct bstr load_cached_file(struct gl_video *p, const char *path)
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
{
if (!path || !path[0])
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
return (struct bstr){0};
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
for (int n = 0; n < p->num_files; n++) {
if (strcmp(p->files[n].path, path) == 0)
return p->files[n].body;
}
// not found -> load it
vo_opengl: increase the size limit for cached file This is mainly for the nnedi3 user shader. With all whose NN weights hardcoded into the shader source code, the shader file could be as large as 300 kB.
2016-06-10 12:53:31 +00:00
struct bstr s = stream_read_file(path, p, p->global, 1024000); // 1024 kB
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
if (s.len) {
vo_opengl: never clear file cache Make it dynamic and never remove entries from it. For now, this is better than possibly creating dangling pointers all over the place in the gl_user_shader struct. Untested.
2016-05-16 10:46:29 +00:00
struct cached_file new = {
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
.path = talloc_strdup(p, path),
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
.body = s,
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
};
vo_opengl: never clear file cache Make it dynamic and never remove entries from it. For now, this is better than possibly creating dangling pointers all over the place in the gl_user_shader struct. Untested.
2016-05-16 10:46:29 +00:00
MP_TARRAY_APPEND(p, p->files, p->num_files, new);
return new.body;
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
}
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
return (struct bstr){0};
vo_opengl: move shader file caching to video.c It's just about loading and cachign small files, not does not necessarily have anything to do with shaders. Move it to video.c where it's used.
2015-09-23 20:13:03 +00:00
}
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
static void debug_check_gl(struct gl_video *p, const char *msg)
{
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
if (p->ra->fns->debug_marker)
p->ra->fns->debug_marker(p->ra, msg);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
static void gl_video_reset_surfaces(struct gl_video *p)
{
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
for (int i = 0; i < SURFACES_MAX; i++) {
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
p->surfaces[i].id = 0;
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
p->surfaces[i].pts = MP_NOPTS_VALUE;
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
}
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
p->surface_idx = 0;
p->surface_now = 0;
vo_opengl: fix "freezes" after seeking with interpolation on When seeking to a different position, and seeking takes long, the OSD might get redrawn. This means that the VO will receive a request to redraw an old frame using whatever the previous PTS was. This breaks the interpolation logic: the old frame will be added to the queue, and then the next frames (with lower PTS if you seeked backwards) are not drawn as the logic assumes they're past frames. Fix this by using the non-interpolation code path when redrawing after a seek reset, and no "real" frame has been drawn yet. It's a recent regression caused by the redrawing code simplification. The old code simply sent a VOCTRL for redrawing the frame, and the VO had to deal with retaining the old frame on its own. This is a hack as in there's probably a better solution. Fixes #2097.
2015-07-02 11:17:20 +00:00
p->frames_drawn = 0;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
p->output_tex_valid = false;
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
}
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
static void gl_video_reset_hooks(struct gl_video *p)
{
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
for (int i = 0; i < p->num_tex_hooks; i++)
vo_opengl: slightly refactor user_shaders code - Each struct tex_hook now stores multiple hooks, this allows us to avoid the awkward way of the current code has to add the same pass multiple times. - As a consequence, SHADER_MAX_HOOKS was split up into SHADER_MAX_PASSES (number of tex_hooks) and SHADER_MAX_HOOKS (number of hooked textures per tex_hook), and both numbers decreased correspondingly. - Instead of having a weird free() callback, we can just leverage talloc's recursive free behavior. The only user is the user shaders code anyway.
2017-07-10 20:52:39 +00:00
talloc_free(p->tex_hooks[i].priv);
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
for (int i = 0; i < p->num_user_textures; i++)
vo_opengl: manage user shader textures with ra Drops some features I guess, no idea if those were needed. Untested due to lack of test cases.
2017-07-30 09:38:52 +00:00
ra_tex_free(p->ra, &p->user_textures[i].tex);
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
p->num_tex_hooks = 0;
p->num_user_textures = 0;
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static inline int surface_wrap(int id)
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
{
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
id = id % SURFACES_MAX;
return id < 0 ? id + SURFACES_MAX : id;
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
}
vo_opengl: fix/simplify reinitialization on dynamic reconfiguration With the new hooks mechanism, user shaders and such are actually loaded before rendering starts, instead of being loaded during rendering. This is used to cache them (instead of e.g. reparsing them every frame). The cached state wasn't cleared correctly in some situations. Namely, resizing didn't correctly enable/disable prescale hooks. Reorganize how these reinitializations are handled. Get rid of reinit_rendering(), whose meaning was pretty unclear. Call the required functions to reset or recreate state directly wherever they are needed.
2016-05-18 15:47:10 +00:00
static void reinit_osd(struct gl_video *p)
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
{
vo_opengl_cb: don't render OSD while VO is not created Unlike other VOs, this rendered OSD even while no VO was created (because the renderer lives as long as the API user wants). Change this, and refactor the code so that the OSD object is accessible only while the VO is created. (There is a short time where the OSD can still be accessed even after VO destruction - this is not a race condition, though it's inelegant and unfortunately unavoidable.)
2015-03-23 15:32:59 +00:00
mpgl_osd_destroy(p->osd);
p->osd = NULL;
vo_opengl: organize ra PBO flag slightly differently Instead of having a mutable ra_tex field (and the only one), move the flag to struct ra, since we have only 2 tex_upload user calls anyway, and both want the same PBO behavior. (At first I considered making it a RA_TEX_UPLOAD_ flag, but why bother. PBOs are a terribly GL-specific thing, so we can't expect a reasonable abstraction of it anyway.)
2017-08-05 11:48:46 +00:00
if (p->osd_state)
vo_opengl: refactor tex_upload to ra_buf_pool Also refactors the usage of tex_upload to make ra_tex_upload_pbo a RA-internal thing again. ra_buf_pool has the main advantage of being dynamically sized depending on buf_poll, so for OpenGL we'll end up only using one buffer (when not persistently mapping) - while for vulkan we'll use as many as necessary, which depends on the swapchain depth anyway.
2017-08-19 02:33:40 +00:00
p->osd = mpgl_osd_init(p->ra, p->log, p->osd_state);
vo_opengl: change initialization of gamma option Make the lazy gamma initialization less weird, and make the default value of the "gamma" sub-option 1.0. This means --vo=opengl:help will list the actual default value. Also change the lower bound to 0.1 - avoids a division by zero (I don't know how shaders handle NaN, but it's probably not a good idea to give them this value).
2015-02-03 16:12:04 +00:00
}
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
static void uninit_rendering(struct gl_video *p)
{
vo_opengl: add macros for scaler units There was no real point in hard-coding these all over the place, especially since the order was sort of arbitrary and confusing.
2016-03-05 08:42:57 +00:00
for (int n = 0; n < SCALER_COUNT; n++)
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
uninit_scaler(p, &p->scaler[n]);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: manage dither texture via ra Also add some more helpers. Fix the broken math.h include statement. utils.c uses ra_gl.h internals, which it shouldn't, and which will be removed again as soon as this code gets converted to ra fully.
2017-07-29 18:14:48 +00:00
ra_tex_free(p->ra, &p->dither_texture);
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
for (int n = 0; n < 4; n++) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
ra_tex_free(p->ra, &p->merge_tex[n]);
ra_tex_free(p->ra, &p->scale_tex[n]);
ra_tex_free(p->ra, &p->integer_tex[n]);
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
ra_tex_free(p->ra, &p->indirect_tex);
ra_tex_free(p->ra, &p->blend_subs_tex);
ra_tex_free(p->ra, &p->screen_tex);
ra_tex_free(p->ra, &p->output_tex);
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
for (int n = 0; n < SURFACES_MAX; n++)
ra_tex_free(p->ra, &p->surfaces[n].tex);
vo_opengl: fix uninitialization logic The FBOs we use never actually got cleaned up anywhere, and the vimg planes were hard-coded to only clean up 3.
2015-03-13 23:32:20 +00:00
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
for (int n = 0; n < p->num_hook_textures; n++)
ra_tex_free(p->ra, &p->hook_textures[n]);
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
gl_video_reset_surfaces(p);
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
gl_video_reset_hooks(p);
vo_opengl: make the screen blue on shader errors This helps visually signify that somthing went wrong, and prevents confusing shader compilation errors with other types of bugs.
2016-05-12 09:27:00 +00:00
gl_sc_reset_error(p->sc);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
vo_opengl: minor renderer option access refactor Reduce accesses to the renderer opts in vo_opengl.c, and instead add accessors for them to video.c. I suppose gamma and maybe icc-auto could be moved to vo_opengl.c options. Also, the output colorspace could probably be adjusted to what is really used, not just the options (although it's possible that this commit changes this, due to video.c mutating its own copy of the options according to actual renderer capapbilities). But don't deal with this now.
2016-09-02 12:50:03 +00:00
bool gl_video_gamma_auto_enabled(struct gl_video *p)
{
return p->opts.gamma_auto;
}
struct mp_colorspace gl_video_get_output_colorspace(struct gl_video *p)
{
return (struct mp_colorspace) {
.primaries = p->opts.target_prim,
.gamma = p->opts.target_trc,
vo_gpu: introduce --target-peak This solves a number of problems simultaneously: 1. When outputting HLG, this allows tuning the OOTF based on the display characteristics. 2. When outputting PQ or other HDR curves, this allows soft-limiting the output brightness using the tone mapping algorithm. 3. When outputting SDR, this allows HDR-in-SDR style output, by controlling the output brightness directly. Closes #5521
2018-02-14 15:10:51 +00:00
.sig_peak = p->opts.target_peak / MP_REF_WHITE,
vo_opengl: minor renderer option access refactor Reduce accesses to the renderer opts in vo_opengl.c, and instead add accessors for them to video.c. I suppose gamma and maybe icc-auto could be moved to vo_opengl.c options. Also, the output colorspace could probably be adjusted to what is really used, not just the options (although it's possible that this commit changes this, due to video.c mutating its own copy of the options according to actual renderer capapbilities). But don't deal with this now.
2016-09-02 12:50:03 +00:00
};
}
vo_opengl: move all icc handling from vo_opengl.c to video.c Originally, video.c did not access any CMS things (other than lut3d being set on it), but this has changed. In practice, almost all accesses to it have moved to video.c. vo_opengl only created it, and set the auto icc profile path. Complete the move. Some things wrt. option handling are a bit fishy. (But when is this not the case.) icc-profile-auto was not tested, but the distributed human CI will take care of it.
2016-06-03 18:35:17 +00:00
// Warning: profile.start must point to a ta allocation, and the function
// takes over ownership.
void gl_video_set_icc_profile(struct gl_video *p, bstr icc_data)
vo_opengl: generate 3DLUT against source and use full BT.1886 This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
2016-02-13 14:33:00 +00:00
{
vo_opengl: cleanup icc + runtime option changing behavior Commit 026b75e7 actually enabled changing icc options at runtime (via vo_cmdline), but it didn't quite work. In particular, changing the icc- profile option just kept the old profile, because it was cached accordingly. As part of this, change gl_lcms.opts from a struct to a pointer to a struct. We properly copy it, instead of allowing possibly dangling strings, like it was done in a working but unclean way before. Also, reinit the whole rendering chain when the auto icc profile changes, just like it's done when icc options are changed.
2016-06-04 15:52:10 +00:00
if (gl_lcms_set_memory_profile(p->cms, icc_data))
reinit_from_options(p);
vo_opengl: generate 3DLUT against source and use full BT.1886 This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
2016-02-13 14:33:00 +00:00
}
vo_opengl: move all icc handling from vo_opengl.c to video.c Originally, video.c did not access any CMS things (other than lut3d being set on it), but this has changed. In practice, almost all accesses to it have moved to video.c. vo_opengl only created it, and set the auto icc profile path. Complete the move. Some things wrt. option handling are a bit fishy. (But when is this not the case.) icc-profile-auto was not tested, but the distributed human CI will take care of it.
2016-06-03 18:35:17 +00:00
bool gl_video_icc_auto_enabled(struct gl_video *p)
{
return p->opts.icc_opts ? p->opts.icc_opts->profile_auto : false;
}
vo_opengl: generate 3DLUT against source and use full BT.1886 This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
2016-02-13 14:33:00 +00:00
static bool gl_video_get_lut3d(struct gl_video *p, enum mp_csp_prim prim,
enum mp_csp_trc trc)
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
{
vo_opengl: remove pointless NULL-check It's never NULL.
2016-06-04 11:44:46 +00:00
if (!p->use_lut_3d)
vo_opengl: generate 3DLUT against source and use full BT.1886 This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
2016-02-13 14:33:00 +00:00
return false;
vo_opengl: runtime icc profile switching The changes in vo_opengl.c are merely for adding the icc options to the set of options than can be changed with the vo_cmdline command.
2014-03-24 22:30:12 +00:00
vo_opengl: support embedded ICC profiles This currently only works when using lcms-based color management (--icc-profile-*). In principle, we could also support using lcms even when the user has not specified an ICC profile, by generating the profile against a fixed reference (--target-prim/--target-trc) instead. I still might do that some day, simply because 3dlut provides a higher quality conversion than our simple gamut mapping does for stuff like BT.2020, and also because it's now needed to enable embedded ICC profiles. But that would be a separate change, so preserve the status quo for now. (Besides, my opinion is still that you should be using an ICC profile if you care about colors being accurate _at all_)
2017-07-25 21:17:04 +00:00
struct AVBufferRef *icc = NULL;
if (p->image.mpi)
icc = p->image.mpi->icc_profile;
if (p->lut_3d_texture && !gl_lcms_has_changed(p->cms, prim, trc, icc))
vo_opengl: generate 3DLUT against source and use full BT.1886 This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
2016-02-13 14:33:00 +00:00
return true;
vo_opengl: manage ICC LUT texture via ra Also move the capability check to gl_video_get_lut3d(), because it seems more convenient (ra won't have a _CAP_EXT16).
2017-07-29 19:22:11 +00:00
// GLES3 doesn't provide filtered 16 bit integer textures
// GLES2 doesn't even provide 3D textures
vo_opengl: use rgba16 for 3DLUTs instead of rgb16 Vulkan compat. rgb16 doesn't exist on hardware anyway, might as well just generate the 3DLUT against rgba16 as well. We've decided this is the simplest way to do vulkan compatibility: just make sure we never actually need 3-component textures.
2017-08-27 11:40:59 +00:00
const struct ra_format *fmt = ra_find_unorm_format(p->ra, 2, 4);
vo_opengl: manage ICC LUT texture via ra Also move the capability check to gl_video_get_lut3d(), because it seems more convenient (ra won't have a _CAP_EXT16).
2017-07-29 19:22:11 +00:00
if (!fmt || !(p->ra->caps & RA_CAP_TEX_3D)) {
p->use_lut_3d = false;
vo_opengl: use rgba16 for 3DLUTs instead of rgb16 Vulkan compat. rgb16 doesn't exist on hardware anyway, might as well just generate the 3DLUT against rgba16 as well. We've decided this is the simplest way to do vulkan compatibility: just make sure we never actually need 3-component textures.
2017-08-27 11:40:59 +00:00
MP_WARN(p, "Disabling color management (no RGBA16 3D textures).\n");
vo_opengl: manage ICC LUT texture via ra Also move the capability check to gl_video_get_lut3d(), because it seems more convenient (ra won't have a _CAP_EXT16).
2017-07-29 19:22:11 +00:00
return false;
}
vo_opengl: generate 3DLUT against source and use full BT.1886 This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
2016-02-13 14:33:00 +00:00
struct lut3d *lut3d = NULL;
vo_opengl: support embedded ICC profiles This currently only works when using lcms-based color management (--icc-profile-*). In principle, we could also support using lcms even when the user has not specified an ICC profile, by generating the profile against a fixed reference (--target-prim/--target-trc) instead. I still might do that some day, simply because 3dlut provides a higher quality conversion than our simple gamut mapping does for stuff like BT.2020, and also because it's now needed to enable embedded ICC profiles. But that would be a separate change, so preserve the status quo for now. (Besides, my opinion is still that you should be using an ICC profile if you care about colors being accurate _at all_)
2017-07-25 21:17:04 +00:00
if (!fmt || !gl_lcms_get_lut3d(p->cms, &lut3d, prim, trc, icc) || !lut3d) {
vo_opengl: cleanup icc + runtime option changing behavior Commit 026b75e7 actually enabled changing icc options at runtime (via vo_cmdline), but it didn't quite work. In particular, changing the icc- profile option just kept the old profile, because it was cached accordingly. As part of this, change gl_lcms.opts from a struct to a pointer to a struct. We properly copy it, instead of allowing possibly dangling strings, like it was done in a working but unclean way before. Also, reinit the whole rendering chain when the auto icc profile changes, just like it's done when icc options are changed.
2016-06-04 15:52:10 +00:00
p->use_lut_3d = false;
vo_opengl: generate 3DLUT against source and use full BT.1886 This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
2016-02-13 14:33:00 +00:00
return false;
vo_opengl: support 3D textures on ANGLE Unfortunately, color management can still not work, because no GLES version specified so far support fixed-point 16 bit textures. Maybe we could use integer textures, but these don't support filtering. Using float textures would be another possibility.
2015-11-19 20:21:04 +00:00
}
vo_opengl: don't allow setting 3D LUT if unsupported The code was always uploading the 3D LUT (even of unused), as long as vo_opengl was setting a icc-profile. This could crash with GLES 2.
2014-12-23 01:48:58 +00:00
vo_opengl: manage ICC LUT texture via ra Also move the capability check to gl_video_get_lut3d(), because it seems more convenient (ra won't have a _CAP_EXT16).
2017-07-29 19:22:11 +00:00
ra_tex_free(p->ra, &p->lut_3d_texture);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: manage ICC LUT texture via ra Also move the capability check to gl_video_get_lut3d(), because it seems more convenient (ra won't have a _CAP_EXT16).
2017-07-29 19:22:11 +00:00
struct ra_tex_params params = {
.dimensions = 3,
.w = lut3d->size[0],
.h = lut3d->size[1],
.d = lut3d->size[2],
.format = fmt,
.render_src = true,
.src_linear = true,
.initial_data = lut3d->data,
};
p->lut_3d_texture = ra_tex_create(p->ra, &params);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
debug_check_gl(p, "after 3d lut creation");
vo_opengl: runtime icc profile switching The changes in vo_opengl.c are merely for adding the icc options to the set of options than can be changed with the vo_cmdline command.
2014-03-24 22:30:12 +00:00
vo_opengl: increase 3DLUT accuracy at lower LUT sizes This code had the exact same texture indexing bug that the original scaler code had before the introduction of the LUT_POS macro to fix it. We can re-use this same macro here, and the performance drop is virtually entirely negligible. The benefit is greatly improved LUT accuracy as the 3DLUT size decreases - in particular, the old LUT started introducing more and more black crush the lower your LUT size is (because the error was essentially an over-contrast bias, with a magnitude linearly related to the lut size). The new code improves black stability as the LUT size decreases, and only at very low values (16 and below) do black levels start noticeably getting affected (due to crude linearization of the nonlinear response curve). The default value of 3dlut-size is definitely generous enough for this to make no difference out of the box, but it also causes no performance drop at all on my machine so I see no harm in improving the logic. Furthermore, this means we could easily decrease the default 3dlut size in a future commit, perhaps even down to 64x64x64 as a default. (But more testing is warranted here)
2016-07-25 08:18:41 +00:00
for (int i = 0; i < 3; i++)
p->lut_3d_size[i] = lut3d->size[i];
vo_opengl: fix giant memory leaks with icc profiles Well this was dumb.
2016-06-03 18:03:49 +00:00
talloc_free(lut3d);
vo_opengl: generate 3DLUT against source and use full BT.1886 This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
2016-02-13 14:33:00 +00:00
return true;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
// Fill an image struct from a ra_tex + some metadata
static struct image image_wrap(struct ra_tex *tex, enum plane_type type,
int components)
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
{
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
assert(type != PLANE_NONE);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
return (struct image){
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
.type = type,
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
.tex = tex,
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
.multiplier = 1.0,
vo_gpu: handle texture initialization errors gracefully Tested by making the ra_tex_resize function always fail (apart from the initial FBO check). This required a few changes: 1. reset shaders on failed dispatch 2. reset cleanup binds on failed dispatch 3. fall back to initializing the struct image to 1x1 on failure 4. handle output_fbo_valid gracefully
2017-09-23 07:54:42 +00:00
.w = tex ? tex->params.w : 1,
.h = tex ? tex->params.h : 1,
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
.transform = identity_trans,
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
.components = components,
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
};
}
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
// Bind an image to a free texture unit and return its ID.
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static int pass_bind(struct gl_video *p, struct image img)
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
{
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
int idx = p->num_pass_imgs;
MP_TARRAY_APPEND(p, p->pass_imgs, p->num_pass_imgs, img);
return idx;
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
}
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
// Rotation by 90° and flipping.
vo_opengl: attempt to fix chroma offset under rotation and flipping Other than being overly convoluted, this seems to make sense to me. Except that to get the "rot" transform I have to set flip=true, which makes no sense at all to me.
2016-10-01 14:07:51 +00:00
// w/h is used for recentering.
static void get_transform(float w, float h, int rotate, bool flip,
struct gl_transform *out_tr)
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
{
vo_opengl: attempt to fix chroma offset under rotation and flipping Other than being overly convoluted, this seems to make sense to me. Except that to get the "rot" transform I have to set flip=true, which makes no sense at all to me.
2016-10-01 14:07:51 +00:00
int a = rotate % 90 ? 0 : rotate / 90;
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
int sin90[4] = {0, 1, 0, -1}; // just to avoid rounding issues etc.
int cos90[4] = {1, 0, -1, 0};
vo_opengl: minor simplification The extra gl_transform_trans() has no apparent use.
2016-10-01 14:12:03 +00:00
struct gl_transform tr = {{{ cos90[a], sin90[a]},
{-sin90[a], cos90[a]}}};
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
// basically, recenter to keep the whole image in view
float b[2] = {1, 1};
vo_opengl: minor simplification The extra gl_transform_trans() has no apparent use.
2016-10-01 14:12:03 +00:00
gl_transform_vec(tr, &b[0], &b[1]);
vo_opengl: attempt to fix chroma offset under rotation and flipping Other than being overly convoluted, this seems to make sense to me. Except that to get the "rot" transform I have to set flip=true, which makes no sense at all to me.
2016-10-01 14:07:51 +00:00
tr.t[0] += b[0] < 0 ? w : 0;
tr.t[1] += b[1] < 0 ? h : 0;
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
vo_opengl: attempt to fix chroma offset under rotation and flipping Other than being overly convoluted, this seems to make sense to me. Except that to get the "rot" transform I have to set flip=true, which makes no sense at all to me.
2016-10-01 14:07:51 +00:00
if (flip) {
struct gl_transform fliptr = {{{1, 0}, {0, -1}}, {0, h}};
gl_transform_trans(fliptr, &tr);
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
}
*out_tr = tr;
}
vo_opengl: attempt to fix chroma offset under rotation and flipping Other than being overly convoluted, this seems to make sense to me. Except that to get the "rot" transform I have to set flip=true, which makes no sense at all to me.
2016-10-01 14:07:51 +00:00
// Return the chroma plane upscaled to luma size, but with additional padding
// for image sizes not aligned to subsampling.
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
static int chroma_upsize(int size, int pixel)
vo_opengl: attempt to fix chroma offset under rotation and flipping Other than being overly convoluted, this seems to make sense to me. Except that to get the "rot" transform I have to set flip=true, which makes no sense at all to me.
2016-10-01 14:07:51 +00:00
{
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
return (size + pixel - 1) / pixel * pixel;
vo_opengl: attempt to fix chroma offset under rotation and flipping Other than being overly convoluted, this seems to make sense to me. Except that to get the "rot" transform I have to set flip=true, which makes no sense at all to me.
2016-10-01 14:07:51 +00:00
}
vo_opengl: don't make assumptions about plane order 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.
2017-07-10 15:56:43 +00:00
// If a and b are on the same plane, return what plane type should be used.
// If a or b are none, the other type always wins.
// Usually: LUMA/RGB/XYZ > CHROMA > ALPHA
static enum plane_type merge_plane_types(enum plane_type a, enum plane_type b)
{
if (a == PLANE_NONE)
return b;
if (b == PLANE_LUMA || b == PLANE_RGB || b == PLANE_XYZ)
return b;
if (b != PLANE_NONE && a == PLANE_ALPHA)
return b;
return a;
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
// Places a video_image's image textures + associated metadata into img[]. The
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
// number of textures is equal to p->plane_count. Any necessary plane offsets
// are stored in off. (e.g. chroma position)
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static void pass_get_images(struct gl_video *p, struct video_image *vimg,
struct image img[4], struct gl_transform off[4])
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
{
vo_opengl: simplify screenshot code Instead of reading back the image from textures, keep a reference to the original image, and return that. The main reason this was done this way was that originally, images weren't refcounted, and would be deallocated or overwritten as soon as the VO's draw call returned. But now there isn't really a good reason for this anymore. One possibly _could_ argue that it was better because other code could reuse the image sooner (e.g. for the cache), but on the other hand, the VO runs already on a different thread, and filtering and decoding each run on other threads too, so this argument probably wouldn't hold up.
2015-01-22 17:29:37 +00:00
assert(vimg->mpi);
vo_opengl: attempt to fix chroma offset under rotation and flipping Other than being overly convoluted, this seems to make sense to me. Except that to get the "rot" transform I have to set flip=true, which makes no sense at all to me.
2016-10-01 14:07:51 +00:00
int w = p->image_params.w;
int h = p->image_params.h;
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
// Determine the chroma offset
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
float ls_w = 1.0 / p->ra_format.chroma_w;
float ls_h = 1.0 / p->ra_format.chroma_h;
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
struct gl_transform chroma = {{{ls_w, 0.0}, {0.0, ls_h}}};
vo_opengl: remove chroma-location suboption Terribly obscure, and vf_format can do this for all VOs.
2015-04-02 21:59:50 +00:00
if (p->image_params.chroma_location != MP_CHROMA_CENTER) {
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
int cx, cy;
vo_opengl: remove chroma-location suboption Terribly obscure, and vf_format can do this for all VOs.
2015-04-02 21:59:50 +00:00
mp_get_chroma_location(p->image_params.chroma_location, &cx, &cy);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
// By default texture coordinates are such that chroma is centered with
// any chroma subsampling. If a specific direction is given, make it
// so that the luma and chroma sample line up exactly.
// For 4:4:4, setting chroma location should have no effect at all.
// luma sample size (in chroma coord. space)
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
chroma.t[0] = ls_w < 1 ? ls_w * -cx / 2 : 0;
chroma.t[1] = ls_h < 1 ? ls_h * -cy / 2 : 0;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
}
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
int msb_valid_bits =
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
p->ra_format.component_bits + MPMIN(p->ra_format.component_pad, 0);
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
// The existing code assumes we just have a single tex multiplier for
// all of the planes. This may change in the future
mp_image: split colorimetry metadata into its own struct This has two reasons: 1. I tend to add new fields to this metadata, and every time I've done so I've consistently forgotten to update all of the dozens of places in which this colorimetry metadata might end up getting used. While most usages don't really care about most of the metadata, sometimes the intend was simply to “copy” the colorimetry metadata from one struct to another. With this being inside a substruct, those lines of code can now simply read a.color = b.color without having to care about added or removed fields. 2. It makes the type definitions nicer for upcoming refactors. In going through all of the usages, I also expanded a few where I felt that omitting the “young” fields was a bug.
2016-06-29 07:16:13 +00:00
float tex_mul = 1.0 / mp_get_csp_mul(p->image_params.color.space,
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
msb_valid_bits,
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
p->ra_format.component_bits);
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
memset(img, 0, 4 * sizeof(img[0]));
vo_opengl: increase the number of video buffers Also the size is now a simple #define that can easily be changed later. This is done for smoothmotion, which might want to blend more than 4 frames at once, depending on the setting.
2015-03-13 12:42:05 +00:00
for (int n = 0; n < p->plane_count; n++) {
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
struct texplane *t = &vimg->planes[n];
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
vo_opengl: don't make assumptions about plane order 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.
2017-07-10 15:56:43 +00:00
enum plane_type type = PLANE_NONE;
for (int i = 0; i < 4; i++) {
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
int c = p->ra_format.components[n][i];
vo_opengl: don't make assumptions about plane order 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.
2017-07-10 15:56:43 +00:00
enum plane_type ctype;
if (c == 0) {
ctype = PLANE_NONE;
} else if (c == 4) {
ctype = PLANE_ALPHA;
} else if (p->image_params.color.space == MP_CSP_RGB) {
ctype = PLANE_RGB;
} else if (p->image_params.color.space == MP_CSP_XYZ) {
ctype = PLANE_XYZ;
} else {
ctype = c == 1 ? PLANE_LUMA : PLANE_CHROMA;
}
type = merge_plane_types(type, ctype);
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
img[n] = (struct image){
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
.type = type,
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
.tex = t->tex,
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
.multiplier = tex_mul,
vo_opengl: don't distinguish "real" and texture size This is from times when we supported padded/non-NPOT textures. The difference is not useful anymore, and theoretical support for different sizes is most likely buggy and unmaintained. So remove it. Also remove the tex_ prefix wherever it appears.
2015-09-02 10:52:11 +00:00
.w = t->w,
.h = t->h,
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
};
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
for (int i = 0; i < 4; i++)
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
img[n].components += !!p->ra_format.components[n][i];
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
vo_opengl: attempt to fix chroma offset under rotation and flipping Other than being overly convoluted, this seems to make sense to me. Except that to get the "rot" transform I have to set flip=true, which makes no sense at all to me.
2016-10-01 14:07:51 +00:00
get_transform(t->w, t->h, p->image_params.rotate, t->flipped,
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
&img[n].transform);
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
if (p->image_params.rotate % 180 == 90)
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
MPSWAP(int, img[n].w, img[n].h);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
vo_opengl: attempt to fix chroma offset under rotation and flipping Other than being overly convoluted, this seems to make sense to me. Except that to get the "rot" transform I have to set flip=true, which makes no sense at all to me.
2016-10-01 14:07:51 +00:00
off[n] = identity_trans;
if (type == PLANE_CHROMA) {
struct gl_transform rot;
get_transform(0, 0, p->image_params.rotate, true, &rot);
struct gl_transform tr = chroma;
gl_transform_vec(rot, &tr.t[0], &tr.t[1]);
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
float dx = (chroma_upsize(w, p->ra_format.chroma_w) - w) * ls_w;
float dy = (chroma_upsize(h, p->ra_format.chroma_h) - h) * ls_h;
vo_opengl: attempt to fix chroma offset under rotation and flipping Other than being overly convoluted, this seems to make sense to me. Except that to get the "rot" transform I have to set flip=true, which makes no sense at all to me.
2016-10-01 14:07:51 +00:00
// Adjust the chroma offset if the real chroma size is fractional
// due image sizes not aligned to chroma subsampling.
struct gl_transform rot2;
get_transform(0, 0, p->image_params.rotate, t->flipped, &rot2);
if (rot2.m[0][0] < 0)
tr.t[0] += dx;
if (rot2.m[1][0] < 0)
tr.t[0] += dy;
if (rot2.m[0][1] < 0)
tr.t[1] += dx;
if (rot2.m[1][1] < 0)
tr.t[1] += dy;
off[n] = tr;
}
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
}
}
vo_opengl: restructure format setup 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.
2017-06-30 14:57:17 +00:00
// Return the index of the given component (assuming all non-padding components
// of all planes are concatenated into a linear list).
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
static int find_comp(struct ra_imgfmt_desc *desc, int component)
vo_opengl: restructure format setup 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.
2017-06-30 14:57:17 +00:00
{
int cur = 0;
for (int n = 0; n < desc->num_planes; n++) {
for (int i = 0; i < 4; i++) {
if (desc->components[n][i]) {
if (desc->components[n][i] == component)
return cur;
cur++;
}
}
}
return -1;
}
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
static void init_video(struct gl_video *p)
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
{
vo_opengl: restructure format setup 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.
2017-06-30 14:57:17 +00:00
p->use_integer_conversion = false;
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
struct ra_hwdec *hwdec = NULL;
for (int n = 0; n < p->num_hwdecs; n++) {
if (ra_hwdec_test_format(p->hwdecs[n], p->image_params.imgfmt)) {
hwdec = p->hwdecs[n];
break;
}
}
if (hwdec) {
if (hwdec->driver->overlay_frame) {
vo_opengl: fix overlay mode (again) Did I mention yet that I regret this overlay mode thing?
2017-08-30 10:19:32 +00:00
MP_WARN(p, "Using HW-overlay mode. No GL filtering is performed "
"on the video!\n");
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
p->hwdec_overlay = hwdec;
vo_opengl: fix overlay mode (again) Did I mention yet that I regret this overlay mode thing?
2017-08-30 10:19:32 +00:00
} else {
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
p->hwdec_mapper = ra_hwdec_mapper_create(hwdec, &p->image_params);
vo_opengl: fix overlay mode (again) Did I mention yet that I regret this overlay mode thing?
2017-08-30 10:19:32 +00:00
if (!p->hwdec_mapper)
MP_ERR(p, "Initializing texture for hardware decoding failed.\n");
}
vo_opengl: separate hwdec context and mapping, port it to use ra This does two separate rather intrusive things: 1. Make the hwdec context (which does initialization, provides the device to the decoder, and other basic state) and frame mapping (getting textures from a mp_image) separate. This is more flexible, and you could map multiple images at once. It will help removing some hwdec special-casing from video.c. 2. Switch all hwdec API use to ra. Of course all code is still GL specific, but in theory it would be possible to support other backends. The most important change is that the hwdec interop returns ra objects, instead of anything GL specific. This removes the last dependency on GL-specific header files from video.c. I'm mixing these separate changes because both requires essentially rewriting all the glue code, so better do them at once. For the same reason, this change isn't done incrementally. hwdec_ios.m is untested, since I can't test it. Apart from superficial mistakes, this also requires dealing with Apple's texture format fuckups: they force you to use GL_LUMINANCE[_ALPHA] instead of GL_RED and GL_RG. We also need to report the correct format via ra_tex to the renderer, which is done by find_la_variant(). It's unknown whether this works correctly. hwdec_rpi.c as well as vo_rpi.c are still broken. (I need to pull my RPI out of a dusty pile of devices and cables, so, later.)
2017-08-10 15:48:33 +00:00
if (p->hwdec_mapper)
p->image_params = p->hwdec_mapper->dst_params;
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
const char **exts = hwdec->glsl_extensions;
vo_opengl: d3d11egl: enable "required" GLSL extensions ANGLE doesn't handle this very strictly. But if they change this in the future, it shouldn't brick us. Not quite happy with this glsl_extensions fields, but it is quite unintrusive after all.
2016-05-19 10:02:08 +00:00
for (int n = 0; exts && exts[n]; n++)
gl_sc_enable_extension(p->sc, (char *)exts[n]);
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
p->hwdec_active = true;
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
}
vo_opengl: add support for rectangle textures This allows vo_opengl to use GL_TEXTURE_RECTANGLE textures, either by enabling it with the 'rectangle-textures' sub-option, or by having a hwdec backend force it. By default it's off. The _only_ reason we're adding this is because VDA can export rectangle textures only.
2013-12-01 22:39:13 +00:00
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
p->ra_format = (struct ra_imgfmt_desc){0};
ra_get_imgfmt_desc(p->ra, p->image_params.imgfmt, &p->ra_format);
vo_opengl: restructure format setup 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.
2017-06-30 14:57:17 +00:00
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
p->plane_count = p->ra_format.num_planes;
vo_opengl: restructure format setup 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.
2017-06-30 14:57:17 +00:00
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
p->has_alpha = false;
p->is_gray = true;
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
for (int n = 0; n < p->ra_format.num_planes; n++) {
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
for (int i = 0; i < 4; i++) {
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
if (p->ra_format.components[n][i]) {
p->has_alpha |= p->ra_format.components[n][i] == 4;
p->is_gray &= p->ra_format.components[n][i] == 1 ||
p->ra_format.components[n][i] == 4;
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
}
}
}
vo_opengl: restructure format setup 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.
2017-06-30 14:57:17 +00:00
for (int c = 0; c < 4; c++) {
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
int loc = find_comp(&p->ra_format, c + 1);
vo_opengl: restructure format setup 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.
2017-06-30 14:57:17 +00:00
p->color_swizzle[c] = "rgba"[loc >= 0 && loc < 4 ? loc : 0];
}
p->color_swizzle[4] = '\0';
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
mp_image_params_guess_csp(&p->image_params);
vo_opengl: add support for rectangle textures This allows vo_opengl to use GL_TEXTURE_RECTANGLE textures, either by enabling it with the 'rectangle-textures' sub-option, or by having a hwdec backend force it. By default it's off. The _only_ reason we're adding this is because VDA can export rectangle textures only.
2013-12-01 22:39:13 +00:00
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
av_lfg_init(&p->lfg, 1);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
debug_check_gl(p, "before video texture creation");
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
if (!p->hwdec_active) {
struct video_image *vimg = &p->image;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
struct mp_image layout = {0};
mp_image_set_params(&layout, &p->image_params);
for (int n = 0; n < p->plane_count; n++) {
struct texplane *plane = &vimg->planes[n];
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
const struct ra_format *format = p->ra_format.planes[n];
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
vo_opengl: add debugging options for testing with padded textures
2016-10-01 10:01:57 +00:00
plane->w = mp_image_plane_w(&layout, n);
plane->h = mp_image_plane_h(&layout, n);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
struct ra_tex_params params = {
.dimensions = 2,
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
.w = plane->w + p->opts.tex_pad_x,
.h = plane->h + p->opts.tex_pad_y,
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
.d = 1,
.format = format,
vo_opengl: move shader handling to ra Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
2017-08-05 12:20:14 +00:00
.render_src = true,
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
.src_linear = format->linear_filter,
.non_normalized = p->opts.use_rectangle,
vo_opengl: refactor RA texture and buffer updates - tex_uploads args are moved to a struct - the ability to directly upload texture data without going through a buffer is made explicit - the concept of buffer updates and buffer polling is made more explicit and generalized to buf_update as well (not just mapped buffers) - the ability to call tex_upload/buf_update on a tex/buf is made explicit during tex/buf creation - uploading from buffers now uses an explicit offset instead of implicitly comparing *src against buf->data, because not all buffers may actually be persistently mapped - the initial_data = immutable requirement is dropped. (May be re-added later for D3D11 if that ever becomes a thing) This change helps the vulkan abstraction immensely and also helps move common code (like the PBO pooling) out of ra_gl and into the opengl/utils.c This also technically has the side-benefit / side-constraint of using PBOs for OSD texture uploads as well, which actually seems to help performance on machines where --opengl-pbo is faster than the naive code path. Because of this, I decided to hook up the OSD code to the opengl-pbo option as well. One drawback of this refactor is that the GL_STREAM_COPY hack for texture uploads "got lost", but I think I'm happy with that going away anyway since DR almost fully deprecates it, and it's not the "right thing" anyway - but instead an nvidia-only hack to make this stuff work somewhat better on NUMA systems with discrete GPUs. Another change is that due to the way fencing works with ra_buf (we get one fence per ra_buf per upload) we have to use multiple ra_bufs instead of offsets into a shared buffer. But for OpenGL this is probably better anyway. It's possible that in future, we could support having independent “buffer slices” (each with their own fence/sync object), but this would be an optimization more than anything. I also think that we could address the underlying problem (memory closeness) differently by making the ra_vk memory allocator smart enough to chunk together allocations under the hood.
2017-08-16 20:13:51 +00:00
.host_mutable = true,
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
};
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
MP_VERBOSE(p, "Texture for plane %d: %dx%d\n", n,
params.w, params.h);
gl_video: make it possible for planes to have different formats Preparation for NV12 support. Also adds support for IMGFMT_YA8.
2013-03-28 19:48:53 +00:00
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
plane->tex = ra_tex_create(p->ra, &params);
if (!plane->tex)
abort(); // shit happens
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
p->use_integer_conversion |= format->ctype == RA_CTYPE_UINT;
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
}
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
debug_check_gl(p, "after video texture creation");
vo_gpu: fix broken 10 bit via integer textures playback The check_gl_features(p) call here checks whether dumb mode can be used. It uses the field use_integer_conversion, which is set _after_ the call in the same function. Move check_gl_features() to the end of the function, when use_integer_conversion is finally set. Fixes that it tried to use bilinear filtering with integer textures. The bug disabled the code that is supposed to convert it to non-integer textures.
2018-01-17 10:09:03 +00:00
// Format-dependent checks.
check_gl_features(p);
vo_opengl: fix/simplify reinitialization on dynamic reconfiguration With the new hooks mechanism, user shaders and such are actually loaded before rendering starts, instead of being loaded during rendering. This is used to cache them (instead of e.g. reparsing them every frame). The cached state wasn't cleared correctly in some situations. Namely, resizing didn't correctly enable/disable prescale hooks. Reorganize how these reinitializations are handled. Get rid of reinit_rendering(), whose meaning was pretty unclear. Call the required functions to reset or recreate state directly wherever they are needed.
2016-05-18 15:47:10 +00:00
gl_video_setup_hooks(p);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
static struct dr_buffer *gl_find_dr_buffer(struct gl_video *p, uint8_t *ptr)
{
for (int i = 0; i < p->num_dr_buffers; i++) {
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
struct dr_buffer *buffer = &p->dr_buffers[i];
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
uint8_t *bufptr = buffer->buf->data;
size_t size = buffer->buf->params.size;
if (ptr >= bufptr && ptr < bufptr + size)
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
return buffer;
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
}
return NULL;
}
static void gc_pending_dr_fences(struct gl_video *p, bool force)
{
again:;
for (int n = 0; n < p->num_dr_buffers; n++) {
struct dr_buffer *buffer = &p->dr_buffers[n];
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
if (!buffer->mpi)
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
continue;
vo_opengl: refactor RA texture and buffer updates - tex_uploads args are moved to a struct - the ability to directly upload texture data without going through a buffer is made explicit - the concept of buffer updates and buffer polling is made more explicit and generalized to buf_update as well (not just mapped buffers) - the ability to call tex_upload/buf_update on a tex/buf is made explicit during tex/buf creation - uploading from buffers now uses an explicit offset instead of implicitly comparing *src against buf->data, because not all buffers may actually be persistently mapped - the initial_data = immutable requirement is dropped. (May be re-added later for D3D11 if that ever becomes a thing) This change helps the vulkan abstraction immensely and also helps move common code (like the PBO pooling) out of ra_gl and into the opengl/utils.c This also technically has the side-benefit / side-constraint of using PBOs for OSD texture uploads as well, which actually seems to help performance on machines where --opengl-pbo is faster than the naive code path. Because of this, I decided to hook up the OSD code to the opengl-pbo option as well. One drawback of this refactor is that the GL_STREAM_COPY hack for texture uploads "got lost", but I think I'm happy with that going away anyway since DR almost fully deprecates it, and it's not the "right thing" anyway - but instead an nvidia-only hack to make this stuff work somewhat better on NUMA systems with discrete GPUs. Another change is that due to the way fencing works with ra_buf (we get one fence per ra_buf per upload) we have to use multiple ra_bufs instead of offsets into a shared buffer. But for OpenGL this is probably better anyway. It's possible that in future, we could support having independent “buffer slices” (each with their own fence/sync object), but this would be an optimization more than anything. I also think that we could address the underlying problem (memory closeness) differently by making the ra_vk memory allocator smart enough to chunk together allocations under the hood.
2017-08-16 20:13:51 +00:00
bool res = p->ra->fns->buf_poll(p->ra, buffer->buf);
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
if (res || force) {
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
// Unreferencing the image could cause gl_video_dr_free_buffer()
// to be called by the talloc destructor (if it was the last
// reference). This will implicitly invalidate the buffer pointer
// and change the p->dr_buffers array. To make it worse, it could
// free multiple dr_buffers due to weird theoretical corner cases.
// This is also why we use the goto to iterate again from the
// start, because everything gets fucked up. Hail satan!
struct mp_image *ref = buffer->mpi;
buffer->mpi = NULL;
talloc_free(ref);
goto again;
}
}
}
vo_opengl: unmap hwdec images once rendering is done Instead of keeping them for a while. While keeping the mapping was perfectly ok, nothing speaks against reducing the time they're mapped.
2016-06-20 11:57:46 +00:00
static void unref_current_image(struct gl_video *p)
{
vo_gpu: don't re-render hwdec frames when repeating frames Repeating frames (for display-sync) is not supposed to render the entire frame again. When using hardware decoding, it unfortunately did: the renderer uses the frame ID to check whether the frame data changed, and unmapping the hwdec frame clears it. Essentially reverts commit 761eeacf5407cab07. Back then I probably thought it would be a good idea to release the hwdec image quickly in order to return it to the decoder, but they're referenced anyway. This should increase the performance and reduce GPU work.
2017-11-03 14:11:14 +00:00
struct video_image *vimg = &p->image;
if (vimg->hwdec_mapped) {
assert(p->hwdec_active && p->hwdec_mapper);
ra_hwdec_mapper_unmap(p->hwdec_mapper);
memset(vimg->planes, 0, sizeof(vimg->planes));
vimg->hwdec_mapped = false;
}
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
vo_gpu: don't re-render hwdec frames when repeating frames Repeating frames (for display-sync) is not supposed to render the entire frame again. When using hardware decoding, it unfortunately did: the renderer uses the frame ID to check whether the frame data changed, and unmapping the hwdec frame clears it. Essentially reverts commit 761eeacf5407cab07. Back then I probably thought it would be a good idea to release the hwdec image quickly in order to return it to the decoder, but they're referenced anyway. This should increase the performance and reduce GPU work.
2017-11-03 14:11:14 +00:00
vimg->id = 0;
mp_image_unrefp(&vimg->mpi);
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
// While we're at it, also garbage collect pending fences in here to
// get it out of the way.
gc_pending_dr_fences(p, false);
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
}
vo_opengl: another attempt at removing the overlay correctly 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.
2017-05-02 15:09:16 +00:00
// If overlay mode is used, make sure to remove the overlay.
// Be careful with this. Removing the overlay and adding another one will
// lead to flickering artifacts.
static void unmap_overlay(struct gl_video *p)
{
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
if (p->hwdec_overlay)
p->hwdec_overlay->driver->overlay_frame(p->hwdec_overlay, NULL, NULL, NULL, true);
vo_opengl: another attempt at removing the overlay correctly 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.
2017-05-02 15:09:16 +00:00
}
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
static void uninit_video(struct gl_video *p)
{
uninit_rendering(p);
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
struct video_image *vimg = &p->image;
vo_opengl: another attempt at removing the overlay correctly 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.
2017-05-02 15:09:16 +00:00
unmap_overlay(p);
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
unref_current_image(p);
vo_opengl: fix uninitialization logic The FBOs we use never actually got cleaned up anywhere, and the vimg planes were hard-coded to only clean up 3.
2015-03-13 23:32:20 +00:00
for (int n = 0; n < p->plane_count; n++) {
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
struct texplane *plane = &vimg->planes[n];
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
ra_tex_free(p->ra, &plane->tex);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
*vimg = (struct video_image){0};
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
gl_video.c: invalidate image_params in uninit_video() When the given mp_image_params does not match with that of gl_video, gl_video_config() always calls uninit_video() but calls init_video() only if valid format is given. Since uninit_video() does not change image_params of gl_video, when the same params as the previous one is given to gl_video_config() after gl_video is unitialized with invalid format, gl_video_config() never calls init_video(). To prevent this, invalidate image_params of gl_video in uninit_video().
2015-01-07 18:00:26 +00:00
// Invalidate image_params to ensure that gl_video_config() will call
// init_video() on uninitialized gl_video.
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
p->real_image_params = (struct mp_image_params){0};
p->image_params = p->real_image_params;
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
p->hwdec_active = false;
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
p->hwdec_overlay = NULL;
vo_opengl: separate hwdec context and mapping, port it to use ra This does two separate rather intrusive things: 1. Make the hwdec context (which does initialization, provides the device to the decoder, and other basic state) and frame mapping (getting textures from a mp_image) separate. This is more flexible, and you could map multiple images at once. It will help removing some hwdec special-casing from video.c. 2. Switch all hwdec API use to ra. Of course all code is still GL specific, but in theory it would be possible to support other backends. The most important change is that the hwdec interop returns ra objects, instead of anything GL specific. This removes the last dependency on GL-specific header files from video.c. I'm mixing these separate changes because both requires essentially rewriting all the glue code, so better do them at once. For the same reason, this change isn't done incrementally. hwdec_ios.m is untested, since I can't test it. Apart from superficial mistakes, this also requires dealing with Apple's texture format fuckups: they force you to use GL_LUMINANCE[_ALPHA] instead of GL_RED and GL_RG. We also need to report the correct format via ra_tex to the renderer, which is done by find_la_variant(). It's unknown whether this works correctly. hwdec_rpi.c as well as vo_rpi.c are still broken. (I need to pull my RPI out of a dusty pile of devices and cables, so, later.)
2017-08-10 15:48:33 +00:00
ra_hwdec_mapper_free(&p->hwdec_mapper);
video: fix crash with vdpau when reinitializing rendering Using vdpau will allocate additional textures for the reinterleaving step, which uninit_rendering() will free. This is a problem because the hwdec image remains mapped when reinitializing, so the reinterleaving textures are turned into dangling pointers. Fix this by freeing the reinterleave textures on full uninit instead. Fixes #5447.
2018-01-26 23:31:14 +00:00
for (int n = 0; n < 2; n++)
ra_tex_free(p->ra, &p->vdpau_deinterleave_tex[n]);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
static void pass_record(struct gl_video *p, struct mp_pass_perf perf)
{
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
if (!p->pass || p->pass_idx == VO_PASS_PERF_MAX)
vo_opengl: make the pass info mechanism more robust - 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.
2017-07-03 14:59:38 +00:00
return;
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
struct pass_info *pass = &p->pass[p->pass_idx];
pass->perf = perf;
if (pass->desc.len == 0)
bstr_xappend(p, &pass->desc, bstr0("(unknown)"));
p->pass_idx++;
}
vo_opengl: add printf format checking to pass_describe()
2017-07-22 20:08:23 +00:00
PRINTF_ATTRIBUTE(2, 3)
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
static void pass_describe(struct gl_video *p, const char *textf, ...)
{
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
if (!p->pass || p->pass_idx == VO_PASS_PERF_MAX)
vo_opengl: make the pass info mechanism more robust - 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.
2017-07-03 14:59:38 +00:00
return;
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
struct pass_info *pass = &p->pass[p->pass_idx];
if (pass->desc.len > 0)
bstr_xappend(p, &pass->desc, bstr0(" + "));
va_list ap;
va_start(ap, textf);
bstr_xappend_vasprintf(p, &pass->desc, textf, ap);
va_end(ap);
}
static void pass_info_reset(struct gl_video *p, bool is_redraw)
{
p->pass = is_redraw ? p->pass_redraw : p->pass_fresh;
p->pass_idx = 0;
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
for (int i = 0; i < VO_PASS_PERF_MAX; i++) {
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
p->pass[i].desc.len = 0;
p->pass[i].perf = (struct mp_pass_perf){0};
}
}
vo_opengl: make the pass info mechanism more robust - 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.
2017-07-03 14:59:38 +00:00
static void pass_report_performance(struct gl_video *p)
{
if (!p->pass)
return;
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
for (int i = 0; i < VO_PASS_PERF_MAX; i++) {
vo_opengl: make the pass info mechanism more robust - 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.
2017-07-03 14:59:38 +00:00
struct pass_info *pass = &p->pass[i];
if (pass->desc.len) {
msg: reinterpret a bunch of message levels I've decided that MP_TRACE means “noisy spam per frame”, whereas MP_DBG just means “more verbose debugging messages than MSGL_V”. Basically, MSGL_DBG shouldn't create spam per frame like it currently does, and MSGL_V should make sense to the end-user and provide mostly additional informational output. MP_DBG is basically what I want to make the new default for --log-file, so the cut-off point for MP_DBG is if we probably want to know if for debugging purposes but the user most likely doesn't care about on the terminal. Also, the debug callbacks for libass and ffmpeg got bumped in their verbosity levels slightly, because being external components they're a bit less relevant to mpv debugging, and a bit too over-eager in what they consider to be relevant information. I exclusively used the "try it on my machine and remove messages from MSGL_* until it does what I want it to" approach of refactoring, so YMMV.
2017-09-28 09:53:57 +00:00
MP_TRACE(p, "pass '%.*s': last %dus avg %dus peak %dus\n",
BSTR_P(pass->desc),
(int)pass->perf.last/1000,
(int)pass->perf.avg/1000,
(int)pass->perf.peak/1000);
vo_opengl: make the pass info mechanism more robust - 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.
2017-07-03 14:59:38 +00:00
}
}
}
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
static void pass_prepare_src_tex(struct gl_video *p)
gl_video: improve dithering Use a different algorithm to generate the dithering matrix. This looks much better than the previous ordered dither matrix with its cross-hatch artifacts. The matrix generation algorithm as well as its implementation was contributed by Wessel Dankers aka Fruit. The code in dither.c is his implementation, reformatted and with static global variables removed by me. The new matrix is uploaded as float texture - before this commit, it was a normal integer fixed point matrix. This means dithering will be disabled on systems without float textures. The size of the dithering matrix can be configured, as the matrix is generated at runtime. The generation of the matrix can take rather long, and is already unacceptable with size 8. The default is at 6, which takes about 100 ms on a Core2 Duo system with dither.c compiled at -O2, which I consider just about acceptable. The old ordered dithering is still available and can be selected by putting the dither=ordered sub-option. The ordered dither matrix generation code was moved to dither.c. This function was originally written by Uoti Urpala.
2013-05-25 23:48:39 +00:00
{
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
struct gl_shader_cache *sc = p->sc;
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
for (int n = 0; n < p->num_pass_imgs; n++) {
struct image *s = &p->pass_imgs[n];
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
if (!s->tex)
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
continue;
common, vo_opengl: add/use helper for formatted strings on the stack 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.
2017-07-24 06:07:32 +00:00
char *texture_name = mp_tprintf(32, "texture%d", n);
char *texture_size = mp_tprintf(32, "texture_size%d", n);
char *texture_rot = mp_tprintf(32, "texture_rot%d", n);
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
char *texture_off = mp_tprintf(32, "texture_off%d", n);
common, vo_opengl: add/use helper for formatted strings on the stack 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.
2017-07-24 06:07:32 +00:00
char *pixel_size = mp_tprintf(32, "pixel_size%d", n);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
gl_sc_uniform_texture(sc, texture_name, s->tex);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
float f[2] = {1, 1};
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
if (!s->tex->params.non_normalized) {
f[0] = s->tex->params.w;
f[1] = s->tex->params.h;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
}
gl_sc_uniform_vec2(sc, texture_size, f);
vo_opengl: abstract hook texture access behind macro This macro takes care of rotation, swizzling, integer conversion and normalization automatically. I found the performance impact to be nonexistant for superxbr and debanding, although rotation *did* have an impact due to the extra matrix multiplication. (So it gets skipped where possible) All of the internal hooks have been rewritten to use this new mechanism, and the prescaler hooks have finally been separated from each other. This also means the prescale FBO kludge is no longer required. This fixes image corruption for image formats like 0bgr, and also fixes prescaling under rotation. (As well as other user hooks that have orientation-dependent access) The "raw" attributes (tex, tex_pos, pixel_size) are still un-rotated, in case something needs them, but ideally the hooks should be rewritten to use the new API as much as possible. The hooked texture has been renamed from just NAME to NAME_raw to make script authors notice the change (and also deemphasize direct texture access). This is also a step towards getting rid of the use_integer pass.
2016-05-14 05:05:04 +00:00
gl_sc_uniform_mat2(sc, texture_rot, true, (float *)s->transform.m);
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
gl_sc_uniform_vec2(sc, texture_off, (float *)s->transform.t);
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
gl_sc_uniform_vec2(sc, pixel_size, (float[]){1.0f / f[0],
1.0f / f[1]});
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
}
}
gl_video: improve dithering Use a different algorithm to generate the dithering matrix. This looks much better than the previous ordered dither matrix with its cross-hatch artifacts. The matrix generation algorithm as well as its implementation was contributed by Wessel Dankers aka Fruit. The code in dither.c is his implementation, reformatted and with static global variables removed by me. The new matrix is uploaded as float texture - before this commit, it was a normal integer fixed point matrix. This means dithering will be disabled on systems without float textures. The size of the dithering matrix can be configured, as the matrix is generated at runtime. The generation of the matrix can take rather long, and is already unacceptable with size 8. The default is at 6, which takes about 100 ms on a Core2 Duo system with dither.c compiled at -O2, which I consider just about acceptable. The old ordered dithering is still available and can be selected by putting the dither=ordered sub-option. The ordered dither matrix generation code was moved to dither.c. This function was originally written by Uoti Urpala.
2013-05-25 23:48:39 +00:00
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
static void cleanup_binds(struct gl_video *p)
{
p->num_pass_imgs = 0;
}
vo_opengl: make compute shaders more flexible This allows users to do their own custom sample writing, mainly meant to address use cases such as RAVU. Also clean up the compute shader code a bit.
2017-07-29 18:41:50 +00:00
// Sets the appropriate compute shader metadata for an implicit compute pass
// bw/bh: block size
static void pass_is_compute(struct gl_video *p, int bw, int bh)
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
{
vo_opengl: make compute shaders more flexible This allows users to do their own custom sample writing, mainly meant to address use cases such as RAVU. Also clean up the compute shader code a bit.
2017-07-29 18:41:50 +00:00
p->pass_compute = (struct compute_info){
.active = true,
.block_w = bw,
.block_h = bh,
};
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
}
// w/h: the width/height of the compute shader's operating domain (e.g. the
// target target that needs to be written, or the source texture that needs to
// be reduced)
vo_opengl: make compute shaders more flexible This allows users to do their own custom sample writing, mainly meant to address use cases such as RAVU. Also clean up the compute shader code a bit.
2017-07-29 18:41:50 +00:00
static void dispatch_compute(struct gl_video *p, int w, int h,
struct compute_info info)
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
{
vo_opengl: make compute shaders more flexible This allows users to do their own custom sample writing, mainly meant to address use cases such as RAVU. Also clean up the compute shader code a bit.
2017-07-29 18:41:50 +00:00
PRELUDE("layout (local_size_x = %d, local_size_y = %d) in;\n",
info.threads_w > 0 ? info.threads_w : info.block_w,
info.threads_h > 0 ? info.threads_h : info.block_h);
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
pass_prepare_src_tex(p);
// Since we don't actually have vertices, we pretend for convenience
// reasons that we do and calculate the right texture coordinates based on
// the output sample ID
vo_opengl: move shader handling to ra Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
2017-08-05 12:20:14 +00:00
gl_sc_uniform_vec2(p->sc, "out_scale", (float[2]){ 1.0 / w, 1.0 / h });
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
PRELUDE("#define outcoord(id) (out_scale * (vec2(id) + vec2(0.5)))\n");
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
for (int n = 0; n < p->num_pass_imgs; n++) {
struct image *s = &p->pass_imgs[n];
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
if (!s->tex)
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
continue;
// We need to rescale the coordinates to the true texture size
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
char *tex_scale = mp_tprintf(32, "tex_scale%d", n);
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
gl_sc_uniform_vec2(p->sc, tex_scale, (float[2]){
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
(float)s->w / s->tex->params.w,
(float)s->h / s->tex->params.h,
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
});
vo_gpu: simplify compute shader coordinate calculation Since the removal of FBOTEX_FUZZY, this can be made slightly simpler.
2017-09-20 09:03:49 +00:00
PRELUDE("#define texmap%d_raw(id) (tex_scale%d * outcoord(id))\n", n, n);
PRELUDE("#define texmap%d(id) (texture_rot%d * texmap%d_raw(id) + "
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
"pixel_size%d * texture_off%d)\n", n, n, n, n, n);
vo_opengl: don't precompute texcoord in global scope Breaks on mesa for whatever reason... even though it doesn't generate a GLSL shader compiler error Shouldn't make a performance difference for us because we cache `pos` anyway, and most compute shaders will probably cache all of their samples to shmem. Might have to re-visit this when we have an actual use case for repeated sampling inside CS though. (RAVU + anti-ringing is a possible candidate for that)
2017-08-03 16:50:07 +00:00
PRELUDE("#define texcoord%d texmap%d(gl_GlobalInvocationID)\n", n, n);
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
}
// always round up when dividing to make sure we don't leave off a part of
// the image
vo_opengl: make compute shaders more flexible This allows users to do their own custom sample writing, mainly meant to address use cases such as RAVU. Also clean up the compute shader code a bit.
2017-07-29 18:41:50 +00:00
int num_x = info.block_w > 0 ? (w + info.block_w - 1) / info.block_w : 1,
num_y = info.block_h > 0 ? (h + info.block_h - 1) / info.block_h : 1;
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
vo_opengl: move shader handling to ra Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
2017-08-05 12:20:14 +00:00
pass_record(p, gl_sc_dispatch_compute(p->sc, num_x, num_y, 1));
vo_gpu: handle texture initialization errors gracefully Tested by making the ra_tex_resize function always fail (apart from the initial FBO check). This required a few changes: 1. reset shaders on failed dispatch 2. reset cleanup binds on failed dispatch 3. fall back to initializing the struct image to 1x1 on failure 4. handle output_fbo_valid gracefully
2017-09-23 07:54:42 +00:00
cleanup_binds(p);
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
}
vo_opengl: simplify mirroring and fix it if glBlitFramebuffer is used The vp_w/vp_h variables and parameters were not really used anymore (they were redundant with ra_tex w/h) - but vp_h was still used to identify whether rendering should be done mirrored. Simplify this by adding a fbodst struct (some bad naming), which contains the render target texture, and some parameters how it should be rendered to (for now only flipping). It would not be appropriate to make this a member of ra_tex, so it's a separate struct. Introduces a weird regression for the first frame rendered after interpolation is toggled at runtime, but seems to work otherwise. This is possibly due to the change that blit() now mirrors, instead of just copying. (This is also why ra_fns.blit is changed.) Fixes #4719.
2017-08-07 14:44:15 +00:00
static struct mp_pass_perf render_pass_quad(struct gl_video *p,
vo_gpu: invalidate fbotex before drawing Don't discard the OSD or pass_draw_to_screen passes though. Could be faster on some hardware.
2017-08-18 00:31:58 +00:00
struct ra_fbo fbo, bool discard,
vo_opengl: move shader handling to ra Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
2017-08-05 12:20:14 +00:00
const struct mp_rect *dst)
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
{
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
// The first element is reserved for `vec2 position`
int num_vertex_attribs = 1 + p->num_pass_imgs;
size_t vertex_stride = num_vertex_attribs * sizeof(struct vertex_pt);
// Expand the VAO if necessary
while (p->vao_len < num_vertex_attribs) {
MP_TARRAY_APPEND(p, p->vao, p->vao_len, (struct ra_renderpass_input) {
.name = talloc_asprintf(p, "texcoord%d", p->vao_len - 1),
.type = RA_VARTYPE_FLOAT,
.dim_v = 2,
.dim_m = 1,
.offset = p->vao_len * sizeof(struct vertex_pt),
});
}
int num_vertices = 6; // quad as triangle list
int num_attribs_total = num_vertices * num_vertex_attribs;
MP_TARRAY_GROW(p, p->tmp_vertex, num_attribs_total);
gl_video: improve dithering Use a different algorithm to generate the dithering matrix. This looks much better than the previous ordered dither matrix with its cross-hatch artifacts. The matrix generation algorithm as well as its implementation was contributed by Wessel Dankers aka Fruit. The code in dither.c is his implementation, reformatted and with static global variables removed by me. The new matrix is uploaded as float texture - before this commit, it was a normal integer fixed point matrix. This means dithering will be disabled on systems without float textures. The size of the dithering matrix can be configured, as the matrix is generated at runtime. The generation of the matrix can take rather long, and is already unacceptable with size 8. The default is at 6, which takes about 100 ms on a Core2 Duo system with dither.c compiled at -O2, which I consider just about acceptable. The old ordered dithering is still available and can be selected by putting the dither=ordered sub-option. The ordered dither matrix generation code was moved to dither.c. This function was originally written by Uoti Urpala.
2013-05-25 23:48:39 +00:00
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
struct gl_transform t;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
gl_transform_ortho_fbo(&t, fbo);
gl_video: improve dithering Use a different algorithm to generate the dithering matrix. This looks much better than the previous ordered dither matrix with its cross-hatch artifacts. The matrix generation algorithm as well as its implementation was contributed by Wessel Dankers aka Fruit. The code in dither.c is his implementation, reformatted and with static global variables removed by me. The new matrix is uploaded as float texture - before this commit, it was a normal integer fixed point matrix. This means dithering will be disabled on systems without float textures. The size of the dithering matrix can be configured, as the matrix is generated at runtime. The generation of the matrix can take rather long, and is already unacceptable with size 8. The default is at 6, which takes about 100 ms on a Core2 Duo system with dither.c compiled at -O2, which I consider just about acceptable. The old ordered dithering is still available and can be selected by putting the dither=ordered sub-option. The ordered dither matrix generation code was moved to dither.c. This function was originally written by Uoti Urpala.
2013-05-25 23:48:39 +00:00
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
float x[2] = {dst->x0, dst->x1};
float y[2] = {dst->y0, dst->y1};
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
gl_transform_vec(t, &x[0], &y[0]);
gl_transform_vec(t, &x[1], &y[1]);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
for (int n = 0; n < 4; n++) {
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
struct vertex_pt *vs = &p->tmp_vertex[num_vertex_attribs * n];
// vec2 position in idx 0
vs[0].x = x[n / 2];
vs[0].y = y[n % 2];
for (int i = 0; i < p->num_pass_imgs; i++) {
struct image *s = &p->pass_imgs[i];
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
if (!s->tex)
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
continue;
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
struct gl_transform tr = s->transform;
vo_opengl: fix rotation This has been completely broken since commit 93546f0c. But even before, rotation handling did not make too much sense. In particular, it rotated the contents of the cropped image, instead of adjusting the crop rectangle as well. The result was that things like panscan or zooming did not behave as expected with rotation applied. The same is true for vertical flipping. Flipping is triggered by negative image stride. OpenGL does not support flipping the image on upload, so it's done as part of the rendering. It can be triggered with --vf=flip, but other filters and even decoders could setup negative stride to flip the image. Fix these issues by applying transforms to texture coordinates properly, and by making rotation and flipping part of these transforms. This still doesn't work properly for separated scaling. The issue is that we'd have to adjust how the passes are done. For now, pick a very stupid solution by rotating the image to a FBO, and then scaling from that. This has the avantage that the scale logic doesn't have to be complicated for such a rare case. It could be improved later. Prescaling is apparently still broken. I don't know if chroma positioning works properly either. None of this should affect the case with no rotation.
2016-03-28 14:30:48 +00:00
float tx = (n / 2) * s->w;
float ty = (n % 2) * s->h;
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
gl_transform_vec(tr, &tx, &ty);
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
bool rect = s->tex->params.non_normalized;
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
// vec2 texcoordN in idx N+1
vs[i + 1].x = tx / (rect ? 1 : s->tex->params.w);
vs[i + 1].y = ty / (rect ? 1 : s->tex->params.h);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
}
}
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
memmove(&p->tmp_vertex[num_vertex_attribs * 4],
&p->tmp_vertex[num_vertex_attribs * 2],
vertex_stride);
vo_opengl: always use GL_TRIANGLES for all primitives Will make the ra layer _slightly_ simpler.
2017-08-04 16:22:26 +00:00
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
memmove(&p->tmp_vertex[num_vertex_attribs * 5],
&p->tmp_vertex[num_vertex_attribs * 1],
vertex_stride);
vo_gpu: invalidate fbotex before drawing Don't discard the OSD or pass_draw_to_screen passes though. Could be faster on some hardware.
2017-08-18 00:31:58 +00:00
return gl_sc_dispatch_draw(p->sc, fbo.tex, discard, p->vao, num_vertex_attribs,
vo_gpu: set the correct number of vertex attribs This was always set to the length of the VAO, but it should have been set to the number of vertex attribs actually in use for this frame. No idea how that managed to survive the test framework on nvidia/linux, but ANGLE caught it.
2017-09-28 10:50:45 +00:00
vertex_stride, p->tmp_vertex, num_vertices);
gl_video: improve dithering Use a different algorithm to generate the dithering matrix. This looks much better than the previous ordered dither matrix with its cross-hatch artifacts. The matrix generation algorithm as well as its implementation was contributed by Wessel Dankers aka Fruit. The code in dither.c is his implementation, reformatted and with static global variables removed by me. The new matrix is uploaded as float texture - before this commit, it was a normal integer fixed point matrix. This means dithering will be disabled on systems without float textures. The size of the dithering matrix can be configured, as the matrix is generated at runtime. The generation of the matrix can take rather long, and is already unacceptable with size 8. The default is at 6, which takes about 100 ms on a Core2 Duo system with dither.c compiled at -O2, which I consider just about acceptable. The old ordered dithering is still available and can be selected by putting the dither=ordered sub-option. The ordered dither matrix generation code was moved to dither.c. This function was originally written by Uoti Urpala.
2013-05-25 23:48:39 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static void finish_pass_fbo(struct gl_video *p, struct ra_fbo fbo,
vo_gpu: invalidate fbotex before drawing Don't discard the OSD or pass_draw_to_screen passes though. Could be faster on some hardware.
2017-08-18 00:31:58 +00:00
bool discard, const struct mp_rect *dst)
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
{
pass_prepare_src_tex(p);
vo_gpu: invalidate fbotex before drawing Don't discard the OSD or pass_draw_to_screen passes though. Could be faster on some hardware.
2017-08-18 00:31:58 +00:00
pass_record(p, render_pass_quad(p, fbo, discard, dst));
vo_opengl: move shader handling to ra Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
2017-08-05 12:20:14 +00:00
debug_check_gl(p, "after rendering");
vo_gpu: handle texture initialization errors gracefully Tested by making the ra_tex_resize function always fail (apart from the initial FBO check). This required a few changes: 1. reset shaders on failed dispatch 2. reset cleanup binds on failed dispatch 3. fall back to initializing the struct image to 1x1 on failure 4. handle output_fbo_valid gracefully
2017-09-23 07:54:42 +00:00
cleanup_binds(p);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
}
// dst_fbo: this will be used for rendering; possibly reallocating the whole
// FBO, if the required parameters have changed
// w, h: required FBO target dimension, and also defines the target rectangle
// used for rasterization
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static void finish_pass_tex(struct gl_video *p, struct ra_tex **dst_tex,
vo_gpu: kill off FBOTEX_FUZZY I've observed the garbage pixels in more scenarios. They also were never really needed to begin with, originally being a discovered work-around for bug that we fixed since then anyway. Doesn't really seem to even help resizing, since the OpenGL drivers are all smart enough to pool resources internally anyway. Fixes #1814
2017-09-22 14:33:25 +00:00
int w, int h)
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
{
vo_gpu: handle texture initialization errors gracefully Tested by making the ra_tex_resize function always fail (apart from the initial FBO check). This required a few changes: 1. reset shaders on failed dispatch 2. reset cleanup binds on failed dispatch 3. fall back to initializing the struct image to 1x1 on failure 4. handle output_fbo_valid gracefully
2017-09-23 07:54:42 +00:00
if (!ra_tex_resize(p->ra, p->log, dst_tex, w, h, p->fbo_format)) {
cleanup_binds(p);
gl_sc_reset(p->sc);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
return;
vo_gpu: handle texture initialization errors gracefully Tested by making the ra_tex_resize function always fail (apart from the initial FBO check). This required a few changes: 1. reset shaders on failed dispatch 2. reset cleanup binds on failed dispatch 3. fall back to initializing the struct image to 1x1 on failure 4. handle output_fbo_valid gracefully
2017-09-23 07:54:42 +00:00
}
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
vo_gpu: aggressively prefer async compute On AMD devices, we only get one graphics pipe but several compute pipes which can (in theory) run independently. As such, we should prefer compute shaders over fragment shaders in scenarios where we expect them to be better for parallelism. This is amusingly trivial to do, and actually improves performance even in a single-queue scenario.
2017-09-24 13:21:37 +00:00
// If RA_CAP_PARALLEL_COMPUTE is set, try to prefer compute shaders
// over fragment shaders wherever possible.
if (!p->pass_compute.active && (p->ra->caps & RA_CAP_PARALLEL_COMPUTE))
pass_is_compute(p, 16, 16);
vo_opengl: make compute shaders more flexible This allows users to do their own custom sample writing, mainly meant to address use cases such as RAVU. Also clean up the compute shader code a bit.
2017-07-29 18:41:50 +00:00
if (p->pass_compute.active) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
gl_sc_uniform_image2D_wo(p->sc, "out_image", *dst_tex);
vo_opengl: make compute shaders more flexible This allows users to do their own custom sample writing, mainly meant to address use cases such as RAVU. Also clean up the compute shader code a bit.
2017-07-29 18:41:50 +00:00
if (!p->pass_compute.directly_writes)
GLSL(imageStore(out_image, ivec2(gl_GlobalInvocationID), color);)
dispatch_compute(p, w, h, p->pass_compute);
p->pass_compute = (struct compute_info){0};
vo_opengl: move shader handling to ra Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
2017-08-05 12:20:14 +00:00
debug_check_gl(p, "after dispatching compute shader");
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
} else {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct ra_fbo fbo = { .tex = *dst_tex, };
vo_gpu: invalidate fbotex before drawing Don't discard the OSD or pass_draw_to_screen passes though. Could be faster on some hardware.
2017-08-18 00:31:58 +00:00
finish_pass_fbo(p, fbo, true, &(struct mp_rect){0, 0, w, h});
vo_opengl: support compute shaders These can either be invoked as dispatch_compute to do a single computation, or finish_pass_fbo (after setting compute_size_minimum) to render to a new texture using a compute shader. To make this stuff all work transparently, we try really, really hard to make compute shaders as identical to fragment shaders as possible in their behavior.
2017-07-17 16:11:32 +00:00
}
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static const char *get_tex_swizzle(struct image *img)
vo_opengl: handle GL_LUMINANCE_ALPHA and integer textures differently GL_LUMINANCE_ALPHA is the only reason why per-plane swizzles exist. Remove per-plane swizzles (again), and regrettably handle them as special cases (again). Carry along the logical texture format (called gl_format in some parts of the code, including the new one). We also don't need a use_integer flag, since the new gl_format member implies whether it's an integer texture. (Yes, the there are separate logical GL formats for integer textures. This aspect of the OpenGL API is hysteric at best.) This should change nothing about actual rendering logic and GL API usage.
2017-02-17 14:46:11 +00:00
{
vo_opengl: separate hwdec context and mapping, port it to use ra This does two separate rather intrusive things: 1. Make the hwdec context (which does initialization, provides the device to the decoder, and other basic state) and frame mapping (getting textures from a mp_image) separate. This is more flexible, and you could map multiple images at once. It will help removing some hwdec special-casing from video.c. 2. Switch all hwdec API use to ra. Of course all code is still GL specific, but in theory it would be possible to support other backends. The most important change is that the hwdec interop returns ra objects, instead of anything GL specific. This removes the last dependency on GL-specific header files from video.c. I'm mixing these separate changes because both requires essentially rewriting all the glue code, so better do them at once. For the same reason, this change isn't done incrementally. hwdec_ios.m is untested, since I can't test it. Apart from superficial mistakes, this also requires dealing with Apple's texture format fuckups: they force you to use GL_LUMINANCE[_ALPHA] instead of GL_RED and GL_RG. We also need to report the correct format via ra_tex to the renderer, which is done by find_la_variant(). It's unknown whether this works correctly. hwdec_rpi.c as well as vo_rpi.c are still broken. (I need to pull my RPI out of a dusty pile of devices and cables, so, later.)
2017-08-10 15:48:33 +00:00
if (!img->tex)
return "rgba";
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
return img->tex->params.format->luminance_alpha ? "raaa" : "rgba";
vo_opengl: handle GL_LUMINANCE_ALPHA and integer textures differently GL_LUMINANCE_ALPHA is the only reason why per-plane swizzles exist. Remove per-plane swizzles (again), and regrettably handle them as special cases (again). Carry along the logical texture format (called gl_format in some parts of the code, including the new one). We also don't need a use_integer flag, since the new gl_format member implies whether it's an integer texture. (Yes, the there are separate logical GL formats for integer textures. This aspect of the OpenGL API is hysteric at best.) This should change nothing about actual rendering logic and GL API usage.
2017-02-17 14:46:11 +00:00
}
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
// Copy a texture to the vec4 color, while increasing offset. Also applies
// the texture multiplier to the sampled color
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static void copy_image(struct gl_video *p, int *offset, struct image img)
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
{
int count = img.components;
assert(*offset + count <= 4);
int id = pass_bind(p, img);
char src[5] = {0};
char dst[5] = {0};
vo_opengl: handle GL_LUMINANCE_ALPHA and integer textures differently GL_LUMINANCE_ALPHA is the only reason why per-plane swizzles exist. Remove per-plane swizzles (again), and regrettably handle them as special cases (again). Carry along the logical texture format (called gl_format in some parts of the code, including the new one). We also don't need a use_integer flag, since the new gl_format member implies whether it's an integer texture. (Yes, the there are separate logical GL formats for integer textures. This aspect of the OpenGL API is hysteric at best.) This should change nothing about actual rendering logic and GL API usage.
2017-02-17 14:46:11 +00:00
const char *tex_fmt = get_tex_swizzle(&img);
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
const char *dst_fmt = "rgba";
for (int i = 0; i < count; i++) {
src[i] = tex_fmt[i];
dst[i] = dst_fmt[*offset + i];
}
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
if (img.tex && img.tex->params.format->ctype == RA_CTYPE_UINT) {
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
uint64_t tex_max = 1ull << p->ra_format.component_bits;
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
img.multiplier *= 1.0 / (tex_max - 1);
}
GLSLF("color.%s = %f * vec4(texture(texture%d, texcoord%d)).%s;\n",
dst, img.multiplier, id, id, src);
*offset += count;
}
vo_opengl: refactor plane-skipping optimizations Instead of hard-coding the logic and planes to skip, factor this out to a reusible function, and instead add the number of relevant coordinates to the texture state.
2016-03-05 11:38:51 +00:00
static void skip_unused(struct gl_video *p, int num_components)
{
for (int i = num_components; i < 4; i++)
GLSLF("color.%c = %f;\n", "rgba"[i], i < 3 ? 0.0 : 1.0);
}
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
static void uninit_scaler(struct gl_video *p, struct scaler *scaler)
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
{
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
ra_tex_free(p->ra, &scaler->sep_fbo);
vo_opengl: manage scaler LUT textures via ra Also fix the RA_CAP_ bitmask nonsense.
2017-07-29 18:15:59 +00:00
ra_tex_free(p->ra, &scaler->lut);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
scaler->kernel = NULL;
scaler->initialized = false;
}
vo_opengl: abstract hook texture access behind macro This macro takes care of rotation, swizzling, integer conversion and normalization automatically. I found the performance impact to be nonexistant for superxbr and debanding, although rotation *did* have an impact due to the extra matrix multiplication. (So it gets skipped where possible) All of the internal hooks have been rewritten to use this new mechanism, and the prescaler hooks have finally been separated from each other. This also means the prescale FBO kludge is no longer required. This fixes image corruption for image formats like 0bgr, and also fixes prescaling under rotation. (As well as other user hooks that have orientation-dependent access) The "raw" attributes (tex, tex_pos, pixel_size) are still un-rotated, in case something needs them, but ideally the hooks should be rewritten to use the new API as much as possible. The hooked texture has been renamed from just NAME to NAME_raw to make script authors notice the change (and also deemphasize direct texture access). This is also a step towards getting rid of the use_integer pass.
2016-05-14 05:05:04 +00:00
static void hook_prelude(struct gl_video *p, const char *name, int id,
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct image img)
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
{
vo_opengl: abstract hook texture access behind macro This macro takes care of rotation, swizzling, integer conversion and normalization automatically. I found the performance impact to be nonexistant for superxbr and debanding, although rotation *did* have an impact due to the extra matrix multiplication. (So it gets skipped where possible) All of the internal hooks have been rewritten to use this new mechanism, and the prescaler hooks have finally been separated from each other. This also means the prescale FBO kludge is no longer required. This fixes image corruption for image formats like 0bgr, and also fixes prescaling under rotation. (As well as other user hooks that have orientation-dependent access) The "raw" attributes (tex, tex_pos, pixel_size) are still un-rotated, in case something needs them, but ideally the hooks should be rewritten to use the new API as much as possible. The hooked texture has been renamed from just NAME to NAME_raw to make script authors notice the change (and also deemphasize direct texture access). This is also a step towards getting rid of the use_integer pass.
2016-05-14 05:05:04 +00:00
GLSLHF("#define %s_raw texture%d\n", name, id);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
GLSLHF("#define %s_pos texcoord%d\n", name, id);
GLSLHF("#define %s_size texture_size%d\n", name, id);
vo_opengl: abstract hook texture access behind macro This macro takes care of rotation, swizzling, integer conversion and normalization automatically. I found the performance impact to be nonexistant for superxbr and debanding, although rotation *did* have an impact due to the extra matrix multiplication. (So it gets skipped where possible) All of the internal hooks have been rewritten to use this new mechanism, and the prescaler hooks have finally been separated from each other. This also means the prescale FBO kludge is no longer required. This fixes image corruption for image formats like 0bgr, and also fixes prescaling under rotation. (As well as other user hooks that have orientation-dependent access) The "raw" attributes (tex, tex_pos, pixel_size) are still un-rotated, in case something needs them, but ideally the hooks should be rewritten to use the new API as much as possible. The hooked texture has been renamed from just NAME to NAME_raw to make script authors notice the change (and also deemphasize direct texture access). This is also a step towards getting rid of the use_integer pass.
2016-05-14 05:05:04 +00:00
GLSLHF("#define %s_rot texture_rot%d\n", name, id);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
GLSLHF("#define %s_pt pixel_size%d\n", name, id);
vo_opengl: support user compute shaders These are identical to regular fragment shader hooks, but with extra metadata indicating the preferred block size.
2017-07-20 09:26:01 +00:00
GLSLHF("#define %s_map texmap%d\n", name, id);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
GLSLHF("#define %s_mul %f\n", name, img.multiplier);
vo_opengl: abstract hook texture access behind macro This macro takes care of rotation, swizzling, integer conversion and normalization automatically. I found the performance impact to be nonexistant for superxbr and debanding, although rotation *did* have an impact due to the extra matrix multiplication. (So it gets skipped where possible) All of the internal hooks have been rewritten to use this new mechanism, and the prescaler hooks have finally been separated from each other. This also means the prescale FBO kludge is no longer required. This fixes image corruption for image formats like 0bgr, and also fixes prescaling under rotation. (As well as other user hooks that have orientation-dependent access) The "raw" attributes (tex, tex_pos, pixel_size) are still un-rotated, in case something needs them, but ideally the hooks should be rewritten to use the new API as much as possible. The hooked texture has been renamed from just NAME to NAME_raw to make script authors notice the change (and also deemphasize direct texture access). This is also a step towards getting rid of the use_integer pass.
2016-05-14 05:05:04 +00:00
// Set up the sampling functions
vo_opengl: also expose NAME_mul for user shaders 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.
2017-07-06 09:27:24 +00:00
GLSLHF("#define %s_tex(pos) (%s_mul * vec4(texture(%s_raw, pos)).%s)\n",
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
name, name, name, get_tex_swizzle(&img));
vo_opengl: abstract hook texture access behind macro This macro takes care of rotation, swizzling, integer conversion and normalization automatically. I found the performance impact to be nonexistant for superxbr and debanding, although rotation *did* have an impact due to the extra matrix multiplication. (So it gets skipped where possible) All of the internal hooks have been rewritten to use this new mechanism, and the prescaler hooks have finally been separated from each other. This also means the prescale FBO kludge is no longer required. This fixes image corruption for image formats like 0bgr, and also fixes prescaling under rotation. (As well as other user hooks that have orientation-dependent access) The "raw" attributes (tex, tex_pos, pixel_size) are still un-rotated, in case something needs them, but ideally the hooks should be rewritten to use the new API as much as possible. The hooked texture has been renamed from just NAME to NAME_raw to make script authors notice the change (and also deemphasize direct texture access). This is also a step towards getting rid of the use_integer pass.
2016-05-14 05:05:04 +00:00
// Since the extra matrix multiplication impacts performance,
// skip it unless the texture was actually rotated
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
if (gl_transform_eq(img.transform, identity_trans)) {
vo_opengl: abstract hook texture access behind macro This macro takes care of rotation, swizzling, integer conversion and normalization automatically. I found the performance impact to be nonexistant for superxbr and debanding, although rotation *did* have an impact due to the extra matrix multiplication. (So it gets skipped where possible) All of the internal hooks have been rewritten to use this new mechanism, and the prescaler hooks have finally been separated from each other. This also means the prescale FBO kludge is no longer required. This fixes image corruption for image formats like 0bgr, and also fixes prescaling under rotation. (As well as other user hooks that have orientation-dependent access) The "raw" attributes (tex, tex_pos, pixel_size) are still un-rotated, in case something needs them, but ideally the hooks should be rewritten to use the new API as much as possible. The hooked texture has been renamed from just NAME to NAME_raw to make script authors notice the change (and also deemphasize direct texture access). This is also a step towards getting rid of the use_integer pass.
2016-05-14 05:05:04 +00:00
GLSLHF("#define %s_texOff(off) %s_tex(%s_pos + %s_pt * vec2(off))\n",
name, name, name, name);
} else {
GLSLHF("#define %s_texOff(off) "
"%s_tex(%s_pos + %s_rot * vec2(off)/%s_size)\n",
name, name, name, name, name);
}
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static bool saved_img_find(struct gl_video *p, const char *name,
struct image *out)
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
{
if (!name || !out)
return false;
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
for (int i = 0; i < p->num_saved_imgs; i++) {
if (strcmp(p->saved_imgs[i].name, name) == 0) {
*out = p->saved_imgs[i].img;
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
return true;
}
}
return false;
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static void saved_img_store(struct gl_video *p, const char *name,
struct image img)
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
{
assert(name);
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
for (int i = 0; i < p->num_saved_imgs; i++) {
if (strcmp(p->saved_imgs[i].name, name) == 0) {
p->saved_imgs[i].img = img;
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
return;
}
}
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
MP_TARRAY_APPEND(p, p->saved_imgs, p->num_saved_imgs, (struct saved_img) {
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
.name = name,
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
.img = img
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
});
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
}
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
static bool pass_hook_setup_binds(struct gl_video *p, const char *name,
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct image img, struct tex_hook *hook)
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
{
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
for (int t = 0; t < SHADER_MAX_BINDS; t++) {
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
char *bind_name = (char *)hook->bind_tex[t];
if (!bind_name)
continue;
// This is a special name that means "currently hooked texture"
if (strcmp(bind_name, "HOOKED") == 0) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
int id = pass_bind(p, img);
hook_prelude(p, "HOOKED", id, img);
hook_prelude(p, name, id, img);
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
continue;
}
// BIND can also be used to load user-defined textures, in which
// case we will directly load them as a uniform instead of
// generating the hook_prelude boilerplate
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
for (int u = 0; u < p->num_user_textures; u++) {
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
struct gl_user_shader_tex *utex = &p->user_textures[u];
if (bstr_equals0(utex->name, bind_name)) {
vo_opengl: manage user shader textures with ra Drops some features I guess, no idea if those were needed. Untested due to lack of test cases.
2017-07-30 09:38:52 +00:00
gl_sc_uniform_texture(p->sc, bind_name, utex->tex);
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
goto next_bind;
}
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct image bind_img;
if (!saved_img_find(p, bind_name, &bind_img)) {
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
// Clean up texture bindings and move on to the next hook
msg: reinterpret a bunch of message levels I've decided that MP_TRACE means “noisy spam per frame”, whereas MP_DBG just means “more verbose debugging messages than MSGL_V”. Basically, MSGL_DBG shouldn't create spam per frame like it currently does, and MSGL_V should make sense to the end-user and provide mostly additional informational output. MP_DBG is basically what I want to make the new default for --log-file, so the cut-off point for MP_DBG is if we probably want to know if for debugging purposes but the user most likely doesn't care about on the terminal. Also, the debug callbacks for libass and ffmpeg got bumped in their verbosity levels slightly, because being external components they're a bit less relevant to mpv debugging, and a bit too over-eager in what they consider to be relevant information. I exclusively used the "try it on my machine and remove messages from MSGL_* until it does what I want it to" approach of refactoring, so YMMV.
2017-09-28 09:53:57 +00:00
MP_TRACE(p, "Skipping hook on %s due to no texture named %s.\n",
name, bind_name);
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
p->num_pass_imgs -= t;
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
return false;
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
hook_prelude(p, bind_name, pass_bind(p, bind_img), bind_img);
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
next_bind: ;
}
return true;
}
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
static struct ra_tex **next_hook_tex(struct gl_video *p)
{
if (p->idx_hook_textures == p->num_hook_textures)
MP_TARRAY_APPEND(p, p->hook_textures, p->num_hook_textures, NULL);
return &p->hook_textures[p->idx_hook_textures++];
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
// Process hooks for a plane, saving the result and returning a new image
// If 'trans' is NULL, the shader is forbidden from transforming img
static struct image pass_hook(struct gl_video *p, const char *name,
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
struct image img, struct gl_transform *trans)
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
{
if (!name)
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
return img;
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
saved_img_store(p, name, img);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
msg: reinterpret a bunch of message levels I've decided that MP_TRACE means “noisy spam per frame”, whereas MP_DBG just means “more verbose debugging messages than MSGL_V”. Basically, MSGL_DBG shouldn't create spam per frame like it currently does, and MSGL_V should make sense to the end-user and provide mostly additional informational output. MP_DBG is basically what I want to make the new default for --log-file, so the cut-off point for MP_DBG is if we probably want to know if for debugging purposes but the user most likely doesn't care about on the terminal. Also, the debug callbacks for libass and ffmpeg got bumped in their verbosity levels slightly, because being external components they're a bit less relevant to mpv debugging, and a bit too over-eager in what they consider to be relevant information. I exclusively used the "try it on my machine and remove messages from MSGL_* until it does what I want it to" approach of refactoring, so YMMV.
2017-09-28 09:53:57 +00:00
MP_TRACE(p, "Running hooks for %s\n", name);
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
for (int i = 0; i < p->num_tex_hooks; i++) {
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
struct tex_hook *hook = &p->tex_hooks[i];
vo_opengl: slightly refactor user_shaders code - Each struct tex_hook now stores multiple hooks, this allows us to avoid the awkward way of the current code has to add the same pass multiple times. - As a consequence, SHADER_MAX_HOOKS was split up into SHADER_MAX_PASSES (number of tex_hooks) and SHADER_MAX_HOOKS (number of hooked textures per tex_hook), and both numbers decreased correspondingly. - Instead of having a weird free() callback, we can just leverage talloc's recursive free behavior. The only user is the user shaders code anyway.
2017-07-10 20:52:39 +00:00
// Figure out if this pass hooks this texture
for (int h = 0; h < SHADER_MAX_HOOKS; h++) {
if (hook->hook_tex[h] && strcmp(hook->hook_tex[h], name) == 0)
goto found;
}
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
vo_opengl: slightly refactor user_shaders code - Each struct tex_hook now stores multiple hooks, this allows us to avoid the awkward way of the current code has to add the same pass multiple times. - As a consequence, SHADER_MAX_HOOKS was split up into SHADER_MAX_PASSES (number of tex_hooks) and SHADER_MAX_HOOKS (number of hooked textures per tex_hook), and both numbers decreased correspondingly. - Instead of having a weird free() callback, we can just leverage talloc's recursive free behavior. The only user is the user shaders code anyway.
2017-07-10 20:52:39 +00:00
continue;
found:
vo_opengl: make user hook passes optional User hooks can now use an extra WHEN expression to specify when the shader should be run. For example, this can be used to only run a chroma scaling shader `WHEN CHROMA.w LUMA.w <`. There's a slight semantics change to user shaders: When trying to bind a texture that does not exist, a shader will now be silently skipped (similar to when the condition is false) instead of generating an error. This allows shader stages to depend on an optional earlier stage without having to copy/paste the same condition everywhere. (In other words: there's an implicit condition on all of the bound textures existing)
2016-06-08 13:05:28 +00:00
// Check the hook's condition
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
if (hook->cond && !hook->cond(p, img, hook->priv)) {
msg: reinterpret a bunch of message levels I've decided that MP_TRACE means “noisy spam per frame”, whereas MP_DBG just means “more verbose debugging messages than MSGL_V”. Basically, MSGL_DBG shouldn't create spam per frame like it currently does, and MSGL_V should make sense to the end-user and provide mostly additional informational output. MP_DBG is basically what I want to make the new default for --log-file, so the cut-off point for MP_DBG is if we probably want to know if for debugging purposes but the user most likely doesn't care about on the terminal. Also, the debug callbacks for libass and ffmpeg got bumped in their verbosity levels slightly, because being external components they're a bit less relevant to mpv debugging, and a bit too over-eager in what they consider to be relevant information. I exclusively used the "try it on my machine and remove messages from MSGL_* until it does what I want it to" approach of refactoring, so YMMV.
2017-09-28 09:53:57 +00:00
MP_TRACE(p, "Skipping hook on %s due to condition.\n", name);
vo_opengl: make user hook passes optional User hooks can now use an extra WHEN expression to specify when the shader should be run. For example, this can be used to only run a chroma scaling shader `WHEN CHROMA.w LUMA.w <`. There's a slight semantics change to user shaders: When trying to bind a texture that does not exist, a shader will now be silently skipped (similar to when the condition is false) instead of generating an error. This allows shader stages to depend on an optional earlier stage without having to copy/paste the same condition everywhere. (In other words: there's an implicit condition on all of the bound textures existing)
2016-06-08 13:05:28 +00:00
continue;
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
if (!pass_hook_setup_binds(p, name, img, hook))
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
continue;
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
// Run the actual hook. This generates a series of GLSL shader
// instructions sufficient for drawing the hook's output
struct gl_transform hook_off = identity_trans;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
hook->hook(p, img, &hook_off, hook->priv);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
int comps = hook->components ? hook->components : img.components;
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
skip_unused(p, comps);
// Compute the updated FBO dimensions and store the result
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct mp_rect_f sz = {0, 0, img.w, img.h};
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
gl_transform_rect(hook_off, &sz);
int w = lroundf(fabs(sz.x1 - sz.x0));
int h = lroundf(fabs(sz.y1 - sz.y0));
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
struct ra_tex **tex = next_hook_tex(p);
finish_pass_tex(p, tex, w, h);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
const char *store_name = hook->save_tex ? hook->save_tex : name;
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
struct image saved_img = image_wrap(*tex, img.type, comps);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
// If the texture we're saving overwrites the "current" texture, also
// update the tex parameter so that the future loop cycles will use the
// updated values, and export the offset
if (strcmp(store_name, name) == 0) {
if (!trans && !gl_transform_eq(hook_off, identity_trans)) {
MP_ERR(p, "Hook tried changing size of unscalable texture %s!\n",
name);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
return img;
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
img = saved_img;
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
if (trans)
gl_transform_trans(hook_off, trans);
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
saved_img_store(p, store_name, saved_img);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
return img;
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
}
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
// This can be used at any time in the middle of rendering to specify an
// optional hook point, which if triggered will render out to a new FBO and
// load the result back into vec4 color. Offsets applied by the hooks are
// accumulated in tex_trans, and the FBO is dimensioned according
// to p->texture_w/h
static void pass_opt_hook_point(struct gl_video *p, const char *name,
struct gl_transform *tex_trans)
{
if (!name)
return;
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
for (int i = 0; i < p->num_tex_hooks; i++) {
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
struct tex_hook *hook = &p->tex_hooks[i];
vo_opengl: slightly refactor user_shaders code - Each struct tex_hook now stores multiple hooks, this allows us to avoid the awkward way of the current code has to add the same pass multiple times. - As a consequence, SHADER_MAX_HOOKS was split up into SHADER_MAX_PASSES (number of tex_hooks) and SHADER_MAX_HOOKS (number of hooked textures per tex_hook), and both numbers decreased correspondingly. - Instead of having a weird free() callback, we can just leverage talloc's recursive free behavior. The only user is the user shaders code anyway.
2017-07-10 20:52:39 +00:00
for (int h = 0; h < SHADER_MAX_HOOKS; h++) {
if (hook->hook_tex[h] && strcmp(hook->hook_tex[h], name) == 0)
goto found;
}
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
for (int b = 0; b < SHADER_MAX_BINDS; b++) {
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
if (hook->bind_tex[b] && strcmp(hook->bind_tex[b], name) == 0)
goto found;
}
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
}
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
// Nothing uses this texture, don't bother storing it
return;
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
found: ;
struct ra_tex **tex = next_hook_tex(p);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
finish_pass_tex(p, tex, p->texture_w, p->texture_h);
struct image img = image_wrap(*tex, PLANE_RGB, p->components);
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
img = pass_hook(p, name, img, tex_trans);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
copy_image(p, &(int){0}, img);
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
p->texture_w = img.w;
p->texture_h = img.h;
p->components = img.components;
vo_opengl: describe the remainder passes after user shaders 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.
2017-07-09 06:48:29 +00:00
pass_describe(p, "(remainder pass)");
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
}
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
static void load_shader(struct gl_video *p, struct bstr body)
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
{
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
gl_sc_hadd_bstr(p->sc, body);
vo_gpu: attempt to avoid UBOs for dynamic variables This makes the radeon driver shut up about frequently updating STATIC_DRAW UBOs (--opengl-debug), and also reduces the amount of synchronization necessary for vulkan uniform buffers. Also add some extra debugging/tracing code paths. I went with a flags-based approach in case we ever want to extend this.
2017-09-17 08:55:43 +00:00
gl_sc_uniform_dynamic(p->sc);
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
gl_sc_uniform_f(p->sc, "random", (double)av_lfg_get(&p->lfg) / UINT32_MAX);
vo_gpu: attempt to avoid UBOs for dynamic variables This makes the radeon driver shut up about frequently updating STATIC_DRAW UBOs (--opengl-debug), and also reduces the amount of synchronization necessary for vulkan uniform buffers. Also add some extra debugging/tracing code paths. I went with a flags-based approach in case we ever want to extend this.
2017-09-17 08:55:43 +00:00
gl_sc_uniform_dynamic(p->sc);
vo_opengl: fix type of glsl variable frame
2017-07-11 02:05:26 +00:00
gl_sc_uniform_i(p->sc, "frame", p->frames_uploaded);
vo_opengl: replace uniform variable image_size with input_size input_size can be the size of a cropped image Signed-off-by: wm4 <wm4@nowhere>
2017-03-19 14:13:51 +00:00
gl_sc_uniform_vec2(p->sc, "input_size",
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
(float[]){(p->src_rect.x1 - p->src_rect.x0) *
p->texture_offset.m[0][0],
(p->src_rect.y1 - p->src_rect.y0) *
p->texture_offset.m[1][1]});
vo_opengl: add output_size uniform to custom shader logically, scaler should know its input and output size Signed-off-by: wm4 <wm4@nowhere>
2016-06-23 17:49:10 +00:00
gl_sc_uniform_vec2(p->sc, "target_size",
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
(float[]){p->dst_rect.x1 - p->dst_rect.x0,
p->dst_rect.y1 - p->dst_rect.y0});
vo_opengl: add tex_offset uniform variable to user shaders
2016-07-15 06:26:35 +00:00
gl_sc_uniform_vec2(p->sc, "tex_offset",
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
(float[]){p->src_rect.x0 * p->texture_offset.m[0][0] +
p->texture_offset.t[0],
p->src_rect.y0 * p->texture_offset.m[1][1] +
p->texture_offset.t[1]});
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
}
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
// Semantic equality
static bool double_seq(double a, double b)
{
return (isnan(a) && isnan(b)) || a == b;
}
static bool scaler_fun_eq(struct scaler_fun a, struct scaler_fun b)
{
if ((a.name && !b.name) || (b.name && !a.name))
return false;
return ((!a.name && !b.name) || strcmp(a.name, b.name) == 0) &&
double_seq(a.params[0], b.params[0]) &&
double_seq(a.params[1], b.params[1]) &&
filter_kernels: add ability to taper kernels/windows This allows us to define the tukey window (and other tapered windows). Also add a missing option definition for `wblur` while we're at it, to make testing out window-related stuff easier.
2016-10-26 14:32:57 +00:00
a.blur == b.blur &&
a.taper == b.taper;
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
}
static bool scaler_conf_eq(struct scaler_config a, struct scaler_config b)
{
// Note: antiring isn't compared because it doesn't affect LUT
// generation
return scaler_fun_eq(a.kernel, b.kernel) &&
scaler_fun_eq(a.window, b.window) &&
vo_opengl: add tscale-clamp option This significantly reduces the amount of noticeable flashing when using tscale kernels with negative lobes, by cutting them off completely. I'm not sure if this has any negative effects. It needs a bit of subjective testing over a period of time, so I just made it an option. Fixes #2155.
2015-08-20 19:45:58 +00:00
a.radius == b.radius &&
a.clamp == b.clamp;
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
}
static void reinit_scaler(struct gl_video *p, struct scaler *scaler,
const struct scaler_config *conf,
double scale_factor,
int sizes[])
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
{
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
if (scaler_conf_eq(scaler->conf, *conf) &&
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
scaler->scale_factor == scale_factor &&
scaler->initialized)
vo_opengl: clean up rendering path Shuffle the special cases around so that it looks cleaner. The result should be equivalent to the code before.
2014-04-20 19:30:23 +00:00
return;
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
uninit_scaler(p, scaler);
vo_opengl: clean up rendering path Shuffle the special cases around so that it looks cleaner. The result should be equivalent to the code before.
2014-04-20 19:30:23 +00:00
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
scaler->conf = *conf;
vo_opengl: somewhat simplify suboption handling mess Enable m_sub_options_copy() to copy nested sub-options, and also enable it to create an option struct from defaults. We can get rid of most of the crap in assign_options() now. Calling handle_scaler_opt() to get a static allocation for scaler name is still needed. It's moved to reinit_scaler(), which seems to be a better place for it. Without it, dangling pointers could be created when options are changed. (And in fact, this fixes possible dangling pointers for window.name.) In theory we could create a dynamic copy, but that seemed even more messy. Chance of regressions.
2016-06-04 18:48:56 +00:00
bool is_tscale = scaler->index == SCALER_TSCALE;
scaler->conf.kernel.name = (char *)handle_scaler_opt(conf->kernel.name, is_tscale);
scaler->conf.window.name = (char *)handle_scaler_opt(conf->window.name, is_tscale);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
scaler->scale_factor = scale_factor;
scaler->insufficient = false;
scaler->initialized = true;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
const struct filter_kernel *t_kernel = mp_find_filter_kernel(conf->kernel.name);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
if (!t_kernel)
return;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
scaler->kernel_storage = *t_kernel;
scaler->kernel = &scaler->kernel_storage;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
const char *win = conf->window.name;
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
if (!win || !win[0])
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
win = t_kernel->window; // fall back to the scaler's default window
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
const struct filter_window *t_window = mp_find_filter_window(win);
if (t_window)
scaler->kernel->w = *t_window;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
for (int n = 0; n < 2; n++) {
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
if (!isnan(conf->kernel.params[n]))
scaler->kernel->f.params[n] = conf->kernel.params[n];
if (!isnan(conf->window.params[n]))
scaler->kernel->w.params[n] = conf->window.params[n];
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
}
vo_opengl: support rotation This turned out much more complicated than I thought. It's not just a matter of adjusting the texture coordinates, but you also have to consider separated scaling and panscan clipping, which make everything complicated. This actually still doesn't clip 100% correctly, but the bug is only visible when rotating (or flipping with --vf=flip), and using something like --video-pan-x/y at the same time.
2014-04-20 19:37:18 +00:00
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
if (conf->kernel.blur > 0.0)
scaler->kernel->f.blur = conf->kernel.blur;
if (conf->window.blur > 0.0)
scaler->kernel->w.blur = conf->window.blur;
vo_opengl: clean up rendering path Shuffle the special cases around so that it looks cleaner. The result should be equivalent to the code before.
2014-04-20 19:30:23 +00:00
filter_kernels: add ability to taper kernels/windows This allows us to define the tukey window (and other tapered windows). Also add a missing option definition for `wblur` while we're at it, to make testing out window-related stuff easier.
2016-10-26 14:32:57 +00:00
if (conf->kernel.taper > 0.0)
scaler->kernel->f.taper = conf->kernel.taper;
if (conf->window.taper > 0.0)
scaler->kernel->w.taper = conf->window.taper;
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
if (scaler->kernel->f.resizable && conf->radius > 0.0)
scaler->kernel->f.radius = conf->radius;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
vo_opengl: add tscale-clamp option This significantly reduces the amount of noticeable flashing when using tscale kernels with negative lobes, by cutting them off completely. I'm not sure if this has any negative effects. It needs a bit of subjective testing over a period of time, so I just made it an option. Fixes #2155.
2015-08-20 19:45:58 +00:00
scaler->kernel->clamp = conf->clamp;
filter_kernels: add radius cutoff functionality 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)
2017-07-03 09:23:48 +00:00
scaler->kernel->value_cutoff = conf->cutoff;
vo_opengl: add tscale-clamp option This significantly reduces the amount of noticeable flashing when using tscale kernels with negative lobes, by cutting them off completely. I'm not sure if this has any negative effects. It needs a bit of subjective testing over a period of time, so I just made it an option. Fixes #2155.
2015-08-20 19:45:58 +00:00
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
scaler->insufficient = !mp_init_filter(scaler->kernel, sizes, scale_factor);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
int size = scaler->kernel->size;
vo_opengl: refactor scaler LUT weight packing/loading This is mostly done so we can support using textures with more components than the scaler LUTs have entries. But while we're at it, also change the way the weights are packed so that they're always sequential with no gaps. This allows us to simplify pass_sample_separated_get_weights as well.
2017-08-27 07:15:50 +00:00
int num_components = size > 2 ? 4 : size;
const struct ra_format *fmt = ra_find_float16_format(p->ra, num_components);
vo_opengl: manage scaler LUT textures via ra Also fix the RA_CAP_ bitmask nonsense.
2017-07-29 18:15:59 +00:00
assert(fmt);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
vo_opengl: refactor scaler LUT weight packing/loading This is mostly done so we can support using textures with more components than the scaler LUTs have entries. But while we're at it, also change the way the weights are packed so that they're always sequential with no gaps. This allows us to simplify pass_sample_separated_get_weights as well.
2017-08-27 07:15:50 +00:00
int width = (size + num_components - 1) / num_components; // round up
int stride = width * num_components;
assert(size <= stride);
vo_opengl: make LOOKUP_TEXTURE_SIZE configurable
2015-12-05 19:14:23 +00:00
scaler->lut_size = 1 << p->opts.scaler_lut_size;
vo_opengl: Fix minor LUT sampling error Define a macro to correct the coordinate for lookup texture. Cache the corrected coordinate for 1D filter and use mix() to minimize the performance impact.
2015-12-05 18:54:25 +00:00
vo_opengl: refactor scaler LUT weight packing/loading This is mostly done so we can support using textures with more components than the scaler LUTs have entries. But while we're at it, also change the way the weights are packed so that they're always sequential with no gaps. This allows us to simplify pass_sample_separated_get_weights as well.
2017-08-27 07:15:50 +00:00
float *weights = talloc_array(NULL, float, scaler->lut_size * stride);
mp_compute_lut(scaler->kernel, scaler->lut_size, stride, weights);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
vo_opengl: manage scaler LUT textures via ra Also fix the RA_CAP_ bitmask nonsense.
2017-07-29 18:15:59 +00:00
bool use_1d = scaler->kernel->polar && (p->ra->caps & RA_CAP_TEX_1D);
struct ra_tex_params lut_params = {
.dimensions = use_1d ? 1 : 2,
.w = use_1d ? scaler->lut_size : width,
.h = use_1d ? 1 : scaler->lut_size,
.d = 1,
.format = fmt,
.render_src = true,
.src_linear = true,
.initial_data = weights,
};
scaler->lut = ra_tex_create(p->ra, &lut_params);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
talloc_free(weights);
debug_check_gl(p, "after initializing scaler");
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
vo_opengl: move self-contained shader routines to a separate file This is mostly to cut down somewhat on the amount of code bloat in video.c by moving out helper functions (including scaler kernels and color management routines) to a separate file. It would certainly be possible to move out more functions (eg. dithering or CMS code) with some extra effort/refactoring, but this is a start. Signed-off-by: wm4 <wm4@nowhere>
2015-09-05 12:03:00 +00:00
// Special helper for sampling from two separated stages
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static void pass_sample_separated(struct gl_video *p, struct image src,
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
struct scaler *scaler, int w, int h)
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
{
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
// Separate the transformation into x and y components, per pass
struct gl_transform t_x = {
.m = {{src.transform.m[0][0], 0.0}, {src.transform.m[1][0], 1.0}},
.t = {src.transform.t[0], 0.0},
};
struct gl_transform t_y = {
.m = {{1.0, src.transform.m[0][1]}, {0.0, src.transform.m[1][1]}},
.t = {0.0, src.transform.t[1]},
};
// First pass (scale only in the y dir)
src.transform = t_y;
sampler_prelude(p->sc, pass_bind(p, src));
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
GLSLF("// first pass\n");
vo_opengl: move self-contained shader routines to a separate file This is mostly to cut down somewhat on the amount of code bloat in video.c by moving out helper functions (including scaler kernels and color management routines) to a separate file. It would certainly be possible to move out more functions (eg. dithering or CMS code) with some extra effort/refactoring, but this is a start. Signed-off-by: wm4 <wm4@nowhere>
2015-09-05 12:03:00 +00:00
pass_sample_separated_gen(p->sc, scaler, 0, 1);
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
GLSLF("color *= %f;\n", src.multiplier);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
finish_pass_tex(p, &scaler->sep_fbo, src.w, h);
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
// Second pass (scale only in the x dir)
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
src = image_wrap(scaler->sep_fbo, src.type, src.components);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
src.transform = t_x;
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
pass_describe(p, "%s second pass", scaler->conf.kernel.name);
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
sampler_prelude(p->sc, pass_bind(p, src));
vo_opengl: move self-contained shader routines to a separate file This is mostly to cut down somewhat on the amount of code bloat in video.c by moving out helper functions (including scaler kernels and color management routines) to a separate file. It would certainly be possible to move out more functions (eg. dithering or CMS code) with some extra effort/refactoring, but this is a start. Signed-off-by: wm4 <wm4@nowhere>
2015-09-05 12:03:00 +00:00
pass_sample_separated_gen(p->sc, scaler, 1, 0);
vo_opengl: add oversample scaler This is like nearest neighbour, but the edges between pixels are linearly interpolating if needed, as if they had been (naively) oversampled.
2015-03-15 05:27:11 +00:00
}
vo_opengl: check against shmem limits The radius check was not strict enough, especially not for all platforms. To fix this, actually check the hardware capabilities instead of relying on a hard-coded maximum radius.
2017-07-25 23:42:19 +00:00
// Picks either the compute shader version or the regular sampler version
// depending on hardware support
static void pass_dispatch_sample_polar(struct gl_video *p, struct scaler *scaler,
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct image img, int w, int h)
vo_opengl: check against shmem limits The radius check was not strict enough, especially not for all platforms. To fix this, actually check the hardware capabilities instead of relying on a hard-coded maximum radius.
2017-07-25 23:42:19 +00:00
{
vo_gpu: drop the RA_CAP_NESTED_ARRAY req from EWA compute Almost as fast as the old code, but more general. Notably, glslang doesn't support nested arrays. (cf. https://github.com/KhronosGroup/glslang/issues/1057) Also much cleaner code-wise, so I think I'll keep it even if glslang implements array_of_arrays.
2017-09-17 03:37:24 +00:00
uint64_t reqs = RA_CAP_COMPUTE;
vo_opengl: move shader handling to ra Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
2017-08-05 12:20:14 +00:00
if ((p->ra->caps & reqs) != reqs)
vo_opengl: check against shmem limits The radius check was not strict enough, especially not for all platforms. To fix this, actually check the hardware capabilities instead of relying on a hard-coded maximum radius.
2017-07-25 23:42:19 +00:00
goto fallback;
int bound = ceil(scaler->kernel->radius_cutoff);
int offset = bound - 1; // padding top/left
int padding = offset + bound; // total padding
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
float ratiox = (float)w / img.w,
ratioy = (float)h / img.h;
vo_opengl: check against shmem limits The radius check was not strict enough, especially not for all platforms. To fix this, actually check the hardware capabilities instead of relying on a hard-coded maximum radius.
2017-07-25 23:42:19 +00:00
// For performance we want to load at least as many pixels
// horizontally as there are threads in a warp (32 for nvidia), as
// well as enough to take advantage of shmem parallelism
const int warp_size = 32, threads = 256;
int bw = warp_size;
int bh = threads / bw;
// We need to sample everything from base_min to base_max, so make sure
// we have enough room in shmem
int iw = (int)ceil(bw / ratiox) + padding + 1,
ih = (int)ceil(bh / ratioy) + padding + 1;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
int shmem_req = iw * ih * img.components * sizeof(float);
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
if (shmem_req > p->ra->max_shmem)
vo_opengl: check against shmem limits The radius check was not strict enough, especially not for all platforms. To fix this, actually check the hardware capabilities instead of relying on a hard-coded maximum radius.
2017-07-25 23:42:19 +00:00
goto fallback;
vo_opengl: make compute shaders more flexible This allows users to do their own custom sample writing, mainly meant to address use cases such as RAVU. Also clean up the compute shader code a bit.
2017-07-29 18:41:50 +00:00
pass_is_compute(p, bw, bh);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
pass_compute_polar(p->sc, scaler, img.components, bw, bh, iw, ih);
vo_opengl: check against shmem limits The radius check was not strict enough, especially not for all platforms. To fix this, actually check the hardware capabilities instead of relying on a hard-coded maximum radius.
2017-07-25 23:42:19 +00:00
return;
fallback:
// Fall back to regular polar shader when compute shaders are unsupported
// or the kernel is too big for shmem
vo_gpu: d3d11: add RA caps for ra_d3d11 ra_d3d11 uses the SPIR-V compiler to translate GLSL to SPIR-V, which is then translated to HLSL. This means it always exposes the same GLSL version that the SPIR-V compiler supports (4.50 for shaderc/glslang.) Despite claiming to support GLSL 4.50, some features that are tied to the GLSL version in OpenGL are not supported by ra_d3d11 when targeting legacy Direct3D feature levels. This includes two features that mpv relies on: - Reading from gl_FragCoord in the fragment shader (requires FL 10_0) - textureGather from any texture component (requires FL 11_0) These features have been exposed as new RA caps.
2017-10-02 12:10:52 +00:00
pass_sample_polar(p->sc, scaler, img.components,
p->ra->caps & RA_CAP_GATHER);
vo_opengl: check against shmem limits The radius check was not strict enough, especially not for all platforms. To fix this, actually check the hardware capabilities instead of relying on a hard-coded maximum radius.
2017-07-25 23:42:19 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
// Sample from image, with the src rectangle given by it.
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
// The dst rectangle is implicit by what the caller will do next, but w and h
// must still be what is going to be used (to dimension FBOs correctly).
vo_opengl: declare vec4 color inside fragment shader stub Why was this done so stupidly, with so many complicated special cases, before? Declare it once so the shader bits don't have to figure out where and when to do so themselves.
2016-02-23 15:18:17 +00:00
// This will write the scaled contents to the vec4 "color".
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
// The scaler unit is initialized by this function; in order to avoid cache
// thrashing, the scaler unit should usually use the same parameters.
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static void pass_sample(struct gl_video *p, struct image img,
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
struct scaler *scaler, const struct scaler_config *conf,
double scale_factor, int w, int h)
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
{
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
reinit_scaler(p, scaler, conf, scale_factor, filter_sizes);
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
// Describe scaler
const char *scaler_opt[] = {
[SCALER_SCALE] = "scale",
[SCALER_DSCALE] = "dscale",
[SCALER_CSCALE] = "cscale",
[SCALER_TSCALE] = "tscale",
};
pass_describe(p, "%s=%s (%s)", scaler_opt[scaler->index],
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
scaler->conf.kernel.name, plane_names[img.type]);
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
bool is_separated = scaler->kernel && !scaler->kernel->polar;
// Set up the transformation+prelude and bind the texture, for everything
// other than separated scaling (which does this in the subfunction)
if (!is_separated)
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
sampler_prelude(p->sc, pass_bind(p, img));
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
// Dispatch the scaler. They're all wildly different.
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
const char *name = scaler->conf.kernel.name;
if (strcmp(name, "bilinear") == 0) {
vo_opengl: declare vec4 color inside fragment shader stub Why was this done so stupidly, with so many complicated special cases, before? Declare it once so the shader bits don't have to figure out where and when to do so themselves.
2016-02-23 15:18:17 +00:00
GLSL(color = texture(tex, pos);)
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
} else if (strcmp(name, "bicubic_fast") == 0) {
vo_opengl: move self-contained shader routines to a separate file This is mostly to cut down somewhat on the amount of code bloat in video.c by moving out helper functions (including scaler kernels and color management routines) to a separate file. It would certainly be possible to move out more functions (eg. dithering or CMS code) with some extra effort/refactoring, but this is a start. Signed-off-by: wm4 <wm4@nowhere>
2015-09-05 12:03:00 +00:00
pass_sample_bicubic_fast(p->sc);
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
} else if (strcmp(name, "oversample") == 0) {
vo_opengl: move self-contained shader routines to a separate file This is mostly to cut down somewhat on the amount of code bloat in video.c by moving out helper functions (including scaler kernels and color management routines) to a separate file. It would certainly be possible to move out more functions (eg. dithering or CMS code) with some extra effort/refactoring, but this is a start. Signed-off-by: wm4 <wm4@nowhere>
2015-09-05 12:03:00 +00:00
pass_sample_oversample(p->sc, scaler, w, h);
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
} else if (scaler->kernel && scaler->kernel->polar) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
pass_dispatch_sample_polar(p, scaler, img, w, h);
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
} else if (scaler->kernel) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
pass_sample_separated(p, img, scaler, w, h);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
} else {
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
// Should never happen
abort();
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
}
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
// Apply any required multipliers. Separated scaling already does this in
// its first stage
if (!is_separated)
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
GLSLF("color *= %f;\n", img.multiplier);
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
// Micro-optimization: Avoid scaling unneeded channels
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
skip_unused(p, img.components);
vo_opengl: some minor cleanups default_tex_params() and texture_size() are each called only once, so move inline/reimplement them at the caller. image_dw/dh were unused. texture_w/h, image_format, and component_bits were rarely used, and can be replaced. Regroup some other fields. Rename surface_num to surface_idx, because the former sounded like a count, and not an index. Move fbosurface_next() closer to its callers too. Move the DebugMessageCallback() code to gl_utils.c (also simplify it by always setting the callback, instead of only when it changes).
2015-01-29 14:50:21 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
// Returns true if two images are semantically equivalent (same metadata)
static bool image_equiv(struct image a, struct image b)
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
{
return a.type == b.type &&
a.components == b.components &&
a.multiplier == b.multiplier &&
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
a.tex->params.format == b.tex->params.format &&
a.tex->params.w == b.tex->params.w &&
a.tex->params.h == b.tex->params.h &&
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
a.w == b.w &&
a.h == b.h &&
vo_opengl: handle GL_LUMINANCE_ALPHA and integer textures differently GL_LUMINANCE_ALPHA is the only reason why per-plane swizzles exist. Remove per-plane swizzles (again), and regrettably handle them as special cases (again). Carry along the logical texture format (called gl_format in some parts of the code, including the new one). We also don't need a use_integer flag, since the new gl_format member implies whether it's an integer texture. (Yes, the there are separate logical GL formats for integer textures. This aspect of the OpenGL API is hysteric at best.) This should change nothing about actual rendering logic and GL API usage.
2017-02-17 14:46:11 +00:00
gl_transform_eq(a.transform, b.transform);
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
}
vo_opengl: add Super-xBR filter for upscaling Add the Super-xBR filter for image doubling, and the prescaling framework to support it. The shader code was ported from MPDN extensions project, with modification to process luma only. This commit is largely inspired by code from #2266, with `gl_transform_trans()` authored by @haasn taken directly.
2015-10-26 22:43:48 +00:00
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static void deband_hook(struct gl_video *p, struct image img,
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
struct gl_transform *trans, void *priv)
{
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
pass_describe(p, "debanding (%s)", plane_names[img.type]);
vo_opengl: scale deband-grain to the signal range This prevents blowing up for high dynamic range sources, where a noise level of 48 can suddenly mean 4800.
2017-09-03 19:51:48 +00:00
pass_sample_deband(p->sc, p->opts.deband_opts, &p->lfg,
p->image_params.color.gamma);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
}
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static void unsharp_hook(struct gl_video *p, struct image img,
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
struct gl_transform *trans, void *priv)
{
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
pass_describe(p, "unsharp masking");
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
pass_sample_unsharp(p->sc, p->opts.unsharp);
}
vo_opengl: move eval_szexpr to user_shaders.c This moves some of the bulky user-shader specific logic into the file dedicated to it. Rather than expose video.c state, variable lookup is now done via a simulated closure.
2016-07-03 17:23:03 +00:00
struct szexp_ctx {
struct gl_video *p;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct image img;
vo_opengl: move eval_szexpr to user_shaders.c This moves some of the bulky user-shader specific logic into the file dedicated to it. Rather than expose video.c state, variable lookup is now done via a simulated closure.
2016-07-03 17:23:03 +00:00
};
vo_opengl: use RPN expressions for user hook sizes This replaces the previous TRANSFORM by WIDTH, HEIGHT and OFFSET where WIDTH and HEIGHT are RPN expressions. This allows for more fine-grained control over the output size, and also makes sure that overwriting existing textures works more cleanly. (Also add some more useful bstr functions)
2016-05-12 01:34:47 +00:00
vo_opengl: move eval_szexpr to user_shaders.c This moves some of the bulky user-shader specific logic into the file dedicated to it. Rather than expose video.c state, variable lookup is now done via a simulated closure.
2016-07-03 17:23:03 +00:00
static bool szexp_lookup(void *priv, struct bstr var, float size[2])
{
struct szexp_ctx *ctx = priv;
struct gl_video *p = ctx->p;
vo_opengl: make size of a cropped source image available to user shaders
2016-07-03 12:06:41 +00:00
if (bstr_equals0(var, "NATIVE_CROPPED")) {
size[0] = (p->src_rect.x1 - p->src_rect.x0) * p->texture_offset.m[0][0];
size[1] = (p->src_rect.y1 - p->src_rect.y0) * p->texture_offset.m[1][1];
return true;
}
vo_opengl: move eval_szexpr to user_shaders.c This moves some of the bulky user-shader specific logic into the file dedicated to it. Rather than expose video.c state, variable lookup is now done via a simulated closure.
2016-07-03 17:23:03 +00:00
// The size of OUTPUT is determined. It could be useful for certain
// user shaders to skip passes.
if (bstr_equals0(var, "OUTPUT")) {
size[0] = p->dst_rect.x1 - p->dst_rect.x0;
size[1] = p->dst_rect.y1 - p->dst_rect.y0;
return true;
}
vo_opengl: use RPN expressions for user hook sizes This replaces the previous TRANSFORM by WIDTH, HEIGHT and OFFSET where WIDTH and HEIGHT are RPN expressions. This allows for more fine-grained control over the output size, and also makes sure that overwriting existing textures works more cleanly. (Also add some more useful bstr functions)
2016-05-12 01:34:47 +00:00
vo_opengl: move eval_szexpr to user_shaders.c This moves some of the bulky user-shader specific logic into the file dedicated to it. Rather than expose video.c state, variable lookup is now done via a simulated closure.
2016-07-03 17:23:03 +00:00
// HOOKED is a special case
if (bstr_equals0(var, "HOOKED")) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
size[0] = ctx->img.w;
size[1] = ctx->img.h;
vo_opengl: move eval_szexpr to user_shaders.c This moves some of the bulky user-shader specific logic into the file dedicated to it. Rather than expose video.c state, variable lookup is now done via a simulated closure.
2016-07-03 17:23:03 +00:00
return true;
vo_opengl: use RPN expressions for user hook sizes This replaces the previous TRANSFORM by WIDTH, HEIGHT and OFFSET where WIDTH and HEIGHT are RPN expressions. This allows for more fine-grained control over the output size, and also makes sure that overwriting existing textures works more cleanly. (Also add some more useful bstr functions)
2016-05-12 01:34:47 +00:00
}
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
for (int o = 0; o < p->num_saved_imgs; o++) {
if (bstr_equals0(var, p->saved_imgs[o].name)) {
size[0] = p->saved_imgs[o].img.w;
size[1] = p->saved_imgs[o].img.h;
vo_opengl: move eval_szexpr to user_shaders.c This moves some of the bulky user-shader specific logic into the file dedicated to it. Rather than expose video.c state, variable lookup is now done via a simulated closure.
2016-07-03 17:23:03 +00:00
return true;
}
vo_opengl: use RPN expressions for user hook sizes This replaces the previous TRANSFORM by WIDTH, HEIGHT and OFFSET where WIDTH and HEIGHT are RPN expressions. This allows for more fine-grained control over the output size, and also makes sure that overwriting existing textures works more cleanly. (Also add some more useful bstr functions)
2016-05-12 01:34:47 +00:00
}
vo_opengl: move eval_szexpr to user_shaders.c This moves some of the bulky user-shader specific logic into the file dedicated to it. Rather than expose video.c state, variable lookup is now done via a simulated closure.
2016-07-03 17:23:03 +00:00
return false;
vo_opengl: make user hook passes optional User hooks can now use an extra WHEN expression to specify when the shader should be run. For example, this can be used to only run a chroma scaling shader `WHEN CHROMA.w LUMA.w <`. There's a slight semantics change to user shaders: When trying to bind a texture that does not exist, a shader will now be silently skipped (similar to when the condition is false) instead of generating an error. This allows shader stages to depend on an optional earlier stage without having to copy/paste the same condition everywhere. (In other words: there's an implicit condition on all of the bound textures existing)
2016-06-08 13:05:28 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static bool user_hook_cond(struct gl_video *p, struct image img, void *priv)
vo_opengl: make user hook passes optional User hooks can now use an extra WHEN expression to specify when the shader should be run. For example, this can be used to only run a chroma scaling shader `WHEN CHROMA.w LUMA.w <`. There's a slight semantics change to user shaders: When trying to bind a texture that does not exist, a shader will now be silently skipped (similar to when the condition is false) instead of generating an error. This allows shader stages to depend on an optional earlier stage without having to copy/paste the same condition everywhere. (In other words: there's an implicit condition on all of the bound textures existing)
2016-06-08 13:05:28 +00:00
{
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
struct gl_user_shader_hook *shader = priv;
vo_opengl: make user hook passes optional User hooks can now use an extra WHEN expression to specify when the shader should be run. For example, this can be used to only run a chroma scaling shader `WHEN CHROMA.w LUMA.w <`. There's a slight semantics change to user shaders: When trying to bind a texture that does not exist, a shader will now be silently skipped (similar to when the condition is false) instead of generating an error. This allows shader stages to depend on an optional earlier stage without having to copy/paste the same condition everywhere. (In other words: there's an implicit condition on all of the bound textures existing)
2016-06-08 13:05:28 +00:00
assert(shader);
float res = false;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct szexp_ctx ctx = {p, img};
eval_szexpr(p->log, &ctx, szexp_lookup, shader->cond, &res);
vo_opengl: make user hook passes optional User hooks can now use an extra WHEN expression to specify when the shader should be run. For example, this can be used to only run a chroma scaling shader `WHEN CHROMA.w LUMA.w <`. There's a slight semantics change to user shaders: When trying to bind a texture that does not exist, a shader will now be silently skipped (similar to when the condition is false) instead of generating an error. This allows shader stages to depend on an optional earlier stage without having to copy/paste the same condition everywhere. (In other words: there's an implicit condition on all of the bound textures existing)
2016-06-08 13:05:28 +00:00
return res;
vo_opengl: use RPN expressions for user hook sizes This replaces the previous TRANSFORM by WIDTH, HEIGHT and OFFSET where WIDTH and HEIGHT are RPN expressions. This allows for more fine-grained control over the output size, and also makes sure that overwriting existing textures works more cleanly. (Also add some more useful bstr functions)
2016-05-12 01:34:47 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static void user_hook(struct gl_video *p, struct image img,
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
struct gl_transform *trans, void *priv)
{
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
struct gl_user_shader_hook *shader = priv;
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
assert(shader);
vo_opengl: make compute shaders more flexible This allows users to do their own custom sample writing, mainly meant to address use cases such as RAVU. Also clean up the compute shader code a bit.
2017-07-29 18:41:50 +00:00
load_shader(p, shader->pass_body);
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
vo_opengl: slightly refactor user_shaders code - Each struct tex_hook now stores multiple hooks, this allows us to avoid the awkward way of the current code has to add the same pass multiple times. - As a consequence, SHADER_MAX_HOOKS was split up into SHADER_MAX_PASSES (number of tex_hooks) and SHADER_MAX_HOOKS (number of hooked textures per tex_hook), and both numbers decreased correspondingly. - Instead of having a weird free() callback, we can just leverage talloc's recursive free behavior. The only user is the user shaders code anyway.
2017-07-10 20:52:39 +00:00
pass_describe(p, "user shader: %.*s (%s)", BSTR_P(shader->pass_desc),
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
plane_names[img.type]);
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
vo_opengl: make compute shaders more flexible This allows users to do their own custom sample writing, mainly meant to address use cases such as RAVU. Also clean up the compute shader code a bit.
2017-07-29 18:41:50 +00:00
if (shader->compute.active) {
p->pass_compute = shader->compute;
GLSLF("hook();\n");
} else {
GLSLF("color = hook();\n");
}
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
vo_opengl: make user hook passes optional User hooks can now use an extra WHEN expression to specify when the shader should be run. For example, this can be used to only run a chroma scaling shader `WHEN CHROMA.w LUMA.w <`. There's a slight semantics change to user shaders: When trying to bind a texture that does not exist, a shader will now be silently skipped (similar to when the condition is false) instead of generating an error. This allows shader stages to depend on an optional earlier stage without having to copy/paste the same condition everywhere. (In other words: there's an implicit condition on all of the bound textures existing)
2016-06-08 13:05:28 +00:00
// Make sure we at least create a legal FBO on failure, since it's better
// to do this and display an error message than just crash OpenGL
float w = 1.0, h = 1.0;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
eval_szexpr(p->log, &(struct szexp_ctx){p, img}, szexp_lookup, shader->width, &w);
eval_szexpr(p->log, &(struct szexp_ctx){p, img}, szexp_lookup, shader->height, &h);
vo_opengl: use RPN expressions for user hook sizes This replaces the previous TRANSFORM by WIDTH, HEIGHT and OFFSET where WIDTH and HEIGHT are RPN expressions. This allows for more fine-grained control over the output size, and also makes sure that overwriting existing textures works more cleanly. (Also add some more useful bstr functions)
2016-05-12 01:34:47 +00:00
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
*trans = (struct gl_transform){{{w / img.w, 0}, {0, h / img.h}}};
vo_opengl: use RPN expressions for user hook sizes This replaces the previous TRANSFORM by WIDTH, HEIGHT and OFFSET where WIDTH and HEIGHT are RPN expressions. This allows for more fine-grained control over the output size, and also makes sure that overwriting existing textures works more cleanly. (Also add some more useful bstr functions)
2016-05-12 01:34:47 +00:00
gl_transform_trans(shader->offset, trans);
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
}
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
static bool add_user_hook(void *priv, struct gl_user_shader_hook hook)
{
struct gl_video *p = priv;
struct gl_user_shader_hook *copy = talloc_ptrtype(p, copy);
*copy = hook;
struct tex_hook texhook = {
.save_tex = bstrdup0(copy, hook.save_tex),
.components = hook.components,
.hook = user_hook,
.cond = user_hook_cond,
.priv = copy,
};
for (int h = 0; h < SHADER_MAX_HOOKS; h++)
texhook.hook_tex[h] = bstrdup0(copy, hook.hook_tex[h]);
for (int h = 0; h < SHADER_MAX_BINDS; h++)
texhook.bind_tex[h] = bstrdup0(copy, hook.bind_tex[h]);
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
MP_TARRAY_APPEND(p, p->tex_hooks, p->num_tex_hooks, texhook);
return true;
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
}
static bool add_user_tex(void *priv, struct gl_user_shader_tex tex)
{
struct gl_video *p = priv;
vo_opengl: simplify/fix user shader textures This broke float textures, which were actually used by some shaders. There were probably some other bugs as well. Lots of code can be avoided by using ra_tex_params directly, so do that. The main change is that COMPONENT/FORMAT are replaced by a single FORMAT directive, which takes different parameters now. Due to the mess with 16/32 bit float textures, and because we want to support other APIs than just GL in the future, it's not really clear how this should be handled, and the nice component/type separation makes things actually harder. So just jump the gun and use the ra_format.name names, which were originally meant mostly for debugging. (This is probably something that will be regretted later.) Still only superficially tested, but seems to work. Fixes #4708.
2017-08-03 14:08:18 +00:00
tex.tex = ra_tex_create(p->ra, &tex.params);
TA_FREEP(&tex.params.initial_data);
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
if (!tex.tex)
return false;
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
MP_TARRAY_APPEND(p, p->user_textures, p->num_user_textures, tex);
return true;
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
}
static void load_user_shaders(struct gl_video *p, char **shaders)
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
{
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
if (!shaders)
return;
for (int n = 0; shaders[n] != NULL; n++) {
struct bstr file = load_cached_file(p, shaders[n]);
vo_opengl: simplify/fix user shader textures This broke float textures, which were actually used by some shaders. There were probably some other bugs as well. Lots of code can be avoided by using ra_tex_params directly, so do that. The main change is that COMPONENT/FORMAT are replaced by a single FORMAT directive, which takes different parameters now. Due to the mess with 16/32 bit float textures, and because we want to support other APIs than just GL in the future, it's not really clear how this should be handled, and the nice component/type separation makes things actually harder. So just jump the gun and use the ra_format.name names, which were originally meant mostly for debugging. (This is probably something that will be regretted later.) Still only superficially tested, but seems to work. Fixes #4708.
2017-08-03 14:08:18 +00:00
parse_user_shader(p->log, p->ra, file, p, add_user_hook, add_user_tex);
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
}
}
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
static void gl_video_setup_hooks(struct gl_video *p)
{
vo_opengl: fix/simplify reinitialization on dynamic reconfiguration With the new hooks mechanism, user shaders and such are actually loaded before rendering starts, instead of being loaded during rendering. This is used to cache them (instead of e.g. reparsing them every frame). The cached state wasn't cleared correctly in some situations. Namely, resizing didn't correctly enable/disable prescale hooks. Reorganize how these reinitializations are handled. Get rid of reinit_rendering(), whose meaning was pretty unclear. Call the required functions to reset or recreate state directly wherever they are needed.
2016-05-18 15:47:10 +00:00
gl_video_reset_hooks(p);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
if (p->opts.deband) {
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
MP_TARRAY_APPEND(p, p->tex_hooks, p->num_tex_hooks, (struct tex_hook) {
vo_opengl: slightly refactor user_shaders code - Each struct tex_hook now stores multiple hooks, this allows us to avoid the awkward way of the current code has to add the same pass multiple times. - As a consequence, SHADER_MAX_HOOKS was split up into SHADER_MAX_PASSES (number of tex_hooks) and SHADER_MAX_HOOKS (number of hooked textures per tex_hook), and both numbers decreased correspondingly. - Instead of having a weird free() callback, we can just leverage talloc's recursive free behavior. The only user is the user shaders code anyway.
2017-07-10 20:52:39 +00:00
.hook_tex = {"LUMA", "CHROMA", "RGB", "XYZ"},
.bind_tex = {"HOOKED"},
.hook = deband_hook,
});
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
}
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
if (p->opts.unsharp != 0.0) {
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
MP_TARRAY_APPEND(p, p->tex_hooks, p->num_tex_hooks, (struct tex_hook) {
vo_opengl: slightly refactor user_shaders code - Each struct tex_hook now stores multiple hooks, this allows us to avoid the awkward way of the current code has to add the same pass multiple times. - As a consequence, SHADER_MAX_HOOKS was split up into SHADER_MAX_PASSES (number of tex_hooks) and SHADER_MAX_HOOKS (number of hooked textures per tex_hook), and both numbers decreased correspondingly. - Instead of having a weird free() callback, we can just leverage talloc's recursive free behavior. The only user is the user shaders code anyway.
2017-07-10 20:52:39 +00:00
.hook_tex = {"MAIN"},
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
.bind_tex = {"HOOKED"},
.hook = unsharp_hook,
});
}
vo_opengl: support loading custom user textures Parsing the texture data as raw strings makes the textures the most portable and self-contained. In order to facilitate different types of shaders, the parse_user_shader interaction has been changed to instead have it loop through blocks and call the passed functions for each valid block parsed. This is more modular and also cleaner, with better code separation. Closes #4586.
2017-07-10 23:59:21 +00:00
load_user_shaders(p, p->opts.user_shaders);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
}
vo_opengl: support 10 bit support with ANGLE GLES does not support high bit depth fixed point textures for unknown reasons, so direct 10 bit input is not possible. But we can still use integer textures, which are supported by GLES 3.0. These store integer data just like the standard fixed point textures, except they are not normalized on sampling. They also don't support bilinear filtering, and require a special sampler ("usampler2D"). While these texture formats enable us to shuffle the data to the GPU, they're rather impractical with the requirements mentioned above and our current architecture. One problem is that most code assumes it can always use bilinear scaling (even if bilinear is never used when using appropriate scale/cscale options). Another is that we don't have any concept of running a function on a texture in an uniform way. So for now, run a simple conversion step through a FBO. The FBO will use the rgba16f format normally, which gives enough bits for 10 bit, and will at least gracefully degrade with higher depth input. This is bound to be much slower than a more "direct" method, but at least it works and is simple to implement. The odd change of function call order in init_video() is to properly disable "dumb mode" (no FBO use) if these texture formats are in use.
2016-01-26 19:47:32 +00:00
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
// sample from video textures, set "color" variable to yuv value
static void pass_read_video(struct gl_video *p)
{
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct image img[4];
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
struct gl_transform offsets[4];
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
pass_get_images(p, &p->image, img, offsets);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
// To keep the code as simple as possibly, we currently run all shader
// stages even if they would be unnecessary (e.g. no hooks for a texture).
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
// In the future, deferred image should optimize this away.
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
// Merge semantically identical textures. This loop is done from back
// to front so that merged textures end up in the right order while
// simultaneously allowing us to skip unnecessary merges
for (int n = 3; n >= 0; n--) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
if (img[n].type == PLANE_NONE)
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
continue;
vo_opengl: support 10 bit support with ANGLE GLES does not support high bit depth fixed point textures for unknown reasons, so direct 10 bit input is not possible. But we can still use integer textures, which are supported by GLES 3.0. These store integer data just like the standard fixed point textures, except they are not normalized on sampling. They also don't support bilinear filtering, and require a special sampler ("usampler2D"). While these texture formats enable us to shuffle the data to the GPU, they're rather impractical with the requirements mentioned above and our current architecture. One problem is that most code assumes it can always use bilinear scaling (even if bilinear is never used when using appropriate scale/cscale options). Another is that we don't have any concept of running a function on a texture in an uniform way. So for now, run a simple conversion step through a FBO. The FBO will use the rgba16f format normally, which gives enough bits for 10 bit, and will at least gracefully degrade with higher depth input. This is bound to be much slower than a more "direct" method, but at least it works and is simple to implement. The odd change of function call order in init_video() is to properly disable "dumb mode" (no FBO use) if these texture formats are in use.
2016-01-26 19:47:32 +00:00
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
int first = n;
int num = 0;
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
for (int i = 0; i < n; i++) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
if (image_equiv(img[n], img[i]) &&
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
gl_transform_eq(offsets[n], offsets[i]))
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
{
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
GLSLF("// merging plane %d ...\n", i);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
copy_image(p, &num, img[i]);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
first = MPMIN(first, i);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
img[i] = (struct image){0};
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
}
vo_opengl: implement debanding (and remove source-shader) The removal of source-shader is a side effect, since this effectively replaces it - and the video-reading code has been significantly restructured to make more sense and be more readable. This means users no longer have to constantly download and maintain a separate deband.glsl installation alongside mpv, which was the only real use case for source-shader that we found either way.
2015-09-05 15:39:27 +00:00
}
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
if (num > 0) {
GLSLF("// merging plane %d ... into %d\n", n, first);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
copy_image(p, &num, img[n]);
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
pass_describe(p, "merging planes");
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
finish_pass_tex(p, &p->merge_tex[n], img[n].w, img[n].h);
img[first] = image_wrap(p->merge_tex[n], img[n].type, num);
img[n] = (struct image){0};
vo_opengl: implement debanding (and remove source-shader) The removal of source-shader is a side effect, since this effectively replaces it - and the video-reading code has been significantly restructured to make more sense and be more readable. This means users no longer have to constantly download and maintain a separate deband.glsl installation alongside mpv, which was the only real use case for source-shader that we found either way.
2015-09-05 15:39:27 +00:00
}
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
}
vo_opengl: fix source-shader + XYZ input
2015-04-12 01:34:38 +00:00
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
// If any textures are still in integer format by this point, we need
// to introduce an explicit conversion pass to avoid breaking hooks/scaling
for (int n = 0; n < 4; n++) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
if (img[n].tex && img[n].tex->params.format->ctype == RA_CTYPE_UINT) {
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
GLSLF("// use_integer fix for plane %d\n", n);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
copy_image(p, &(int){0}, img[n]);
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
pass_describe(p, "use_integer fix");
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
finish_pass_tex(p, &p->integer_tex[n], img[n].w, img[n].h);
img[n] = image_wrap(p->integer_tex[n], img[n].type,
img[n].components);
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
}
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
}
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
// Dispatch the hooks for all of these textures, saving and perhaps
// modifying them in the process
for (int n = 0; n < 4; n++) {
const char *name;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
switch (img[n].type) {
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
case PLANE_RGB: name = "RGB"; break;
case PLANE_LUMA: name = "LUMA"; break;
case PLANE_CHROMA: name = "CHROMA"; break;
case PLANE_ALPHA: name = "ALPHA"; break;
case PLANE_XYZ: name = "XYZ"; break;
default: continue;
}
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
img[n] = pass_hook(p, name, img[n], &offsets[n]);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
}
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
// At this point all planes are finalized but they may not be at the
// required size yet. Furthermore, they may have texture offsets that
// require realignment. For lack of something better to do, we assume
// the rgb/luma texture is the "reference" and scale everything else
// to match.
for (int n = 0; n < 4; n++) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
switch (img[n].type) {
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
case PLANE_RGB:
case PLANE_XYZ:
case PLANE_LUMA: break;
default: continue;
vo_opengl: add Super-xBR filter for upscaling Add the Super-xBR filter for image doubling, and the prescaling framework to support it. The shader code was ported from MPDN extensions project, with modification to process luma only. This commit is largely inspired by code from #2266, with `gl_transform_trans()` authored by @haasn taken directly.
2015-10-26 22:43:48 +00:00
}
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
p->texture_w = img[n].w;
p->texture_h = img[n].h;
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
p->texture_offset = offsets[n];
break;
}
// Compute the reference rect
struct mp_rect_f src = {0.0, 0.0, p->image_params.w, p->image_params.h};
struct mp_rect_f ref = src;
gl_transform_rect(p->texture_offset, &ref);
// Explicitly scale all of the textures that don't match
for (int n = 0; n < 4; n++) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
if (img[n].type == PLANE_NONE)
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
continue;
vo_opengl: add Super-xBR filter for upscaling Add the Super-xBR filter for image doubling, and the prescaling framework to support it. The shader code was ported from MPDN extensions project, with modification to process luma only. This commit is largely inspired by code from #2266, with `gl_transform_trans()` authored by @haasn taken directly.
2015-10-26 22:43:48 +00:00
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
// If the planes are aligned identically, we will end up with the
// exact same source rectangle.
struct mp_rect_f rect = src;
gl_transform_rect(offsets[n], &rect);
if (mp_rect_f_seq(ref, rect))
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
continue;
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
// If the rectangles differ, then our planes have a different
// alignment and/or size. First of all, we have to compute the
// corrections required to meet the target rectangle
struct gl_transform fix = {
.m = {{(ref.x1 - ref.x0) / (rect.x1 - rect.x0), 0.0},
{0.0, (ref.y1 - ref.y0) / (rect.y1 - rect.y0)}},
.t = {ref.x0, ref.y0},
};
// Since the scale in texture space is different from the scale in
// absolute terms, we have to scale the coefficients down to be
// relative to the texture's physical dimensions and local offset
struct gl_transform scale = {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
.m = {{(float)img[n].w / p->texture_w, 0.0},
{0.0, (float)img[n].h / p->texture_h}},
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
.t = {-rect.x0, -rect.y0},
};
vo_opengl: partially fix rotation for 4:2:2 content The chroma alignment renormalization code forgot to account for the fact that the chroma subsampling ratio has to be rotated. Unfortunately, doing it this way seems to have somewhat broken the chroma offset rotation logic for odd-sized subsampled image files. While this is a bug, it's much, much less noticeable, so it's not nearly as important as the bug this change fixes. Either way, a future patch needs to still revise this logic, ideally by redesigning the entire rotation mechanism.
2016-12-28 01:46:55 +00:00
if (p->image_params.rotate % 180 == 90)
MPSWAP(double, scale.m[0][0], scale.m[1][1]);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
gl_transform_trans(scale, &fix);
// Since the texture transform is a function of the texture coordinates
// to texture space, rather than the other way around, we have to
// actually apply the *inverse* of this. Fortunately, calculating
// the inverse is relatively easy here.
fix.m[0][0] = 1.0 / fix.m[0][0];
fix.m[1][1] = 1.0 / fix.m[1][1];
fix.t[0] = fix.m[0][0] * -fix.t[0];
fix.t[1] = fix.m[1][1] * -fix.t[1];
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
gl_transform_trans(fix, &img[n].transform);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
int scaler_id = -1;
const char *name = NULL;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
switch (img[n].type) {
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
case PLANE_RGB:
case PLANE_LUMA:
case PLANE_XYZ:
scaler_id = SCALER_SCALE;
// these aren't worth hooking, fringe hypothetical cases only
break;
case PLANE_CHROMA:
scaler_id = SCALER_CSCALE;
name = "CHROMA_SCALED";
break;
case PLANE_ALPHA:
// alpha always uses bilinear
name = "ALPHA_SCALED";
vo_opengl: add Super-xBR filter for upscaling Add the Super-xBR filter for image doubling, and the prescaling framework to support it. The shader code was ported from MPDN extensions project, with modification to process luma only. This commit is largely inspired by code from #2266, with `gl_transform_trans()` authored by @haasn taken directly.
2015-10-26 22:43:48 +00:00
}
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
if (scaler_id < 0)
continue;
const struct scaler_config *conf = &p->opts.scaler[scaler_id];
struct scaler *scaler = &p->scaler[scaler_id];
// bilinear scaling is a free no-op thanks to GPU sampling
if (strcmp(conf->kernel.name, "bilinear") != 0) {
GLSLF("// upscaling plane %d\n", n);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
pass_sample(p, img[n], scaler, conf, 1.0, p->texture_w, p->texture_h);
finish_pass_tex(p, &p->scale_tex[n], p->texture_w, p->texture_h);
img[n] = image_wrap(p->scale_tex[n], img[n].type, img[n].components);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
}
// Run any post-scaling hooks
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
img[n] = pass_hook(p, name, img[n], NULL);
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
}
vo_opengl: add Super-xBR filter for upscaling Add the Super-xBR filter for image doubling, and the prescaling framework to support it. The shader code was ported from MPDN extensions project, with modification to process luma only. This commit is largely inspired by code from #2266, with `gl_transform_trans()` authored by @haasn taken directly.
2015-10-26 22:43:48 +00:00
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
// All planes are of the same size and properly aligned at this point
vo_gpu: describe the plane merging pass This can get left unknown if something hooks NATIVE
2017-09-16 01:28:38 +00:00
pass_describe(p, "combining planes");
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
int coord = 0;
for (int i = 0; i < 4; i++) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
if (img[i].type != PLANE_NONE)
copy_image(p, &coord, img[i]);
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
}
vo_opengl: refactor plane-skipping optimizations Instead of hard-coding the logic and planes to skip, factor this out to a reusible function, and instead add the number of relevant coordinates to the texture state.
2016-03-05 11:38:51 +00:00
p->components = coord;
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
// Utility function that simply binds a texture and reads from it, without any
vo_opengl: get rid of weird double-bind in pass_read_fbo 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.
2017-07-04 23:31:31 +00:00
// transformations.
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static void pass_read_tex(struct gl_video *p, struct ra_tex *tex)
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
{
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct image img = image_wrap(tex, PLANE_RGB, p->components);
copy_image(p, &(int){0}, img);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
}
// yuv conversion, and any other conversions before main up/down-scaling
static void pass_convert_yuv(struct gl_video *p)
{
struct gl_shader_cache *sc = p->sc;
vo_opengl: greatly increase smoothmotion performance Instead of rendering and upscaling each video frame on every vsync, this version of the algorithm only draws them once and caches the result, so the only operation that has to run on every vsync is a cheap linear interpolation, plus CMS/dithering. On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz monitor), up to 120% faster. (The speedup is not quite 250% because of the overhead that the larger FBOs and CMS provides) In terms of the implementation, this commit basically swaps interpolation and upscaling - upscaling is moved to inter_program, and interpolation is moved to the final_program. Furthermore, the main bulk of the frame rendering logic (upscaling etc.) was moved to a separete function, which is called from gl_video_interpolate_frame only if it's actually necessarily, and skipped otherwise.
2015-02-20 21:12:02 +00:00
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
struct mp_csp_params cparams = MP_CSP_PARAMS_DEFAULTS;
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
cparams.gray = p->is_gray;
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
mp_csp_set_image_params(&cparams, &p->image_params);
video: redo video equalizer option handling I really wouldn't care much about this, but some parts of the core code are under HAVE_GPL, so there's some need to get rid of it. Simply turn the video equalizer from its current fine-grained handling with vf/vo fallbacks into global options. This makes updating them much simpler. This removes any possibility of applying video equalizers in filters, which affects vf_scale, and the previously removed vf_eq. Not a big loss, since the preferred VOs have this builtin. Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and vo_xv. I'm not going to waste my time on these legacy VOs. vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which exists _only_ to trigger a redraw. This seems silly, but for now I feel like this is less of a pain. The rest of the equalizer using code is self-updating. See commit 96b906a51d5 for how some video equalizer code was GPL only. Some command line option names and ranges can probably be traced back to a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
mp_csp_equalizer_state_get(p->video_eq, &cparams);
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
p->user_gamma = 1.0 / (cparams.gamma * p->opts.gamma);
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
pass_describe(p, "color conversion");
vo_opengl: greatly increase smoothmotion performance Instead of rendering and upscaling each video frame on every vsync, this version of the algorithm only draws them once and caches the result, so the only operation that has to run on every vsync is a cheap linear interpolation, plus CMS/dithering. On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz monitor), up to 120% faster. (The speedup is not quite 250% because of the overhead that the larger FBOs and CMS provides) In terms of the implementation, this commit basically swaps interpolation and upscaling - upscaling is moved to inter_program, and interpolation is moved to the final_program. Furthermore, the main bulk of the frame rendering logic (upscaling etc.) was moved to a separete function, which is called from gl_video_interpolate_frame only if it's actually necessarily, and skipped otherwise.
2015-02-20 21:12:02 +00:00
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
if (p->color_swizzle[0])
GLSLF("color = color.%s;\n", p->color_swizzle);
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
// Pre-colormatrix input gamma correction
mp_image: split colorimetry metadata into its own struct This has two reasons: 1. I tend to add new fields to this metadata, and every time I've done so I've consistently forgotten to update all of the dozens of places in which this colorimetry metadata might end up getting used. While most usages don't really care about most of the metadata, sometimes the intend was simply to “copy” the colorimetry metadata from one struct to another. With this being inside a substruct, those lines of code can now simply read a.color = b.color without having to care about added or removed fields. 2. It makes the type definitions nicer for upcoming refactors. In going through all of the usages, I also expanded a few where I felt that omitting the “young” fields was a bug.
2016-06-29 07:16:13 +00:00
if (cparams.color.space == MP_CSP_XYZ)
vo_opengl: remove one more XYZ special-case The XYZ colorspace on XYZ pixfmt is enforced in some sanitation routine.
2015-12-09 16:10:38 +00:00
GLSL(color.rgb = pow(color.rgb, vec3(2.6));) // linear light
vo_opengl: greatly increase smoothmotion performance Instead of rendering and upscaling each video frame on every vsync, this version of the algorithm only draws them once and caches the result, so the only operation that has to run on every vsync is a cheap linear interpolation, plus CMS/dithering. On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz monitor), up to 120% faster. (The speedup is not quite 250% because of the overhead that the larger FBOs and CMS provides) In terms of the implementation, this commit basically swaps interpolation and upscaling - upscaling is moved to inter_program, and interpolation is moved to the final_program. Furthermore, the main bulk of the frame rendering logic (upscaling etc.) was moved to a separete function, which is called from gl_video_interpolate_frame only if it's actually necessarily, and skipped otherwise.
2015-02-20 21:12:02 +00:00
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
// We always explicitly normalize the range in pass_read_video
cparams.input_bits = cparams.texture_bits = 0;
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
vo_opengl: enable colormatrix even for RGB input Enables brightness/contrast controls, and handles gbrp10 correctly.
2015-12-07 22:45:41 +00:00
// Conversion to RGB. For RGB itself, this still applies e.g. brightness
// and contrast controls, or expansion of e.g. LSB-packed 10 bit data.
struct mp_cmat m = {{{0}}};
csputils: rename "yuv2rgb" functions They're not necessarily restricted to YUV aka YCbCr. vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
2015-12-08 23:22:12 +00:00
mp_get_csp_matrix(&cparams, &m);
vo_opengl: enable colormatrix even for RGB input Enables brightness/contrast controls, and handles gbrp10 correctly.
2015-12-07 22:45:41 +00:00
gl_sc_uniform_mat3(sc, "colormatrix", true, &m.m[0][0]);
gl_sc_uniform_vec3(sc, "colormatrix_c", m.c);
GLSL(color.rgb = mat3(colormatrix) * color.rgb + colormatrix_c;)
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
mp_image: split colorimetry metadata into its own struct This has two reasons: 1. I tend to add new fields to this metadata, and every time I've done so I've consistently forgotten to update all of the dozens of places in which this colorimetry metadata might end up getting used. While most usages don't really care about most of the metadata, sometimes the intend was simply to “copy” the colorimetry metadata from one struct to another. With this being inside a substruct, those lines of code can now simply read a.color = b.color without having to care about added or removed fields. 2. It makes the type definitions nicer for upcoming refactors. In going through all of the usages, I also expanded a few where I felt that omitting the “young” fields was a bug.
2016-06-29 07:16:13 +00:00
if (p->image_params.color.space == MP_CSP_BT_2020_C) {
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
// Conversion for C'rcY'cC'bc via the BT.2020 CL system:
// C'bc = (B'-Y'c) / 1.9404 | C'bc <= 0
// = (B'-Y'c) / 1.5816 | C'bc > 0
//
// C'rc = (R'-Y'c) / 1.7184 | C'rc <= 0
// = (R'-Y'c) / 0.9936 | C'rc > 0
//
// as per the BT.2020 specification, table 4. This is a non-linear
// transformation because (constant) luminance receives non-equal
// contributions from the three different channels.
GLSLF("// constant luminance conversion\n");
GLSL(color.br = color.br * mix(vec2(1.5816, 0.9936),
vec2(1.9404, 1.7184),
lessThanEqual(color.br, vec2(0)))
+ color.gg;)
// Expand channels to camera-linear light. This shader currently just
// assumes everything uses the BT.2020 12-bit gamma function, since the
// difference between 10 and 12-bit is negligible for anything other
// than 12-bit content.
vo_opengl: avoid constant divisions 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
2017-07-17 03:23:55 +00:00
GLSL(color.rgb = mix(color.rgb * vec3(1.0/4.5),
pow((color.rgb + vec3(0.0993))*vec3(1.0/1.0993),
vec3(1.0/0.45)),
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
lessThanEqual(vec3(0.08145), color.rgb));)
// Calculate the green channel from the expanded RYcB
// The BT.2020 specification says Yc = 0.2627*R + 0.6780*G + 0.0593*B
vo_opengl: avoid constant divisions 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
2017-07-17 03:23:55 +00:00
GLSL(color.g = (color.g - 0.2627*color.r - 0.0593*color.b)*1.0/0.6780;)
vo_opengl: fix incorrect wording in comment "compand" was used where the actual operation was "compress". Change to avoid confusion.
2015-03-14 02:04:23 +00:00
// Recompress to receive the R'G'B' result, same as other systems
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
GLSL(color.rgb = mix(color.rgb * vec3(4.5),
vec3(1.0993) * pow(color.rgb, vec3(0.45)) - vec3(0.0993),
lessThanEqual(vec3(0.0181), color.rgb));)
}
vo_opengl: refactor plane-skipping optimizations Instead of hard-coding the logic and planes to skip, factor this out to a reusible function, and instead add the number of relevant coordinates to the texture state.
2016-03-05 11:38:51 +00:00
p->components = 3;
vo_opengl: use enums for choice options internally This is much more readable than hard-coding magic IDs all over the file, and removes the need for all the explanatory comments that were a direct result of this.
2016-05-15 22:14:02 +00:00
if (!p->has_alpha || p->opts.alpha_mode == ALPHA_NO) {
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
GLSL(color.a = 1.0;)
vo_opengl: refactor plane-skipping optimizations Instead of hard-coding the logic and planes to skip, factor this out to a reusible function, and instead add the number of relevant coordinates to the texture state.
2016-03-05 11:38:51 +00:00
} else { // alpha present in image
p->components = 4;
vo_opengl: always premultiply alpha Until now, we've let the windowing backend decide. But since they usually require premultiplied alpha, and premultiplied alpha is easier to handle, hardcode it.
2016-03-29 19:56:38 +00:00
GLSL(color = vec4(color.rgb * color.a, color.a);)
vo_opengl: apply alpha after conversion to rgb Currently this was done before conversion, which could fuck up a hypothetical YUVA stream.
2015-03-13 20:29:04 +00:00
}
vo_opengl: greatly increase smoothmotion performance Instead of rendering and upscaling each video frame on every vsync, this version of the algorithm only draws them once and caches the result, so the only operation that has to run on every vsync is a cheap linear interpolation, plus CMS/dithering. On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz monitor), up to 120% faster. (The speedup is not quite 250% because of the overhead that the larger FBOs and CMS provides) In terms of the implementation, this commit basically swaps interpolation and upscaling - upscaling is moved to inter_program, and interpolation is moved to the final_program. Furthermore, the main bulk of the frame rendering logic (upscaling etc.) was moved to a separete function, which is called from gl_video_interpolate_frame only if it's actually necessarily, and skipped otherwise.
2015-02-20 21:12:02 +00:00
}
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
static void get_scale_factors(struct gl_video *p, bool transpose_rot, double xy[2])
vo_opengl: add smoothmotion frame blending SmoothMotion is a way to time and blend frames made popular by MadVR. It's intended behaviour is to remove stuttering caused by mismatches between the display refresh rate and the video fps, while preserving the video's original artistic qualities (no soap opera effect). It's supposed to make 24fps video playback on 60hz monitors as close as possible to a 24hz monitor. Instead of drawing a frame once once it's pts has passed the vsync time, we redraw at the display refresh rate, and if we detect the vsync is between two frames we interpolated them (depending on their position relative to the vsync). We actually interpolate as few frames as possible to avoid a blur effect as much as possible. For example, if we were to play back a 1fps video on a 60hz monitor, we would blend at most on 1 vsync for each frame (while the other 59 vsyncs would be rendered as is). Frame interpolation is always done before scaling and in linear light when possible (an ICC profile is used, or :srgb is used).
2014-11-23 19:06:05 +00:00
{
vo_opengl: fix rotation This has been completely broken since commit 93546f0c. But even before, rotation handling did not make too much sense. In particular, it rotated the contents of the cropped image, instead of adjusting the crop rectangle as well. The result was that things like panscan or zooming did not behave as expected with rotation applied. The same is true for vertical flipping. Flipping is triggered by negative image stride. OpenGL does not support flipping the image on upload, so it's done as part of the rendering. It can be triggered with --vf=flip, but other filters and even decoders could setup negative stride to flip the image. Fix these issues by applying transforms to texture coordinates properly, and by making rotation and flipping part of these transforms. This still doesn't work properly for separated scaling. The issue is that we'd have to adjust how the passes are done. For now, pick a very stupid solution by rotating the image to a FBO, and then scaling from that. This has the avantage that the scale logic doesn't have to be complicated for such a rare case. It could be improved later. Prescaling is apparently still broken. I don't know if chroma positioning works properly either. None of this should affect the case with no rotation.
2016-03-28 14:30:48 +00:00
double target_w = p->src_rect.x1 - p->src_rect.x0;
double target_h = p->src_rect.y1 - p->src_rect.y0;
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
if (transpose_rot && p->image_params.rotate % 180 == 90)
vo_opengl: fix rotation This has been completely broken since commit 93546f0c. But even before, rotation handling did not make too much sense. In particular, it rotated the contents of the cropped image, instead of adjusting the crop rectangle as well. The result was that things like panscan or zooming did not behave as expected with rotation applied. The same is true for vertical flipping. Flipping is triggered by negative image stride. OpenGL does not support flipping the image on upload, so it's done as part of the rendering. It can be triggered with --vf=flip, but other filters and even decoders could setup negative stride to flip the image. Fix these issues by applying transforms to texture coordinates properly, and by making rotation and flipping part of these transforms. This still doesn't work properly for separated scaling. The issue is that we'd have to adjust how the passes are done. For now, pick a very stupid solution by rotating the image to a FBO, and then scaling from that. This has the avantage that the scale logic doesn't have to be complicated for such a rare case. It could be improved later. Prescaling is apparently still broken. I don't know if chroma positioning works properly either. None of this should affect the case with no rotation.
2016-03-28 14:30:48 +00:00
MPSWAP(double, target_w, target_h);
xy[0] = (p->dst_rect.x1 - p->dst_rect.x0) / target_w;
xy[1] = (p->dst_rect.y1 - p->dst_rect.y0) / target_h;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
}
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
// Cropping.
vo_opengl: fix rotation This has been completely broken since commit 93546f0c. But even before, rotation handling did not make too much sense. In particular, it rotated the contents of the cropped image, instead of adjusting the crop rectangle as well. The result was that things like panscan or zooming did not behave as expected with rotation applied. The same is true for vertical flipping. Flipping is triggered by negative image stride. OpenGL does not support flipping the image on upload, so it's done as part of the rendering. It can be triggered with --vf=flip, but other filters and even decoders could setup negative stride to flip the image. Fix these issues by applying transforms to texture coordinates properly, and by making rotation and flipping part of these transforms. This still doesn't work properly for separated scaling. The issue is that we'd have to adjust how the passes are done. For now, pick a very stupid solution by rotating the image to a FBO, and then scaling from that. This has the avantage that the scale logic doesn't have to be complicated for such a rare case. It could be improved later. Prescaling is apparently still broken. I don't know if chroma positioning works properly either. None of this should affect the case with no rotation.
2016-03-28 14:30:48 +00:00
static void compute_src_transform(struct gl_video *p, struct gl_transform *tr)
vo_opengl: move video source rectangle computation to a function Needed for the following commit.
2015-09-07 19:02:49 +00:00
{
vo_opengl: make image size dynamic during rendering This commit marks the image size variables temporary, and renames them in order to prevent any potential confusion in the future.
2015-10-23 17:52:03 +00:00
float sx = (p->src_rect.x1 - p->src_rect.x0) / (float)p->texture_w,
sy = (p->src_rect.y1 - p->src_rect.y0) / (float)p->texture_h,
vo_opengl: move video source rectangle computation to a function Needed for the following commit.
2015-09-07 19:02:49 +00:00
ox = p->src_rect.x0,
oy = p->src_rect.y0;
vo_opengl: fix rotation This has been completely broken since commit 93546f0c. But even before, rotation handling did not make too much sense. In particular, it rotated the contents of the cropped image, instead of adjusting the crop rectangle as well. The result was that things like panscan or zooming did not behave as expected with rotation applied. The same is true for vertical flipping. Flipping is triggered by negative image stride. OpenGL does not support flipping the image on upload, so it's done as part of the rendering. It can be triggered with --vf=flip, but other filters and even decoders could setup negative stride to flip the image. Fix these issues by applying transforms to texture coordinates properly, and by making rotation and flipping part of these transforms. This still doesn't work properly for separated scaling. The issue is that we'd have to adjust how the passes are done. For now, pick a very stupid solution by rotating the image to a FBO, and then scaling from that. This has the avantage that the scale logic doesn't have to be complicated for such a rare case. It could be improved later. Prescaling is apparently still broken. I don't know if chroma positioning works properly either. None of this should affect the case with no rotation.
2016-03-28 14:30:48 +00:00
struct gl_transform transform = {{{sx, 0}, {0, sy}}, {ox, oy}};
vo_opengl: add Super-xBR filter for upscaling Add the Super-xBR filter for image doubling, and the prescaling framework to support it. The shader code was ported from MPDN extensions project, with modification to process luma only. This commit is largely inspired by code from #2266, with `gl_transform_trans()` authored by @haasn taken directly.
2015-10-26 22:43:48 +00:00
gl_transform_trans(p->texture_offset, &transform);
vo_opengl: move video source rectangle computation to a function Needed for the following commit.
2015-09-07 19:02:49 +00:00
*tr = transform;
}
vo_opengl: color manage after interpolation This moves the color management code out of pass_render_main (which is now dedicated solely to up/downscaling and hence renamed pass_scale_main) and into a new function, which gets called from pass_draw_to_screen instead. This makes more sense from a logical standpoint, and also means that we interpolate in linear RGB, before color management - rather than after it, which is significantly better for color accuracy and probably also interpolation quality.
2015-03-15 21:52:34 +00:00
// Takes care of the main scaling and pre/post-conversions
static void pass_scale_main(struct gl_video *p)
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
{
// Figure out the main scaler.
double xy[2];
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
get_scale_factors(p, true, xy);
vo_opengl: add Super-xBR filter for upscaling Add the Super-xBR filter for image doubling, and the prescaling framework to support it. The shader code was ported from MPDN extensions project, with modification to process luma only. This commit is largely inspired by code from #2266, with `gl_transform_trans()` authored by @haasn taken directly.
2015-10-26 22:43:48 +00:00
// actual scale factor should be divided by the scale factor of prescaling.
xy[0] /= p->texture_offset.m[0][0];
xy[1] /= p->texture_offset.m[1][1];
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
bool downscaling = xy[0] < 1.0 || xy[1] < 1.0;
bool upscaling = !downscaling && (xy[0] > 1.0 || xy[1] > 1.0);
double scale_factor = 1.0;
vo_opengl: add macros for scaler units There was no real point in hard-coding these all over the place, especially since the order was sort of arbitrary and confusing.
2016-03-05 08:42:57 +00:00
struct scaler *scaler = &p->scaler[SCALER_SCALE];
struct scaler_config scaler_conf = p->opts.scaler[SCALER_SCALE];
vo_opengl: add Super-xBR filter for upscaling Add the Super-xBR filter for image doubling, and the prescaling framework to support it. The shader code was ported from MPDN extensions project, with modification to process luma only. This commit is largely inspired by code from #2266, with `gl_transform_trans()` authored by @haasn taken directly.
2015-10-26 22:43:48 +00:00
if (p->opts.scaler_resizes_only && !downscaling && !upscaling) {
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
scaler_conf.kernel.name = "bilinear";
vo_opengl: minor change to scaler_resizes_only Instead of rounding down, we round to the nearest float. This reduces the maximum possible error introduced by this rounding operation. Also clarify the comment.
2016-04-17 11:07:14 +00:00
// For scaler-resizes-only, we round the texture offset to
// the nearest round value in order to prevent ugly blurriness
// (in exchange for slightly shifting the image by up to half a
// subpixel)
p->texture_offset.t[0] = roundf(p->texture_offset.t[0]);
p->texture_offset.t[1] = roundf(p->texture_offset.t[1]);
vo_opengl: add Super-xBR filter for upscaling Add the Super-xBR filter for image doubling, and the prescaling framework to support it. The shader code was ported from MPDN extensions project, with modification to process luma only. This commit is largely inspired by code from #2266, with `gl_transform_trans()` authored by @haasn taken directly.
2015-10-26 22:43:48 +00:00
}
vo_opengl: add macros for scaler units There was no real point in hard-coding these all over the place, especially since the order was sort of arbitrary and confusing.
2016-03-05 08:42:57 +00:00
if (downscaling && p->opts.scaler[SCALER_DSCALE].kernel.name) {
scaler_conf = p->opts.scaler[SCALER_DSCALE];
scaler = &p->scaler[SCALER_DSCALE];
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
}
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
vo_opengl: rename fancy-downscaling to correct-downscaling The old name was stupid. Very stupid.
2015-11-07 16:49:14 +00:00
// When requesting correct-downscaling and the clip is anamorphic, and
// because only a single scale factor is used for both axes, enable it only
vo_opengl: fancy-downscaling: enable also for anamorphic clips
2015-08-10 00:57:53 +00:00
// when both axes are downscaled, and use the milder of the factors to not
// end up with too much blur on one axis (even if we end up with sub-optimal
vo_opengl: rename fancy-downscaling to correct-downscaling The old name was stupid. Very stupid.
2015-11-07 16:49:14 +00:00
// scale factor on the other axis). This is better than not respecting
// correct scaling at all for anamorphic clips.
vo_opengl: fancy-downscaling: enable also for anamorphic clips
2015-08-10 00:57:53 +00:00
double f = MPMAX(xy[0], xy[1]);
vo_opengl: rename fancy-downscaling to correct-downscaling The old name was stupid. Very stupid.
2015-11-07 16:49:14 +00:00
if (p->opts.correct_downscaling && f < 1.0)
vo_opengl: fancy-downscaling: enable also for anamorphic clips
2015-08-10 00:57:53 +00:00
scale_factor = 1.0 / f;
vo_opengl: greatly increase smoothmotion performance Instead of rendering and upscaling each video frame on every vsync, this version of the algorithm only draws them once and caches the result, so the only operation that has to run on every vsync is a cheap linear interpolation, plus CMS/dithering. On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz monitor), up to 120% faster. (The speedup is not quite 250% because of the overhead that the larger FBOs and CMS provides) In terms of the implementation, this commit basically swaps interpolation and upscaling - upscaling is moved to inter_program, and interpolation is moved to the final_program. Furthermore, the main bulk of the frame rendering logic (upscaling etc.) was moved to a separete function, which is called from gl_video_interpolate_frame only if it's actually necessarily, and skipped otherwise.
2015-02-20 21:12:02 +00:00
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
// Pre-conversion, like linear light/sigmoidization
GLSLF("// scaler pre-conversion\n");
vo_opengl: adjust the rules for linearization Two changes, compounded into one since they affect the same logic: 1. Never use linearization for HDR downscaling 2. Always use linearization for interpolation Instead of fixing p->use_linear at the beginning of pass_render_frame, we flip it on "dynamically" as needed. I plan on killing this p->use_linear frame (along with other per-pass metadata) and moving them into their own struct for tracking the "current" state of the video, but that's a separate/upcoming refactor. As a small bonus, reduce some code duplication in the interpolation logic. Fixes #4631
2017-07-24 21:22:30 +00:00
bool use_linear = p->opts.linear_scaling || p->opts.sigmoid_upscaling;
// Linear light downscaling results in nasty artifacts for HDR curves due
// to the potentially extreme brightness differences severely compounding
// any ringing. So just scale in gamma light instead.
if (mp_trc_is_hdr(p->image_params.color.gamma) && downscaling)
use_linear = false;
if (use_linear) {
p->use_linear = true;
mp_image: split colorimetry metadata into its own struct This has two reasons: 1. I tend to add new fields to this metadata, and every time I've done so I've consistently forgotten to update all of the dozens of places in which this colorimetry metadata might end up getting used. While most usages don't really care about most of the metadata, sometimes the intend was simply to “copy” the colorimetry metadata from one struct to another. With this being inside a substruct, those lines of code can now simply read a.color = b.color without having to care about added or removed fields. 2. It makes the type definitions nicer for upcoming refactors. In going through all of the usages, I also expanded a few where I felt that omitting the “young” fields was a bug.
2016-06-29 07:16:13 +00:00
pass_linearize(p->sc, p->image_params.color.gamma);
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
pass_opt_hook_point(p, "LINEAR", NULL);
}
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
vo_opengl: adjust the rules for linearization Two changes, compounded into one since they affect the same logic: 1. Never use linearization for HDR downscaling 2. Always use linearization for interpolation Instead of fixing p->use_linear at the beginning of pass_render_frame, we flip it on "dynamically" as needed. I plan on killing this p->use_linear frame (along with other per-pass metadata) and moving them into their own struct for tracking the "current" state of the video, but that's a separate/upcoming refactor. As a small bonus, reduce some code duplication in the interpolation logic. Fixes #4631
2017-07-24 21:22:30 +00:00
bool use_sigmoid = use_linear && p->opts.sigmoid_upscaling && upscaling;
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
float sig_center, sig_slope, sig_offset, sig_scale;
if (use_sigmoid) {
// Coefficients for the sigmoidal transform are taken from the
// formula here: http://www.imagemagick.org/Usage/color_mods/#sigmoidal
sig_center = p->opts.sigmoid_center;
sig_slope = p->opts.sigmoid_slope;
// This function needs to go through (0,0) and (1,1) so we compute the
// values at 1 and 0, and then scale/shift them, respectively.
sig_offset = 1.0/(1+expf(sig_slope * sig_center));
sig_scale = 1.0/(1+expf(sig_slope * (sig_center-1))) - sig_offset;
vo_opengl: avoid constant divisions 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
2017-07-17 03:23:55 +00:00
GLSLF("color.rgb = %f - log(1.0/(color.rgb * %f + %f) - 1.0) * 1.0/%f;\n",
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
sig_center, sig_scale, sig_offset, sig_slope);
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
pass_opt_hook_point(p, "SIGMOID", NULL);
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
}
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
pass_opt_hook_point(p, "PREKERNEL", NULL);
vo_opengl: fix rotation This has been completely broken since commit 93546f0c. But even before, rotation handling did not make too much sense. In particular, it rotated the contents of the cropped image, instead of adjusting the crop rectangle as well. The result was that things like panscan or zooming did not behave as expected with rotation applied. The same is true for vertical flipping. Flipping is triggered by negative image stride. OpenGL does not support flipping the image on upload, so it's done as part of the rendering. It can be triggered with --vf=flip, but other filters and even decoders could setup negative stride to flip the image. Fix these issues by applying transforms to texture coordinates properly, and by making rotation and flipping part of these transforms. This still doesn't work properly for separated scaling. The issue is that we'd have to adjust how the passes are done. For now, pick a very stupid solution by rotating the image to a FBO, and then scaling from that. This has the avantage that the scale logic doesn't have to be complicated for such a rare case. It could be improved later. Prescaling is apparently still broken. I don't know if chroma positioning works properly either. None of this should affect the case with no rotation.
2016-03-28 14:30:48 +00:00
int vp_w = p->dst_rect.x1 - p->dst_rect.x0;
int vp_h = p->dst_rect.y1 - p->dst_rect.y0;
vo_opengl: move video source rectangle computation to a function Needed for the following commit.
2015-09-07 19:02:49 +00:00
struct gl_transform transform;
vo_opengl: fix rotation This has been completely broken since commit 93546f0c. But even before, rotation handling did not make too much sense. In particular, it rotated the contents of the cropped image, instead of adjusting the crop rectangle as well. The result was that things like panscan or zooming did not behave as expected with rotation applied. The same is true for vertical flipping. Flipping is triggered by negative image stride. OpenGL does not support flipping the image on upload, so it's done as part of the rendering. It can be triggered with --vf=flip, but other filters and even decoders could setup negative stride to flip the image. Fix these issues by applying transforms to texture coordinates properly, and by making rotation and flipping part of these transforms. This still doesn't work properly for separated scaling. The issue is that we'd have to adjust how the passes are done. For now, pick a very stupid solution by rotating the image to a FBO, and then scaling from that. This has the avantage that the scale logic doesn't have to be complicated for such a rare case. It could be improved later. Prescaling is apparently still broken. I don't know if chroma positioning works properly either. None of this should affect the case with no rotation.
2016-03-28 14:30:48 +00:00
compute_src_transform(p, &transform);
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
GLSLF("// main scaling\n");
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
finish_pass_tex(p, &p->indirect_tex, p->texture_w, p->texture_h);
struct image src = image_wrap(p->indirect_tex, PLANE_RGB, p->components);
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
gl_transform_trans(transform, &src.transform);
vo_opengl: refactor plane-skipping optimizations Instead of hard-coding the logic and planes to skip, factor this out to a reusible function, and instead add the number of relevant coordinates to the texture state.
2016-03-05 11:38:51 +00:00
pass_sample(p, src, scaler, &scaler_conf, scale_factor, vp_w, vp_h);
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
vo_opengl: make image size dynamic during rendering This commit marks the image size variables temporary, and renames them in order to prevent any potential confusion in the future.
2015-10-23 17:52:03 +00:00
// Changes the texture size to display size after main scaler.
p->texture_w = vp_w;
p->texture_h = vp_h;
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
pass_opt_hook_point(p, "POSTKERNEL", NULL);
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
GLSLF("// scaler post-conversion\n");
if (use_sigmoid) {
// Inverse of the transformation above
vo_opengl: avoid constant divisions 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
2017-07-17 03:23:55 +00:00
GLSLF("color.rgb = (1.0/(1.0 + exp(%f * (%f - color.rgb))) - %f) * 1.0/%f;\n",
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
sig_slope, sig_center, sig_offset, sig_scale);
}
vo_opengl: color manage after interpolation This moves the color management code out of pass_render_main (which is now dedicated solely to up/downscaling and hence renamed pass_scale_main) and into a new function, which gets called from pass_draw_to_screen instead. This makes more sense from a logical standpoint, and also means that we interpolate in linear RGB, before color management - rather than after it, which is significantly better for color accuracy and probably also interpolation quality.
2015-03-15 21:52:34 +00:00
}
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
vo_opengl: generalize HDR tone mapping mechanism This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
2016-06-29 07:28:17 +00:00
// Adapts the colors to the right output color space. (Final pass during
// rendering)
// If OSD is true, ignore any changes that may have been made to the video
// by previous passes (i.e. linear scaling)
static void pass_colormanage(struct gl_video *p, struct mp_colorspace src, bool osd)
{
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
struct ra *ra = p->ra;
vo_opengl: support HDR peak detection This is done via compute shaders. As a consequence, the tone mapping algorithms had to be rewritten to compute their known constants in GLSL (ahead of time), instead of doing it once. Didn't affect performance. Using shmem/SSBO atomics in this way is extremely fast on nvidia, but it might be slow on other platforms. Needs testing. Unfortunately, setting up the SSBO still requires OpenGL calls, which means I can't have it in video_shaders.c, where it belongs. But I'll defer worrying about that until the backend refactor, since then I'll be breaking up the video/video_shaders structure anyway.
2017-07-17 19:39:06 +00:00
vo_opengl: generalize HDR tone mapping mechanism This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
2016-06-29 07:28:17 +00:00
// Figure out the target color space from the options, or auto-guess if
// none were set
struct mp_colorspace dst = {
.gamma = p->opts.target_trc,
.primaries = p->opts.target_prim,
vo_opengl: implement support for OOTFs and non-display referred content 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.
2017-06-14 18:06:56 +00:00
.light = MP_CSP_LIGHT_DISPLAY,
vo_gpu: introduce --target-peak This solves a number of problems simultaneously: 1. When outputting HLG, this allows tuning the OOTF based on the display characteristics. 2. When outputting PQ or other HDR curves, this allows soft-limiting the output brightness using the tone mapping algorithm. 3. When outputting SDR, this allows HDR-in-SDR style output, by controlling the output brightness directly. Closes #5521
2018-02-14 15:10:51 +00:00
.sig_peak = p->opts.target_peak / MP_REF_WHITE,
vo_opengl: generalize HDR tone mapping mechanism This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
2016-06-29 07:28:17 +00:00
};
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
if (p->use_lut_3d) {
vo_opengl: generalize HDR tone mapping mechanism This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
2016-06-29 07:28:17 +00:00
// The 3DLUT is always generated against the video's original source
// space, *not* the reference space. (To avoid having to regenerate
// the 3DLUT for the OSD on every frame)
mp_image: split colorimetry metadata into its own struct This has two reasons: 1. I tend to add new fields to this metadata, and every time I've done so I've consistently forgotten to update all of the dozens of places in which this colorimetry metadata might end up getting used. While most usages don't really care about most of the metadata, sometimes the intend was simply to “copy” the colorimetry metadata from one struct to another. With this being inside a substruct, those lines of code can now simply read a.color = b.color without having to care about added or removed fields. 2. It makes the type definitions nicer for upcoming refactors. In going through all of the usages, I also expanded a few where I felt that omitting the “young” fields was a bug.
2016-06-29 07:16:13 +00:00
enum mp_csp_prim prim_orig = p->image_params.color.primaries;
enum mp_csp_trc trc_orig = p->image_params.color.gamma;
vo_opengl: generate 3DLUT against source and use full BT.1886 This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
2016-02-13 14:33:00 +00:00
vo_opengl: implement ARIB STD-B68 (HLG) HDR TRC This HDR function is unique in that it's still display-referred, it just allows for values above the reference peak (super-highlights). The official standard doesn't actually document this very well, but the nominal peak turns out to be exactly 12.0 - so we normalize to this value internally in mpv. (This lets us preserve the property that the textures are encoded in the range [0,1], preventing clipping and making the best use of an integer texture's range) This was grouped together with SMPTE ST2084 when checking libavutil compatibility since they were added in the same release window, in a similar timeframe.
2016-06-26 17:04:36 +00:00
// One exception: HDR is not implemented by LittleCMS for technical
// limitation reasons, so we use a gamma 2.2 input curve here instead.
// We could pick any value we want here, the difference is just coding
// efficiency.
csputils: rename HDR curves 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.
2017-06-13 15:09:02 +00:00
if (mp_trc_is_hdr(trc_orig))
vo_opengl: implement HDR (SMPTE ST2084) Currently, this relies on the user manually entering their display brightness (since we have no way to detect this at runtime or from ICC metadata). The default value of 250 was picked by looking at ~10 reviews on tftcentral.co.uk and realizing they all come with around 250 cd/m^2 out of the box. (In addition, ITU-R Rec. BT.2022 supports this) Since there is no metadata in FFmpeg to indicate usage of this TRC, the only way to actually play HDR content currently is to set ``--vf=format=gamma=st2084``. (It could be guessed based on SEI, but this is not implemented yet) Incidentally, since SEI is ignored, it's currently assumed that all content is scaled to 10,000 cd/m^2 (and hard-clipped where out of range). I don't see this assumption changing much, though. As an unfortunate consequence of the fact that we don't know the display brightness, mixed with the fact that LittleCMS' parametric tone curves are not flexible enough to support PQ, we have to build the 3DLUT against gamma 2.2 if it's used. This might be a good thing, though, consdering the PQ source space is probably not fantastic for interpolation either way. Partially addresses #2572.
2016-05-15 18:16:12 +00:00
trc_orig = MP_CSP_TRC_GAMMA22;
vo_opengl: generate 3DLUT against source and use full BT.1886 This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
2016-02-13 14:33:00 +00:00
if (gl_video_get_lut3d(p, prim_orig, trc_orig)) {
vo_opengl: generalize HDR tone mapping mechanism This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
2016-06-29 07:28:17 +00:00
dst.primaries = prim_orig;
dst.gamma = trc_orig;
vo_gpu: simplify and correct color scale handling The primary need for this change is the fact that the OOTF was incorrectly scaled, due to the fact that the application of the OOTF can itself change the required normalization peak. (Plus, an oversight in pass_inverse_ootf meant we forgot to normalize at the end of it) The linearize/delinearize functions still normalize the scale since it's used in a number of places throughout gpu/video.c, but the color management function now converts to absolute scale right away, instead of in an awkward way inside the tone mapping branch. The OOTF functions now work in absolute scale only. In addition, minor changes have been made to the way normalization is handled for tone mapping - we now divide out the dst_peak *after* peak detection, in order to make the scale of the peak detection buffer consistent even if the dst_peak were to (hypothetically) change mid-stream. In theory, we could also do this for desaturation, but doing the desaturation before tone mapping has the advantage of preserving much more brightness than the other way around - and even mid-stream changes are not that drastic here. Finally, some preparation work has been done for allowing the user to customize the `dst.sig_peak` in the future.
2018-02-14 13:14:48 +00:00
assert(dst.primaries && dst.gamma);
vo_opengl: generate 3DLUT against source and use full BT.1886 This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
2016-02-13 14:33:00 +00:00
}
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
}
vo_opengl: generalize HDR tone mapping mechanism This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
2016-06-29 07:28:17 +00:00
if (dst.primaries == MP_CSP_PRIM_AUTO) {
vo_opengl: revise the logic for picking the default color space Too many "exceptions" these days, it's easier to just hard-code a whitelist instead of a blacklist. And besides, it only really makes sense to avoid adaptation for BT.601 specifically, since that's the one we auto-guess based on the resolution.
2016-06-28 11:55:10 +00:00
// The vast majority of people are on sRGB or BT.709 displays, so pick
// this as the default output color space.
vo_opengl: generalize HDR tone mapping mechanism This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
2016-06-29 07:28:17 +00:00
dst.primaries = MP_CSP_PRIM_BT_709;
vo_opengl: avoid outputting ultra-wide-gamut by default The default behavior of vo_opengl has pretty much always been 'show the source colors as-is, without caring to adapt it to the target device'. This decision is mostly based on the fact that if we do anything else, lots of people will complain. With the rise of content like BT.2020, however, it turns out more people complain about this content being very desaturated than people complain about this content not matching VLC - so let's just map ultra-wide gamut content back down to standard gamut by default.
2016-06-07 09:31:22 +00:00
video: refactor HDR implementation 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.
2017-06-10 12:01:25 +00:00
if (src.primaries == MP_CSP_PRIM_BT_601_525 ||
src.primaries == MP_CSP_PRIM_BT_601_625)
vo_opengl: use image_params instead of *_src for autoconfig I'm not even sure why we ever consulted *_src to begin with, since that just describes the current image format - and not the original metadata. (And in fact, we specifically had logic to work around the impliciations this had on linear scaling) image_params is *the* authoritative source on the intended (i.e. reference) image metadata, whereas *_src may be changed by previous passes already. So only consult image_params for picking auto-generated values. Also, add some more missing "wide gamut" and "non-gamma" curves to the autoconfig blacklist. (Maybe it would make sense to move this list to csputils in the future? Or perhaps even auto-detect it based on the associated primaries)
2016-06-27 23:18:55 +00:00
{
vo_opengl: revise the logic for picking the default color space Too many "exceptions" these days, it's easier to just hard-code a whitelist instead of a blacklist. And besides, it only really makes sense to avoid adaptation for BT.601 specifically, since that's the one we auto-guess based on the resolution.
2016-06-28 11:55:10 +00:00
// Since we auto-pick BT.601 and BT.709 based on the dimensions,
// combined with the fact that they're very similar to begin with,
// and to avoid confusing the average user, just don't adapt BT.601
// content automatically at all.
video: refactor HDR implementation 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.
2017-06-10 12:01:25 +00:00
dst.primaries = src.primaries;
vo_opengl: use image_params instead of *_src for autoconfig I'm not even sure why we ever consulted *_src to begin with, since that just describes the current image format - and not the original metadata. (And in fact, we specifically had logic to work around the impliciations this had on linear scaling) image_params is *the* authoritative source on the intended (i.e. reference) image metadata, whereas *_src may be changed by previous passes already. So only consult image_params for picking auto-generated values. Also, add some more missing "wide gamut" and "non-gamma" curves to the autoconfig blacklist. (Maybe it would make sense to move this list to csputils in the future? Or perhaps even auto-detect it based on the associated primaries)
2016-06-27 23:18:55 +00:00
}
vo_opengl: avoid outputting ultra-wide-gamut by default The default behavior of vo_opengl has pretty much always been 'show the source colors as-is, without caring to adapt it to the target device'. This decision is mostly based on the fact that if we do anything else, lots of people will complain. With the rise of content like BT.2020, however, it turns out more people complain about this content being very desaturated than people complain about this content not matching VLC - so let's just map ultra-wide gamut content back down to standard gamut by default.
2016-06-07 09:31:22 +00:00
}
vo_opengl: generalize HDR tone mapping mechanism This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
2016-06-29 07:28:17 +00:00
if (dst.gamma == MP_CSP_TRC_AUTO) {
vo_opengl: revise the transfer curve logic Instead of hard-coding a big list, move some of the functionality to csputils. Affects both the auto-guess blacklist and the peak estimation. Also update the comments.
2016-06-28 12:28:32 +00:00
// Most people seem to complain when the image is darker or brighter
// than what they're "used to", so just avoid changing the gamma
// altogether by default. The only exceptions to this rule apply to
// very unusual TRCs, which even hardcode technoluddites would probably
// not enjoy viewing unaltered.
video: refactor HDR implementation 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.
2017-06-10 12:01:25 +00:00
dst.gamma = src.gamma;
vo_opengl: use image_params instead of *_src for autoconfig I'm not even sure why we ever consulted *_src to begin with, since that just describes the current image format - and not the original metadata. (And in fact, we specifically had logic to work around the impliciations this had on linear scaling) image_params is *the* authoritative source on the intended (i.e. reference) image metadata, whereas *_src may be changed by previous passes already. So only consult image_params for picking auto-generated values. Also, add some more missing "wide gamut" and "non-gamma" curves to the autoconfig blacklist. (Maybe it would make sense to move this list to csputils in the future? Or perhaps even auto-detect it based on the associated primaries)
2016-06-27 23:18:55 +00:00
vo_opengl: revise the transfer curve logic Instead of hard-coding a big list, move some of the functionality to csputils. Affects both the auto-guess blacklist and the peak estimation. Also update the comments.
2016-06-28 12:28:32 +00:00
// Avoid outputting linear light or HDR content "by default". For these
// just pick gamma 2.2 as a default, since it's a good estimate for
// the response of typical displays
vo_opengl: generalize HDR tone mapping mechanism This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
2016-06-29 07:28:17 +00:00
if (dst.gamma == MP_CSP_TRC_LINEAR || mp_trc_is_hdr(dst.gamma))
dst.gamma = MP_CSP_TRC_GAMMA22;
vo_opengl: refactor HDR mechanism Instead of doing HDR tone mapping on an ad-hoc basis inside pass_colormanage, the reference peak of an image is now part of the image params (alongside colorspace, gamma, etc.) and tone mapping is done whenever peak_src != peak_dst. To get sensible behavior when mixing HDR and SDR content and displays, target-brightness is a generic filler for "the assumed brightness of SDR content". This gets rid of the weird display_scaled hack, sets the framework for multiple HDR functions with difference reference peaks, and allows us to (in a future commit) autodetect the right source peak from the HDR metadata. (Apart from metadata, the source peak can also be controlled via vf_format. For HDR content this adjusts the overall image brightness, for SDR content it's like simulating a different exposure)
2016-05-30 17:56:58 +00:00
}
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
vo_gpu: introduce --target-peak This solves a number of problems simultaneously: 1. When outputting HLG, this allows tuning the OOTF based on the display characteristics. 2. When outputting PQ or other HDR curves, this allows soft-limiting the output brightness using the tone mapping algorithm. 3. When outputting SDR, this allows HDR-in-SDR style output, by controlling the output brightness directly. Closes #5521
2018-02-14 15:10:51 +00:00
// If there's no specific signal peak known for the output display, infer
// it from the chosen transfer function
if (!dst.sig_peak)
dst.sig_peak = mp_trc_nom_peak(dst.gamma);
vo_gpu: simplify and correct color scale handling The primary need for this change is the fact that the OOTF was incorrectly scaled, due to the fact that the application of the OOTF can itself change the required normalization peak. (Plus, an oversight in pass_inverse_ootf meant we forgot to normalize at the end of it) The linearize/delinearize functions still normalize the scale since it's used in a number of places throughout gpu/video.c, but the color management function now converts to absolute scale right away, instead of in an awkward way inside the tone mapping branch. The OOTF functions now work in absolute scale only. In addition, minor changes have been made to the way normalization is handled for tone mapping - we now divide out the dst_peak *after* peak detection, in order to make the scale of the peak detection buffer consistent even if the dst_peak were to (hypothetically) change mid-stream. In theory, we could also do this for desaturation, but doing the desaturation before tone mapping has the advantage of preserving much more brightness than the other way around - and even mid-stream changes are not that drastic here. Finally, some preparation work has been done for allowing the user to customize the `dst.sig_peak` in the future.
2018-02-14 13:14:48 +00:00
vo_gpu: port HDR tone mapping algorithm from libplacebo The current peak detection algorithm was very bugged (which contributed to the excessive cross-frame flicker without long normalization) and also didn't take into account the frame average brightness level. The new algorithm both takes into account frame average brightness (in addition to peak brightness), and also computes the values in a more stable/correct way. (The old path was basically undefined behavior) In addition to improving the algorithm, we also switch to hable tone mapping by default, and try to enable peak computation automatically whever possible (compute shaders + SSBOs supported). We also make the desaturation milder, after extensive testing during libplacebo development. I also had to compensate a bit for the representational differences between mpv and libplacebo (libplacebo treats 1.0 as the reference peak, but mpv treats it as the nominal peak), but it shouldn't have caused any problems. This is still not quite the same as libplacebo, since libplacebo also allows tagging the desired scene average brightness on the output, and it also supports reading the scene average brightness from static metadata (MaxFALL) where available. But those changes are a bit more involved. It's possible we could also read this from metadata in the future, but we have problems communicating with AVFrames as it is and I don't want to touch the mpv colorimetry structs for the time being.
2018-02-03 13:45:01 +00:00
bool detect_peak = p->opts.compute_hdr_peak >= 0 && mp_trc_is_hdr(src.gamma);
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
if (detect_peak && !p->hdr_peak_ssbo) {
struct {
vo_gpu: refactor HDR peak detection algorithm The major changes are as follows: 1. Use `uint32_t` instead of `unsigned int` for the SSBO size calculation. This doesn't really matter, since a too-big buffer will still work just fine, but since `uint` is a 32-bit integer by definition this is the correct way to do it. 2. Pre-divide the frame_sum by the num_wg immediately at the end of a frame. This change was made to prevent overflow. At 4K screen size, this code is currently already very at risk of overflow, especially once I started playing with longer averaging sizes. Pre-dividing this out makes it just about fit into 32-bit even for worst-case PQ content. (It's technically also faster and easier this way, so I should have done it to begin with). Rename `frame_sum` to `frame_avg` to clearly signal the change in semantics. 3. Implement a scene transition detection algorithm. This basically compares the current frame's average brightness against the (averaged) value of the past frames. If it exceeds a threshold, which I experimentally configured, we reset the peak detection SSBO's state immediately - so that it just contains the current frame. This prevents annoying "eye adaptation"-like effects on scene transitions. 4. As a result of the previous change, we can now use a much larger buffer size by default, which results in a more stable and less flickery result. I experimented with values between 20 and 256 and settled on the new value of 64. (I also switched to a power-of-2 array size, because I like powers of two)
2018-02-10 21:42:11 +00:00
uint32_t counter;
uint32_t frame_idx;
uint32_t frame_num;
uint32_t frame_max[PEAK_DETECT_FRAMES+1];
uint32_t frame_sum[PEAK_DETECT_FRAMES+1];
uint32_t total_max;
uint32_t total_sum;
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
} peak_ssbo = {0};
struct ra_buf_params params = {
.type = RA_BUF_TYPE_SHADER_STORAGE,
.size = sizeof(peak_ssbo),
.initial_data = &peak_ssbo,
};
vo_opengl: support HDR peak detection This is done via compute shaders. As a consequence, the tone mapping algorithms had to be rewritten to compute their known constants in GLSL (ahead of time), instead of doing it once. Didn't affect performance. Using shmem/SSBO atomics in this way is extremely fast on nvidia, but it might be slow on other platforms. Needs testing. Unfortunately, setting up the SSBO still requires OpenGL calls, which means I can't have it in video_shaders.c, where it belongs. But I'll defer worrying about that until the backend refactor, since then I'll be breaking up the video/video_shaders structure anyway.
2017-07-17 19:39:06 +00:00
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
p->hdr_peak_ssbo = ra_buf_create(ra, &params);
vo_opengl: support HDR peak detection This is done via compute shaders. As a consequence, the tone mapping algorithms had to be rewritten to compute their known constants in GLSL (ahead of time), instead of doing it once. Didn't affect performance. Using shmem/SSBO atomics in this way is extremely fast on nvidia, but it might be slow on other platforms. Needs testing. Unfortunately, setting up the SSBO still requires OpenGL calls, which means I can't have it in video_shaders.c, where it belongs. But I'll defer worrying about that until the backend refactor, since then I'll be breaking up the video/video_shaders structure anyway.
2017-07-17 19:39:06 +00:00
if (!p->hdr_peak_ssbo) {
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
MP_WARN(p, "Failed to create HDR peak detection SSBO, disabling.\n");
vo_gpu: port HDR tone mapping algorithm from libplacebo The current peak detection algorithm was very bugged (which contributed to the excessive cross-frame flicker without long normalization) and also didn't take into account the frame average brightness level. The new algorithm both takes into account frame average brightness (in addition to peak brightness), and also computes the values in a more stable/correct way. (The old path was basically undefined behavior) In addition to improving the algorithm, we also switch to hable tone mapping by default, and try to enable peak computation automatically whever possible (compute shaders + SSBOs supported). We also make the desaturation milder, after extensive testing during libplacebo development. I also had to compensate a bit for the representational differences between mpv and libplacebo (libplacebo treats 1.0 as the reference peak, but mpv treats it as the nominal peak), but it shouldn't have caused any problems. This is still not quite the same as libplacebo, since libplacebo also allows tagging the desired scene average brightness on the output, and it also supports reading the scene average brightness from static metadata (MaxFALL) where available. But those changes are a bit more involved. It's possible we could also read this from metadata in the future, but we have problems communicating with AVFrames as it is and I don't want to touch the mpv colorimetry structs for the time being.
2018-02-03 13:45:01 +00:00
detect_peak = false;
p->opts.compute_hdr_peak = -1;
vo_opengl: support HDR peak detection This is done via compute shaders. As a consequence, the tone mapping algorithms had to be rewritten to compute their known constants in GLSL (ahead of time), instead of doing it once. Didn't affect performance. Using shmem/SSBO atomics in this way is extremely fast on nvidia, but it might be slow on other platforms. Needs testing. Unfortunately, setting up the SSBO still requires OpenGL calls, which means I can't have it in video_shaders.c, where it belongs. But I'll defer worrying about that until the backend refactor, since then I'll be breaking up the video/video_shaders structure anyway.
2017-07-17 19:39:06 +00:00
}
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
}
vo_opengl: support HDR peak detection This is done via compute shaders. As a consequence, the tone mapping algorithms had to be rewritten to compute their known constants in GLSL (ahead of time), instead of doing it once. Didn't affect performance. Using shmem/SSBO atomics in this way is extremely fast on nvidia, but it might be slow on other platforms. Needs testing. Unfortunately, setting up the SSBO still requires OpenGL calls, which means I can't have it in video_shaders.c, where it belongs. But I'll defer worrying about that until the backend refactor, since then I'll be breaking up the video/video_shaders structure anyway.
2017-07-17 19:39:06 +00:00
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
if (detect_peak) {
pass_describe(p, "detect HDR peak");
pass_is_compute(p, 8, 8); // 8x8 is good for performance
vo_opengl: support HDR peak detection This is done via compute shaders. As a consequence, the tone mapping algorithms had to be rewritten to compute their known constants in GLSL (ahead of time), instead of doing it once. Didn't affect performance. Using shmem/SSBO atomics in this way is extremely fast on nvidia, but it might be slow on other platforms. Needs testing. Unfortunately, setting up the SSBO still requires OpenGL calls, which means I can't have it in video_shaders.c, where it belongs. But I'll defer worrying about that until the backend refactor, since then I'll be breaking up the video/video_shaders structure anyway.
2017-07-17 19:39:06 +00:00
gl_sc_ssbo(p->sc, "PeakDetect", p->hdr_peak_ssbo,
vo_gpu: port HDR tone mapping algorithm from libplacebo The current peak detection algorithm was very bugged (which contributed to the excessive cross-frame flicker without long normalization) and also didn't take into account the frame average brightness level. The new algorithm both takes into account frame average brightness (in addition to peak brightness), and also computes the values in a more stable/correct way. (The old path was basically undefined behavior) In addition to improving the algorithm, we also switch to hable tone mapping by default, and try to enable peak computation automatically whever possible (compute shaders + SSBOs supported). We also make the desaturation milder, after extensive testing during libplacebo development. I also had to compensate a bit for the representational differences between mpv and libplacebo (libplacebo treats 1.0 as the reference peak, but mpv treats it as the nominal peak), but it shouldn't have caused any problems. This is still not quite the same as libplacebo, since libplacebo also allows tagging the desired scene average brightness on the output, and it also supports reading the scene average brightness from static metadata (MaxFALL) where available. But those changes are a bit more involved. It's possible we could also read this from metadata in the future, but we have problems communicating with AVFrames as it is and I don't want to touch the mpv colorimetry structs for the time being.
2018-02-03 13:45:01 +00:00
"uint counter;"
"uint frame_idx;"
"uint frame_num;"
"uint frame_max[%d];"
vo_gpu: refactor HDR peak detection algorithm The major changes are as follows: 1. Use `uint32_t` instead of `unsigned int` for the SSBO size calculation. This doesn't really matter, since a too-big buffer will still work just fine, but since `uint` is a 32-bit integer by definition this is the correct way to do it. 2. Pre-divide the frame_sum by the num_wg immediately at the end of a frame. This change was made to prevent overflow. At 4K screen size, this code is currently already very at risk of overflow, especially once I started playing with longer averaging sizes. Pre-dividing this out makes it just about fit into 32-bit even for worst-case PQ content. (It's technically also faster and easier this way, so I should have done it to begin with). Rename `frame_sum` to `frame_avg` to clearly signal the change in semantics. 3. Implement a scene transition detection algorithm. This basically compares the current frame's average brightness against the (averaged) value of the past frames. If it exceeds a threshold, which I experimentally configured, we reset the peak detection SSBO's state immediately - so that it just contains the current frame. This prevents annoying "eye adaptation"-like effects on scene transitions. 4. As a result of the previous change, we can now use a much larger buffer size by default, which results in a more stable and less flickery result. I experimented with values between 20 and 256 and settled on the new value of 64. (I also switched to a power-of-2 array size, because I like powers of two)
2018-02-10 21:42:11 +00:00
"uint frame_avg[%d];"
vo_gpu: port HDR tone mapping algorithm from libplacebo The current peak detection algorithm was very bugged (which contributed to the excessive cross-frame flicker without long normalization) and also didn't take into account the frame average brightness level. The new algorithm both takes into account frame average brightness (in addition to peak brightness), and also computes the values in a more stable/correct way. (The old path was basically undefined behavior) In addition to improving the algorithm, we also switch to hable tone mapping by default, and try to enable peak computation automatically whever possible (compute shaders + SSBOs supported). We also make the desaturation milder, after extensive testing during libplacebo development. I also had to compensate a bit for the representational differences between mpv and libplacebo (libplacebo treats 1.0 as the reference peak, but mpv treats it as the nominal peak), but it shouldn't have caused any problems. This is still not quite the same as libplacebo, since libplacebo also allows tagging the desired scene average brightness on the output, and it also supports reading the scene average brightness from static metadata (MaxFALL) where available. But those changes are a bit more involved. It's possible we could also read this from metadata in the future, but we have problems communicating with AVFrames as it is and I don't want to touch the mpv colorimetry structs for the time being.
2018-02-03 13:45:01 +00:00
"uint total_max;"
vo_gpu: refactor HDR peak detection algorithm The major changes are as follows: 1. Use `uint32_t` instead of `unsigned int` for the SSBO size calculation. This doesn't really matter, since a too-big buffer will still work just fine, but since `uint` is a 32-bit integer by definition this is the correct way to do it. 2. Pre-divide the frame_sum by the num_wg immediately at the end of a frame. This change was made to prevent overflow. At 4K screen size, this code is currently already very at risk of overflow, especially once I started playing with longer averaging sizes. Pre-dividing this out makes it just about fit into 32-bit even for worst-case PQ content. (It's technically also faster and easier this way, so I should have done it to begin with). Rename `frame_sum` to `frame_avg` to clearly signal the change in semantics. 3. Implement a scene transition detection algorithm. This basically compares the current frame's average brightness against the (averaged) value of the past frames. If it exceeds a threshold, which I experimentally configured, we reset the peak detection SSBO's state immediately - so that it just contains the current frame. This prevents annoying "eye adaptation"-like effects on scene transitions. 4. As a result of the previous change, we can now use a much larger buffer size by default, which results in a more stable and less flickery result. I experimented with values between 20 and 256 and settled on the new value of 64. (I also switched to a power-of-2 array size, because I like powers of two)
2018-02-10 21:42:11 +00:00
"uint total_avg;",
vo_gpu: port HDR tone mapping algorithm from libplacebo The current peak detection algorithm was very bugged (which contributed to the excessive cross-frame flicker without long normalization) and also didn't take into account the frame average brightness level. The new algorithm both takes into account frame average brightness (in addition to peak brightness), and also computes the values in a more stable/correct way. (The old path was basically undefined behavior) In addition to improving the algorithm, we also switch to hable tone mapping by default, and try to enable peak computation automatically whever possible (compute shaders + SSBOs supported). We also make the desaturation milder, after extensive testing during libplacebo development. I also had to compensate a bit for the representational differences between mpv and libplacebo (libplacebo treats 1.0 as the reference peak, but mpv treats it as the nominal peak), but it shouldn't have caused any problems. This is still not quite the same as libplacebo, since libplacebo also allows tagging the desired scene average brightness on the output, and it also supports reading the scene average brightness from static metadata (MaxFALL) where available. But those changes are a bit more involved. It's possible we could also read this from metadata in the future, but we have problems communicating with AVFrames as it is and I don't want to touch the mpv colorimetry structs for the time being.
2018-02-03 13:45:01 +00:00
PEAK_DETECT_FRAMES + 1,
PEAK_DETECT_FRAMES + 1
vo_opengl: support HDR peak detection This is done via compute shaders. As a consequence, the tone mapping algorithms had to be rewritten to compute their known constants in GLSL (ahead of time), instead of doing it once. Didn't affect performance. Using shmem/SSBO atomics in this way is extremely fast on nvidia, but it might be slow on other platforms. Needs testing. Unfortunately, setting up the SSBO still requires OpenGL calls, which means I can't have it in video_shaders.c, where it belongs. But I'll defer worrying about that until the backend refactor, since then I'll be breaking up the video/video_shaders structure anyway.
2017-07-17 19:39:06 +00:00
);
}
vo_opengl: generalize HDR tone mapping mechanism This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
2016-06-29 07:28:17 +00:00
// Adapt from src to dst as necessary
vo_opengl: generalize HDR tone mapping to gamut mapping Since this code was already written for HDR, and is now per-channel (because it works better for HDR as well), we can actually reuse this to get very high quality gamut mapping without clipping. The only required change is to move the tone mapping from before the gamut map to after the gamut map. Additonally, we need to also account for changes in the signal range as a result of applying the CMS when we compute ref_peak, which is fortunately pretty easy because we only need to consider the case of primaries mapping to themselves. Since `HDR` no longer really makes sense as a label, rename it to `--tone-mapping` in general. Also fits better with `--tone-mapping-desat` etc. Arguably we could also rename `--hdr-compute-peak`, but that option is basically only useful for HDR content anyway because we don't need information about the signal range for gamut mapping. This (finally!) gives us reasonably high quality gamut mapping even in the absence of an ICC profile / 3DLUT.
2017-08-03 10:46:57 +00:00
pass_color_map(p->sc, src, dst, p->opts.tone_mapping,
vo_opengl: add --tone-mapping-desaturate 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.
2017-07-06 03:43:00 +00:00
p->opts.tone_mapping_param, p->opts.tone_mapping_desat,
vo_opengl: add a gamut warning feature This clearly highlights all out-of-gamut/clipped pixels. (Either too bright or too saturated) Has some (documented) caveats. Also make TONE_MAPPING_CLIP stop actually clamping the value range (it's unnecessary and breaks this feature).
2017-09-10 16:18:31 +00:00
detect_peak, p->opts.gamut_warning, p->use_linear && !osd);
vo_opengl: generate 3DLUT against source and use full BT.1886 This commit refactors the 3DLUT loading mechanism to build the 3DLUT against the original source characteristics of the file. This allows us, among other things, to use a real BT.1886 profile for the source. This also allows us to actually use perceptual mappings. Finally, this reduces errors on standard gamut displays (where the previous 3DLUT target of BT.2020 was unreasonably wide). This also improves the overall accuracy of the 3DLUT due to eliminating rounding errors where possible, and allows for more accurate use of LUT-based ICC profiles. The current code is somewhat more ugly than necessary, because the idea was to implement this commit in a working state first, and then maybe refactor the profile loading mechanism in a later commit. Fixes #2815.
2016-02-13 14:33:00 +00:00
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
if (p->use_lut_3d) {
vo_opengl: manage ICC LUT texture via ra Also move the capability check to gl_video_get_lut3d(), because it seems more convenient (ra won't have a _CAP_EXT16).
2017-07-29 19:22:11 +00:00
gl_sc_uniform_texture(p->sc, "lut_3d", p->lut_3d_texture);
vo_opengl: increase 3DLUT accuracy at lower LUT sizes This code had the exact same texture indexing bug that the original scaler code had before the introduction of the LUT_POS macro to fix it. We can re-use this same macro here, and the performance drop is virtually entirely negligible. The benefit is greatly improved LUT accuracy as the 3DLUT size decreases - in particular, the old LUT started introducing more and more black crush the lower your LUT size is (because the error was essentially an over-contrast bias, with a magnitude linearly related to the lut size). The new code improves black stability as the LUT size decreases, and only at very low values (16 and below) do black levels start noticeably getting affected (due to crude linearization of the nonlinear response curve). The default value of 3dlut-size is definitely generous enough for this to make no difference out of the box, but it also causes no performance drop at all on my machine so I see no harm in improving the logic. Furthermore, this means we could easily decrease the default 3dlut size in a future commit, perhaps even down to 64x64x64 as a default. (But more testing is warranted here)
2016-07-25 08:18:41 +00:00
GLSL(vec3 cpos;)
for (int i = 0; i < 3; i++)
GLSLF("cpos[%d] = LUT_POS(color[%d], %d.0);\n", i, i, p->lut_3d_size[i]);
vo_opengl: add support for vulkan GLSL dialect Redefining texture1D / texture3D seems to be illegal, they are already built-in macros or something. So just use tex1D and tex3D instead. Additionally, GL_KHR_vulkan_glsl requires using explicit vertex locations and bindings, so make some changes to facilitate this. (It also requires explicitly setting location=0 for the color attachment output)
2017-08-20 02:27:42 +00:00
GLSL(color.rgb = tex3D(lut_3d, cpos).rgb;)
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
}
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
}
vo_opengl: add smoothmotion frame blending SmoothMotion is a way to time and blend frames made popular by MadVR. It's intended behaviour is to remove stuttering caused by mismatches between the display refresh rate and the video fps, while preserving the video's original artistic qualities (no soap opera effect). It's supposed to make 24fps video playback on 60hz monitors as close as possible to a 24hz monitor. Instead of drawing a frame once once it's pts has passed the vsync time, we redraw at the display refresh rate, and if we detect the vsync is between two frames we interpolated them (depending on their position relative to the vsync). We actually interpolate as few frames as possible to avoid a blur effect as much as possible. For example, if we were to play back a 1fps video on a 60hz monitor, we would blend at most on 1 vsync for each frame (while the other 59 vsyncs would be rendered as is). Frame interpolation is always done before scaling and in linear light when possible (an ICC profile is used, or :srgb is used).
2014-11-23 19:06:05 +00:00
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
void gl_video_set_fb_depth(struct gl_video *p, int fb_depth)
{
p->fb_depth = fb_depth;
}
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
static void pass_dither(struct gl_video *p)
{
// Assume 8 bits per component if unknown.
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
int dst_depth = p->fb_depth > 0 ? p->fb_depth : 8;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
if (p->opts.dither_depth > 0)
dst_depth = p->opts.dither_depth;
vo_opengl: use enums for choice options internally This is much more readable than hard-coding magic IDs all over the file, and removes the need for all the explanatory comments that were a direct result of this.
2016-05-15 22:14:02 +00:00
if (p->opts.dither_depth < 0 || p->opts.dither_algo == DITHER_NONE)
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
return;
if (!p->dither_texture) {
MP_VERBOSE(p, "Dither to %d.\n", dst_depth);
vo_opengl: silence -Wmaybe-uninitialized false positive 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.
2017-06-19 20:46:04 +00:00
int tex_size = 0;
void *tex_data = NULL;
vo_opengl: manage dither texture via ra Also add some more helpers. Fix the broken math.h include statement. utils.c uses ra_gl.h internals, which it shouldn't, and which will be removed again as soon as this code gets converted to ra fully.
2017-07-29 18:14:48 +00:00
const struct ra_format *fmt = NULL;
vo_opengl: do not use GL format conversion on texture upload The dither texture data is created as a float array, but uploaded to a texture with GL_R16 as internal format. We relied on GL to do the conversion from float to uint16_t. Not all GL variants even support this: GLES does not provide this conversion (one of the reasons why this code has a float16 code path). Also, ra is not going to do this. So just convert on the fly. Still keep the float16 texture format fallback, because not all GLES implementations provide GL_R16. There is some possibility that we'll need to provide some kind of upload conversion anyway for float->float16. We still rely on GL doing this implicitly, and all GL variants support it, but with RA there might be the need for explicit conversion. Even then, it might be best to reduce the number of conversion cases. I'll worry about this later.
2017-07-29 18:12:43 +00:00
void *temp = NULL;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
vo_opengl: use enums for choice options internally This is much more readable than hard-coding magic IDs all over the file, and removes the need for all the explanatory comments that were a direct result of this.
2016-05-15 22:14:02 +00:00
if (p->opts.dither_algo == DITHER_FRUIT) {
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
int sizeb = p->opts.dither_size;
int size = 1 << sizeb;
if (p->last_dither_matrix_size != size) {
p->last_dither_matrix = talloc_realloc(p, p->last_dither_matrix,
float, size * size);
mp_make_fruit_dither_matrix(p->last_dither_matrix, sizeb);
p->last_dither_matrix_size = size;
}
vo_opengl: fix precision loss of fruit dithering matrix With default setting, the matrix for fruit dithering requires 12 bits precision (values from 0/4096 to 4095/4096). But 16-bit float provides only 10 bits. In addition, when `dither-size-fruit=8` is set, 16 bits are required from the texture format. Fix this by attempting to use 16 bit integer texture first. This is still not precise, but should be better than using a half float.
2015-12-08 22:22:08 +00:00
// Prefer R16 texture since they provide higher precision.
vo_opengl: manage dither texture via ra Also add some more helpers. Fix the broken math.h include statement. utils.c uses ra_gl.h internals, which it shouldn't, and which will be removed again as soon as this code gets converted to ra fully.
2017-07-29 18:14:48 +00:00
fmt = ra_find_unorm_format(p->ra, 2, 1);
vo_opengl: do not use GL format conversion on texture upload The dither texture data is created as a float array, but uploaded to a texture with GL_R16 as internal format. We relied on GL to do the conversion from float to uint16_t. Not all GL variants even support this: GLES does not provide this conversion (one of the reasons why this code has a float16 code path). Also, ra is not going to do this. So just convert on the fly. Still keep the float16 texture format fallback, because not all GLES implementations provide GL_R16. There is some possibility that we'll need to provide some kind of upload conversion anyway for float->float16. We still rely on GL doing this implicitly, and all GL variants support it, but with RA there might be the need for explicit conversion. Even then, it might be best to reduce the number of conversion cases. I'll worry about this later.
2017-07-29 18:12:43 +00:00
if (!fmt)
vo_opengl: manage dither texture via ra Also add some more helpers. Fix the broken math.h include statement. utils.c uses ra_gl.h internals, which it shouldn't, and which will be removed again as soon as this code gets converted to ra fully.
2017-07-29 18:14:48 +00:00
fmt = ra_find_float16_format(p->ra, 1);
vo_opengl: reorganize texture format handling This merges all knowledge about texture format into a central table. Most of the work done here is actually identifying which formats exactly are supported by OpenGL(ES) under which circumstances, and keeping this information in the format table in a somewhat declarative way. (Although only to the extend needed by mpv.) In particular, ES and float formats are a horrible mess. Again this is a big refactor that might cause regression on "obscure" configurations.
2016-05-12 18:08:49 +00:00
if (fmt) {
vo_opengl: fall back to ordered dither instead of blowing up 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.
2017-06-17 11:54:21 +00:00
tex_size = size;
tex_data = p->last_dither_matrix;
vo_opengl: manage dither texture via ra Also add some more helpers. Fix the broken math.h include statement. utils.c uses ra_gl.h internals, which it shouldn't, and which will be removed again as soon as this code gets converted to ra fully.
2017-07-29 18:14:48 +00:00
if (fmt->ctype == RA_CTYPE_UNORM) {
vo_opengl: do not use GL format conversion on texture upload The dither texture data is created as a float array, but uploaded to a texture with GL_R16 as internal format. We relied on GL to do the conversion from float to uint16_t. Not all GL variants even support this: GLES does not provide this conversion (one of the reasons why this code has a float16 code path). Also, ra is not going to do this. So just convert on the fly. Still keep the float16 texture format fallback, because not all GLES implementations provide GL_R16. There is some possibility that we'll need to provide some kind of upload conversion anyway for float->float16. We still rely on GL doing this implicitly, and all GL variants support it, but with RA there might be the need for explicit conversion. Even then, it might be best to reduce the number of conversion cases. I'll worry about this later.
2017-07-29 18:12:43 +00:00
uint16_t *t = temp = talloc_array(NULL, uint16_t, size * size);
for (int n = 0; n < size * size; n++)
t[n] = p->last_dither_matrix[n] * UINT16_MAX;
tex_data = t;
}
vo_opengl: fall back to ordered dither instead of blowing up 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.
2017-06-17 11:54:21 +00:00
} else {
MP_VERBOSE(p, "GL too old. Falling back to ordered dither.\n");
p->opts.dither_algo = DITHER_ORDERED;
vo_opengl: fix precision loss of fruit dithering matrix With default setting, the matrix for fruit dithering requires 12 bits precision (values from 0/4096 to 4095/4096). But 16-bit float provides only 10 bits. In addition, when `dither-size-fruit=8` is set, 16 bits are required from the texture format. Fix this by attempting to use 16 bit integer texture first. This is still not precise, but should be better than using a half float.
2015-12-08 22:22:08 +00:00
}
vo_opengl: fall back to ordered dither instead of blowing up 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.
2017-06-17 11:54:21 +00:00
}
if (p->opts.dither_algo == DITHER_ORDERED) {
vo_opengl: do not use GL format conversion on texture upload The dither texture data is created as a float array, but uploaded to a texture with GL_R16 as internal format. We relied on GL to do the conversion from float to uint16_t. Not all GL variants even support this: GLES does not provide this conversion (one of the reasons why this code has a float16 code path). Also, ra is not going to do this. So just convert on the fly. Still keep the float16 texture format fallback, because not all GLES implementations provide GL_R16. There is some possibility that we'll need to provide some kind of upload conversion anyway for float->float16. We still rely on GL doing this implicitly, and all GL variants support it, but with RA there might be the need for explicit conversion. Even then, it might be best to reduce the number of conversion cases. I'll worry about this later.
2017-07-29 18:12:43 +00:00
temp = talloc_array(NULL, char, 8 * 8);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
mp_make_ordered_dither_matrix(temp, 8);
vo_opengl: manage dither texture via ra Also add some more helpers. Fix the broken math.h include statement. utils.c uses ra_gl.h internals, which it shouldn't, and which will be removed again as soon as this code gets converted to ra fully.
2017-07-29 18:14:48 +00:00
fmt = ra_find_unorm_format(p->ra, 1, 1);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
tex_size = 8;
tex_data = temp;
}
vo_opengl: manage dither texture via ra Also add some more helpers. Fix the broken math.h include statement. utils.c uses ra_gl.h internals, which it shouldn't, and which will be removed again as soon as this code gets converted to ra fully.
2017-07-29 18:14:48 +00:00
struct ra_tex_params params = {
.dimensions = 2,
.w = tex_size,
.h = tex_size,
.d = 1,
.format = fmt,
.render_src = true,
.src_repeat = true,
.initial_data = tex_data,
};
p->dither_texture = ra_tex_create(p->ra, &params);
vo_opengl: fix smoothmotion coefficient calculation, for real this time I've reworked pretty much all the logic to correspond to what the theory actually describes. With this commit, playback is wonderfully smooth on my machine.
2015-02-19 13:03:18 +00:00
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
debug_check_gl(p, "dither setup");
vo_opengl: do not use GL format conversion on texture upload The dither texture data is created as a float array, but uploaded to a texture with GL_R16 as internal format. We relied on GL to do the conversion from float to uint16_t. Not all GL variants even support this: GLES does not provide this conversion (one of the reasons why this code has a float16 code path). Also, ra is not going to do this. So just convert on the fly. Still keep the float16 texture format fallback, because not all GLES implementations provide GL_R16. There is some possibility that we'll need to provide some kind of upload conversion anyway for float->float16. We still rely on GL doing this implicitly, and all GL variants support it, but with RA there might be the need for explicit conversion. Even then, it might be best to reduce the number of conversion cases. I'll worry about this later.
2017-07-29 18:12:43 +00:00
talloc_free(temp);
vo_opengl: greatly increase smoothmotion performance Instead of rendering and upscaling each video frame on every vsync, this version of the algorithm only draws them once and caches the result, so the only operation that has to run on every vsync is a cheap linear interpolation, plus CMS/dithering. On my machine, this is a huge speedup for 24 Hz content (on a 60 Hz monitor), up to 120% faster. (The speedup is not quite 250% because of the overhead that the larger FBOs and CMS provides) In terms of the implementation, this commit basically swaps interpolation and upscaling - upscaling is moved to inter_program, and interpolation is moved to the final_program. Furthermore, the main bulk of the frame rendering logic (upscaling etc.) was moved to a separete function, which is called from gl_video_interpolate_frame only if it's actually necessarily, and skipped otherwise.
2015-02-20 21:12:02 +00:00
}
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
GLSLF("// dithering\n");
// This defines how many bits are considered significant for output on
// screen. The superfluous bits will be used for rounding according to the
// dither matrix. The precision of the source implicitly decides how many
// dither patterns can be visible.
vo_opengl: reduce number of uniforms in dithering pass We now update uniforms every time, so we should try to reduce the number of uniforms to avoid performance penalties. (Originally, some caching was planned, but it looks like it would be too complicated to implement compared to the expected gains.)
2015-03-16 19:22:09 +00:00
int dither_quantization = (1 << dst_depth) - 1;
vo_opengl: manage dither texture via ra Also add some more helpers. Fix the broken math.h include statement. utils.c uses ra_gl.h internals, which it shouldn't, and which will be removed again as soon as this code gets converted to ra fully.
2017-07-29 18:14:48 +00:00
int dither_size = p->dither_texture->params.w;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
vo_opengl: manage dither texture via ra Also add some more helpers. Fix the broken math.h include statement. utils.c uses ra_gl.h internals, which it shouldn't, and which will be removed again as soon as this code gets converted to ra fully.
2017-07-29 18:14:48 +00:00
gl_sc_uniform_texture(p->sc, "dither", p->dither_texture);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
vo_opengl: manage dither texture via ra Also add some more helpers. Fix the broken math.h include statement. utils.c uses ra_gl.h internals, which it shouldn't, and which will be removed again as soon as this code gets converted to ra fully.
2017-07-29 18:14:48 +00:00
GLSLF("vec2 dither_pos = gl_FragCoord.xy * 1.0/%d.0;\n", dither_size);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
if (p->opts.temporal_dither) {
vo_opengl: add temporal-dither-period option This was requested multiple times by users, and it's not hard to implement and/or maintain.
2015-07-20 17:09:22 +00:00
int phase = (p->frames_rendered / p->opts.temporal_dither_period) % 8u;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
float r = phase * (M_PI / 2); // rotate
float m = phase < 4 ? 1 : -1; // mirror
float matrix[2][2] = {{cos(r), -sin(r) },
{sin(r) * m, cos(r) * m}};
vo_gpu: attempt to avoid UBOs for dynamic variables This makes the radeon driver shut up about frequently updating STATIC_DRAW UBOs (--opengl-debug), and also reduces the amount of synchronization necessary for vulkan uniform buffers. Also add some extra debugging/tracing code paths. I went with a flags-based approach in case we ever want to extend this.
2017-09-17 08:55:43 +00:00
gl_sc_uniform_dynamic(p->sc);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
gl_sc_uniform_mat2(p->sc, "dither_trafo", true, &matrix[0][0]);
GLSL(dither_pos = dither_trafo * dither_pos;)
vo_opengl: fix smoothmotion coefficient calculation, for real this time I've reworked pretty much all the logic to correspond to what the theory actually describes. With this commit, playback is wonderfully smooth on my machine.
2015-02-19 13:03:18 +00:00
}
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
GLSL(float dither_value = texture(dither, dither_pos).r;)
vo_opengl: avoid constant divisions 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
2017-07-17 03:23:55 +00:00
GLSLF("color = floor(color * %d.0 + dither_value + 0.5 / %d.0) * 1.0/%d.0;\n",
vo_opengl: manage dither texture via ra Also add some more helpers. Fix the broken math.h include statement. utils.c uses ra_gl.h internals, which it shouldn't, and which will be removed again as soon as this code gets converted to ra fully.
2017-07-29 18:14:48 +00:00
dither_quantization, dither_size * dither_size, dither_quantization);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
}
vo_opengl: blend-subtitles in non-linear light
2015-03-29 04:34:34 +00:00
// Draws the OSD, in scene-referred colors.. If cms is true, subtitles are
// instead adapted to the display's gamut.
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
static void pass_draw_osd(struct gl_video *p, int draw_flags, double pts,
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct mp_osd_res rect, struct ra_fbo fbo, bool cms)
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
{
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
if ((draw_flags & OSD_DRAW_SUB_ONLY) && (draw_flags & OSD_DRAW_OSD_ONLY))
return;
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
mpgl_osd_generate(p->osd, rect, pts, p->image_params.stereo_out, draw_flags);
vo_opengl: measure pass_draw_osd as a whole In the past, this always measured the per-shader execution times of the individual OSD parts, which was thrown off because the shader was reused anyway. (And apparently recording the OSD shader execution times was removed completely, probably because of them being so unrealiably anyway) Since ra_timer no longer has the restriction of not allowing timers to run concurrently, we can just wrap the entire OSD block inside a single osd_timer now, and record that. (Technically, this can still be off when using --blend-subtitles=video/yes and showing a full-screen OSD at the same time. Maybe this can be done better?)
2017-08-05 16:59:28 +00:00
timer_pool_start(p->osd_timer);
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
for (int n = 0; n < MAX_OSD_PARTS; n++) {
vo_opengl: osd: use new VAO mechanism 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.
2017-07-22 19:53:50 +00:00
// (This returns false if this part is empty with nothing to draw.)
if (!mpgl_osd_draw_prepare(p->osd, n, p->sc))
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
continue;
vo_opengl: generalize HDR tone mapping mechanism This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
2016-06-29 07:28:17 +00:00
// When subtitles need to be color managed, assume they're in sRGB
// (for lack of anything saner to do)
vo_opengl: refactor HDR mechanism Instead of doing HDR tone mapping on an ad-hoc basis inside pass_colormanage, the reference peak of an image is now part of the image params (alongside colorspace, gamma, etc.) and tone mapping is done whenever peak_src != peak_dst. To get sensible behavior when mixing HDR and SDR content and displays, target-brightness is a generic filler for "the assumed brightness of SDR content". This gets rid of the weird display_scaled hack, sets the framework for multiple HDR functions with difference reference peaks, and allows us to (in a future commit) autodetect the right source peak from the HDR metadata. (Apart from metadata, the source peak can also be controlled via vf_format. For HDR content this adjusts the overall image brightness, for SDR content it's like simulating a different exposure)
2016-05-30 17:56:58 +00:00
if (cms) {
vo_opengl: generalize HDR tone mapping mechanism This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
2016-06-29 07:28:17 +00:00
static const struct mp_colorspace csp_srgb = {
.primaries = MP_CSP_PRIM_BT_709,
.gamma = MP_CSP_TRC_SRGB,
vo_opengl: implement support for OOTFs and non-display referred content 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.
2017-06-14 18:06:56 +00:00
.light = MP_CSP_LIGHT_DISPLAY,
vo_opengl: generalize HDR tone mapping mechanism This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
2016-06-29 07:28:17 +00:00
};
pass_colormanage(p, csp_srgb, true);
vo_opengl: refactor HDR mechanism Instead of doing HDR tone mapping on an ad-hoc basis inside pass_colormanage, the reference peak of an image is now part of the image params (alongside colorspace, gamma, etc.) and tone mapping is done whenever peak_src != peak_dst. To get sensible behavior when mixing HDR and SDR content and displays, target-brightness is a generic filler for "the assumed brightness of SDR content". This gets rid of the weird display_scaled hack, sets the framework for multiple HDR functions with difference reference peaks, and allows us to (in a future commit) autodetect the right source peak from the HDR metadata. (Apart from metadata, the source peak can also be controlled via vf_format. For HDR content this adjusts the overall image brightness, for SDR content it's like simulating a different exposure)
2016-05-30 17:56:58 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
mpgl_osd_draw_finish(p->osd, n, p->sc, fbo);
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
}
vo_opengl: measure pass_draw_osd as a whole In the past, this always measured the per-shader execution times of the individual OSD parts, which was thrown off because the shader was reused anyway. (And apparently recording the OSD shader execution times was removed completely, probably because of them being so unrealiably anyway) Since ra_timer no longer has the restriction of not allowing timers to run concurrently, we can just wrap the entire OSD block inside a single osd_timer now, and record that. (Technically, this can still be off when using --blend-subtitles=video/yes and showing a full-screen OSD at the same time. Maybe this can be done better?)
2017-08-05 16:59:28 +00:00
timer_pool_stop(p->osd_timer);
pass_describe(p, "drawing osd");
pass_record(p, timer_pool_measure(p->osd_timer));
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
}
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
static float chroma_realign(int size, int pixel)
vo_opengl: partially fix dumb-mode cropping with rotation Combining rotation and cropping didn't work. It was just completely broken. I'm still not sure if this is correct. Chroma positioning seems to be broken on rotation. There might also be a problem with non-mod-2 frame sizes. Still, strictly an improvement for both rotated and non-rotated rendering modes. Also, this could probably be written in a more elegant way.
2016-09-30 20:14:47 +00:00
{
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
return size / (float)chroma_upsize(size, pixel);
vo_opengl: partially fix dumb-mode cropping with rotation Combining rotation and cropping didn't work. It was just completely broken. I'm still not sure if this is correct. Chroma positioning seems to be broken on rotation. There might also be a problem with non-mod-2 frame sizes. Still, strictly an improvement for both rotated and non-rotated rendering modes. Also, this could probably be written in a more elegant way.
2016-09-30 20:14:47 +00:00
}
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
// Minimal rendering code path, for GLES or OpenGL 2.1 without proper FBOs.
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
static void pass_render_frame_dumb(struct gl_video *p)
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
{
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct image img[4];
vo_opengl: add hooks and rework pass_read_video The hook mechanism allows arbitrary processing stages to get dispatched whenever certain named textures have been "finalized" by the code. This is mostly meant to serve as a change that opens up the internal processing in pass_read_video to user scripts, but as a side benefit all of the code dealing with offsets and plane alignment and other such confusing things has been rewritten. This hook mechanism is powerful enough to cover the needs of both debanding and prescaling (and more), so as a result they can be removed from pass_read_video entirely and implemented through hooks. Some avenues for optimization: - The prescale hook is currently somewhat distributed code-wise. It might be cleaner to split it into superxbr and NNEDI3 hooks which can each be self-contained. - It might be possible to move a large part of the hook code out to an external file (including the hook definitions for debanding and prescaling), which would be very much desired. - Currently, some stages (chroma merging, integer conversion) will *always* run even if unnecessary. I'm planning another series of refactors (deferred img_tex) to allow dropping unnecessary shader stages like these, but that's probably some ways away. In the meantime it would be doable to re-add some of the logic to skip these stages if we know we don't need them. - More hook locations could be added (?)
2016-04-16 16:14:32 +00:00
struct gl_transform off[4];
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
pass_get_images(p, &p->image, img, off);
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
struct gl_transform transform;
vo_opengl: fix rotation This has been completely broken since commit 93546f0c. But even before, rotation handling did not make too much sense. In particular, it rotated the contents of the cropped image, instead of adjusting the crop rectangle as well. The result was that things like panscan or zooming did not behave as expected with rotation applied. The same is true for vertical flipping. Flipping is triggered by negative image stride. OpenGL does not support flipping the image on upload, so it's done as part of the rendering. It can be triggered with --vf=flip, but other filters and even decoders could setup negative stride to flip the image. Fix these issues by applying transforms to texture coordinates properly, and by making rotation and flipping part of these transforms. This still doesn't work properly for separated scaling. The issue is that we'd have to adjust how the passes are done. For now, pick a very stupid solution by rotating the image to a FBO, and then scaling from that. This has the avantage that the scale logic doesn't have to be complicated for such a rare case. It could be improved later. Prescaling is apparently still broken. I don't know if chroma positioning works properly either. None of this should affect the case with no rotation.
2016-03-28 14:30:48 +00:00
compute_src_transform(p, &transform);
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
int index = 0;
for (int i = 0; i < p->plane_count; i++) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
int cw = img[i].type == PLANE_CHROMA ? p->ra_format.chroma_w : 1;
int ch = img[i].type == PLANE_CHROMA ? p->ra_format.chroma_h : 1;
vo_opengl: partially fix dumb-mode cropping with rotation Combining rotation and cropping didn't work. It was just completely broken. I'm still not sure if this is correct. Chroma positioning seems to be broken on rotation. There might also be a problem with non-mod-2 frame sizes. Still, strictly an improvement for both rotated and non-rotated rendering modes. Also, this could probably be written in a more elegant way.
2016-09-30 20:14:47 +00:00
if (p->image_params.rotate % 180 == 90)
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
MPSWAP(int, cw, ch);
vo_opengl: partially fix dumb-mode cropping with rotation Combining rotation and cropping didn't work. It was just completely broken. I'm still not sure if this is correct. Chroma positioning seems to be broken on rotation. There might also be a problem with non-mod-2 frame sizes. Still, strictly an improvement for both rotated and non-rotated rendering modes. Also, this could probably be written in a more elegant way.
2016-09-30 20:14:47 +00:00
struct gl_transform t = transform;
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
t.m[0][0] *= chroma_realign(p->texture_w, cw);
t.m[1][1] *= chroma_realign(p->texture_h, ch);
vo_opengl: partially fix dumb-mode cropping with rotation Combining rotation and cropping didn't work. It was just completely broken. I'm still not sure if this is correct. Chroma positioning seems to be broken on rotation. There might also be a problem with non-mod-2 frame sizes. Still, strictly an improvement for both rotated and non-rotated rendering modes. Also, this could probably be written in a more elegant way.
2016-09-30 20:14:47 +00:00
vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usage These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
2017-06-30 15:13:58 +00:00
t.t[0] /= cw;
t.t[1] /= ch;
vo_opengl: partially fix dumb-mode cropping with rotation Combining rotation and cropping didn't work. It was just completely broken. I'm still not sure if this is correct. Chroma positioning seems to be broken on rotation. There might also be a problem with non-mod-2 frame sizes. Still, strictly an improvement for both rotated and non-rotated rendering modes. Also, this could probably be written in a more elegant way.
2016-09-30 20:14:47 +00:00
t.t[0] += off[i].t[0];
t.t[1] += off[i].t[1];
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
gl_transform_trans(img[i].transform, &t);
img[i].transform = t;
vo_opengl: partially fix dumb-mode cropping with rotation Combining rotation and cropping didn't work. It was just completely broken. I'm still not sure if this is correct. Chroma positioning seems to be broken on rotation. There might also be a problem with non-mod-2 frame sizes. Still, strictly an improvement for both rotated and non-rotated rendering modes. Also, this could probably be written in a more elegant way.
2016-09-30 20:14:47 +00:00
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
copy_image(p, &index, img[i]);
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
}
pass_convert_yuv(p);
}
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
// The main rendering function, takes care of everything up to and including
vo_opengl: cleanup frame reupload logic There are some situations when redrawing is requested, but the current frame was deleted. This could happen when switching e.g. hw decoding mid-stream. Separate uploading/drawing and fix the condition.
2015-07-17 21:21:04 +00:00
// upscaling. p->image is rendered.
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
// flags: bit set of RENDER_FRAME_* flags
static bool pass_render_frame(struct gl_video *p, struct mp_image *mpi,
uint64_t id, int flags)
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
{
vo_opengl: merge uploading and rendering 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.
2017-06-29 15:09:11 +00:00
// initialize the texture parameters and temporary variables
vo_opengl: make image size dynamic during rendering This commit marks the image size variables temporary, and renames them in order to prevent any potential confusion in the future.
2015-10-23 17:52:03 +00:00
p->texture_w = p->image_params.w;
p->texture_h = p->image_params.h;
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
p->texture_offset = identity_trans;
vo_opengl: refactor plane-skipping optimizations Instead of hard-coding the logic and planes to skip, factor this out to a reusible function, and instead add the number of relevant coordinates to the texture state.
2016-03-05 11:38:51 +00:00
p->components = 0;
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
p->num_saved_imgs = 0;
p->idx_hook_textures = 0;
vo_opengl: fix incorrect video rendering after vdpau preemption recovery This could also trigger in certain other cases, whenever it falls back to dumb mode.
2016-09-07 16:48:24 +00:00
p->use_linear = false;
vo_opengl: make image size dynamic during rendering This commit marks the image size variables temporary, and renames them in order to prevent any potential confusion in the future.
2015-10-23 17:52:03 +00:00
vo_opengl: merge uploading and rendering 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.
2017-06-29 15:09:11 +00:00
// try uploading the frame
if (!pass_upload_image(p, mpi, id))
return false;
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
if (p->image_params.rotate % 180 == 90)
MPSWAP(int, p->texture_w, p->texture_h);
vo_opengl: enable dumb-mode automatically if possible I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
2015-11-19 20:22:24 +00:00
if (p->dumb_mode)
vo_opengl: merge uploading and rendering 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.
2017-06-29 15:09:11 +00:00
return true;
vo_opengl: add time queries To avoid blocking the CPU, we use 8 time objects and rotate through them, only blocking until the last possible moment (before we need access to them on the next iteration through the ring buffer). I tested it out on my machine and 4 query objects were enough to guarantee block-free querying, but the extra margin shouldn't hurt. Frame render times are just output at the end of each frame, via MP_DBG. This might be improved in the future. (In particular, I want to expose these numbers as properties so that users get some more visible feedback about render times) Currently, we measure pass_render_frame and pass_draw_to_screen separately because the former might be called multiple times due to interpolation. Doing it this way gives more faithful numbers. Same goes for frame upload times.
2016-06-05 19:55:30 +00:00
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
pass_read_video(p);
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
pass_opt_hook_point(p, "NATIVE", &p->texture_offset);
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
pass_convert_yuv(p);
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
pass_opt_hook_point(p, "MAINPRESUB", &p->texture_offset);
vo_opengl: add blend-subtitles-res This can be used to draw the subtitles at the video's native res, which can make them look more natural and increases performance.
2015-04-10 20:19:44 +00:00
// For subtitles
double vpts = p->image.mpi->pts;
if (vpts == MP_NOPTS_VALUE)
vpts = p->osd_pts;
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
if (p->osd && p->opts.blend_subs == BLEND_SUBS_VIDEO &&
(flags & RENDER_FRAME_SUBS))
{
vo_opengl: fix blend-subtitles-res=video & anamorphic video Since scaling the video changes the aspect ratio, we have to compensate for this when rendering subtitles.
2015-04-11 13:53:00 +00:00
double scale[2];
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
get_scale_factors(p, false, scale);
vo_opengl: fix blend-subtitles-res=video & anamorphic video Since scaling the video changes the aspect ratio, we have to compensate for this when rendering subtitles.
2015-04-11 13:53:00 +00:00
struct mp_osd_res rect = {
vo_opengl: make image size dynamic during rendering This commit marks the image size variables temporary, and renames them in order to prevent any potential confusion in the future.
2015-10-23 17:52:03 +00:00
.w = p->texture_w, .h = p->texture_h,
vo_opengl: fix blend-subtitles-res=video & anamorphic video Since scaling the video changes the aspect ratio, we have to compensate for this when rendering subtitles.
2015-04-11 13:53:00 +00:00
.display_par = scale[1] / scale[0], // counter compensate scaling
};
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
finish_pass_tex(p, &p->blend_subs_tex, rect.w, rect.h);
struct ra_fbo fbo = { p->blend_subs_tex };
pass_draw_osd(p, OSD_DRAW_SUB_ONLY, vpts, rect, fbo, false);
pass_read_tex(p, p->blend_subs_tex);
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
pass_describe(p, "blend subs video");
vo_opengl: add blend-subtitles-res This can be used to draw the subtitles at the video's native res, which can make them look more natural and increases performance.
2015-04-10 20:19:44 +00:00
}
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
pass_opt_hook_point(p, "MAIN", &p->texture_offset);
vo_opengl: remove sharpen scalers, add sharpen sub-option This turns the old scalers (inherited from MPlayer) into a pre- processing step (after color conversion and before scaling). The code for the "sharpen5" scaler is reused for this. The main reason MPlayer implemented this as scalers was perhaps because FBOs were too expensive, and making it a scaler allowed to implement this in 1 pass. But unsharp masking is not really a scaler, and I would guess the result is more like combining bilinear scaling and unsharp masking.
2015-09-23 20:43:27 +00:00
vo_opengl: color manage after interpolation This moves the color management code out of pass_render_main (which is now dedicated solely to up/downscaling and hence renamed pass_scale_main) and into a new function, which gets called from pass_draw_to_screen instead. This makes more sense from a logical standpoint, and also means that we interpolate in linear RGB, before color management - rather than after it, which is significantly better for color accuracy and probably also interpolation quality.
2015-03-15 21:52:34 +00:00
pass_scale_main(p);
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
int vp_w = p->dst_rect.x1 - p->dst_rect.x0,
vp_h = p->dst_rect.y1 - p->dst_rect.y0;
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
if (p->osd && p->opts.blend_subs == BLEND_SUBS_YES &&
(flags & RENDER_FRAME_SUBS))
{
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
// Recreate the real video size from the src/dst rects
struct mp_osd_res rect = {
.w = vp_w, .h = vp_h,
vo_opengl: make image size dynamic during rendering This commit marks the image size variables temporary, and renames them in order to prevent any potential confusion in the future.
2015-10-23 17:52:03 +00:00
.ml = -p->src_rect.x0, .mr = p->src_rect.x1 - p->image_params.w,
.mt = -p->src_rect.y0, .mb = p->src_rect.y1 - p->image_params.h,
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
.display_par = 1.0,
};
// Adjust margins for scale
double scale[2];
vo_opengl: improve rotation handling (again) Apply basic transformations like rotation by 90° and mirroring when sampling from the source textures. The original idea was making this part of img_tex.transform, but this didn't work: lots of code plays tricks on the transform, so manipulating it is not necessarily transparent, especially when width/height are switched. So add a new pre_transform field, which is strictly applied before the normal transform. This fixes most glitches involved with rotating the image. Cropping and rotation are now weirdly separated, even though they could be done in the same step. I think this is not much of a problem, and has the advantage that changing panscan does not trigger FBO reallocations (I think...).
2016-04-08 20:21:31 +00:00
get_scale_factors(p, true, scale);
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
rect.ml *= scale[0]; rect.mr *= scale[0];
rect.mt *= scale[1]; rect.mb *= scale[1];
vo_opengl: blend-subtitles in non-linear light
2015-03-29 04:34:34 +00:00
// We should always blend subtitles in non-linear light
vo_opengl: avoid redundant double-gamma conversion Due to the way color management in mpv worked historically, the subtitle blending function was written to preserve the linearity of the input. (In the past, the 3DLUT function required linear inputs) Since the 3DLUT was refactored to accept the video color directly, the re-linearization after blending is now virtually always redundant. (Notably, it's also redundant when CMS is turned off, so this way of writing the code stopped making sense a long time ago. It is a remnant from before the pass_colormanage function was as flexible as it is now)
2016-05-15 22:19:25 +00:00
if (p->use_linear) {
mp_image: split colorimetry metadata into its own struct This has two reasons: 1. I tend to add new fields to this metadata, and every time I've done so I've consistently forgotten to update all of the dozens of places in which this colorimetry metadata might end up getting used. While most usages don't really care about most of the metadata, sometimes the intend was simply to “copy” the colorimetry metadata from one struct to another. With this being inside a substruct, those lines of code can now simply read a.color = b.color without having to care about added or removed fields. 2. It makes the type definitions nicer for upcoming refactors. In going through all of the usages, I also expanded a few where I felt that omitting the “young” fields was a bug.
2016-06-29 07:16:13 +00:00
pass_delinearize(p->sc, p->image_params.color.gamma);
vo_opengl: avoid redundant double-gamma conversion Due to the way color management in mpv worked historically, the subtitle blending function was written to preserve the linearity of the input. (In the past, the 3DLUT function required linear inputs) Since the 3DLUT was refactored to accept the video color directly, the re-linearization after blending is now virtually always redundant. (Notably, it's also redundant when CMS is turned off, so this way of writing the code stopped making sense a long time ago. It is a remnant from before the pass_colormanage function was as flexible as it is now)
2016-05-15 22:19:25 +00:00
p->use_linear = false;
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
finish_pass_tex(p, &p->blend_subs_tex, p->texture_w, p->texture_h);
struct ra_fbo fbo = { p->blend_subs_tex };
pass_draw_osd(p, OSD_DRAW_SUB_ONLY, vpts, rect, fbo, false);
pass_read_tex(p, p->blend_subs_tex);
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
pass_describe(p, "blend subs");
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
}
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
pass_opt_hook_point(p, "SCALED", NULL);
vo_opengl: merge uploading and rendering 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.
2017-06-29 15:09:11 +00:00
return true;
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static void pass_draw_to_screen(struct gl_video *p, struct ra_fbo fbo)
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
{
vo_opengl: enable dumb-mode automatically if possible I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
2015-11-19 20:22:24 +00:00
if (p->dumb_mode)
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
pass_render_frame_dumb(p);
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
vo_opengl: treat non-blended subtitles as sRGB Currently, the code just skipped CMS completely. This commit treats them as sRGB by default, instead. This also refactors much of the color management code to make it more generalized and re-usable.
2015-03-27 10:12:46 +00:00
// Adjust the overall gamma before drawing to screen
if (p->user_gamma != 1) {
gl_sc_uniform_f(p->sc, "user_gamma", p->user_gamma);
GLSL(color.rgb = clamp(color.rgb, 0.0, 1.0);)
GLSL(color.rgb = pow(color.rgb, vec3(user_gamma));)
}
vo_opengl: draw transparency checkerboard after upscaling This also draws it after color management etc. In a nutshell, this change makes the transparency checkerboard independent of upscaling, panning, cropping etc. It will always be the same apparent size and position (relative to the window). It will also be independent of the video colorspace and such things. (Note: This might cause white imbalance issues if playing a file with a white point that does not match the display, in absolute colorimetric mode. But that's uncommon, especially in conjunction with transparent image files, so it's not a primary concern here)
2016-03-29 20:26:24 +00:00
vo_opengl: generalize HDR tone mapping mechanism This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
2016-06-29 07:28:17 +00:00
pass_colormanage(p, p->image_params.color, false);
vo_opengl: draw transparency checkerboard after upscaling This also draws it after color management etc. In a nutshell, this change makes the transparency checkerboard independent of upscaling, panning, cropping etc. It will always be the same apparent size and position (relative to the window). It will also be independent of the video colorspace and such things. (Note: This might cause white imbalance issues if playing a file with a white point that does not match the display, in absolute colorimetric mode. But that's uncommon, especially in conjunction with transparent image files, so it's not a primary concern here)
2016-03-29 20:26:24 +00:00
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
// Since finish_pass_fbo doesn't work with compute shaders, and neither
vo_opengl: support HDR peak detection This is done via compute shaders. As a consequence, the tone mapping algorithms had to be rewritten to compute their known constants in GLSL (ahead of time), instead of doing it once. Didn't affect performance. Using shmem/SSBO atomics in this way is extremely fast on nvidia, but it might be slow on other platforms. Needs testing. Unfortunately, setting up the SSBO still requires OpenGL calls, which means I can't have it in video_shaders.c, where it belongs. But I'll defer worrying about that until the backend refactor, since then I'll be breaking up the video/video_shaders structure anyway.
2017-07-17 19:39:06 +00:00
// does the checkerboard/dither code, we may need an indirection via
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
// p->screen_tex here.
vo_opengl: make compute shaders more flexible This allows users to do their own custom sample writing, mainly meant to address use cases such as RAVU. Also clean up the compute shader code a bit.
2017-07-29 18:41:50 +00:00
if (p->pass_compute.active) {
vo_opengl: support HDR peak detection This is done via compute shaders. As a consequence, the tone mapping algorithms had to be rewritten to compute their known constants in GLSL (ahead of time), instead of doing it once. Didn't affect performance. Using shmem/SSBO atomics in this way is extremely fast on nvidia, but it might be slow on other platforms. Needs testing. Unfortunately, setting up the SSBO still requires OpenGL calls, which means I can't have it in video_shaders.c, where it belongs. But I'll defer worrying about that until the backend refactor, since then I'll be breaking up the video/video_shaders structure anyway.
2017-07-17 19:39:06 +00:00
int o_w = p->dst_rect.x1 - p->dst_rect.x0,
o_h = p->dst_rect.y1 - p->dst_rect.y0;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
finish_pass_tex(p, &p->screen_tex, o_w, o_h);
struct image tmp = image_wrap(p->screen_tex, PLANE_RGB, p->components);
copy_image(p, &(int){0}, tmp);
vo_opengl: support HDR peak detection This is done via compute shaders. As a consequence, the tone mapping algorithms had to be rewritten to compute their known constants in GLSL (ahead of time), instead of doing it once. Didn't affect performance. Using shmem/SSBO atomics in this way is extremely fast on nvidia, but it might be slow on other platforms. Needs testing. Unfortunately, setting up the SSBO still requires OpenGL calls, which means I can't have it in video_shaders.c, where it belongs. But I'll defer worrying about that until the backend refactor, since then I'll be breaking up the video/video_shaders structure anyway.
2017-07-17 19:39:06 +00:00
}
vo_opengl: blend against background color for --alpha=blend Do it after color management, etc. so that it matches the color drawn in the margins.
2016-11-12 18:19:40 +00:00
if (p->has_alpha){
if (p->opts.alpha_mode == ALPHA_BLEND_TILES) {
// Draw checkerboard pattern to indicate transparency
GLSLF("// transparency checkerboard\n");
vo_opengl: avoid constant divisions 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
2017-07-17 03:23:55 +00:00
GLSL(bvec2 tile = lessThan(fract(gl_FragCoord.xy * 1.0/32.0), vec2(0.5));)
vo_gpu: reduce the --alpha=blend-tiles checkerboard intensity This was sort of grating by default and made it really hard to actually read e.g. text on top of a transparent background. I decided to approach the problem from both directions, making the whites darker and the grays lighter. This brings it closer to the dynamic range of e.g. the wikipedia transparent svg preview.
2017-09-22 19:08:08 +00:00
GLSL(vec3 background = vec3(tile.x == tile.y ? 0.93 : 0.87);)
video: fix alpha handling Regression since ec6e8a31e092a1d. Removal of the explicit else case always applies the conversion to premultiplied alpha in the else branch. We want to scale with multiplied alpha, but we don't want to multiply with alpha again on top of it. Fixes #4983, hopefully.
2017-10-19 17:01:33 +00:00
GLSL(color.rgb += background.rgb * (1.0 - color.a);)
GLSL(color.a = 1.0;)
vo_opengl: blend against background color for --alpha=blend Do it after color management, etc. so that it matches the color drawn in the margins.
2016-11-12 18:19:40 +00:00
} else if (p->opts.alpha_mode == ALPHA_BLEND) {
// Blend into background color (usually black)
struct m_color c = p->opts.background;
GLSLF("vec4 background = vec4(%f, %f, %f, %f);\n",
c.r / 255.0, c.g / 255.0, c.b / 255.0, c.a / 255.0);
video: fix alpha handling Regression since ec6e8a31e092a1d. Removal of the explicit else case always applies the conversion to premultiplied alpha in the else branch. We want to scale with multiplied alpha, but we don't want to multiply with alpha again on top of it. Fixes #4983, hopefully.
2017-10-19 17:01:33 +00:00
GLSL(color.rgb += background.rgb * (1.0 - color.a);)
GLSL(color.a = background.a;)
vo_opengl: blend against background color for --alpha=blend Do it after color management, etc. so that it matches the color drawn in the margins.
2016-11-12 18:19:40 +00:00
}
vo_opengl: draw transparency checkerboard after upscaling This also draws it after color management etc. In a nutshell, this change makes the transparency checkerboard independent of upscaling, panning, cropping etc. It will always be the same apparent size and position (relative to the window). It will also be independent of the video colorspace and such things. (Note: This might cause white imbalance issues if playing a file with a white point that does not match the display, in absolute colorimetric mode. But that's uncommon, especially in conjunction with transparent image files, so it's not a primary concern here)
2016-03-29 20:26:24 +00:00
}
vo_opengl: add optional hook points These are "sequence points" where the image could be rendered out to an FBO, hooked, and re-loaded if any such hook exists. This is perfect for things like the current user shaders system, as well as optional effects like unsharp masking. Note that since we have to pick *some* FBO to store the optionally hooked texture, we just store it in an array indexed by an increasing counter. Since we only ever store as many as MAX_TEXTURE_HOOKS + all internal hook points entries, this is guaranteed to be enough space. This commit also removes some of the now unused FBOs.
2016-04-19 18:45:40 +00:00
pass_opt_hook_point(p, "OUTPUT", NULL);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
pass_dither(p);
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
pass_describe(p, "output to screen");
vo_gpu: invalidate fbotex before drawing Don't discard the OSD or pass_draw_to_screen passes though. Could be faster on some hardware.
2017-08-18 00:31:58 +00:00
finish_pass_fbo(p, fbo, false, &p->dst_rect);
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
}
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
// flags: bit set of RENDER_FRAME_* flags
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
static bool update_surface(struct gl_video *p, struct mp_image *mpi,
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
uint64_t id, struct surface *surf, int flags)
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
{
int vp_w = p->dst_rect.x1 - p->dst_rect.x0,
vo_opengl: add FBOTEX_FUZZY alias Minor reusability factor
2015-03-25 22:06:46 +00:00
vp_h = p->dst_rect.y1 - p->dst_rect.y0;
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
vo_opengl: adjust the rules for linearization Two changes, compounded into one since they affect the same logic: 1. Never use linearization for HDR downscaling 2. Always use linearization for interpolation Instead of fixing p->use_linear at the beginning of pass_render_frame, we flip it on "dynamically" as needed. I plan on killing this p->use_linear frame (along with other per-pass metadata) and moving them into their own struct for tracking the "current" state of the video, but that's a separate/upcoming refactor. As a small bonus, reduce some code duplication in the interpolation logic. Fixes #4631
2017-07-24 21:22:30 +00:00
pass_info_reset(p, false);
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
if (!pass_render_frame(p, mpi, id, flags))
vo_opengl: adjust the rules for linearization Two changes, compounded into one since they affect the same logic: 1. Never use linearization for HDR downscaling 2. Always use linearization for interpolation Instead of fixing p->use_linear at the beginning of pass_render_frame, we flip it on "dynamically" as needed. I plan on killing this p->use_linear frame (along with other per-pass metadata) and moving them into their own struct for tracking the "current" state of the video, but that's a separate/upcoming refactor. As a small bonus, reduce some code duplication in the interpolation logic. Fixes #4631
2017-07-24 21:22:30 +00:00
return false;
// Frame blending should always be done in linear light to preserve the
// overall brightness, otherwise this will result in flashing dark frames
// because mixing in compressed light artificially darkens the results
if (!p->use_linear) {
p->use_linear = true;
pass_linearize(p->sc, p->image_params.color.gamma);
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
finish_pass_tex(p, &surf->tex, vp_w, vp_h);
vo_opengl: adjust the rules for linearization Two changes, compounded into one since they affect the same logic: 1. Never use linearization for HDR downscaling 2. Always use linearization for interpolation Instead of fixing p->use_linear at the beginning of pass_render_frame, we flip it on "dynamically" as needed. I plan on killing this p->use_linear frame (along with other per-pass metadata) and moving them into their own struct for tracking the "current" state of the video, but that's a separate/upcoming refactor. As a small bonus, reduce some code duplication in the interpolation logic. Fixes #4631
2017-07-24 21:22:30 +00:00
surf->id = id;
surf->pts = mpi->pts;
return true;
}
// Draws an interpolate frame to fbo, based on the frame timing in t
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
// flags: bit set of RENDER_FRAME_* flags
vo_opengl: adjust the rules for linearization Two changes, compounded into one since they affect the same logic: 1. Never use linearization for HDR downscaling 2. Always use linearization for interpolation Instead of fixing p->use_linear at the beginning of pass_render_frame, we flip it on "dynamically" as needed. I plan on killing this p->use_linear frame (along with other per-pass metadata) and moving them into their own struct for tracking the "current" state of the video, but that's a separate/upcoming refactor. As a small bonus, reduce some code duplication in the interpolation logic. Fixes #4631
2017-07-24 21:22:30 +00:00
static void gl_video_interpolate_frame(struct gl_video *p, struct vo_frame *t,
vo_gpu: make screenshots use the GL renderer Using the GL renderer for color conversion will make sure screenshots will use the same conversion as normal video rendering. It can do this for all types of screenshots. The logic when to write 16 bit PNGs changes. To approximate the old behavior, we decide by looking whether the source video format has more than 8 bits per component. We apply this logic even for window screenshots. Also, 16 bit PNGs now always include an unused alpha channel. The reason is that FFmpeg has RGB48 and RGBA64 formats, but no RGB064. RGB48 is 3 bytes and usually not supported by GPUs for rendering, so we have to use RGBA64, which forces an alpha channel. Will break for users who use --target-trc and similar options. I considered creating a new gl_video context, but it could double GPU memory use, so I didn't. This uses FBOs instead of glGetTexImage(), because that increases the chance it could work on GLES (e.g. ANGLE). Untested. No support for the Vulkan and D3D11 backends yet. Fixes #5498. Also fixes #5240, because the code for reading back is not used with the new code path.
2018-02-07 19:18:36 +00:00
struct ra_fbo fbo, int flags)
vo_opengl: adjust the rules for linearization Two changes, compounded into one since they affect the same logic: 1. Never use linearization for HDR downscaling 2. Always use linearization for interpolation Instead of fixing p->use_linear at the beginning of pass_render_frame, we flip it on "dynamically" as needed. I plan on killing this p->use_linear frame (along with other per-pass metadata) and moving them into their own struct for tracking the "current" state of the video, but that's a separate/upcoming refactor. As a small bonus, reduce some code duplication in the interpolation logic. Fixes #4631
2017-07-24 21:22:30 +00:00
{
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
bool is_new = false;
vo_opengl: fix framestepping/pausing + interpolation This is not the most theoretically perfect solution, ideally we could check to see if the frame in question has already been rendered somewhere in the queue and then avoid re-rendering it, at the cost of a few extra lines of code. But I don't think the performance trade-off is dramatic enough here.
2015-06-30 23:25:30 +00:00
// Reset the queue completely if this is a still image, to avoid any
// interpolation artifacts from surrounding frames when unpausing or
// framestepping
if (t->still)
gl_video_reset_surfaces(p);
Fix misspellings
2016-06-25 18:07:38 +00:00
// First of all, figure out if we have a frame available at all, and draw
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
// it manually + reset the queue if not
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
if (p->surfaces[p->surface_now].id == 0) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct surface *now = &p->surfaces[p->surface_now];
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
if (!update_surface(p, t->current, t->frame_id, now, flags))
vo_opengl: change error state handling and fix hwdec crashes on errors gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
2016-05-19 10:18:48 +00:00
return;
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
p->surface_idx = p->surface_now;
vo_opengl: adjust the rules for linearization Two changes, compounded into one since they affect the same logic: 1. Never use linearization for HDR downscaling 2. Always use linearization for interpolation Instead of fixing p->use_linear at the beginning of pass_render_frame, we flip it on "dynamically" as needed. I plan on killing this p->use_linear frame (along with other per-pass metadata) and moving them into their own struct for tracking the "current" state of the video, but that's a separate/upcoming refactor. As a small bonus, reduce some code duplication in the interpolation logic. Fixes #4631
2017-07-24 21:22:30 +00:00
is_new = true;
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
}
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
// Find the right frame for this instant
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
if (t->current) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
int next = surface_wrap(p->surface_now + 1);
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
while (p->surfaces[next].id &&
p->surfaces[next].id > p->surfaces[p->surface_now].id &&
p->surfaces[p->surface_now].id < t->frame_id)
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
{
p->surface_now = next;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
next = surface_wrap(next + 1);
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
}
}
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
// Figure out the queue size. For illustration, a filter radius of 2 would
// look like this: _ A [B] C D _
vo_opengl: fix interpolation with display-sync At least I hope so. Deriving the duration from the pts was not really correct. It doesn't include speed adjustments, and becomes completely wrong of the user e.g. changes the playback speed by a huge amount. Pass through the accurate duration value by adding a new vo_frame field. The value for vsync_offset was not correct either. We don't need the error for the next frame, but the error for the current one. This wasn't noticed because it makes no difference in symmetric cases, like 24 fps on 60 Hz. I'm still not entirely confident in the correctness of this, but it sure is an improvement. Also, remove the MP_STATS() calls - they're not really useful to debug anything anymore.
2015-11-28 14:45:35 +00:00
// A is surface_bse, B is surface_now, C is surface_now+1 and D is
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
// surface_end.
vo_opengl: add macros for scaler units There was no real point in hard-coding these all over the place, especially since the order was sort of arbitrary and confusing.
2016-03-05 08:42:57 +00:00
struct scaler *tscale = &p->scaler[SCALER_TSCALE];
reinit_scaler(p, tscale, &p->opts.scaler[SCALER_TSCALE], 1, tscale_sizes);
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
bool oversample = strcmp(tscale->conf.kernel.name, "oversample") == 0;
vo_opengl: add a tscale=linear direct implementation This uses GLSL mix() instead of going through an indirect texture access. Easy to implement and might require less resources on some devices, since the oversample code was already essentially just a special case of this. Could be made the new default (as per issue #2685), but that should be done in a separate commit.
2016-07-19 18:12:33 +00:00
bool linear = strcmp(tscale->conf.kernel.name, "linear") == 0;
vo_opengl: add oversample support for tscale This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
2015-03-15 06:11:51 +00:00
int size;
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
vo_opengl: add a tscale=linear direct implementation This uses GLSL mix() instead of going through an indirect texture access. Easy to implement and might require less resources on some devices, since the oversample code was already essentially just a special case of this. Could be made the new default (as per issue #2685), but that should be done in a separate commit.
2016-07-19 18:12:33 +00:00
if (oversample || linear) {
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
size = 2;
} else {
assert(tscale->kernel && !tscale->kernel->polar);
size = ceil(tscale->kernel->size);
}
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
int radius = size/2;
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
int surface_now = p->surface_now;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
int surface_bse = surface_wrap(surface_now - (radius-1));
int surface_end = surface_wrap(surface_now + radius);
assert(surface_wrap(surface_bse + size-1) == surface_end);
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
// Render new frames while there's room in the queue. Note that technically,
// this should be done before the step where we find the right frame, but
// it only barely matters at the very beginning of playback, and this way
// makes the code much more linear.
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
int surface_dst = surface_wrap(p->surface_idx + 1);
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 17:24:28 +00:00
for (int i = 0; i < t->num_frames; i++) {
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
// Avoid overwriting data we might still need
if (surface_dst == surface_bse - 1)
break;
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 17:24:28 +00:00
struct mp_image *f = t->frames[i];
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
uint64_t f_id = t->frame_id + i;
if (!mp_image_params_equal(&f->params, &p->real_image_params))
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
continue;
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
if (f_id > p->surfaces[p->surface_idx].id) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct surface *dst = &p->surfaces[surface_dst];
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
if (!update_surface(p, f, f_id, dst, flags))
vo_opengl: change error state handling and fix hwdec crashes on errors gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
2016-05-19 10:18:48 +00:00
return;
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
p->surface_idx = surface_dst;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
surface_dst = surface_wrap(surface_dst + 1);
vo_opengl: adjust the rules for linearization Two changes, compounded into one since they affect the same logic: 1. Never use linearization for HDR downscaling 2. Always use linearization for interpolation Instead of fixing p->use_linear at the beginning of pass_render_frame, we flip it on "dynamically" as needed. I plan on killing this p->use_linear frame (along with other per-pass metadata) and moving them into their own struct for tracking the "current" state of the video, but that's a separate/upcoming refactor. As a small bonus, reduce some code duplication in the interpolation logic. Fixes #4631
2017-07-24 21:22:30 +00:00
is_new = true;
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
}
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
}
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
// Figure out whether the queue is "valid". A queue is invalid if the
// frames' PTS is not monotonically increasing. Anything else is invalid,
// so avoid blending incorrect data and just draw the latest frame as-is.
// Possible causes for failure of this condition include seeks, pausing,
// end of playback or start of playback.
bool valid = true;
vo_opengl: improve interpolation diagnostics This adds extra debugging output for buffer underruns, to help track down possible queueing issues. It also inverts the numberic output for tscale=oversample to make more sense, without changing the logic.
2015-03-15 22:25:01 +00:00
for (int i = surface_bse, ii; valid && i != surface_end; i = ii) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
ii = surface_wrap(i + 1);
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
if (p->surfaces[i].id == 0 || p->surfaces[ii].id == 0) {
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
valid = false;
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
} else if (p->surfaces[ii].id < p->surfaces[i].id) {
vo_opengl: improve interpolation diagnostics This adds extra debugging output for buffer underruns, to help track down possible queueing issues. It also inverts the numberic output for tscale=oversample to make more sense, without changing the logic.
2015-03-15 22:25:01 +00:00
valid = false;
MP_DBG(p, "interpolation queue underrun\n");
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
}
}
vo_opengl: correct OSD PTS when using interpolation
2015-03-25 21:40:10 +00:00
// Update OSD PTS to synchronize subtitles with the displayed frame
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
p->osd_pts = p->surfaces[surface_now].pts;
vo_opengl: correct OSD PTS when using interpolation
2015-03-25 21:40:10 +00:00
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
// Finally, draw the right mix of frames to the screen.
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
if (!is_new)
pass_info_reset(p, true);
pass_describe(p, "interpolation");
vo_opengl: fix framestepping/pausing + interpolation This is not the most theoretically perfect solution, ideally we could check to see if the frame in question has already been rendered somewhere in the queue and then avoid re-rendering it, at the cost of a few extra lines of code. But I don't think the performance trade-off is dramatic enough here.
2015-06-30 23:25:30 +00:00
if (!valid || t->still) {
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
// surface_now is guaranteed to be valid, so we can safely use it.
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
pass_read_tex(p, p->surfaces[surface_now].tex);
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
p->is_interpolated = false;
} else {
vo_opengl: fix interpolation with display-sync At least I hope so. Deriving the duration from the pts was not really correct. It doesn't include speed adjustments, and becomes completely wrong of the user e.g. changes the playback speed by a huge amount. Pass through the accurate duration value by adding a new vo_frame field. The value for vsync_offset was not correct either. We don't need the error for the next frame, but the error for the current one. This wasn't noticed because it makes no difference in symmetric cases, like 24 fps on 60 Hz. I'm still not entirely confident in the correctness of this, but it sure is an improvement. Also, remove the MP_STATS() calls - they're not really useful to debug anything anymore.
2015-11-28 14:45:35 +00:00
double mix = t->vsync_offset / t->ideal_frame_duration;
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
// The scaler code always wants the fcoord to be between 0 and 1,
// so we try to adjust by using the previous set of N frames instead
// (which requires some extra checking to make sure it's valid)
if (mix < 0.0) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
int prev = surface_wrap(surface_bse - 1);
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
if (p->surfaces[prev].id != 0 &&
p->surfaces[prev].id < p->surfaces[surface_bse].id)
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
{
mix += 1.0;
surface_bse = prev;
} else {
mix = 0.0; // at least don't blow up, this should only
// ever happen at the start of playback
}
vo_opengl: add oversample support for tscale This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
2015-03-15 06:11:51 +00:00
}
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
if (oversample) {
vo_opengl: add a tscale=linear direct implementation This uses GLSL mix() instead of going through an indirect texture access. Easy to implement and might require less resources on some devices, since the oversample code was already essentially just a special case of this. Could be made the new default (as per issue #2685), but that should be done in a separate commit.
2016-07-19 18:12:33 +00:00
// Oversample uses the frame area as mix ratio, not the the vsync
// position itself
vo_opengl: fix interpolation with display-sync At least I hope so. Deriving the duration from the pts was not really correct. It doesn't include speed adjustments, and becomes completely wrong of the user e.g. changes the playback speed by a huge amount. Pass through the accurate duration value by adding a new vo_frame field. The value for vsync_offset was not correct either. We don't need the error for the next frame, but the error for the current one. This wasn't noticed because it makes no difference in symmetric cases, like 24 fps on 60 Hz. I'm still not entirely confident in the correctness of this, but it sure is an improvement. Also, remove the MP_STATS() calls - they're not really useful to debug anything anymore.
2015-11-28 14:45:35 +00:00
double vsync_dist = t->vsync_interval / t->ideal_frame_duration,
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
threshold = tscale->conf.kernel.params[0];
threshold = isnan(threshold) ? 0.0 : threshold;
mix = (1 - mix) / vsync_dist;
mix = mix <= 0 + threshold ? 0 : mix;
mix = mix >= 1 - threshold ? 1 : mix;
mix = 1 - mix;
vo_opengl: add a tscale=linear direct implementation This uses GLSL mix() instead of going through an indirect texture access. Easy to implement and might require less resources on some devices, since the oversample code was already essentially just a special case of this. Could be made the new default (as per issue #2685), but that should be done in a separate commit.
2016-07-19 18:12:33 +00:00
}
// Blend the frames together
if (oversample || linear) {
vo_gpu: attempt to avoid UBOs for dynamic variables This makes the radeon driver shut up about frequently updating STATIC_DRAW UBOs (--opengl-debug), and also reduces the amount of synchronization necessary for vulkan uniform buffers. Also add some extra debugging/tracing code paths. I went with a flags-based approach in case we ever want to extend this.
2017-09-17 08:55:43 +00:00
gl_sc_uniform_dynamic(p->sc);
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
gl_sc_uniform_f(p->sc, "inter_coeff", mix);
vo_opengl: declare vec4 color inside fragment shader stub Why was this done so stupidly, with so many complicated special cases, before? Declare it once so the shader bits don't have to figure out where and when to do so themselves.
2016-02-23 15:18:17 +00:00
GLSL(color = mix(texture(texture0, texcoord0),
texture(texture1, texcoord1),
inter_coeff);)
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
} else {
vo_gpu: attempt to avoid UBOs for dynamic variables This makes the radeon driver shut up about frequently updating STATIC_DRAW UBOs (--opengl-debug), and also reduces the amount of synchronization necessary for vulkan uniform buffers. Also add some extra debugging/tracing code paths. I went with a flags-based approach in case we ever want to extend this.
2017-09-17 08:55:43 +00:00
gl_sc_uniform_dynamic(p->sc);
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
gl_sc_uniform_f(p->sc, "fcoord", mix);
vo_opengl: move self-contained shader routines to a separate file This is mostly to cut down somewhat on the amount of code bloat in video.c by moving out helper functions (including scaler kernels and color management routines) to a separate file. It would certainly be possible to move out more functions (eg. dithering or CMS code) with some extra effort/refactoring, but this is a start. Signed-off-by: wm4 <wm4@nowhere>
2015-09-05 12:03:00 +00:00
pass_sample_separated_gen(p->sc, tscale, 0, 0);
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
}
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
// Load all the required frames
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
for (int i = 0; i < size; i++) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct image img =
image_wrap(p->surfaces[surface_wrap(surface_bse+i)].tex,
PLANE_RGB, p->components);
vo_opengl: refactor pass_read_video and texture binding This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
2016-03-05 10:29:19 +00:00
// Since the code in pass_sample_separated currently assumes
// the textures are bound in-order and starting at 0, we just
// assert to make sure this is the case (which it should always be)
int id = pass_bind(p, img);
assert(id == i);
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
}
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
msg: reinterpret a bunch of message levels I've decided that MP_TRACE means “noisy spam per frame”, whereas MP_DBG just means “more verbose debugging messages than MSGL_V”. Basically, MSGL_DBG shouldn't create spam per frame like it currently does, and MSGL_V should make sense to the end-user and provide mostly additional informational output. MP_DBG is basically what I want to make the new default for --log-file, so the cut-off point for MP_DBG is if we probably want to know if for debugging purposes but the user most likely doesn't care about on the terminal. Also, the debug callbacks for libass and ffmpeg got bumped in their verbosity levels slightly, because being external components they're a bit less relevant to mpv debugging, and a bit too over-eager in what they consider to be relevant information. I exclusively used the "try it on my machine and remove messages from MSGL_* until it does what I want it to" approach of refactoring, so YMMV.
2017-09-28 09:53:57 +00:00
MP_TRACE(p, "inter frame dur: %f vsync: %f, mix: %f\n",
t->ideal_frame_duration, t->vsync_interval, mix);
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
p->is_interpolated = true;
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
}
pass_draw_to_screen(p, fbo);
vo_opengl: fix "freezes" after seeking with interpolation on When seeking to a different position, and seeking takes long, the OSD might get redrawn. This means that the VO will receive a request to redraw an old frame using whatever the previous PTS was. This breaks the interpolation logic: the old frame will be added to the queue, and then the next frames (with lower PTS if you seeked backwards) are not drawn as the logic assumes they're past frames. Fix this by using the non-interpolation code path when redrawing after a seek reset, and no "real" frame has been drawn yet. It's a recent regression caused by the redrawing code simplification. The old code simply sent a VOCTRL for redrawing the frame, and the VO had to deal with retaining the old frame on its own. This is a hack as in there's probably a better solution. Fixes #2097.
2015-07-02 11:17:20 +00:00
p->frames_drawn += 1;
vo_opengl: add smoothmotion frame blending SmoothMotion is a way to time and blend frames made popular by MadVR. It's intended behaviour is to remove stuttering caused by mismatches between the display refresh rate and the video fps, while preserving the video's original artistic qualities (no soap opera effect). It's supposed to make 24fps video playback on 60hz monitors as close as possible to a 24hz monitor. Instead of drawing a frame once once it's pts has passed the vsync time, we redraw at the display refresh rate, and if we detect the vsync is between two frames we interpolated them (depending on their position relative to the vsync). We actually interpolate as few frames as possible to avoid a blur effect as much as possible. For example, if we were to play back a 1fps video on a 60hz monitor, we would blend at most on 1 vsync for each frame (while the other 59 vsyncs would be rendered as is). Frame interpolation is always done before scaling and in linear light when possible (an ICC profile is used, or :srgb is used).
2014-11-23 19:06:05 +00:00
}
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
void gl_video_render_frame(struct gl_video *p, struct vo_frame *frame,
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
struct ra_fbo fbo, int flags)
vo_opengl: move OSD rendering to separate function Also reindent the few lines that call into the actual renderer to remove the "draw_osd" goto.
2015-03-23 15:28:33 +00:00
{
vo_gpu: fix video sometimes not being rerendered on equalizer change With video paused, changing the brightness controls (or similar) would sometimes not rerender the video frame. So the OSD would redraw, but the video wouldn't change. This is caused by output caching, and a redraw request is free to return the cached frame. Change it such to invalidate the cached frame if any of the options or the equalizer change. In theory, gl_video_reset_surfaces() could be called if the equalizer changes - this would apparently force interpolatzion to redraw all frames. But this looks kind of crappy when changing the equalizer during playback. It'll "eventually" use the correct settings anyway, and when paused interpolation is off.
2017-10-17 07:07:35 +00:00
gl_video_update_options(p);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct mp_rect target_rc = {0, 0, fbo.tex->params.w, fbo.tex->params.h};
vo_opengl: change error state handling and fix hwdec crashes on errors gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
2016-05-19 10:18:48 +00:00
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
p->broken_frame = false;
vo_opengl: move OSD rendering to separate function Also reindent the few lines that call into the actual renderer to remove the "draw_osd" goto.
2015-03-23 15:28:33 +00:00
vo_opengl: simplify a condition The " || vimg->mpi" part virtually never seems to trigger, but on the other hand could possibly create unintended corner cases (for example by trying to upload a NULL image, which would then be marked as an error and render a blue screen). I guess it's a leftover from over times, where a NULL image meant "redraw the current frame". This is now handled by actually passing along the current frame.
2016-09-08 13:54:08 +00:00
bool has_frame = !!frame->current;
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 17:24:28 +00:00
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
if (!has_frame || !mp_rect_equals(&p->dst_rect, &target_rc)) {
rpi: fix build Runtime untested, because I get this: [vo/rpi] Could not get DISPMANX objects. This happened even when building older git versions, and on a RPI image that hasn't changed in the recent years. I don't know how to make this POS work again, so I guess if there's a bug in the new code, it will remain broken.
2017-08-11 11:02:13 +00:00
struct m_color c = p->clear_color;
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
float color[4] = {c.r / 255.0, c.g / 255.0, c.b / 255.0, c.a / 255.0};
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
p->ra->fns->clear(p->ra, fbo.tex, color, &target_rc);
vo_opengl: move OSD rendering to separate function Also reindent the few lines that call into the actual renderer to remove the "draw_osd" goto.
2015-03-23 15:28:33 +00:00
}
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
if (p->hwdec_overlay) {
vo_opengl: add hw overlay support and use it for RPI This overlay support specifically skips the OpenGL rendering chain, and uses GL rendering only for OSD/subtitles. This is for devices which don't have performant GL support. hwdec_rpi.c contains code ported from vo_rpi.c. vo_rpi.c is going to be deprecated. I left in the code for uploading sw surfaces (as it might be slightly more efficient for rendering sw decoded video), although it's dead code for now.
2016-09-12 13:08:38 +00:00
if (has_frame) {
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
float *color = p->hwdec_overlay->overlay_colorkey;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
p->ra->fns->clear(p->ra, fbo.tex, color, &p->dst_rect);
vo_opengl: add hw overlay support and use it for RPI This overlay support specifically skips the OpenGL rendering chain, and uses GL rendering only for OSD/subtitles. This is for devices which don't have performant GL support. hwdec_rpi.c contains code ported from vo_rpi.c. vo_rpi.c is going to be deprecated. I left in the code for uploading sw surfaces (as it might be slightly more efficient for rendering sw decoded video), although it's dead code for now.
2016-09-12 13:08:38 +00:00
}
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
p->hwdec_overlay->driver->overlay_frame(p->hwdec_overlay, frame->current,
&p->src_rect, &p->dst_rect,
frame->frame_id != p->image.id);
vo_opengl: add hw overlay support and use it for RPI This overlay support specifically skips the OpenGL rendering chain, and uses GL rendering only for OSD/subtitles. This is for devices which don't have performant GL support. hwdec_rpi.c contains code ported from vo_rpi.c. vo_rpi.c is going to be deprecated. I left in the code for uploading sw surfaces (as it might be slightly more efficient for rendering sw decoded video), although it's dead code for now.
2016-09-12 13:08:38 +00:00
if (frame->current)
p->osd_pts = frame->current->pts;
// Disable GL rendering
has_frame = false;
}
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 17:24:28 +00:00
if (has_frame) {
vo_opengl: replace tscale-interpolates-only with interpolation-threshold The previous approach was too naive, and can e.g. ruin playback if scheduling switches e.g. between 1 and 2 vsync per frame.
2016-01-27 20:07:17 +00:00
bool interpolate = p->opts.interpolation && frame->display_synced &&
(p->frames_drawn || !frame->still);
if (interpolate) {
double ratio = frame->ideal_frame_duration / frame->vsync_interval;
if (fabs(ratio - 1.0) < p->opts.interpolation_threshold)
interpolate = false;
}
vo_opengl: add tscale-interpolates-only sub-option
2016-01-25 20:46:01 +00:00
vo_opengl: replace tscale-interpolates-only with interpolation-threshold The previous approach was too naive, and can e.g. ruin playback if scheduling switches e.g. between 1 and 2 vsync per frame.
2016-01-27 20:07:17 +00:00
if (interpolate) {
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
gl_video_interpolate_frame(p, frame, fbo, flags);
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 17:24:28 +00:00
} else {
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
bool is_new = frame->frame_id != p->image.id;
// Redrawing a frame might update subtitles.
vo_opengl: fix --blend-subtitles handling The intention was that if --blend-subtitles is enabled, the frame should always be re-rendered instead of using e.g. a cached scaled frame. The reason is that subtitles can change anyway, e.g. if you pause and change subtitle size and such. On the other hand, if the frame is marked as repeated, it should always use the cached copy. Actually "simplify" this and drop the cache only if playback is paused (which frame->still indicates indirectly). Also see PR #3773.
2016-11-07 21:49:24 +00:00
if (frame->still && p->opts.blend_subs)
is_new = true;
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
if (is_new || !p->output_tex_valid) {
p->output_tex_valid = false;
vo_opengl: use glBlitFramebuffer to draw repeated frames In the display-sync, non-interpolation case, and if the display refresh rate is higher than the video framerate, we duplicate display frames by rendering exactly the same screen again. The redrawing is cached with a FBO to speed up the repeat. Use glBlitFramebuffer() instead of another shader pass. It should be faster. For some reason, post-process was run again on each display refresh. Stop doing this, which should also be slightly faster. The only disadvantage is that temporal dithering will be run only once per video frame, but I can live with this. One aspect is messy: clearing the background is done at the start on the target framebuffer, so to avoid clearing twice and duplicating the code, only copy the part of the framebuffer that contains the rendered video. (Which also gets slightly messy - needs to compensate for coordinate system flipping.)
2015-11-15 17:30:54 +00:00
vo_opengl: only mark frames as fresh if they contain a new image When using dumb mode, we can actually redraw a frame without uploading it. Marking this as fresh as well results in unpredictable pass behavior, which is confusing and makes debugging harder. So mark it as a redraw instead, in that case.
2017-08-06 00:51:11 +00:00
pass_info_reset(p, !is_new);
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
if (!pass_render_frame(p, frame->current, frame->frame_id, flags))
vo_opengl: change error state handling and fix hwdec crashes on errors gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
2016-05-19 10:18:48 +00:00
goto done;
vo_opengl: always cache to an FBO when not interpolating This speeds up redraws considerably (improving eg. <60 Hz material on a 60 Hz monitor with display-sync active, or redraws while paused), but slightly slows down the worst case (eg. video FPS = display FPS).
2015-09-05 10:02:02 +00:00
vo_opengl: minor typo and coding style fixes
2016-06-28 17:41:40 +00:00
// For the non-interpolation case, we draw to a single "cache"
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
// texture to speed up subsequent re-draws (if any exist)
struct ra_fbo dest_fbo = fbo;
vo_opengl: use glBlitFramebuffer to draw repeated frames In the display-sync, non-interpolation case, and if the display refresh rate is higher than the video framerate, we duplicate display frames by rendering exactly the same screen again. The redrawing is cached with a FBO to speed up the repeat. Use glBlitFramebuffer() instead of another shader pass. It should be faster. For some reason, post-process was run again on each display refresh. Stop doing this, which should also be slightly faster. The only disadvantage is that temporal dithering will be run only once per video frame, but I can live with this. One aspect is messy: clearing the background is done at the start on the target framebuffer, so to avoid clearing twice and duplicating the code, only copy the part of the framebuffer that contains the rendered video. (Which also gets slightly messy - needs to compensate for coordinate system flipping.)
2015-11-15 17:30:54 +00:00
if (frame->num_vsyncs > 1 && frame->display_synced &&
vo_gpu: use blit() only if target ra_tex supports it Even if RA_CAP_BLIT is set, this might just not be enabled for the target ra_tex.
2018-02-08 00:38:24 +00:00
!p->dumb_mode && (p->ra->caps & RA_CAP_BLIT) &&
fbo.tex->params.blit_dst)
vo_opengl: cache frames only in display-sync mode vo_frame.num_vsyncs can be != 1 in some cases in normal sync mode too. This is not a very exact fix, but in exchange it's robust. (These vo_frame flags are way too tricky in combination with redrawing and such.)
2015-10-30 11:53:43 +00:00
{
vo_gpu: attempt re-using the FBO format for p->output_tex This allows RAs with support for non-opaque FBO formats to use a more appropriate FBO format for the output tex, possibly enabling a more efficient blit operation. This requires distinguishing between real formats (which can be used to create textures) and fake formats (e.g. ra_gl's FBO hack).
2017-09-29 12:41:52 +00:00
// Attempt to use the same format as the destination FBO
// if possible. Some RAs use a wrapped dummy format here,
// so fall back to the fbo_format in that case.
const struct ra_format *fmt = fbo.tex->params.format;
if (fmt->dummy_format)
fmt = p->fbo_format;
vo_gpu: handle texture initialization errors gracefully Tested by making the ra_tex_resize function always fail (apart from the initial FBO check). This required a few changes: 1. reset shaders on failed dispatch 2. reset cleanup binds on failed dispatch 3. fall back to initializing the struct image to 1x1 on failure 4. handle output_fbo_valid gracefully
2017-09-23 07:54:42 +00:00
bool r = ra_tex_resize(p->ra, p->log, &p->output_tex,
fbo.tex->params.w, fbo.tex->params.h,
vo_gpu: attempt re-using the FBO format for p->output_tex This allows RAs with support for non-opaque FBO formats to use a more appropriate FBO format for the output tex, possibly enabling a more efficient blit operation. This requires distinguishing between real formats (which can be used to create textures) and fake formats (e.g. ra_gl's FBO hack).
2017-09-29 12:41:52 +00:00
fmt);
vo_gpu: handle texture initialization errors gracefully Tested by making the ra_tex_resize function always fail (apart from the initial FBO check). This required a few changes: 1. reset shaders on failed dispatch 2. reset cleanup binds on failed dispatch 3. fall back to initializing the struct image to 1x1 on failure 4. handle output_fbo_valid gracefully
2017-09-23 07:54:42 +00:00
if (r) {
dest_fbo = (struct ra_fbo) { p->output_tex };
p->output_tex_valid = true;
}
vo_opengl: always cache to an FBO when not interpolating This speeds up redraws considerably (improving eg. <60 Hz material on a 60 Hz monitor with display-sync active, or redraws while paused), but slightly slows down the worst case (eg. video FPS = display FPS).
2015-09-05 10:02:02 +00:00
}
vo_opengl: use glBlitFramebuffer to draw repeated frames In the display-sync, non-interpolation case, and if the display refresh rate is higher than the video framerate, we duplicate display frames by rendering exactly the same screen again. The redrawing is cached with a FBO to speed up the repeat. Use glBlitFramebuffer() instead of another shader pass. It should be faster. For some reason, post-process was run again on each display refresh. Stop doing this, which should also be slightly faster. The only disadvantage is that temporal dithering will be run only once per video frame, but I can live with this. One aspect is messy: clearing the background is done at the start on the target framebuffer, so to avoid clearing twice and duplicating the code, only copy the part of the framebuffer that contains the rendered video. (Which also gets slightly messy - needs to compensate for coordinate system flipping.)
2015-11-15 17:30:54 +00:00
pass_draw_to_screen(p, dest_fbo);
vo_opengl: always cache to an FBO when not interpolating This speeds up redraws considerably (improving eg. <60 Hz material on a 60 Hz monitor with display-sync active, or redraws while paused), but slightly slows down the worst case (eg. video FPS = display FPS).
2015-09-05 10:02:02 +00:00
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
// "output tex valid" and "output tex needed" are equivalent
vo_gpu: use blit() only if target ra_tex supports it Even if RA_CAP_BLIT is set, this might just not be enabled for the target ra_tex.
2018-02-08 00:38:24 +00:00
if (p->output_tex_valid && fbo.tex->params.blit_dst) {
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
pass_info_reset(p, true);
pass_describe(p, "redraw cached frame");
vo_opengl: simplify mirroring and fix it if glBlitFramebuffer is used The vp_w/vp_h variables and parameters were not really used anymore (they were redundant with ra_tex w/h) - but vp_h was still used to identify whether rendering should be done mirrored. Simplify this by adding a fbodst struct (some bad naming), which contains the render target texture, and some parameters how it should be rendered to (for now only flipping). It would not be appropriate to make this a member of ra_tex, so it's a separate struct. Introduces a weird regression for the first frame rendered after interpolation is toggled at runtime, but seems to work otherwise. This is possibly due to the change that blit() now mirrors, instead of just copying. (This is also why ra_fns.blit is changed.) Fixes #4719.
2017-08-07 14:44:15 +00:00
struct mp_rect src = p->dst_rect;
struct mp_rect dst = src;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
if (fbo.flip) {
dst.y0 = fbo.tex->params.h - src.y0;
dst.y1 = fbo.tex->params.h - src.y1;
vo_opengl: use glBlitFramebuffer to draw repeated frames In the display-sync, non-interpolation case, and if the display refresh rate is higher than the video framerate, we duplicate display frames by rendering exactly the same screen again. The redrawing is cached with a FBO to speed up the repeat. Use glBlitFramebuffer() instead of another shader pass. It should be faster. For some reason, post-process was run again on each display refresh. Stop doing this, which should also be slightly faster. The only disadvantage is that temporal dithering will be run only once per video frame, but I can live with this. One aspect is messy: clearing the background is done at the start on the target framebuffer, so to avoid clearing twice and duplicating the code, only copy the part of the framebuffer that contains the rendered video. (Which also gets slightly messy - needs to compensate for coordinate system flipping.)
2015-11-15 17:30:54 +00:00
}
vo_opengl: move timers to struct ra In order to prevent code duplication and keep the ra abstraction as small as possible, `ra` only implements the actual timer queries, it does not do pooling/averaging of the results. This is instead moved to a ra-neutral struct timer_pool in utils.c.
2017-08-05 16:20:45 +00:00
timer_pool_start(p->blit_timer);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
p->ra->fns->blit(p->ra, fbo.tex, p->output_tex, &dst, &src);
vo_opengl: move timers to struct ra In order to prevent code duplication and keep the ra abstraction as small as possible, `ra` only implements the actual timer queries, it does not do pooling/averaging of the results. This is instead moved to a ra-neutral struct timer_pool in utils.c.
2017-08-05 16:20:45 +00:00
timer_pool_stop(p->blit_timer);
pass_record(p, timer_pool_measure(p->blit_timer));
vo_opengl: always cache to an FBO when not interpolating This speeds up redraws considerably (improving eg. <60 Hz material on a 60 Hz monitor with display-sync active, or redraws while paused), but slightly slows down the worst case (eg. video FPS = display FPS).
2015-09-05 10:02:02 +00:00
}
vo: change internal API for drawing frames draw_image_timed is renamed to draw_frame. struct frame_timing is renamed to vo_frame. flip_page_timed is merged into draw_frame (the additional parameters are part of struct vo_frame). draw_frame also deprecates VOCTRL_REDRAW_FRAME, and replaces it with a method that works for both VOs which can cache the current frame, and VOs which need to redraw it anyway. This is preparation to making the interpolation and (work in progress) display sync code saner. Lots of other refactoring, and also some simplifications.
2015-07-01 17:24:28 +00:00
}
vo_opengl: move OSD rendering to separate function Also reindent the few lines that call into the actual renderer to remove the "draw_osd" goto.
2015-03-23 15:28:33 +00:00
}
vo_opengl: change error state handling and fix hwdec crashes on errors gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
2016-05-19 10:18:48 +00:00
done:
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
debug_check_gl(p, "after video rendering");
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
if (p->osd && (flags & (RENDER_FRAME_SUBS | RENDER_FRAME_OSD))) {
vo_opengl: fix some more pass_info_reset issues 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.
2017-07-01 02:27:09 +00:00
// If we haven't actually drawn anything so far, then we technically
// need to consider this the start of a new pass. Let's call it a
// redraw just because, since it's basically a blank frame anyway
if (!has_frame)
pass_info_reset(p, true);
vo_gpu: add internal ability to skip osd/subs for rendering Needed for the following commit.
2018-02-08 00:55:31 +00:00
int osd_flags = p->opts.blend_subs ? OSD_DRAW_OSD_ONLY : 0;
if (!(flags & RENDER_FRAME_SUBS))
osd_flags |= OSD_DRAW_OSD_ONLY;
if (!(flags & RENDER_FRAME_OSD))
osd_flags |= OSD_DRAW_SUB_ONLY;
pass_draw_osd(p, osd_flags, p->osd_pts, p->osd_rect, fbo, true);
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
debug_check_gl(p, "after OSD rendering");
}
vo_opengl: change error state handling and fix hwdec crashes on errors gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
2016-05-19 10:18:48 +00:00
vo_gpu: error out if there were rendering errors when taking screenshot
2018-03-02 11:15:03 +00:00
p->broken_frame |= gl_sc_error_state(p->sc);
if (p->broken_frame) {
vo_opengl: change error state handling and fix hwdec crashes on errors gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
2016-05-19 10:18:48 +00:00
// Make the screen solid blue to make it visually clear that an
// error has occurred
vo_opengl: pass ra objects during rendering instead of GL objects Another "small" step towards removing GL dependencies from the renderer. This commit generally passes ra_tex objects instead of GL FBO integer IDs to various rendering functions. video.c still manually binds the FBOs when calling shaders. This also happens to fix a memory leak with output_fbo.
2017-08-04 13:47:50 +00:00
float color[4] = {0.0, 0.05, 0.5, 1.0};
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
p->ra->fns->clear(p->ra, fbo.tex, color, &target_rc);
vo_opengl: change error state handling and fix hwdec crashes on errors gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
2016-05-19 10:18:48 +00:00
}
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
p->frames_rendered++;
vo_opengl: make the pass info mechanism more robust - 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.
2017-07-03 14:59:38 +00:00
pass_report_performance(p);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
vo_gpu: make screenshots use the GL renderer Using the GL renderer for color conversion will make sure screenshots will use the same conversion as normal video rendering. It can do this for all types of screenshots. The logic when to write 16 bit PNGs changes. To approximate the old behavior, we decide by looking whether the source video format has more than 8 bits per component. We apply this logic even for window screenshots. Also, 16 bit PNGs now always include an unused alpha channel. The reason is that FFmpeg has RGB48 and RGBA64 formats, but no RGB064. RGB48 is 3 bytes and usually not supported by GPUs for rendering, so we have to use RGBA64, which forces an alpha channel. Will break for users who use --target-trc and similar options. I considered creating a new gl_video context, but it could double GPU memory use, so I didn't. This uses FBOs instead of glGetTexImage(), because that increases the chance it could work on GLES (e.g. ANGLE). Untested. No support for the Vulkan and D3D11 backends yet. Fixes #5498. Also fixes #5240, because the code for reading back is not used with the new code path.
2018-02-07 19:18:36 +00:00
void gl_video_screenshot(struct gl_video *p, struct vo_frame *frame,
struct voctrl_screenshot *args)
{
bool ok = false;
struct mp_image *res = NULL;
if (!p->ra->fns->tex_download)
return;
struct mp_rect old_src = p->src_rect;
struct mp_rect old_dst = p->dst_rect;
struct mp_osd_res old_osd = p->osd_rect;
if (!args->scaled) {
int w = p->real_image_params.w;
int h = p->real_image_params.h;
if (w < 1 || h < 1)
return;
vo_gpu: fix taking screenshots of rotated videos Good old 90° rotation logic messing everything up.
2018-03-02 11:13:21 +00:00
if (p->image_params.rotate % 180 == 90)
MPSWAP(int, w, h);
vo_gpu: make screenshots use the GL renderer Using the GL renderer for color conversion will make sure screenshots will use the same conversion as normal video rendering. It can do this for all types of screenshots. The logic when to write 16 bit PNGs changes. To approximate the old behavior, we decide by looking whether the source video format has more than 8 bits per component. We apply this logic even for window screenshots. Also, 16 bit PNGs now always include an unused alpha channel. The reason is that FFmpeg has RGB48 and RGBA64 formats, but no RGB064. RGB48 is 3 bytes and usually not supported by GPUs for rendering, so we have to use RGBA64, which forces an alpha channel. Will break for users who use --target-trc and similar options. I considered creating a new gl_video context, but it could double GPU memory use, so I didn't. This uses FBOs instead of glGetTexImage(), because that increases the chance it could work on GLES (e.g. ANGLE). Untested. No support for the Vulkan and D3D11 backends yet. Fixes #5498. Also fixes #5240, because the code for reading back is not used with the new code path.
2018-02-07 19:18:36 +00:00
struct mp_rect rc = {0, 0, w, h};
struct mp_osd_res osd = {.w = w, .h = h, .display_par = 1.0};
gl_video_resize(p, &rc, &rc, &osd);
}
gl_video_reset_surfaces(p);
struct ra_tex_params params = {
.dimensions = 2,
.downloadable = true,
.w = p->osd_rect.w,
.h = p->osd_rect.h,
.render_dst = true,
};
params.format = ra_find_unorm_format(p->ra, 1, 4);
int mpfmt = IMGFMT_RGB0;
if (args->high_bit_depth && p->ra_format.component_bits > 8) {
const struct ra_format *fmt = ra_find_unorm_format(p->ra, 2, 4);
if (fmt && fmt->renderable) {
params.format = fmt;
mpfmt = IMGFMT_RGBA64;
}
}
if (!params.format || !params.format->renderable)
goto done;
struct ra_tex *target = ra_tex_create(p->ra, &params);
if (!target)
goto done;
int flags = 0;
if (args->subs)
flags |= RENDER_FRAME_SUBS;
if (args->osd)
flags |= RENDER_FRAME_OSD;
gl_video_render_frame(p, frame, (struct ra_fbo){target}, flags);
res = mp_image_alloc(mpfmt, params.w, params.h);
if (!res)
goto done;
struct ra_tex_download_params download_params = {
.tex = target,
.dst = res->planes[0],
.stride = res->stride[0],
};
if (!p->ra->fns->tex_download(p->ra, &download_params))
goto done;
vo_gpu: error out if there were rendering errors when taking screenshot
2018-03-02 11:15:03 +00:00
if (p->broken_frame)
goto done;
vo_gpu: make screenshots use the GL renderer Using the GL renderer for color conversion will make sure screenshots will use the same conversion as normal video rendering. It can do this for all types of screenshots. The logic when to write 16 bit PNGs changes. To approximate the old behavior, we decide by looking whether the source video format has more than 8 bits per component. We apply this logic even for window screenshots. Also, 16 bit PNGs now always include an unused alpha channel. The reason is that FFmpeg has RGB48 and RGBA64 formats, but no RGB064. RGB48 is 3 bytes and usually not supported by GPUs for rendering, so we have to use RGBA64, which forces an alpha channel. Will break for users who use --target-trc and similar options. I considered creating a new gl_video context, but it could double GPU memory use, so I didn't. This uses FBOs instead of glGetTexImage(), because that increases the chance it could work on GLES (e.g. ANGLE). Untested. No support for the Vulkan and D3D11 backends yet. Fixes #5498. Also fixes #5240, because the code for reading back is not used with the new code path.
2018-02-07 19:18:36 +00:00
ok = true;
done:
ra_tex_free(p->ra, &target);
gl_video_resize(p, &old_src, &old_dst, &old_osd);
if (!ok)
TA_FREEP(&res);
args->res = res;
}
rpi: fix build Runtime untested, because I get this: [vo/rpi] Could not get DISPMANX objects. This happened even when building older git versions, and on a RPI image that hasn't changed in the recent years. I don't know how to make this POS work again, so I guess if there's a bug in the new code, it will remain broken.
2017-08-11 11:02:13 +00:00
// Use this color instead of the global option.
void gl_video_set_clear_color(struct gl_video *p, struct m_color c)
{
p->force_clear_color = true;
p->clear_color = c;
}
vo_rpi: fix operation Commit 697c4389a9e6 worked "almost". I couldn't test it at the time.
2017-08-15 17:12:39 +00:00
void gl_video_set_osd_pts(struct gl_video *p, double pts)
{
p->osd_pts = pts;
}
rpi: fix build Runtime untested, because I get this: [vo/rpi] Could not get DISPMANX objects. This happened even when building older git versions, and on a RPI image that hasn't changed in the recent years. I don't know how to make this POS work again, so I guess if there's a bug in the new code, it will remain broken.
2017-08-11 11:02:13 +00:00
bool gl_video_check_osd_change(struct gl_video *p, struct mp_osd_res *res,
double pts)
{
return p->osd ? mpgl_osd_check_change(p->osd, res, pts) : false;
}
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
void gl_video_resize(struct gl_video *p,
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
struct mp_rect *src, struct mp_rect *dst,
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
struct mp_osd_res *osd)
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
{
vo_opengl: don't discard buffered video on redundant resize calls If a VO-area option changes, gl_video_resize() is called unconditionally. This function does something even if the size does not change (at least it discards buffered frames for interpolation), which can lead to stutter when you keep firing option change events during playback. Check for an actual resize, and if nothing changes, exit early.
2017-08-29 13:15:34 +00:00
if (mp_rect_equals(&p->src_rect, src) &&
mp_rect_equals(&p->dst_rect, dst) &&
osd_res_equals(p->osd_rect, *osd))
return;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
p->src_rect = *src;
p->dst_rect = *dst;
p->osd_rect = *osd;
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
gl_video_reset_surfaces(p);
vo_opengl, osd: allow osc.lua to react faster on resizes Glitches when resizing are still possible, but are reduced. Other VOs could support this too, but don't need to do so. (Totally avoiding glitches would be much more effort, and probably not worth the trouble. How about you just watch the video the player is playing, instead of spending your time resizing the window.)
2016-03-21 21:23:41 +00:00
vo_opengl_cb: fix NULL deref Broken in commit d6c99c85. vo_opengl_cb.c adds the corner case that p->osd can be NULL. This make opengl-cb always crash.
2016-03-23 13:49:39 +00:00
if (p->osd)
mpgl_osd_resize(p->osd, p->osd_rect, p->image_params.stereo_out);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
static void frame_perf_data(struct pass_info pass[], struct mp_frame_perf *out)
vo_opengl: expose performance timers as properties This is plumbed through a new VOCTRL, VOCTRL_PERFORMANCE_DATA, and exposed as properties render-time-last, render-time-avg etc. All of these numbers are in microseconds, which gives a good precision range when just outputting them via show-text. (Lua scripts can obviously still do their own formatting etc.) Signed-off-by: wm4 <wm4@nowhere>
2016-06-06 00:44:15 +00:00
{
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
for (int i = 0; i < VO_PASS_PERF_MAX; i++) {
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
if (!pass[i].desc.len)
break;
out->perf[out->count] = pass[i].perf;
out->desc[out->count] = pass[i].desc.start;
out->count++;
}
vo_opengl: expose performance timers as properties This is plumbed through a new VOCTRL, VOCTRL_PERFORMANCE_DATA, and exposed as properties render-time-last, render-time-avg etc. All of these numbers are in microseconds, which gives a good precision range when just outputting them via show-text. (Lua scripts can obviously still do their own formatting etc.) Signed-off-by: wm4 <wm4@nowhere>
2016-06-06 00:44:15 +00:00
}
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
void gl_video_perfdata(struct gl_video *p, struct voctrl_performance_data *out)
vo_opengl: expose performance timers as properties This is plumbed through a new VOCTRL, VOCTRL_PERFORMANCE_DATA, and exposed as properties render-time-last, render-time-avg etc. All of these numbers are in microseconds, which gives a good precision range when just outputting them via show-text. (Lua scripts can obviously still do their own formatting etc.) Signed-off-by: wm4 <wm4@nowhere>
2016-06-06 00:44:15 +00:00
{
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
*out = (struct voctrl_performance_data){0};
frame_perf_data(p->pass_fresh, &out->fresh);
frame_perf_data(p->pass_redraw, &out->redraw);
vo_opengl: expose performance timers as properties This is plumbed through a new VOCTRL, VOCTRL_PERFORMANCE_DATA, and exposed as properties render-time-last, render-time-avg etc. All of these numbers are in microseconds, which gives a good precision range when just outputting them via show-text. (Lua scripts can obviously still do their own formatting etc.) Signed-off-by: wm4 <wm4@nowhere>
2016-06-06 00:44:15 +00:00
}
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
// This assumes nv12, with textures set to GL_NEAREST filtering.
vo_opengl: separate hwdec context and mapping, port it to use ra This does two separate rather intrusive things: 1. Make the hwdec context (which does initialization, provides the device to the decoder, and other basic state) and frame mapping (getting textures from a mp_image) separate. This is more flexible, and you could map multiple images at once. It will help removing some hwdec special-casing from video.c. 2. Switch all hwdec API use to ra. Of course all code is still GL specific, but in theory it would be possible to support other backends. The most important change is that the hwdec interop returns ra objects, instead of anything GL specific. This removes the last dependency on GL-specific header files from video.c. I'm mixing these separate changes because both requires essentially rewriting all the glue code, so better do them at once. For the same reason, this change isn't done incrementally. hwdec_ios.m is untested, since I can't test it. Apart from superficial mistakes, this also requires dealing with Apple's texture format fuckups: they force you to use GL_LUMINANCE[_ALPHA] instead of GL_RED and GL_RG. We also need to report the correct format via ra_tex to the renderer, which is done by find_la_variant(). It's unknown whether this works correctly. hwdec_rpi.c as well as vo_rpi.c are still broken. (I need to pull my RPI out of a dusty pile of devices and cables, so, later.)
2017-08-10 15:48:33 +00:00
static void reinterleave_vdpau(struct gl_video *p,
struct ra_tex *input[4], struct ra_tex *output[2])
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
{
for (int n = 0; n < 2; n++) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct ra_tex **tex = &p->vdpau_deinterleave_tex[n];
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
// This is an array of the 2 to-merge planes.
vo_opengl: separate hwdec context and mapping, port it to use ra This does two separate rather intrusive things: 1. Make the hwdec context (which does initialization, provides the device to the decoder, and other basic state) and frame mapping (getting textures from a mp_image) separate. This is more flexible, and you could map multiple images at once. It will help removing some hwdec special-casing from video.c. 2. Switch all hwdec API use to ra. Of course all code is still GL specific, but in theory it would be possible to support other backends. The most important change is that the hwdec interop returns ra objects, instead of anything GL specific. This removes the last dependency on GL-specific header files from video.c. I'm mixing these separate changes because both requires essentially rewriting all the glue code, so better do them at once. For the same reason, this change isn't done incrementally. hwdec_ios.m is untested, since I can't test it. Apart from superficial mistakes, this also requires dealing with Apple's texture format fuckups: they force you to use GL_LUMINANCE[_ALPHA] instead of GL_RED and GL_RG. We also need to report the correct format via ra_tex to the renderer, which is done by find_la_variant(). It's unknown whether this works correctly. hwdec_rpi.c as well as vo_rpi.c are still broken. (I need to pull my RPI out of a dusty pile of devices and cables, so, later.)
2017-08-10 15:48:33 +00:00
struct ra_tex **src = &input[n * 2];
int w = src[0]->params.w;
int h = src[0]->params.h;
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
int ids[2];
for (int t = 0; t < 2; t++) {
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
ids[t] = pass_bind(p, (struct image){
vo_opengl: separate hwdec context and mapping, port it to use ra This does two separate rather intrusive things: 1. Make the hwdec context (which does initialization, provides the device to the decoder, and other basic state) and frame mapping (getting textures from a mp_image) separate. This is more flexible, and you could map multiple images at once. It will help removing some hwdec special-casing from video.c. 2. Switch all hwdec API use to ra. Of course all code is still GL specific, but in theory it would be possible to support other backends. The most important change is that the hwdec interop returns ra objects, instead of anything GL specific. This removes the last dependency on GL-specific header files from video.c. I'm mixing these separate changes because both requires essentially rewriting all the glue code, so better do them at once. For the same reason, this change isn't done incrementally. hwdec_ios.m is untested, since I can't test it. Apart from superficial mistakes, this also requires dealing with Apple's texture format fuckups: they force you to use GL_LUMINANCE[_ALPHA] instead of GL_RED and GL_RG. We also need to report the correct format via ra_tex to the renderer, which is done by find_la_variant(). It's unknown whether this works correctly. hwdec_rpi.c as well as vo_rpi.c are still broken. (I need to pull my RPI out of a dusty pile of devices and cables, so, later.)
2017-08-10 15:48:33 +00:00
.tex = src[t],
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
.multiplier = 1.0,
.transform = identity_trans,
.w = w,
.h = h,
});
}
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
pass_describe(p, "vdpau reinterleaving");
vo_opengl: avoid constant divisions 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
2017-07-17 03:23:55 +00:00
GLSLF("color = fract(gl_FragCoord.y * 0.5) < 0.5\n");
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
GLSLF(" ? texture(texture%d, texcoord%d)\n", ids[0], ids[0]);
GLSLF(" : texture(texture%d, texcoord%d);", ids[1], ids[1]);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
int comps = n == 0 ? 1 : 2;
const struct ra_format *fmt = ra_find_unorm_format(p->ra, 1, comps);
ra_tex_resize(p->ra, p->log, tex, w, h * 2, fmt);
struct ra_fbo fbo = { *tex };
vo_gpu: invalidate fbotex before drawing Don't discard the OSD or pass_draw_to_screen passes though. Could be faster on some hardware.
2017-08-18 00:31:58 +00:00
finish_pass_fbo(p, fbo, true, &(struct mp_rect){0, 0, w, h * 2});
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
output[n] = *tex;
vo_opengl: vdpau interop without RGB conversion Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
2016-06-19 17:58:40 +00:00
}
}
vo_opengl: change error state handling and fix hwdec crashes on errors gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
2016-05-19 10:18:48 +00:00
// Returns false on failure.
vo_opengl: merge uploading and rendering 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.
2017-06-29 15:09:11 +00:00
static bool pass_upload_image(struct gl_video *p, struct mp_image *mpi, uint64_t id)
vo_opengl: do not block on wayland When not receiving frame callbacks, we should not draw anything to avoid blocking the OpenGL renderer. We do this by extending gl context api, by introducing new optional function 'is_active', that indicates whether OpenGL renderers should draw or not. This fixes issue #249.
2015-03-22 00:32:03 +00:00
{
struct video_image *vimg = &p->image;
vo_opengl: refactor wayland frame skipping Currently, the wayland backend needs extra work to avoid drawing more often than the wayland frame callback allows. (This is not ideal, but will be fixed at a later time.) Unify this with the start_frame callback added for cocoa. Some details change for the better. For example, if a frame is dropped, and a redraw is done afterwards, the actually correct frame is redrawn, instead whatever was in the textures from before the dropped frame.
2015-05-01 16:44:45 +00:00
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
if (vimg->id == id)
return true;
vo_opengl: change error state handling and fix hwdec crashes on errors gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
2016-05-19 10:18:48 +00:00
unref_current_image(p);
vo_opengl: simplify After recent changes, there is no reason why gl_video_set_image() should exist anymore. So merge it back into gl_video_upload_image().
2015-07-15 10:22:49 +00:00
mpi = mp_image_new_ref(mpi);
if (!mpi)
vo_opengl: change error state handling and fix hwdec crashes on errors gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
2016-05-19 10:18:48 +00:00
goto error;
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
vo_opengl: simplify After recent changes, there is no reason why gl_video_set_image() should exist anymore. So merge it back into gl_video_upload_image().
2015-07-15 10:22:49 +00:00
vimg->mpi = mpi;
vo_opengl: make frame reupload logic more robust It's not that easy to decide whether a frame needs to be reuploaded/rerendered. Using unique frame IDs for input makes it slightly easier and more robust. This also removes the use of video PTS in the interpolation path. This should also avoid reuploading the video frame if it's just redrawn in paused mode, or when using OSD/subtitles in cover art mode.
2016-11-01 12:06:48 +00:00
vimg->id = id;
vo_opengl: refactor wayland frame skipping Currently, the wayland backend needs extra work to avoid drawing more often than the wayland frame callback allows. (This is not ideal, but will be fixed at a later time.) Unify this with the start_frame callback added for cocoa. Some details change for the better. For example, if a frame is dropped, and a redraw is done afterwards, the actually correct frame is redrawn, instead whatever was in the textures from before the dropped frame.
2015-05-01 16:44:45 +00:00
p->osd_pts = mpi->pts;
vo_opengl: simplify After recent changes, there is no reason why gl_video_set_image() should exist anymore. So merge it back into gl_video_upload_image().
2015-07-15 10:22:49 +00:00
p->frames_uploaded++;
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
vo_opengl: minor cleanup to hwdec texture setting code Instead of special-casing hwdec in the place where the video textures are used, just set the textures in the image upload function. The renderer code doesn't need to know whether hwdec interop is used at all.
2015-07-26 18:13:53 +00:00
if (p->hwdec_active) {
vo_opengl: also collect upload perfdata for hwdec Instead of measuring the actual upload time, this instead measures the time needed to render + map the texture via vdpau. These numbers are still useful, since they're part of the critical path.
2016-06-07 09:05:57 +00:00
// Hardware decoding
vo_opengl: separate hwdec context and mapping, port it to use ra This does two separate rather intrusive things: 1. Make the hwdec context (which does initialization, provides the device to the decoder, and other basic state) and frame mapping (getting textures from a mp_image) separate. This is more flexible, and you could map multiple images at once. It will help removing some hwdec special-casing from video.c. 2. Switch all hwdec API use to ra. Of course all code is still GL specific, but in theory it would be possible to support other backends. The most important change is that the hwdec interop returns ra objects, instead of anything GL specific. This removes the last dependency on GL-specific header files from video.c. I'm mixing these separate changes because both requires essentially rewriting all the glue code, so better do them at once. For the same reason, this change isn't done incrementally. hwdec_ios.m is untested, since I can't test it. Apart from superficial mistakes, this also requires dealing with Apple's texture format fuckups: they force you to use GL_LUMINANCE[_ALPHA] instead of GL_RED and GL_RG. We also need to report the correct format via ra_tex to the renderer, which is done by find_la_variant(). It's unknown whether this works correctly. hwdec_rpi.c as well as vo_rpi.c are still broken. (I need to pull my RPI out of a dusty pile of devices and cables, so, later.)
2017-08-10 15:48:33 +00:00
if (!p->hwdec_mapper)
goto error;
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
pass_describe(p, "map frame (hwdec)");
vo_opengl: move timers to struct ra In order to prevent code duplication and keep the ra abstraction as small as possible, `ra` only implements the actual timer queries, it does not do pooling/averaging of the results. This is instead moved to a ra-neutral struct timer_pool in utils.c.
2017-08-05 16:20:45 +00:00
timer_pool_start(p->upload_timer);
vo_opengl: separate hwdec context and mapping, port it to use ra This does two separate rather intrusive things: 1. Make the hwdec context (which does initialization, provides the device to the decoder, and other basic state) and frame mapping (getting textures from a mp_image) separate. This is more flexible, and you could map multiple images at once. It will help removing some hwdec special-casing from video.c. 2. Switch all hwdec API use to ra. Of course all code is still GL specific, but in theory it would be possible to support other backends. The most important change is that the hwdec interop returns ra objects, instead of anything GL specific. This removes the last dependency on GL-specific header files from video.c. I'm mixing these separate changes because both requires essentially rewriting all the glue code, so better do them at once. For the same reason, this change isn't done incrementally. hwdec_ios.m is untested, since I can't test it. Apart from superficial mistakes, this also requires dealing with Apple's texture format fuckups: they force you to use GL_LUMINANCE[_ALPHA] instead of GL_RED and GL_RG. We also need to report the correct format via ra_tex to the renderer, which is done by find_la_variant(). It's unknown whether this works correctly. hwdec_rpi.c as well as vo_rpi.c are still broken. (I need to pull my RPI out of a dusty pile of devices and cables, so, later.)
2017-08-10 15:48:33 +00:00
bool ok = ra_hwdec_mapper_map(p->hwdec_mapper, vimg->mpi) >= 0;
vo_opengl: move timers to struct ra In order to prevent code duplication and keep the ra abstraction as small as possible, `ra` only implements the actual timer queries, it does not do pooling/averaging of the results. This is instead moved to a ra-neutral struct timer_pool in utils.c.
2017-08-05 16:20:45 +00:00
timer_pool_stop(p->upload_timer);
pass_record(p, timer_pool_measure(p->upload_timer));
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
vimg->hwdec_mapped = true;
if (ok) {
struct mp_image layout = {0};
mp_image_set_params(&layout, &p->image_params);
vo_opengl: separate hwdec context and mapping, port it to use ra This does two separate rather intrusive things: 1. Make the hwdec context (which does initialization, provides the device to the decoder, and other basic state) and frame mapping (getting textures from a mp_image) separate. This is more flexible, and you could map multiple images at once. It will help removing some hwdec special-casing from video.c. 2. Switch all hwdec API use to ra. Of course all code is still GL specific, but in theory it would be possible to support other backends. The most important change is that the hwdec interop returns ra objects, instead of anything GL specific. This removes the last dependency on GL-specific header files from video.c. I'm mixing these separate changes because both requires essentially rewriting all the glue code, so better do them at once. For the same reason, this change isn't done incrementally. hwdec_ios.m is untested, since I can't test it. Apart from superficial mistakes, this also requires dealing with Apple's texture format fuckups: they force you to use GL_LUMINANCE[_ALPHA] instead of GL_RED and GL_RG. We also need to report the correct format via ra_tex to the renderer, which is done by find_la_variant(). It's unknown whether this works correctly. hwdec_rpi.c as well as vo_rpi.c are still broken. (I need to pull my RPI out of a dusty pile of devices and cables, so, later.)
2017-08-10 15:48:33 +00:00
struct ra_tex **tex = p->hwdec_mapper->tex;
struct ra_tex *tmp[4] = {0};
if (p->hwdec_mapper->vdpau_fields) {
reinterleave_vdpau(p, tex, tmp);
tex = tmp;
}
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
for (int n = 0; n < p->plane_count; n++) {
vimg->planes[n] = (struct texplane){
.w = mp_image_plane_w(&layout, n),
.h = mp_image_plane_h(&layout, n),
vo_opengl: separate hwdec context and mapping, port it to use ra This does two separate rather intrusive things: 1. Make the hwdec context (which does initialization, provides the device to the decoder, and other basic state) and frame mapping (getting textures from a mp_image) separate. This is more flexible, and you could map multiple images at once. It will help removing some hwdec special-casing from video.c. 2. Switch all hwdec API use to ra. Of course all code is still GL specific, but in theory it would be possible to support other backends. The most important change is that the hwdec interop returns ra objects, instead of anything GL specific. This removes the last dependency on GL-specific header files from video.c. I'm mixing these separate changes because both requires essentially rewriting all the glue code, so better do them at once. For the same reason, this change isn't done incrementally. hwdec_ios.m is untested, since I can't test it. Apart from superficial mistakes, this also requires dealing with Apple's texture format fuckups: they force you to use GL_LUMINANCE[_ALPHA] instead of GL_RED and GL_RG. We also need to report the correct format via ra_tex to the renderer, which is done by find_la_variant(). It's unknown whether this works correctly. hwdec_rpi.c as well as vo_rpi.c are still broken. (I need to pull my RPI out of a dusty pile of devices and cables, so, later.)
2017-08-10 15:48:33 +00:00
.tex = tex[n],
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
};
}
} else {
vo_opengl: print error if opengl hwdec interop fails
2016-04-27 11:32:20 +00:00
MP_FATAL(p, "Mapping hardware decoded surface failed.\n");
vo_opengl: change error state handling and fix hwdec crashes on errors gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
2016-05-19 10:18:48 +00:00
goto error;
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
}
vo_opengl: change error state handling and fix hwdec crashes on errors gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
2016-05-19 10:18:48 +00:00
return true;
vo_opengl: minor cleanup to hwdec texture setting code Instead of special-casing hwdec in the place where the video textures are used, just set the textures in the image upload function. The renderer code doesn't need to know whether hwdec interop is used at all.
2015-07-26 18:13:53 +00:00
}
vo_opengl: add infrastructure for hardware decoding OpenGL interop Most hardware decoding APIs provide some OpenGL interop. This allows using vo_opengl, without having to read the video data back from GPU. This requires adding a backend for each hardware decoding API. (Each backend is an entry in gl_hwdec_vaglx[].) The backends expose video data as a set of OpenGL textures. Add infrastructure to support this. The next commit will add support for VA-API.
2013-11-03 23:00:18 +00:00
vo_opengl: also collect upload perfdata for hwdec Instead of measuring the actual upload time, this instead measures the time needed to render + map the texture via vdpau. These numbers are still useful, since they're part of the critical path.
2016-06-07 09:05:57 +00:00
// Software decoding
vo_opengl: add infrastructure for hardware decoding OpenGL interop Most hardware decoding APIs provide some OpenGL interop. This allows using vo_opengl, without having to read the video data back from GPU. This requires adding a backend for each hardware decoding API. (Each backend is an entry in gl_hwdec_vaglx[].) The backends expose video data as a set of OpenGL textures. Add infrastructure to support this. The next commit will add support for VA-API.
2013-11-03 23:00:18 +00:00
assert(mpi->num_planes == p->plane_count);
vo_opengl: move timers to struct ra In order to prevent code duplication and keep the ra abstraction as small as possible, `ra` only implements the actual timer queries, it does not do pooling/averaging of the results. This is instead moved to a ra-neutral struct timer_pool in utils.c.
2017-08-05 16:20:45 +00:00
timer_pool_start(p->upload_timer);
vo_opengl: add infrastructure for hardware decoding OpenGL interop Most hardware decoding APIs provide some OpenGL interop. This allows using vo_opengl, without having to read the video data back from GPU. This requires adding a backend for each hardware decoding API. (Each backend is an entry in gl_hwdec_vaglx[].) The backends expose video data as a set of OpenGL textures. Add infrastructure to support this. The next commit will add support for VA-API.
2013-11-03 23:00:18 +00:00
for (int n = 0; n < p->plane_count; n++) {
gl_video: move video image fields into a struct This is a bit cleaner. Also don't repeat the chroma shift calculations over and over, but store the image size instead, which is simpler and will give us a chance to fix display of non-mod-2 image sizes.
2013-03-28 19:40:19 +00:00
struct texplane *plane = &vimg->planes[n];
vo_opengl: move PBO upload handling to shared code This introduces a gl_pbo_upload_tex() function, which works almost like our gl_upload_tex() glTexSubImage2D() wrapper, except it takes a struct which caches the PBO handles. It also takes the full texture size (to make allocating an ideal buffer size easier), and a parameter to disable PBOs (so that the caller doesn't have to duplicate the gl_upload_tex() call if PBOs are disabled or unavailable). This also removes warnings and fallbacks on PBO failure. We just silently try using PBOs on every frame, and if that fails at some point, revert to normal texture uploads. Probably doesn't matter.
2016-07-03 14:00:51 +00:00
vo_opengl: refactor RA texture and buffer updates - tex_uploads args are moved to a struct - the ability to directly upload texture data without going through a buffer is made explicit - the concept of buffer updates and buffer polling is made more explicit and generalized to buf_update as well (not just mapped buffers) - the ability to call tex_upload/buf_update on a tex/buf is made explicit during tex/buf creation - uploading from buffers now uses an explicit offset instead of implicitly comparing *src against buf->data, because not all buffers may actually be persistently mapped - the initial_data = immutable requirement is dropped. (May be re-added later for D3D11 if that ever becomes a thing) This change helps the vulkan abstraction immensely and also helps move common code (like the PBO pooling) out of ra_gl and into the opengl/utils.c This also technically has the side-benefit / side-constraint of using PBOs for OSD texture uploads as well, which actually seems to help performance on machines where --opengl-pbo is faster than the naive code path. Because of this, I decided to hook up the OSD code to the opengl-pbo option as well. One drawback of this refactor is that the GL_STREAM_COPY hack for texture uploads "got lost", but I think I'm happy with that going away anyway since DR almost fully deprecates it, and it's not the "right thing" anyway - but instead an nvidia-only hack to make this stuff work somewhat better on NUMA systems with discrete GPUs. Another change is that due to the way fencing works with ra_buf (we get one fence per ra_buf per upload) we have to use multiple ra_bufs instead of offsets into a shared buffer. But for OpenGL this is probably better anyway. It's possible that in future, we could support having independent “buffer slices” (each with their own fence/sync object), but this would be an optimization more than anything. I also think that we could address the underlying problem (memory closeness) differently by making the ra_vk memory allocator smart enough to chunk together allocations under the hood.
2017-08-16 20:13:51 +00:00
struct ra_tex_upload_params params = {
.tex = plane->tex,
.src = mpi->planes[n],
.invalidate = true,
.stride = mpi->stride[n],
};
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
vo_gpu: never pass flipped images to ra or ra backends Seems like the last refactor to this code broke playing flipped images, at least with --opengl-pbo --gpu-api=opengl. Flipping is rather a shitmess. The main problem is that OpenGL does not support flipped uploading. The original vo_gl implementation considered it important to handle the flipped case efficiently, so instead of uploading the image line by line backwards, it uploaded it flipped, and then flipped it in the renderer (basically the upload path ignored the flipping). The ra code and backends probably have an insane and inconsistent mix of semantics, so fix this by never passing it flipped images in the first place. In the future, the backends should probably support flipped images directly. Fixes #5097.
2017-11-10 09:06:33 +00:00
plane->flipped = params.stride < 0;
if (plane->flipped) {
int h = mp_image_plane_h(mpi, n);
params.src = (char *)params.src + (h - 1) * params.stride;
params.stride = -params.stride;
}
vo_opengl: refactor RA texture and buffer updates - tex_uploads args are moved to a struct - the ability to directly upload texture data without going through a buffer is made explicit - the concept of buffer updates and buffer polling is made more explicit and generalized to buf_update as well (not just mapped buffers) - the ability to call tex_upload/buf_update on a tex/buf is made explicit during tex/buf creation - uploading from buffers now uses an explicit offset instead of implicitly comparing *src against buf->data, because not all buffers may actually be persistently mapped - the initial_data = immutable requirement is dropped. (May be re-added later for D3D11 if that ever becomes a thing) This change helps the vulkan abstraction immensely and also helps move common code (like the PBO pooling) out of ra_gl and into the opengl/utils.c This also technically has the side-benefit / side-constraint of using PBOs for OSD texture uploads as well, which actually seems to help performance on machines where --opengl-pbo is faster than the naive code path. Because of this, I decided to hook up the OSD code to the opengl-pbo option as well. One drawback of this refactor is that the GL_STREAM_COPY hack for texture uploads "got lost", but I think I'm happy with that going away anyway since DR almost fully deprecates it, and it's not the "right thing" anyway - but instead an nvidia-only hack to make this stuff work somewhat better on NUMA systems with discrete GPUs. Another change is that due to the way fencing works with ra_buf (we get one fence per ra_buf per upload) we have to use multiple ra_bufs instead of offsets into a shared buffer. But for OpenGL this is probably better anyway. It's possible that in future, we could support having independent “buffer slices” (each with their own fence/sync object), but this would be an optimization more than anything. I also think that we could address the underlying problem (memory closeness) differently by making the ra_vk memory allocator smart enough to chunk together allocations under the hood.
2017-08-16 20:13:51 +00:00
struct dr_buffer *mapped = gl_find_dr_buffer(p, mpi->planes[n]);
if (mapped) {
params.buf = mapped->buf;
params.buf_offset = (uintptr_t)params.src -
(uintptr_t)mapped->buf->data;
params.src = NULL;
}
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
if (p->using_dr_path != !!mapped) {
p->using_dr_path = !!mapped;
MP_VERBOSE(p, "DR enabled: %s\n", p->using_dr_path ? "yes" : "no");
}
vo_opengl: refactor RA texture and buffer updates - tex_uploads args are moved to a struct - the ability to directly upload texture data without going through a buffer is made explicit - the concept of buffer updates and buffer polling is made more explicit and generalized to buf_update as well (not just mapped buffers) - the ability to call tex_upload/buf_update on a tex/buf is made explicit during tex/buf creation - uploading from buffers now uses an explicit offset instead of implicitly comparing *src against buf->data, because not all buffers may actually be persistently mapped - the initial_data = immutable requirement is dropped. (May be re-added later for D3D11 if that ever becomes a thing) This change helps the vulkan abstraction immensely and also helps move common code (like the PBO pooling) out of ra_gl and into the opengl/utils.c This also technically has the side-benefit / side-constraint of using PBOs for OSD texture uploads as well, which actually seems to help performance on machines where --opengl-pbo is faster than the naive code path. Because of this, I decided to hook up the OSD code to the opengl-pbo option as well. One drawback of this refactor is that the GL_STREAM_COPY hack for texture uploads "got lost", but I think I'm happy with that going away anyway since DR almost fully deprecates it, and it's not the "right thing" anyway - but instead an nvidia-only hack to make this stuff work somewhat better on NUMA systems with discrete GPUs. Another change is that due to the way fencing works with ra_buf (we get one fence per ra_buf per upload) we have to use multiple ra_bufs instead of offsets into a shared buffer. But for OpenGL this is probably better anyway. It's possible that in future, we could support having independent “buffer slices” (each with their own fence/sync object), but this would be an optimization more than anything. I also think that we could address the underlying problem (memory closeness) differently by making the ra_vk memory allocator smart enough to chunk together allocations under the hood.
2017-08-16 20:13:51 +00:00
vo_opengl: refactor tex_upload to ra_buf_pool Also refactors the usage of tex_upload to make ra_tex_upload_pbo a RA-internal thing again. ra_buf_pool has the main advantage of being dynamically sized depending on buf_poll, so for OpenGL we'll end up only using one buffer (when not persistently mapping) - while for vulkan we'll use as many as necessary, which depends on the swapchain depth anyway.
2017-08-19 02:33:40 +00:00
if (!p->ra->fns->tex_upload(p->ra, &params)) {
vo_opengl: refactor RA texture and buffer updates - tex_uploads args are moved to a struct - the ability to directly upload texture data without going through a buffer is made explicit - the concept of buffer updates and buffer polling is made more explicit and generalized to buf_update as well (not just mapped buffers) - the ability to call tex_upload/buf_update on a tex/buf is made explicit during tex/buf creation - uploading from buffers now uses an explicit offset instead of implicitly comparing *src against buf->data, because not all buffers may actually be persistently mapped - the initial_data = immutable requirement is dropped. (May be re-added later for D3D11 if that ever becomes a thing) This change helps the vulkan abstraction immensely and also helps move common code (like the PBO pooling) out of ra_gl and into the opengl/utils.c This also technically has the side-benefit / side-constraint of using PBOs for OSD texture uploads as well, which actually seems to help performance on machines where --opengl-pbo is faster than the naive code path. Because of this, I decided to hook up the OSD code to the opengl-pbo option as well. One drawback of this refactor is that the GL_STREAM_COPY hack for texture uploads "got lost", but I think I'm happy with that going away anyway since DR almost fully deprecates it, and it's not the "right thing" anyway - but instead an nvidia-only hack to make this stuff work somewhat better on NUMA systems with discrete GPUs. Another change is that due to the way fencing works with ra_buf (we get one fence per ra_buf per upload) we have to use multiple ra_bufs instead of offsets into a shared buffer. But for OpenGL this is probably better anyway. It's possible that in future, we could support having independent “buffer slices” (each with their own fence/sync object), but this would be an optimization more than anything. I also think that we could address the underlying problem (memory closeness) differently by making the ra_vk memory allocator smart enough to chunk together allocations under the hood.
2017-08-16 20:13:51 +00:00
timer_pool_stop(p->upload_timer);
goto error;
}
if (mapped && !mapped->mpi)
mapped->mpi = mp_image_new_ref(mpi);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
vo_opengl: move timers to struct ra In order to prevent code duplication and keep the ra abstraction as small as possible, `ra` only implements the actual timer queries, it does not do pooling/averaging of the results. This is instead moved to a ra-neutral struct timer_pool in utils.c.
2017-08-05 16:20:45 +00:00
timer_pool_stop(p->upload_timer);
vo_opengl: refactor tex_upload to ra_buf_pool Also refactors the usage of tex_upload to make ra_tex_upload_pbo a RA-internal thing again. ra_buf_pool has the main advantage of being dynamically sized depending on buf_poll, so for OpenGL we'll end up only using one buffer (when not persistently mapping) - while for vulkan we'll use as many as necessary, which depends on the swapchain depth anyway.
2017-08-19 02:33:40 +00:00
bool using_pbo = p->ra->use_pbo || !(p->ra->caps & RA_CAP_DIRECT_UPLOAD);
const char *mode = p->using_dr_path ? "DR" : using_pbo ? "PBO" : "naive";
vo_opengl: describe the texture uploading mode Be a bit more transparent here, which is especially helpful when people are sending me screenshots of stats pages.
2017-07-26 00:42:23 +00:00
pass_describe(p, "upload frame (%s)", mode);
vo_opengl: move timers to struct ra In order to prevent code duplication and keep the ra abstraction as small as possible, `ra` only implements the actual timer queries, it does not do pooling/averaging of the results. This is instead moved to a ra-neutral struct timer_pool in utils.c.
2017-08-05 16:20:45 +00:00
pass_record(p, timer_pool_measure(p->upload_timer));
vo_opengl: add time queries To avoid blocking the CPU, we use 8 time objects and rotate through them, only blocking until the last possible moment (before we need access to them on the next iteration through the ring buffer). I tested it out on my machine and 4 query objects were enough to guarantee block-free querying, but the extra margin shouldn't hurt. Frame render times are just output at the end of each frame, via MP_DBG. This might be improved in the future. (In particular, I want to expose these numbers as properties so that users get some more visible feedback about render times) Currently, we measure pass_render_frame and pass_draw_to_screen separately because the former might be called multiple times due to interpolation. Doing it this way gives more faithful numbers. Same goes for frame upload times.
2016-06-05 19:55:30 +00:00
vo_opengl: change error state handling and fix hwdec crashes on errors gl_video_upload_image() can fail in the hardware decoding case. In this case rendering continued "normally", which meant that pass_get_img_tex() would kill the process with an assertion failure. Fix this by allowing gl_video_upload_image() to fail, and exit rendering early enough to skip code which requires an image to be present. (Maybe this is still a bit too subtle, but better than before.) Set an error flag, and render the blue screen we introduced for shader errors. (For this purpose also move the rendering of it to final output, to ensure it's visible at all.) The error flag is temporary, because the associated failure might also be temporary, unlike shader compilation errors.
2016-05-19 10:18:48 +00:00
return true;
error:
unref_current_image(p);
p->broken_frame = true;
return false;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
vo_opengl: make fbotex helper use ra Further work removing GL dependencies from the actual video renderer, and moving them into ra backends. Use of glInvalidateFramebuffer() falls away. I'd like to keep this, but it's better to readd it once shader runs are in ra.
2017-08-04 11:48:37 +00:00
static bool test_fbo(struct gl_video *p, const struct ra_format *fmt)
gl_video: add some debug code for testing texture depth This probes and prints the depth of some texture formats with the help of a FBO. By default it tests the format used for scaling, as well as the format used for dithering and the 3D LUT (if any of these are enabled). The output is visible only with -v. Some representative values are probed, and the difference of input and output value is printed as hex- float. Hex-floats are used because they make the implied precision more obvious. Originally I wanted to do some more sophisticated guessing of the implied depth/precision for more user-friendly reporting, but then I decided that printing raw data is better for debugging, especially if things go wrong. This does not try to disable any functionality and does not print any warnings if the depth is lower than what it should be.
2013-05-30 13:37:13 +00:00
{
vo_opengl: make fbotex helper use ra Further work removing GL dependencies from the actual video renderer, and moving them into ra backends. Use of glInvalidateFramebuffer() falls away. I'd like to keep this, but it's better to readd it once shader runs are in ra.
2017-08-04 11:48:37 +00:00
MP_VERBOSE(p, "Testing FBO format %s\n", fmt->name);
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct ra_tex *tex = NULL;
bool success = ra_tex_resize(p->ra, p->log, &tex, 16, 16, fmt);
ra_tex_free(p->ra, &tex);
vo_opengl: require FBOs and get rid of the single-pass optimization This change makes vo_opengl slightly less compatible (ancient devices without FBOs will no longer work) and decreases performance in the simplest case (vo=opengl), in exchange for significantly reducing code complexity and making everything easier to reason about.
2015-09-05 09:39:20 +00:00
return success;
gl_video: add some debug code for testing texture depth This probes and prints the depth of some texture formats with the help of a FBO. By default it tests the format used for scaling, as well as the format used for dithering and the 3D LUT (if any of these are enabled). The output is visible only with -v. Some representative values are probed, and the difference of input and output value is printed as hex- float. Hex-floats are used because they make the implied precision more obvious. Originally I wanted to do some more sophisticated guessing of the implied depth/precision for more user-friendly reporting, but then I decided that printing raw data is better for debugging, especially if things go wrong. This does not try to disable any functionality and does not print any warnings if the depth is lower than what it should be.
2013-05-30 13:37:13 +00:00
}
vo_opengl: enable dumb-mode automatically if possible I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
2015-11-19 20:22:24 +00:00
// Return whether dumb-mode can be used without disabling any features.
video: change some remaining vo_opengl mentions to vo_gpu
2018-01-20 15:10:42 +00:00
// Essentially, vo_gpu with mostly default settings will return true.
vo_opengl: enable dumb-mode automatically if possible I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
2015-11-19 20:22:24 +00:00
static bool check_dumb_mode(struct gl_video *p)
{
struct gl_video_opts *o = &p->opts;
vo_opengl: support 10 bit support with ANGLE GLES does not support high bit depth fixed point textures for unknown reasons, so direct 10 bit input is not possible. But we can still use integer textures, which are supported by GLES 3.0. These store integer data just like the standard fixed point textures, except they are not normalized on sampling. They also don't support bilinear filtering, and require a special sampler ("usampler2D"). While these texture formats enable us to shuffle the data to the GPU, they're rather impractical with the requirements mentioned above and our current architecture. One problem is that most code assumes it can always use bilinear scaling (even if bilinear is never used when using appropriate scale/cscale options). Another is that we don't have any concept of running a function on a texture in an uniform way. So for now, run a simple conversion step through a FBO. The FBO will use the rgba16f format normally, which gives enough bits for 10 bit, and will at least gracefully degrade with higher depth input. This is bound to be much slower than a more "direct" method, but at least it works and is simple to implement. The odd change of function call order in init_video() is to properly disable "dumb mode" (no FBO use) if these texture formats are in use.
2016-01-26 19:47:32 +00:00
if (p->use_integer_conversion)
return false;
vo_opengl: rework --opengl-dumb-mode 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.
2017-07-07 12:46:46 +00:00
if (o->dumb_mode > 0) // requested by user
vo_opengl: enable dumb-mode automatically if possible I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
2015-11-19 20:22:24 +00:00
return true;
vo_opengl: rework --opengl-dumb-mode 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.
2017-07-07 12:46:46 +00:00
if (o->dumb_mode < 0) // disabled by user
return false;
// otherwise, use auto-detection
vo_opengl: enable dumb-mode automatically if possible I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
2015-11-19 20:22:24 +00:00
if (o->target_prim || o->target_trc || o->linear_scaling ||
o->correct_downscaling || o->sigmoid_upscaling || o->interpolation ||
vo_opengl: remove prescaling framework with superxbr prescaler Signed-off-by: wm4 <wm4@nowhere>
2016-06-10 12:35:09 +00:00
o->blend_subs || o->deband || o->unsharp)
vo_opengl: enable dumb-mode automatically if possible I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
2015-11-19 20:22:24 +00:00
return false;
vo_opengl: add macros for scaler units There was no real point in hard-coding these all over the place, especially since the order was sort of arbitrary and confusing.
2016-03-05 08:42:57 +00:00
// check remaining scalers (tscale is already implicitly excluded above)
for (int i = 0; i < SCALER_COUNT; i++) {
if (i != SCALER_TSCALE) {
const char *name = o->scaler[i].kernel.name;
if (name && strcmp(name, "bilinear") != 0)
return false;
}
vo_opengl: enable dumb-mode automatically if possible I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
2015-11-19 20:22:24 +00:00
}
vo_opengl: support external user hooks This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
2016-04-20 23:33:13 +00:00
if (o->user_shaders && o->user_shaders[0])
return false;
vo_opengl: enable dumb-mode automatically if possible I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
2015-11-19 20:22:24 +00:00
if (p->use_lut_3d)
return false;
return true;
}
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
// Disable features that are not supported with the current OpenGL version.
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
static void check_gl_features(struct gl_video *p)
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
{
vo_opengl: move shader handling to ra Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
2017-08-05 12:20:14 +00:00
struct ra *ra = p->ra;
bool have_float_tex = !!ra_find_float16_format(ra, 1);
bool have_mglsl = ra->glsl_version >= 130; // modern GLSL
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
const struct ra_format *rg_tex = ra_find_unorm_format(p->ra, 1, 2);
bool have_texrg = rg_tex && !rg_tex->luminance_alpha;
vo_opengl: move shader handling to ra Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
2017-08-05 12:20:14 +00:00
bool have_compute = ra->caps & RA_CAP_COMPUTE;
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
bool have_ssbo = ra->caps & RA_CAP_BUF_RW;
vo_gpu: use a variable for the RA_CAP_FRAGCOORD flag This is just a cosmetic change. Now the RA_CAP_FRAGCOORD check looks like all the others.
2018-02-12 12:06:57 +00:00
bool have_fragcoord = ra->caps & RA_CAP_FRAGCOORD;
vo_gpu: correctly infer HDR peak detection support The re-ordering of commits e3d93fd and 0870859 ended up swallowing the change which made the HDR tone mapping algorithm actually check for RA_CAP_NUM_GROUPS support.
2018-02-10 21:49:19 +00:00
bool have_numgroups = ra->caps & RA_CAP_NUM_GROUPS;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_gpu: add rgba16hf to the list of FBO formats This should be functionally identical to rgba16f, since the formats only differ in their representation on the CPU, but it could be useful for RA backends that don't expose rgba16f, like Vulkan. It's definitely useful for the WIP D3D11 backend.
2017-10-18 12:40:23 +00:00
const char *auto_fbo_fmts[] = {"rgba16", "rgba16f", "rgba16hf",
"rgb10_a2", "rgba8", 0};
vo_opengl: make fbotex helper use ra Further work removing GL dependencies from the actual video renderer, and moving them into ra backends. Use of glInvalidateFramebuffer() falls away. I'd like to keep this, but it's better to readd it once shader runs are in ra.
2017-08-04 11:48:37 +00:00
const char *user_fbo_fmts[] = {p->opts.fbo_format, 0};
const char **fbo_fmts = user_fbo_fmts[0] && strcmp(user_fbo_fmts[0], "auto")
? user_fbo_fmts : auto_fbo_fmts;
vo_opengl: slightly better FBO format check Now that we know in advance whether an implementation should support a specific format, we have more flexibility when determining which format to use. In particular, we can drop the roundabout ES logic. I'm not sure if actually trying to create the FBO for probing still has any value. But it might, so leave it for now.
2016-05-12 19:08:51 +00:00
bool have_fbo = false;
vo_opengl: make fbotex helper use ra Further work removing GL dependencies from the actual video renderer, and moving them into ra backends. Use of glInvalidateFramebuffer() falls away. I'd like to keep this, but it's better to readd it once shader runs are in ra.
2017-08-04 11:48:37 +00:00
p->fbo_format = NULL;
vo_opengl: slightly better FBO format check Now that we know in advance whether an implementation should support a specific format, we have more flexibility when determining which format to use. In particular, we can drop the roundabout ES logic. I'm not sure if actually trying to create the FBO for probing still has any value. But it might, so leave it for now.
2016-05-12 19:08:51 +00:00
for (int n = 0; fbo_fmts[n]; n++) {
vo_opengl: make fbotex helper use ra Further work removing GL dependencies from the actual video renderer, and moving them into ra backends. Use of glInvalidateFramebuffer() falls away. I'd like to keep this, but it's better to readd it once shader runs are in ra.
2017-08-04 11:48:37 +00:00
const char *fmt = fbo_fmts[n];
const struct ra_format *f = ra_find_named_format(p->ra, fmt);
if (!f && fbo_fmts == user_fbo_fmts)
MP_WARN(p, "FBO format '%s' not found!\n", fmt);
if (f && f->renderable && f->linear_filter && test_fbo(p, f)) {
MP_VERBOSE(p, "Using FBO format %s.\n", f->name);
vo_opengl: slightly better FBO format check Now that we know in advance whether an implementation should support a specific format, we have more flexibility when determining which format to use. In particular, we can drop the roundabout ES logic. I'm not sure if actually trying to create the FBO for probing still has any value. But it might, so leave it for now.
2016-05-12 19:08:51 +00:00
have_fbo = true;
vo_opengl: make fbotex helper use ra Further work removing GL dependencies from the actual video renderer, and moving them into ra backends. Use of glInvalidateFramebuffer() falls away. I'd like to keep this, but it's better to readd it once shader runs are in ra.
2017-08-04 11:48:37 +00:00
p->fbo_format = f;
vo_opengl: slightly better FBO format check Now that we know in advance whether an implementation should support a specific format, we have more flexibility when determining which format to use. In particular, we can drop the roundabout ES logic. I'm not sure if actually trying to create the FBO for probing still has any value. But it might, so leave it for now.
2016-05-12 19:08:51 +00:00
break;
}
vo_opengl: switch FBO format on GLES GL_RGB10_A2 is the best fixed-point format we can get on GLES/ANGLE for now. (Unless we somehow switch to non-normalized integer textures.)
2015-11-19 20:20:50 +00:00
}
vo_gpu: use a variable for the RA_CAP_FRAGCOORD flag This is just a cosmetic change. Now the RA_CAP_FRAGCOORD check looks like all the others.
2018-02-12 12:06:57 +00:00
if (!have_fragcoord && p->opts.dither_depth >= 0 &&
vo_gpu: check for RA_CAP_FRAGCOORD in dumb mode too The RA_CAP_FRAGCOORD checks apply to dumb mode as well, but they were after the check for dumb mode, which returns early, so they never ran. Fixes #5436
2018-01-29 12:08:49 +00:00
p->opts.dither_algo != DITHER_NONE)
{
p->opts.dither_algo = DITHER_NONE;
MP_WARN(p, "Disabling dithering (no gl_FragCoord).\n");
}
vo_gpu: use a variable for the RA_CAP_FRAGCOORD flag This is just a cosmetic change. Now the RA_CAP_FRAGCOORD check looks like all the others.
2018-02-12 12:06:57 +00:00
if (!have_fragcoord && p->opts.alpha_mode == ALPHA_BLEND_TILES) {
vo_gpu: check for RA_CAP_FRAGCOORD in dumb mode too The RA_CAP_FRAGCOORD checks apply to dumb mode as well, but they were after the check for dumb mode, which returns early, so they never ran. Fixes #5436
2018-01-29 12:08:49 +00:00
p->opts.alpha_mode = ALPHA_BLEND;
// Verbose, since this is the default setting
MP_VERBOSE(p, "Disabling alpha checkerboard (no gl_FragCoord).\n");
}
vo_gpu: check for HDR peak detection in dumb mode too Similar spirit to edb4970ca8b9. check_gl_features() has a confusing early-return. This also adds compute_hdr_peak to the list of options that is copied to the dumb-mode options struct, since it seems to make a difference. Otherwise it would be impossible to disable HDR peak detection in dumb mode.
2018-02-12 12:01:52 +00:00
bool have_compute_peak = have_compute && have_ssbo && have_numgroups;
if (!have_compute_peak && p->opts.compute_hdr_peak >= 0) {
int msgl = p->opts.compute_hdr_peak == 1 ? MSGL_WARN : MSGL_V;
MP_MSG(p, msgl, "Disabling HDR peak computation (no compute shaders).\n");
p->opts.compute_hdr_peak = -1;
}
vo_opengl: rework --opengl-dumb-mode 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.
2017-07-07 12:46:46 +00:00
p->forced_dumb_mode = p->opts.dumb_mode > 0 || !have_fbo || !have_texrg;
vo_opengl: enable dumb-mode automatically if possible I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
2015-11-19 20:22:24 +00:00
bool voluntarily_dumb = check_dumb_mode(p);
vo_opengl: support 10 bit support with ANGLE GLES does not support high bit depth fixed point textures for unknown reasons, so direct 10 bit input is not possible. But we can still use integer textures, which are supported by GLES 3.0. These store integer data just like the standard fixed point textures, except they are not normalized on sampling. They also don't support bilinear filtering, and require a special sampler ("usampler2D"). While these texture formats enable us to shuffle the data to the GPU, they're rather impractical with the requirements mentioned above and our current architecture. One problem is that most code assumes it can always use bilinear scaling (even if bilinear is never used when using appropriate scale/cscale options). Another is that we don't have any concept of running a function on a texture in an uniform way. So for now, run a simple conversion step through a FBO. The FBO will use the rgba16f format normally, which gives enough bits for 10 bit, and will at least gracefully degrade with higher depth input. This is bound to be much slower than a more "direct" method, but at least it works and is simple to implement. The odd change of function call order in init_video() is to properly disable "dumb mode" (no FBO use) if these texture formats are in use.
2016-01-26 19:47:32 +00:00
if (p->forced_dumb_mode || voluntarily_dumb) {
vo_opengl: enable dumb-mode automatically if possible I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
2015-11-19 20:22:24 +00:00
if (voluntarily_dumb) {
MP_VERBOSE(p, "No advanced processing required. Enabling dumb mode.\n");
vo_opengl: rework --opengl-dumb-mode 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.
2017-07-07 12:46:46 +00:00
} else if (p->opts.dumb_mode <= 0) {
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
MP_WARN(p, "High bit depth FBOs unsupported. Enabling dumb mode.\n"
"Most extended features will be disabled.\n");
}
vo_opengl: enable dumb-mode automatically if possible I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
2015-11-19 20:22:24 +00:00
p->dumb_mode = true;
vo_opengl: filter allowed options in dumb-mode Instead of the other way around of disabling disallowed options. This is more robust and also slightly simpler, at least conceptually. If new vo_opengl features are added, they don't need to be explicitly disabled for dumb-mode just to avoid that it accidentally breaks.
2015-09-08 20:55:01 +00:00
// Most things don't work, so whitelist all options that still work.
vo_opengl: simplify option handling Instead of copying the options around... just don't. video.c now has full control over when options are updated. (It still gets notified from outside, but it decides when the updated options are copied: when m_config_cache_update() is called.) So there's no need for tricky stuff, and it can be simplified a bit. Also change lcms.c. We could do it like video.c, and get the options from the global config store. But it seems simpler to just provide a pointer to an option struct, which is arbitrarily mutated from the outside (from the perspective of lcms.c).
2016-09-06 09:11:36 +00:00
p->opts = (struct gl_video_opts){
vo_opengl: filter allowed options in dumb-mode Instead of the other way around of disabling disallowed options. This is more robust and also slightly simpler, at least conceptually. If new vo_opengl features are added, they don't need to be explicitly disabled for dumb-mode just to avoid that it accidentally breaks.
2015-09-08 20:55:01 +00:00
.gamma = p->opts.gamma,
.gamma_auto = p->opts.gamma_auto,
.pbo = p->opts.pbo,
.fbo_format = p->opts.fbo_format,
.alpha_mode = p->opts.alpha_mode,
.use_rectangle = p->opts.use_rectangle,
.background = p->opts.background,
vo_gpu: check for HDR peak detection in dumb mode too Similar spirit to edb4970ca8b9. check_gl_features() has a confusing early-return. This also adds compute_hdr_peak to the list of options that is copied to the dumb-mode options struct, since it seems to make a difference. Otherwise it would be impossible to disable HDR peak detection in dumb mode.
2018-02-12 12:01:52 +00:00
.compute_hdr_peak = p->opts.compute_hdr_peak,
vo_opengl: properly respect dither option if dumb mode is used 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.
2017-03-20 03:44:24 +00:00
.dither_algo = p->opts.dither_algo,
.dither_depth = p->opts.dither_depth,
.dither_size = p->opts.dither_size,
.temporal_dither = p->opts.temporal_dither,
vo_opengl: fix crash by coping temporal_dither_period for dumb mode too Specifically, this field must never be 0 (and the option can naturally not be 0 in any way, unless it wasn't initialized correctly).
2017-04-21 05:16:26 +00:00
.temporal_dither_period = p->opts.temporal_dither_period,
vo_opengl: properly respect dither option if dumb mode is used 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.
2017-03-20 03:44:24 +00:00
.tex_pad_x = p->opts.tex_pad_x,
.tex_pad_y = p->opts.tex_pad_y,
vo_opengl: generalize HDR tone mapping to gamut mapping Since this code was already written for HDR, and is now per-channel (because it works better for HDR as well), we can actually reuse this to get very high quality gamut mapping without clipping. The only required change is to move the tone mapping from before the gamut map to after the gamut map. Additonally, we need to also account for changes in the signal range as a result of applying the CMS when we compute ref_peak, which is fortunately pretty easy because we only need to consider the case of primaries mapping to themselves. Since `HDR` no longer really makes sense as a label, rename it to `--tone-mapping` in general. Also fits better with `--tone-mapping-desat` etc. Arguably we could also rename `--hdr-compute-peak`, but that option is basically only useful for HDR content anyway because we don't need information about the signal range for gamut mapping. This (finally!) gives us reasonably high quality gamut mapping even in the absence of an ICC profile / 3DLUT.
2017-08-03 10:46:57 +00:00
.tone_mapping = p->opts.tone_mapping,
vo_opengl: copy over HDR parameters to dumb_mode Since dumb mode is affected by tone mapping (which I'll call a feature, not a bug), we need to copy over the configuration - in particular, the defaults. (To prevent a render failure)
2016-05-16 12:20:48 +00:00
.tone_mapping_param = p->opts.tone_mapping_param,
vo_opengl: add --tone-mapping-desaturate 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.
2017-07-06 03:43:00 +00:00
.tone_mapping_desat = p->opts.tone_mapping_desat,
vo_opengl: apply --opengl-early-flush in dumb mode too In "dumb mode" (where most features are disabled and which only performs some basic rendering) we explicitly copy a set of whitelisted options, and leave all the other options at their default values. Add the new --opengl-early-flush option to this whitelist. Also remove an option field accidentally added in the commit adding --opengl-early-flush.
2016-10-05 18:35:00 +00:00
.early_flush = p->opts.early_flush,
vo_gpu: enable 3DLUTs in dumb mode Unless FBOs are unsupported, this works. In particular, it's required to get ICC profiles working in voluntary dumb mode. So instead of blanket-disabling it, only disable it in the !have_fbo false case.
2017-09-30 14:25:20 +00:00
.icc_opts = p->opts.icc_opts,
video: properly initialize and set hwdec_interop Don't reset --gpu-hwdec-interop if vo_gpu uses dumb mode.
2017-12-10 21:54:32 +00:00
.hwdec_interop = p->opts.hwdec_interop,
vo_opengl: filter allowed options in dumb-mode Instead of the other way around of disabling disallowed options. This is more robust and also slightly simpler, at least conceptually. If new vo_opengl features are added, they don't need to be explicitly disabled for dumb-mode just to avoid that it accidentally breaks.
2015-09-08 20:55:01 +00:00
};
vo_opengl: add macros for scaler units There was no real point in hard-coding these all over the place, especially since the order was sort of arbitrary and confusing.
2016-03-05 08:42:57 +00:00
for (int n = 0; n < SCALER_COUNT; n++)
vo_opengl: simplify option handling Instead of copying the options around... just don't. video.c now has full control over when options are updated. (It still gets notified from outside, but it decides when the updated options are copied: when m_config_cache_update() is called.) So there's no need for tricky stuff, and it can be simplified a bit. Also change lcms.c. We could do it like video.c, and get the options from the global config store. But it seems simpler to just provide a pointer to an option struct, which is arbitrarily mutated from the outside (from the perspective of lcms.c).
2016-09-06 09:11:36 +00:00
p->opts.scaler[n] = gl_video_opts_def.scaler[n];
vo_gpu: enable 3DLUTs in dumb mode Unless FBOs are unsupported, this works. In particular, it's required to get ICC profiles working in voluntary dumb mode. So instead of blanket-disabling it, only disable it in the !have_fbo false case.
2017-09-30 14:25:20 +00:00
if (!have_fbo)
p->use_lut_3d = false;
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
return;
vo_opengl: require FBOs and get rid of the single-pass optimization This change makes vo_opengl slightly less compatible (ancient devices without FBOs will no longer work) and decreases performance in the simplest case (vo=opengl), in exchange for significantly reducing code complexity and making everything easier to reason about.
2015-09-05 09:39:20 +00:00
}
vo_opengl: enable dumb-mode automatically if possible I decided that I actually can't stand how vo_opengl unnecessarily puts the video through 3 shader stages (instead of 1). Thus, what was meant to be a fallback for weak OpenGL implementations, the dumb-mode, now becomes default if the user settings allow it. The code required to check for the settings isn't so wild, so I guess it's manageable. I still hope that one day, our rendering logic can generate ideal shader stages for this case too. Note that in theory, dumb-mode could be reenabled at runtime due to a color management 3D LUT being set, so a separate dumb_mode field is required. The dumb-mode option can't just be overwritten.
2015-11-19 20:22:24 +00:00
p->dumb_mode = false;
vo_opengl: require FBOs and get rid of the single-pass optimization This change makes vo_opengl slightly less compatible (ancient devices without FBOs will no longer work) and decreases performance in the simplest case (vo=opengl), in exchange for significantly reducing code complexity and making everything easier to reason about.
2015-09-05 09:39:20 +00:00
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
// Normally, we want to disable them by default if FBOs are unavailable,
// because they will be slow (not critically slow, but still slower).
// Without FP textures, we must always disable them.
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
// I don't know if luminance alpha float textures exist, so disregard them.
vo_opengl: add macros for scaler units There was no real point in hard-coding these all over the place, especially since the order was sort of arbitrary and confusing.
2016-03-05 08:42:57 +00:00
for (int n = 0; n < SCALER_COUNT; n++) {
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
const struct filter_kernel *kernel =
mp_find_filter_kernel(p->opts.scaler[n].kernel.name);
vo_opengl: test FBOs only if they're going to be used Change test_fbo() so that it checks the FBO lazily, and restructure check_gl_features() to invoke it only if we know that a FBO will be needed for a certain enabled feature. This can avoid strange error messages when using --vo=opengl and the FBO format does not work. It's also less confusing when reading the verbose log (users might think that the FBO is actually used, etc.).
2015-02-26 09:35:49 +00:00
if (kernel) {
char *reason = NULL;
if (!have_float_tex)
vo_opengl: slightly more informative message when disabling scalers
2015-07-27 21:18:19 +00:00
reason = "(float tex. missing)";
vo_opengl: disable scalers on ES2 Even if everything else is available, the need for first class arrays breaks it. In theory we could fix this since we don't strictly need them, but I guess it's not worth bothering. Also give the misnamed have_mix variable a slightly better name.
2016-05-12 18:52:26 +00:00
if (!have_mglsl)
reason = "(GLSL version too old)";
vo_opengl: test FBOs only if they're going to be used Change test_fbo() so that it checks the FBO lazily, and restructure check_gl_features() to invoke it only if we know that a FBO will be needed for a certain enabled feature. This can avoid strange error messages when using --vo=opengl and the FBO format does not work. It's also less confusing when reading the verbose log (users might think that the FBO is actually used, etc.).
2015-02-26 09:35:49 +00:00
if (reason) {
vo_opengl: add scaler name to the 'Disabling scaler' message Print to the user the name of the scaler that gets disabled rather than just printing its number.
2016-06-21 15:57:07 +00:00
MP_WARN(p, "Disabling scaler #%d %s %s.\n", n,
p->opts.scaler[n].kernel.name, reason);
vo_opengl: simplify option handling Instead of copying the options around... just don't. video.c now has full control over when options are updated. (It still gets notified from outside, but it decides when the updated options are copied: when m_config_cache_update() is called.) So there's no need for tricky stuff, and it can be simplified a bit. Also change lcms.c. We could do it like video.c, and get the options from the global config store. But it seems simpler to just provide a pointer to an option struct, which is arbitrarily mutated from the outside (from the perspective of lcms.c).
2016-09-06 09:11:36 +00:00
// p->opts is a copy => we can just mess with it.
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
p->opts.scaler[n].kernel.name = "bilinear";
vo_opengl: correctly disable interpolation if tscale can't be used It'll fail with an assertion in the interpolation code otherwise.
2016-05-12 17:34:02 +00:00
if (n == SCALER_TSCALE)
p->opts.interpolation = 0;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
}
}
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
int use_cms = p->opts.target_prim != MP_CSP_PRIM_AUTO ||
p->opts.target_trc != MP_CSP_TRC_AUTO || p->use_lut_3d;
vo_opengl: Correct and clarify gl_check_features This updates the logic for the new, somewhat unified behavior of SRGB and 3DLUT since 34bf9be (not that it was particularly correct even that change) and checks for the presence of corresponding extensions only in the cases in which they're needed.
2014-03-05 14:01:32 +00:00
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
// mix() is needed for some gamma functions
vo_opengl: disable scalers on ES2 Even if everything else is available, the need for first class arrays breaks it. In theory we could fix this since we don't strictly need them, but I guess it's not worth bothering. Also give the misnamed have_mix variable a slightly better name.
2016-05-12 18:52:26 +00:00
if (!have_mglsl && (p->opts.linear_scaling || p->opts.sigmoid_upscaling)) {
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
p->opts.linear_scaling = false;
p->opts.sigmoid_upscaling = false;
vo_opengl: slightly simplify check_gl_features() Not sure why this was so roundabout; probably to keep spam down if the user's OpenGL drivers are crap (but then just don't enable extended features), or because the "Disabling..." text was so repetitious. But there doesn't seem to be a good reason after all. Also, this could already overflow the fixed size disabled[] array. Just print the messages directly.
2015-04-11 17:24:54 +00:00
MP_WARN(p, "Disabling linear/sigmoid scaling (GLSL version too old).\n");
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
}
vo_opengl: disable scalers on ES2 Even if everything else is available, the need for first class arrays breaks it. In theory we could fix this since we don't strictly need them, but I guess it's not worth bothering. Also give the misnamed have_mix variable a slightly better name.
2016-05-12 18:52:26 +00:00
if (!have_mglsl && use_cms) {
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
p->opts.target_prim = MP_CSP_PRIM_AUTO;
p->opts.target_trc = MP_CSP_TRC_AUTO;
p->use_lut_3d = false;
vo_opengl: slightly simplify check_gl_features() Not sure why this was so roundabout; probably to keep spam down if the user's OpenGL drivers are crap (but then just don't enable extended features), or because the "Disabling..." text was so repetitious. But there doesn't seem to be a good reason after all. Also, this could already overflow the fixed size disabled[] array. Just print the messages directly.
2015-04-11 17:24:54 +00:00
MP_WARN(p, "Disabling color management (GLSL version too old).\n");
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
vo_opengl: disable scalers on ES2 Even if everything else is available, the need for first class arrays breaks it. In theory we could fix this since we don't strictly need them, but I guess it's not worth bothering. Also give the misnamed have_mix variable a slightly better name.
2016-05-12 18:52:26 +00:00
if (!have_mglsl && p->opts.deband) {
vo_opengl: debanding requires GLSL 1.30 We have to disable it, or shader compilation will fail. Fixes #2362.
2015-10-01 18:44:39 +00:00
p->opts.deband = 0;
MP_WARN(p, "Disabling debanding (GLSL version too old).\n");
}
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
static void init_gl(struct gl_video *p)
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
{
debug_check_gl(p, "before init_gl");
vo_opengl: move timers to struct ra In order to prevent code duplication and keep the ra abstraction as small as possible, `ra` only implements the actual timer queries, it does not do pooling/averaging of the results. This is instead moved to a ra-neutral struct timer_pool in utils.c.
2017-08-05 16:20:45 +00:00
p->upload_timer = timer_pool_create(p->ra);
p->blit_timer = timer_pool_create(p->ra);
vo_opengl: measure pass_draw_osd as a whole In the past, this always measured the per-shader execution times of the individual OSD parts, which was thrown off because the shader was reused anyway. (And apparently recording the OSD shader execution times was removed completely, probably because of them being so unrealiably anyway) Since ra_timer no longer has the restriction of not allowing timers to run concurrently, we can just wrap the entire OSD block inside a single osd_timer now, and record that. (Technically, this can still be off when using --blend-subtitles=video/yes and showing a full-screen OSD at the same time. Maybe this can be done better?)
2017-08-05 16:59:28 +00:00
p->osd_timer = timer_pool_create(p->ra);
vo_opengl: add time queries To avoid blocking the CPU, we use 8 time objects and rotate through them, only blocking until the last possible moment (before we need access to them on the next iteration through the ring buffer). I tested it out on my machine and 4 query objects were enough to guarantee block-free querying, but the extra margin shouldn't hurt. Frame render times are just output at the end of each frame, via MP_DBG. This might be improved in the future. (In particular, I want to expose these numbers as properties so that users get some more visible feedback about render times) Currently, we measure pass_render_frame and pass_draw_to_screen separately because the former might be called multiple times due to interpolation. Doing it this way gives more faithful numbers. Same goes for frame upload times.
2016-06-05 19:55:30 +00:00
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
debug_check_gl(p, "after init_gl");
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
ra_dump_tex_formats(p->ra, MSGL_DEBUG);
ra_dump_img_formats(p->ra, MSGL_DEBUG);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
void gl_video_uninit(struct gl_video *p)
{
vo_opengl: make uninit idempotent
2014-12-03 21:37:39 +00:00
if (!p)
return;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
uninit_video(p);
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
for (int n = 0; n < p->num_hwdecs; n++)
ra_hwdec_uninit(p->hwdecs[n]);
p->num_hwdecs = 0;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
gl_sc_destroy(p->sc);
vo_opengl: manage ICC LUT texture via ra Also move the capability check to gl_video_get_lut3d(), because it seems more convenient (ra won't have a _CAP_EXT16).
2017-07-29 19:22:11 +00:00
ra_tex_free(p->ra, &p->lut_3d_texture);
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
ra_buf_free(p->ra, &p->hdr_peak_ssbo);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: move timers to struct ra In order to prevent code duplication and keep the ra abstraction as small as possible, `ra` only implements the actual timer queries, it does not do pooling/averaging of the results. This is instead moved to a ra-neutral struct timer_pool in utils.c.
2017-08-05 16:20:45 +00:00
timer_pool_destroy(p->upload_timer);
timer_pool_destroy(p->blit_timer);
vo_opengl: measure pass_draw_osd as a whole In the past, this always measured the per-shader execution times of the individual OSD parts, which was thrown off because the shader was reused anyway. (And apparently recording the OSD shader execution times was removed completely, probably because of them being so unrealiably anyway) Since ra_timer no longer has the restriction of not allowing timers to run concurrently, we can just wrap the entire OSD block inside a single osd_timer now, and record that. (Technically, this can still be off when using --blend-subtitles=video/yes and showing a full-screen OSD at the same time. Maybe this can be done better?)
2017-08-05 16:59:28 +00:00
timer_pool_destroy(p->osd_timer);
vo_opengl: move timers to struct ra In order to prevent code duplication and keep the ra abstraction as small as possible, `ra` only implements the actual timer queries, it does not do pooling/averaging of the results. This is instead moved to a ra-neutral struct timer_pool in utils.c.
2017-08-05 16:20:45 +00:00
vo_gpu: kill some static arrays This gets rid of the hard-coded limits on the number of hooks, textures and hook points.
2017-09-27 21:38:54 +00:00
for (int i = 0; i < VO_PASS_PERF_MAX; i++) {
vo_opengl: refactor vo performance subsystem 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)
2017-06-29 15:00:06 +00:00
talloc_free(p->pass_fresh[i].desc.start);
talloc_free(p->pass_redraw[i].desc.start);
}
vo_opengl: add time queries To avoid blocking the CPU, we use 8 time objects and rotate through them, only blocking until the last possible moment (before we need access to them on the next iteration through the ring buffer). I tested it out on my machine and 4 query objects were enough to guarantee block-free querying, but the extra margin shouldn't hurt. Frame render times are just output at the end of each frame, via MP_DBG. This might be improved in the future. (In particular, I want to expose these numbers as properties so that users get some more visible feedback about render times) Currently, we measure pass_render_frame and pass_draw_to_screen separately because the former might be called multiple times due to interpolation. Doing it this way gives more faithful numbers. Same goes for frame upload times.
2016-06-05 19:55:30 +00:00
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
mpgl_osd_destroy(p->osd);
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
// Forcibly destroy possibly remaining image references. This should also
// cause gl_video_dr_free_buffer() to be called for the remaining buffers.
gc_pending_dr_fences(p, true);
// Should all have been unreffed already.
assert(!p->num_dr_buffers);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
talloc_free(p);
}
vo_opengl: add smoothmotion frame blending SmoothMotion is a way to time and blend frames made popular by MadVR. It's intended behaviour is to remove stuttering caused by mismatches between the display refresh rate and the video fps, while preserving the video's original artistic qualities (no soap opera effect). It's supposed to make 24fps video playback on 60hz monitors as close as possible to a 24hz monitor. Instead of drawing a frame once once it's pts has passed the vsync time, we redraw at the display refresh rate, and if we detect the vsync is between two frames we interpolated them (depending on their position relative to the vsync). We actually interpolate as few frames as possible to avoid a blur effect as much as possible. For example, if we were to play back a 1fps video on a 60hz monitor, we would blend at most on 1 vsync for each frame (while the other 59 vsyncs would be rendered as is). Frame interpolation is always done before scaling and in linear light when possible (an ICC profile is used, or :srgb is used).
2014-11-23 19:06:05 +00:00
void gl_video_reset(struct gl_video *p)
{
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
gl_video_reset_surfaces(p);
vo_opengl: add smoothmotion frame blending SmoothMotion is a way to time and blend frames made popular by MadVR. It's intended behaviour is to remove stuttering caused by mismatches between the display refresh rate and the video fps, while preserving the video's original artistic qualities (no soap opera effect). It's supposed to make 24fps video playback on 60hz monitors as close as possible to a 24hz monitor. Instead of drawing a frame once once it's pts has passed the vsync time, we redraw at the display refresh rate, and if we detect the vsync is between two frames we interpolated them (depending on their position relative to the vsync). We actually interpolate as few frames as possible to avoid a blur effect as much as possible. For example, if we were to play back a 1fps video on a 60hz monitor, we would blend at most on 1 vsync for each frame (while the other 59 vsyncs would be rendered as is). Frame interpolation is always done before scaling and in linear light when possible (an ICC profile is used, or :srgb is used).
2014-11-23 19:06:05 +00:00
}
vo_opengl: redraw when pausing while showing an interpolated frame If smoothmotion is enabled, and the screen shows an interpolated frame the moment you pause, redraw a non-interpolated frame.
2015-02-04 22:37:38 +00:00
bool gl_video_showing_interpolated_frame(struct gl_video *p)
{
return p->is_interpolated;
}
vo_opengl: restructure format setup 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.
2017-06-30 14:57:17 +00:00
static bool is_imgfmt_desc_supported(struct gl_video *p,
vo_opengl: use ra_* for format negotiation too Format handling via ra_* was added earlier, but the format negotiation part was forgotten. Actually move some aspects of it to ra_get_imgfmt_desc(). Also make sure the unorm and float formats selected by the common format lookup functions are linear filterable. (For OpenGL, this is implicitly guaranteed, so it wasn't done before.) Whether these assumptions should be checked/enforced in the ra code at all is a bit fuzzy, but with ra being helper code only for the actual video renderer, it's probably justified.
2017-07-29 18:11:51 +00:00
const struct ra_imgfmt_desc *desc)
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
{
vo_opengl: restructure format setup 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.
2017-06-30 14:57:17 +00:00
if (!desc->num_planes)
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
return false;
vo_opengl: use ra_* for format negotiation too Format handling via ra_* was added earlier, but the format negotiation part was forgotten. Actually move some aspects of it to ra_get_imgfmt_desc(). Also make sure the unorm and float formats selected by the common format lookup functions are linear filterable. (For OpenGL, this is implicitly guaranteed, so it wasn't done before.) Whether these assumptions should be checked/enforced in the ra code at all is a bit fuzzy, but with ra being helper code only for the actual video renderer, it's probably justified.
2017-07-29 18:11:51 +00:00
if (desc->planes[0]->ctype == RA_CTYPE_UINT && p->forced_dumb_mode)
vo_opengl: support 10 bit support with ANGLE GLES does not support high bit depth fixed point textures for unknown reasons, so direct 10 bit input is not possible. But we can still use integer textures, which are supported by GLES 3.0. These store integer data just like the standard fixed point textures, except they are not normalized on sampling. They also don't support bilinear filtering, and require a special sampler ("usampler2D"). While these texture formats enable us to shuffle the data to the GPU, they're rather impractical with the requirements mentioned above and our current architecture. One problem is that most code assumes it can always use bilinear scaling (even if bilinear is never used when using appropriate scale/cscale options). Another is that we don't have any concept of running a function on a texture in an uniform way. So for now, run a simple conversion step through a FBO. The FBO will use the rgba16f format normally, which gives enough bits for 10 bit, and will at least gracefully degrade with higher depth input. This is bound to be much slower than a more "direct" method, but at least it works and is simple to implement. The odd change of function call order in init_video() is to properly disable "dumb mode" (no FBO use) if these texture formats are in use.
2016-01-26 19:47:32 +00:00
return false;
vo_opengl: GLES 3 support Tested with MESA on software emulation. Seems to work well, although the default FBO format in opengl-hq disables most interesting features. I have no idea how well it will work on real hardware (or if it does at all). Unfortunately, some features, including playback of 10 bit video, are not supported. Not sure what to do about this. GLES 2 or 1 do not work.
2014-12-17 20:48:23 +00:00
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
return true;
}
vo_opengl: add infrastructure for hardware decoding OpenGL interop Most hardware decoding APIs provide some OpenGL interop. This allows using vo_opengl, without having to read the video data back from GPU. This requires adding a backend for each hardware decoding API. (Each backend is an entry in gl_hwdec_vaglx[].) The backends expose video data as a set of OpenGL textures. Add infrastructure to support this. The next commit will add support for VA-API.
2013-11-03 23:00:18 +00:00
bool gl_video_check_format(struct gl_video *p, int mp_format)
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
{
vo_opengl: use ra_* for format negotiation too Format handling via ra_* was added earlier, but the format negotiation part was forgotten. Actually move some aspects of it to ra_get_imgfmt_desc(). Also make sure the unorm and float formats selected by the common format lookup functions are linear filterable. (For OpenGL, this is implicitly guaranteed, so it wasn't done before.) Whether these assumptions should be checked/enforced in the ra code at all is a bit fuzzy, but with ra being helper code only for the actual video renderer, it's probably justified.
2017-07-29 18:11:51 +00:00
struct ra_imgfmt_desc desc;
if (ra_get_imgfmt_desc(p->ra, mp_format, &desc) &&
vo_opengl: restructure format setup 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.
2017-06-30 14:57:17 +00:00
is_imgfmt_desc_supported(p, &desc))
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
return true;
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
for (int n = 0; n < p->num_hwdecs; n++) {
if (ra_hwdec_test_format(p->hwdecs[n], mp_format))
return true;
}
vo_opengl: refactor how hwdec interop exports textures Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
2016-05-10 16:29:10 +00:00
return false;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
video: add a new method to configure filters and VOs The filter chain and the video ouputs have config() functions. They are strictly limited to transfering the video size and format. Other parameters (like color levels) have to be transferred separately. Improve upon this by introducing a separate set of reconfig() functions, which use mp_image_params to carry format parameters. This struct contains all image format related parameters from config(), plus additional parameters such as colorspace. Change vf_rotate to use it, as well as vo_opengl. vf_rotate is just an example/test case, but vo_opengl will need it later. The intention is also to get rid of VOCTRL_SET_YUV_COLORSPACE. This information is now handed to the VOs via reconfig(). The getter, VOCTRL_GET_YUV_COLORSPACE, will still be needed though.
2013-06-07 23:35:44 +00:00
void gl_video_config(struct gl_video *p, struct mp_image_params *params)
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
{
vo_opengl: another attempt at removing the overlay correctly 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.
2017-05-02 15:09:16 +00:00
unmap_overlay(p);
vo_opengl: use dedicated image unref function in config case Just another corner-caseish potential issue. Unlike unreffing the image manually, unref_current_image() also takes care of properly unmapping hwdec frames. (The corner-case part of this is that it's probably never mapped at this point, but it's apparently not entirely guaranteed.)
2016-09-08 13:55:47 +00:00
unref_current_image(p);
vo_opengl: redo aspects of initialization, change hwdec API Instead of checking for resolution and image format changes, always fully reinit on any parameter change. Let init_video do all required initializations, which simplifies things a little bit. Change the gl_video/hardware decoding interop API slightly, so that hwdec initialization gets the full image parameters. Also make some cosmetic changes.
2013-11-05 18:08:44 +00:00
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
if (!mp_image_params_equal(&p->real_image_params, params)) {
vo_opengl: redo aspects of initialization, change hwdec API Instead of checking for resolution and image format changes, always fully reinit on any parameter change. Let init_video do all required initializations, which simplifies things a little bit. Change the gl_video/hardware decoding interop API slightly, so that hwdec initialization gets the full image parameters. Also make some cosmetic changes.
2013-11-05 18:08:44 +00:00
uninit_video(p);
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
p->real_image_params = *params;
p->image_params = *params;
vo_opengl_cb: simplify reconfigure, render transparent if unconfigured I think that's expected; mpv shouldn't draw anything while no video is active. This doesn't blend transparently, though. Also document the vo_opengl_cb thing.
2014-12-09 20:36:45 +00:00
if (params->imgfmt)
vo_opengl: let hwdec driver report the exact image format Hardware decoding/displaying with vo_opengl is done by replacing the normal video textures with textures provided by the hardware decoding API OpenGL interop code. Often, this changes the format (vaglx and vdpau return RGBA, vda returns packed YUV). If the format is changed, there was a chance (or at least a higher potential for bugs) that the shader generation code could be confused by the mismatch of formats, and would create incorrect conversions. Simplify this by requiring the hwdec interop driver to set the format it will return to us. This affects all fields, not just some (done by replacing the format with the value of the converted_imgfmt field in init_format), in particular fields like colorlevels. Currently, no hwdec interop driver does anything sophisticated, and the win is mostly from the mp_image_params_guess_csp() function, which will reset fields like colorlevels to expected value if RGBA is used.
2015-01-29 18:53:49 +00:00
init_video(p);
vo_opengl: redo aspects of initialization, change hwdec API Instead of checking for resolution and image format changes, always fully reinit on any parameter change. Let init_video do all required initializations, which simplifies things a little bit. Change the gl_video/hardware decoding interop API slightly, so that hwdec initialization gets the full image parameters. Also make some cosmetic changes.
2013-11-05 18:08:44 +00:00
}
vo_opengl: initialize renderer after setting size This silences the warning: video/out/gl_video.c:1091:51: runtime error: division by zero when running with clang -fsanitize=undefined. Division by zero is legal according to IEEE, but I guess clang doesn't care about standard. While triggering this warning isn't actually avoided in all cases, it's avoided in the common case and also makes people shut up about it.
2014-11-07 14:28:12 +00:00
vo_opengl: refactor shader generation (part 2) This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
2015-03-12 21:18:16 +00:00
gl_video_reset_surfaces(p);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
vo_opengl_cb: don't render OSD while VO is not created Unlike other VOs, this rendered OSD even while no VO was created (because the renderer lives as long as the API user wants). Change this, and refactor the code so that the OSD object is accessible only while the VO is created. (There is a short time where the OSD can still be accessed even after VO destruction - this is not a race condition, though it's inelegant and unfortunately unavoidable.)
2015-03-23 15:32:59 +00:00
void gl_video_set_osd_source(struct gl_video *p, struct osd_state *osd)
{
mpgl_osd_destroy(p->osd);
p->osd = NULL;
p->osd_state = osd;
vo_opengl: fix/simplify reinitialization on dynamic reconfiguration With the new hooks mechanism, user shaders and such are actually loaded before rendering starts, instead of being loaded during rendering. This is used to cache them (instead of e.g. reparsing them every frame). The cached state wasn't cleared correctly in some situations. Namely, resizing didn't correctly enable/disable prescale hooks. Reorganize how these reinitializations are handled. Get rid of reinit_rendering(), whose meaning was pretty unclear. Call the required functions to reset or recreate state directly wherever they are needed.
2016-05-18 15:47:10 +00:00
reinit_osd(p);
vo_opengl_cb: don't render OSD while VO is not created Unlike other VOs, this rendered OSD even while no VO was created (because the renderer lives as long as the API user wants). Change this, and refactor the code so that the OSD object is accessible only while the VO is created. (There is a short time where the OSD can still be accessed even after VO destruction - this is not a race condition, though it's inelegant and unfortunately unavoidable.)
2015-03-23 15:32:59 +00:00
}
vo_opengl: further GL API use separation Move multiple GL-specific things from the renderer to other places like vo_opengl.c, vo_opengl_cb.c, and ra_gl.c. The vp_w/vp_h parameters to gl_video_resize() make no sense anymore, and are implicitly part of struct fbodst. Checking the main framebuffer depth is moved to vo_opengl.c. For vo_opengl_cb.c it always assumes 8. The API user now has to override this manually. The previous heuristic didn't make much sense anyway. The only remaining dependency on GL is the hwdec stuff, which is harder to change.
2017-08-07 17:14:18 +00:00
struct gl_video *gl_video_init(struct ra *ra, struct mp_log *log,
struct mpv_global *g)
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
{
struct gl_video *p = talloc_ptrtype(NULL, p);
*p = (struct gl_video) {
vo_opengl: start work on rendering API abstraction This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
2017-07-26 09:19:51 +00:00
.ra = ra,
vo_opengl: add support for custom shaders
2015-03-27 12:27:40 +00:00
.global = g,
video/out: use new mp_msg stuff for vo.c and vo_opengl The first step; also serves as example.
2013-07-31 19:44:21 +00:00
.log = log,
vo_opengl: move shader handling to ra Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
2017-08-05 12:20:14 +00:00
.sc = gl_sc_create(ra, g, log),
video: redo video equalizer option handling I really wouldn't care much about this, but some parts of the core code are under HAVE_GPL, so there's some need to get rid of it. Simply turn the video equalizer from its current fine-grained handling with vf/vo fallbacks into global options. This makes updating them much simpler. This removes any possibility of applying video equalizers in filters, which affects vf_scale, and the previously removed vf_eq. Not a big loss, since the preferred VOs have this builtin. Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and vo_xv. I'm not going to waste my time on these legacy VOs. vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which exists _only_ to trigger a redraw. This seems silly, but for now I feel like this is less of a pain. The rest of the equalizer using code is self-updating. See commit 96b906a51d5 for how some video equalizer code was GPL only. Some command line option names and ranges can probably be traced back to a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
.video_eq = mp_csp_equalizer_create(p, g),
vo_opengl: deprecate sub-options, add them as global options vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
2016-09-02 13:59:40 +00:00
.opts_cache = m_config_cache_alloc(p, g, &gl_video_conf),
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
};
vo_opengl: make the pass info mechanism more robust - 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.
2017-07-03 14:59:38 +00:00
// make sure this variable is initialized to *something*
p->pass = p->pass_fresh;
vo_opengl: simplify option handling Instead of copying the options around... just don't. video.c now has full control over when options are updated. (It still gets notified from outside, but it decides when the updated options are copied: when m_config_cache_update() is called.) So there's no need for tricky stuff, and it can be simplified a bit. Also change lcms.c. We could do it like video.c, and get the options from the global config store. But it seems simpler to just provide a pointer to an option struct, which is arbitrarily mutated from the outside (from the perspective of lcms.c).
2016-09-06 09:11:36 +00:00
struct gl_video_opts *opts = p->opts_cache->opts;
p->cms = gl_lcms_init(p, log, g, opts->icc_opts),
p->opts = *opts;
vo_opengl: add macros for scaler units There was no real point in hard-coding these all over the place, especially since the order was sort of arbitrary and confusing.
2016-03-05 08:42:57 +00:00
for (int n = 0; n < SCALER_COUNT; n++)
p->scaler[n] = (struct scaler){.index = n};
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
// our VAO always has the vec2 position as the first element
MP_TARRAY_APPEND(p, p->vao, p->vao_len, (struct ra_renderpass_input) {
.name = "position",
.type = RA_VARTYPE_FLOAT,
.dim_v = 2,
.dim_m = 1,
.offset = 0,
});
vo_opengl: restore single pass optimization as separate code path The single path optimization, rendering the video in one shader pass and without FBO indirections, was removed soem commits ago. It didn't have a place in this code, and caused considerable complexity and maintenance issues. On the other hand, it still has some worth, such as for use with extremely crappy hardware (GLES only or OpenGL 2.1 without FBO extension). Ideally, these use cases would be handled by a separate VO (say, vo_gles). While cleaner, this would still cause code duplication and other complexity. The third option is making the single-pass optimization a completely separate code path, with most vo_opengl features disabled. While this does duplicate some functionality (such as "unpacking" the video data from textures), it's also relatively unintrusive, and the high quality code path doesn't need to take it into account at all. On another positive node, this "dumb-mode" could be forced in other cases where OpenGL 2.1 is not enough, and where we don't want to care about versions this old.
2015-09-07 19:09:06 +00:00
init_gl(p);
vo_opengl: fix --icc-profile initial behavior Setting --icc-profile had no effect, until a vo_opengl option was changed at runtime. We must initialize the renderer for the initial option state too. For some reason, the ICC profile gets loaded twice. The next commit happens to fix this.
2016-09-06 09:11:23 +00:00
reinit_from_options(p);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
return p;
}
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
// Get static string for scaler shader. If "tscale" is set to true, the
// scaler must be a separable convolution filter.
static const char *handle_scaler_opt(const char *name, bool tscale)
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
{
vo_opengl: make "mitchell" the hq default filter for downscaling Seems like several people agree that it's a good filter for downscaling. Setting this option by default may also prevent people from accidentally using an unsuitable filter for downscaling by setting "scale" and without being aware of the impliciations (maybe). On the other hand, this change is not strictly backwards compatible for the same reasons. Also, allow disabling this option with scale-down="" (before this, not setting it was the only way to do this - not possible anymore if it's set by default). This is what the change in handle_scaler_opt() does.
2015-01-26 01:03:44 +00:00
if (name && name[0]) {
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
const struct filter_kernel *kernel = mp_find_filter_kernel(name);
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
if (kernel && (!tscale || !kernel->polar))
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
return kernel->f.name;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: add oversample support for tscale This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
2015-03-15 06:11:51 +00:00
for (const char *const *filter = tscale ? fixed_tscale_filters
: fixed_scale_filters;
*filter; filter++) {
if (strcmp(*filter, name) == 0)
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
return *filter;
}
}
return NULL;
}
vo_gpu: fix video sometimes not being rerendered on equalizer change With video paused, changing the brightness controls (or similar) would sometimes not rerender the video frame. So the OSD would redraw, but the video wouldn't change. This is caused by output caching, and a redraw request is free to return the cached frame. Change it such to invalidate the cached frame if any of the options or the equalizer change. In theory, gl_video_reset_surfaces() could be called if the equalizer changes - this would apparently force interpolatzion to redraw all frames. But this looks kind of crappy when changing the equalizer during playback. It'll "eventually" use the correct settings anyway, and when paused interpolation is off.
2017-10-17 07:07:35 +00:00
static void gl_video_update_options(struct gl_video *p)
vo_opengl: move gl_video_opts copying code to separate function Sigh... Hopefully this code will be completely unnecessary one day, as it's only needed due to the sub-option parser craziness. Move dumb_mode to the top of the struct, so the C universal initializer doesn't cause warnings with all those broken compilers.
2015-09-08 20:46:36 +00:00
{
vo_opengl: deprecate sub-options, add them as global options vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
2016-09-02 13:59:40 +00:00
if (m_config_cache_update(p->opts_cache)) {
vo_opengl: simplify option handling Instead of copying the options around... just don't. video.c now has full control over when options are updated. (It still gets notified from outside, but it decides when the updated options are copied: when m_config_cache_update() is called.) So there's no need for tricky stuff, and it can be simplified a bit. Also change lcms.c. We could do it like video.c, and get the options from the global config store. But it seems simpler to just provide a pointer to an option struct, which is arbitrarily mutated from the outside (from the perspective of lcms.c).
2016-09-06 09:11:36 +00:00
gl_lcms_update_options(p->cms);
vo_opengl: deprecate sub-options, add them as global options vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
2016-09-02 13:59:40 +00:00
reinit_from_options(p);
}
vo_gpu: fix video sometimes not being rerendered on equalizer change With video paused, changing the brightness controls (or similar) would sometimes not rerender the video frame. So the OSD would redraw, but the video wouldn't change. This is caused by output caching, and a redraw request is free to return the cached frame. Change it such to invalidate the cached frame if any of the options or the equalizer change. In theory, gl_video_reset_surfaces() could be called if the equalizer changes - this would apparently force interpolatzion to redraw all frames. But this looks kind of crappy when changing the equalizer during playback. It'll "eventually" use the correct settings anyway, and when paused interpolation is off.
2017-10-17 07:07:35 +00:00
if (mp_csp_equalizer_state_changed(p->video_eq))
p->output_tex_valid = false;
vo_opengl: cleanup icc + runtime option changing behavior Commit 026b75e7 actually enabled changing icc options at runtime (via vo_cmdline), but it didn't quite work. In particular, changing the icc- profile option just kept the old profile, because it was cached accordingly. As part of this, change gl_lcms.opts from a struct to a pointer to a struct. We properly copy it, instead of allowing possibly dangling strings, like it was done in a working but unclean way before. Also, reinit the whole rendering chain when the auto icc profile changes, just like it's done when icc options are changed.
2016-06-04 15:52:10 +00:00
}
static void reinit_from_options(struct gl_video *p)
{
vo_opengl: somewhat simplify suboption handling mess Enable m_sub_options_copy() to copy nested sub-options, and also enable it to create an option struct from defaults. We can get rid of most of the crap in assign_options() now. Calling handle_scaler_opt() to get a static allocation for scaler name is still needed. It's moved to reinit_scaler(), which seems to be a better place for it. Without it, dangling pointers could be created when options are changed. (And in fact, this fixes possible dangling pointers for window.name.) In theory we could create a dynamic copy, but that seemed even more messy. Chance of regressions.
2016-06-04 18:48:56 +00:00
p->use_lut_3d = gl_lcms_has_profile(p->cms);
vo_opengl: move all icc handling from vo_opengl.c to video.c Originally, video.c did not access any CMS things (other than lut3d being set on it), but this has changed. In practice, almost all accesses to it have moved to video.c. vo_opengl only created it, and set the auto icc profile path. Complete the move. Some things wrt. option handling are a bit fishy. (But when is this not the case.) icc-profile-auto was not tested, but the distributed human CI will take care of it.
2016-06-03 18:35:17 +00:00
vo_opengl: simplify option handling Instead of copying the options around... just don't. video.c now has full control over when options are updated. (It still gets notified from outside, but it decides when the updated options are copied: when m_config_cache_update() is called.) So there's no need for tricky stuff, and it can be simplified a bit. Also change lcms.c. We could do it like video.c, and get the options from the global config store. But it seems simpler to just provide a pointer to an option struct, which is arbitrarily mutated from the outside (from the perspective of lcms.c).
2016-09-06 09:11:36 +00:00
// Copy the option fields, so that check_gl_features() can mutate them.
// This works only for the fields themselves of course, not for any memory
// referenced by them.
p->opts = *(struct gl_video_opts *)p->opts_cache->opts;
rpi: fix build Runtime untested, because I get this: [vo/rpi] Could not get DISPMANX objects. This happened even when building older git versions, and on a RPI image that hasn't changed in the recent years. I don't know how to make this POS work again, so I guess if there's a bug in the new code, it will remain broken.
2017-08-11 11:02:13 +00:00
if (!p->force_clear_color)
p->clear_color = p->opts.background;
vo_opengl: refactor queue configuration Just avoid some code duplication. Also, gl_video_set_options() having a queue size output parameter is weird at best. While I don't appreciate that this commit suddenly requires gl_video.c to deal with vo.c directly in a special case, it's simply the best place to put this function.
2015-07-16 20:43:40 +00:00
check_gl_features(p);
uninit_rendering(p);
vo_opengl: move shader handling to ra Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
2017-08-05 12:20:14 +00:00
gl_sc_set_cache_dir(p->sc, p->opts.shader_cache_dir);
vo_opengl: refactor tex_upload to ra_buf_pool Also refactors the usage of tex_upload to make ra_tex_upload_pbo a RA-internal thing again. ra_buf_pool has the main advantage of being dynamically sized depending on buf_poll, so for OpenGL we'll end up only using one buffer (when not persistently mapping) - while for vulkan we'll use as many as necessary, which depends on the swapchain depth anyway.
2017-08-19 02:33:40 +00:00
p->ra->use_pbo = p->opts.pbo;
vo_opengl: fix/simplify reinitialization on dynamic reconfiguration With the new hooks mechanism, user shaders and such are actually loaded before rendering starts, instead of being loaded during rendering. This is used to cache them (instead of e.g. reparsing them every frame). The cached state wasn't cleared correctly in some situations. Namely, resizing didn't correctly enable/disable prescale hooks. Reorganize how these reinitializations are handled. Get rid of reinit_rendering(), whose meaning was pretty unclear. Call the required functions to reset or recreate state directly wherever they are needed.
2016-05-18 15:47:10 +00:00
gl_video_setup_hooks(p);
reinit_osd(p);
vo_opengl: warn if interpolation is enabled, but not display-sync Try to avoid user confusion. Reading the global options in this place is a pretty disgusting hack, but it's still the most robust way.
2015-11-28 18:59:11 +00:00
if (p->opts.interpolation && !p->global->opts->video_sync && !p->dsi_warned) {
MP_WARN(p, "Interpolation now requires enabling display-sync mode.\n"
"E.g.: --video-sync=display-resample\n");
p->dsi_warned = true;
}
vo_opengl: refactor queue configuration Just avoid some code duplication. Also, gl_video_set_options() having a queue size output parameter is weird at best. While I don't appreciate that this commit suddenly requires gl_video.c to deal with vo.c directly in a special case, it's simply the best place to put this function.
2015-07-16 20:43:40 +00:00
}
void gl_video_configure_queue(struct gl_video *p, struct vo *vo)
{
vo_gpu: fix video sometimes not being rerendered on equalizer change With video paused, changing the brightness controls (or similar) would sometimes not rerender the video frame. So the OSD would redraw, but the video wouldn't change. This is caused by output caching, and a redraw request is free to return the cached frame. Change it such to invalidate the cached frame if any of the options or the equalizer change. In theory, gl_video_reset_surfaces() could be called if the equalizer changes - this would apparently force interpolatzion to redraw all frames. But this looks kind of crappy when changing the equalizer during playback. It'll "eventually" use the correct settings anyway, and when paused interpolation is off.
2017-10-17 07:07:35 +00:00
gl_video_update_options(p);
vo: minor simplification for queue size handling Instead of calling it "future frames" and adding or subtracting 1 from it, always call it "requested frames". This simplifies it a bit. MPContext.next_frames had 2 added to it; this was mainly to ensure a minimum size of 2. Drop it and assume VO_MAX_REQ_FRAMES is at least 2; together with the other changes, this can be the exact size of the array.
2015-07-20 19:12:46 +00:00
int queue_size = 1;
vo_opengl: refactor queue configuration Just avoid some code duplication. Also, gl_video_set_options() having a queue size output parameter is weird at best. While I don't appreciate that this commit suddenly requires gl_video.c to deal with vo.c directly in a special case, it's simply the best place to put this function.
2015-07-16 20:43:40 +00:00
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
// Figure out an adequate size for the interpolation queue. The larger
vo_opengl: adjust interpolation code for the new video-sync mechanism This should make interpolation work much better in general, although there still might be some side effects for unusual framerates (eg. 35 Hz or 48 Hz). Most of the common framerates are tested and working fine. (24 Hz, 30 Hz, 60 Hz) The new code doesn't have support for oversample yet, so it's been removed (and will most likely be reimplemented in a cleaner way if there's enough demand). I would recommend using something like robidoux or mitchell instead of oversample, though - they're much smoother for the common cases.
2015-06-26 08:59:57 +00:00
// the radius, the earlier we need to queue frames.
vo_opengl: refactor queue configuration Just avoid some code duplication. Also, gl_video_set_options() having a queue size output parameter is weird at best. While I don't appreciate that this commit suddenly requires gl_video.c to deal with vo.c directly in a special case, it's simply the best place to put this function.
2015-07-16 20:43:40 +00:00
if (p->opts.interpolation) {
vo_opengl: refactor scaler configuration This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
const struct filter_kernel *kernel =
vo_opengl: add macros for scaler units There was no real point in hard-coding these all over the place, especially since the order was sort of arbitrary and confusing.
2016-03-05 08:42:57 +00:00
mp_find_filter_kernel(p->opts.scaler[SCALER_TSCALE].kernel.name);
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
if (kernel) {
filter_kernels: Keep f.radius in terms of dest/filter coords. The existing code modifies f.radius so that it is in terms of the filter sample radius (in the source coordinate space) and has some small errors because of this behavior. This commit changes f.radius so that it is always in terms of the filter function radius (in the destination coordinate space). The sample radius can always be derived by multiplying f.radius by filter_scale, which is the new, more descriptive name for the previous inv_scale.
2017-03-05 01:13:18 +00:00
// filter_scale wouldn't be correctly initialized were we to use it here.
// This is fine since we're always upsampling, but beware if downsampling
// is added!
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
double radius = kernel->f.radius;
vo_opengl: add macros for scaler units There was no real point in hard-coding these all over the place, especially since the order was sort of arbitrary and confusing.
2016-03-05 08:42:57 +00:00
radius = radius > 0 ? radius : p->opts.scaler[SCALER_TSCALE].radius;
vo: minor simplification for queue size handling Instead of calling it "future frames" and adding or subtracting 1 from it, always call it "requested frames". This simplifies it a bit. MPContext.next_frames had 2 added to it; this was mainly to ensure a minimum size of 2. Drop it and assume VO_MAX_REQ_FRAMES is at least 2; together with the other changes, this can be the exact size of the array.
2015-07-20 19:12:46 +00:00
queue_size += 1 + ceil(radius);
vo_opengl: reimplement tscale=oversample Closes #2102.
2015-07-11 11:55:45 +00:00
} else {
vo_opengl: add a tscale=linear direct implementation This uses GLSL mix() instead of going through an indirect texture access. Easy to implement and might require less resources on some devices, since the oversample code was already essentially just a special case of this. Could be made the new default (as per issue #2685), but that should be done in a separate commit.
2016-07-19 18:12:33 +00:00
// Oversample/linear case
vo: minor simplification for queue size handling Instead of calling it "future frames" and adding or subtracting 1 from it, always call it "requested frames". This simplifies it a bit. MPContext.next_frames had 2 added to it; this was mainly to ensure a minimum size of 2. Drop it and assume VO_MAX_REQ_FRAMES is at least 2; together with the other changes, this can be the exact size of the array.
2015-07-20 19:12:46 +00:00
queue_size += 2;
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
}
}
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
vo_opengl: disable interpolation without display-sync Without display-sync mode, our guesses wrt. vsync phase etc. are much worse, and I see no reason to keep the complicated "vsync_timed" code.
2015-11-25 21:10:55 +00:00
vo_set_queue_params(vo, 0, queue_size);
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
m_option: add mp_log callback to OPT_STRING_VALIDATE options And also convert a bunch of other code, especially ao_wasapi and ao_portaudio.
2013-12-21 19:03:36 +00:00
static int validate_scaler_opt(struct mp_log *log, const m_option_t *opt,
struct bstr name, struct bstr param)
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
{
vo_opengl: improve terminal messages with lscale suboption errors Make it more apparent what the hell the user did wrong.
2015-01-22 18:58:22 +00:00
char s[20] = {0};
int r = 1;
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
bool tscale = bstr_equals0(name, "tscale");
vo_opengl: some option changes Doing "mpv --vo=opengl:lscale=help" now lists possible scalers and exits. The "backend" suboption behaves similar. Make the "stereo" suboption a choice, instead of using magic integer values.
2013-07-22 00:14:15 +00:00
if (bstr_equals0(param, "help")) {
options: simplify M_OPT_EXIT There were multiple values under M_OPT_EXIT (M_OPT_EXIT-n for n>=0). Somehow M_OPT_EXIT-n either meant error code n (with n==0 no error?), or the number of option valus consumed (0 or 1). The latter is MPlayer legacy, which left it to the option type parsers to determine whether an option took a value or not. All of this was changed in mpv, by requiring the user to use explicit syntax ("--opt=val" instead of "-opt val"). In any case, the n value wasn't even used (anymore), so rip this all out. Now M_OPT_EXIT-1 doesn't mean anything, and could be used by a new error code.
2016-09-17 16:07:40 +00:00
r = M_OPT_EXIT;
vo_opengl: improve terminal messages with lscale suboption errors Make it more apparent what the hell the user did wrong.
2015-01-22 18:58:22 +00:00
} else {
snprintf(s, sizeof(s), "%.*s", BSTR_P(param));
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
if (!handle_scaler_opt(s, tscale))
vo_opengl: improve terminal messages with lscale suboption errors Make it more apparent what the hell the user did wrong.
2015-01-22 18:58:22 +00:00
r = M_OPT_INVALID;
}
if (r < 1) {
m_option: add mp_log callback to OPT_STRING_VALIDATE options And also convert a bunch of other code, especially ao_wasapi and ao_portaudio.
2013-12-21 19:03:36 +00:00
mp_info(log, "Available scalers:\n");
vo_opengl: add oversample support for tscale This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
2015-03-15 06:11:51 +00:00
for (const char *const *filter = tscale ? fixed_tscale_filters
: fixed_scale_filters;
*filter; filter++) {
mp_info(log, " %s\n", *filter);
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
}
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
for (int n = 0; mp_filter_kernels[n].f.name; n++) {
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
if (!tscale || !mp_filter_kernels[n].polar)
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
mp_info(log, " %s\n", mp_filter_kernels[n].f.name);
vo_opengl: refactor smoothmotion -> interpolation This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
2015-03-13 18:30:31 +00:00
}
vo_opengl: improve terminal messages with lscale suboption errors Make it more apparent what the hell the user did wrong.
2015-01-22 18:58:22 +00:00
if (s[0])
mp_fatal(log, "No scaler named '%s' found!\n", s);
vo_opengl: some option changes Doing "mpv --vo=opengl:lscale=help" now lists possible scalers and exits. The "backend" suboption behaves similar. Make the "stereo" suboption a choice, instead of using magic integer values.
2013-07-22 00:14:15 +00:00
}
vo_opengl: improve terminal messages with lscale suboption errors Make it more apparent what the hell the user did wrong.
2015-01-22 18:58:22 +00:00
return r;
vo_opengl: split into multiple files, convert to new option API gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
2013-03-01 20:19:20 +00:00
}
add a way to resize window contents without VO resize gl_video_resize_redraw() simply resizes and redraws (but without invoking swapGlBuffers()). The VO is not involved in any way, so this can simply be called from inside the mpgl lock from any thread. Requires a minor refactor of the GL OSD code in order to redraw without an OSD object.
2013-03-15 19:17:33 +00:00
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
static int validate_window_opt(struct mp_log *log, const m_option_t *opt,
struct bstr name, struct bstr param)
{
char s[20] = {0};
int r = 1;
if (bstr_equals0(param, "help")) {
options: simplify M_OPT_EXIT There were multiple values under M_OPT_EXIT (M_OPT_EXIT-n for n>=0). Somehow M_OPT_EXIT-n either meant error code n (with n==0 no error?), or the number of option valus consumed (0 or 1). The latter is MPlayer legacy, which left it to the option type parsers to determine whether an option took a value or not. All of this was changed in mpv, by requiring the user to use explicit syntax ("--opt=val" instead of "-opt val"). In any case, the n value wasn't even used (anymore), so rip this all out. Now M_OPT_EXIT-1 doesn't mean anything, and could be used by a new error code.
2016-09-17 16:07:40 +00:00
r = M_OPT_EXIT;
vo_opengl: separate kernel and window This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
} else {
snprintf(s, sizeof(s), "%.*s", BSTR_P(param));
const struct filter_window *window = mp_find_filter_window(s);
if (!window)
r = M_OPT_INVALID;
}
if (r < 1) {
mp_info(log, "Available windows:\n");
for (int n = 0; mp_filter_windows[n].name; n++)
mp_info(log, " %s\n", mp_filter_windows[n].name);
if (s[0])
mp_fatal(log, "No window named '%s' found!\n", s);
}
return r;
}
vo_opengl: add gamma-auto option This automatically sets the gamma option depending on lighting conditions measured from the computer's ambient light sensor. sRGB – arguably the “sibling” to BT.709 for still images – has a reference viewing environment defined in its specification (IEC 61966-2-1:1999, see http://www.color.org/chardata/rgb/srgb.xalter). According to this data, the assumed ambient illuminance is 64 lux. This is the illuminance where the gamma that results from ICC color management is correct. On the other hand, BT.1886 formalizes that the gamma level for dim environments to be 2.40, and Apple resources (WWDC12: 2012 Session 523: Best practices for color management) define the BT.1886 dim at 16 lux. So the logic we apply is: * >= 64lux -> 1.961 gamma * =< 16lux -> 2.400 gamma * 16lux < x < 64lux -> logaritmic rescale of lux to gamma. The human perception of illuminance roughly follows a logaritmic scale of lux [1]. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/dd319008%28v=vs.85%29.aspx
2015-02-07 12:54:18 +00:00
float gl_video_scale_ambient_lux(float lmin, float lmax,
float rmin, float rmax, float lux)
{
assert(lmax > lmin);
float num = (rmax - rmin) * (log10(lux) - log10(lmin));
float den = log10(lmax) - log10(lmin);
float result = num / den + rmin;
// clamp the result
float max = MPMAX(rmax, rmin);
float min = MPMIN(rmax, rmin);
return MPMAX(MPMIN(result, max), min);
}
void gl_video_set_ambient_lux(struct gl_video *p, int lux)
{
if (p->opts.gamma_auto) {
vo_gpu: fix gamma scale This never really made sense since the BT.1886 changes. It should get *brighter* for bright rooms, not darker for dark rooms. Picked some new values that seemed reasonable-ish.
2017-09-19 04:35:24 +00:00
p->opts.gamma = gl_video_scale_ambient_lux(16.0, 256.0, 1.0, 1.2, lux);
msg: reinterpret a bunch of message levels I've decided that MP_TRACE means “noisy spam per frame”, whereas MP_DBG just means “more verbose debugging messages than MSGL_V”. Basically, MSGL_DBG shouldn't create spam per frame like it currently does, and MSGL_V should make sense to the end-user and provide mostly additional informational output. MP_DBG is basically what I want to make the new default for --log-file, so the cut-off point for MP_DBG is if we probably want to know if for debugging purposes but the user most likely doesn't care about on the terminal. Also, the debug callbacks for libass and ffmpeg got bumped in their verbosity levels slightly, because being external components they're a bit less relevant to mpv debugging, and a bit too over-eager in what they consider to be relevant information. I exclusively used the "try it on my machine and remove messages from MSGL_* until it does what I want it to" approach of refactoring, so YMMV.
2017-09-28 09:53:57 +00:00
MP_TRACE(p, "ambient light changed: %d lux (gamma: %f)\n", lux,
p->opts.gamma);
vo_opengl: add gamma-auto option This automatically sets the gamma option depending on lighting conditions measured from the computer's ambient light sensor. sRGB – arguably the “sibling” to BT.709 for still images – has a reference viewing environment defined in its specification (IEC 61966-2-1:1999, see http://www.color.org/chardata/rgb/srgb.xalter). According to this data, the assumed ambient illuminance is 64 lux. This is the illuminance where the gamma that results from ICC color management is correct. On the other hand, BT.1886 formalizes that the gamma level for dim environments to be 2.40, and Apple resources (WWDC12: 2012 Session 523: Best practices for color management) define the BT.1886 dim at 16 lux. So the logic we apply is: * >= 64lux -> 1.961 gamma * =< 16lux -> 2.400 gamma * 16lux < x < 64lux -> logaritmic rescale of lux to gamma. The human perception of illuminance roughly follows a logaritmic scale of lux [1]. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/dd319008%28v=vs.85%29.aspx
2015-02-07 12:54:18 +00:00
}
}
vo_opengl: remove DR image layouting code to renderer No reason to have it in a higher level.
2017-08-14 17:57:44 +00:00
static void *gl_video_dr_alloc_buffer(struct gl_video *p, size_t size)
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
{
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
struct ra_buf_params params = {
.type = RA_BUF_TYPE_TEX_UPLOAD,
.host_mapped = true,
.size = size,
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
};
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
struct ra_buf *buf = ra_buf_create(p->ra, &params);
if (!buf)
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
return NULL;
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
MP_TARRAY_GROW(p, p->dr_buffers, p->num_dr_buffers);
p->dr_buffers[p->num_dr_buffers++] = (struct dr_buffer){ .buf = buf };
return buf->data;
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
};
vo_opengl: remove DR image layouting code to renderer No reason to have it in a higher level.
2017-08-14 17:57:44 +00:00
static void gl_video_dr_free_buffer(void *opaque, uint8_t *data)
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
{
vo_opengl: remove DR image layouting code to renderer No reason to have it in a higher level.
2017-08-14 17:57:44 +00:00
struct gl_video *p = opaque;
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
for (int n = 0; n < p->num_dr_buffers; n++) {
struct dr_buffer *buffer = &p->dr_buffers[n];
vo_opengl: remove DR image layouting code to renderer No reason to have it in a higher level.
2017-08-14 17:57:44 +00:00
if (buffer->buf->data == data) {
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
assert(!buffer->mpi); // can't be freed while it has a ref
vo_opengl: generalize ra_buf to support other buffer objects This allows us to integrate PBOs and SSBOs into the same abstraction, with the potential to easily add UBOs if the need arises.
2017-08-05 20:29:48 +00:00
ra_buf_free(p->ra, &buffer->buf);
vo_opengl: add direct rendering support 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).
2017-07-23 07:41:51 +00:00
MP_TARRAY_REMOVE_AT(p->dr_buffers, p->num_dr_buffers, n);
return;
}
}
// not found - must not happen
assert(0);
}
vo_opengl: remove DR image layouting code to renderer No reason to have it in a higher level.
2017-08-14 17:57:44 +00:00
struct mp_image *gl_video_get_image(struct gl_video *p, int imgfmt, int w, int h,
int stride_align)
{
vo_gpu: skip DR for unsupported image formats DR (direct rendering) works by having the decoder decode into the GPU staging buffers, instead of copying the video data on texture upload. We did this even for formats unsupported by the GPU or the renderer. This "worked" because the staging memory is untyped, and the video frame was converted by libswscale to a supported format, and then uploaded with a copy using the normal non-DR texture upload path. Even though it "works", we don't gain anything from using the staging buffers for decoding, since we can't use them for upload anyway. Also, staging memory might be potentially limited (what really happens is up to the driver). It's easy to avoid, so just skip it in these cases.
2018-01-17 10:49:55 +00:00
if (!gl_video_check_format(p, imgfmt))
return NULL;
vo_opengl: remove DR image layouting code to renderer No reason to have it in a higher level.
2017-08-14 17:57:44 +00:00
int size = mp_image_get_alloc_size(imgfmt, w, h, stride_align);
if (size < 0)
return NULL;
int alloc_size = size + stride_align;
void *ptr = gl_video_dr_alloc_buffer(p, alloc_size);
if (!ptr)
return NULL;
// (we expect vo.c to proxy the free callback, so it happens in the same
// thread it was allocated in, removing the need for synchronization)
struct mp_image *res = mp_image_from_buffer(imgfmt, w, h, stride_align,
ptr, alloc_size, p,
gl_video_dr_free_buffer);
if (!res)
gl_video_dr_free_buffer(p, ptr);
return res;
}
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
static void load_add_hwdec(struct gl_video *p, struct mp_hwdec_devices *devs,
const struct ra_hwdec_driver *drv, bool is_auto)
{
struct ra_hwdec *hwdec =
ra_hwdec_load_driver(p->ra, p->log, p->global, devs, drv, is_auto);
if (hwdec)
MP_TARRAY_APPEND(p, p->hwdecs, p->num_hwdecs, hwdec);
}
void gl_video_load_hwdecs(struct gl_video *p, struct mp_hwdec_devices *devs,
bool load_all_by_default)
{
char *type = p->opts.hwdec_interop;
if (!type || !type[0] || strcmp(type, "auto") == 0) {
if (!load_all_by_default)
return;
type = "all";
}
if (strcmp(type, "no") == 0) {
// do nothing, just block further loading
} else if (strcmp(type, "all") == 0) {
video: remove code duplication by calling a hwdec loader helper Make gl_video_load_hwdecs() call gl_video_load_hwdecs_all() when all HW decoders should be loaded.
2017-12-10 21:56:29 +00:00
gl_video_load_hwdecs_all(p, devs);
vo_gpu: make it possible to load multiple hwdec interop drivers Make the VO<->decoder interface capable of supporting multiple hwdec APIs at once. The main gain is that this simplifies autoprobing a lot. Before this change, it could happen that the VO loaded the "wrong" hwdec API, and the decoder was stuck with the choice (breaking hw decoding). With the change applied, the VO simply loads all available APIs, so autoprobing trickery is left entirely to the decoder. In the past, we were quite careful about not accidentally loading the wrong interop drivers. This was in part to make sure autoprobing works, but also because libva had this obnoxious bug of dumping garbage to stderr when using the API. libva was fixed, so this is not a problem anymore. The --opengl-hwdec-interop option is changed in various ways (again...), and renamed to --gpu-hwdec-interop. It does not have much use anymore, other than debugging. It's notable that the order in the hwdec interop array ra_hwdec_drivers[] still matters if multiple drivers support the same image formats, so the option can explicitly force one, if that should ever be necessary, or more likely, for debugging. One example are the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both support d3d11 input. vo_gpu now always loads the interop lazily by default, but when it does, it loads them all. vo_opengl_cb now always loads them when the GL context handle is initialized. I don't expect that this causes any problems. It's now possible to do things like changing between vdpau and nvdec decoding at runtime. This is also preparation for cleaning up vd_lavc.c hwdec autoprobing. It's another reason why hwdec_devices_request_all() does not take a hwdec type anymore.
2017-12-01 04:05:00 +00:00
} else {
for (int n = 0; ra_hwdec_drivers[n]; n++) {
const struct ra_hwdec_driver *drv = ra_hwdec_drivers[n];
if (strcmp(type, drv->name) == 0) {
load_add_hwdec(p, devs, drv, false);
break;
}
}
}
p->hwdec_interop_loading_done = true;
}
void gl_video_load_hwdecs_all(struct gl_video *p, struct mp_hwdec_devices *devs)
{
if (!p->hwdec_interop_loading_done) {
for (int n = 0; ra_hwdec_drivers[n]; n++)
load_add_hwdec(p, devs, ra_hwdec_drivers[n], true);
p->hwdec_interop_loading_done = true;
}
}
Reference in New Issue Copy Permalink