AMD Radeon Software AMDGPU PRO 16.40-348864

[d2kx]

AMD Radeon Software AMDGPU PRO 16.40-348864

TREIBER BUILD

16.40-348864

UNTERSTÜTZTE SYSTEME

Ubuntu 16.04 LTS (64-bit)
Red Hat Enterprise Linux 7.2 (64-bit)
Red Hat Enterprise Linux 6.8 (64-bit)

HIGHLIGHTS

<TBA>

DOWNLOAD

AMDGPU PRO für Ubuntu (~104 MB) (https://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Install.aspx)
AMDGPU PRO für RHEL (~122 MB) (https://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-RedHat-Install.aspx)

ONE MORE THING

<TBA>

[Dino-Fossil]

Bietet AMD unter Linux eigentlich ein zu Wattman vergleichbares Tool?

[DevilX]

Gibt es überhaupt aktuell ein Tool für AMDGPU / AMDGPU-PRO?

[iuno]

@Dino-Fossil: nope
@DevilX: was fuer ein Tool?

[Dino-Fossil]

Was ich wenigstens gefunden habe ist, dass evtl. irgendwann Radeon Settings ge-open-sourced wird. Damit besteht eine gewisse Hoffnung, dass auch Linux-Nutzer in Zukunft in den Genuss eines vernünftigen Interfaces für ihre AMD GPU kommen könnten.

Allerdings ist die Linuxentwicklung des AMD-Treibers nach wie vor in der Geschwindigkeit zw. "Gletscherzunge" und "Kontinentaldrift" angesiedelt, weshalb ich befürchte, dass es noch sehr lange dauern wird (es sei denn es tut sich mal ordentlich was mit dem Crimson-Nachfolger).

[@Mirko]

Nein, die GUI wird derzeit nicht mit dem AMDPro-Treiber Stack unter Linux gebundelt. Das GUI unter Linux setzt weit verbreitet auf das KDE Framework 5 auf, daher müsste Qt eigentlich lauffähig sein. Wahrscheinlich wird es aus Lizenzierungsgründen bisher noch nicht gebundelt, weil am Quellcode Anspassungen vorgenommen werden müssten. Das liegt dann sicher nicht in Entscheidung von AMD.

[iuno]

Die Architektur des Kerneltreibers ist ganz anders als bei Windows, man braeuchte also groessere Anpassungen, um ueberhaupt das Tool unter Linux nutzen zu koennen, egal ob open source, mit Qt gebaut oder nicht.
Und dann hat man auch aktuell gar nicht die Schnittstellen, um ueberhaupt viel einzustellen. Man kann iirc den GPU- und Speichertakt aendern und das wars. Da ist wenig mit Spannungen fuer alle DPM States, Luefterkurve usw.

Lustig, dass du die Entwicklung als so langsam empfindest. Wie lange verfolgst du das Thema schon?

[Dino-Fossil]

Lustig, dass du die Entwicklung als so langsam empfindest. Wie lange verfolgst du das Thema schon?

Nun, seit den ersten Ankündigungen ist schon einige Zeit vergangen.
War das so 2014?
Es kamen irgendwann Mitte 2015, glaube ich, die ersten Entwicklerversionen und seit Anfang 2016 findet er langsam den Weg in Linux-Distros, wobei er noch so einige Probleme hat, wenn man sich mal diverse Benchmarks ansieht - stellt mMn mehr eine Beta dar.

Ist natürlich auch der teilweisen Integration in den Linux-Kernel (und den damit verbundenen Zyklen) geschuldet, aber im Vergleich z.B. zum Stand der Windows-Treiber ist amdgpu immer noch weit abgeschlagen.

[d2kx]

Die Architektur des Kerneltreibers ist ganz anders als bei Windows, man braeuchte also groessere Anpassungen, um ueberhaupt das Tool unter Linux nutzen zu koennen, egal ob open source, mit Qt gebaut oder nicht.
Und dann hat man auch aktuell gar nicht die Schnittstellen, um ueberhaupt viel einzustellen. Man kann iirc den GPU- und Speichertakt aendern und das wars. Da ist wenig mit Spannungen fuer alle DPM States, Luefterkurve usw.

Genau das ist die Aufgabe von AMD DAL, der in seiner dritten Version von Grund auf für Windows & Linux entworfen wurde, vom Crimson Edition unter Windows bereits genutzt wird und auch in Zukunft in das freie AMDGPU Kernelmodul einfließen wird und schlussendlich die Radeon Settings portierbar macht. Ein wenig wird das allerdings noch dauern.

[Gast]

Es kamen irgendwann Mitte 2015, glaube ich, die ersten Entwicklerversionen und seit Anfang 2016 findet er langsam den Weg in Linux-Distros, wobei er noch so einige Probleme hat, wenn man sich mal diverse Benchmarks ansieht - stellt mMn mehr eine Beta dar.
Ich finde es auch eine Frechheit was AMD den Linuxusern als final verkaufen will.
Riesen Baustelle und keine wirkliche Besserung in sicht.

Das ist nebenbei auch eins der gründe warum Feral kein AMD Support liefert, unfertige Treiber.

Läuft Freesync eigentlich mittlerweile mal unter Linux?

[iuno]

DAL ist nur Display Kram, ein kleiner Bruchteil vom ganzen Treiber Stack. Die ganze DR Infrastruktur wird sicherlich nicht dadurch ersetzt werden, wodurch eigentlich schon alles ziemlich so aehnlich bleibt wie es gerade ist.
Oder wie kommst du darauf?

Ehrlich gesagt halte ich seit der Praesentation von Harry Wentland auch nicht mehr viel von DAL, aber das ist auch ein eher unwichtiges Detail. Keine Ahnung wer sich das ausgedacht hat, aber so wie es anfangs erdacht war, geht es jedenfalls nicht auf. Und ehrlich gesagt stoert mich das auch nicht.

@Dino: Das erklaert einiges. Linux gibt es nicht erst seit 2014 :D
Was fuer Benchmarks? Linux-Gaming auf technisch hohem Niveau gibt es nicht.
Man muss Profi- und Grosskunden gewinnen, fuer die paar Nutzer mit Linux Desktops, die ein bisschen zocken wollen, wird der ganze Aufwand nicht getrieben. Trotzdem ist was da abfaellt imho ziemlich beeindruckend. Immerhin bekomme ich heute ootb (!) quasi OpenGL 4.5, Vulkan, Videobeschleunigung inkl. HEVC mit 10 Bit, bessere Kompatibilitaet als bei anderen Produkten.
Ja, erste Infos zu den Plaenen rund um die neuen Stacks gab es iirc zur XDC 2014, also vor genau 2 Jahren. Dass der ganze Umbau nicht von heute auf morgen geht war klar, aber besser es wird diesmal richtig gemacht als nochmal in eine Situation zu kommen wie vorher. Und immerhin wurde teilweise auch mehr gemacht als urspr. geplant, z.B. support fuer alle GCN Produkte anstatt derer ab VI.

Natuerlich gibt es noch viele Baustellen, die gibt es aber anderswo auch und wenigstens muss ich dafuer kein Windows benutzen :ulol:

[Dino-Fossil]

Was fuer Benchmarks? Linux-Gaming auf technisch hohem Niveau gibt es nicht.
Phoronix z.B. hat immer wieder mal welche. Ja, die Seite ist nicht immer die beste Quelle, aber sie bringen immerhin regelmäßige Updates zur Grafiktreibersituation unter Linux.
Und was das Linux-Gaming angeht - das ist zu guter Letzt auch der Treibersituation geschuldet. Wobei der proprietäre NVidia Treiber wenigstens (meistens) gut läuft und dann häufig nur wenig langsamer ist als unter Windows.
AMD hat mit radeonsi zwar einen sehr guten offenen Treiber, der gerade in den letzten 1,2 Jahren mächtig aufgeholt hat (nicht zuletzt dank des Engagements von AMD), aber die generell schlechtere OpenGL-Performance schlägt unter Linux oft nochmal richtig durch.


Man muss Profi- und Grosskunden gewinnen, fuer die paar Nutzer mit Linux Desktops, die ein bisschen zocken wollen, wird der ganze Aufwand nicht getrieben. Trotzdem ist was da abfaellt imho ziemlich beeindruckend. Immerhin bekomme ich heute ootb (!) quasi OpenGL 4.5, Vulkan, Videobeschleunigung inkl. HEVC mit 10 Bit, bessere Kompatibilitaet als bei anderen Produkten.

Naja, hat teils auch lange genug gedauert. Ob sich Profi- und Grosskunden davon aber beeindrucken lassen, weiß ich nicht so recht.

Ich klinge hier etwas arg negativ, dabei halte ich amdgpu für eine gute und sinnvolle Sache.
Aber die gebotene Treibersituation ist unter Linux einfach noch nicht da, wo sie hin muss und man merkt einfach, dass Linux nur ein Nebenschauplatz für AMD ist.

[iuno]

Nun, das ganze Engagement bzgl. der freien Treiber kommt aus der CPU Sparte hinsichtlich eben dieser Kunden. Da ist man zum Glueck den imho richtigen Weg gegangen, wie gesagt es dauert halt alles noch etwas. Aber das ganze Projekt sieht mit den Grafik- und ROC Stacks ganz gut aus, imho.

Dass OpenGL Spiele und dann insbesondere auf Linux schlecht performen ist bekannt. Da wird sich aber teilweise wohl nicht konform verhalten und oft genug sind es einfach beschissene Ports, die billigst mittels Wrappern gemacht wurden. Und da ist es mir ehrlich gesagt voellig egal, wie die Performance ist, da soll man ruhig keine Ressourcen investieren. Bevor ich derartige Software benutze kann ich grad auf Windows zocken.

Mit Vulkan koennte sich das aendern, dafuer muesste aber auch langsam mal etwas passieren. Zumindest sind die groesseren Engines jetzt wohl langsam mal so weit, ueberhaupt mal oeffentlich von Vulkan zu sprechen. Ich wuerde mir da mal ordentliche d3d12 Ports wuenschen oder einfach ein Doom, das eh schon mit Vk laeuft.

[Gast]

Testing Deus Ex On Linux With RadeonSI Mesa, AMDGPU-PRO
http://phoronix.com/scan.php?page=news_item&px=Deus-Ex-Mesa-AMDGPU-PRO

[Arcanoxer]

Phoronix hat weitere AMDGPU-PRO 16.40 Benchmarks am Start.

OpenGL vs. Vulkan With AMDGPU-PRO 16.40, Compared To NVIDIA On Lin (http://phoronix.com/scan.php?page=news_item&px=AMDGPU-PRO-16.40-VLK-NV)

Das wird noch ein langer und harter Weg werden.
Selbst mit Vulkan ist man nicht konkurrenzfähig, oftmals sogar langsamer als OpenGL.

[fondness]

Wird da AMDs Open-Source Treiber mit NVs Closed Source Müll verglichen?

[aufkrawall]

Übertreibs nicht, dieser "Müll" liefert bei Spielen die gleiche Performance wie unter Windows...

[fondness]

Übertreibs nicht, dieser "Müll" liefert bei Spielen die gleiche Performance wie unter Windows...

Wer spielt unter Linux? Und selbst wenn, habe ich die Wahl zwischen einem Open-Source-Treiber, wo ich mir genau anschauen kann was passiert und warum (also maximale Transparenz) und Nvidias Wolke.

[aufkrawall]

Wer spielt unter Linux?
Die Performance ist also egal, so lange es open source ist?
Ich beglückwünsche dich zu deiner kruden Argumentation.

[fondness]

Die Performance ist also egal, so lange es open source ist?
Ich beglückwünsche dich zu deiner kruden Argumentation.

Maximale Performance in Spielen gibt es nur unter Windows, im übrigen auch bei Nvidia. Linux verwendet man aus anderen Gründen. Ganz davon abgesehen, dass es die meisten Spielen ohnehin nicht für Linux gibt.

[Achill]

Phoronix hat weitere AMDGPU-PRO 16.40 Benchmarks am Start.

OpenGL vs. Vulkan With AMDGPU-PRO 16.40, Compared To NVIDIA On Lin (http://phoronix.com/scan.php?page=news_item&px=AMDGPU-PRO-16.40-VLK-NV)

Das wird noch ein langer und harter Weg werden.
Selbst mit Vulkan ist man nicht konkurrenzfähig, oftmals sogar langsamer als OpenGL.

Nein, es zeigt nur das Michael den Software-Stack nicht prüft den er da testet bzw. das deine Verallgemeinerung des Tests nicht korrekt ist.

Michael hat in dem Test folgendes "zusammen gesteckt":
- Ubuntu 16.04
- Kernel 4.8.4.x (Custom Kernel, Ubuntu 16.04 LTS hat v4.4.x)
- AMD- & NV-Driver

Michael hat selber geschrieben (andere älter News), dass der Linux Kernel 4.8.x eine Perf-Regression bei AMD-Karten hat! Der "Bug" ist außerdem im Kernel-Code den der AMD-Treiber verwendet, m.W ist es aber kein Code vom AMDGPU....

Die zeigt auch der ältere Test mit Ubuntu 16.04, Standard-Kernel dieser Ubuntu-Version (4.4.x) und den 16.30 Treiber: https://www.phoronix.com/scan.php?page=article&item=amdgpu-rx480-linux&num=11

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=57947&stc=1&d=1478717547

Wenn man ein Custom-Kernel verwendet oder selber baut, muss man natürlich immer prüfen ob noch alles funktioniert / performed wie vorher.

Man kann aber auch einen auf Trump machen...

[aufkrawall]

Maximale Performance in Spielen gibt es nur unter Windows, im übrigen auch bei Nvidia.
Ich habe Talos Principle selbst mit Vulkan unter Linux getestet auf der 1070, das läuft ganze 1fps langsamer als unter Windows und OGL gar nicht.

[Dino-Fossil]

Der freie AMD-Treiber ist zwar um Welten besser als der freie nVidia-Treiber, aber es gibt nix daran zu beschönigen, dass der closed-source Treiber von nVidia unter Linux bessere Resultate liefert als AMDs Treiber.

Es hat sich viel getan, aber mit amdgpu muss noch mehr kommen.

Klar, man kann jetzt argumentieren, dass eh kaum einer unter Linux zockt, nur ist das wenig zielführend.

[fondness]

Ich habe Talos Principle selbst mit Vulkan unter Linux getestet auf der 1070, das läuft ganze 1fps langsamer als unter Windows und OGL gar nicht.

Wer sagt, dass das bei AMD anders ist? Die benchs sind ja offenbar Murks. Die Dota Werte oben sehen mehr als nur gut aus. Ich finde trotzdem, dass das eine akademische Diskussion ist.

[aufkrawall]

Wenn der Phoronix-Bench Murks ist, hast du natürlich recht, dass es kein fairer Vergleich ist.
Deine Aussage mit "maximale Performance nur unter Windows" ist aber trotzdem falsch oder mindestens ungenau, denn der performancebestimmende Faktor ist die genutzte Grafik-API und die Implementierung des Entwicklers, und nicht das Betriebssystem bzw. ist Linux offenbar nicht langsamer als Windows.
(Wobei der AMD OpenGL-Treiber vielleicht unter Linux noch schlechter als unter Windows ist, aber das müsste man auch mal wieder sauber überprüfen.)

[iuno]

@Achill: Ich habe es zuletzt nicht genau verfolgt aber idR. ist nicht jeder ist von Regressionen betroffen, sonst wuerden sie gar nicht erst auftauchen. Wo soll im Kernel ein Bug sein, der fuer Regressionen verantwortlich ist, wenn nicht im amdgpu Modul? Wenn du amdgpu-pro installierst wird im Kernel auch sonst nichts angefasst. Also musst du dich schon entscheiden: entweder ist das Problem ein Allgemeines in 4.8, dann ist egal ob man pro oder free verwendet. Oder er ist im dkms Modul im aktuellen Pro Paket, was impliziert dass er eben doch im amdgpu liegt und nicht ausserhalb dessen irgendwo im Kernel.

Ich will nicht abstreiten, dass es Probleme geben kann, man sollte aber nicht zu viel erwarten. AMD hat momentan keinen Linux Stack, der insgesamt schneller ist als Windows oder gar auf vergleichbarem Niveau wie Nvidia, das ist einfach so.
Uebrigens waren Nvidia Karten in dem aelteren, von dir geposteten Test mitunter auch schneller.

Man muss nur immer wieder daran denken, dass Phoronix Tests qualitativ nichts mit anderen Tests zu tun haben, die wir gewohnt sind. Also sollte man dem sowieso keine allzugrosse Aufmerksamkeit zukommen lassen.

@aufkrawall: sicherlich richtig, aber es gibt immer noch kein groesseres und 'besseres' Spiel das gleichermassen fuer Linux und Windows entwickelt wurde, dementsprechend ist man mit Portierungen auch langsamer unterwegs, auch mit Nvidia, siehe etwa das kuerzlich erschienene Deus Ex. Etwas DOTA als technischen Massstab zu nehmen ist halt auch ein bisschen daneben.

[Lurtz]

Finde ich gar nicht, Dota2 zeigt eben, was mit genug Aufwand möglich ist. Dass diesen Aufwand für unter 1% Marktanteil fast niemand betreibt, ist wieder eine andere Geschichte.

[iuno]

offizielles Zurueckgerudere: https://phoronix.com/scan.php?page=news_item&px=AMDGPU-PRO-Linux-4.8-DKMS

edit: @Lurtz: wo steckt in Dota (oder ueberhaupt in etwas das Valve noch selber macht) viel Aufwand?

[aufkrawall]

Dota 2 läuft nicht gut mit Vulkan, es stockt. Am besten läuft wieder mal DX11.

[Achill]

offizielles Zurueckgerudere: https://phoronix.com/scan.php?page=news_item&px=AMDGPU-PRO-Linux-4.8-DKMS

edit: @Lurtz: wo steckt in Dota (oder ueberhaupt in etwas das Valve noch selber macht) viel Aufwand?

Michael hat das glaube noch nie gemacht (m.W.) - das sieht schon fast nach einer Richtigstellung aus - auch wenn er es nicht direkt sagen kann: Ich hab da Mist gebaut.


Dota 2 läuft nicht gut mit Vulkan, es stockt. Am besten läuft wieder mal DX11.

Nicht unter Linux wie es scheint (wobei ich nicht mit Windows vergleich will) ... ab ~6:00 kommt der Vulkan teil. (Das ist aber streng OT, da OpenSource AMDGPU + OpenSource Vulkan bzw. RadeonSI Treiber)

CXXbMPlE8Dw

[aufkrawall]

Das ist nur ein 30fps Video und er scrollt nicht oder kaum raus.

[iuno]

Naja stimmt schon aber bei dir ist es auch schon eine Weile her oder?
Ich spiele das Spiel nicht sonst koennte ich es auch mal testen.

[Gast]

Michael hat das glaube noch nie gemacht (m.W.) - das sieht schon fast nach einer Richtigstellung aus - auch wenn er es nicht direkt sagen kann: Ich hab da Mist gebaut.So ein Blödsinn, die bekommen einfach keinen Kernelübergreifenden Support für den Treiber hin.

"After talking with John Bridgman last week, AMDGPU-PRO 16.40 is only intended to work with Linux 4.7 kernels and older"

AMD erklärt nun mal einfach ein veralteten Kernel zum standard, oder was willst Du uns damit sagen?

"No error messages are printed when this happens, but hopefully in a future AMDGPU-PRO update they will make it more clear when the unsupported combination is in use."

Das ist ein Trauerspiel für ein sogenannten "Pro" Treiber.

[Achill]

So ein Blödsinn, die bekommen einfach keinen Kernelübergreifenden Support für den Treiber hin.

"After talking with John Bridgman last week, AMDGPU-PRO 16.40 is only intended to work with Linux 4.7 kernels and older"

AMD erklärt nun mal einfach ein veralteten Kernel zum standard, oder was willst Du uns damit sagen?

"No error messages are printed when this happens, but hopefully in a future AMDGPU-PRO update they will make it more clear when the unsupported combination is in use."

Das ist ein Trauerspiel für ein sogenannten "Pro" Treiber.

Der Kernel übergreifende Support von AMD GPUs ist schon eine ganze Zeit direkt im Kernel enthalten. Man *muss* keinen Treiber installieren damit die GPU funktioniert.

Der AMDGPU-Pro Stack bringt u.a. OpenGL Profile für professionelle SW unter Linux mit und ist gegen einen *bestimmten* Stand einer Distribution getestet. Die Software selbst setzt meist auch eine bestimmte Version einer Distribution voraus, wer damit dann produktiv arbeitet nimmt in der Regel nicht irgend ein neusten Kernel oder andere Pakete, sondern den Software-Stack wo auch Support mit eingekauft ist.

Wenn man davon abweicht (und ein anderer Kernel ist eine maßgebliche Abweichung), dann muss man den Test natürlich selbst durchführen / durchführen lassen (das hat man überall wo geprüfte SW-Stacks zum Einsatz kommen - egal ob Linux oder Windows) ...

Das "Trauerspiel" ist also ein anderes.

[..]
After talking with John Bridgman last week, AMDGPU-PRO 16.40 is only intended to work with Linux 4.7 kernels and older while the official focus is on Linux 4.4 of Ubuntu 16.04. I had tested with Linux 4.8 since that's what I was using during the AMDGPU open-source testing as well as during my NVIDIA testing with its proprietary driver, which quickly supports new kernel versions.
[..]


Was ich schon geschrieben habe, der Kernel entsprach nicht dem SW-Stack für den der Treiber vorgesehen ist. Das der OpenSource-AMDGPU mit den Kernel 4.8 geht, liegt einfach darin bedingt, dass dieser eben ein voller Kernel Treiber ist und auch nur mit dieser Kernel-Version funktionieren muss - mann kann davon nicht auf den AMDGPU-Pro Stack schließen.

Phoronix will den Unterschied aber nicht verstehen:

A - "Kernel-Treiber" (OS-AMDGPU)
B - "Hybrid - Teilweise-Closed-Treiber" (AMDGPU-Pro)
C - "Closed Treiber / Kernel Modul" das Kernel- und UserSpace-Schnittstellen implementiert (NV)

Der Grad der Integration/Bindung an den Kernel-APIs und -Verhalten hat natürlich Auswirkungen auf die Kompatibilität.

Im Fall von A muss der Treiber nur zum Kernel selbst kompatibel sein, da dieser den Treiber selbst beinhaltet.

Im Fall von B ist der Closed-Source-Teil auf API & Verhalten von Kernel-Teilen angewiesen. Wenn die API bricht, kann ohne Patch der Treiber bzw. Teile davon nicht mehr geladen werden (die angesprochen Fehler kommen). Im Fall von unterschiedlichen Verhalten gibt es oft keinen Fehler beim "Laden/Initialisieren" sondern erst bei der Ausführung gibt es Abweichungen. Daher wird in diesem Fall ein Menge an Versionen getestet und dafür frei gegeben.

Im Fall von C wird nur noch ein sehr kleiner Teil des Kernels (im Vergleich zu A & B) verwendet, damit sinkt einerseits das Risiko das die API bricht und auch die Abhängigkeit auf konkretes Verhalten des Kernel ist stark reduziert. Dafür muss aber auch die komplette SW-Infrastruktur selbst umgesetzt werden die nachgelagerte Prozesse ihrerseits Konsumieren.


[..]
But the strange thing is when testing on my 4.8 configuration, I don't recall seeing any DKMS errors when installing AMDGPU-PRO 16.40. I've encountered the AMDGPU-PRO 16.40 build problems previously when trying out too new of a kernel on some systems, but during this recent testing I don't recall encountering any problems, obviously otherwise would have reverted to an older kernel, and the 16.40 install process had succeeded.
[..]


Fehler gibt es natürlich bei Inkompatibilität, nicht wenn sich Verhalten in einer neuen Kernel-Version verändert - dies kann zu Fehlern führen oder auch zu anderer Performance - je nach dem was sich ändert.

Nach dieser Logik wird man auf phoronix.com keine Test sehen, wo der NV-Treiber nicht geht - da es hier (Aufgrund des Treiber-Typs) fasst immer nur die Möglichkeiten gibt:
- Geht (phoronix macht ein Test mit der Kernel-Version)
- Geht nicht (phoronix macht kein Test mit der Kernel-Version)

Im Falle des Hybrid-Treibers ist es halt aufwendiger (wenn man ein Performance Vergleich ziehen will) oder es ist nur eine Aussage ob und wie gut der Treiber mit einer anderen Kernel-Version läuft, aber eher ungeeigent um Performance zu vergleichen.

---
Es kann natürlich sein das der 16.40 nicht gut mit Ubuntu 16.04 läuft - aber das müsste phoronix erst einmal Testen. Solange das nicht passieren ist, sind alle Aussagen zu Performance oder Güte im Luftleeren Raum.

---
Oder ganz Platt: Ich tanke auch nicht Diesel wenn ich ein Benziner habe, obwohl die Kohlen-Wasserstoff-Ketten nur etwas länger sind sondern halte mich an die Vorgaben des Fahrzeugtyps - wenn das Auto noch schön weiter laufen soll.

[Gast]

Achill, ich gehe nun nicht auf deine ganze Textmauer ein, die sich um Hals und Kragen redet um eine Erklärung zu finden. Die ganzen wenn und aber bringen den Treiber nämlich nicht weiter.

Thema debugging: Ist im AMDGPU PRO nicht ansatzweise gegeben, dort besteht enormer Nachholbedarf. Selbst AMD Mitarbeiter haben kein Plan wo der Fehler liegt, wie auch?
Wie kann man so etwas vernachlässigen?

"No error messages are printed when this happens, but hopefully in a future AMDGPU-PRO update they will make it more clear when the unsupported combination is in use."

Versuch so etwas mal einen Großkunden (wenn es die überhaupt gibt) zu erklären.
Der wird sich lachend abwenden.

Nur noch so viel, wenn weiterhin versucht wird die Bugs als Feature zu verkaufen wird sich nichts an der Situation ändern und die Kunden werden sich weiter abwenden.

Man muss sich die offensichtlichen Defizite eingestehen und dann gezielt angehen.
Bei der Konkurrenz geht es ja auch!

[Gast]

Wie soll man denn noch genauer dienunterstützten systeme abheben als in den release motes geschehen? Da steht doch klipp und klar


UNTERSTÜTZTE SYSTEME

Ubuntu 16.04 LTS (64-bit)
Red Hat Enterprise Linux 7.2 (64-bit)
Red Hat Enterprise Linux 6.8 (64-bit)


Und das heißt kernel <=4.4 und nicht 4.8.

[iuno]

Versuch so etwas mal einen Großkunden (wenn es die überhaupt gibt) zu erklären.
Der wird sich lachend abwenden.
Und welcher Grosskunde soll das sein, der amdgpu pro mit einem neueren als dem der unterstuetzten Distri gepackten Kernel benutzen will?
;D
Ueber Grosskunden koennen wir uns unterhalten, wenn AMD den ganzen Umbau fertig hat und vielleicht irgendwann mal welche bekommt.

[Gast]

AMDGPU-PRO 16.40 Tests On Deus Ex: Mankind Divided With Ubuntu 16.04
http://phoronix.com/scan.php?page=news_item&px=AMDGPU-PRO-16.40-Deus-MD