ferdium-app: FYI: what to do in case of "Skia shader compilation error" reports on the terminal (Linux)

Your issue

I updated my libdrm yesterday and rebuilt Mesa after that.

After retarting Ferdium this morning I got rendering issues and endless error messages on the calling terminal:

xdg-settings: unexpected/missing argument                                                                            
Try 'xdg-settings --help' for more information.                                                                      
MESA-INTEL: warning: ../mesa-21.0.1/src/intel/vulkan/anv_device.c:171: The kernel reported a GTT size larger than 2 GiB but not support for 48-bit addresses                                                                              
[29474:0711/142415.755573:ERROR:shared_context_state.cc(81)] Skia shader compilation error                           
------------------------                                                                                             
// Vertex SKSL                                                                                                       
#extension GL_NV_shader_noperspective_interpolation: require                                                         
uniform float4 sk_RTAdjust;uniform float3x3 umatrix_S1;in float2 position;in half4 color;in float2 localCoord;flat out half4 vcolor_S0;noperspective out float2 vTransformedCoords_2_S0;void main() {// Primitive Processor QuadPerEdgeAAGeometryProcessor                                                                                                     
vcolor_S0 = color;sk_Position = position.xy01;{                                                                      
vTransformedCoords_2_S0 = float3x2(umatrix_S1) * localCoord.xy1;                                                     
}                                                                                                                    
}                                                                                                                    
// Fragment SKSL                                                                                                     
#extension GL_NV_shader_noperspective_interpolation: require                                                         
uniform float3x3 umatrix_S1;uniform sampler2D uTextureSampler_0_S1;                                                  
flat in half4 vcolor_S0;noperspective in float2 vTransformedCoords_2_S0;half4 TextureEffect_S1_c0(half4 _input) {    
return sample(uTextureSampler_0_S1, vTransformedCoords_2_S0).rrrr;}                                                  

half4 MatrixEffect_S1(half4 _input) {
return TextureEffect_S1_c0(_input);
}

void main() {// Stage 0, QuadPerEdgeAAGeometryProcessor
half4 outputColor_S0;outputColor_S0 = vcolor_S0;const half4 outputCoverage_S0 = half4(1);half4 output_S1;output_S1 = MatrixEffect_S1(outputCoverage_S0);{ // Xfer Processor: Porter Duff
sk_FragColor = outputColor_S0 * output_S1;}}
// Vertex GLSL
#version 300 es

#extension GL_NV_shader_noperspective_interpolation : require
precision mediump float;
precision mediump sampler2D;
uniform highp vec4 sk_RTAdjust;
uniform highp mat3 umatrix_S1;
in highp vec2 position;
in mediump vec4 color;
in highp vec2 localCoord;
flat out mediump vec4 vcolor_S0;
noperspective out highp vec2 vTransformedCoords_2_S0;
void main() {
    vcolor_S0 = color;
    gl_Position = vec4(position, 0.0, 1.0);
    {
        vTransformedCoords_2_S0 = mat3x2(umatrix_S1) * vec3(localCoord, 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
<SNIP>

Searching for “Skia shader compilation error” I found this ticket that also offered a solution:

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

The solution:

> find ~/.config/Ferdium/ -name "GPUCache" | xargs rm -rf

The strange thing is that Chromium does not report a change in the GL_RENDERER string.

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Reactions: 15
  • Comments: 16

Most upvoted comments

Since I got this on openSUSE tumbleweed too with the Zulip Desktop (which has actually more than one cache) I do:

find ~/.config/ -name GPUCache -type d -exec rm -rf {} \;

To make the fix a little more persistent, so it survives a Ferdium restart:

find ~/.config/chromium -maxdepth 4 -type d -name GPUCache -exec rm -r {}/* ; find ~/.config/chromium -maxdepth 4 -type d -name GPUCache -exec chmod 0000 {} ;

The idea is that the fix is required because the embedded Chromium framework doesn’t detect that the cached GPU stuff has to be discarded/refreshed. You force that regeneration by removing the entire cache, and afterwards it’s populated with “kosher” GPU stuff. That’s all the permanence you should need, until a next Mesa/whatever update.

Also, it’s ~/.config/Ferdium, not chromium.

1.) Removing / cleaning the GPUCache Dir does NOT solve my issue. Upon restart they are automatically recreated with broken cache stuff.

That sounds like a different or additional issue. This cache is populated with compiled shader “programmes”, you can compare it to .pyc or .pyo files that contain the result of byte-compiling python code. If you run the same code through a different version of the interpreter it could print an error about those .pyc/pyo file(s); instead it replaces their content silently with a newly compiled version.

Chromium does the same under “normal” circumstances. When you remove the cache it also creates a new version that contains the newly compiled (and thus correct) binary representation of the shaders it has to run. Those are correct by definition, if your Mesa installation is correct. Apparently it is, if disabling the GPUCache restores normal behaviour for you.

What you’re describing looks like a general bug in the code that writes compiled shaders to cache file, but such a bug should hit everyone (if it’s in Chromium).

That said, if your machine is recent/powerful enough you probably won’t notice a performance difference of disabling the GPUCache.

KDE uses QtWebengine for lots of HTML-related things, which is also built around some version/variant of the Chromium framework. So yeah, one could expect issues there too. Good luck finding the corresponding GPUCache directory/ies!

For instance: ~/.local/share/konqueror/QtWebEngine/Default/GPUCache/