Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsLinux-News der Woche: ROCm für RDNA 4, Fedora verabschiedet sich von X11
Monate nach Release der RX 9070 (XT) Grafikkarten, bringt AMD nun den ROCm-Treiber. Das Team hinter Fedora setzt ab Version 43 auf einen Wayland-Only-Release mit Gnome. Gallium Nine verschwindet aus Mesa. Ubuntu setzt auf einen neuen Zeitsynchronisations-Dienst. Microsoft trägt zu Mesa bei.
Ich hätte mir gewünscht dass Gallium-Nine durch einen Codebeitrag von MS ersetzt wird der ein vollständiges DirectX Backend für Mesa inkludiert und damit eine Bug-kompatible Version hat und nicht mühsam alles in Vulkan übersetzen muss.
Bin sehr gespannt, wie sich die 9060/XT unter Linux macht.
Ich meine die Woche auch gehört zuhaben, dass KDE mit Plasma 7 wohl Xorg wohl endgültig einstampfen und einen ähnlichen Weg fahren wird, wie das GNOME-Projekt.
Ich mein, mir ist das relativ gleichgültig mittlerweile, da es mit Sicherheit irgendeine Distri auch in Zukunft, für solche Fälle geben wird, wo X11 eben doch die bessere Wahl ist.
Schade, die 9070XT ging ja vor dem offiziellen Support bereits (mit Stable Diffusion), aber ich hatte gehofft, dass die katastrophale Performance mit dem offiziellen Release gefixt ist. Scheinbar ist dem aber nicht so: https://github.com/ROCm/ROCm/issues/4443#issuecomment-2907586796
Muss ich vorerst für SD bei meiner 6900XT bleiben.
Tatsächlich ist die Diffusion bereits ähnlich schnell, nur VAE encoden/decoden ist katastrophal. Mit erzwungener CPU-Variante ist es erträglich, aber immernoch langsamer als mit der 6900XT :/
Ich mein, mir ist das relativ gleichgültig mittlerweile, da es mit Sicherheit irgendeine Distri auch in Zukunft, für solche Fälle geben wird, wo X11 eben doch die bessere Wahl ist.
Alleine schon, weil der Wayland-Support bspw. bei Cinnamon und auch Mate aktuelle immer noch "work in progress" ist, wird X11 weiterhin in den meisten Distributionen erhalten bleiben. Da brauchst du also gar nicht unbedingt auf irgendeine spezielle Distribution mit X11 setzen, sondern alle größeren Distributionen werden das noch ein paar Jahre in den Repos haben, wenn sie nicht die Desktopumgebungen ohne vollen Wayland-Support absägen wollen.
Alleine schon, weil der Wayland-Support bspw. bei Cinnamon und auch Mate aktuelle immer noch "work in progress" ist, wird X11 weiterhin in den meisten Distributionen erhalten bleiben.
Joa, mein PC und mein ThinkPad auf Arbeit laufen beide mit Mint Debian.
Mir ist es da auch relativ egal, ob die mit X oder Wayland laufen und die Distro ist super stabil.
Die Funktionen, für welche ich privat eher an Wayland interessiert bin, bringen mir da ohnehin eher etwas im Hobby was.
Dafür kann ich auf Arbeit wenigstens noch Barrier benutzen und spare mir einen Hardware KM-Switch.
Input Leap funktioniert nach wie vor mit Wayland nicht.
Dass Mesa die "hingeschissenen" 62k LOC von Microsoft akzeptiert, die keinem FOSS-Projekt, sondern ausschließlich Microsoft dienen, finde ich ehrlich gesagt sehr schade.
Schön, dass Microsoft sich beteiligt, aber:
1.) einen so riesigen Drop kann doch keiner vernünftig reviewen
2.) ist fragwürdig, ob Microsoft auch den Pflegeaufwand übernehmen wird
3.) hat es ausserhalb von Windows keinerlei Nutzen
@riloka
Das ist eine Ecke komplizierter, und lustigerweise hat Microsoft da schon allerhand in Bewegung gesetzt, das es Vereinheitlichung geben wird.
DirectX als Programmcode wird vor Auslieferung im Regelfall zu DXIL übersetzt. DXIL ist eine sogenannte Zwischensprache und ähnelt Maschinenbefehlen/Assembler. Um diesen Code auszuführen muss von DXIL der eigentliche Maschinencode für die konkreter Architektur der Grafikkarte abgeleitet werden (das erfolgt auf den Rechnern der Nutzer·innen). Unter Windows können die Grafikkartentreiber mit den mitgeliefertern Kompilern direkt DXIL übersetzen, unter allen anderen Systemen muss DXIL transformiert werden. Die Übersetzung derfolgt zu SPIR-V, was ebenso eine Zwischensprache ist. SPIR-V wird dann wieder durch den Kompiler des Grafiktreibers gejagt, um Code für die GPU zu erzeugen.
Vulkan wird immer zu SPIR-V übersetzt und jetzt kommt der große Knaller, ab Shadermodell 7.0 (nahe Zukunft) wird DirectX auch SPIR-V unterstützen und DXIL perspektifisch ausrangieren: https://devblogs.microsoft.com/directx/directx-adopting-spir-v/
Selbstlos macht das Microsoft auch nicht. In gemischten, virtualisierten Umgebungen geht GPU-Beschleunigung besser, wenn man SPIR-V Weiterreichen kann, die GPU-Architekturen der ARM SOCs (ARM Mali, PowerVR, Qualcomm Adreno) sind alle ganz gut darin SPIR-V zu verarbeiten und DXIL ist eher fremd.
Dass Mesa die "hingeschissenen" 62k LOC von Microsoft akzeptiert, [...]
1.) einen so riesigen Drop kann doch keiner vernünftig reviewen
2.) ist fragwürdig, ob Microsoft auch den Pflegeaufwand übernehmen wird
3.) hat es ausserhalb von Windows keinerlei Nutzen
Ein großteil der FOSS-Projekte existiert, weil irgendwer sein Problem gelöst haben wollte. Egal ob das so ein finischer Student war, der seinen Rechner betreiben wollte, oder ein Prozessorhersteller dem 1024 CPU-Threads perspektifisch zu wenig waren.. Hier will Microsoft ihre Problemchen gelöst haben, das ist in Ordnung.
Die Commits für Grafiktechnologien sind immer wieder riesig. Die 62k Loc sind jetzt kein Ausreißer, der auffällig wäre und Microsoft hat mittlerweile den Ruf, dass sie sich langfristig um ihren Kram kümmern und die Qualität des Codes ist seit etwa einer Dekade auch in Ordnung.
Photon schrieb:
Wie kommt es denn, dass AMD nur Ubuntu und RHEL unterstützt? Können andere Distros die neue Version nicht auch pakettieren und anbieten?
Die Maintainer der anderen Distributionen müssen sich da im Zweifelsfall drum kümmern. Was durchaus allerhand Arbeit bedeutet, der RoCm-Stack ist komplex, hat allerhand Abhänigkeiten und wenn sich APIs der Abhänigkeiten ändern bedeutet das ernsthaft Arbeit. Das man sich da auf wenige, verbreitete Distributionen zurückzieht, wo sich die Abhänigkeiten vorhersehbar zur nur den Releases ändern ist verständlich.
Zudem ist RoCm lange ein Projekt gewesen, was sich an gewerbliche Abnehmer richtet, entsprechend ist es sinnvoll die großen Distributionen mit gewerblichen Nutzern abzudecken. Das RoCm überhaupt minimal Unterstützung für die GPU-Modelle für Endnutzer erfährt ist ja schon ein kleines Wunder.
@Piktogramm
das hilft aber auch nicht für ältere Spiele für andere Versionen von DirectX. Da wird man wohl weiter auf mühsame, performance-beeinträchtigende Zwischenstufen setzen die nur eine Näherung ans Original sind
@riloka
So groß ist der Overhead ja nun auch nicht und der Großteil landet eh im Shadercache[1], die Performance ist im Regelfall ganz in Ordnung und "nur" beim Raytracing holpert es noch arg.
Zudem, mit der Ankündigung vom Abschied von DXIL wird kein GPU-Hersteller noch Mesa-Entwickeler·in dafür offen sein Kompiler für DXIL->GPU-ISA zu programmieren, einzupflegen und zu warten.
[1]Mit Steam bekommt man ja gernmal den Shadercache per Download anstatt da selber CPU-Zyklen drauf werfen zu müssen.
@ETI1120
Das glaube ich erst, wenn ich zwei GPU-Wechsel mit Unterstützung selbst erlebt habe!
Ich hatte trotz Versprechungen von AMD wie geil GPGPU sei noch keine GPU/APU von AMD wo das geklappt hat. Egal ob OpenCL oder RoCm, die GPU-Architekturen die ich hatten zusammen mit dem Sofwarestack immer eine bunte Mischung aus "noch nicht unterstützt", "Bugfest" und "die GPU ist zu alt wir unterstützen sie nicht mehr".
Dass Mesa die "hingeschissenen" 62k LOC von Microsoft akzeptiert, die keinem FOSS-Projekt, sondern ausschließlich Microsoft dienen, finde ich ehrlich gesagt sehr schade.
Schön, dass Microsoft sich beteiligt, aber:
1.) einen so riesigen Drop kann doch keiner vernünftig reviewen
2.) ist fragwürdig, ob Microsoft auch den Pflegeaufwand übernehmen wird
3.) hat es ausserhalb von Windows keinerlei Nutzen
Richtig. Microsoft arbeiten dienen nur der Erhaltung des eigenen Monopols.
WSL ist keine Implementierung der APIs und ABIs von Linux (oder gar POSIX). Es soll Migrationen von Windowsanwendern auf Linux verhindern. Speziell Entwickler die lieber ein Entwicklerbetriebsystem hätten (Coreutils, Shell, Control-Groups, Namespaces, Container) sollen von der Migration abgelenkt werden.
// edit
Geändert hat sich in dem Konzern nichts.
SecureBoot, wieder mit Zertifikaten. Nachdem das bei SSL/TLS im Internet schon ein Desaster war. Warum keine privaten/öffentlischen Schlüssel?
Azure und Zwangscloud in Windows
Windows 11 mit TPM2 Zwang
Zwangscloudaccounts
Zwangsupdates und Zwangsreboots in allen PC-Versione
Exklusivdeal mit Qualcomm über ARM um den Markt abzuschotten. Verlierer? Qualcomm. Und Linux. Das ist 1:1 das Vorgehen aus den 90ern.
Und dann Microsoft Teams. Es ist humoristisch schlecht. Aber dann wird der Videocallbutton in Firefox ausgegraut, obwohl es über geplante Meetings perfekt funktioniert. Safari wird auch geschickt blockiert, die passende Fehlermeldung - mit Hinweis zu einem Workaround - kommt beim dritten oder vierten Versuch.
Wieso darf ein Monopolist überhaupt neue Märkte betreten? Früher wurde reguliert. Und so hat AT&T und allen UNIX, C und quelloffenen Code gegeben.
Das glaube ich erst, wenn ich zwei GPU-Wechsel mit Unterstützung selbst erlebt habe!
Ich hatte trotz Versprechungen von AMD wie geil GPGPU sei noch keine GPU/APU von AMD wo das geklappt hat.
Das Problem ist ganz einfach, AMD bekommt es hin oder AMD läuft gegen die Wand. Ohne Entwicklermaschinen wird es auf Dauer nicht gehen. Und für die Entwicklermaschinen braucht AMD Client-GPUs oder APUs.
Das was Du beklagst liegt eben daran, dass AMD bei der Entwicklung der GPU-Hardware die Anforderungen der Software nicht berücksichtigt hat. Und wenn die Hardwareentwickler die Kompatibilität nicht im Fokus haben, dann wird die Softwareentwicklung zur Sisyphus-Arbeit.
Dass RDNA und CDNA wieder zusammengeführt werden war überfällig und wenn AMD mit UDNA tatsächlich bei der Hardwareentwicklung auf Rückwärtskompatibilität achtet, könnte es klappen. Mal schauen.
Ich bin gespannt, ob tatsächlich AMD an einem Backend mit MLIR arbeitet.
Klar irgendwann muss ein Schnitt kommen, aber wenn man wie Nvidia Hard- und Software Hand-in-Hand entwickelt, dann kann man das alles in Ruhe und geordnet machen. Und nicht in der Release Notre schreiben, übrigens Polaris wird nichtr mehr unterstützt. Nvidia bereitet die Anwender darauf vor, dass die neuen Hauptversionen Maxwell Pasacal und Volta nicht mehr unterstützen werden.https://www.phoronix.com/news/NVIDIA-CUDA-Upgrade-Post-Volta
SweetOhm schrieb:
Das waren noch Zeiten, als ROCm noch CUDA "durfte" ...
Was das sollte habe ich nie verstanden. Es ist offensichtlich, dass das nicht gut gehen konnte. Es hat zudem vom eigenen Softwarestack abgelenkt.
Das eigentliche Problem das AMD hat, ist dass sie einen AI Stack benötigen der CPU, NPU und GPU unterstützt. Das hatte Victor Peng 2022 angekündigt, aber momentan redet alles vom GPU Stack.
