summaryrefslogtreecommitdiffstats
path: root/video/out/opengl
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: enable brightness/contrast controls for RGBwm42015-12-121-1/+1
| | | | | | | | | Why not. Also, instead of disabling hue/saturation for RGB, just don't apply them. (They don't make sense for conversion matrixes other than YUV, but I can't be bothered to keep the fine-grained disabling of UI controls either.)
* vo_opengl: add dxinterop backendJames Ross-Gowan2015-12-113-0/+675
| | | | | | | | | | | | | | | | | | | | | WGL_NV_DX_interop is widely supported by Nvidia and AMD drivers. It allows a texture to be shared between Direct3D and WGL, so that rendering can be done with WGL and presentation can be done with Direct3D. This should allow us to work around some persistent WGL issues, such as dropped frames with some driver/OS combos, drivers that buffer frames to increase performance at the cost of latency, and the inability to disable exclusive fullscreen mode when using WGL to render to a fullscreen window. The addition of a DX_interop backend might also enable some cool Direct3D-specific enhancements in the future, such as using the GetPresentStatistics API to get accurate frame presentation timestamps. Note that due to a driver bug, this backend is currently broken on Intel. It will appear to work as long as the window is not resized too often, but after a few changes of size it will be unable to share the newly created renderbuffer with GL. See: https://software.intel.com/en-us/forums/graphics-driver-bug-reporting/topic/562051
* vo_opengl: remove one more XYZ special-casewm42015-12-091-7/+2
| | | | The XYZ colorspace on XYZ pixfmt is enforced in some sanitation routine.
* vo_opengl: fix precision loss of fruit dithering matrixBin Jin2015-12-091-2/+9
| | | | | | | | | | 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.
* csputils: rename "yuv2rgb" functionswm42015-12-091-1/+1
| | | | | | They're not necessarily restricted to YUV aka YCbCr. vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
* csputils, vo_opengl: remove XYZ special case in color matrix retrievalwm42015-12-091-6/+1
| | | | | This just seems unnecessary. Refactor it a bit. There should be no functional changes.
* vo_opengl: fix shader compilation regressionwm42015-12-082-4/+5
| | | | | | | | | | The recent LUT adjustment changes broke interpolation. The concatenation of the shader stages is a bit messy, and it seems like sampler_prelude is not a good place to add this macro. Always add the macro to every shader instead. (While this doesn't seem too elegant, this isn't too inelegant either, and goes these problems out of the way.)
* vo_opengl: enable colormatrix even for RGB inputwm42015-12-071-15/+13
| | | | Enables brightness/contrast controls, and handles gbrp10 correctly.
* vo_opengl: fix issues with some obscure pixel formatswm42015-12-071-6/+6
| | | | | | | | | | | | | | | | | | | The computation of the tex_mul variable was broken in multiple ways. This variable is used e.g. by debanding for moving expansion of 10 bit fixed-point input to normalized range to another stage of processing. One obvious bug was that the rgb555 pixel format was broken. This format has component_bits=5, but obviously it's already sampled in normalized range, and does not need expansion. The tex_mul-free code path avoids this by not using the colormatrix. (The code was originally designed to work around dealing with the generally complicated pixel formats by only using the colormatrix in the YUV case.) Another possible bug was with 10 bit input. It expanded the input by bringing the [0,2^10) range to [0,1], and then treating the expanded input as 16 bit input. I didn't bother to check what this actually computed, but it's somewhat likely it was wrong anyway. Now it uses mp_get_csp_mul(), and disables expansion when computing the YUV matrix.
* vo_opengl: decrease default lookup texture size to 64Bin Jin2015-12-071-2/+2
| | | | | | 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.
* vo_opengl: make LOOKUP_TEXTURE_SIZE configurableBin Jin2015-12-072-4/+5
|
* vo_opengl: Fix minor LUT sampling errorBin Jin2015-12-073-11/+22
| | | | | | 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.
* vo_opengl: improve boundary check for polar filtersBin Jin2015-12-051-2/+2
| | | | | | | | | If the sampling point is placed diagonally, the radius difference could be as large as sqrt(2.0). And a loosened check with (radius - 1) would potentially include pixels out of the range. Fix the check to handle those corner case properly to avoid unnecessary texture lookup and improve the performance a bit.
* win32: remove dwmapi.dll dynamic loadingwm42015-12-041-34/+5
| | | | All Windows versions we support have this API.
* vo_opengl: require --enable-gpl3 for nnediwm42015-12-033-2/+31
| | | | | | | | | There are claims that nnedi3.c doesn't constitute its own new implementation, but is derived from existing HLSL or OpenCL shaders distributed under the LGPLv3 license. Until these are resolved, do the "correct" thing and require --enable-gpl3 to build nnedi.
* vo_opengl: fix backend=x11 on Intelwm42015-12-021-1/+1
| | | | "backend=x11" was resolved to x11_probe, which is unintentional.
* vo_opengl: add credits to NNEDI3 shaderBin Jin2015-12-021-0/+16
| | | | Add credits to several existing implementation of NNEDI3 shader.
* vo_opengl: enable NNEDI3 prescaler on OpenGL ES 3.0Bin Jin2015-12-023-14/+19
| | | | | | | | | | | | | | It turns out that both UBO and intBitsToFloat() are supported in OpenGL ES 3.0[1][2], enable them so that NNEDI3 prescaler can be used in a wider range of backends. Also fixes some implicit int-to-float conversions so that the shader actually compiles on GLES. Tested on Linux desktop (nvidia 358.16) with "es" sub-option. [1]: https://www.khronos.org/opengles/sdk/docs/man3/html/glGetUniformBlockIndex.xhtml [2]: https://www.khronos.org/opengles/sdk/docs/manglsl/docbook4/xhtml/intBitsToFloat.xml
* vo_opengl: make tscale=mitchell:tscale-clamp the defaultwm42015-11-291-2/+4
| | | | Looks better than "oversample". tscale-clamp suggested by haasn.
* vo_opengl: warn if interpolation is enabled, but not display-syncwm42015-11-281-0/+10
| | | | | | | 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.
* vo_opengl: fix interpolation with display-syncwm42015-11-281-12/+6
| | | | | | | | | | | | | | | | | | | | 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.
* vo: change vo_frame field unitswm42015-11-271-4/+3
| | | | | | | This was just converting back and forth between int64_t/microseconds and double/seconds. Remove this stupidity. The pts/duration fields are still in microseconds, but they have no meaning in the display-sync case (also drop printing the pts field from opengl/video.c - it's always 0).
* vo_opengl: disable interpolation without display-syncwm42015-11-251-2/+4
| | | | | 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.
* vo_opengl: win32: test for exclusive modeJames Ross-Gowan2015-11-261-0/+6
| | | | | | | | | | This is a hack, but unfortunately the DwmGetCompositionTimingInfo heuristic does not work in all cases (with multiple-monitors on Windows 8.1 and even with a single monitor in Windows 10.) See the comment in mp_w32_is_in_exclusive_mode() for more details. It should go without saying that if any better method of doing this reveals itself, this hack should be dropped.
* vo_opengl: angle: don't load libGLESv2.dllJames Ross-Gowan2015-11-261-17/+1
| | | | | ANGLE has EGL_KHR_get_all_proc_addresses, so all GLES core functions can be queried with eglGetProcAddress.
* vo_opengl: fix superxbr on GLESwm42015-11-211-6/+6
| | | | Well, not that anyone does or should care.
* vo_opengl: angle: allow using D3D9 backendwm42015-11-211-22/+31
| | | | | | | | | | | | | | The D3D9 backend does not support GLES 3, which makes it pretty useless. But it still might be a legitimate replacement of vo_direct3d.c on Windows 7 machines. Note that we could just use: eglGetDisplay(EGL_D3D11_ELSE_D3D9_DISPLAY_ANGLE) But for now I'll leave the old code. Maybe this can exclude use of software rendering backends (EGL_PLATFORM_ANGLE_DEVICE_TYPE_WARP_ANGLE). Since I'm not sure, I won't touch it.
* vo_opengl: use ANGLE by default if available (except for "hq" preset)wm42015-11-212-9/+10
| | | | | | | | | Running mpv with default config will now pick up ANGLE by default. Since some think ANGLE is still not good enough for hq features, extend the "es" option to reject GLES backends, and add to to the opengl-hq preset. One consequence is that mpv will by default use libswscale to convert 10 bit video to 8 bit, before it reaches the VO.
* vo_opengl: enable dumb-mode automatically if possiblewm42015-11-191-6/+44
| | | | | | | | | | | | | | | 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.
* vo_opengl: support 3D textures on ANGLEwm42015-11-192-3/+13
| | | | | | | 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.
* vo_opengl: switch FBO format on GLESwm42015-11-191-5/+11
| | | | | 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.)
* vo_opengl: make 1D textures completely optionalwm42015-11-192-5/+6
| | | | | | | | Polar scalers use 1D textures, because they're slightly faster on some GPUs than 2D textures. But 2D textures work too, so add support for them. Allows using these scalers with ANGLE.
* vo_opengl: fix some more GLES shader issueswm42015-11-191-6/+6
| | | | | | Just like commit f9a2fc59. There are probably some more such cases. The vec2 constructor calls are probably fine, but don't bother with confusing inconsistencies.
* vo_opengl: create FBOs in a more GLES conformant waywm42015-11-191-2/+40
| | | | | | | | | | | | | | | While desktop GL's glTexImage2D() essentially accepts anything, GLES is much stricter. The combination of allowed formats/types/internal formats is exactly specified. The GLES 3.0.4 specification lists them in table 3.2. (The ANGLE API validation code references this table.) The table could probably be extended into a general declarative table about GL formats covering other uses, but this would be a big non-trivial project, so don't bother and accept a minor degree of duplication with other tables. Note that the format and type do (or should) not matter here, because no image data is transferred to the GPU.
* vo_opengl: better check for float texture supportwm42015-11-191-7/+8
| | | | | | We don't only need float textures for advanced scaling - we also need them to be filterable with GL_LINEAR. On GLES, this is not supported until GLES 3.1, but some implementation expose them with extensions.
* vo_opengl: check shader string before sscanfing itKevin Mitchell2015-11-191-1/+1
|
* vo_opengl: add missing log newlineKevin Mitchell2015-11-191-1/+1
|
* vo_opengl: add RGBA8 framebuffer format, enable non-dumb mode for ES 3.0wm42015-11-191-1/+2
| | | | | | | This makes advanced scaling sort-of work for GLES 3.0 (on ANGLE). It's still not very advisable, as 8 bits might not be enough to avoid debanding. (Ironically, the debanding filter can be enabled, and does not raise any GL errors - but probably doesn't do anything useful.)
* vo_opengl: don't mix floats and integers in dither shaderwm42015-11-191-3/+3
| | | | | Some GLSL dialects (GLSL ES 3.00) do not have such implicit conversions. They have to be made floats for the sake of the shader compiler.
* vo_opengl: fix ANGLE GLES3 modeJames Ross-Gowan2015-11-192-2/+9
| | | | | | Turns out glGetTexLevelParameter, which is missing in ANGLE, is a GLES3.1 function. Removing it from the list of core GLES3 functions makes ANGLE work in GLES3 mode.
* vo_opengl: add initial ANGLE supportJames Ross-Gowan2015-11-182-0/+219
| | | | | | | | | | | ANGLE is a GLES2 implementation for Windows that uses Direct3D 11 for rendering, enabling vo_opengl to work on systems with poor OpenGL drivers and bypassing some of the problems with native GL, such as VSync in fullscreen mode. Unfortunately, using GLES2 means that most of vo_opengl's advanced features will not work, however ANGLE is under rapid development and GLES3 support is supposed to be coming soon.
* videotoolbox: make decoder format customizablewm42015-11-173-8/+33
| | | | | | | | | | Because apparently there's no ideal universally working format. The weird OpenGL texture format for kCVPixelFormatType_32BGRA is from: http://stackoverflow.com/questions/22077544/draw-an-iosurface-to-an-opengl-context (Which apparently got it from the linked Apple example code.)
* vo_opengl: osx: error out if there is no IOSurfacewm42015-11-171-0/+4
|
* vo_opengl: force dumb mode if RG textures are not availablewm42015-11-161-3/+3
| | | | | | | Something goes wrong somewhere. Don't bother, it's only needed for compatibility with our absolute baseline (GL 2.1/GLES 2). On the other hand, we can process nv12 formats just fine.
* vo_opengl: attempt to improve GLX vs. EGL backend detectionwm42015-11-163-37/+57
| | | | | | | | | | | | | | | For the sake of vaapi interop, we want to use EGL, but on the other hand, but because driver developers are full of shit, vdpau interop will not work on EGL (even if the driver supports EGL). The latter happens with both nvidia and AMD Mesa drivers. Additionally, EGL vaapi interop support can apparently only detected at runtime by actually using it. While hwdec_vaegl.c already does this, it would require initializing libva on _every_ system, which will cause libav to print an unpreventable bullshit message to the terminal. Try to counter these huge loads of bullshit by adding more fucking bullshit.
* vo_opengl: fix backend autoprobingwm42015-11-161-0/+9
| | | | | | | | | | | | | We want the following behavior: - VO probed, backend probed: only accept non-sw, fail completely otherwise - VO forced, backend probed: use the first non-sw, or if none is found, fall back to the first working sw backend - VO probed, backend forced: (I don't care about this case) - VO forced, backend forced: just use that backend Also, on backend probe failure the vo->probed field was left in its old state.
* vo_opengl: use glBlitFramebuffer to draw repeated frameswm42015-11-153-16/+27
| | | | | | | | | | | | | | | | | | | | | 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.)
* vo_opengl: move the glFlush() call to the rendererwm42015-11-101-0/+5
|
* vo_opengl: limit GLSL to version 3.3wm42015-11-101-0/+2
| | | | | Fixes custom shaders, which define their entrypoint as sample() function.
* vo_opengl: fix 10-bit video prescalingBin Jin2015-11-095-24/+21
| | | | | | | | | | | The nnedi3 prescaler requires a normalized range to work properly, but the original implementation did the range normalization after the first step of the first pass. This could lead to severe quality degradation when debanding is not enabled for NNEDI3. Fix this issue by passing `tex_mul` into the shader code. Fixes #2464
* vo_opengl: handle GL_ARB_uniform_buffer_object with low GLSL versionswm42015-11-095-6/+19
| | | | Why is this stupid crap being so much a pain for no reason.
* vo_opengl: fix extension namewm42015-11-091-1/+1
|
* vo_opengl: simplify GLSL version detectionwm42015-11-091-10/+4
| | | | | | | | | | | Pick the correct GLSL version from the GL_SHADING_LANGUAGE_VERSION string. Might be somewhat questionable, as we expect the minor version number not to have leading 0s. Should help with cases when the reported GLSL version is much higher than the equivalent of the reported GL version. This problem was observed in combination with GL_ARB_uniform_buffer_object, which can't be used if the declared GLSL version is too low.
* vo_opengl: never load vaapi GLX interop by defaultwm42015-11-095-8/+8
| | | | | | | Causes more harm than it helps. Will eventually be removed. Also rename the "reject_emulated" field to "probing" - this is more appropriate now.
* vo_opengl: rename "drm_egl" to "drm-egl"wm42015-11-091-1/+1
|
* vo_opengl: disable drm_egl autopickuprr-2015-11-091-0/+4
|
* vo_drm: relicense to LGPLrr-2015-11-081-4/+5
| | | | | Also removed authorship information (as per convention seen in other files)
* vo_drm: use bool rather than integer return valuesrr-2015-11-081-3/+2
| | | | | Since the errors weren't used for anything other than simple success/fail checks, I simplified things a bit.
* vo_opengl: add DRM EGL backendrr-2015-11-082-0/+439
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Notes: - Unfortunately the only way to talk to EGL from within DRM I could find involves linking with GBM (generic buffer management for Mesa.) Because of this, I'm pretty sure it won't work with proprietary NVidia drivers, but then again, last time I checked NVidia didn't offer proper screen resolution for VT. - VT switching doesn't seem to work at all. It's worth mentioning that using vo_drm before introduction of VT switcher had an anomaly where user could switch to another VT and input text to it, while video played on top of that VT. However, that isn't the case with drm_egl: I can't switch to other VT during playback like this. This makes me think that it's either a limitation coming from my firmware or from EGL/KMS itself rather than a bug with my code. Nonetheless, I still left (untestable) VT switching code in place, in case it's useful to someone else. - The mode_id, connector_id and device_path should be configurable for power users and people who wish to watch videos on nonprimary screen. Unfortunately I didn't see anything that would allow OpenGL backends to register their own set of options. At the same time, adding them to global namespace is pointless. - A few dozens of lines could be shared with vo_drm (setting up VT switching, most of code behind page flipping). I don't have any strong opinion on this. - Sometimes I get minor visual glitches. I'm not sure if there's a race condition of some sort, unitialized variable (doubtful), or if it's buggy driver. (I'm using integrated Intel HD Graphics 4400 with