Gnome performance unterirdisch, OpenGL zu niedrig?

[Artim]

Gnome (3.34) hat bei uns eine wirklich grauenhafte Performance, es treten quasi alle Probleme auf die man bei Google findet. Allgemein zähe arbeitsweise, Mauszeiger bleibt ständig hängen, viele Fenster zeigen beim Aufbau und vor allem beim Vergrößern starke Artefakte. Unter X ist das Problem nicht ganz so stark, aber insbesondere unter Wayland ist es wirklich schlimm.
Ich habe daher mal diverse andere Desktopumgebungen installiert um zu schauen wie die sich schlagen. Ich bin direkt bei KDE/Plasma hängen geblieben, dort ist mir aufgefallen, dass die Performance zwar auch schlimm war, allerdings sind mir dort Einstellungen für den Compositor aufgefallen. Das Problem scheint sich offenbar zu erledigen, wenn man dort von OpenGL 2.0 auf 3.1 umstellt. Insbesondere die Maus bleibt nach Ändern mancher Einstellungen zwar immer noch oft hängen, das erledigt sich aber nach 'ner Minute, dann ist alles wieder flüssig. Daraus würde ich schließen, dass OpenGL 2.0 entweder ungeeignet für den Zweck ist oder es zumindest mit unserem Rechner nicht so toll zusammenarbeitet.

Da stellt sich mir die Frage, welche OpenGL Version nutzt Gnome? Den Beobachtungen nach würde ich mal auf 2.0 tippen. Wenn dem so ist, gibt es eine Möglichkeit, dies wie bei KDE zu ändern? In den Einstellungen finde ich dazu nichts und das zu googlen bringt wenig, die Ergebnisse haben rein gar nichts mit dem Gesuchten zu tun.
Wir würden gerne bei Gnome bleiben, aber wie gesagt, die Performance ist so schlecht, das macht das Arbeiten zu einer Zumutung.

[towo]

Die Wahl der OpenGL Version gibts bei Gnome nicht.
Mal abgesehen davon, ist Deine Hardware so geheim, dass Du sie uns nicht verraten darfst?

[MSfree]

Gnome (3.34) hat bei uns eine wirklich grauenhafte Performance

Auf welcher Hardware?

Wenn dem so ist, gibt es eine Möglichkeit, dies wie bei KDE zu ändern?

Bei KDE kann man die GL-Version nicht ändern. Man kann nur einzelne Effekte ausschalten und dadurch Rechenoperationen sparen, was letztlich die Sache schneller machen kann.

[Artim]

Die Wahl der OpenGL Version gibts bei Gnome nicht.
Mal abgesehen davon, ist Deine Hardware so geheim, dass Du sie uns nicht verraten darfst?

Lenovo ThinkCenter M625q Tiny

Gnome (3.34) hat bei uns eine wirklich grauenhafte Performance

Auf welcher Hardware?

Wenn dem so ist, gibt es eine Möglichkeit, dies wie bei KDE zu ändern?

Bei KDE kann man die GL-Version nicht ändern. Man kann nur einzelne Effekte ausschalten und dadurch Rechenoperationen sparen, was letztlich die Sache schneller machen kann.

Und was ist dann bitteschön in den Systemeinstellungen unter Anzeige und Monitor -> Compositor der Punkt Ausgabemodul, wo ich sehr wohl die OpenGL-Version ändern kann? Und an Effekten habe ich unter KDE weit mehr aktiviert als unter Gnome überhaupt möglich ist und es läuft trotzdem flüssig.
Offenbar verfüge ich wohl nun offiziell über die Gabe der schwarzen Magie...

[Artim]

PS: dass es in GNOME nicht vorgesehen ist wie unter KDE die Ausgabe von OpengL 2.0 auf 3.1 zu ändern sehe ich ja selbst. Aber irgendeine Methode muss es ja geben, im zweifelsfall händisch entsprechend kompilieren, irgendwo muss GNOME ja gesagt werden was es nutzen soll. Das wäre aber eine letzte Notlösung, dafür bräuchte ich eine entsprechende Anleitung.

[towo]

Code: Alles auswählen

irgendwo muss GNOME ja gesagt werden was es nutzen soll. 

So, muss es?

Code: Alles auswählen

Das wäre aber eine letzte Notlösung, dafür bräuchte ich eine entsprechende Anleitung.

Nein, du brauchst keine Anleitung!
Was wir aber brauchen sind endlich relevante Infos!

lspci | egrep -i "vga|3d|display"
glxinfo | grep OpenG

und evtl noch ein vollständiges Xorg.0.log

[Artim]

Code: Alles auswählen

irgendwo muss GNOME ja gesagt werden was es nutzen soll. 

So, muss es?

Ja, ich würde es nicht gerade für schlau halten es einfach würfeln zu lassen, da mehr als genügend Möglichkeiten bestehen. Denn eine Sinnvolle Entscheidung würde es dann ganz offensichtlich nicht treffen.

Code: Alles auswählen

Das wäre aber eine letzte Notlösung, dafür bräuchte ich eine entsprechende Anleitung.

Nein, du brauchst keine Anleitung!
Was wir aber brauchen sind endlich relevante Infos!

lspci | egrep -i "vga|3d|display"
glxinfo | grep OpenG

und evtl noch ein vollständiges Xorg.0.log

Wer nicht fragt erhält auch keine Antwort...

Code: Alles auswählen

root@pc01:~# lspci | egrep -i "vga|3d|display"
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Stoney [Radeon R2/R3/R4/R5 Graphics] (rev ca)

Genauer gesagt ist eine Radeon R5 verbaut, laut AMDs infos.

root@pc01:~# glxinfo | grep OpenG
Error: unable to open display

Offenbar muss ich das morgen mal am Gerät selbst machen, einfach per ssh scheint es nicht zu laufen. Bei der Gelegenheit kann ich auch noch ein paar Logs von X sammeln. Wäre es zu diesem Zweck hilfreich im GDM3 Daemon das

Additionally lets the X server dump core if it crashes

zu aktivieren?

PS: falls es relevant ist, es ist die Nonfree Version von Debian testing am Werk, nur mit der ließ es sich bisher regeln, eine grafische Ausgabe zu erhalten. Aber auch nur unter Bullseye. Unter Buster bekommt weder der VGA noch der DP Monitor irgendein Signal. Also selbst eine einfache Bash lässt sich gar nicht erst nutzen.

PPS: der Firmware update manager (fwupdmgr) vermeldet eine neue Version der "System Firmware". Scheint aber für die CPU zu sein, aufgrund der Beschreibung

Code: Alles auswählen

 Enhancement to address security vulnerability

Klingt nach der Sicherheitslücke die erst gefunden wurde

[Artim]

Code: Alles auswählen

@pc01:~$ glxinfo | grep OpenG
OpenGL vendor string: X.Org
OpenGL renderer string: AMD STONEY (DRM 3.35.0, 5.4.0-4-amd64, LLVM 9.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.3.3
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.3.3
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.3.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

https://pastebin.com/fapVWgas

[wanne]

Ja, ich würde es nicht gerade für schlau halten es einfach würfeln zu lassen, da mehr als genügend Möglichkeiten bestehen. Denn eine Sinnvolle Entscheidung würde es dann ganz offensichtlich nicht treffen.

Kurz zur Auflösung. Du programmierst halt für eine OpenGL Version. Gnome nutzt in der X11 Variante meines Wissens hauptsächlich OpenGL 1.3 und in neueren Teilen OpenGL 2.1. Schafft deine Grafikkarte OpenGL 2.1 nicht, läuft es halt nicht. KDE bzw. die relevanten Teile davon wurden mehrfach geschrieben. Deswegen die Auswahlmöglichkeit. Wenn du willst, dass Gnome sich anders verhält: Schreib es neu!
Tendenziell sollte die neuere API immer die schnellere sein. Aber wie immer bei zwei unterschiedlichen Programmen: Was auf welcher Hardware am schnellsten läuft ist nicht so ganz vorhersehbar.
Würde auch mal rumspielen ob du besser mit wayland oder X11 fährst und eventeull unter wayland mit export GDK_BACKEND=wayland

Genauer gesagt ist eine Radeon R5 verbaut, laut AMDs infos.

Würde mir ernsthaft überlegen ob ich die ~200€ für einen Rechner ausgebe, bei dem du die Performance-Probleme nicht mehr hast.

[towo]

Also laut dem Xorg.0.log hast Du im Moment gar keine Grafische Oberfläche, da ist der Server gecrasht. Wenn Gnome im Moment unter Wayland läuft, gibts auch kein X-Log.
Laut glxinfo hat das System kein Problem mit der Grafik, da ist alles richtig initialisiert. Nun bleibt nur noch der Hinweis von wanne, allerdings braucht es für ein flüssiges Gnome keine Higend-Grafikkarte, deine Radeon R5 ist zwar keine Rakete, für Gnome sollte die aber allemal reichen.

[MSfree]

Tendenziell sollte die neuere API immer die schnellere sein.

Jein. GL2 beinhaltet alle Funktionen, die GL1.3 bietet, plus eben das, was GL2 mehr kann. Alle Funktionen, die von GL1.3 abgedeckt werden, werden auch von höheren GL-Versionen im "GL1.3-Modus" ausgeführt. Oder einfacher gesagt:
Wenn das Zeichnen einer Linie in GL1.3 implementiert wurde, gibt es keine neuere Implementierung in GL2. GL2 würde dann einfach den GL1.3-Aufruf verwenden, um eine Linie zu zeichnen.

Insofern wird die Graphik nicht schneller, wenn man die API wechselt, solange die Software nicht auch die zusätzlichen Funktionen nutzt.

Es könnte z.B. sein, daß das Zeichnen eines gefüllten Poligons in GL2 schneller geht als das Zeichnen einer Linie in GL1.3. Dann muß man das Zeichnen einen Linie aber dadurch "simulieren", in dem man ein gefülltes "sehr schmales" Poligon zeichnet,

[Artim]

Tendenziell sollte die neuere API immer die schnellere sein. Aber wie immer bei zwei unterschiedlichen Programmen: Was auf welcher Hardware am schnellsten läuft ist nicht so ganz vorhersehbar.
Würde auch mal rumspielen ob du besser mit wayland oder X11 fährst und eventeull unter wayland mit export GDK_BACKEND=wayland

Hättest du meinen ersten Post gelesen wäre dir aufgefallen dass ich beschrieben habe, dass es unter Wayland noch deutlich schlimmer ist als unter X.

Würde mir ernsthaft überlegen ob ich die ~200€ für einen Rechner ausgebe, bei dem du die Performance-Probleme nicht mehr hast.

Wieso sollten wir Hardware neu kaufen, wenn das Problem offensichtlich ein Softwareproblem ist?

[Artim]

Also laut dem Xorg.0.log hast Du im Moment gar keine Grafische Oberfläche, da ist der Server gecrasht. Wenn Gnome im Moment unter Wayland läuft, gibts auch kein X-Log.
Laut glxinfo hat das System kein Problem mit der Grafik, da ist alles richtig initialisiert. Nun bleibt nur noch der Hinweis von wanne, allerdings braucht es für ein flüssiges Gnome keine Higend-Grafikkarte, deine Radeon R5 ist zwar keine Rakete, für Gnome sollte die aber allemal reichen.

Das ist strange, ich nutze auch jetzt im Moment Gnome unter Xorg. Ich werde aber mal die erweiterten Logs aktivieren, vielleicht hilft das ja.

PS: kann es sein, dass das Log erst geschrieben wird, wenn man sich auslogt? Kann man einfach einen Dump erzwingen?

[towo]

PS: kann es sein, dass das Log erst geschrieben wird, wenn man sich auslogt? Kann man einfach einen Dump erzwingen?

Nein, aber da Du vermutlich GDM3 benutzt, findest Du das Gesuchte in ~./local/share/xorg/Xorg.0.log.

[wanne]

Insofern wird die Graphik nicht schneller, wenn man die API wechselt, solange die Software nicht auch die zusätzlichen Funktionen nutzt.

Wenn du nur Funktionen aus OpenGL 1.3 benutzt nutzt du OpenGL 1.3 nicht OpenGL 2.1. Erst sobald du die erste Funktion nutzt, die neuer ist nutzt du das neuere OpenGL. Und dann brächtest du für die Implementierung in der älteren Version alternativen. Und die sind meist teurer.

[wanne]

Insofern wird die Graphik nicht schneller, wenn man die API wechselt, solange die Software nicht auch die zusätzlichen Funktionen nutzt.

Wenn du nur Funktionen aus OpenGL 1.3 benutzt nutzt du OpenGL 1.3 nicht OpenGL 2.1. Erst sobald du die erste Funktion nutzt, die neuer ist nutzt du das neuere OpenGL. Und dann brächtest du für die Implementierung in der älteren Version alternativen. Und die sind meist teurer.

Wieso sollten wir Hardware neu kaufen, wenn das Problem offensichtlich ein Softwareproblem ist?

Nein. Das Problem ist offensichtlich eines deiner Hardware. Auf anderer Hardware läuft das ganze ja hervorragend. Du kannst jetzt entweder die Software auf deine Hardware anpassen, andere Software nutzen oder halt passende Hardware kaufen.
Wenn du unbedingt GNOME (als Anforderungshungrigste DE) willst, dann nutze sie halt mit zeitgemäßer Hardware. Wie gesagt: Ich weiß nicht genau, was das für ein Rechner ist aber für ~200€ bekommst du vermutlich einen neueren der nicht etwas sonder doppelt oder vier mal so schnell ist. Da ist halt irgend wann mal die Frage da, ob sich das lohnt.

[willy4711]

Na so alt ist das Teil ja nicht.
Da er ja nicht so mitteilsam ist, habe ich mir erlaubt mal selbst zu suchen. (inxi -F hätte es auch getan )
Hab zu seinem Rechner folgendes gefunden:
https://www.amazon.de/Lenovo-ThinkCentr ... B07GRZ1V1Y
Prozessor:
https://www.cpu-monkey.com/de/cpu-amd_a9_9420e-1294

Nach diesem Artikel entspricht diese R5 den Carrizo Modellen.
https://www.notebookcheck.com/AMD-Radeo ... 587.0.html

Nach seinem Xorg.0.log scheint aber nur bei den Treibern der xserver-xorg-video-ati
gesucht zu werden.
Ob es mal mit firmware-amd-graphics versucht wurde, ist nicht bekannt.
auf jeden Fall steht dort:

Code: Alles auswählen

 * "Carrizo" CE firmware (amdgpu/carrizo_ce.bin)
 * "Carrizo" ME firmware (amdgpu/carrizo_me.bin)
 * "Carrizo" MEC firmware (amdgpu/carrizo_mec.bin)
 * "Carrizo" MEC2 firmware (amdgpu/carrizo_mec2.bin)
 * "Carrizo" PFP firmware (amdgpu/carrizo_pfp.bin)
 * "Carrizo" RLC firmware (amdgpu/carrizo_rlc.bin)
 * "Carrizo" SDMA firmware (amdgpu/carrizo_sdma.bin)
 * "Carrizo" SDMA1 firmware (amdgpu/carrizo_sdma1.bin)
 * "Carrizo" UVD firmware, version 1.87 (amdgpu/carrizo_uvd.bin)
 * "Carrizo" VCE firmware (amdgpu/carrizo_vce.bin)

Nun hab ich keine Ahnung von AMD - Grafik, wollte das aber nur mal angemerkt haben

[Artim]

PS: kann es sein, dass das Log erst geschrieben wird, wenn man sich auslogt? Kann man einfach einen Dump erzwingen?

Nein, aber da Du vermutlich GDM3 benutzt, findest Du das Gesuchte in ~./local/share/xorg/Xorg.0.log.

Danke, habe das verlinkte Log aktualisiert

@willy4711
ich habe nunmal anderes zu tun als den ganzen Tag nur hier zu schauen ob es neue Antworten gibt.

Außerdem habe ich erwähnt, dass Debian testing non-free zum Einsatz kommt. Das schließt firmware-amd-graphics ein.

@wanne
wenn sich das Problem in Software problemlos lösen lässt ist es offensichtlich kein Problem der Hardware. Und wie @willy4711 richtig angemerkt hat ist der PC alles andere als alt. Wenn GNOME auf der Hardware nicht ordentlich läuft ist es kein Problem der Hardware sondern eins von GNOME.

[willy4711]

@willy4711
ich habe nunmal anderes zu tun als den ganzen Tag nur hier zu schauen ob es neue Antworten gibt.

Ob du es glaubst oder nicht, wir auch.
Vielleicht verlange ich ja zu viel, aber es wäre wirklich toll, wenn du folgende Ausgaben posten würdest:
inxi installieren
und dann

Code: Alles auswählen

inxi -f

sowie

Code: Alles auswählen

 inxi -Gxx

sowie

Code: Alles auswählen

dpkg -l *amd* |grep ii

ist haveged installiert ?
sowie

Code: Alles auswählen

journalctl -b |grep "vga\|fail"

Vielleicht hast du ja mal Zeit dazu

[rockyracoon]

@Artim:

@willy4711
ich habe nunmal anderes zu tun als den ganzen Tag nur hier zu schauen ob es neue Antworten gibt.

Hast Du schon mal etwas von "Höflichkeit" oder gar "Dankbarkeit" gehört, wenn sich hier Leute die Mühe machen, auf Deine Anfrage einzugehen?

[Artim]

root@pc01:~# inxi -Gxx
Graphics: Device-1: AMD Stoney [Radeon R2/R3/R4/R5 Graphics] vendor: Lenovo driver: amdgpu v: kernel
bus ID: 00:01.0 chip ID: 1002:98e4
Display: server: X.org 1.20.7 driver: ati,radeon,vesa unloaded: fbdev,modesetting
compositor: gnome-shell tty: 105x55
Message: Advanced graphics data unavailable in console for root.

Code: Alles auswählen

root@pc01:~# dpkg -l *amd* |grep ii
ii  amd64-microcode                    3.20191218.1              amd64        Processor microcode firmware for AMD CPUs
ii  firmware-amd-graphics              20190717-2                all          Binary firmware for AMD/ATI graphics chips
ii  fwupd-amd64-signed                 1.3.8+1                   amd64        Tools to manage UEFI firmware updates (signed)
ii  grub-efi-amd64                     2.04-5                    amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 version)
ii  grub-efi-amd64-bin                 2.04-5                    amd64        GRand Unified Bootloader, version 2 (EFI-AMD64 modules)
ii  grub-efi-amd64-signed              1+2.04+5                  amd64        GRand Unified Bootloader, version 2 (amd64 UEFI signed by Debian)
ii  libamd2:amd64                      1:5.7.1+dfsg-2            amd64        approximate minimum degree ordering library for sparse matrices
ii  libcamd2:amd64                     1:5.7.1+dfsg-2            amd64        symmetric approximate minimum degree library for sparse matrices
ii  libccolamd2:amd64                  1:5.7.1+dfsg-2            amd64        constrained column approximate library for sparse matrices
ii  libcolamd2:amd64                   1:5.7.1+dfsg-2            amd64        column approximate minimum degree ordering library for sparse matrices
ii  libdrm-amdgpu1:amd64               2.4.100-4                 amd64        Userspace interface to amdgpu-specific kernel DRM services -- runtime
ii  libteamdctl0:amd64                 1.30-1                    amd64        library for communication with `teamd` process
ii  linux-image-5.4.0-3-amd64          5.4.13-1                  amd64        Linux 5.4 for 64-bit PCs (signed)
ii  linux-image-5.4.0-4-amd64          5.4.19-1                  amd64        Linux 5.4 for 64-bit PCs (signed)
ii  linux-image-amd64                  5.4.19-1                  amd64        Linux for 64-bit PCs (meta-package)
ii  shim-helpers-amd64-signed          1+15+1533136590.3beb971+7 amd64        boot loader to chain-load signed boot loaders (signed by Debian)
ii  xserver-xorg-video-amdgpu          19.1.0-1                  amd64        X.Org X server -- AMDGPU display driver

haveged ist tatsächlich installiert

https://pastebin.com/zMSwSJW9

@rockyracoon wenn ihr der Meinung seid immer direkt antworten zu können/wollen ist das eure Sache. Beschwert euch dann aber nicht wenn andere dies nicht tun...

[towo]

Oha, das is ja wirklich mal eine lahme AMD Grafik, die da werkelt.

https://www.notebookcheck.com/AMD-Radeo ... 587.0.html

Da kann Gnome ja tatsächlich ins stocken kommen.

[wanne]

wenn sich das Problem in Software problemlos lösen lässt ist es offensichtlich kein Problem der Hardware.

Na dann löse mal schön...

Und wie @willy4711 richtig angemerkt hat ist der PC alles andere als alt.

Sorry, ich habe das irgend wie verwächselt. Ich dachte R5 wäre irgend so eine Gaming-Karte aus ~2013 oder so gewesen. Da habe ich was verwechselt.

Wenn GNOME auf der Hardware nicht ordentlich läuft ist es kein Problem der Hardware sondern eins von GNOME.

Im Prinzip sehe ich das ähnlich. Die Hardwareanforderungen für Gnome sind IMHO krass überzogen. Aber auf der anderen Seite hast du mit KDE in manchen fällen ähnliche Probleme. Scheint so, als ob das Ding bei manchen Funktionen halt wirklich stinke Lahm ist. Und du kannst von einem Entwickler nicht erwarten, dass er gewisse Sachen nicht verwendet, nur weil es auf irgend einer speziellen Karte nicht performant läuft. Btw. ist das der Grund den ich von nem Spielentwicklern vor kurzen gehört habe, warum sie Anwendungen nicht nur in OpenGL für alle Plattformen sondern für Windows in DirectX nochmal bauen: Da läuft dann alles überall ähnlich flüssig, während du für OpenGL erst mal feststellen musst, dass die Hälfte auf NVIDIA das falsche tut, bei AMD für jede Generation einzeln gucken musst ob das auch auf jeder AMD Karte in annehmbarer Zeit tut und Intel sei zwar meist unproblematisch hätte aber ein paar Spezialkarten auf denen gar nichts tut.

[Artim]

Scheint so, als ob das Ding bei manchen Funktionen halt wirklich stinke Lahm ist. Und du kannst von einem Entwickler nicht erwarten, dass er gewisse Sachen nicht verwendet, nur weil es auf irgend einer speziellen Karte nicht performant läuft.

Dann sollte man aber dem Nutzer die Wahl lassen, wenn offensichtlich wird, dass die Entscheidung nicht passt. So wie es KDE vor macht. Und dass sich auch GNOME stärker auf performance konzentrieren muss, sollte eigentlich bekannt sein, seit sich abzeichnet dass X mittelfristig vollständig durch Wayland ersetzt wird. Und das ist ja nicht erst seit gestern bekannt.

Btw. ist das der Grund den ich von nem Spielentwicklern vor kurzen gehört habe, warum sie Anwendungen nicht nur in OpenGL für alle Plattformen sondern für Windows in DirectX nochmal bauen: Da läuft dann alles überall ähnlich flüssig, während du für OpenGL erst mal feststellen musst, dass die Hälfte auf NVIDIA das falsche tut, bei AMD für jede Generation einzeln gucken musst ob das auch auf jeder AMD Karte in annehmbarer Zeit tut und Intel sei zwar meist unproblematisch hätte aber ein paar Spezialkarten auf denen gar nichts tut.

Da möchte man hoffen, dass das mit Vulkan sinnvoller gelöst wird. Da ist dann nur noch macOS/iOS Einzelgänger, aber das ist deren Problem.

[wanne]

Und dass sich auch GNOME stärker auf performance konzentrieren muss, sollte eigentlich bekannt sein, seit sich abzeichnet dass X mittelfristig vollständig durch Wayland ersetzt wird. Und das ist ja nicht erst seit gestern bekannt.

Werden sie nicht. Ist nicht ihr Ziel. Du hast die Wahl. LXDE, LXQT und XFCE sind explizit für schwächere Systeme entwickelt worden. Ich würde sagen mehr als die Hälfte der WMs werben explizit mit kleinen Systemanforderungen. Wenn du GNOME nutzt und dich dann über die hohen Hardwareanforderungen beschwerst, bist du genau so falsch am platz, wie wenn du dich über den großen Sprittverbrauch von nem Maroder beschwerst. GNOME ist so ziemlich die einzige Plattform, die sich nicht bis kaum um schwache Hardware Kümmert und hat die mit Abstand meisten Nutzer. – So unbeliebt scheint das Konzept nicht zu sein.

So wie es KDE vor macht.

Man sieht leider an KDE schön dass das eben leider nicht gut tut. Deren Konzept von wir wollen überall laufen irgend wann an seine Grenzen kam. (Das betrifft ja nicht nur x86-Grafikkarten KDE lief auch unter Windows, auf Android, mit Touchbedinung, auf Eingebetten Systemen ganz ohne OpenGL Support, mit eingeschränkten Farben...) Am Ende gilt KDE-Software als Überladen mit Spezialfunktionen und oft Buggy. In letzter Zeit ist der Anteil der KDE- Installationenen in Debian von 38% auf 17% gesunken.

Da möchte man hoffen, dass das mit Vulkan sinnvoller gelöst wird. Da ist dann nur noch macOS/iOS Einzelgänger, aber das ist deren Problem.

Mittlerweile ist Auch unter macOS/iOS Vulcan-Support da. Das Grundsätzliche Problem bleibt aber:
Während bei DirectX Microsoft halt einfach nein Sagen kann entscheiden die Grafikkartenhersteller bei Vulcan selbst. Während AMD (nachdem sie für OpenGL oft grauenhafte Implementierungen abgeliefert haben) eingesehen hat, dass das am ende negativ auf sie zurück fällt, wenn sie schlecht implementieren ist jetzt NVIDIA das sorgenkind. Die empfehlen immer noch für neue Projekte OpenGL zu nutzen. Zuerst hatte ich gedacht, dass das kein Problem ist, einige AAA-Games (Doom, Half-Life: Alyx) hatten angekündigt auf Vulcan zu setzen. Am ende ist das, das was in den Benchmarks genutzt wird. Hätte da ein Hersteller schlecht ausgesehen wäre das ein Problem für den Hersteller gewesen. Mit den Problemen bei NVIDIA sind aber alle Games einen Schritt zurück: Alle leistungshungrigen Games (Anno 1800, RD2, Doom Eternal, Half-Life: Alyx, Cyberpunk 2077, Black Mesa..) sind doch wieder in DirectX (zumindest wenn sie unter Windows laufen).
In sofern sehe ich da leider schwarz. Vermutlich wird Vulkan wieder ein Feature, für verrückte Nerds, das auch mal buggy sein kann.