vo/opengl/formats: use R8 and RG8 formats on GL2.1 and ES2 if available by anarsoul · Pull Request #18264 · mpv-player/mpv

anarsoul · 2026-07-14T17:50:58Z

Improve vo_gpu's OpenGL backend on older/limited GL implementations (notably Mesa lima, which exposes GL 2.1 with GL_EXT_framebuffer_object and GL_EXT_texture_rg, but no GL_ARB_framebuffer_object)

Support GL_EXT_framebuffer_object as an FBO provider: Some GL 2.1 drivers expose only the EXT variant of the FBO extension, leaving MPGL_CAP_FB unset even though FBOs work fine. mpv's FBO usage falls within the subset that EXT and ARB share, so load the EXT entrypoints as an alternative; the ARB/core entrypoints still overwrite them when available. Since querying default-framebuffer attachment parameters is an ARB/GL 3.0 addition, ra_gl_ctx_color_depth() now skips that query when only the EXT extension is present.
Use R8/RG8 formats on GLES 2.0 and GL 2.1 with texture_rg: Previously R/RG textures were only used on GL 3.0/ES 3.0, or GL 2.1 with texture_rg + texture_float + FBOs all present. Add format classes for ES2 with GL_EXT_texture_rg (unsized internal formats) and GL 2.1 with ARB/EXT_texture_rg alone. This avoids the LUMINANCE/LUMINANCE_ALPHA swizzle hack and matches the .rg layout of dmabuf imports (DRM_FORMAT_R8/GR88, i.e. NV12 via drm-prime).

anarsoul · 2026-07-14T17:51:41Z

Fixes #12968

anarsoul · 2026-07-14T17:59:49Z

As I mentioned in #14570 2 years ago, you can use MESA_GLES_VERSION_OVERRIDE=2.0 mpv --hwdec=vaapi --opengl-es=yes your-video.mkv to test the fix with GLES2

anarsoul · 2026-07-14T18:18:45Z

Build / mingw failure is not related to this PR:

Building ffmpeg
  Cloning into 'ffmpeg'...
  ~/work/mpv/mpv/ffmpeg/builddir ~/work/mpv/mpv
  Unknown option "--enable-libshaderc".
  See ../configure --help for available options.

CounterPillow · 2026-07-14T18:41:23Z

For those doubting the relevancy of hardware supported by the Lima driver today, there has been new low-end SoCs with Utgard-era Mali GPUs launched as recently as two years ago. I'm not happy about it either, but sometimes "ancient GPU that does GLES2" is preferable over "bespoke 2D blitter".

anarsoul · 2026-07-14T18:51:39Z

And if anyone is curious why I got back to it, see https://xff.cz/git/libva-v4l2_request/about/ - it finally allows using HW video decoders on Allwinner and Rockchip SoCs without waiting for ffmpeg to merge v4l2_request patches.

kasper93 · 2026-07-14T18:58:58Z

vo_gpu is legacy, could you also port this to libplacebo? Thanks.

anarsoul · 2026-07-14T19:17:28Z

vo_gpu is legacy, could you also port this to libplacebo? Thanks.

Last time I checked, libplacebo didn't support GL2 / GLES2 GPUs at all. Baseline is GLES3 which is not supported by this hardware.

Some GL 2.1 drivers (e.g. Mesa lima) expose GL_EXT_framebuffer_object but not GL_ARB_framebuffer_object, leaving MPGL_CAP_FB unset even though FBOs are usable. Load the EXT entrypoints as an alternative provider of MPGL_CAP_FB; mpv's FBO usage (Gen'd names, GL_FRAMEBUFFER target, single color attachment, runtime completeness checks) is within the subset EXT and ARB share. The section is placed before the ARB/core one so the latter overwrites the function pointers whenever it is available. Querying attachment parameters of the default framebuffer is an ARB/GL 3.0 addition, so skip that query in ra_gl_ctx_color_depth() when only the EXT extension is present.

GLES 2.0 contexts with GL_EXT_texture_rg never used single- and two-component R/RG textures, because the format table only listed them for GL 3.0/ES 3.0, or for GL 2.1 with texture_rg + texture_float + FBOs all present (F_GL2F). Video planes were uploaded as LUMINANCE/ LUMINANCE_ALPHA instead, which needs a swizzle hack and mismatches the .rg layout produced by dmabuf imports of DRM_FORMAT_R8/GR88 (NV12 via drm-prime), and forced dumb mode due to the have_texrg check. Add format classes for ES2 with GL_EXT_texture_rg (unsized internal formats, as ES2 requires) and for GL 2.1 with ARB/EXT_texture_rg alone, without the float/FBO requirements of F_GL2F. The entries are placed before the legacy LUMINANCE ones so format lookups prefer them; F_GL2RG is suppressed when F_GL2F is active to avoid duplicate entries.

kasper93 · 2026-07-14T20:00:00Z

vo_gpu is legacy, could you also port this to libplacebo? Thanks.

Last time I checked, libplacebo didn't support GL2 / GLES2 GPUs at all. Baseline is GLES3 which is not supported by this hardware.

Is this stated explicitly or there are bugs in libplacebo that prevent GLES2 support? At least I see the GL2/GLES2 related format definition there, so maybe it should be supported?

EDIT: I guess readme says its GL ES >= 3.0, the question is why, and how much effort would be to fix the earlier support.

anarsoul · 2026-07-14T20:06:35Z

the question is why, and how much effort would be to fix the earlier support.

It is not trivial. There is a huge technological gap between GLES2 and GLES3-class hardware.

Whatever is appropriate for GLES3 may not work at all or perform poorly on GLES2

github-actions · 2026-07-14T20:25:40Z

Download the artifacts for this pull request:

Windows

macOS

anarsoul · 2026-07-14T20:28:30Z

It is not trivial. There is a huge technological gap between GLES2 and GLES3-class hardware.

To expand on that, in GL2/GLES2 hardware, vo_gpu would usually use "dumb" mode, i.e. single rendering pass, since using multiple rendering passes might be prohibitive due to limited memory bandwidth on these low-end systems (think 16-bit DDR3 running at 1333MT/s - a quarter of what low-end DDR3-class x86 machine would have).

I'm not sure how much code can be shared with GLES3, but likely not a lot.

If you are planning to drop vo_gpu in future MPV releases, it might be worth leaving "dumb" mode in for older GPUs

kasper93 · 2026-07-14T20:43:12Z

It is not trivial. There is a huge technological gap between GLES2 and GLES3-class hardware.

To expand on that, in GL2/GLES2 hardware, vo_gpu would usually use "dumb" mode, i.e. single rendering pass, since using multiple rendering passes might be prohibitive due to limited memory bandwidth on these low-end systems (think 16-bit DDR3 running at 1333MT/s - a quarter of what low-end DDR3-class x86 machine would have).

I'm not sure how much code can be shared with GLES3, but likely not a lot.

If you are planning to drop vo_gpu in future MPV releases, it might be worth leaving "dumb" mode in for older GPUs

libplacebo has likewise the "dumb" mode. In fact most of the libplacebo design and code, is inherited from mpv's vo_gpu. It has been refactored and at points changed, but especially opengl backed is not really much different. I understand what you are saying, but at the same time, I don't think there is much gap in the actual code.

anarsoul · 2026-07-14T21:10:32Z

To begin with, vo=gpu-next won't even start on GL2 or GLES2. I'm not sure how much work it would be to get it working and whether libplacebo devs are happy with carrying support for legacy hardware.

It might be better to introduce GL2/GLES2-only vo in mpv.

na-na-hi · 2026-07-15T00:40:54Z

Tested GLES2 fix works with this PR.

Is this stated explicitly or there are bugs in libplacebo that prevent GLES2 support? At least I see the GL2/GLES2 related format definition there, so maybe it should be supported?

EDIT: I guess readme says its GL ES >= 3.0, the question is why, and how much effort would be to fix the earlier support.

This allows us to delete large, large swathes of shitty back-compat code for GLSL 110.

It was intentionally removed from libplacebo. I don't think adding compatibility code in libplacebo will happen.

kasper93 · 2026-07-15T01:18:56Z

Tested GLES2 fix works with this PR.

Is this stated explicitly or there are bugs in libplacebo that prevent GLES2 support? At least I see the GL2/GLES2 related format definition there, so maybe it should be supported?
EDIT: I guess readme says its GL ES >= 3.0, the question is why, and how much effort would be to fix the earlier support.

This allows us to delete large, large swathes of shitty back-compat code for GLSL 110.

It was intentionally removed from libplacebo. I don't think adding compatibility code in libplacebo will happen.

Unfortunate.

kasper93 · 2026-07-15T21:43:24Z

+         | ((gl->es == 200 &&
+            (gl->mpgl_caps & MPGL_CAP_TEX_RG)) ? F_ES2RG : 0)
         | (gl->mpgl_caps & MPGL_CAP_APPLE_RGB_422 ? F_APPL : 0);
+    // F_GL2RG is a subset of F_GL2F; avoid duplicate format entries.


Why? What is this fixing? F_GL2RG is non-float as I understand so why you bundle it with F_GL2F?

PR adds new entries for r8/rg8 formats (and r/rg for GLES2). Since F_GL2RG is a subset of F_GL2F (which is F_GL2RG + float textures + ARB_framebuffer_object), that would result in two r8/rg8 formats registered twice.

This particular line enforces mutual exclusivity - i.e. full color-renderable will be used with F_GL2F hardware, while filter-only fallback is only used on F_GL2RG

The logic is "clear F_GL2RG is F_GL2F is set", I hope it makes sense.

This particular line enforces mutual exclusivity - i.e. full color-renderable will be used with F_GL2F hardware, while filter-only fallback is only used on F_GL2RG

The format lookup always prefer formats higher on the lists. It's priority list of formats. So there is no issue in having lesser formats down the list. We already have duplication on master between F_GL2 and F_GL2F.

Either way, it's fine, just something that is rather not focused on main change.

kasper93 · 2026-07-15T21:44:34Z

Tested GLES2 fix works with this PR.

Is this stated explicitly or there are bugs in libplacebo that prevent GLES2 support? At least I see the GL2/GLES2 related format definition there, so maybe it should be supported?
EDIT: I guess readme says its GL ES >= 3.0, the question is why, and how much effort would be to fix the earlier support.

This allows us to delete large, large swathes of shitty back-compat code for GLSL 110.
It was intentionally removed from libplacebo. I don't think adding compatibility code in libplacebo will happen.

Unfortunate.

I have a plan to add proper non painful support for GLES < 130, but this will have to wait, because I have other task that need finishing first.

anarsoul · 2026-07-17T18:38:37Z

I have a plan to add proper non painful support for GLES < 130, but this will have to wait, because I have other task that need finishing first.

I'd suggest to introduce a separate renderer for GLES2-class hardware

anarsoul · 2026-07-21T20:32:47Z

Any further comments?

kasper93 · 2026-07-23T11:31:44Z


+    // Querying the default framebuffer needs GL_ARB_framebuffer_object or
+    // GL 3.0+; GL_EXT_framebuffer_object does not allow it.
+    if (!p->main_fb && gl->version && gl->version < 300 &&


Do we need !p->main_fb check here? GL_FRAMEBUFFER_ATTACHMENT_GREEN_SIZE is itself a GL 3.0 / ARB_framebuffer_object. So if libmpv api user provides FBO we would still try to query it and fail. So we can early exit. no?

anarsoul added 2 commits July 14, 2026 12:57

anarsoul force-pushed the gl_ext_fbo branch from 4c19e00 to 5e6c477 Compare July 14, 2026 19:57

kasper93 reviewed Jul 15, 2026

View reviewed changes

kasper93 reviewed Jul 23, 2026

View reviewed changes

Uh oh!

Conversation

anarsoul commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

anarsoul commented Jul 14, 2026

Uh oh!

anarsoul commented Jul 14, 2026

Uh oh!

anarsoul commented Jul 14, 2026

Uh oh!

CounterPillow commented Jul 14, 2026

Uh oh!

anarsoul commented Jul 14, 2026

Uh oh!

kasper93 commented Jul 14, 2026

Uh oh!

anarsoul commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kasper93 commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

anarsoul commented Jul 14, 2026

Uh oh!

github-actions Bot commented Jul 14, 2026

Uh oh!

anarsoul commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kasper93 commented Jul 14, 2026

Uh oh!

anarsoul commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

na-na-hi commented Jul 15, 2026

Uh oh!

kasper93 commented Jul 15, 2026

Uh oh!

kasper93 Jul 15, 2026

Choose a reason for hiding this comment

Uh oh!

anarsoul Jul 17, 2026

Choose a reason for hiding this comment

Uh oh!

anarsoul Jul 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kasper93 Jul 23, 2026

Choose a reason for hiding this comment

Uh oh!

kasper93 commented Jul 15, 2026

Uh oh!

anarsoul commented Jul 17, 2026

Uh oh!

anarsoul commented Jul 21, 2026

Uh oh!

kasper93 Jul 23, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

anarsoul commented Jul 14, 2026 •

edited

Loading

anarsoul commented Jul 14, 2026 •

edited

Loading

kasper93 commented Jul 14, 2026 •

edited

Loading

anarsoul commented Jul 14, 2026 •

edited

Loading

anarsoul commented Jul 14, 2026 •

edited

Loading

anarsoul Jul 17, 2026 •

edited

Loading