News Tuxedo: Aus für Linux-Notebook mit Snapdragon X Elite

[fdsonne]

Wieso sollte das mit Linux nicht gehen?

Das ist die typische Reaktion, gehen tut vieles, die Frage ist mit welchem Aufwand und zu welchen Kosten. Microsoft bietet mit seinem Entra Cloud Kram eine sehr mächtige Suite, wo quasi alle Features mit Windows, viele mit MacOS/iOS/Android und wenige mit Linux gehen, aber mit mancher Anforderung kommt man da nicht ans Ziel via Linux. Du kannst alles selbst bauen, das ist überhaupt nicht das Thema, sondern am Ende ist die Frage, was kostet es den Spaß zu betreiben, supporten, warten, weiter zu entwickeln usw. SLAs, Verfügbarkeiten, ggf. weltweit notwendige Zugriffe, das fällt nicht vom Himmel und ist für ne IT Abteilung häufig gar nicht im Ansatz ähnlich erschaffbar.

So ganz banale Sachen wie das Client Onboarding über einen Selfservice für BYOD Szenarien oder ein funktionsfähiges Konzept in einem Zero Trust Szenario. Also wo ein ITler nicht das Gerät in die Hand nehmen muss, aber am Ende der User dennoch arbeiten kann. Es gibt auch so nette Spielereien wie VPN less Zugriff auf OnPrem Ressourcen, eine Internet Access Lösung für besagte BYOD Szenarien obwohl der Client kein Firmengerät ist, also nie ein ITler dran war und dennoch der Freelancer im Auftrag vielleicht nicht irgendwelchen quatsch im Netz ansurfen soll.

Man kann das bis sonstwo hin ausdehnen, solange man die Eintrittshürde MS Cloud nimmt. Erfahrungsgemäß nehmen die aber im Business Umfeld recht viele. Aber das ist auch gar nicht das Thema, es ging initial eher darum, dass Windows nicht nur den Vorteil der App Kompatibilität hat. Vor allem im Business nicht. Da zählt Compliance und Unternehmen lassen sich sowas auch noch zertifizieren respektive bewegen sich in diesen Softwaregefilden, weil u.A. diese Zertifizierungen damit relativ einfach erlangbar sind.

 

[eastcoast_pete]

Das n am Ende von Problemen ist zu viel.

Vielleicht war das "n" ein Platzhalter für die Zahl der Probleme ?

Ergänzung (Dienstag um 22:23)

Dass es nicht nur AMDs Verdienst ist, mag sein, aber es ist tatsaechlich unbedingt AMDs Verdienst. Das sieht man schoen bei Nvidia. Da waren genuegend Leute bereit, schwere Arbeit zu leisten, und haben das Nouveau-Projekt auf die Beine gestellt, aber ohne Informationen ueber die Schnittstellen zur Hardware ist das, was da herauskommt, eben doch beschraenkt.

Angeblich haben sie ihre Politik inzwischen geaendert (wobei sie einen Gutteil der Sachen, die sie geheim halten wollen, in einen Blob verschoben haben), aber bis das Fruechte traegt, dauert's halt. Jedenfalls haben Qualcomm und Nvidia zu Linux 6.17 mehr Zeilen beigetragen als AMD, die Frage ist halt, ob dabei Unterstuetzung fuer den Snapdragon X und die Nvidia-Desktop-Karten dabei war.

Ergänzung (Dienstag um 08:37)

Liegt aber offenbar auch daran, von wem man sich dafuer zertifizieren laesst. Bei uns gab's offenbar aus diesen Gruenden Druck, dass jeder Mitarbeiter einen Online-Sicherheitskurs absolvieren muss, aber dass die Mitarbeiter zwangsweise auf Windows und MacOS umgestellt werden, das ist noch keinem eingefallen.

P.S.: Ich vermute einmal, dass MacOS von den Security-Checkbox-Dienstleistern unterstuetzt wird, hat mit Nachfrage zu tun. Dass Linux (z.B. in Form von Ubuntu) nicht unterstuetzt wird, auch.

Bei Qualcomm's engagement bei Linux ist es IMHO schon fast daneben, dass sie schon koennen, wenn sie nur wollen. Im IoT Bereich haben sie es ja gekonnt/gemacht: https://www.qualcomm.com/developer/...comm-linux-unified-simplified-iot-development
Ich nehme einfach mal an, dass dies der Grund ist, warum QC zu Linux 6.17 mehr Zeilen beigetragen hat als AMD; leider scheint das Engagement auf IoT SoCs begrenzt zu sein.

 

[Gullveig]

Nur zur Info: Linux unterstützt setze beliebige Architektur ein seit es Linux und die Architektur gibt.

"Klugscheissermodus an:"
MIPS wird von keiner aktuellen Linux Desktop Distribution mehr unterstützt.

Wenn man dann auf ältere Linux Derivate geht, dann aber auch bei Windows. Und dann schauts mit der Unterstützung auch relativ gleich aus.

ARM wurde von Windows schon 1996 unterstützt.

Bei Windows und Risc-V weiss ich es allerdings nicht wie es da aktuell mit der Unterstützung aussieht.

 

[ETI1120]

Dass es nicht nur AMDs Verdienst ist, mag sein, aber es ist tatsaechlich unbedingt AMDs Verdienst. Das sieht man schoen bei Nvidia. Da waren genuegend Leute bereit, schwere Arbeit zu leisten, und haben das Nouveau-Projekt auf die Beine gestellt, aber ohne Informationen ueber die Schnittstellen zur Hardware ist das, was da herauskommt, eben doch beschraenkt.

AMD ist nicht so bockig wie es lange Nvidia war, AMD verhindert nicht dass andere die Arbeit von AMD erledigen und AMD stellt rudimentäre Doku bereit. Ich finde dafür muss man AMD nicht besonders loben.

wo AMD schon seit vielen Jahren mit ihren CPUs, GPUs, und SoCs ist.

Bei den CPUs segelt AMD ziemlich im Windschatten von Intel. Nachdem Intel so wie es ausschaut bei der Softwareentwicklung für Linux ziemlich gekürzt hat, wird AMD hier erheblich aktiver werden müssen.

Bei den GPUs hat es sehr sehr lange gedauert bis das Umschwenken von AMD tatsächlich Resultate gebracht hat.

"Klugscheissermodus an:"
MIPS wird von keiner aktuellen Linux Desktop Distribution mehr unterstützt.

Welche Desktop Computer mit MIPS gibt es denn?
Keine. Und wieso soll jemand dann eine Linux Desktop Distribution auflegen oder irgend eine Distrubution für Enduser auflegen?

AFAIU hat MIPS im Embedded Umfeld überlebt und es wird immer noch von Linux unterstützt:
z.B.:
https://www.phoronix.com/news/Linux-6.15-MIPS

 

[mae]

"Klugscheissermodus an:"
MIPS wird von keiner aktuellen Linux Desktop Distribution mehr unterstützt.

Von Linux selbst (dem Kernel) schon. Was Distributions betrifft, habe ich einmal bei ein paar geschaut:

Debian 13 (also das aktuelle stable) unterstuetzt mipsel und mips64el als inoffizielle Ports, aber big-endian mips nur bis Debian 11 (oldoldstable, long-term support bis 31.8.2026).

"The mips architecture is supported within Gentoo through the Gentoo MIPS Project."

Bei Openwrt wird viel Hardware mit einer "Pkg Arch" mips_... unterstuetzt.

Und das waren nur ein paar, die ich mir angeschaut habe.

Wenn man dann auf ältere Linux Derivate geht, dann aber auch bei Windows. Und dann schauts mit der Unterstützung auch relativ gleich aus.

MIPS Unterstuetzung in irgendeinem Windows aus diesem Jahrtausend? Alpha? m68K? PowerPC? s390x? HPPA? Loongarch64? RISC-V? SPARC?

Einige wenige davon (WIMRE MIPS, PowerPC und Alpha) wurden von WNT4.0 oder so irgendwann in den 90ern unterstuetzt, das ganze wurde aber mit dem naechsten Windows-Release schon wieder eingestampft, das ist gar kein Vergleich zu der Vielzahl von Architekturen, die von Linux und auch von diversen Linux-Distributionen unterstuetzt werden, und zwar noch immer. Nicht einmal fuer die herausgepickte Rosine MIPS stimmt Dein Befund.

 

[Piktogramm]

Ich finde dafür muss man AMD nicht besonders loben.

Solang AMD durch das "minimale" Verhalten zu den zugänglichsten Anbietern gehört, ist es halt durchaus lobenswert.

Genauso wie Intel Lob dafür gebührt, dass sehr lange FOSS Projekten optimierten Code gegeben haben, Regressionen gefixt wurden und das durchaus in Bereichen wo nicht nur ihre Architekturen dadurch verbessert wurden.

@mae
Naja, viele der selteneren, unterstützten Architekturen brauchen sehr viele Fußnoten, dass da nicht zwingend alle Module verfügbar sind, ohne proprietäre DeviceTrees wenig bis nichts geht, Blobs zwingend sind und so Dinge wie Mesa problematisch werden. Ganz zu schweigen, dass bei vielen Architekturen schon längerfristig keine Tests auf Hardware gefahren werden..
Die Unterstützung ist damit oft irgendwo zwischen theoretisch bis hin, dass die Implementierung in Geräten in proprietären Blackboxes enden, wo es egal ist welcher Kernel läuft.

 

[Gullveig]

@mae
ja, Windows NT stellte damals den Support für MIPS, mit 2000 wurde die Architektur nicht mehr unterstützt.

Aber dann mit Windows CE weit in die Neuzeit hinein. Offiziell wurde die Unterstützung 2011 eingestellt, aber der long term support von Windows CE 6.0 lief bis 10. April 2018.

Also offizielle Unterstützung von Windows bis 2018.

 

[mae]

Solang AMD durch das "minimale" Verhalten zu den zugänglichsten Anbietern gehört, ist es halt durchaus lobenswert.

Ich weiss nicht, woran @ETI1120 das "minimal" festmacht. AMD-Angestellte haben 16085 Zeilen (2.6%) am 6.17 Kernel geaendert und 33176 Zeilen (4.5%) am 6.16 Kernel. Das ist zwar weniger als Intel (beide male knapp 70000 Zeilen und ueber 10%), aber es ist deutlich mehr als "minimal". Je nach Betrachtungsweise aber vielleicht auch weniger, weil sie es sich durch die Codebeitraege ersparen, Dokumentation zu den Schnittstellen herauszugeben (die sie aber vielleicht auch intern nicht in einer Form haben, die man veroeffentlichen kann).

Naja, viele der selteneren, unterstützten Architekturen brauchen sehr viele Fußnoten, dass da nicht zwingend alle Module verfügbar sind, ohne proprietäre DeviceTrees wenig bis nichts geht, Blobs zwingend sind und so Dinge wie Mesa problematisch werden [...] die Implementierung in Geräten in proprietären Blackboxes enden, wo es egal ist welcher Kernel läuft.

Das alles sind eher Probleme der neueren und haeufigeren Architekturen, insbesondere ARMv8-A, aber (abgesehen von den Device Trees) auch bei AMD64. Die aelteren Architekturen haben dieses Problem in geringerem Ausmass bis gar nicht, da die Geraete damals noch nicht so viel RAM hatten, und man da keine Blobs reingeladen hat; Beispiel: Die Matrox Millenium II in unserer Alpha hat WIMRE 4MB RAM und die braucht sie als Videospeicher, da wird nichts fuer einen Blob abgezwackt.

Was den Device Tree betrifft: Irgendwie war das auf unseren Alphas nie ein Problem; WIMRE hat damals der Kernel einfach den PCI-Bus gescant, und die Devices haben sich gemeldet. Warum das heute nicht mehr geht, weiss ich nicht. Klar wollte man sich die Zeit fuer das Scannen bei Booten sparen, aber wenn man keinen Device Tree hat, ist Scannen besser als nichts.

Ganz zu schweigen, dass bei vielen Architekturen schon längerfristig keine Tests auf Hardware gefahren werden..

Irgendwer wird's schon auf realer Hardware laufen lassen und damit testen. Wenn Distributionen das ohne solche Hardware hinbekommen, und es auf realer Hardware dann laeuft, spricht es dafuer, wie gut QEMU funktioniert.

 

[Piktogramm]

@mae
Bei den LoC muss man sehr aufpassen, dass das eine wenig geliebte Metrik ist hat Gründe. Ohne alle Patches zu sichten, kommt AMD meist auf sehr viele LoC weil deren Hardwareenabeling für GPUs ein riesen Haufen an automatisiert erstellten Registerdefinitionen enthält. In einem Umfang, der für alle anderen Hardwareanbieter untypisch ist. Wenn ich das richtig im Kopf habe, sind sich die Maintainer auch einig, dass sie entsprechende Treiber heute so nicht mehr aufnehmen würden.

Um eigene Hardware zu unterstützen ist AMD mittlerweile echt gut dabei. Deren Kram kann man als Linuxer nahezu blind kaufen, selbst wenn man RoCm will. Da ist die RDNA4-Familie ja endlich mal gescheit integriert mit der kommunizierten Linie Consumerlösungen besser einzubinden (glaubhaft, weil mindestens mit einer GPU-Generation umgesetzt im Gegensatz zu Qualcomm..).

Was AMD aber nicht leifert sind Patches wie sie Intel lange geliefert hat. Extrem optimierte Zstd-, Crypto-, Raid-, ... für x86 in SSE2, AVX2, AVX512 oder aber entsprechend optimierter Code in Projekten wie OpenSSL, FFmpeg.

Irgendwer wird's schon auf realer Hardware laufen lassen und damit testen. Wenn Distributionen das ohne solche Hardware hinbekommen, und es auf realer Hardware dann laeuft, spricht es dafuer, wie gut QEMU funktioniert.

Bei den Letzten Zuckungen von Itanium hatten selbst die Maintainer für Kernel und GCC nur virtuelle Testumgebungen. Ob/Wie das auf realer Hardware läuft konnte entsprechend kaum nachvollzogen werden. Was durchaus ein Problem ist, denn so Dinger, dass es AMD immer wieder versemmelt ihre Zufallsgeneratoren stabil hinzustellen (RDseed auf Zen5 ist kaputt, eine Tradition, die sie mindestens seit Jaguar pflegen -.-). Entsprechende Bugs lassen sich nur auf Hardware finden und IA64 zu beschaffen ist kein Kinderspiel.
Bei anderen, obskuren Architekturen wird es nicht besser. Zudem einige der Architekturen derart alt sind, dass etwaige Tests darauf utopisch langsam laufen.
IA64 zu beerdigen ist bereits (wieder) in der Diskussion für GC16 und für die anderen, alten Architekturen sehe ich das auch kommen.


Was deine Warnehmung angeht, dass das früher einfach so ging, und DTs erst später problematisch wurden. Mit der Integrationsdichte moderner CPUs/SOCs, Poermanagement, Modems, PCIe, USB, .. wurde das wirklich komplizierter. Aber die Funktionen will ich und ich wage zu behaupten die Meisten Anwender privat wie professionell.

 

[mae]

Bei den LoC muss man sehr aufpassen, dass das eine wenig geliebte Metrik ist hat Gründe. Ohne alle Patches zu sichten, kommt AMD meist auf sehr viele LoC weil deren Hardwareenabeling für GPUs ein riesen Haufen an automatisiert erstellten Registerdefinitionen enthält. In einem Umfang, der für alle anderen Hardwareanbieter untypisch ist. Wenn ich das richtig im Kopf habe, sind sich die Maintainer auch einig, dass sie entsprechende Treiber heute so nicht mehr aufnehmen würden.

Na ob das besser waere, wenn AMD einen Blob liefert, in dem die Registerzugriffe versteckt werden? Der Blob hat dann zwar ein einfacheres Interface, aber freie Software ist etwas anderes. Ja, AMD laedt in meinem Phoenix trotzdem 2.5MB an Blobs. Trotzdem sehe ich keinen Vorteil, wenn die Zeilen geringer sind und die Blobs groesser.

Was AMD aber nicht leifert sind Patches wie sie Intel lange geliefert hat. Extrem optimierte Zstd-, Crypto-, Raid-, ... für x86 in SSE2, AVX2, AVX512 oder aber entsprechend optimierter Code in Projekten wie OpenSSL, FFmpeg.

Ist m.E. nicht so wichtig, weil Intel und AMD da das Richtige tun: Sie dokumentieren diese Befehlssatzerweiterungen, sodass jeder solche Optimierungen machen kann.

Bei den Letzten Zuckungen von Itanium hatten selbst die Maintainer für Kernel und GCC nur virtuelle Testumgebungen. Ob/Wie das auf realer Hardware läuft konnte entsprechend kaum nachvollzogen werden. Was durchaus ein Problem ist, denn so Dinger, dass es AMD immer wieder versemmelt ihre Zufallsgeneratoren stabil hinzustellen (RDseed auf Zen5 ist kaputt, eine Tradition, die sie mindestens seit Jaguar pflegen -.-). Entsprechende Bugs lassen sich nur auf Hardware finden und IA64 zu beschaffen ist kein Kinderspiel.

Wir haben noch eine RX2600 mit Itanium II herumstehen. Aber wer's beschaffen will, einfach bei ebay fragen. Da habe ich auf die Schnelle das gefunden: HP Integrity BL870c i2 Blade Server 2x 4-Core Itanium2 9320 1,33GHz 64Gb Ram und noch ein paar andere. Also so schwer ist das nicht. Schwieriger wird's, wenn man einen Itanium 95xx oder 97xx will; davon wurden wohl kaum welche hergestellt und daher auch kaum welche weiterverkauft.

 

[Kontrapaganda]

Das ist die typische Reaktion, gehen tut vieles, die Frage ist mit welchem Aufwand und zu welchen Kosten. Microsoft bietet mit seinem Entra Cloud Kram eine sehr mächtige Suite, wo quasi alle Features mit Windows, viele mit MacOS/iOS/Android und wenige mit Linux gehen, aber mit mancher Anforderung kommt man da nicht ans Ziel via Linux. Du kannst alles selbst bauen, das ist überhaupt nicht das Thema, sondern am Ende ist die Frage, was kostet es den Spaß zu betreiben, supporten, warten, weiter zu entwickeln usw. SLAs, Verfügbarkeiten, ggf. weltweit notwendige Zugriffe, das fällt nicht vom Himmel und ist für ne IT Abteilung häufig gar nicht im Ansatz ähnlich erschaffbar.

So ganz banale Sachen wie das Client Onboarding über einen Selfservice für BYOD Szenarien oder ein funktionsfähiges Konzept in einem Zero Trust Szenario. Also wo ein ITler nicht das Gerät in die Hand nehmen muss, aber am Ende der User dennoch arbeiten kann. Es gibt auch so nette Spielereien wie VPN less Zugriff auf OnPrem Ressourcen, eine Internet Access Lösung für besagte BYOD Szenarien obwohl der Client kein Firmengerät ist, also nie ein ITler dran war und dennoch der Freelancer im Auftrag vielleicht nicht irgendwelchen quatsch im Netz ansurfen soll.

Man kann das bis sonstwo hin ausdehnen, solange man die Eintrittshürde MS Cloud nimmt. Erfahrungsgemäß nehmen die aber im Business Umfeld recht viele. Aber das ist auch gar nicht das Thema, es ging initial eher darum, dass Windows nicht nur den Vorteil der App Kompatibilität hat. Vor allem im Business nicht. Da zählt Compliance und Unternehmen lassen sich sowas auch noch zertifizieren respektive bewegen sich in diesen Softwaregefilden, weil u.A. diese Zertifizierungen damit relativ einfach erlangbar sind.

Das ist doch genau das Problem. Wenn die IT bzw. die die meistenns Non-IT-Manager in den Strukturen des Microsoft-Ökosystems denken, wird man immer zu dem Schluss kommen, dass genau dieses Ökosystem alternativlos ist.

Komischerweise werden Linux-Systeme da draußen in der Realität sowohl auf dem Server als auch auf dem Client seit Jahrzehnten produktiv im Unternehmensumfeld eingesetzt. Dafür gibt es espezielle Enterprise-Linuxe mit entsorechendem Supprt dahinter. Den gibt's natürlich nicht für lau. Und diese Enterprise-Linux haben meist auch mit dem dem, bitte nicht persönlich nehmen, zusammengrfrickelten Bleeding-Edge-Rolling-Release Distros wie Arch nicht viel zu tun. Die laufen meist auch nucht auf den allerneuesten Cosnumer-Geräten von der CES mit 1000 Firmware-Bugs. Gerade im Business-Umfeld wird traditionell eher konservativ ältere Software auf nicht ganz aktueller Hardware enigesetzt.

In anderen Ländern steigen ganze Regierungsverwaltungen auf Linux-basierte Systeme um.


Das ist mMn einse der Grundprobleme, warum die Digitalisierung in DE so schleppend voran geht diese "Geht Nicht/Haben wir schon immer so gemacht". In anderen Ländern herrscht dam oft mehr eine Hands-on-Mentalität. Die "machen einfach" mit der Digitalisierung, während der Michel aus D ungläubig zuschaut.

 

[Piktogramm]

Nur weil man keine Registerdefinitionen in den Kernel wirft, heißt das nicht, dass riesige Blobs zum Einsatz kommen müssen. Zudem war das nicht der Argumentationsstrang rund um Blobs, sondern wieso AMD auf recht viele Codezeilen kommt. Die Begründung ist da leider, dass AMD leider sehr viele Codezeilen für die GPU-Treiber braucht.

Da gibt es dann solche Brecher für jede Architektur: https://git.kernel.org/pub/scm/linu...amd/amdgpu/vega10_sdma_pkt_open.h?h=v6.18-rc7

Intel hingegen ist vergleichsweise kompakt:
https://git.kernel.org/pub/scm/linu...nux.git/tree/drivers/gpu/drm/i915?h=v6.18-rc7

Zweitquelle:
https://www.phoronix.com/news/Linux-5.9-AMDGPU-Stats

AMD ist das bewusst, und des wurde sich durchaus Mühe gegeben, da nicht weiter zu eskalieren:
https://www.phoronix.com/forums/for...0-5-of-the-linux-kernel?p=1212149#post1212149

Ist m.E. nicht so wichtig, weil Intel und AMD da das Richtige tun: Sie dokumentieren diese Befehlssatzerweiterungen, sodass jeder solche Optimierungen machen kann.

Das ist nicht realistisch. Entsprechenden Code zu schreiben bedeutet allerhand Aufwand. Privat macht das fast Niemand einfach mal so und geht durch mehrere Runden Review und Tests. Bisher hat sich auch eher gezeigt, dass die entsprechenden Entwickler dafür bezahlt worden.


Das mit dem Itanium.. ja klar ein Haufen Geld ausgeben für eine Kiste die am unterem Ende des Leistungsspektrum ein haufen Energie zieht um unbezahlt in der Freizeit für eine tote Architektur zu entwickeln.

 

[ETI1120]

Solang AMD durch das "minimale" Verhalten zu den zugänglichsten Anbietern gehört, ist es halt durchaus lobenswert.

In diesem Fall trifft "net schimpfee isch gelobd gnuag" tatsächlich zu.

AMD ist schon lange nicht mehr die kleine Klitsche, die gerade so verhindern kann von Intel an die Wand geklatscht zu werden. AMD hat knapp 30000 Mitarbeiter und wird dieses Jahr ungefähr 34 Milliarden USD Umsatz machen. Davon entfällt einiges auf Systeme die mit Linux laufen.

Genauso wie Intel Lob dafür gebührt, dass sehr lange FOSS Projekten optimierten Code gegeben haben, Regressionen gefixt wurden und das durchaus in Bereichen wo nicht nur ihre Architekturen dadurch verbessert wurden.

AMD profitiert massiv von der Opensource arbeit von Intel. Und konnte sich bisher wegen der guten Arbeit von Intel ziemlich zurückhalten.

Aber hier wird AMD, wie schon gesagt, viel mehr tun müssen, damit der gute Support von X86 nicht leidet.

Ich weiss nicht, woran @ETI1120 das "minimal" festmacht.

Das "minimal" kommt von @Piktogramm, nicht von mir.

Minimal in Sinne von das mindeste Tun was erforderlich ist, könnte ich über alles gesehen gerade so unterschreiben. AMD macht auf Seite der CPU definitiv zu wenig, bei den GPUs ist es in Ordnung, bei den adaptive SoC könnte es was werden.

Mit in Ordnung meine ich dass der Support als GPU gut ist. Ich habe mir kurz nach dem Release eine RX5500 zugelegt sie hat auf anhieb tadellos unter Linux funktioniert. Für GPGPU und AI war es viel zu wenig. Ich habe allerdings das Gefühl, dass jetzt der richtige Druck dahinter ist und sich einiges zum besseren verändert.

Man muss natürlich Arbeit an Linux und anderen OpenSorce Projekten auch im Kontext sehen, dass AMD traditionell bei software nicht gut agiert hat. Fusion ist gescheitert, weil AMD es nicht geschafft hat, die notwendige Software bereitzustellen.

AMD-Angestellte haben 16085 Zeilen (2.6%) am 6.17 Kernel geaendert und 33176 Zeilen (4.5%) am 6.16 Kernel.

Lines of Code ist eine nette Statistik aber @Piktogramm erklärt sehr gut warum die Zahl irrelevant ist.

Was AMD aber nicht leifert sind Patches wie sie Intel lange geliefert hat. Extrem optimierte Zstd-, Crypto-, Raid-, ... für x86 in SSE2, AVX2, AVX512 oder aber entsprechend optimierter Code in Projekten wie OpenSSL, FFmpeg.

Genau das ist der Punkt. Hier hat AMD so gut wie alle Arbeit Intel überlassen.

Hinzu kommt, dass AMD mit Anpassungen und Optimierungen für die Compiler notorisch spät dran ist.

Ist m.E. nicht so wichtig, weil Intel und AMD da das Richtige tun: Sie dokumentieren diese Befehlssatzerweiterungen, sodass jeder solche Optimierungen machen kann.

Es ist nun Mal so, dass Code zu optimieren, harte Arbeit ist, die, wenn es zum Beispiel um AVX-512 effizient einzusetzen, nur wenige erledigen können.

Die optimale Performance der Hardware verfügbar machen, ist der Job des Herstellers dieser Hardware. Entweder stellt man die erforderlichen Experten ein oder man heuert sie für Projekte an.

Bei den X86 CPUs hat Intel das bisher getan. AMD nur unzureichend agiert. Da waren Google und die anderen Cloudanbieter erheblich aktiver als AMD.

 

[Piktogramm]

Hinzu kommt, dass AMD mit Anpassungen und Optimierungen für die Compiler notorisch spät dran ist.

Das wurde mit dem fortschreitendem Erfolg von Zen aber auch deutlich besser. Zen6 Enablement ist im Kernel, die binutils haben entsprechende Patches gesehen und auch GCC
https://wccftech.com/amd-zen-6-cpu-core-isa-revealed-avx512-fp16-vnni-int8-more/

AMD ist mit CPU und GPU mittlerweile recht gut darin, dass Day1 der Kram recht gut läuft. Spannend wird es allenfalls, wie gut das mit dem Wegfall von amdgpu mit den GPUs klappt.

 

[ETI1120]

Das wurde mit dem fortschreitendem Erfolg von Zen aber auch deutlich besser. Zen6 Enablement ist im Kernel, die binutils haben entsprechende Patches gesehen und auch GCC
https://wccftech.com/amd-zen-6-cpu-core-isa-revealed-avx512-fp16-vnni-int8-more/

Habe ich gesehen, direkt von @instLatX64 und bei Phoronix.

AMD ist mit CPU und GPU mittlerweile recht gut darin, dass Day1 der Kram recht gut läuft.

Aber das gilt eben nur für die reine GPU-Funktion.

ROCm für Raden bereitzustellen hat Ewigkeiten gedauert. Das hat sich erst geändert, als die (neuen) verantwortlichen bei AMD erkannt haben, dass ohne die Möglichkeit auf Clientside mit ROCm zu entwickeln, ROCm nie ausreichend Entwickler bekommen wird.

Spannend wird es allenfalls, wie gut das mit dem Wegfall von amdgpu mit den GPUs klappt.

In wie fern soll amdgpu wegfallen? das wäre mir neu, dass AMD den kerneldriver einstellt.
AFAIU hat AMD die Arbeit an amdvlk eingestellt und RADV zum offiziellen AMD userspace driver gemacht.

Um wieder On topic zu werden. Ich kann mich noch an Zeiten erinnern, als die Situation mit AMD GPUs unter Linux deutlich schlechter als unter Windows war. AMD hat dann die Open Source Strategie verkündet. Nach ein paar Jahren wurden die Dinge langsam besser. Gut ist die Situation als GPU erst als RADV entstanden ist. Erst jetzt wird es langsam akzeptabel was GPGPU und AI angeht, aber hier ist auch einiges an Hoffnung drin dass der Trend des letzten Jahrs anhält.

Die Situation bei Qualcomm SoCs und Linux ist nicht gut. Aber genauso wie es sich bei AMD von einer jämmerlichen Situation bei den GPUs zu einer ordentlichen Situation entwickelt hat, kann es sich bei Qualcomm entwickeln. Hans DeGoede zu holen ist ein massives Statement von Qualcomm. Wir werden sehen was Qualcomm weiter unternimmt.

 

[Piktogramm]

@ETI1120
Dir scheint ja klar zu sein, dass ich den Userspaceteil gemeint habe, als ich Amdgpu geschriebe habe, wieso also die Argumente zum Kernelteil?

Wie kommst du drauf, dass es bei Qualcomm besser werden könnte? Die eine Personalie machts Kraut nicht fett, vor allem ist ja ersichtlich wie wenig in der Richtung kommuniziert bzw. gepatcht wird. Imho gibt es keine Anzeichen, dass ACPI unter Linux funktionieren wird, ein equivalent zum Qualcomm PEP Treiber für Linux ist nicht in Sicht, native Unterstützung um einen Hypervisor auf EL2 (Exception Level2) laufen zu lassen auch nicht (tldr: kvm geht nicht ohne Hacks).
Würden entsprechende Ziele kommuniziert werden, würde ich kaum vor 2030 damit rechnen. Bisher gibt es nur gar kein Zeichen, dass sich das Ökosystem in die Richtung entwickelt.

 

[ETI1120]

@ETI1120
Dir scheint ja klar zu sein, dass ich den Userspaceteil gemeint habe, als ich Amdgpu geschriebe habe, wieso also die Argumente zum Kernelteil?

Warum schreibst Du nicht was Du meinst?

Wie kommst du drauf, dass es bei Qualcomm besser werden könnte?

Alle Vorhersagen sind schwierig, besonders wenn sie die Zukunft betreffen.

Ich maße mir nicht an zu wissen, was Qualcomm vor hat. Was ich aber weiß ist, wenn man nicht anfängt, wird man auch nie fertig.

Die eine Personalie machts Kraut nicht fett, vor allem ist ja ersichtlich wie wenig in der Richtung kommuniziert bzw. gepatcht wird.

Änderungen beginnen nun Mal damit, dass an die entscheidenden Positionen die richtigen Leute setzt.
Ob es dann funktioniert, wird die Zukunft zeigen.

Imho gibt es keine Anzeichen, dass ACPI unter Linux funktionieren wird, ein equivalent zum Qualcomm PEP Treiber für Linux ist nicht in Sicht, native Unterstützung um einen Hypervisor auf EL2 (Exception Level2) laufen zu lassen auch nicht (tldr: kvm geht nicht ohne Hacks).

Solche Dinge entstehen gewöhnlich aus dem nichts und sind plötzlich da, ist es das was Du sagen willst?

Es ist natürlich vollkommen aus der Luft gegriffen, dass Qualcomm Hans De Goede dazu geholt hat, dafür zu sorgen, dass ACPI auch für Qualcomm SoCs unter Linux funktioniert. Dass er es alleine nicht hinbekommt ist auch klar. Hans De Goede wird schon wissen wen er ins Boot holen muss.

Wenn man Deine Statements in Klartext übersetzt, sagst Du, dass es wahrscheinlich ist, dass Hans De Goede keinen Bock mehr auf Linux und hardwarenahe Software hat und bei Qualcomm nur einen gut bezahlten Bürostuhl angenommen hat.

Würden entsprechende Ziele kommuniziert werden, würde ich kaum vor 2030 damit rechnen. Bisher gibt es nur gar kein Zeichen, dass sich das Ökosystem in die Richtung entwickelt.

Warum sollte man herumschwaffeln. Durch Herumschwaffeln schreibt sich die Software nicht von selbst. Man holt die Leute die dafür notwendig sind und lässt sie es erledigen.

Das schöne ist doch, dass wir sehen werden, wie sich die Dinge entwickeln.

 

[Piktogramm]

Warum schreibst Du nicht was Du meinst?

Weil du normalerweise Ahnung von Linux hast und nicht jeden Happen an Information brauchst. Ich habe schlicht angenommen, dass du weißt, welcher Teil der AMD eigenen Treiberinfrastruktur eingestellt wurde. (TLDR: Ich bin faul)

Solche Dinge entstehen gewöhnlich aus dem nichts und sind plötzlich da, ist es das was Du sagen willst?

Ne, die Aussage ist, normalerweise bekommt man derartig deutliche Strategiewechsel sehr deutlich mit, wenn man das ganze halbwegs beobachtet.

Wenn man Deine Statements in Klartext übersetzt, sagst Du, dass es wahrscheinlich ist, dass Hans De Goede keinen Bock mehr auf Linux und hardwarenahe Software hat und bei Qualcomm nur einen gut bezahlten Bürostuhl angenommen hat.

Dein Klartext ist wilde Spekulation. Was ich meine, habe ich zur Personalie bereits geschrieben:

Weil Intel Stellen gestrichen, Projekte beendet hat. Da kann Qualcomm problemlos grüneren Rasen haben auf den man wechseln will, ohne dass da wirklich viel besser werden muss im Endkundenbereich. Zudem vermute ich, dass Qualcomm sich mit den Margen und Mengen im Endkundenbereich nicht zufriedengeben wird und auch SOCs für Server anbieten wollen wird. Da braucht es dann Mainline und fürs Marketing entsprechend tragfähige Namen für das Versprechen, dass der Kram funktionieren wird.

Ich vermute, dass Qualcomm in das Segment expandieren will, bei dem die Margen besser sind als im Endkundengeschäft. An der Stelle braucht es Mainlinesupport, Kompatibilität zu jeglicher peripherer Hardware. Da würde ich dann auch die Aufgabe von Goede sehen, dieses Segment zum Laufen zu bekommen, ohne dass die Endkundensysteme davon groß berührt werden.
Im Zweifelsfall kommt auch eine große Hexagon NPU Lösung, die ebenso massiv Softwareinfrastruktur braucht um überhaupt irgendwie Aufsicht auf Absatz zu haben.

Vielleicht liege ich auch falsch, und big Q krempelt die Strategie wirklich alsbald um. Es würde mich aber extrem wundern. Qualcomm ist ein Aktienunternehmen und gut profitabel. Ein teurer "Einkauf" wie Goede ist vor Aktionären nicht vertretbar, ohne deutlichen Ausblick auf mehr Einnahmen, Gewinne[1]. Bei den Smartphones ist es egal, die gehen auch so weg. Linuxdistries am Client sind zu klein um eine entsprechende Auswirkung zu haben.

[1] Um "Klartext" Spielraum einzudämmen. Goede allein machts Kraut nicht fett, der Herr wird aber Imho wirklich kein Vertrag unterschreiben, bei dem ihm nicht Ressourcen gewährt werden. In dem Fall also ein paar Stellen potenter (teurer) Softwaredevs. Das sind fix Milliönchen an Personalkosten jedes Jahr.

Warum sollte man herumschwaffeln. Durch Herumschwaffeln schreibt sich die Software nicht von selbst. Man holt die Leute die dafür notwendig sind und lässt sie es erledigen.

Das schöne ist doch, dass wir sehen werden, wie sich die Dinge entwickeln.

Durch Herumschwaffeln schreibt sich die Software nicht von selbst. Man holt die Leute die dafür notwendig sind und lässt sie es erledigen.

Fall du mich mit Schwafeln meinst, ich bin zu deppert zum Treiber entwickeln
Falls du Qualcomm meinst mit Schwafeln, Qualcomm ist ein Aktienunternehmen und haben entsprechend Pflichten gewisse strategische Dinge zu kommunizieren. Genauso wie bei der kooperativen Entwicklung von Linux irgendwann die Hosen runtergelassen werden müssen.

 

[ETI1120]

Fall du mich mit Schwafeln meinst, ich bin zu deppert zum Treiber entwickeln

Nein

Falls du Qualcomm meinst mit Schwafeln, Qualcomm ist ein Aktienunternehmen und haben entsprechend Pflichten gewisse strategische Dinge zu kommunizieren.

Ein paar Softwareentwickler einzustellen, ist kein Grund für eine offizielle Bekanntmachung des Unternehmens.

AMD hat bis heute nicht schlüssig erklärt warum sie mehrere Unternehmen aufgekauft haben, die hohe Expertise in MLIR und IREE hatten.

Hast Du irgend etwas von den Meetings der X86 Advisory Group mitbekommen? Nach der Ankündigung der X86 Advisory Group Funkstille. Unvermittelt gab es den Post von Robert Hormuth auf LinkedIn. etwas später die Pressemittelungen zum einjährigen bestehen und damit war dann rückblickend klar, dass einige Revisonen die Intel an Dokumenten gemacht hat, auf die X86 Advisory Group zurück gingen.

Und so witrd man auch weniog mitbekommen was Qualcomm im Linuxumfeld vorbereitet.

Genauso wie bei der kooperativen Entwicklung von Linux irgendwann die Hosen runtergelassen werden müssen.

Man wird sehen was Hand De Goede und andere von Qualcomm commiten. Die ersten commits mit seinem neuem Account waren noch für X86.

Ich weiß nicht was Qualcomm vor hat. Es ist gut möglich dass Du mit Deiner Skepsis recht hast. Aber es ist genauso möglich, dass Du die Situation falsch einschätzt.

Und was den Server angeht. Wenn Qualcomm keinen Deal mit Microsoft hat, wird es extrem schwer. Ampere hat mit Arm und Softbank im Rücken eine solide Basis und Google und Amazon werden Qualcomm nicht mit offenen Armen empfangen.

 

[mae]

Das ist nicht realistisch. Entsprechenden Code zu schreiben bedeutet allerhand Aufwand. Privat macht das fast Niemand einfach mal so

Da kenne ich durchaus einige Leute. Ein relativ bekanntes Beispiel ist z.B. Alexander Yee. Aber wenn eine Firma will, dass bestimmter Code optimiert wird, dann engagiert sie eben solche Leute, oder sie wenden sich an ihren CPU- oder ggf. GPU-Lieferanten.

Und Intel will natuerlich auch, dass die neueste Befehlssatzerweiterung schnell unterstuetzt wird, bevor AMD sie auch hat, und sie wollen auch, dass die Befehle verwendet werden, die auf Intel schnell sind, und nicht die, die auf Intel langsam sind.

Das mit dem Itanium.. ja klar ein Haufen Geld ausgeben für eine Kiste die am unterem Ende des Leistungsspektrum ein haufen Energie zieht um unbezahlt in der Freizeit für eine tote Architektur zu entwickeln.

Die Behauptung war, dass die Beschaffung "kein Kinderspiel" waere. Also schwierig ist sie nicht. Ob es einem das wert ist, ist eine andere Frage. Offenbar ist das noch genug Leuten ein paar hundert bis ein paar tausend Euro wert (und das trotz des Stromverbrauchs), sonst waeren die Preise niedriger. Andererseits sind das wohl keine Linux-Entwickler, sonst waere IA-64 nicht aus den Kernel-Architekturen entfernt worden.