# [erledigt] kwin-5.8.x mit radeon, mesa-13.x und llvm-3.9

## schmidicom

Falls irgend jemand auf die Idee kommt den KDE Plasma auf einem Computer mit moderner AMD Gafikkarte (also eine die den radeonsi Treiber von Mesa benutzt) und einem Mesa das von llvm-3.9 gebaut wurde zu nutzen sollte er/sie es lieber lassen!

Wenn der radeonsi Treiber von Mesa im Einsatz ist und dieser mit llvm-3.9 gebaut wurde crasht kwin beim versuch irgendetwas in Richtung OpenGL anzufangen schlicht und einfach reproduzierbar ab.

Habe diesen Fehler jetzt schon auf zwei Rechnern mit entsprechender Hardware beobachtet und es hat mich rund drei Tage Zeit gekostet der Quelle des Problems auf die schliche zu kommen. Vielleicht crashen auch andere Programme als nur der kwin an einer solchen Kombi aber bei mir war es nur der kwin.Last edited by schmidicom on Sun Nov 06, 2016 9:20 am; edited 3 times in total

----------

## firefly

Hmm bei mir stützt es nicht ab.

Habe eine R7 370 im einsatz.

habe folgende pakete im einsatz:

```
r   sys-devel/llvm:0::gentoo 3.9.0-r1 to ::installed replacing 3.9.0-r1 [cycle 1]

    clang -debug -default-compiler-rt -default-libcxx -doc -gold -libedit libffi (-lldb) -multitarget ncurses -ocaml python sanitize static-analyzer xml (-test) ABI_X86: 32 (64) (-x32) LLVM_TARGETS: -AArch64 AMDGPU -ARM BPF -Hexagon -MSP430 -Mips NVPTX -PowerPC -Sparc -SystemZ (X86) -XCore PYTHON_TARGETS: python2_7 build_options: symbols=split -dwarf_compress -optional_tests -trace work=tidyup

    Reasons: target, media-libs/mesa-13.0.0:0::gentoo, sys-devel/clang-3.9.0-r100:0::installed

    In dependency cycle with existing packages: media-libs/mesa:0, sys-devel/llvm:0

r   media-libs/mesa:0::gentoo 13.0.0 to ::installed replacing 13.0.0 [cycle 1]

    -bindist -classic -d3d9 -debug dri3 egl gallium gbm gles1 gles2 llvm nptl -opencl -openmax -osmesa -pax_kernel -pic (-selinux) vaapi -valgrind vdpau wayland xa xvmc ABI_X86: 32 (64) (-x32) VIDEO_CARDS: (-freedreno) -i915 -i965 -ilo -intel -nouveau -r100 -r200 -r300 -r600 radeon radeonsi (-vc4) -vmware build_options: symbols=split -dwarf_compress -optional_tests -trace work=tidyup

    Reasons: target, !<media-libs/mesa-10.3.4-r1 from app-eselect/eselect-opengl-1.3.1-r4:0::installed, !<media-libs/mesa-9 from media-libs/glu-9.0.0-r1:0::installed, 10 more

r   kde-plasma/kwin:5::gentoo 5.8.3 to ::installed replacing 5.8.3

    -debug -gles2 handbook -multimedia (-test) build_options: symbols=split -dwarf_compress (-optional_tests) -trace work=tidyup

    Reasons: target, kde-plasma/plasma-desktop-5.8.3:5::installed, kde-plasma/plasma-workspace-5.8.3:5::installed

```

Als kernel verwende ich gentoo-sources 4.8.5 und das radeon kernel modul (kein amdgpu)

Eventuell wurde der Bug in den aktuellen upstream versionen von kwin/mesa gefixt.  Oder es ist es problem mit spezifischen Grafikkarten oder kernel version.

Für kwin ist bei mir opengl2.0 als renderer backend fürs compositing eingestellt.

----------

## firefly

Hast du nach dem llvm update auch mesa neugebaut? Eventuell ist da was binär inkompatibel geworden

----------

## schmidicom

Beim diesem Computer hier ist es eine Radeon R7 260X (Bonaire) mit Kernel 4.8.6 und ja ich habe daran gedacht das ein Upgrade von LLVM eventuell ein remerge von mesa nötig machen könnte aber wie bereits geschrieben half nichts anderes als ein Mesa das mit max. llvm 3.8.x gebaut wird. Und selbst jetzt wird mein SystemLog noch von solchen Meldungen regelrecht überflutet, für die sich bei KDE (oder deren Bugzilla) kein Schwein interessiert.

Ich persönlich glaube allerdings nicht mehr daran das es sich hierbei um einen echten Fehler in Mesa, LLVM, Kernel oder sonst was handelt, aus meiner Sicht ist das einfach wieder mal so richtig typisch KDE.

EDIT:

Möglicherweise habe ich gerade etwas enteckt was gleich mehrere Probleme auf einmal erledigt haben könnte, aber bevor ich das raus haue will ich es erst auch noch auf einem anderen Rechner testen.

----------

## firefly

Du hast null informationen über dein setup gegeben.

Welche version von mesa, kwin?

Wie ist das compositing von kwin konfiguriert?

X11 oder wayland?

Und dadurch ist deine Aussage das es an kwin/kde liegen muss völlig aus der Luft gegriffen.

Folgende Bugs im kde bugtracker habe ich gefunden, welche zu mindestens die gleiche Fehlermeldung bezüglich "no precision specified" haben:

https://bugs.kde.org/show_bug.cgi?id=324522

https://bugs.kde.org/show_bug.cgi?id=324478

Und die haben alle mit GLES zu tun, welche man auf dem Desktop normalerweise nicht verwenden soll.

----------

## schmidicom

Wenn die Lösung die ich gefunden habe das Problem tatsächlich gelöst hat dann war es wohl mein Setup, was aber nichts daran ändert das NUR der kwin/KDE und kein anderes auf Qt basierendes Programm damit Probleme hatte. Wenn es eine für mich brauchbare alternative zum KDE Plasma gäbe wäre ich schon längst weiter gezogen und wenn diese Mätzchen nicht bald aufhören passiert das vielleicht trotz mangelnder Alternative.

Das da die Mitteilsamkeit leidet ist doch wohl verständlich, oder?

----------

## firefly

Ohne mehr an informationen sehe ich das nicht so.

Aktuell klingt das für mich eher an eine rant gegen KDE ohne stichhaltige Argumente.

Kann aber gut sein, dass du eventuell EGL oder GLES als composting backend aktiviert hattest. Seit plasma 5.8 (wurde zu plasma 5.7 backported) kann man nicht mehr über die GUI zwischen EGL/GLX wählen.

Grund siehe: https://blog.martin-graesslin.com/blog/2016/08/opengl-changes-in-kwin-compositing/

Das könnte dein Problem erklären. -> Verwendung eines Backend, welches noch nicht völlig funktionsfähig unter X11 ist.

----------

## schmidicom

Also inzwischen bin ich mir sicher das es an dem aktivierten gles2 USE-Flags der qt Pakete gelegen hat (die hatte ich noch von meinen ersten Wayland-Experimenten her aktiv), seit dem das nicht mehr aktiv ist sieht das ganze Systemlog wesentlich besser aus und es gibt bei den Plasmoids auch keine Verzögerungen mehr. Trotzdem war der KDE Plasma der einzige der damit ein Problem hatte, LXQt ging das Flag so ziemlich am Arsch vorbei, und wenn die KDE-Devs wirklich in den Mobile bereich vordringen wollen sollte so etwas keine Rolle spielen.

Dieses USE-Flag ist eh etwas seltsam, bei den einen Paketen sorgt es für eine optionale Unterstützung von OpenGL ES und bei den anderen erzwingt es diese. Wäre vielleicht nicht verkehrt wenn die Gentoo Devs das mal auseinander nehmen würden, zb. gles2 und force-gles2 oder so.

----------

## firefly

 *schmidicom wrote:*   

> LXQt ging das Flag so ziemlich am Arsch vorbei

 

Könnte daran liegen das LXQt vermutlich kein compositing kann? Oder so gut wie keine effekte hat?

Denn KWin hat einen haufen effekte und nicht alle funktionieren, wie man in einem der beiden von mir geposteten bugs sehen kann, mit GLES.

Deshalb ist der Vergleich eher ein Vergleich von Äpfeln mit Birnen.

----------

## schmidicom

Du findest es also absolut verständlich das wenn mal ein Effekt nicht verfügbar ist oder nicht funktioniert gleich die halbe/ganze DE abschmiert?

----------

## firefly

 *schmidicom wrote:*   

> Du findest es also absolut verständlich das wenn mal ein Effekt nicht verfügbar ist oder nicht funktioniert gleich die halbe/ganze DE abschmiert?

 

Nein finde ich nicht. Aber du vergleichst hier echt Äpfel (KWin/Plasma) mit Birnen(LXQt).

Und du sagst selbst der crash war weg mit llvm 3.8.x aber die Ausgaben wegen fehlerhaften shadern war immer noch vorhanden. Also kann deine aussage "wenn mal ein Effekt nicht verfügbar ist oder nicht funktioniert  gleich die halbe/ganze DE abschmiert" nicht stimmen.

Dein Problem ist da du hier zwei verschiedene Probleme miteinander vermischst.

Das eine Problem ist/war das bei dir KWin mit llvm 3.9 crashte.

Das andere Problem ist/war das einige shader von KWin Effekten sich nicht übersetzen lassen.

Das 2. Problem liegt daran, dass einige KWin effekte noch nicht mit GLES funktionieren.

Das erste Problem könnte daran liegen das du ein verkorkstes setup hattest. Eventuell waren nicht alle teile sauber gebaut worden, z.b. Qt wurde nachträglich mit GLES support gebaut aber andere komponenten welche auf Qt aufbauen (hauptsächlich die Elemente, welche den Rendering Teil von Qt verwenden) wurden nicht neu gebaut.

AFAIK hat eine mit GLES gebautes Qt eine leicht andere ABI als wenn sie mit OpenGL support gebaut wurde.

----------

## firefly

Ich sehe gerade dass du amdgpu mit R7 260X (Bonaire) verwendest, welche  GCN 1.1 is(laut wikipedia: https://en.wikipedia.org/wiki/AMD_Radeon_Rx_200_series#Radeon_R7_260X).

Da der support für GCN 1.0/1.1 in amdgpu noch nicht final ist (z.b. funktioniert generell HDMI/DP audio nicht). Und selbst der userspace part (Hauptsächlich der LLVM AMD backend part, welche die shader übersetzt) welches mit amdgpu kommuniziert ist vermutlich für diese GCN Generationen noch sehr experimental.

Deshalb die Frage wiso verwendest du "amdgpu" kernel treiber statt "radeon"?

----------

## schmidicom

 *firefly wrote:*   

> Aber du vergleichst hier echt Äpfel (KWin/Plasma) mit Birnen(LXQt).

 

Da bin ich anderer Meinung aber darum geht es gar nicht sondern darum das hier eine Software auf biegen und brechen versucht etwas zu verwenden ohne vorher zu prüfen ob das überhaupt mit dem aktuellen System möglich ist. Wenn ein Effekt nicht funktioniert muss dieser und nur dieser abgeschaltet werden und auf gar keinen Fall darf deswegen gleich der Fenstermanager crashen.

 *firefly wrote:*   

> Deshalb die Frage wiso verwendest du "amdgpu" kernel treiber statt "radeon"?

 

Ich habe es natürlich mit beiden versucht und beide haben sich genau gleich verhalten.

Jetzt funktioniert es sowohl mit radeon als auch mit amdgpu und da mesa 13.x nur mit amdgpu in der Lage ist die Vulkan API zu unterstützen werde ich vorerst beim amdgpu-Treiber bleiben.

----------

