summaryrefslogtreecommitdiffstats
path: root/video/out/opengl/video.c
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: always use GL_TRIANGLES for all primitiveswm42017-08-051-2/+5
| | | | Will make the ra layer _slightly_ simpler.
* vo_opengl: pass ra objects during rendering instead of GL objectswm42017-08-051-139/+91
| | | | | | | | | 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.
* vo_opengl: make fbotex helper use rawm42017-08-051-47/+52
| | | | | | | | 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.
* vo_opengl: support embedded ICC profilesNiklas Haas2017-08-031-2/+6
| | | | | | | | | | | | | | | | 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_)
* vo_opengl: don't precompute texcoord in global scopeNiklas Haas2017-08-031-1/+1
| | | | | | | | | | | 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)
* vo_opengl: make compute shaders more flexibleNiklas Haas2017-08-031-25/+32
| | | | | | 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.
* vo_opengl: simplify/fix user shader textureswm42017-08-031-24/+4
| | | | | | | | | | | | | | | | | | | | 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.
* vo_opengl: generalize HDR tone mapping to gamut mappingNiklas Haas2017-08-031-4/+5
| | | | | | | | | | | | | | | | | | | | | | 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.
* vo_opengl: manage user shader textures with rawm42017-07-301-31/+16
| | | | | Drops some features I guess, no idea if those were needed. Untested due to lack of test cases.
* vo_opengl: fix dither texture filterwm42017-07-301-1/+0
| | | | Should be GL_NEAREST, not GL_LINEAR.
* vo_opengl: manage ICC LUT texture via rawm42017-07-291-28/+25
| | | | | Also move the capability check to gl_video_get_lut3d(), because it seems more convenient (ra won't have a _CAP_EXT16).
* vo_opengl: manage scaler LUT textures via rawm42017-07-291-33/+16
| | | | Also fix the RA_CAP_ bitmask nonsense.
* vo_opengl: manage dither texture via rawm42017-07-291-30/+23
| | | | | | | | | 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.
* vo_opengl: do not use GL format conversion on texture uploadwm42017-07-291-16/+16
| | | | | | | | | | | | | | | | | | 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.
* vo_opengl: use ra_* for format negotiation toowm42017-07-291-23/+4
| | | | | | | | | | | | | 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.
* vo_opengl: support loading custom user texturesNiklas Haas2017-07-271-58/+145
| | | | | | | | | | | 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.
* vo_opengl: slightly refactor user_shaders codeNiklas Haas2017-07-271-63/+44
| | | | | | | | | | | | | | - 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.
* vo_opengl: fix mpgl_caps bit checkNiklas Haas2017-07-271-1/+1
| | | | | As pointed out by @bjin, this would match if _any_ of the reqs are set. Need to test for explicit equality.
* vo_opengl: start work on rendering API abstractionwm42017-07-261-121/+85
| | | | | | | | | | | | | | | | | | | | | | 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.
* vo_opengl: describe the texture uploading modeNiklas Haas2017-07-261-1/+2
| | | | | Be a bit more transparent here, which is especially helpful when people are sending me screenshots of stats pages.
* vo_opengl: check against shmem limitsNiklas Haas2017-07-261-15/+45
| | | | | | 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.
* vo_opengl: cosmetic changeNiklas Haas2017-07-251-8/+6
|
* vo_opengl: kill off FBOTEX_COMPUTE againNiklas Haas2017-07-251-5/+1
| | | | | | | | | | | The textures not having an FBO actually caused regressions when trying to render the subtitles on top of this texture (--blend-subtitles), which still relied on an FBO. So just kill off the logic entirely. Why worry about a single FBO wasted when we're allocating like 10 anyway. Fixes #4657.
* vo_opengl: fix incoherent SSBO usageNiklas Haas2017-07-251-0/+1
| | | | | | | According to the OpenGL spec, atomic access to SSBO variables is *not* guaranteed to be coherent, even when reusing the same SSBO attached to the same shader across different frames. So we actually need a glMemoryBarrier here, at least in theory.
* vo_opengl: fix incoherent texture usageNiklas Haas2017-07-251-0/+1
| | | | | | | | | This bug slipped past my attention because nvidia ignores memory barriers, but this is not necessarily always the case. Since image_load_store is incoherent (specifically, writing to images from compute shaders is incoherent) we need to insert a memory barrier to make it coherent again. Since we only care about texture fetches, that's the only barrier we need.
* vo_opengl: adjust the rules for linearizationNiklas Haas2017-07-241-20/+41
| | | | | | | | | | | | | | | | | | 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
* vo_opengl: enable compute shader for mesaBin Jin2017-07-251-4/+7
| | | | | | | | | Mesa 17.1 supports compute shader but not full specs of OpenGL 4.3. Change the code to detect OpenGL extension "GL_ARB_compute_shader" rather than OpenGL version 4.3. HDR peak detection requires SSBO, and polar scaler requires 2D array extension. Add these extensions as requirement as well.
* vo_opengl: support user compute shadersNiklas Haas2017-07-241-0/+2
| | | | | These are identical to regular fragment shader hooks, but with extra metadata indicating the preferred block size.
* vo_opengl: implement compute shader based EWA kernelNiklas Haas2017-07-241-1/+15
| | | | | | | | | | | This performs almost 50% faster on my machine (!!), from 4650μs down to about 3176μs for ewa_lanczossharp. It's possible we could use a similar approach to speed up the separable scalers, although with vastly simpler code. For separable scalers we'd also have the additional huge benefit of only needing padding in one direction, so we could potentially use a big 256x1 kernel or something to essentially compute an entire row at once.
* vo_opengl: support HDR peak detectionNiklas Haas2017-07-241-1/+56
| | | | | | | | | | | | | | 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.
* vo_opengl: support compute shadersNiklas Haas2017-07-241-4/+89
| | | | | | | | 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.
* vo_opengl: cut down on FBOTEX_FUZZY abuseNiklas Haas2017-07-241-4/+2
| | | | | | | | Don't use FBOTEX_FUZZY where the FBO is sized according to p->texture_w/h, since this changes infrequently (and when it does, we need to reset everything anyway). No real reason to make this change other than that it possibly prevents nasty surprises in the future, so I feel more comfortable about it.
* common, vo_opengl: add/use helper for formatted strings on the stackwm42017-07-241-8/+4
| | | | | | | | | | | Seems like I really like this C99 idiom. No reason not to generalize it do snprintf(). Introduce mp_tprintf(), which basically this idiom to snprintf(). This macro looks like it returns a string that was allocated with alloca() on the caller site, except it's portable C99/C11. (And unlike alloca(), the result is valid only within block scope.) Use it in 2 places in the vo_opengl code. But it has the potential to make a whole bunch of weird looking code look slightly nicer.
* vo_opengl: add direct rendering supportwm42017-07-241-4/+151
| | | | | | | | | | | | | | | | | | | | Can be enabled via --vd-lavc-dr=yes. See manpage additions for what it does. This reminds of the MPlayer -dr flag, but the implementation is completely different. It's the same basic concept: letting the decoder render into a GPU buffer to avoid a copy. Unlike MPlayer, this doesn't try to go through filters (libavfilter doesn't support this anyway). Unless a filter can work in-place, DR will be silently disabled. MPlayer had very complex semantics about buffer types and management (which apparently nobody ever understood) and weird restrictions that mostly limited it to mpeg2 style codecs. The mpv code does not do any of this, and just lets the decoder allocate an arbitrary number of untyped images. (No MPlayer code was used.) Parts of the code based on work by atomnuker (starting point for the generic code) and haasn (some GL definitions, some basic PBO code, and correct fencing).
* vo_opengl: add printf format checking to pass_describe()wm42017-07-221-0/+1
|
* vo_opengl: osd: use new VAO mechanismwm42017-07-221-22/+4
| | | | | | | In addition to using the new VAO mechanism introduced in the previous commit, this tries to keep the OSD code self-contained. This doesn't work all too well (because of the pass and CMS stuff), but it's still better than before.
* vo_opengl: add mechanism to create/cache VAO on the flywm42017-07-221-10/+3
| | | | | | This removes VAO handling from video.c. Instead the shader cache will create the VAO as needed. The consequence is that this creates a VAO per shader, which might be a bit wasteful, but doesn't matter anyway.
* vo_opengl: osd: refactor and simplifywm42017-07-221-1/+2
| | | | | | | | Reduce this to 1 draw call per OSD pass. This removes the need for some annoying special handling regarding 3D video support (we supported duplicating the OSD/subtitles for side-by-side 3D output etc.). Remove the unneeded texture sampler uniform thing.
* vo_opengl: avoid constant divisionsNiklas Haas2017-07-171-9/+10
| | | | | | | These are apparently expensive on some drivers which are not smart enough to turn x/42 into x*1.0/42. So, do it for them. My great test framework says it's okay
* vo_opengl: generalize --scale-clamp etc.Niklas Haas2017-07-121-1/+1
| | | | | This can help fight ringing without completely killing it, thus providing a middle-ground between ringing and aliasing.
* vo_opengl: remove redundant gl_video_setup_hooks callNiklas Haas2017-07-121-1/+0
| | | | | | | | This is unnecessary to call from gl_video_resize, because the hooks only (possibly) change when the actual vo_opengl options change. This used to be required back when mpv still had prescaling built in, but since that was all moved to user shaders and the code removed, this is a left-over artifact.
* vo_opengl: fix type of glsl variable frameAman Gupta2017-07-111-1/+1
|
* vo_opengl: don't make assumptions about plane orderwm42017-07-101-9/+30
| | | | | | | | | | | | | | | | | | | The renderer code doesn't list a fixed set of supported formats, but supports anything that is described by AVPixFmtDescriptor and follows a number of constraints. Plane order is not included in those constraints. This means the planes could be in random order, rather than what the vo_opengl renderer happens to assume. For example, it assumes that the 4th plane is alpha, even though alpha could be on any plane. Likewise it assumes that plane 0 was always luma, and planes 2/3 chroma. (In earlier iterations of format support, this was guaranteed by MP_IMGFLAG_YUV_P, but this is not used anymore.) Explicitly set the plane semantics (enum plane_type) by the component descriptors and the used colorspace. The behavior should mostly not change, but it's less likely to break when FFmpeg adds new pixel formats.
* vo_opengl: fix dumb_mode chroma transformation fixupNiklas Haas2017-07-101-2/+2
| | | | | | | | In commit 6eb0bbe this was changed from xs[n] to use gl_format.chroma_w indiscriminately, which broke chroma rendering when zooming/cropping. The solution is to only use chroma_w for chroma planes. Fixes #4592.
* vo_opengl: describe the remainder passes after user shadersNiklas Haas2017-07-091-0/+1
| | | | | | | | | | | | On optional hook points, we store to a temp FBO and then read from it again to complete any operations that may still be left (e.g. sigmoidization after MAIN/LINEAR). In theory this mechanism should be reworked to avoid the temporary FBO until the next time we actually need one - and also skip redundant passes if we the next thing we need *is* a FBO - but both are those are tricky. Anyway, in the meantime, at least we can label the (semi-)redundant passes that get generated when using user shaders.
* vo_opengl: rework --opengl-dumb-modeNiklas Haas2017-07-071-4/+9
| | | | | | | It's now possible to request non-dumb mode as a user, even when not using any non-dumb features. This change is mostly intended for testing, so I can easily switch between dumb and non-dumb mode on default settings. The default behavior is unaffected.
* vo_opengl: also expose NAME_mul for user shadersNiklas Haas2017-07-061-2/+3
| | | | | | | | | This is exposed so that bjin/mpv-prescalers can use textureGatherOffset for performance. Since there are now quite a lot of parameters where it isn't quite clear why they're all defined, add a paragraph to the man page that explains them a bit.
* vo_opengl: add --tone-mapping-desaturateNiklas Haas2017-07-061-1/+5
| | | | | | | This helps prevent unnaturally, weirdly colorized blown out highlights for direct images of the sunlit sky and other way-too-bright HDR content. I was debating whether to set the default at 1.0 or 2.0, but went with the more conservative option that preserves more detail/color.
* vo_opengl: get rid of weird double-bind in pass_read_fboNiklas Haas2017-07-051-4/+2
| | | | | | | | This logic doesn't really make sense. copy_img_tex already binds the texture, so why would we bind it a second time? Furthermore, nothing actually uses this return value. Must have been some left-over artifact of a previous iteration of this function. Anyway, it's harmless, just nonsensical. So remove it.
* vo_opengl: remove redundant left-over lineNiklas Haas2017-07-051-1/+0
| | | | The pass_read_fbo immediately below replaces it
* vo_opengl: use textureGatherOffset for polar filtersNiklas Haas2017-07-051-1/+1
| | | | | | | | | | | | | | | | | | This is more efficient on my machine (nvidia), but only when applied to groups of exactly 4 texels. So we switch to the more efficient textureGather for groups of 4. Some notes: - textureGatherOffset seems to be faster than textureGather by a non-negligible amount, but for some reason, textureOffset is still slower than a straight-up texture - textureGather* requires GLSL 400; and at least on nvidia, this requires actually allocating a GL 4.0 context. - the code in opengl/common.c that clamped the GLSL version to 330 is deprecated, because the old user shader style has been removed completely in the meantime - To combat the growing complexity of the polar sampling code, we drop the antiringing functionality from EWA shaders completely, since it never really worked well for EWA to begin with. (Horrific artifacting)
* vo_opengl: make the pass info mechanism more robustNiklas Haas2017-07-031-17/+26
| | | | | | | | | | - change asserts to silent exits - check all pointers before use - move the p->pass initialization code to the right place This should hopefully cut down on the amount of crashing by making the code fundamentally more robust, while also fixing a concrete issue where opengl-cb failed to initialize p->pass.
* filter_kernels: add radius cutoff functionalityNiklas Haas2017-07-031-4/