News Radeon unter Linux 6.3: AMD plant zahlreiche neue Features für den neuen Kernel

Ennea schrieb:
Laeuft problemlos, habe ich bereits getestet. Da allerdings KDE derzeit noch einige Wayland-Bugs hat und ich nicht auf Software verzichten will, die grad (unabhaengig von Nvidia) nicht unter Wayland laeuft, bleibe ich derzeit noch bei X11.

Da bist du der erste von dem ich gehört habe.
Konnte es auf 2 verschiedenen Desktops mit NV Karten nicht zum laufen bringen.

Nur auf meinem Laptop aber auch nur weil die Intel iGPU über Optimus verwendet wird.
 
Hm, kurios. War auch gar kein Problem. Keine extra Kniffe oder Konfiguration, es lief einfach.
 
Beelzebot schrieb:
und eine NTFS Partition auf der die Spiele liegen :freak:
NTFS sollte eigentlich keine Rolle spielen. Kann ja Linux schon länger.
 
Aber nicht mit der Performance die die Emulation an den Tag legt. Das waren bei mir man gerade 50MiB/sek, das ist vielleicht ein viertel der Leistung was eine HDD schafft und moderne Spiele brauchen erheblich höhere Durchsatzraten. Das mag mit dem neuen Treiber besser geworden sein, aber spielen wollte ich darauf nicht. Jedenfalls ist das eine häufige Fehlerquelle von Anfängern. Sie hängen ihre bisherige Steam-SSD in Linux ein und wundern sich, dass die Spiele nicht oder nur bescheiden laufen.
Und ich möchte hinzufügen: Ich habe exakt denselben Fehler gemacht.
 
  • Gefällt mir
Reaktionen: Alexander2
Ich bin mal so frech und wünsche mir ein Linux welches es schafft, SÄMTLICHE Spiele aus der 8bit DOS Ära bis hin zu den aktuellen Titeln ohne Gefrickel, bei Bedarf mit Integer-Scaling und/oder Upsampling lauffähig zu machen. Also alles, was auf x86 ausgeführt wurde und wird.

Eigentlich wünsch ich mir sowas von Microsoft als eine Art nahtlos in Windows integrierten Gamemode, der dann halt die meisten alten Sachen virtualisiert ablaufen lässt oder noch besser. Aber so, dass ich es nicht mitbekomme und nicht selbst Hand anlegen muss.

Man wird ja wohl noch träumen dürfen
Für eine solche Linux-Version würd ich auch 500,- zahlen :D
 
daivdon schrieb:
Ja gut, näh, das ist ja beides manuell, das wollte ich gerade nicht. Wenn man das mal vergisst
und dann zu spät zur Arbeit kommt (windows zeigt ja früh genug an), wird das erklären schwierig :p
Aber trotzdem danke, d.h. für mich also daran denken, die einzige Alternative die mir einfällt,
wäre eine Batch-Datei zu schreiben, die den Zeitserver beim Winstart stoppt und manuell synchronisiert. Muss mal schauen ob ich dazu Lust habe..

Eigentlich sollte eine andere Distro getestet werden, aber ich probier das mal aus. Backups spielen für den Einsatzzweck (ausprobieren und reinarbeiten) derzeit keine Rolle).
Höchstens ist Opensuse schon eine zu große Distro.
Du kannst Windows sagen, dass es auch die UTC-Zeit als Grundlage nehmen soll. Dann gibt es kein Problem mehr. Es werden dann in beiden Betriebssystemen die korrekte Uhrzeit angezeigt:
https://techlr.de/dual-boot-windows-10-und-linux-falsche-uhrzeit/
 
DaBo87 schrieb:
Ich bin mal so frech und wünsche mir ein Linux welches es schafft, SÄMTLICHE Spiele aus der 8bit DOS Ära
DOSbox-X macht das doch unter jedem OS?
https://dosbox-x.com/
DaBo87 schrieb:
bis hin zu den aktuellen Titeln ohne Gefrickel, bei Bedarf mit Integer-Scaling und/oder Upsampling lauffähig zu machen. Also alles, was auf x86 ausgeführt wurde und wird.
Der Traum erfüllt dir nicht mal Windows.
 
Gibt es eigentlich nen Vergleich vom alten NTFS Userspace Treiber und dem neuen Treiber der in den Mainline Kernel eingeflossen ist ? Bin mir grad nich sicher ob das schon lang genug her is um in den Distros angekommen zu sein.
 
Beelzebot schrieb:
Ich habe exakt denselben Fehler gemacht.
Ich auch, natürlich, weil es eben so angenehm ist nicht alles hin und her kopieren zu müssen. Aber man hört schnell damit auf die Bibliothek zu teilen, wenn man realisiert dass das das Problem ist und NTFS dazu noch oben drauf zu Problemen führt (auch wenn ich nicht weiß wodurch)

Ja, NTFS wird unterstützt, und dennoch ist das nie dazu gedacht um Das Linux System drauf zu jucken oder programme für Linux. dann doch tatsächlich eher der Kompatibilität wegen um Daten austauschen zu können und ggf. auch um Windeows von der Seite unter die Arme greifen zu können, wenn es sich gerade selber zerschossen hat.

Wie sich hier im Thread herausgestellt hat ist für den Linux Steam Client wohl ext4 die beste Wahl, aus Kompatibilitätsgründen. Wusste ich vorher so auch nicht, aber zumindest mit XFS und BTRFS hatte ich da auch schonmal Probleme.
 
Ja, der Steam-Linux-Client kommt oder kam zumindest bei Release nicht mit 64b inodes klar, sondern nur mit 32b inodes. Eigentlich ist die Software damit locker 20 Jahre veraltet, aber Valve scheint das egal zu sein, weil ext4 noch existiert und dann will man mit nichts anderem testen. Das Problem entsteht dann, wenn eine vom Spiel benötigte Datei in einer Adresse im Dateisystem liegt, die eine Zahl größer als 32b braucht. Ext4 kann halt aus eigener Beschränktheit aufgrund seiner eigenen technischen Veralterung keine inodes größer als 32b haben. 2006 hatte Tseodore T'so, der ursprüngliche Miantainer von ext4, betont, dass ext4 nur eine kurze Überbrückung ist. Das ist jetzt 16 Jahre her und im Home-Desktop-Bereich wird immernoch getan, als sei ext4 der Ultimo-Standard - 2006 ist drei Jahre länger her als das Design-Datum meiner "völlig überalterten" Radeon HD5770 ;)

In der Steam-Community gibt es einen Thread, der das zusammenfast, der aber an manchen Stellen auch zeigt, dass die Community selbst den Anachronismus nicht sieht. Beispielsweise: "a filesystem which always works with 32 bit inodes, e.g. ext4." - da muss ich einfach sagen, eben nicht zum Beispiel, sondern genau ext4 - es sei denn man wertet ext3 und ext2 und ReiserFS3 noch als aktuelle Dateisysteme.

Das es nun gerade mit XFS auffällt, liegt halt daran, dass man sich in den 2020ern eigentlich nur fragt, ob man btrfs oder XFS verwenden soll und btrfs noch meistens wegen der Instabilitäts-Vorwürfe an dessen Volume-Management-Fähigkeiten verworfen wird.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Caramon2
Da hab ich damals ja dire richtige Entscheidung getroffen, vom Athlon II X3 direkt auf Piledriver zu wechseln, statt den damals so beliebten Phenom II X6 zu nehmen. Aber gut zu wissen, weil meine Mutter noch an einem Athlon II X4 sitzt und ich mit dem Gedanken gespielt hatte, wenn Fedora BIOS-Legacy nicht mehr unterstützen sollte, auf OpenSuse zu wechseln. Vielleicht muss sie dann auf ein Kaveri-System umziehen.

Aber ich finde das von Suse durchaus überraschend, weil die bei 32b doch, soweit ich mich erinnere, auch immer i586 statt i686 waren.
 
Zumindest Debian wird i686 wohl noch einige Jahre unterstützen. Und wenn der Linux kernel doch mal auf v2 wechseln sollte, gibt es ja noch BSD :)
 
Beelzebot schrieb:
Aber nicht mit der Performance die die Emulation an den Tag legt. Das waren bei mir man gerade 50MiB/sek, das ist vielleicht ein viertel der Leistung was eine HDD schafft
Das liegt an ntfs-3g. Mit ntfs3 gibt es diesen Flaschenhals nicht mehr.

Wie man das standardmäßig nutzt, habe ich hier beschrieben: https://www.computerbase.de/forum/threads/udev-und-udisk2-regeln-z-b-fuer-ntfs3.2069930/

Anschließend kontrollieren, ob es wirklich übernommen wurde, da manche Distributionen das offenbar ignorieren. Da muss man die Partition eben per fstab schon beim booten mounten.
Ergänzung ()

MountWalker schrieb:
Da hab ich damals ja dire richtige Entscheidung getroffen, vom Athlon II X3 direkt auf Piledriver zu wechseln, statt den damals so beliebten Phenom II X6 zu nehmen.
Dann wird dich das vielleicht interessieren:

Ich bin vor einigen Jahren vom Phenom II X6 (@3,5 GHz bei Standard-vCore) zum FX-8350 (@4,0 GHz bei -100 mV vCore-Offset) gewechselt: Auf dem selben Board, RAM, usw. Turbocore bei beiden deaktiviert.

(Nachtrag: Das war der Phenom II X6 1055T: 2,8 GHz Standardtakt, 3,3 GHz Turbo auf max. drei Kernen. Turbo hat die Spannung deutlich erhöht, ohne Turbo konnte ich sie dagegen ohne diese Spannungaerhöhung mit 3,5 GHz auf allen Kernen takten.)

Da ich die Rechenleistung hauptsächlich für Videoencoding *) nutze, habe ich das miteinander verglichen:

Bei fast identischen Stromverbrauch (der FX brauchte geringfügig weniger), war der FX ca. 1/3 schneller.

*) s. hier: https://www.computerbase.de/forum/threads/videobearbeitung-mit-avidemux.2111091/
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: MountWalker
devanet schrieb:
Dann gibt es kein Problem mehr.
Hat im ersten Anlauf wie gehabt nicht funktioniert, sowohl manuell als auch mit der angebotenen Reg-Datei.
In der Zwischenzeit habe ich Nobara auf die Festplatte gebracht gehabt, jetzt zeigt Win die richtige Uhrzeit an.
Ob das installierte Linux sich anders verhält als wenn es vom Stick kommt, weiß ich nicht, aber die betreffende Reg-Zeile ist unverändert.
Danke übrigens an alle für den Hinweis.
 
daivdon schrieb:
In der Zwischenzeit habe ich Nobara auf die Festplatte gebracht gehabt, jetzt zeigt Win die richtige Uhrzeit an.
Ob das installierte Linux sich anders verhält als wenn es vom Stick kommt, weiß ich nicht, aber die betreffende Reg-Zeile ist unverändert.
Du brauchst doch nur ins BIOS gehen, welche Zeit dort angezeigt wird: Ist es weiterhin die lokale Zeit, hast du mit der Reg. was falsch gemacht: Die funktioniert ab Win2k bis einschließlich Win11 (mit Win XP, 7, 10 und 11 hat es hier bei allen funktioniert, bei denen ich das eingerichtet habe). - Natürlich erst nach einem Reboot.

Nachtrag:

Am PC wollte ich die .reg raussuchen und bin dabei auf eine .txt von 2019 gestoßen, wo ich das einem Bekannten erklärt und ihm noch weitere Tipps gegeben habe:
Ich meine, das hättest du schon gemacht, aber sicherheitshalber:

Erstelle eine Textdatei "Optimierungen10.reg" mit diesem Inhalt (und aufbewahren - am besten mit Beschreibung):

---
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"RealTimeIsUniversal"=dword:00000001

[HKEY_CURRENT_USER\Control Panel\Desktop]
"FontSmoothing"="2"
"FontSmoothingType"=dword:00000002
"FontSmoothingGamma"=dword:00000578
"FontSmoothingOrientation"=dword:00000001
---

Das per Doppelklick in Windows importieren (funktioniert mindestens seit XP und auch unter 10).

Die korrigiert die Uhr auf UTC, damit es zu keinem Konflikt mit Linux kommt und optimiert Cleartype (bessere Schärfe/Kontrast).

========================

Das DOS-Fenster als Admin öffnen und dieses Ausführen:

---
chkntfs /t:0
powercfg /h off
---

1. deaktiviert diesen lästigen Countdown, wenn man für "chkdsk /f c:" rebooten muss (funktioniert auch ab mindestens XP und einschließlich 10)

2. deaktiviert Ruhezustand und Schnellstart, so dass Windows immer sauber herunter gefahren wird und man dann von Linux aus Schreibzugriff hat.

Dann noch in die Datenträgervergewaltigung und der Boot-Partition B: geben, falls noch nicht gemacht:

Dadurch vermeidest du Probleme, da Windows sie nur dann überprüfen kann. - Es kommt unten rechts eine Meldung bzgl. Wechseldatenträger, aber die kommt immer wenn man einen Laufwerksbuchstaben geändert hat und hat nichts mit B: (war ja früher das 2. Diskettenlaufwerk) zu tun. - Also nicht weiter beachten.

========================

Dann reboot und kontrollieren, dass hib/pagefile* wirklich weg sind und dass die Boot-Partition noch B: hat. - Am besten gleich RMB/Eigenschaften und es prüfen: Die Boot-Partition konnte mangels Laufwerksbuchstaben vorher nie überprüft werden.



Vor einer Sicherung zuerst unter Windows RMB/Eigenschaften auf C: und bereinigen (alles markieren und zuerst auf die Systemverwalter-Schaltfläche (o. ä.), dann nochmal alles markieren und auf OK). Danach auch noch die Speicherplatzbereinigung (oder wie das heißt) manuell ausführen (afair auf "jetzt freigeben" klicken und dort auch alles auswählen).

============================

Wenn Win10 beim aufrufen der Datenträgerprüfung (bzgl. B: und C: ) angibt, dass das Laufwerk ohne Fehler und eine Prüfung nicht notwendig ist, dann kann man sich darauf NICHT verlassen: Also trotzdem prüfen, um sicher zu gehen. - Das dauert ja nur ein paar Sek.

Relevant:

Bei Win10 trimmt die Defragmentierung SSDs (anstelle sie zu defragmentieren): Dummerweise (genau wie unter Linux) wird das standardmäßig nur wöchentlich ausgeführt: Also am besten noch vor der Sicherung die Defragmentierung täglich ausführen lassen, damit das nach einer ggfs. nötigen Wiederherstellung nicht vergessen wird.

Nachtrag:

Auch mit dem aktuellen Win11-22H2 funktioniert es noch: Anbei vorher und wie man die .reg importiert (vgl. Uhrzeit Window <-> Host) und nach dem Reboot von Windows.
 

Anhänge

  • UTC-1.jpg
    UTC-1.jpg
    114,6 KB · Aufrufe: 88
  • UTC-2.jpg
    UTC-2.jpg
    40,1 KB · Aufrufe: 87
Zuletzt bearbeitet:
Ich bin seit einem Jahr auf Linux und AMD umgestiegen. Artikel wie dieser freuen mich immer sehr, und ich habe mich deswegen auch schon getraut, die neuesten Kernel zu installieren.
Wirklich schön, wie das alles funktioniert, wenn man vorab auf die Hardwareauswahl achtet.

Spielen habe ich erst gar nicht probiert. Wäre schön wenn es ginge, doch aus Faulheit habe ich von Anfang an beschlossen, einfach ein virtuelles Win10 herzunehmen. Das war nur einmaliges Recherchieren und Konfigurieren.
Da ist auch die nvidia als Passthrough-GPU gut aufgehoben.
 
@Hammerhead Ich kann dir nur raten das mit dem Spielen einfach mal auszuprobieren. Es ist laecherlich einfach. Mit Steam + Proton brauchst du fuer viele Spiele auch null Gefrickel. Du installierst es einfach ganz normal und fertig.
 
Ein klitzekleiner Einwand:
In steam den Haken setzen im Menü, das Proton für alle Spiele genutzt wird (außer native), das vereinfacht das vorgehen indem man auf alles was man in der Bibliothek hat einfach installieren klicken kann.

Die "Whitelist" die Valve führt ist gut und mit glück hat man ja auch eines der Spiele davon, aber trotzdem ist die im vergleich aller Spiele noch immer klein diese Whitelist :-) → Aber, muss man nicht wissen, einfach den haken setzen ...
 
Zurück
Oben