Commit Graph

6 Commits

Author SHA1 Message Date
wm4 eb83ee4a4a vo_opengl: add our own copy of OpenGL headers
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.
2017-04-07 15:09:27 +02:00
wm4 b0cbda84ed vo_opengl: add a backend start_frame callback for context_vdpau
Might be useful for other backends too. For context_vdpau, resize
handling, presentation, and handling the mapping state becomes somewhat
less awkward.
2017-03-20 13:37:47 +01:00
wm4 8fb9cc2534 vo_opengl: read framebuffer depth from actual FBO used for rendering
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.
2017-03-20 13:31:28 +01:00
wm4 84bf6aabf0 vo_opengl: context_vdpau: resize output surfaces lazily
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.
2017-03-19 09:26:10 +01:00
wm4 d2dc29f221 vo_opengl: context_vdpau: minor fixes
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).
2017-03-19 09:03:13 +01:00
wm4 c3248369ac vo_opengl: add experimental vdpauglx backend
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.
2017-03-18 17:43:57 +01:00