summaryrefslogtreecommitdiffstats
path: root/video/out/opengl/context_vdpau.c
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: add our own copy of OpenGL headerswm42017-04-071-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gl_headers.h is basically header_fixes.h done consequently. It contains all OpenGL defines (and some typedefs) we need. We don't include GL headers provided by the system anymore. Some care has to be taken by certain windowing APIs including all of gl.h anyway. Then the definitions could clash. Fortunately, redefining preprocessor symbols to the same content is allowed and ignored. Also, redefining typedefs to the same thing is allowed in C11. Apparently the latter is not allowed in C99, so there is an imperfect attempt to avoid the typedefs if required API symbols are apparently present already. The nost risky part about this are the standard typedefs and GLAPIENTRY. The latter is different only on win32 (and at least consistently so). The typedefs are mostly based on stdint.h typedefs, which khrplatform.h clumsily emulates on platforms which don't have it. The biggest difference is that we define GLsizeiptr directly to ptrdiff_t, instead of checking for the _WIN64 symbol and defining it to long or long long. This also typedefs GLsync to __GLsync, just like the khronos headers. Although symbols prefixed with __ are implementation reserved, khronos also violates this rule, and having the same definition as khronos will avoid problems on duplicate definitions. We can simplify the build scripts too. The ios-gl check seems a bit wrong now (what we really want to test for is EAGLContext), but I can't test and thus can't improve it. cuda_dynamic.h redefined two GL symbols; just include the new headers directly instead.
* vo_opengl: add a backend start_frame callback for context_vdpauwm42017-03-201-40/+38
| | | | | | Might be useful for other backends too. For context_vdpau, resize handling, presentation, and handling the mapping state becomes somewhat less awkward.
* vo_opengl: read framebuffer depth from actual FBO used for renderingwm42017-03-201-2/+2
| | | | | | | | | | | | In some cases, such as when using the libmpv opengl-cb API, or with certain vo_opengl backends, the main framebuffer is never accessed. Instead, rendering is done to a FBO that acts as back buffer. This meant an incorrect/broken bit depth could be used for dithering. Change it to read the framebuffer depth lazily on the first render call. Also move the main FBO field out of the GL struct to MPGLContext, because the renderer's init function does not need to access it anymore.
* vo_opengl: context_vdpau: resize output surfaces lazilywm42017-03-191-80/+82
| | | | | | | This actually fixes the dreaded errors during resizing. It works pretty much like before, except each surface is reallocated before it's used. It implies surfaces with the old size remain in the presentation queue and will be displayed.
* vo_opengl: context_vdpau: minor fixeswm42017-03-191-20/+37
| | | | | | | | | | | | | | | | | | Don't assume 0 is an invalid object handle. vdpau with its weird API design makes all objects indexes, with 0 being a perfectly valid and common value. You need to use VDP_INVALID_HANDLE, which is not 0. Don't crash if init fails at vdpau initialization. It's because mp_vdpau_destroy(NULL) crashes. Simplify it. Destroy output surface backed FBO before output surface. Also, strictly bookkeep the map/unmap calls (and unmap surfaces before destroying the FBO/texture). I can't see a change in the weird errors when resizing the window, but I guess it's slightly more correct. Add the GL_WRITE_DISCARD_NV symbol to header_fixes.h, because we might fail compilation with headers that do not contain the vdpau extension (well, probably doesn't matter).
* vo_opengl: add experimental vdpauglx backendwm42017-03-181-0/+375
As the manpage says, this has no value other than adding bugs. It uses code based on context_x11.c, and basically does very stripped down context creation (no alpha support etc.). It uses vdpau for display, and maps vdpau output surfaces as FBOs to render into them. This might be good to experiment with asynchronous presentation. For now, it presents synchronously, with a 4 frame delay (which should whack off A/V sync). The forced 4 frame delay is probably also why interaction feels slower. There are some weird vdpau errors on resizing and uninit. No idea what causes them.