aboutsummaryrefslogtreecommitdiffhomepage
path: root/video/out/opengl/common.h
Commit message (Collapse)AuthorAge
* vo_opengl: add time queriesGravatar Niklas Haas2016-06-07
| | | | | | | | | | | | | | | | | | 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.
* vo_opengl: make ES float texture format checks stricterGravatar wm42016-05-23
| | | | | | | | | | | | | | | Some of these checks became pointless after dropping ES 2.0 support for extended filtering. GL_EXT_texture_rg is part of core in ES 3.0, and we already check for this version, so testing for the extension is redundant. GL_OES_texture_half_float_linear is also always available, at least as far as our needs go. The functionality we need from GL_EXT_color_buffer_half_float is always available in ES 3.2, and we explicitly check for ES 3.2, so reject this extension if the ES version is new enough.
* vo_opengl: make PBOs work on GLES 3.xGravatar wm42016-05-23
| | | | | | | | | | | | | For some reason, GLES has no glMapBuffer, only glMapBufferRange. GLES 2 has no buffer mapping at all, and GL 2.1 does not always have glMapBufferRange. On those PBOs remain unsupported (there's no reason to care about GL 2.1 without the extension). This doesn't actually work on ANGLE, and I have no idea why. (There are artifacts on OSD, as if parts of the OSD data weren't copied.) It works on desktop OpenGL and at least 1 other ES 3 implementation. Don't enable it on ANGLE, I guess.
* vo_opengl: remove unused glDrawBufferGravatar wm42016-05-23
|
* vo_opengl: support framebuffer invalidationGravatar wm42016-05-23
| | | | | | | | | | Not sure how much can be gained with this, as we can't use it properly yet. For now, this is used only before rendering, which probably does overwhelmingly nothing. In the future, this should be used after temporary passes, which could possibly reduce memory usage and even memory bandwidth usage, depending on the drivers.
* vo_opengl: reorganize texture format handlingGravatar wm42016-05-12
| | | | | | | | | | | | | 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.
* vo_opengl: angle: dump translated shadersGravatar wm42016-05-12
| | | | Helpful for debugging and such.
* vo_opengl: support GL_EXT_texture_norm16 on GLESGravatar wm42016-04-27
| | | | | | | | | | | | | | | This gives us 16 bit fixed-point integer texture formats, including ability to sample from them with linear filtering, and using them as FBO attachments. The integer texture format path is still there for the sake of ANGLE, which does not support GL_EXT_texture_norm16 yet. The change to pass_dither() is needed, because the code path using GL_R16 for the dither texture relies on glTexImage2D being able to convert from GL_FLOAT to GL_R16. GLES does not allow this. This could be trivially fixed by doing the conversion ourselves, but I'm too lazy to do this now.
* vo_opengl: always premultiply alphaGravatar wm42016-03-29
| | | | | | 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.
* Enable building the opengl-cb video renderer on AndroidGravatar Jan Ekström2016-02-10
| | | | | | * Add Android-specific OpenGL ES feature and checks * Add missing GL_* symbols for Android (list gathered by Ilya Zhuravlev <whatever@xyz.is>)
* Change GPL/LGPL dual-licensed files to LGPLGravatar wm42016-01-19
| | | | | | | | | | | 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.
* vo_opengl: cocoa: output premultiplied alphaGravatar wm42015-12-19
| | | | | Which is apparently what is expected here. (I'm pretty sure X11 compositors want stright alpha, so 2 code paths are needed.)
* vo_opengl: split backend code from common.c to context.cGravatar wm42015-12-19
| | | | | | | | Now common.c only contains the code for the function loader, while context.c contains the backend loader/dispatcher. Not calling it "backend.c", because the central struct is called MPGLContext.
* vo_opengl: refactor how framebuffer depth is passed from backendsGravatar wm42015-12-19
| | | | | | | | | | | Store the determined framebuffer depth in struct GL instead of MPGLContext. This means gl_video_set_output_depth() can be removed, and also justifies adding new fields describing framebuffer/backend properties to struct GL instead of having to add more functions just to shovel the information around. Keep in mind that mpgl_load_functions() will wipe struct GL, so the new fields must be set before calling it.
* vo_opengl: add dxinterop backendGravatar James Ross-Gowan2015-12-11
| | | | | | | | | | | | | | | | | | | | | 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: use ANGLE by default if available (except for "hq" preset)Gravatar wm42015-11-21
| | | | | | | | | 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: use glBlitFramebuffer to draw repeated framesGravatar wm42015-11-15
| | | | | | | | | | | | | | | | | | | | | 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: implement NNEDI3 prescalerGravatar Bin Jin2015-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement NNEDI3, a neural network based deinterlacer. The shader is reimplemented in GLSL and supports both 8x4 and 8x6 sampling window now. This allows the shader to be licensed under LGPL2.1 so that it can be used in mpv. The current implementation supports uploading the NN weights (up to 51kb with placebo setting) in two different way, via uniform buffer object or hard coding into shader source. UBO requires OpenGL 3.1, which only guarantee 16kb per block. But I find that 64kb seems to be a default setting for recent card/driver (which nnedi3 is targeting), so I think we're fine here (with default nnedi3 setting the size of weights is 9kb). Hard-coding into shader requires OpenGL 3.3, for the "intBitsToFloat()" built-in function. This is necessary to precisely represent these weights in GLSL. I tried several human readable floating point number format (with really high precision as for single precision float), but for some reason they are not working nicely, bad pixels (with NaN value) could be produced with some weights set. We could also add support to upload these weights with texture, just for compatibility reason (etc. upscaling a still image with a low end graphics card). But as I tested, it's rather slow even with 1D texture (we probably had to use 2D texture due to dimension size limitation). Since there is always better choice to do NNEDI3 upscaling for still image (vapoursynth plugin), it's not implemented in this commit. If this turns out to be a popular demand from the user, it should be easy to add it later. For those who wants to optimize the performance a bit further, the bottleneck seems to be: 1. overhead to upload and access these weights, (in particular, the shader code will be regenerated for each frame, it's on CPU though). 2. "dot()" performance in the main loop. 3. "exp()" performance in the main loop, there are various fast implementation with some bit tricks (probably with the help of the intBitsToFloat function). The code is tested with nvidia card and driver (355.11), on Linux. Closes #2230
* vo_opengl: add vsync-fences optionGravatar wm42015-10-30
| | | | | | | | | | | | | | | | | | | | | | Yet another relatively useless option that tries to make OpenGL's sync behavior somewhat sane. The results are not too encouraging. With a value of 1, vsync jitter is gone on nVidia, but there are frame drops (less than with glfinish). With 2, I get the usual vsync jitter _and_ frame drops. There's still some hope that it might prevent too deep queuing with some GPUs, I guess. The timeout for the wait call is 1 second. The value is pretty arbitrary; it should just not be too high to freeze the process (if the GPU is un-nice), and not too low to trigger the timeout in normal cases, even if the GPU load is very high. So I guess 1 second is ok as a timeout. The idea to use fences this way to control the queue depth was stolen from RetroArch: https://github.com/libretro/RetroArch/blob/df01279cf318e7ec90ace039d60515296e3de908/gfx/drivers/gl.c#L1856
* video/out: remove an unused parameterGravatar wm42015-10-03
| | | | | | | | | | | This parameter has been unused for years (the last flag was removed in commit d658b115). Get rid of it. This affects the general VO API, as well as the vo_opengl backend API, so it touches a lot of files. The VOFLAGs are still used to control OpenGL context creation, so move them to the OpenGL backend code.
* vo_opengl: drop old backend APIGravatar wm42015-10-02
|
* vo_opengl: rpi: switch to new internal APIGravatar wm42015-10-02
|
* vo_opengl: w32: switch to new internal APIGravatar wm42015-10-02
|
* vo_opengl: refactor DwmFlush crapGravatar wm42015-10-02
| | | | | Get it out of the way in the common code. MPGLContext.dwm_flush_opt can be removed as well as soon as the option system gets overhauled.
* vo_opengl: wayland: switch to new internal APIGravatar wm42015-10-01
|
* vo_opengl: cocoa: switch to new internal APIGravatar wm42015-10-01
|
* vo_opengl: refactor EGL context information callbackGravatar wm42015-09-27
| | | | | Move the ugliness from x11egl.c to common.c, so that the ugliness doesn't have to be duplicated in wayland.c.
* vo_opengl: vaapi: redo how EGL extensions are loadedGravatar wm42015-09-27
| | | | | | | It looks like my hope that we can unconditionally include EGL headers in the OpenGL code is not coming true, because OSX does not support EGL at all. So I prefer loading the VAAPI EGL/GL specific extensions manually, because it's less of a mess. Partially reverts commit d47dff3f.
* vo_opengl: load certain EGL extensions needed for VAAPI EGL interopGravatar wm42015-09-25
| | | | | | | | | These extensions use a bunch of EGL types, so we need to include the EGL headers in common.h to use our GL function loader with this. In the future, we should probably require presence of the EGL headers to reduce the hacks. This might be not so simple at least with OSX, so for now this has to do.
* client API: rename GL_MP_D3D_interfacesGravatar wm42015-09-24
| | | | | | | | | | | | | This is a pseudo-OpenGL extension for letting libmpv query native windowing system handles from the API user. (It uses the OpenGL extension mechanism because I'm lazy. In theory it would be nicer to let the user pass them with mpv_opengl_cb_init_gl(), but this would require a more intrusive API change to extend its argument list.) The naming of the extension and associated function was unnecessarily Windows specific (using "D3D"), even though it would work just fine for other platforms. So deprecate the old names and introduce new ones. The old ones still work.
* vo_opengl: remove gl_ prefixes from files in video/out/openglGravatar Niklas Haas2015-09-09
This is a bit redundant with the name of the directory itself, and not in line with existing naming conventions.