Am 30.11.2016 um 00:32 schrieb Peter Mc Donough:
Hi,
tut sich eigentlich etwas bei dem proprietären amd-Treiber für suse, sei es Leap oder Tumbleweed? Ich hatte ihn gerne für meine AMD RX 460 wegen openCL für Darktable
Für Ubuntu 16.4 gibt es sich Anleitungen, ich finde jedoch nichts für suse.
Hallo zusammen, ich wollte mich kurz zum Status von AMDGPU-Pro auf openSUSE melden. Das neue Installationsskript ist im Moment noch sehr rudimentär. Das Umverpacken von AMDGPU-Pro für openSUSE funktioniert schon mal so wie geplant. Als ich die AMDGPU-Pro Pakete auf meiner aktuellen Maschine mit openSUSE 42.1 + Kernel 4.9 (wegen meiner Grafikkarte Radeon R9 290X auf Basis der Southern Island Architektur) installierte, hing der X-Server sich beim Booten natürlich auf. Ein Blick in die Logdatei offenbarte, dass der X-Server einfach zu alt war und die ABI-Version sich unterschied. Die Installation eines neuen X-Server aus dem openSUSE-Repo funktionierte leider auch nicht, weil hier viel zu neu. Also begann ich auf der Maschine in einer separaten Partition openSUSE Leap 42.2 neu zu installieren und band den Kernel-Repo ein, um den Kernel 4.9 auch dort zu installieren. Danach baute ich für diese openSUSE-Version über das Installationsskript nochmal die AMDGPU-Pro Pakete und installierte diese. Nach einem Neustart tippte ich folgendes in die Konsole. # lsmod | grep radeon Und hatte quasi keine Ausgabe, somit wurde der Open-Source Radeon-Treiber aus dem System verbannt, was im Prinzip ja bezweckt wurde. # lsmod | grep amdgpu Ausgabe: mfd_core 16384 1 amdgpu i2c_algo_bit 16384 1 amdgpu drm_kms_helper 159744 1 amdgpu ttm 102400 1 amdgpu drm 360448 14 amdgpu,ttm,drm_kms_helper In der o.g. Ausgabe sah ich, dass der AMDGPU-Treiber geladen und auch aktiv war. Die Ausgabe von hwinfo bestätigte das nochmal. # hwinfo --gfxcard Ausgabe: 39: PCI 100.0: 0300 VGA compatible controller (VGA) [Created at pci.378] Unique ID: VCu0.2+ifnaJv4L1 Parent ID: _Znp.+7g4VeAizS0 SysFS ID: /devices/pci0000:00/0000:00:02.0/0000:01:00.0 SysFS BusID: 0000:01:00.0 Hardware Class: graphics card Model: "XFX Pine Double Dissipation R9 290X" Vendor: pci 0x1002 "ATI Technologies Inc" Device: pci 0x67b0 "Hawaii XT / Grenada XT [Radeon R9 290X/390X]" SubVendor: pci 0x1682 "XFX Pine Group Inc." SubDevice: pci 0x9290 "Double Dissipation R9 290X" Driver: "amdgpu" Driver Modules: "drm" Memory Range: 0xc0000000-0xcfffffff (ro,non-prefetchable) Memory Range: 0xd0000000-0xd07fffff (ro,non-prefetchable) I/O Ports: 0xe000-0xefff (rw) Memory Range: 0xfea00000-0xfea3ffff (rw,non-prefetchable) Memory Range: 0x000c0000-0x000dffff (rw,non-prefetchable,disabled) IRQ: 35 (70884 events) I/O Ports: 0x3c0-0x3df (rw) Module Alias: "pci:v00001002d000067B0sv00001682sd00009290bc03sc00i00" Driver Info #0: Driver Status: radeon is not active Driver Activation Cmd: "modprobe radeon" Driver Info #1: Driver Status: amdgpu is active Driver Activation Cmd: "modprobe amdgpu" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #22 (PCI bridge) Primary display adapter: #39 Danach überprüfte ich, ob GLX mit der AMDGPU-Pro zusammenarbeitete und bekam folgende Ausgabe. # glxinfo Ausgabe: name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: AMD server glx version string: 1.4 server glx extensions: [...] client glx vendor string: AMD client glx version string: 1.4 client glx extensions: [...] GLX version: 1.4 GLX extensions: [...] OpenGL vendor string: Advanced Micro Devices, Inc. OpenGL renderer string: AMD Radeon R9 200 Series OpenGL core profile version string: 4.5.13462 Core Profile Context OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: [...] OpenGL version string: 4.5.13462 Compatibility Profile Context OpenGL shading language version string: 4.50 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL extensions: [...] OpenGL ES profile version string: 4.5.13462 Compatibility Profile Context OpenGL ES profile shading language version string: 4.50 OpenGL ES profile extensions: [...] Dann startete ich das Mesa-Demo-Programm "glxgears" und bekam die berühmten animierten 3 Rädchen zu Gesicht. Die Installation war also scheinbar geglückt. Dann installierte ich ein paar Open-Source 3D-Spiele und startete diese. Ich konnte sehr flüssig damit spielen. Es lief bis hierhin ziemlich stabil. Dann prüfte ich nochmal, ob OpenCL aktiviert war und auch verwendet werden konnte. # clinfo Ausgabe: Number of platforms: 1 Platform Profile: FULL_PROFILE Platform Version: OpenCL 2.0 AMD-APP (2236.5) Platform Name: AMD Accelerated Parallel Processing Platform Vendor: Advanced Micro Devices, Inc. Platform Extensions: cl_khr_icd cl_amd_event_callback cl_amd_offline_devices Platform Name: AMD Accelerated Parallel Processing Number of devices: 2 Device Type: CL_DEVICE_TYPE_GPU Vendor ID: 1002h Board name: AMD Radeon R9 200 Series Device Topology: PCI[ B#1, D#0, F#0 ] [...] Die o.g. verkürzte Ausgabe bescheinigte mir, dass OpenCL eingebunden und lauffähig war. Das war schon mal sehr gut. Dann wollte ich die Hardware-Videobeschleunigung VDPAU mit AMDGPU-Pro ausprobieren. "vainfo" sagte mir erst, dass kein VDPAU-Treiber vorhanden war. Das fand ich sehr merkwürdig. Nach eingehender Untersuchung wurde der VDPAU-AMDGPU-Pro Treiber von AMD nur falsch benannt. Ich erstellte einfach ein Symlink zur ursprünglichen Datei und siehe da "vainfo" sagte, dass er darauf zugreifen konnte. Ich lud mir ein Test-Video (H.264/AVC) über YouTube per "youtube-dl" herunter. Danach installierte ich VLC aus dem Packman-Repo und konfigurierte VLC auf VDPAU. Zum Abschluss startete ich das Video. Die Systemaktivität von KDE bescheinigte mir, dass sich die CPU quasi mit 1% Auslastung langweilte. Auf meinem Produktivsystem lief das Video ohne Hardware-Beschleunigung mit 7% CPU-Auslastung. Das war beeindruckend und funktionierte also. "vainfo" von AMD gab folgendes aus: libva info: VA-API version 0.39.4 libva info: va_getDriverName() returns 0 libva info: Trying to open /opt/amdgpu-pro/lib64/dri/amdgpu_drv_video.so libva info: Found init function __vaDriverInit_0_39 Warning: LLVM emitted unknown config register: 0x4 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.39 (libva 1.7.3.pre1) vainfo: Driver version: mesa gallium vaapi vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileH264Baseline : VAEntrypointVLD VAProfileH264Main : VAEntrypointVLD VAProfileH264High : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc Als nächsten Test kam Steam dran und installierte es. Als ich es starten wollte, war mir dabei plötzlich Steam und auch gleich der X-Server zusammengebrochen. Dann befand ich mich nur noch auf der Konsole wieder. WTF?! Es lief doch alles wunderbar, was war denn da passiert?! Die Logdatei vom X-Server gab nur Speicherzugrifffehler wieder. Dann schaute ich mir mal die Pakete an, die Steam bei der Installation benötigte und entdeckte, dass 32-bit Libraries benötigt wurden und somit zusätzlich der Open-Source AMDGPU-Treiber in der 32-bit Version installiert war. Klar, dass es hier mit dem proprietären Treiber AMDGPU-Pro kollidiert war. Ich schaute mir die originalen AMDGPU-Pro Pakete von AMD an und sah für SLED 12 SP 2 kein einziges 32-bit Paket. Bei den anderen Paketen für RHEL 6.8/7.3 sowie Ubuntu 16.04 waren die 32-bit Pakete gleich on Board. Prima, AMD, für SLED 12 SP 2 (letztendlich auch für openSUSE Leap 42.2) habt ihr es natürlich voll in den Sand gesetzt. Qualitätskontrolle hat mal wieder bei AMD versagt, wie man es schon früher von AMD Catalyst (fglrx) kannte. -_- Ich begann die Pakete von RHEL 7.3 und Ubuntu 16.04 zu inspizieren und entdeckte, dass die AMDGPU-Pro 32-bit Libraries von Ubuntu 16.04 auch für openSUSE Leap 42.2 brauchbar waren. Also installierte ich kurzerhand die benötigten Libraries per Hand an die richtigen Stellen. Nach einem Neustart war ich natürlich gespannt, ob sich Steam nun starten ließ. Ein Klick auf Steam und es meldete sich wie gewohnt mit einer Anmeldemaske. Ok, bis hierher warst du vorhin noch gar nicht gekommen. Dann loggte ich mich in Steam ein und installierte zum Test ein 3D-Spiel "7 Days to Die" über Steam. Das Spiel ließ sich starten und war ziemlich flüssig. Bemerkenswert. Dann hatte ich noch mein Sorgenkind "Universe Sandbox 2" in der Steam Bibliothek. Diese Universum-Simulation ließ sich nicht mit dem Open-Source Radeon-Treiber geschweige mit AMD Catalyst (fglrx) zum Laufen zu bewegen. Ich installierte es und ein Klick auf "Starten" rührte sich erstmal nix, soweit war ich bisher auch gekommen. Dann plötzlich öffnete sich tatsächlich das Programm und ich bekam zum ersten Mal die Oberfläche zu Gesicht. Donnerwetter, jetzt lief auch "Universe Sandbox 2". Wäre nicht dieser blöde Faux-pas von AMD mit den fehlenden 32-bit Libraries von AMDGPU-Pro, wäre ich jetzt mit dem automatisierten Paketbau fertig gewesen. Aber nein, irgendwas ist immer. Dies habe ich bereits direkt an AMD gemeldet und hoffe, dass sie es demnächst in den Griff bekommen und neue Pakete für SLED 12 SP 2 bereitstellen. Puh... Bis der AMDGPU-Pro-Treiber für die Allgemeinheit lauffähig wird, dauert leider noch etwas. Es ist ungewiss, ob ich es überhaupt bis Weihnachten schaffen werde. Aber jetzt wisst ihr es ja, dass der AMDGPU-Pro-Treiber funktionieren kann und hoffentlich demnächst auch wird. Auf Tumbleweed habe ich es noch nicht getestet. Aber eine kurze Prüfung bzgl. der ABI-Version vom X-Server offenbarte, dass der AMDGPU-Pro-Treiber voraussichtlich auch dort laufen wird. Jetzt eine Frage an die Runde: Soll ich das Installationskript so weit anpassen, dass die Ubuntu-Pakete zusätzlich heruntergeladen und die 32-bit Libraries für die openSUSE-Pakete extrahiert werden? Oder sollen wir noch warten bis AMD das Problem behoben hat? PS: Übrigens habe ich bis hierher mindestens 40 Stunden investiert, um das Installationsskript (inkl. RPM-Spec-Datei) zu schreiben sowie diverse Tests und Nachforschungen zur Lauffähigkeit von AMDGPU-Pro auf openSUSE Leap 42.2. Also, richtig viel Arbeit. ;-) -- Gruß Sebastian - openSUSE Member (Freespacer) Webseite/Blog: https://www.sebastian-siebert.de Wichtiger Hinweis zur openSUSE Mailing Liste: http://de.opensuse.org/openSUSE:Mailinglisten_Netiquette -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org