News AMDGPU: AMD rüstet die Grafiktreiber für Linux auf

[VikingGe]

Was für einen Unterschied macht denn ein Notebook?

Zum Beispiel, dass sich mit Kernel 4.0 die Bildschirmhelligkeit bei meinem Gerät nicht mehr regeln lässt, was bis einschließlich 3.19 noch wunderbar funktioniert. Catalyst hat(te?) nebenbei genau dasselbe Problem, als ich den mal probiert hatte. Plus ein paar Kaveri-spezifische Probleme vor ein paar Monaten, die aber wohl auch Desktop-APUs betroffen haben dürften.

OpenGL 4.0 ist nicht mehr soo weit weg. Mit etwas Glück noch dieses Jahr?

Naja, 4.0. Die größeren Spiele, die in letzter Zeit herausgekommen sind, brauchen afaik 4.2 und mein eigener Code braucht 4.5.

Ich meine, Mesa ist für nen Desktop + einige 3D-Kleinigkeiten (Indiegames, Kodi, ggf. Emulatoren) absolut ausreichend, aber für Größeres muss ich dann doch entweder auf Windows+Catalyst oder den Desktop mit Nvidia-Karte ausweichen.

1. first class Hardware Support für den open source Treiber und

Gab es da bisher größere Probleme? Habe bisher nur mitbekommen, dass Hawaii wohl nicht so dolle laufen soll, aber bei Nouveau+Maxwell ist die Lage da afaik deutlich dramatischer.

2. Vulkan kommt ja auch noch, und der Treiber sollte schneller zu schreiben sein als das riesige Trumm namens OpenGL,

Das stimmt allerdings. Bleibt zu hoffen, dass a) bald mal die Spezifikationen und Dokumentationen rausgerückt werden und b) Valve nicht die einzigen sind, die ihre Engines auf Vulkan portieren.

 

[chithanh]

Zum Beispiel, dass sich mit Kernel 4.0 die Bildschirmhelligkeit bei meinem Gerät nicht mehr regeln lässt, was bis einschließlich 3.19 noch wunderbar funktioniert.

Das ist meist kein Treiberproblem, sondern dass der Rechner mehrere (ACPI-)Controls zur Einstellung der Helligkeit bietet, von denen aber nicht alle funktionieren. Der Kernel, der das nicht wissen kann, listet dann einfach alle auf.

Manche Desktopumgebungen (z.B. KDE) nutzen nur die erste vom Kernel gelistete, und daher gehen die entsprechenden Hotkeys dann manchmal nicht.

Du kannst unter /sys/class/backlight/ nachsehen, ob es mehrere Backlight-Controls gibt und probeweise ein paar Werte nach "brightness" schreiben.

 

[Zehkul]

… und wenn es wirklich der Kernel sein sollte, geh doch bisecten.

Naja, 4.0. Die größeren Spiele, die in letzter Zeit herausgekommen sind, brauchen afaik 4.2 und mein eigener Code braucht 4.5.

Tesselation ist zum Beispiel ein großer fehlender Baustein, und das neigt sich ja jetzt hoffentlich langsam dem Ende zu. Bis 4.2 dürfte es recht schnell gehen, da schon eine Menge fertig. Darüber hinaus, mal schauen.

http://mesamatrix.net/

Von 4.3-4.5 ist auch viel in Arbeit, und was nicht in Arbeit/bereits fertig ist, wird in vielen Fällen als nutzlos erachtet. Ein Spiel nutzt ja nicht alle Extensions, mit MESA_GL_VERSION_OVERRIDE kann man immer wieder mal was perfekt zum Laufen bringen.

Ich meine, Mesa ist für nen Desktop + einige 3D-Kleinigkeiten (Indiegames, Kodi, ggf. Emulatoren) absolut ausreichend, aber für Größeres muss ich dann doch entweder auf Windows+Catalyst oder den Desktop mit Nvidia-Karte ausweichen.

Catalyst wird unter Windows deinen GL Code auch nicht besser ausführen als unter Linux. Eher schlechter sogar.

Gab es da bisher größere Probleme?

Nö, nur viele Monate nach Kartenrelease überhaupt erst Support, teils Jahre fehlendes Powermanagement bzw. Bugs darin (Für viele erst mit 4.0 wirklich funktionierend), nix dramatisches also.

 

[xmarsx]

Danke fethomm für deine Linuxartikel!

AMD macht es richtig! Die Entwicklung gefällt mir.

Irgendwo habe ich gelesen, dass der Catalyst für AMDGPU ab der R4xx Reihe erscheint.

Für die ältere Hardware wird der Catalyst für den proprietären Kerneltreiber nicht so schnell verschwinden und bestimmt noch einige Zeit weiterentwickelt.

Leider hat man bei AMD wie (offenbar üblich) gepennt, sonst hätte man jetzt wohl eine Betriebssystem übergreifende Lösung in der Hand.

SciTech Software hatte schon vor über 10 Jahren den perfekten Unterbau mit "SciTech SNAP Graphics" (SNAP=System Neutral Access Protocol) oder dem direkten Vorgänger SciTech Display Doctor (SDD). Einige ältere hier im Forum kennen SciTech Software bestimmt, denn von denen kam zu DOS-Zeiten der UniVBE Treiber (die Vorstufe des SciTech Display Doctors).

Damals gab es nur eine Hardwarebeschleunigte 2D-Unterstützung weil die Hersteller damals wie heute auf ihren 3D Chipdetails sitzen wie eine Henne auf Ihren Eiern.

Selbst bei den 2D Funktionen hatte SciTech Software massive Probleme an die nötigen Informationen zu kommen. Einige Kooperationen mit Intel, Matrox und ATI haben damals aber geholfen zumindest die 2D Features weitgehend vollständig abzudecken inkl. z. B. dem Multi-Monitor Support (sprich Dual- bzw. MultiHead), Video-Overlay und so weiter.
Bei nVidia (die waren damals schon die Pest wenn es um Hardware Interna ging...der Linus hat es ja schon mal deutlich formuliert...) basiert die komplette SciTech SNAP Unterstützung auf Reverse-Engineering und den OpenSource X-Treibern für die verschiedenen nVidia Karten.
SciTech SNAP unterstützte an die 240 Chipsatzvarianten!

Es grenzt schon an ein Wunder das SciTech das damals überhaupt hinbekommen mit einer Hand voll Personen (zwei der Entwickler habe ich vor Jahren persönlich kennengelernt und einer von denen arbeitet immer noch für Kendall Bennett).

Der Lohn...:
Ein Treibermodul funktioniert auf jedem von SNAP unterstützten System (sprich OS/2, Linux, Windows, QNX und ....man glaub es kaum AmigaOS, denn auch Hyperion hat 2003 auf SciTech gesetzt).
Das Austauschen der Grafikkarte wurde zum Kinderspiel, weil der SciTech SNAP Loader beim booten den Systemunabhängigen Chip-Modultreiber automatisch wählt und die Einstellungen der alten Karte (Auflösung) direkt übernehmen konnte.
Die übrigen Bestandteile der SNAP Software erlauben die Konfiguration der Grafikeinstellungen.

2006/2007 gab es von SciTech Versuche die 3D-Funktionalität doch noch über eine reine 3D Software-Emulation hinaus zu integrieren (u. a. über Mesa/DRI und SciTech MGL), aber die Hersteller haben die nötigen Details nicht herausgerückt und damit ging es nicht weiter.
Parallel zur 3D-Funktionalität hat man das Konzept von SciTech SNAP von Grafikkarten auf Soundkarten übertragen (SciTech SNAP Audio), aber das lohnte sich "leider" auch nicht.

Vor knapp 7 Jahren (2008) hat Kendall Bennett der Eigentümer von SciTech Software dann aufgegeben und seinen Laden bzw. die Technologie dann an ein anderes Unternehmen verkauft (Alt Richmond Inc), das es für den Embedded Bereich weiter nutzen wollte. Dann war das Produkt leider tot. Angeblich kann man bei Alt Richmond immer noch den Kram lizensieren, aber man hört von denen quasi nichts.
Das war 2008 eigentlich die Steilvorlage für AMD (nachdem man ATI 2006 gekauft hat) den ganzen Kram von SciTech zu kaufen, aber AMD hat zu dem Zeitpunkt (wieder einmal) geschlafen.

Wer noch Details sehen möchte, den verweise ich auf die inoffizielle SciTech SNAP FAQ und die SciTech SNAP OS/2 Chipliste (die Chip-Treiber funktionieren auch auf den anderen Betriebssystemen für die es SciTech SNAP gibt...die Versionsnummer sollte aber weitestgehend passen).


Ich bin mal gespannt wie lange es bei AMD noch dauert bis die neuen Grafikkarten angeboten werden. Das war bisher eine Möglichkeit vom schlecht laufenden CPU Geschäft abzulenken. Die Zahlen des nächsten Quartals (ab dem 15.07. erwartet) werden aber vermutlich nicht besser sein, als die vom 16. April.
Das sich der AMD Aktienkurs (AMD Chart bei Yahoo Finance) verbessert ist daher mehr als fraglich.

 

[VikingGe]

Du kannst unter /sys/class/backlight/ nachsehen, ob es mehrere Backlight-Controls gibt und probeweise ein paar Werte nach "brightness" schreiben.

Hast recht, diesmal funktioniert wenigstens das noch. Beim Catalyst war es aber wirklich ein Treiber-Problem.

Catalyst wird unter Windows deinen GL Code auch nicht besser ausführen als unter Linux. Eher schlechter sogar.

AMDs GL-Implementierung ist vielleicht nicht besonders toll, unterstützt aber immerhin (wenn auch mit Verspätung - GL_ARB_state_access fehlt auch noch) die wesentlichen Features, während bei Mesa nicht nur Tessellation noch fehlt, sondern eben auch Image Load/Store (dürfte ein ähnlicher Brocken werden und ist nebenbei viel interessanter für aktuelle Render-Techniken) - und laut Mesa-Matrix hängt gerade radeonsi nochmal besonders hinterher.

 

[Zehkul]

… sondern eben auch Image Load/Store (dürfte ein ähnlicher Brocken werden und ist nebenbei viel interessanter für aktuelle Render-Techniken)

Und ist auch schon eine ganze Weile in Arbeit. Bei Mesa läuft halt viel parallel, mehr Programmierer an dieselbe Aufgabe werfen, macht es nicht unbedingt schneller.

Aber ja, bis die Radeon Seite aufholt, wird es noch mal ein Stückchen extra dauern (/e: Oder auch nicht, offenbar ist Radeonsi tesselation schon mehr oder weniger fertig), aber erfahrungsgemäß nicht zu lange.