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_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");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|