RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-12-11 17:37:23 +00:00
Code Issues Releases Wiki Activity
1b2aed0b5a
mpv/video/out/opengl/formats.h

52 lines
1.9 KiB
C
Raw Normal View History

vo_opengl: reorganize texture format handling 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.
2016-05-12 18:08:49 +00:00
#ifndef MPGL_FORMATS_H_
#define MPGL_FORMATS_H_
#include "common.h"
struct gl_format {
vo_opengl: start work on rendering API abstraction 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.
2017-07-26 09:19:51 +00:00
const char *name; // symbolic name for user interaction/debugging
vo_opengl: reorganize texture format handling 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.
2016-05-12 18:08:49 +00:00
GLint internal_format; // glTexImage argument
GLenum format; // glTexImage argument
GLenum type; // e.g. GL_UNSIGNED_SHORT
vo_opengl: minor cosmetics
2017-04-14 15:35:27 +00:00
int flags; // F_* flags
vo_opengl: reorganize texture format handling 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.
2016-05-12 18:08:49 +00:00
};
enum {
// --- gl_format.flags
// Version flags. If at least 1 flag matches, the format entry is considered
// supported on the current GL context.
F_GL2 = 1 << 0, // GL2.1-only
F_GL3 = 1 << 1, // GL3.0 or later
F_ES2 = 1 << 2, // ES2-only
F_ES3 = 1 << 3, // ES3.0 or later
F_ES32 = 1 << 4, // ES3.2 or later
F_EXT16 = 1 << 5, // ES with GL_EXT_texture_norm16
vo_opengl: make ES float texture format checks stricter 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.
2016-05-23 17:29:08 +00:00
F_EXTF16 = 1 << 6, // GL_EXT_color_buffer_half_float
vo_opengl: reorganize texture format handling 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.
2016-05-12 18:08:49 +00:00
F_GL2F = 1 << 7, // GL2.1-only with texture_rg + texture_float + FBOs
F_APPL = 1 << 8, // GL_APPLE_rgb_422
// Feature flags. They are additional and signal presence of features.
F_CR = 1 << 16, // color-renderable
F_TF = 1 << 17, // texture-filterable with GL_LINEAR
F_CF = F_CR | F_TF,
F_F16 = 1 << 18, // uses half-floats (16 bit) internally, even though
// the format is still GL_FLOAT (32 bit)
// --- Other constants.
vo_opengl: start work on rendering API abstraction 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.
2017-07-26 09:19:51 +00:00
MPGL_TYPE_UNORM = RA_CTYPE_UNORM, // normalized integer (fixed point) formats
MPGL_TYPE_UINT = RA_CTYPE_UINT, // full integer formats
MPGL_TYPE_FLOAT = RA_CTYPE_FLOAT, // float formats (both full and half)
vo_opengl: reorganize texture format handling 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.
2016-05-12 18:08:49 +00:00
};
vo_opengl: start work on rendering API abstraction 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.
2017-07-26 09:19:51 +00:00
extern const struct gl_format gl_formats[];
vo_opengl: reorganize texture format handling 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.
2016-05-12 18:08:49 +00:00
int gl_format_feature_flags(GL *gl);
int gl_format_type(const struct gl_format *format);
GLenum gl_integer_format_to_base(GLenum format);
int gl_component_size(GLenum type);
int gl_format_components(GLenum format);
int gl_bytes_per_pixel(GLenum format, GLenum type);
#endif
Reference in New Issue Copy Permalink