News Mesa 25.0: Vulkan 1.4 und RDNA 4 für Linux

Update and shutdown.

Nein Windows nicht Neustart 😂
 
ContractSlayer schrieb:
Auch laufen immer mehr Spiele unter Linux performanter als unter Linux.
das wird ja immer besser xD :smokin: :evillol::watt:
 
  • Gefällt mir
Reaktionen: iPat1337, Nordwind2000 und illumina7
Und ewig grüßt das Fehler-Teufelchen ... :lol:
 
Marco01_809 schrieb:
Wenn du IPC meinst würde ich sagen liegt es an der library nicht die BC zu breaken. Das ist ja eh weitgehend unverzichtbar wegen containern/flatpak/u.s.w. wo draußen und drinnen unterschiedliche OS als base image genutzt werden. Kenn mich aber nicht gut genug mit dbus & Co. aus um zu sagen wie/ob man damit umgehen sollte wenn sich die Version eines Endpunkts im laufenden Betrieb ändert. Die freedesktop DBus APIs sind ja eigentlich recht genau durchspezifiziert und bei einer stabilen Distribution wie Debian sollten bei Updates ja grundsätzlich nie BC breaks reinkommen.
Nimm alles was dir einfällt und lege noch State der bei einem Neustart verloren geht oder Stunden zum neu machen oben drauf.
 
end0fseven schrieb:
Dabei will ich endlich komplett weg von Windows. Auf dem Notebook habe ich schon seit einem Jahr Linux Mint drauf, da wird aber auch nicht wirklich mehr gespielt als Minecraft und das läuft ja mittlerweile auf jeder Kartoffel 🙈
Wenn du ein System für Hannover hast dann kannst du dir auch Bazzite.gg anschauen
Steam OS Klon auf Fedora Basis!
Entsprechen auf Gaming optimiert
Läuft bei mir auf einen Rog ally
 
0x8100 schrieb:
du willst also damit sagen, dass kernel-live-patching nicht genutzt wird? na dann können wir redhat, ubuntu, suse und den anderen enterprise-anbietern ja sagen, dass sie sich den aufwand sparen können...
Ich halte das für ein mee-too bzw. checklisten feature.
 
foofoobar schrieb:
Ich halte das für ein mee-too bzw. checklisten feature.
Ja, die Checkliste von den Betreibern größerer Storage-, Datenbanksysteme und Hoster wo Neustarts recht viel Zeit brauchen, danach Caches kalt sind und es SLAs einzuhalten gilt.
 
Ein kleiner Nachtrag zu meinem Post #3:

Ich habe Mesa 25 jetzt auf Ubuntu am Laufen und es läuft wirklich alles smooth und ohne Probleme. Möchte sogar sagen, dass noch ein bisschen besser läuft. Jedenfalls ist das Bild beim Gaming viel ruhiger und es wirkt alles flüssiger. Nicht das ich mich über die FPS vorher beschweren hätte können. Aber anscheinend sind die Frametimes, subjektive Einschätzung, jetzt noch ruhiger geworden.
 
  • Gefällt mir
Reaktionen: Deinorius, Molokai und Tanzmusikus
Deinorius schrieb:
Basiert das auf einem direkten Vergleich mit Zahlen oder ist das nur ein Gefühl?
Semi-"gemessen"
Hatte MangoHUD zum Vergleich mitlaufen.

Guild Wars 2 z.B Hämmert nicht mehr alle 16Kerne
lauft aber nicht wirklich "schneller" das Spiel kann aber weder CPU noch GPU ausnutzen.

Forbidden West lauf 5 bis 10 FPS besser.
Jedi Survivor deutlich besser.
Das spiel war immer etwas schwammig.
Das fühlt sich jetzt viel besser an.

Witcher 3 selbes verhalten deutlich direkter.
( Launcher muss für die CachyOS Proton Version deaktiviert werden )

Aber um zum Kern der Frage zurück zu kommen.
Nein keine direkten Benchmarks.
( Ich habe keine 1:1 vergleiche angestellt sondern gespielt )

Meine Eindrücke sind rein subjektiv.
Die aber sehr positiv.

EDIT:
Schneller Test mit dem Cyberpunk 2077 Internem Benchmark.
( Mehr FPS NTSync )
Die FPS sind nicht so weit auseinander.
Der Proton Experimentell Lauf hatte aber mehrere heftige Ruckler
( Der Benchmark scheint sie nicht bemerkt zu haben )
Die NTSync Version lief komplett butterweich.

Treiber war MESA 25.
 

Anhänge

  • Proton EX.jpg
    Proton EX.jpg
    189,9 KB · Aufrufe: 159
  • Proton-NTSync.jpg
    Proton-NTSync.jpg
    190,1 KB · Aufrufe: 164
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus, Deinorius, Molokai und 4 andere
Piktogramm schrieb:
Ja, die Checkliste von den Betreibern größerer Storage-, Datenbanksysteme und Hoster wo Neustarts recht viel Zeit brauchen, danach Caches kalt sind und es SLAs einzuhalten gilt.
SLAs realisiert man besser mit Redundanz, Staging, usw..
 
Randnotiz schrieb:
Wenn das System hopps geht, bin ich dann zwar immer noch den halben Tag genervt, egal ob Linux oder Windows
Ich habe eine bootfähige 1:1 Kopie meines Produktivsystems auf einer ext. SSD, damit ich es (und damit meine gewohnte Arbeitsumgebung und alle Tools), überall booten kann: s. hier

Ich halte es bei einfachem Skript (mit rsync) aktuelle und wenn ich mal bei meinem Produktivsystem etwas rückgängig machen will (selbst falls ich es total zerschossen hätte), boote ich es einfach von der ext. SSD und synchronisiere es zurück: Üblicherweise dauert das 20-30 Sek., aber selbst wenn ich die Partition neu formatieren muss (weil komplett geschreddert - Snapshots wären dann auch weg, weshalb ich nichts davon halte), nur knapp eine Minute, um wieder alles wie vorher zu haben.

Da ich gerne bastle, passiert mir sowas gelegentlich "im Eifer des Gefechts": Ich muss ja nicht groß aufpassen, da ich alles, egal was ich verbocke, schnell wieder rückgängig machen kann.

devanet schrieb:
Setzen auf performance im Terminal:
Ich habe mir dafür ein "gov"-Skript geschrieben: s. hier

Das nutze ich auch "umgekehrt": Wenns im Hochsommer in meiner Dachwohnung zu heiß wird, begrenze ich den Takt auf eine niedrigere Taktstufe, oder ganz auf idle-Takt ("powersave").
Ergänzung ()

iPat1337 schrieb:
Frage mich wie man sich Windows 11 freiwillig geben kann.
In der VM und ohne Internetverbindung läuft es doch gut. ;)
 
  • Gefällt mir
Reaktionen: Piktogramm und Randnotiz
@foofoobar
Jain, es kommt sehr aufs Produkt an. Bei vielen mietbaren Instanzen/VMs sind diese nicht redundant und auch nicht sinnvoll redundant anzubieten und es gibt dennoch SLAs. Als Hoster würde ich mir da Reboots vom Host und SAN sparen wollen.
Selbst wenn die ganze Infrastruktur schön redundant ist, bei größeren Systemen unter Last ist die Synchronisation eine längere Angelegenheit, selbst bei nur kurzen Downtimes einzelner Instanzen. Bis da jedes System aktualisiert wird geht Zeit flöten, oftmals leidet die Performance und während des Ganzen bleiben alle bisher nicht gepatchten Systeme verwundbar. Mit Kernellivepatches hat man den ganzen Stress nicht und kann die Systeme neustarten, wenn immer es gerade passt (wenig Last, definierte Wartungsfenster, ...).

Edit: Also ich Niemand mit Updtimefetisch, aber ich halte viel auf Flexibilität was den Zeitpunkt von Reboots angeht und auf zeitnahe Sicherheitsupdates. Live Patches finde ich entsprechend super.
 
Piktogramm schrieb:
@foofoobar
Jain, es kommt sehr aufs Produkt an. Bei vielen mietbaren Instanzen/VMs sind diese nicht redundant und auch nicht sinnvoll redundant anzubieten und es gibt dennoch SLAs. Als Hoster würde ich mir da Reboots vom Host und SAN sparen wollen.
SAN -> IBM SVC + Multipathing
VM -> Live Migration
NAS -> Netapp
DB -> It depends. (Je mehr die DB selber kann umso besser, und je nach DBA :-)
Was ich allerdings unter Linux vermisse ist ein ganz gewöhnlichen Cluster.
Auch wenn es in Summe eher wenig Vorteile gegenüber einer VM mit Live-Migration und verfügbaren Storage bringt.
Piktogramm schrieb:
Selbst wenn die ganze Infrastruktur schön redundant ist, bei größeren Systemen unter Last ist die Synchronisation eine längere Angelegenheit, selbst bei nur kurzen Downtimes einzelner Instanzen. Bis da jedes System aktualisiert wird geht Zeit flöten, oftmals leidet die Performance und während des Ganzen bleiben alle bisher nicht gepatchten Systeme verwundbar. Mit Kernellivepatches hat man den ganzen Stress nicht und kann die Systeme neustarten, wenn immer es gerade passt (wenig Last, definierte Wartungsfenster, ...).
Hauptangriffsvektor sind immer noch die Applikationen. Und wenn eine Anwendung damit nicht klar kommt das einzelne Nodes rausspringen hat meistens die Anwendungsarchitektur ein Problem. (Was allerdings meistens niemand hören will)

Von den echten Problemen die man ihn einem verfügbaren Umfeld hat löst Kernel-live patching höchstens einen Bruchteil.
 
Zuletzt bearbeitet:
devanet schrieb:
Hast du mal explizit den CPU Governor auf "performance" gestellt? Ich habe gemerkt, dass dies für manche Spiele einen erheblichen Unterschied macht (obwohl gamemoderun benutzt wurde).

https://www.thomas-krenn.com/de/wiki/CPU_Governor_unter_Linux_setzen

Auslesen - im Terminal:
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Setzen auf performance im Terminal:
echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Oder bei Mint in den Einstellungen seit Mint 22.1/Xia in Power Management:
Anhang anzeigen 1587033
Ich werde nochmal eine Clean Installation machen. Hatte damals noch die Version 22. Habe noch eine 256GB SSD und werde das Testen. Vielleicht läuft es diesmal ja besser. Eine andere Distribution will ich eigentlich nicht. Bazzite klingt interessant ja, aber ich habe mich gerade recht daran gewöhnt mit Mint. Auch kenne ich schon einige Debian Befehle für das Terminal.
Aber sollte das auch nicht Funktionieren, werde ich definitv Bazzite Testen.
 
@foofoobar
Und in der Praxis gibt es kaum einen Firma, die das so umsetzt, weil es eine Mischung aus teuer, aufwendig, in der Praxis nicht annähernd so gut wie beworben funktioniert. Selbst wenn da irgend eine Firma sich viel Mühe gibt, da ist man im Regelfall dennoch nicht auf Reboots scharf aus bereits benannten Gründen.
 
devanet schrieb:
Hast du mal explizit den CPU Governor auf "performance" gestellt? Ich habe gemerkt, dass dies für manche Spiele einen erheblichen Unterschied macht (obwohl gamemoderun benutzt wurde).

https://www.thomas-krenn.com/de/wiki/CPU_Governor_unter_Linux_setzen

Auslesen - im Terminal:
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Setzen auf performance im Terminal:
echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Oder bei Mint in den Einstellungen seit Mint 22.1/Xia in Power Management:
Anhang anzeigen 1587033
Habe jetzt noch einmal geschaut. Ich habe nur Balanced und Sparen.. Ryzen 5600X.
 
@end0fseven
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver enthält Angaben dazu welcher Treiber eingesetzt wird, das sollte amd-pstate-epp sein und da ist eher interessant was cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_available_preferences an Möglichkeiten bietet energy_performance_preference lässt dann die Einstellung zu. Darüber hinaus gibt es noch div. Dateien die mit amd_pstate anfangen und die auch noch allerhand Anpassungen zulassen. Wobei abgesehen vom Umsellen vom Performanceprofil das viel Gefummel mit wenig ertrag ist.
 
  • Gefällt mir
Reaktionen: end0fseven
Was bei MESA 25 noch dazu kommt ist das man die AMD Treiber ACO only bauen kann
also ohne LLVM.

Das soll den Speicherverbrauch etwas eindämmen da keine unnötigen Abhängigkeiten initialisiert werden müssen.
Link.
https://gitlab.freedesktop.org/mesa/mesa/-/issues/12164

Cross Builds ohne LLVM gehen soweit ich weiß nicht, ältere Treiber wie R300/R600 usw. benötigen die Option.


Für z.B meinen Fall mit RDNA2 kann man die Option "amd-use-llvm" false setzen.
Der AMD-Compiler scheint auch nicht alle Features implementiert zu haben.
Bei mir läuft der Build bis jetzt aber ohne Probleme.
 
Ice-Lord schrieb:
Forbidden West lauf 5 bis 10 FPS besser.
Das ist schon mal eine Ansage, wenn der Vergleich am selben Ort stattgefunden hat.

Ice-Lord schrieb:
Meine Eindrücke sind rein subjektiv.
Die aber sehr positiv.
Ist ja auch völlig in Ordnung. Wenn der Zustand vorher ruckelig war und dann nicht mehr, ist das definitiv eine Verbesserung. Aber oftmals tritt der Placebo-Effekt auf, wenn man von höherer Leistung (ich meine hier primär avg-fps) redet.
 
  • Gefällt mir
Reaktionen: Ice-Lord
Zurück
Oben