Environment
- Creality Print 7.2.1 (stock
CrealityPrint-V7.2.1.5476-x86_64-Release.AppImage)
- Kubuntu 26.04, Plasma 6 (Wayland session, app running via XWayland), kernel 7.0.0-30
- Intel Core 5 120U iGPU (8086:a7ac, driver i915), Mesa 26.0.8
Symptom
Slicing completes, then ~7 s later the window turns black with the title … (Not Responding). The process stays alive (main thread idle). Reproducible on every slice, even a single 950-triangle STL. journalctl -k:
i915 0000:00:02.0: [drm] CrealityPrint[462756] context reset due to GPU hang
Core backtrace of the main thread:
iris (libgallium-26.0.8) … driUnbindContext
libGLX_mesa → libGLX
MakeCurrent(unsigned long, __GLXcontextRec*)
Slic3r::GUI::GLCanvas3D::reload_scene(bool, bool)
Slic3r::GUI::Plater::priv::on_slicing_completed(wxCommandEvent&)
wxEvtHandler::ProcessPendingEvents … gtk_main
The app log ends right after load_toolpaths … send vertices data to gpu end — i.e. the hang is the first draw of the toolpath preview. Loading a project that already contains G-code triggers it as well, without slicing.
A/B results (scripted: launch → click Slice plate → check kernel log)
| variant |
result |
| stock |
GPU hang |
INTEL_DEBUG=noccs |
OK — preview renders, export completes, GPU acceleration kept |
INTEL_DEBUG=nohiz |
GPU hang |
LIBGL_DRI3_DISABLE=1 |
GPU hang |
MESA_GL_VERSION_OVERRIDE=2.1 (GL 1.10 shader path) |
GPU hang |
gcode_preview_lite_mode |
GPU hang |
LIBGL_ALWAYS_SOFTWARE=1 (llvmpipe) |
OK |
So colour-compressed (CCS) surfaces are what wedges the preview draw on this driver/GPU combination. I have not isolated which draw/FBO it is on the app side; happy to test patches.
Workaround
INTEL_DEBUG=noccs in the environment (e.g. Exec=env INTEL_DEBUG=noccs … in the .desktop file). A fork ships this in the AppRun wrapper (applied only when an Intel GPU is present, overridable) together with two other Linux launcher fixes and a repacked 7.2.1 AppImage: https://github.com/hpflatorre/CrealityPrint — write-up in https://github.com/hpflatorre/CrealityPrint/blob/cr200b-kubuntu/doc/Linux-Troubleshooting.md.
Environment
CrealityPrint-V7.2.1.5476-x86_64-Release.AppImage)Symptom
Slicing completes, then ~7 s later the window turns black with the title
… (Not Responding). The process stays alive (main thread idle). Reproducible on every slice, even a single 950-triangle STL.journalctl -k:Core backtrace of the main thread:
The app log ends right after
load_toolpaths … send vertices data to gpu end— i.e. the hang is the first draw of the toolpath preview. Loading a project that already contains G-code triggers it as well, without slicing.A/B results (scripted: launch → click Slice plate → check kernel log)
INTEL_DEBUG=noccsINTEL_DEBUG=nohizLIBGL_DRI3_DISABLE=1MESA_GL_VERSION_OVERRIDE=2.1(GL 1.10 shader path)gcode_preview_lite_modeLIBGL_ALWAYS_SOFTWARE=1(llvmpipe)So colour-compressed (CCS) surfaces are what wedges the preview draw on this driver/GPU combination. I have not isolated which draw/FBO it is on the app side; happy to test patches.
Workaround
INTEL_DEBUG=noccsin the environment (e.g.Exec=env INTEL_DEBUG=noccs …in the .desktop file). A fork ships this in the AppRun wrapper (applied only when an Intel GPU is present, overridable) together with two other Linux launcher fixes and a repacked 7.2.1 AppImage: https://github.com/hpflatorre/CrealityPrint — write-up in https://github.com/hpflatorre/CrealityPrint/blob/cr200b-kubuntu/doc/Linux-Troubleshooting.md.