diff options
author | 2016-01-26 20:47:32 +0100 | |
---|---|---|
committer | 2016-01-26 21:35:23 +0100 | |
commit | 7b6e3772ab7a39fc81e7524540e69eb30c4da7ac (patch) | |
tree | daa55a939321c662a2f759fac442c416004fd72c /sub/osd_libass.c | |
parent | beb7094301a73d3af056982601ace45b8f3e7039 (diff) |
vo_opengl: support 10 bit support with ANGLE
GLES does not support high bit depth fixed point textures for unknown
reasons, so direct 10 bit input is not possible. But we can still use
integer textures, which are supported by GLES 3.0. These store integer
data just like the standard fixed point textures, except they are not
normalized on sampling. They also don't support bilinear filtering, and
require a special sampler ("usampler2D").
While these texture formats enable us to shuffle the data to the GPU,
they're rather impractical with the requirements mentioned above and our
current architecture. One problem is that most code assumes it can
always use bilinear scaling (even if bilinear is never used when using
appropriate scale/cscale options). Another is that we don't have any
concept of running a function on a texture in an uniform way.
So for now, run a simple conversion step through a FBO. The FBO will use
the rgba16f format normally, which gives enough bits for 10 bit, and
will at least gracefully degrade with higher depth input.
This is bound to be much slower than a more "direct" method, but at
least it works and is simple to implement.
The odd change of function call order in init_video() is to properly
disable "dumb mode" (no FBO use) if these texture formats are in use.
Diffstat (limited to 'sub/osd_libass.c')
0 files changed, 0 insertions, 0 deletions