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
|
|
|
#include "common/common.h"
|
|
|
|
#include "common/msg.h"
|
|
|
|
#include "video/img_format.h"
|
|
|
|
|
|
|
|
#include "ra.h"
|
|
|
|
|
2017-07-29 18:14:48 +00:00
|
|
|
struct ra_tex *ra_tex_create(struct ra *ra, const struct ra_tex_params *params)
|
|
|
|
{
|
|
|
|
return ra->fns->tex_create(ra, params);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ra_tex_free(struct ra *ra, struct ra_tex **tex)
|
|
|
|
{
|
|
|
|
if (*tex)
|
|
|
|
ra->fns->tex_destroy(ra, *tex);
|
|
|
|
*tex = NULL;
|
|
|
|
}
|
|
|
|
|
2017-08-05 20:29:48 +00:00
|
|
|
struct ra_buf *ra_buf_create(struct ra *ra, const struct ra_buf_params *params)
|
|
|
|
{
|
|
|
|
return ra->fns->buf_create(ra, params);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ra_buf_free(struct ra *ra, struct ra_buf **buf)
|
|
|
|
{
|
|
|
|
if (*buf)
|
|
|
|
ra->fns->buf_destroy(ra, *buf);
|
|
|
|
*buf = NULL;
|
|
|
|
}
|
|
|
|
|
2017-08-07 17:14:18 +00:00
|
|
|
void ra_free(struct ra **ra)
|
|
|
|
{
|
|
|
|
if (*ra)
|
|
|
|
(*ra)->fns->destroy(*ra);
|
|
|
|
talloc_free(*ra);
|
|
|
|
*ra = NULL;
|
|
|
|
}
|
|
|
|
|
2017-09-08 02:27:53 +00:00
|
|
|
size_t ra_vartype_size(enum ra_vartype type)
|
2017-08-05 12:20:14 +00:00
|
|
|
{
|
|
|
|
switch (type) {
|
|
|
|
case RA_VARTYPE_INT: return sizeof(int);
|
|
|
|
case RA_VARTYPE_FLOAT: return sizeof(float);
|
|
|
|
case RA_VARTYPE_BYTE_UNORM: return 1;
|
|
|
|
default: return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-09-08 02:27:53 +00:00
|
|
|
struct ra_layout ra_renderpass_input_layout(struct ra_renderpass_input *input)
|
2017-08-05 12:20:14 +00:00
|
|
|
{
|
2017-09-08 02:27:53 +00:00
|
|
|
size_t el_size = ra_vartype_size(input->type);
|
|
|
|
if (!el_size)
|
|
|
|
return (struct ra_layout){0};
|
|
|
|
|
|
|
|
// host data is always tightly packed
|
|
|
|
return (struct ra_layout) {
|
|
|
|
.align = 1,
|
|
|
|
.stride = el_size * input->dim_v,
|
|
|
|
.size = el_size * input->dim_v * input->dim_m,
|
|
|
|
};
|
2017-08-05 12:20:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct ra_renderpass_input *dup_inputs(void *ta_parent,
|
|
|
|
const struct ra_renderpass_input *inputs, int num_inputs)
|
|
|
|
{
|
|
|
|
struct ra_renderpass_input *res =
|
|
|
|
talloc_memdup(ta_parent, (void *)inputs, num_inputs * sizeof(inputs[0]));
|
|
|
|
for (int n = 0; n < num_inputs; n++)
|
|
|
|
res[n].name = talloc_strdup(res, res[n].name);
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Return a newly allocated deep-copy of params.
|
2017-09-08 02:33:01 +00:00
|
|
|
struct ra_renderpass_params *ra_renderpass_params_copy(void *ta_parent,
|
2017-08-05 12:20:14 +00:00
|
|
|
const struct ra_renderpass_params *params)
|
|
|
|
{
|
|
|
|
struct ra_renderpass_params *res = talloc_ptrtype(ta_parent, res);
|
|
|
|
*res = *params;
|
|
|
|
res->inputs = dup_inputs(res, res->inputs, res->num_inputs);
|
|
|
|
res->vertex_attribs =
|
|
|
|
dup_inputs(res, res->vertex_attribs, res->num_vertex_attribs);
|
|
|
|
res->cached_program = bstrdup(res, res->cached_program);
|
|
|
|
res->vertex_shader = talloc_strdup(res, res->vertex_shader);
|
|
|
|
res->frag_shader = talloc_strdup(res, res->frag_shader);
|
|
|
|
res->compute_shader = talloc_strdup(res, res->compute_shader);
|
|
|
|
return res;
|
|
|
|
};
|
|
|
|
|
vo_gpu: export the GLSL format qualifier for ra_format
Backported from @haasn's change to libplacebo, except in the current RA,
there's nothing to indicate an ra_format can be bound as a storage
image, so there's no way to force all of these formats to have a
glsl_format. Instead, the layout qualifier will be removed if
glsl_format is NULL.
This is needed for the upcoming ra_d3d11 backend. In Direct3D 11, while
loading float values from unorm images often works as expected, it's
technically undefined behaviour, and in Windows 10, it will cause the
debug layer to spam the log with error messages. Also, apparently in
GLSL, the format name must match the image's format exactly (but in
Direct3D, it just has to have the same component type.)
2017-10-21 14:18:31 +00:00
|
|
|
struct glsl_fmt {
|
|
|
|
enum ra_ctype ctype;
|
|
|
|
int num_components;
|
|
|
|
int component_depth[4];
|
|
|
|
const char *glsl_format;
|
|
|
|
};
|
|
|
|
|
|
|
|
// List taken from the GLSL specification, sans snorm and sint formats
|
|
|
|
static const struct glsl_fmt ra_glsl_fmts[] = {
|
|
|
|
{RA_CTYPE_FLOAT, 1, {16}, "r16f"},
|
|
|
|
{RA_CTYPE_FLOAT, 1, {32}, "r32f"},
|
|
|
|
{RA_CTYPE_FLOAT, 2, {16, 16}, "rg16f"},
|
|
|
|
{RA_CTYPE_FLOAT, 2, {32, 32}, "rg32f"},
|
|
|
|
{RA_CTYPE_FLOAT, 4, {16, 16, 16, 16}, "rgba16f"},
|
|
|
|
{RA_CTYPE_FLOAT, 4, {32, 32, 32, 32}, "rgba32f"},
|
|
|
|
{RA_CTYPE_FLOAT, 3, {11, 11, 10}, "r11f_g11f_b10f"},
|
|
|
|
|
|
|
|
{RA_CTYPE_UNORM, 1, {8}, "r8"},
|
|
|
|
{RA_CTYPE_UNORM, 1, {16}, "r16"},
|
|
|
|
{RA_CTYPE_UNORM, 2, {8, 8}, "rg8"},
|
|
|
|
{RA_CTYPE_UNORM, 2, {16, 16}, "rg16"},
|
|
|
|
{RA_CTYPE_UNORM, 4, {8, 8, 8, 8}, "rgba8"},
|
|
|
|
{RA_CTYPE_UNORM, 4, {16, 16, 16, 16}, "rgba16"},
|
|
|
|
{RA_CTYPE_UNORM, 4, {10, 10, 10, 2}, "rgb10_a2"},
|
|
|
|
|
|
|
|
{RA_CTYPE_UINT, 1, {8}, "r8ui"},
|
|
|
|
{RA_CTYPE_UINT, 1, {16}, "r16ui"},
|
|
|
|
{RA_CTYPE_UINT, 1, {32}, "r32ui"},
|
|
|
|
{RA_CTYPE_UINT, 2, {8, 8}, "rg8ui"},
|
|
|
|
{RA_CTYPE_UINT, 2, {16, 16}, "rg16ui"},
|
|
|
|
{RA_CTYPE_UINT, 2, {32, 32}, "rg32ui"},
|
|
|
|
{RA_CTYPE_UINT, 4, {8, 8, 8, 8}, "rgba8ui"},
|
|
|
|
{RA_CTYPE_UINT, 4, {16, 16, 16, 16}, "rgba16ui"},
|
|
|
|
{RA_CTYPE_UINT, 4, {32, 32, 32, 32}, "rgba32ui"},
|
|
|
|
{RA_CTYPE_UINT, 4, {10, 10, 10, 2}, "rgb10_a2ui"},
|
|
|
|
};
|
|
|
|
|
|
|
|
const char *ra_fmt_glsl_format(const struct ra_format *fmt)
|
|
|
|
{
|
|
|
|
for (int n = 0; n < MP_ARRAY_SIZE(ra_glsl_fmts); n++) {
|
|
|
|
const struct glsl_fmt *gfmt = &ra_glsl_fmts[n];
|
|
|
|
|
|
|
|
if (fmt->ctype != gfmt->ctype)
|
|
|
|
continue;
|
|
|
|
if (fmt->num_components != gfmt->num_components)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
for (int i = 0; i < fmt->num_components; i++) {
|
|
|
|
if (fmt->component_depth[i] != gfmt->component_depth[i])
|
|
|
|
goto next_fmt;
|
|
|
|
}
|
|
|
|
|
|
|
|
return gfmt->glsl_format;
|
|
|
|
|
|
|
|
next_fmt: ; // equivalent to `continue`
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
2017-08-05 12:20:14 +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
|
|
|
// Return whether this is a tightly packed format with no external padding and
|
2017-08-07 17:18:58 +00:00
|
|
|
// with the same bit size/depth in all components, and the shader returns
|
|
|
|
// components in the same order as in memory.
|
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
|
|
|
static bool ra_format_is_regular(const struct ra_format *fmt)
|
|
|
|
{
|
2017-08-07 17:18:58 +00:00
|
|
|
if (!fmt->pixel_size || !fmt->num_components || !fmt->ordered)
|
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
|
|
|
return false;
|
|
|
|
for (int n = 1; n < fmt->num_components; n++) {
|
|
|
|
if (fmt->component_size[n] != fmt->component_size[0] ||
|
|
|
|
fmt->component_depth[n] != fmt->component_depth[0])
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (fmt->component_size[0] * fmt->num_components != fmt->pixel_size * 8)
|
|
|
|
return false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-07-29 18:11:51 +00:00
|
|
|
// Return a regular filterable format using RA_CTYPE_UNORM.
|
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 struct ra_format *ra_find_unorm_format(struct ra *ra,
|
|
|
|
int bytes_per_component,
|
|
|
|
int n_components)
|
|
|
|
{
|
|
|
|
for (int n = 0; n < ra->num_formats; n++) {
|
|
|
|
const struct ra_format *fmt = ra->formats[n];
|
|
|
|
if (fmt->ctype == RA_CTYPE_UNORM && fmt->num_components == n_components &&
|
|
|
|
fmt->pixel_size == bytes_per_component * n_components &&
|
|
|
|
fmt->component_depth[0] == bytes_per_component * 8 &&
|
2017-07-29 18:11:51 +00:00
|
|
|
fmt->linear_filter && ra_format_is_regular(fmt))
|
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
|
|
|
return fmt;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Return a regular format using RA_CTYPE_UINT.
|
|
|
|
const struct ra_format *ra_find_uint_format(struct ra *ra,
|
|
|
|
int bytes_per_component,
|
|
|
|
int n_components)
|
|
|
|
{
|
|
|
|
for (int n = 0; n < ra->num_formats; n++) {
|
|
|
|
const struct ra_format *fmt = ra->formats[n];
|
|
|
|
if (fmt->ctype == RA_CTYPE_UINT && fmt->num_components == n_components &&
|
|
|
|
fmt->pixel_size == bytes_per_component * n_components &&
|
|
|
|
fmt->component_depth[0] == bytes_per_component * 8 &&
|
|
|
|
ra_format_is_regular(fmt))
|
|
|
|
return fmt;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-08-15 15:00:35 +00:00
|
|
|
// Find a float format of any precision that matches the C type of the same
|
|
|
|
// size for upload.
|
2017-08-24 20:44:41 +00:00
|
|
|
// May drop bits from the mantissa (such as selecting float16 even if
|
|
|
|
// bytes_per_component == 32); prefers possibly faster formats first.
|
2017-08-15 15:00:35 +00:00
|
|
|
static const struct ra_format *ra_find_float_format(struct ra *ra,
|
|
|
|
int bytes_per_component,
|
|
|
|
int n_components)
|
|
|
|
{
|
2017-08-24 20:44:41 +00:00
|
|
|
// Assumes ra_format are ordered by performance.
|
|
|
|
// The >=16 check is to avoid catching fringe formats.
|
2017-08-15 15:00:35 +00:00
|
|
|
for (int n = 0; n < ra->num_formats; n++) {
|
|
|
|
const struct ra_format *fmt = ra->formats[n];
|
|
|
|
if (fmt->ctype == RA_CTYPE_FLOAT && fmt->num_components == n_components &&
|
|
|
|
fmt->pixel_size == bytes_per_component * n_components &&
|
2017-08-24 20:44:41 +00:00
|
|
|
fmt->component_depth[0] >= 16 &&
|
2017-08-15 15:00:35 +00:00
|
|
|
fmt->linear_filter && ra_format_is_regular(fmt))
|
|
|
|
return fmt;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-08-24 20:44:41 +00:00
|
|
|
// Return a filterable regular format that uses at least float16 internally, and
|
|
|
|
// uses a normal C float for transfer on the CPU side. (This is just so we don't
|
|
|
|
// need 32->16 bit conversion on CPU, which would be messy.)
|
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 struct ra_format *ra_find_float16_format(struct ra *ra, int n_components)
|
|
|
|
{
|
2017-08-24 20:44:41 +00:00
|
|
|
return ra_find_float_format(ra, sizeof(float), n_components);
|
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
|
|
|
}
|
|
|
|
|
2017-08-04 11:48:37 +00:00
|
|
|
const struct ra_format *ra_find_named_format(struct ra *ra, const char *name)
|
|
|
|
{
|
|
|
|
for (int n = 0; n < ra->num_formats; n++) {
|
|
|
|
const struct ra_format *fmt = ra->formats[n];
|
|
|
|
if (strcmp(fmt->name, name) == 0)
|
|
|
|
return fmt;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
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
|
|
|
|
2017-07-29 18:11:51 +00:00
|
|
|
// Like ra_find_unorm_format(), but if no fixed point format is available,
|
|
|
|
// return an unsigned integer 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
|
|
|
static const struct ra_format *find_plane_format(struct ra *ra, int bytes,
|
2017-08-15 15:00:35 +00:00
|
|
|
int n_channels,
|
|
|
|
enum mp_component_type ctype)
|
|
|
|
{
|
|
|
|
switch (ctype) {
|
|
|
|
case MP_COMPONENT_TYPE_UINT: {
|
|
|
|
const struct ra_format *f = ra_find_unorm_format(ra, bytes, n_channels);
|
|
|
|
if (f)
|
|
|
|
return f;
|
|
|
|
return ra_find_uint_format(ra, bytes, n_channels);
|
|
|
|
}
|
|
|
|
case MP_COMPONENT_TYPE_FLOAT:
|
|
|
|
return ra_find_float_format(ra, bytes, n_channels);
|
|
|
|
default: return NULL;
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
// Put a mapping of imgfmt to texture formats into *out. Basically it selects
|
|
|
|
// the correct texture formats needed to represent an imgfmt in a shader, with
|
|
|
|
// textures using the same memory organization as on the CPU.
|
|
|
|
// Each plane is represented by a texture, and each texture has a RGBA
|
|
|
|
// component order. out->components describes the meaning of them.
|
|
|
|
// May return integer formats for >8 bit formats, if the driver has no
|
|
|
|
// normalized 16 bit formats.
|
|
|
|
// Returns false (and *out is not touched) if no format found.
|
|
|
|
bool ra_get_imgfmt_desc(struct ra *ra, int imgfmt, struct ra_imgfmt_desc *out)
|
|
|
|
{
|
|
|
|
struct ra_imgfmt_desc res = {0};
|
|
|
|
|
|
|
|
struct mp_regular_imgfmt regfmt;
|
|
|
|
if (mp_get_regular_imgfmt(®fmt, imgfmt)) {
|
2017-07-29 18:11:51 +00:00
|
|
|
enum ra_ctype ctype = RA_CTYPE_UNKNOWN;
|
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
|
|
|
res.num_planes = regfmt.num_planes;
|
|
|
|
res.component_bits = regfmt.component_size * 8;
|
|
|
|
res.component_pad = regfmt.component_pad;
|
|
|
|
for (int n = 0; n < regfmt.num_planes; n++) {
|
|
|
|
struct mp_regular_imgfmt_plane *plane = ®fmt.planes[n];
|
|
|
|
res.planes[n] = find_plane_format(ra, regfmt.component_size,
|
2017-08-15 15:00:35 +00:00
|
|
|
plane->num_components,
|
|
|
|
regfmt.component_type);
|
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
|
|
|
if (!res.planes[n])
|
|
|
|
return false;
|
|
|
|
for (int i = 0; i < plane->num_components; i++)
|
|
|
|
res.components[n][i] = plane->components[i];
|
2017-07-29 18:11:51 +00:00
|
|
|
// Dropping LSBs when shifting will lead to dropped MSBs.
|
|
|
|
if (res.component_bits > res.planes[n]->component_depth[0] &&
|
|
|
|
res.component_pad < 0)
|
|
|
|
return false;
|
|
|
|
// Renderer restriction, but actually an unwanted corner case.
|
|
|
|
if (ctype != RA_CTYPE_UNKNOWN && ctype != res.planes[n]->ctype)
|
|
|
|
return false;
|
|
|
|
ctype = res.planes[n]->ctype;
|
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
|
|
|
}
|
|
|
|
res.chroma_w = regfmt.chroma_w;
|
|
|
|
res.chroma_h = regfmt.chroma_h;
|
|
|
|
goto supported;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (int n = 0; n < ra->num_formats; n++) {
|
2017-08-29 13:05:32 +00:00
|
|
|
if (imgfmt && ra->formats[n]->special_imgfmt == imgfmt) {
|
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
|
|
|
res = *ra->formats[n]->special_imgfmt_desc;
|
|
|
|
goto supported;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Unsupported format
|
|
|
|
return false;
|
|
|
|
|
|
|
|
supported:
|
|
|
|
|
|
|
|
*out = res;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ra_dump_tex_formats(struct ra *ra, int msgl)
|
|
|
|
{
|
|
|
|
if (!mp_msg_test(ra->log, msgl))
|
|
|
|
return;
|
|
|
|
MP_MSG(ra, msgl, "Texture formats:\n");
|
2017-08-03 14:18:20 +00:00
|
|
|
MP_MSG(ra, msgl, " NAME COMP*TYPE SIZE DEPTH PER COMP.\n");
|
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
|
|
|
for (int n = 0; n < ra->num_formats; n++) {
|
|
|
|
const struct ra_format *fmt = ra->formats[n];
|
|
|
|
const char *ctype = "unknown";
|
|
|
|
switch (fmt->ctype) {
|
|
|
|
case RA_CTYPE_UNORM: ctype = "unorm"; break;
|
|
|
|
case RA_CTYPE_UINT: ctype = "uint "; break;
|
|
|
|
case RA_CTYPE_FLOAT: ctype = "float"; break;
|
|
|
|
}
|
|
|
|
char cl[40] = "";
|
|
|
|
for (int i = 0; i < fmt->num_components; i++) {
|
|
|
|
mp_snprintf_cat(cl, sizeof(cl), "%s%d", i ? " " : "",
|
|
|
|
fmt->component_size[i]);
|
|
|
|
if (fmt->component_size[i] != fmt->component_depth[i])
|
|
|
|
mp_snprintf_cat(cl, sizeof(cl), "/%d", fmt->component_depth[i]);
|
|
|
|
}
|
|
|
|
MP_MSG(ra, msgl, " %-10s %d*%s %3dB %s %s %s {%s}\n", fmt->name,
|
|
|
|
fmt->num_components, ctype, fmt->pixel_size,
|
|
|
|
fmt->luminance_alpha ? "LA" : " ",
|
|
|
|
fmt->linear_filter ? "LF" : " ",
|
|
|
|
fmt->renderable ? "CR" : " ", cl);
|
|
|
|
}
|
2017-08-03 14:18:20 +00:00
|
|
|
MP_MSG(ra, msgl, " LA = LUMINANCE_ALPHA hack format\n");
|
|
|
|
MP_MSG(ra, msgl, " LF = linear filterable\n");
|
|
|
|
MP_MSG(ra, msgl, " CR = can be used for render targets\n");
|
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
|
|
|
}
|
|
|
|
|
|
|
|
void ra_dump_imgfmt_desc(struct ra *ra, const struct ra_imgfmt_desc *desc,
|
|
|
|
int msgl)
|
|
|
|
{
|
|
|
|
char pl[80] = "";
|
|
|
|
char pf[80] = "";
|
|
|
|
for (int n = 0; n < desc->num_planes; n++) {
|
|
|
|
if (n > 0) {
|
|
|
|
mp_snprintf_cat(pl, sizeof(pl), "/");
|
|
|
|
mp_snprintf_cat(pf, sizeof(pf), "/");
|
|
|
|
}
|
|
|
|
char t[5] = {0};
|
|
|
|
for (int i = 0; i < 4; i++)
|
|
|
|
t[i] = "_rgba"[desc->components[n][i]];
|
|
|
|
for (int i = 3; i > 0 && t[i] == '_'; i--)
|
|
|
|
t[i] = '\0';
|
|
|
|
mp_snprintf_cat(pl, sizeof(pl), "%s", t);
|
|
|
|
mp_snprintf_cat(pf, sizeof(pf), "%s", desc->planes[n]->name);
|
|
|
|
}
|
|
|
|
MP_MSG(ra, msgl, "%d planes %dx%d %d/%d [%s] (%s)\n",
|
|
|
|
desc->num_planes, desc->chroma_w, desc->chroma_h,
|
|
|
|
desc->component_bits, desc->component_pad, pf, pl);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ra_dump_img_formats(struct ra *ra, int msgl)
|
|
|
|
{
|
|
|
|
if (!mp_msg_test(ra->log, msgl))
|
|
|
|
return;
|
|
|
|
MP_MSG(ra, msgl, "Image formats:\n");
|
|
|
|
for (int imgfmt = IMGFMT_START; imgfmt < IMGFMT_END; imgfmt++) {
|
|
|
|
const char *name = mp_imgfmt_to_name(imgfmt);
|
|
|
|
if (strcmp(name, "unknown") == 0)
|
|
|
|
continue;
|
|
|
|
MP_MSG(ra, msgl, " %s", name);
|
|
|
|
struct ra_imgfmt_desc desc;
|
|
|
|
if (ra_get_imgfmt_desc(ra, imgfmt, &desc)) {
|
|
|
|
MP_MSG(ra, msgl, " => ");
|
|
|
|
ra_dump_imgfmt_desc(ra, &desc, msgl);
|
|
|
|
} else {
|
|
|
|
MP_MSG(ra, msgl, "\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|