Mpv: [vo/gpu/wayland] glGetString(GL_VERSION) returned NULL

Created on 15 Nov 2018  路  6Comments  路  Source: mpv-player/mpv

mpv version and platform

mpv 0.29.0 on Ubuntu 18.04 arm64. Wayland desktop. Also tested with mpv-git.
Board: Le Potato (Cortex A-53 + Mali-450)
Using the binary drivers for the Mali, enabling GLES 2.0

Reproduction steps

mpv -v --vo=gpu --gpu-context=wayland --opengl-es=yes input.mp4

Expected behavior

The call to glGetString doesn't return NULL. Note that on the same configuration, I can run glmark2-es2-wayland and it works fine (including its call to glGetString, it reads out the Mali vendor strings, etc.).

libre@libre-computer-board:~$ glmark2-es2-wayland
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-450 MP
    GL_VERSION:    OpenGL ES 2.0
=======================================================

Actual behavior

[vo/gpu/wayland] glGetString(GL_VERSION) returned NULL.

Log file

https://0x0.st/sUiE.txt

voopengl vowayland

Most helpful comment

Board: Le Potato (Cortex A-53 + Mali-450)

I first thought this was a joke. But no, it's actual real hardware. Great name.

All 6 comments

Board: Le Potato (Cortex A-53 + Mali-450)

I first thought this was a joke. But no, it's actual real hardware. Great name.

I dug a bit more into this, and it's the call to eglMakeCurrent(p->egl_display, NULL, NULL, p->egl_context) in context_wayland.c that fails with error EGL_BAD_MATCH. There's no error-guard around the call so it kept going forward to glGetString.

Still trying to see exactly what's wrong but nothing jumps out so far.

"Fixed" it by calling egl_create_window(ctx) (had to set default geometry values since they were at 0 for the window creation), removing the call to eglMakeCurrent(p->egl_display, NULL, NULL, p->egl_context).

I'm guessing the mali blob for wayland doesn't like having NULL surfaces in its eglMakeCurrent implementation.

This is also a still present issue on zynqmp based devices (mali 400MP).

This probably warrants checking the code to see whether it's a driver bug or a mistake in the mpv code.

It's hard to say what the problem is. Just glancing at Khronos1, this one looks like the most likely one to me.

If context does not support being bound without read and draw surfaces, and both draw and read are EGL_NO_SURFACE, an EGL_BAD_MATCH error is generated.

Perhaps the real solution is #6240?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lightonflux picture lightonflux  路  4Comments

sant527 picture sant527  路  4Comments

ghost picture ghost  路  3Comments

olivergondza picture olivergondza  路  3Comments

fitipe picture fitipe  路  3Comments