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

[RJVB]

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.

[derjohn]

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 {} ;

[RJVB]

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`.

[derjohn]

Oooopss ... I took the wrong script-lines :) . The issue happens with chromium, too. And: The one-time deletion doesn't help at the moment. The issue is still there, but someone took already care: https://bugs.chromium.org/p/chromium/issues/detail?id=1442633

In my case the Fredium tabs don't recover if you delete the GPU after startup. If you choose "reload ferdium" from the menu, the GPUCache Dir are automatically recreated and the content is still not there. As I have about 20 or so ferdium tabs, reloading them one by one is a pain ....

[derjohn]

Again: If I delete the GPUcache it's not populated with a proper cache. (I run nixos and have an Intel i915 Iris XE MAX with mesa libs from current nixos. But anyway: Either mesa or chrom(e|ium) have to fix the issue, it's not Ferdium's fault IMHO.

[RJVB]

No, it's most likely a Chromium issue because Firefox isn't affected for instance (FF does other weird things with Mesa though, like causing "permission denied" errors about /dev/dri/renderDXYZ devices that do not even exist). Anyway, I meant a full, "cold" Ferdium restart. Ferdium itself also has a GPUCache for the application (~/.config/Ferdium/GPUCache) and I expect that you really need to quit and restart the application to see the effects of removing the files in there. As you probably know, deleting a file on *nix only removes the directory entry (hence the name, `rm`) but the file content itself isn't liberated as long as someone has the file open.

[derjohn]

I observed issues in some other components, too. E.g. in spectacle (KDE screenshot tool). If you make a screenshot and try annotate it, you don't see the yellow overlay annotations ... might be a random coincidence ...

[RJVB]

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/`

[derjohn]

Well, no, I will use that as my test case, if the issue has been resolved ...
oh, konqi, too?! ..... Please press thumbs the the upstream bug will be resolved sooooon.

[RJVB]

Well, no, I will use that as my test case, if the issue has been resolved

What test case?

Cache directories can always be removed and will be recreated the next time they're required. Browsers often have a feature to clean them (Ferdium does too) which might also address the issue.

Just don't expect any upstream fixes to trickle down to "old" versions of QtWebengine, unless it can be backported easily enough that your distro handles it!

[derjohn]

1.) Removing / cleaning the GPUCache Dir does NOT solve my issue. Upon restart they are automatically recreated with broken cache stuff. That why I chmodded them "0000", so Ferdium can't place stuff in there
2.) I hope the the (mesa or chromium) gets repaired .....
3.) Do yon guess the fixup is that chromium (lib) simply cleans the old cache dir?

[derjohn]

ATM I follow this bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=1442633

[RJVB]

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.

[stefankoop]

After an openSUSE Tumbleweed update the whole view of Joplins GUI was broken with some of the above error messages.

• Joplin AppImage 2.12.18 on
• openSUSE Tumbleweed 20231008 / KDE

For the sake of completeness

rm -rf ~/.config/Joplin/GPUCache

did the job for me. After (re)starting Joplin, everything went back to normal.

[euneuber]

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 {} \;

[RJVB]

For some reason I had to resort to this kludge this morning after waking the computer. Hadn't updated anything, only installed Mutter for some testing yesterday (and uninstalled it again). That shouldn't have changed anything relevant for Ferdium though...

[Shal-Ziar]

Had a similar issue with RedisInsight, can confirm that clearing GPU cache works. Good find @euneuber and @stefankoop

[SotchNam]

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 {} \;

Also solved my issue with Arduino ide v2 looking blank and corrupted, seems like an issue with electron