summaryrefslogtreecommitdiffstats
path: root/video/out/opengl/formats.c
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: remove some dead codewm42017-08-111-155/+0
| | | | | These were replaced by ra equivalents, and with the recent changes, all of them became fully unused.
* vo_opengl: add a hack for Apple's broken iOS hwdec stuffwm42017-08-081-0/+7
| | | | | As seen in hwdec_ios.m, it insists on using the legacy luminance alpha formats for mapped textures.
* vo_opengl: give special Apple name a more appropriate namewm42017-08-031-1/+1
| | | | | | | | Or less appropriate, as some would argue. The new name is short for "Apple YUV packed". (This format is needed only for hardware decoding on rather old Apple hardware, and a very annoying special case.)
* vo_opengl: start work on rendering API abstractionwm42017-07-261-51/+51
| | | | | | | | | | | | | | | | | | | | | | 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.
* video: get rid of swapped packed YUVwm42017-06-301-6/+2
| | | | | | Another legacy annoyance. The only place where packed YUV is still important is slightly older Apple hardware or drivers, which require it for efficient hardware decoding.
* vo_opengl: remove mp_imgfmt_desc and IMGFLAG_ usagewm42017-06-301-0/+4
| | | | | These were weird due to their past, and often undefined or ill-defined. Time to get rid of them.
* vo_opengl: restructure format setupwm42017-06-301-70/+38
| | | | | | | | | | | | Instead of setting up a weird swizzle (which is linked to how the internal renderer code works, rather than the generic format code), add per-component mapping to gl_imgfmt_desc. The renderer still computes the weird swizzle, but at least it's confined to itself. Also, it appears the hwdec backends don't need this anymore. It's really nice that the messy init_format() goes away too.
* vo_opengl: rely on FFmpeg pixdesc a bit morewm42017-06-291-80/+27
| | | | | | | | | | | | | Add something that allows is to extract the component order from various RGBA formats. In fact, also handle YUV, GBRP, and XYZ formats with this. It introduces a new struct mp_regular_imgfmt, that hopefully will eventually replace struct mp_imgfmt_desc. The latter is still needed by a lot of code though, especially generic code. Also vo_opengl still uses the old one, so this commit is sort of incomplete. Due to its genericness, it's also possible that this commit introduces rendering bugs, or accepts formats it shouldn't accept.
* vo_opengl: minor cosmeticswm42017-04-141-6/+10
|
* vo_opengl: don't crash on unsupported formatswm42017-02-171-1/+2
| | | | Regression from recent refactor.
* vo_opengl: hwdec_vaegl: use new format setup functionwm42017-02-171-1/+8
| | | | Plus add a helper.
* vo_opengl: hwdec_osx: use new format setup functionwm42017-02-171-2/+2
| | | | | | | | | | | | | | | | We can drop the custom table. For some reason, the interop does not accept GL_RGB_RAW_422_APPLE as internal format for GL_RGB_422_APPLE, so switch the format table to use GL_RGB (this way both interop and real textures work the same). Another victim of the apparent requirement of exactly matching texture formats is kCVPixelFormatType_32BGRA. vo_opengl wants to handle this as normal RGBA texture, with a swizzle applied in the shader. CGLTexImageIOSurface2D() rejects this, because it wants the exact internal format. Just drop the format, because it's useless anyway. (Maybe this is a bit too fragile...)
* vo_opengl: move texture mapping of pixel formats to helper functionwm42017-02-171-0/+140
| | | | | | | All supported pixel formats have a specific "mapping" of CPU data to textures. This function determines the number and the formats of these textures. Moving it to a helper will be useful for some hardware decode interop backends, since they all need similar things.
* vo_opengl: handle GL_LUMINANCE_ALPHA and integer textures differentlywm42017-02-171-0/+5
| | | | | | | | | | | | | | | GL_LUMINANCE_ALPHA is the only reason why per-plane swizzles exist. Remove per-plane swizzles (again), and regrettably handle them as special cases (again). Carry along the logical texture format (called gl_format in some parts of the code, including the new one). We also don't need a use_integer flag, since the new gl_format member implies whether it's an integer texture. (Yes, the there are separate logical GL formats for integer textures. This aspect of the OpenGL API is hysteric at best.) This should change nothing about actual rendering logic and GL API usage.
* vo_opengl: make ES float texture format checks stricterwm42016-05-231-3/+1
| | | | | | | | | | | | | | | 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: require at least ES 3.0 for float textureswm42016-05-191-1/+1
| | | | | | | | | | | | ES 2.0 has this weird rule that not the internalformat parameter determines the internal format, but the combination of all texture parameters. GL_OES_texture_half_float thus does not specify e.g. a GL_RGBA16F format, but requires passing GL_RGBA as format and GL_HALF_FLOAT_OES as type. We won't bother with this, since ES 2.0 is a lost cause anyway. This also removes the OpenGL error when the code is trying to create a f16 FBO for testing whether FBOs work.
* vo_opengl: restrict ES2 FBO formatswm42016-05-131-4/+4
| | | | | | | | | Only a few very low bit depth internal formats can be rendered to in pure ES2 (GL_RGB565 is the "best" one). Seems like the only potentially reasonable renderable formats in ES2 could be provided via GL_OES_rgb8_rgba8, or half-floats, so don't bother with this at all.
* vo_opengl: reorganize texture format handlingwm42016-05-121-0/+274
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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-03 22:29:31 +0000