FEDORA-2023-84965ba750 — bugfix update for mesa

unpushed

mesa-23.0.3-2.fc37

FEDORA-2023-84965ba750 created by pwalter a year ago for Fedora 37

This is another attempt to prevent partial updates, where important mesa subpackages get desynchronized with mesa-dri-drivers, and things crash because of version mismatch.

This update has been submitted for testing by pwalter.

a year ago

This update's test gating status has been changed to 'waiting'.

a year ago

This update's test gating status has been changed to 'passed'.

a year ago

This update has been pushed to testing.

a year ago

nucleo commented & provided feedback a year ago

karma

Chromium displays empty pages after this update. Works fine after downgrade to mesa 23.0.3-1.fc37

Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.

a year ago

nucleo commented & provided feedback a year ago

karma

Errors:
link failed but did not provide an info log
[8932:8932:0526/131217.530754:ERROR:shared_context_state.cc(77)] Skia shader compilation error
------------------------
// Vertex SKSL
#extension GL_NV_shader_noperspective_interpolation: require
uniform float4 sk_RTAdjust;in float2 position;in half4 color;noperspective out half4 vcolor_S0;void main() {// Primitive Processor QuadPerEdgeAAGeometryProcessor
vcolor_S0 = color;sk_Position = position.xy01;}
// Fragment SKSL
#extension GL_NV_shader_noperspective_interpolation: require
noperspective in half4 vcolor_S0;void main() {// Stage 0, QuadPerEdgeAAGeometryProcessor
half4 outputColor_S0;outputColor_S0 = vcolor_S0;const half4 outputCoverage_S0 = half4(1);{ // Xfer Processor: Porter Duff
sk_FragColor = outputColor_S0 * outputCoverage_S0;}}
// Vertex GLSL
#version 300 es

#extension GL_NV_shader_noperspective_interpolation : require
precision mediump float;
precision mediump sampler2D;
uniform highp vec4 sk_RTAdjust;
in highp vec2 position;
in mediump vec4 color;
noperspective out mediump vec4 vcolor_S0;
void main() {
    vcolor_S0 = color;
    gl_Position = vec4(position, 0.0, 1.0);
    gl_Position = vec4(gl_Position.xy * sk_RTAdjust.xz + gl_Position.ww * sk_RTAdjust.yw, 0.0, gl_Position.w);
}

// Fragment GLSL
#version 300 es

#extension GL_NV_shader_noperspective_interpolation : require
precision mediump float;
precision mediump sampler2D;
out mediump vec4 sk_FragColor;
noperspective in mediump vec4 vcolor_S0;
void main() {
    mediump vec4 outputColor_S0;
    outputColor_S0 = vcolor_S0;
    {
        sk_FragColor = outputColor_S0;
    }
}

geraldosimiao commented & provided feedback a year ago

karma

Working correctly here:

Operating System: Fedora Linux 37
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.106.0
Qt Version: 5.15.9
Kernel Version: 6.3.4-100.fc37.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-3632QM CPU @ 2.20GHz
Graphics Processor: Mesa Intel® HD Graphics 4000

I'm running these packages:

firefox-113.0.1-4.fc37.x86_64
google-chrome-beta-114.0.5735.45-1.x86_64
mesa-dri-drivers-23.0.3-2.fc37.x86_64
mesa-filesystem-23.0.3-2.fc37.x86_64
mesa-libEGL-23.0.3-2.fc37.x86_64
mesa-libgbm-23.0.3-2.fc37.x86_64
mesa-libGL-23.0.3-2.fc37.x86_64
mesa-libglapi-23.0.3-2.fc37.x86_64
mesa-libGLU-9.0.1-7.fc37.x86_64
mesa-libxatracker-23.0.3-2.fc37.x86_64
mesa-va-drivers-23.0.3-2.fc37.x86_64
mesa-vulkan-drivers-23.0.3-2.fc37.x86_64

rai510 provided feedback a year ago

karma

kparal commented & provided feedback a year ago

@nucleo Chrome/Chromium seem to have some problems with its gpu shader cache. See https://bodhi.fedoraproject.org/updates/FEDORA-2023-a20a26a598#comment-3040852 and https://bugzilla.redhat.com/show_bug.cgi?id=2193335 . This Mesa update is unlikely to blame here (literally the only thing that changed between -1 and -2 are package dependencies), it just triggers the Chrome bug.

nucleo commented & provided feedback a year ago

https://bugs.chromium.org/p/chromium/issues/detail?id=1442633#c14

It seems these are cases where Chromium can't invalidate cached shader blobs 
because the GL_RENDERER string doesn't change across package updates even 
though the update is clearly a breaking change. In #c0 GL_RENDERER is 
"ANGLE (AMD, AMD Radeon Graphics (renoir LLVM 15.0.7 DRM 3.49 6.1.27-1-lts), 
OpenGL 4.6 (Core Profile) Mesa 23.0.3)" - LLVM version is tagged as 15.0.7 so 
I presume that's the same across 15.0.7-2 and 15.0.7-3 - there's no way for 
Chromium to distinguish between the two.

So what I'd like to confirm is whether this hypothesis is true or not - please 
attach chrome://gpu output from before and after the update to verify this. 
If that is indeed the case, please file bugs downstream with the distro to either 
1) not making breaking changes in minor point releases - easier said than done, or 
2) somehow include the full version number in GL_RENDERER string - someone 
more familiar with mesa would know how this is done. Another alternative is to 
let us know if there's a more reliable string to use as the prefix for our shader
cache in GpuHostImpl::GetShaderPrefixKey here[1] - note that this only a prefix - 
the other part of the key contains a SHA of GL specific state/limits we think 
can affect a cached shader [2].