glamor: gles2 starting apps and changing window-size very slow
Package: xwayland Version: 2:22.1.3-2 with specific es2 updates of merge-requests !924 (closed) and !934 (merged)
I am using graphics: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) Subsystem: Dell Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) Subsystem: Dell Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller Kernel driver in use: i915 Kernel modules: i915 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) Subsystem: Dell Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller I still use the latest "classic" i915-driver ES 2.0 Mesa 21.3.8. It is intel gen 3 and supports GL1.4 and ES2.0. This driver is not delivered at Debian (testing) Bookworm anymore. I also tested the new? gallium i915-driver, that supports GL2.1 and ES2.0.. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux debian 5.19.0-2-686-pae (SMP w/2 CPU threads) With the extra updates of the merge-requests a lot of window-handling is fast, but starting up of an app, changing the size of the window or using the buttons at the title bar (minimize, maximize terminate) is very slow. This is caused by large gradient and composite shaders. At the log we see next errors, (environment-vars INTEL_DEBUG=perf and MESA_GLSL=dump,errors,useprog are set): large gradient shader: warning: Couldn't flatten if-statement. This will likely result in software rasterization. i915_program_error: Could not allocate registers large composite shader: i915_program_error: Exceeded max ALU instructions (96 out of 64) i915_program_error: Exceeded max instructions (128 out of 123) i915_program_error: Exceeded max instructions (230 out of 123) ENTER FALLBACK 10000: Program LEAVE FALLBACK Program The hardware is too poor, to support these shaders and the driver fallbacks in that case to software-rendering. Performance of this software-rendering is very poor. A patch is made to avoid usage of these shaders and use the fallback of glamor in that case. This solves the problem but it is not easy to find good criteria for this patch. Classic i915 always gives status OK at GLSLlink and internally uses some kind of very slow software-rendering, if the linked shader can not run at the graphics card. To solve this problem glamor requires a minimum number of ALU instructions at GL2.1. Unfortunately this test can not be done at ES2.0. This causes the strange situation that glamor is not activated at GL2.1, because performance is not sufficient, but is running at the lower driver standard ES2.0 at the same graphics card. Gallium i915 gives status NOK at link of large gradient shaders. Glamor aborts at NOK, causing an abort of Xwayland and login. At lack of resources, Gallium i915 simply uses a simple fragment shader. Patch: At GL the max number of available ALU instructions is retrieved. If this value is low only small composite-shaders are activated, the others are executed by glamor fallback. Both i915-drivers set at GLSLlink of a large gradient a text at info log. If a text is present all gradient shaders are ignored and glamor fallback is activated. For ES2.0 the max number of ALU instructions is lowered to 64, causing only small composite-shaders to be activated. With this patch a specific setting for max number of ALU instructions depending on the driver is not needed and commented out The abort at status NOK at GLSLlink is removed.
Patch attached
Edited by GKraats