News Linux-News der Woche: Mesa wird Explizit, Updates für Proton, AMD auf RISC-V

Kaito Kariheddo

Redakteur
Teammitglied
Registriert
Dez. 2021
Beiträge
492
  • Gefällt mir
Reaktionen: flo.murr, Letscho, netzgestaltung und 55 andere
Jetzt brauchen wir nur noch gut benutzbare RISC-V Systeme.
 
  • Gefällt mir
Reaktionen: Fritzler, Miustone, Fabii02 und 14 andere
Einfach mal kurz ein Danke an dich für das Linux Write Up! Woher beziehst du deine Infos?

Ich ziehe mir alles aus Phoronix, Hacker News, Gaming on Linux, this week in gnome/kde und /r/linuxgaming zusammen.

Zuerst hat Ferdinand Thommes abgeliefert, dann Sven, nun du, danke dafür!
 
  • Gefällt mir
Reaktionen: flo.murr, Fritzler, Letscho und 30 andere
+1 für die gute und fundierte Zusammenfassung. Lese ich auch sehr gerne.

Liebe Grüße Sven
 
  • Gefällt mir
Reaktionen: Spike Py, Zorror, devanet und 32 andere
andy_m4 schrieb:
Jetzt brauchen wir nur noch gut benutzbare RISC-V Systeme.

Unser Starfive Visionfive v1 ist schon gut benutzbar (wenn auch recht langsam), der v2 besser sein (v.a. ein bisschen schneller).
 
  • Gefällt mir
Reaktionen: andy_m4
@mae Hab gehört das die amerikanischen Behörden nicht kapieren das man ne Architektur nicht am Einführen nach China verhindern kann.

Ist Risc als Architektur neben dem offenen besser als X86? Weniger Backwardskompatibilitätsprobleme I would guess? Arm gilt ja in low power Situationen als effizienter als x86.

Ich mein wenn es halbwegs schnelle Prozessoren ohne Blobs drin gäbe wäre schon viel gewonnen vor allem mit GPUs ohne Blobs. (Firmware)
 
Zuletzt bearbeitet:
blackiwid schrieb:
Ist Risc als Architektur neben dem offenen besser als X86?
RISC-V ist eine Instruction Set Architecture (Befehlsatz) und keine CPU-Architektur.

Man kann verschiedene CPU-Architekturen entwickeln, die mit der RISC-V ISA kompatibel sind.

Letztendlich entscheidet die implementierte CPU (Mikro)-Architektur über die Performance.

Der Witz ist, dass X86 in der Anfangszeit sehr offen war. Intel war damals sehr großzügig mit den Lizenzen. Das hat nicht unwesentlich zur Verbreitung von X86 beigetragen. Mit dem durchschlagenden Erfolg von X86 ist Intel immer restriktiver geworden.
 
  • Gefällt mir
Reaktionen: Tanzmusikus
ETI1120 schrieb:
RISC-V ist eine Instruction Set Architecture (Befehlsatz) und keine CPU-Architektur.
Gut aber das gilt doch auch für X86 oder nicht?

Daher bleibt die Frage die gleiche? Nur halt mit einem Wort ausgetauscht, oder kanns auch noch bisschen in schöner fragen, ist RISC eine bessere Basis für eine Architektur? So wie Arm z.B. bessere Basis für eine Energiesparende Architektur ist wie x86.

Oder sind alle x86 Hersteller nur unfähig und schaffen es nicht ultramobile mit Arm mit zu halten obwohl x86 da keine Steine in den Weg legt?
 
Die Antwort bleibt die gleiche:


Letztendlich entscheidet die implementierte CPU (Mikro)-Architektur über die Performance.


Arm, RISC-V und X86 haben alle notwendigen Befehle, um performante Kerne zu bauen. Und da kommt es eben darauf an was man alles in den Kern einbaut.

Beim minimalen Verbrauch spielt die ISA durchaus eine Rolle. Je umfangreichere der Befehlssatz ist desto mehr Transistoren benötigt der Decoder. Aber da ist inzwischen auch der Befehlssatz von Armv9 zu umfangreich um mit den wirklich schlanken Kernen mithalten zu können.


Zum Thema ISA vs Micro-Architecture gibt es umfangreiche Studien die belegen dass es die Micro-Architecture und nicht die ISA ist, die über Performance und Power entscheiden.

Das hindert natürlich die üblichen Verdächtigen nicht daran den Unsinn immer wieder aufzukochen Arm gehöre die Zukuft weil X86 veralte wäre, X86 an eine Grenze gestoßen wäre.

Ein Aufruf X86 müsse verschwinden hat Chips and Cheese zu einem leicht angesäuerten Artikel veranalasst.

In den Anfangstagen hatten sie schon Mal einen Artikel zu diesem Thema geschrieben.

Bei RISC-V sind einige Hochleistungskerne in Arbeit.

Das kritische ist dass bei X86 nur noch AMD und Intel Kerne entwickeln, währen sehr viele bei RISC-V Kerne entwickeln. Bei Arm sind es eigentlich AFAIK auch nur Apple, Arm und Qualcomm die Kerne entwickeln. Aber alleine Arm hat erheblich mehr Kerne als AMD und Intel zusammengenommen.
 
  • Gefällt mir
Reaktionen: Spike Py, Limit, Unnu und 3 andere
Ist es nicht möglich das Risc-v nicht auch x86 Befehle bzw codec verwenden könnte weil die flexible arbeiten fände ich doch besser. Und das x86 an emde ist kann man so nicht sagen. Es gibt ja bei x86 noch Programme die da lässt die Leistung ja sogar noch steigern. Also auf ganz am Ende sind wir noch nicht ganz. Solange es ipc Verbesserungen gibt, ist dies ja auch kein problem nicht wahr?
 
Herzlichen Dank für die Linux News.
 
  • Gefällt mir
Reaktionen: Kuristina
@Arboster hoffentlich wird es mehr davon geben. ;) Da Microsoft sich so langsam selbst abschafft. ;)
 
  • Gefällt mir
Reaktionen: Kuristina
blackiwid schrieb:
Hab gehört das die amerikanischen Behörden nicht kapieren das man ne Architektur nicht am Einführen nach China verhindern kann.

Ich denke schon, dass die wissen, was sie koennen. Und die RISC-V Foundation ist sofort in die Schweiz umgezogen, als die USA ARM auferlegt haben, nicht nach China zu lizensieren.

Ist Risc als Architektur neben dem offenen besser als X86?

Besser nach welchem Kriterium?

RISCs im allgemeinen und RISC-V im speziellen verursachen weniger Aufwand bei der Implementierung und vor allem bei der Validierung der Implementierung; ein Beispiel fuer die Probleme, die sich daraus ergeben, ist Downfall (wobei Downfall nicht aus den Features herkommt, die von 8086..386 geerbt wurden, sondern von den relativ neuen (2011) AVX-Befehlen, aber wenn sie sich dabei an das RISC-Prinzip "Maximal ein Speicherzugriff pro Befehl" gehalten haetten, haetten sie sich Downfall erspart).

Nichtsdestoweniger hat das weder Intel noch AMD davon abgehalten, sehr schnelle CPU-Kerne zu entwickeln, an die fuer meine Benchmarks niemand anderer herankommt (und bei anderen Benchmarks nur Apple).

Was den Energieverbrauch betrifft, ist die Frage, ob die Unterschiede sich daraus ergeben, dass Intel und AMD seit Jahrzehnten im Wettbewerb um die Geschwindigkeit stehen, der laengste Balken im Benchmark zaehlt, und der laengste Balken im Energieverbrauch wird von den Kunden akzeptiert; nicht einmal bei den Laptops ist es viel anders, wenn auch die Kuehlsysteme dort noch nicht soviel wegkuehlen koennen. Im Gegensatz dazu wurde ARM bei den Mobiltelefonen gross, wo die Power Limits viel niedriger sind, und wo die Prozessoren dauernd laufen, und dementsprechend wurden sie seit Jahrzehnten in diese Richtung entwickelt, und die Entwickler wissen, wie das geht.

Ich mein wenn es halbwegs schnelle Prozessoren ohne Blobs drin gäbe wäre schon viel gewonnen vor allem mit GPUs ohne Blobs. (Firmware)

Da nuetzt RISC-V nichts, weil das ist eine Architektur fuer CPUs, nicht GPUs. Wenn Intel mit Larrabee Erfolg gehabt haette, haetten wir vielleicht weniger Blobs in der Grafik gehabt. Neben der Grafik gibt's auf typischen ARM-SoCs jede Menge Zeug ohne oeffentliche Hardware-Doku, wo Treiber fuer Android-Linux geliefert werden, die nicht gewartet werden, sobald der SoC nicht mehr verkauft wird.

Ich wuerde mir von RISC-V-SoCs nichts besseres erwarten, auch wenn das die RISC-V-Gruender sicher auch lieber anders haetten; aber die Kraefte, die diesen Mist bei den ARM-SoCs verursachen, wirken genauso in den Maerkten, in denen RISC-V unterwegs ist.

Dass es bei den PCs ein bisschen besser ist, liegt eben daran, dass PCs offene Systeme sind, die aus den verschiedensten Komponenten zusammengebaut werden. Zumindest war es frueher so. Mit dem Einzug von Prozessoren auf die Erweiterungskarten selbst konnten die Hersteller dann Teile der Treiber auf die Karten verlegen und die Software dafuer dann in Form von Blobs zur Verfuegung stellen. Und so wachsen die Blobs auch unter Linux seit vielen Jahren.

In der Hinsicht sind die Smartphones wohl noch weniger weit, weil's dort keine separaten Karten gibt, und man wohl auf einem SoC seltener noch einen Extrakern fuer eine Spezialfunktion spendiert, wenn es auf dem SoC ohnehin einen Haufen CPU-Kerne gibt. Aber wenn der Treiber dann nicht gewartet wird, hat man auch wenig davon, selbst wenn der Treiber als freie Software vorliegt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus, DeltaPee und floTTes
Ich freue mich auch immer auf die Rubrik. 🙂 Danke dafür.
 
  • Gefällt mir
Reaktionen: Kaito Kariheddo, Termy und Arboster
Ich bin sehr gespannt, wie es dieses Jahr mit den freien Treibern für RTX-Karten voran geht.
Ist ja leider ein Fakt, dass die meisten doch Grakas aus dem Hause Jenson beziehen, welche ihrerseits sich gern noch mit unter anderem Wayland und besonders Kernelupdates querstellen, sofern diese händisch erledigt werden.
 
  • Gefällt mir
Reaktionen: floTTes
Ich nutze inzwischen auf drei Systemen Manjaro mit KDE Plasma 6. (i7-10875H+UHD630+2070S, i5-7200U+HD620, i7-4810MQ+HD4600) Auf allen dreien habe ich aber kleinere Probleme, die mal nur mit Wayland und mal nur mit X11 auftreten.

Wayland:
  • gefühlte "FPS-Drops" bei manchen Programmstarts, was man daran merkt, dass der Mauszeiger dann entweder kurz stehenbleibt und plötzlich dort auftaucht wo man ihn hinbewegt hat oder sich nur ruckelig bewegt; ebenso passiert das wenn die Maus über die Minimieren/Maximieren/Schließen-Buttons in der Fensterecke fährt und es sich bei den Fensterdekorationen um ein Aurorae-6-Thema handelt
  • gelegentlich ruckelige Animationen
  • Stifttasten des Wacom-Digitiziers werden nicht alle erkannt und man kann ihnen keine Maustasten-Aktionen (z.B. Rechtsklick) zuweisen (nur i5-7200U-System)
  • MPV spielt keine Videos ab (nur der Ton ist zu hören) wenn man das Vulkan-Backend nutzen will. Lusterweise lässt sich die exakt gleiche MPV-Konfiguration (mit Vulkan!) aber in Celluloid verwenden (welches MPV als Backend nutzt)

X11:
  • Bei der Verwendung von Aurorae-6-Fensterdekorationen (z.B. Fluent) sind die Fensterrahmen extrem dick, wenn man DPI-Skalierung (in meinem Fall: 200%) verwendet, selbst wenn man die Dekorationen auf rahmenlos einstellt. Das mitgelieferte Breeze ist davon aber nicht betroffen (weil es wohl nicht auf Aurorae basiert). Abhilfe schafft, wenn man bei den Schrifteinstellungen(!) die DPI-Forcierung für die Schrift ausschaltet, was dann aber in manchen (vor allem nicht Qt-)Programmen zu viel zu kleinen und unleserlichen Schriften führt (betroffen: i7-10875H+UHD630+2070S und i5-7200U+HD620)
  • Zur Konfiguration des Stiftes (i5-7200U-System) benötigt man noch das Paket wacomtablet, das dann aber gar keine Stift-Tasten erkennt, wobei sich (theoretisch) hier Mausklick-Aktionen zuweisen lassen würden

Hat jemand ähnliches beobachtet und eventuell eine Lösung gefunden? Ich bin leider trotz langwieriger Suche in Arch- und Manjaro-Foren sowie Google nicht fündig geworden.
 
ETI1120 schrieb:
Das kritische ist dass bei X86 nur noch AMD und Intel Kerne entwickeln, währen sehr viele bei RISC-V Kerne entwickeln. Bei Arm sind es eigentlich AFAIK auch nur Apple, Arm und Qualcomm die Kerne entwickeln. Aber alleine Arm hat erheblich mehr Kerne als AMD und Intel zusammengenommen.
für die benutzerseite ist auf dauer dennoch entscheidend welche "kerne" tatsächlich in der herstellung landen und dann in der realen welt nutzbar werden...
 
Zurück
Oben