Skip to content

Require compatibility profile context when not forcing OpenGL ES - #16214

Closed
ry-gatoni wants to merge 1 commit into
mixxxdj:mainfrom
ry-gatoni:ry
Closed

Require compatibility profile context when not forcing OpenGL ES#16214
ry-gatoni wants to merge 1 commit into
mixxxdj:mainfrom
ry-gatoni:ry

Conversation

@ry-gatoni

Copy link
Copy Markdown
Contributor

This prevents a potential version conflict between the context and packed shaders, which would result in shader compilation failure.

Fixes bug #16213

I'm not sure if altering the context is a good solution, or if it would be better to change the packed shader versions. I'd appreciate some feedback here.

This prevents a potential version conflict between the context and
packed shaders, which would result in shader compilation failure.
@daschuer

daschuer commented Mar 24, 2026

Copy link
Copy Markdown
Member

The code should run on GL and EGL. So picking here

format.setRenderableType(QSurfaceFormat::OpenGL);

does not work. Or does it?

Do you haven log of the errors you like to fix?

@daschuer

Copy link
Copy Markdown
Member

As a first-time contributor we also need your signature at Mixxx Contributor Agreement (Please comment here when you have done). It gives us permission to distribute your contribution under the GPL v2 or later license and the Apple Mac App Store. It is also helpful for us to have contact information for contributors in case we may need it in the future.

@ry-gatoni

Copy link
Copy Markdown
Contributor Author

I've signed the agreement

@ry-gatoni

Copy link
Copy Markdown
Contributor Author

EGL and OpenGL are not mutually exclusive; EGL is often used to create an OpenGL context.
If you mean OpenGL ES, then no that line of code will not work if it runs on a platform that only supports OpenGL ES. I tried to guard against this scenario by putting it behind that preprocessor check. Is FORCE_GLES defined when building on every platform that only supports OpenGL ES? Or is that only for debug/testing?
If guarding with the preprocessor check is not sufficient, that code can be put behind a dynamic check instead.

@ry-gatoni

ry-gatoni commented Mar 25, 2026

Copy link
Copy Markdown
Contributor Author

It would take up too much space to include the full error logs, so I'll describe the general pattern and show some examples.
There are two sources of errors on 9d13df1 (where I first noticed the errors).
The first is fragment shaders compiled in Shader::load() in shaders/shader.cpp. All error messages have the same form, "unsupported version 120". Here is an example:

warning [Main] QOpenGLShader::compile(Fragment): 0(3) : error C0201: unsupported version 120
0(2) : error C7532: global type sampler2D requires "#version 100" or later
0(3) : error C7532: global type vec2 requires "#version 100" or later
0(4) : error C7532: global type float requires "#version 100" or later
0(4) : error C7573: OpenGL/ES requires precision specifier on this float type (there is no default precision)
0(7) : error C7532: global variable gl_FragColor requires "#version 110" or later
0(7) : error C0000: ... or #extension GL_ARB_compatibility : enable
0(7) : error C7532: global function texture2D requires "#version 110" or later
0(7) : error C7532: global type vec4 requires "#version 100" or later

warning [Main] *** Problematic Fragment shader source code ***

#version 120
#ifdef GL_KHR_blend_equation_advanced
#extension GL_ARB_fragment_coord_conventions : enable
#extension GL_KHR_blend_equation_advanced : enable
#endif
#line 2
uniform sampler2D texture;
varying highp vec2 vTexcoord;
uniform float alpha;
void main()
{
gl_FragColor = texture2D(texture, vTexcoord) * vec4(1.0, 1.0, 1.0, alpha > .0 ? alpha : 1.0);
}


critical [Main] DEBUG ASSERT: "addShaderFromSourceCode( GLShader::Fragment, fragmentShaderCode)" in function void mixxx::Shader::load(const QString&, const QString&) at ./src/shaders/shader.cpp:23
warning [Main] QOpenGLShaderProgram::uniformLocation(matrix): shader program is not linked
warning [Main] QOpenGLShaderProgram::attributeLocation(position): shader program is not linked
warning [Main] QOpenGLShaderProgram::attributeLocation(texcoord): shader program is not linked
warning [Main] QOpenGLShaderProgram::uniformLocation(texture): shader program is not linked
warning [Main] QOpenGLShader::link: Link info

OpenGL ES programs must have both vertex and fragment shaders or a compute shader or a mesh and fragment shader.
[New Thread 0x7ffec4ff96c0 (LWP 153533)]
warning [Main] QOpenGLShader::link: Link info

#15874 fixes this class of errors. But it doesn't fix errors coming from vertex shaders compiled by MaterialShader::MaterialShader() in rendergraph/common/rendergraph/materialshader.h. These are the 5 vertex shaders in rendergraph/shaders. These error messages again have the same form, referring to unsupported version 120. For example:

warning [Main] QOpenGLShader::compile(Vertex): 0(2) : error C0201: unsupported version 120
0(4) : error C7532: global type mat4 requires "#version 100" or later
0(9) : error C7532: global type vec4 requires "#version 100" or later
0(16) : error C7532: global variable gl_Position requires "#version 100" or later

warning [Main] *** Problematic Vertex shader source code ***
#version 120
#line 1

struct buf
{
mat4 matrix;
};

uniform buf ubuf;

varying vec4 vColor;
attribute vec4 color;
attribute vec4 position;

void main()
{
vColor = color;
gl_Position = ubuf.matrix * position;
}


warning [Main] MaterialShader - compilation failed: ":/shaders/rendergraph/rgba.vert.qsb"

One of these is the shader whose failure to compile results in the crash I observed when opening any audio file, but I'm not sure which one it is.

@daschuer

daschuer commented Mar 25, 2026

Copy link
Copy Markdown
Member

I have two related PR:
#15874
#15762

Do they help to avoid the crash in the first place?

In this PR
#15797

I have remove the version 120 requirement utilizing the QT compatible layer between GL and GLES. We may check the remaining version guards, but I am afraid the shaders are actually required the version.

FORCE_GLES is a debug flag, I have introduced to check if GLES is working on my system which is GL by default. That's nothing we use in a release.

If I understand correctly, Fedora uses Wayland in EGL mode for optimal compatibility and performance. This is also supported by Qt.
However, you can start Mixxx with
-platform wayland or -platform wayland-egl
to select one or the other.
Alternatively, you can use the environment variables: QT_QPA_PLATFORM=wayland or QT_QPA_PLATFORM=wayland-egl
Can you try this and confirm if it works?

@ry-gatoni

Copy link
Copy Markdown
Contributor Author

Neither of those arguments or environment variables fix the problem. Neither of those PRs fix the issue either.

The reason for the crash is indexing into an empty vector (in BaseMaterialShader::uniformLocation()). The vector is empty because shader compilation failed (in MaterialShader::MaterialShader()) and the vector was never filled.
So the crash can be avoided either by ensuring the context and shader versions are such that shaders always compile, or if not make sure the system doesn't try to use an invalid shader for rendering.

I can add an early return in BaseGeometryNode::render() if a shader fails to bind, which prevents the crash but not the underlying issue of shader compilation failure. I can open this fix as another PR or add to an existing one. Let me know what would be best.

@daschuer

Copy link
Copy Markdown
Member

The current approach is to not offer waveforms that are known to crash.

Of cause replacing an actual crash by a VERIFY_OR_DEBUG_ASSERT is also a good practice, for that card the waveform selection verification fails.

A separate PR would be nice.

@daschuer

Copy link
Copy Markdown
Member

Did you had a second look here? The solution of this PR does not work, because it overrides the QT default.
Shall we close this PR?

@ry-gatoni

Copy link
Copy Markdown
Contributor Author

This is no longer necessary as #16213 was fixed by #16236.

@ry-gatoni ry-gatoni closed this Apr 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants