AMD Radeon Software AMDGPU PRO 16.60-379184

[d2kx]

AMD Radeon Software AMDGPU PRO 16.60-379184

TREIBER BUILD

16.60-379184

UNTERSTÜTZTE SYSTEME

Ubuntu 16.04 LTS (64-bit)
Red Hat Enterprise Linux/CentOS 7.3 (64-bit)
Red Hat Enterprise Linux/CentOS 6.8 (64-bit)
SLED/SLES 12 SP2 (64-bit)

HIGHLIGHTS

Supported APIs:
OpenGL 4.5 and GLX 1.4
OpenCL™1.2
Vulkan™ 1.0
VDPAU
Basic display features
Basic power management features
KMS (Kernel Mode Setting) and ADF (Atomic Display Framework) support
GPL compliant kernel module
FirePro™ Features (EDID Management and 30-bit color)
FreeSync support (Please refer to this FAQ for more information)
DirectGMA for OpenGL
Install script and native packages for all supported operating systems

BEHOBENE FEHLER

Hard-hangs are sometimes observed during display hot-plug.
Launching Steam client sometimes causes system hang.
Rendering error in glxgears in performance mode.

BEKANNTE FEHLER

System hangs when OpenCL attempts to allocate more than available system memory.
System fails to boot to OS with DP1.2 enabled on RHEL 7.3.
Intermittent screen corruption on system restart after manually switching to AMD performance mode. System operates normally afterwards.

DOWNLOAD

Release Notes & Download (http://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-for-Linux-Release-Notes.aspx)

[DevilX]

Angeblich soll der nächste endlich neuere Kernel unterstützen, ich bin mal gespannt.
Kann man eigentlich irgendwie schnell zwischen amdgpu und amdgpu-pro wechseln?

[planet1]

Nabend allerseits,

soweit ich den neuen Treiber testen konnte anbei die ersten Erfahrungen:

+ Läuft unter Ubuntu 16.10 (Kernel 4.8.0-34)
+ Vulkan Treiber wurde aktualisiert (v1.4.1 (http://vulkan.gpuinfo.org/compare.php?compare=compare&id%5B1086%5D=on&id%5B922%5D=on
) = Windows-Niveau)
+ VDPAU funktioniert
+ Die vulkanisierte Unity Viking Village demo (https://www.youtube.com/watch?v=iV-224nMwN8) läuft super (ohne Absturz und Murren):


http://www.imghost.in/img/2017-01/29/esiubnhfg708qk2d5le6megun.png (http://www.imghost.in/)
http://www.imghost.in/img/2017-01/29/vhz4n5mwonavsg3pf16qr9k3d.png (http://www.imghost.in/)
http://www.imghost.in/img/2017-01/29/fhlzu8k2ked7tq8f0d8ojxkzf.png (http://www.imghost.in/)
http://www.imghost.in/img/2017-01/29/j08mfcur3eozpgatj8c15hz9f.png (http://www.imghost.in/)
http://www.imghost.in/img/2017-01/29/eh4o79y7ab0ut2z8redsynp2d.png (http://www.imghost.in/)



- UEFI SecureBoot wurde wohl verbessert (keine PW Eingabe mehr), jedoch bootet mein System nicht mehr gescheit (ATA Fehler). Werde wohl auf dieses Feature verzichten müssen.

[Gast]

Bin ein wenig enttäuscht. Bei Games hat dieser Treiber mit meiner 7950 viele Darstellungsfehler. Die Mesa Sache läuft deutlich besser. Da kann ich auf Doom verzichten.

[planet1]

Wie in Windows (https://www.forum-3dcenter.org/vbulletin/showthread.php?t=579217) müsste es einen OpenCL Performance-Boost dank SPIR-V (http://opengl.gpuinfo.org/gl_comparereports.php?reports_length=50&compare=compare&id%5B1712%5D=on&id%5B1618%5D=on) geben.

Mal sehen was für OpenCL Anwendungen für Linux sich finden lassen ..

[aufkrawall]

Luxmark böte sich doch idealerweise an.
Folding wär natürlich auch interessant, weil man dort einen Boost bitter nötig hätte. Ist aber nicht wirklich sauber zu benchmarken, sofern es nicht um große Sprünge geht.

[iuno]

Wie in Windows (https://www.forum-3dcenter.org/vbulletin/showthread.php?t=579217) müsste es einen OpenCL Performance-Boost dank SPIR-V (http://opengl.gpuinfo.org/gl_comparereports.php?reports_length=50&compare=compare&id%5B1712%5D=on&id%5B1618%5D=on) geben.
:confused:
SPIR-V gibt es seit OpenCL 2.1, das unterstuetzt der Treiber nicht mal.
Davon ab: warum soll der wechsel der IR einen Boost bringen? Ausserdem muesste die Anwendung selbst auf SPIR-V umstellen.

[planet1]

Nabend, ja AMD hat seinen OpenCL Treiber immer noch unter Versionsnummer 2.0 gelisted.

Jedoch gibts sowohl unter Win als auch Linux eine neue OpenGL Erweiterung (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11291536&postcount=9).

Der von mir verzeichnete Boost in einer bestehenden OpenCL-Anwendung (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11291531#post11291531) ist KEINE gesicherte Erkenntnis sondern eine in diesem Zusammenhang geäußerte Vermutung die bislang noch kein Feedback erfahren hat.

Last but not least: Das bestürzende an der Extension GL_ARB_gl_spirv ist jedoch nicht ihr Seltenheitsfaktor mit 5,7% oder Platz 768 von 802 (http://opengl.gpuinfo.org/gl_extensions.php), sondern die Tatsache dass das grüne Lager das Ganze vor über einem HALBEN JAHR (http://opengl.gpuinfo.org/gl_listreports.php?listreportsbyextension=GL_ARB_gl_spirv) bereits implementiert hat!

[Achill]

Nabend, ja AMD hat seinen OpenCL Treiber immer noch unter Versionsnummer 2.0 gelisted.

Jedoch gibts sowohl unter Win als auch Linux eine neue OpenGL Erweiterung (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11291536&postcount=9).

Der von mir verzeichnete Boost in einer bestehenden OpenCL-Anwendung (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11291531#post11291531) ist KEINE gesicherte Erkenntnis sondern eine in diesem Zusammenhang geäußerte Vermutung die bislang noch kein Feedback erfahren hat.

Last but not least: Das bestürzende an der Extension GL_ARB_gl_spirv ist jedoch nicht ihr Seltenheitsfaktor mit 5,7% oder Platz 768 von 802 (http://opengl.gpuinfo.org/gl_extensions.php), sondern die Tatsache dass das grüne Lager das Ganze vor über einem HALBEN JAHR (http://opengl.gpuinfo.org/gl_listreports.php?listreportsbyextension=GL_ARB_gl_spirv) bereits implementiert hat!

Die Extension GL_ARB_gl_spirv hat - wenn es richtig lese - aber nichts direkt mit OpenCL zu tun noch liefert es ein Hinweis, das NV hier irgend was neueres als OpenCL 1.2 unterstützt.


This extension does two things:

1. Allows a SPIR-V module to be specified as containing a programmable
shader stage, rather than using GLSL, whatever the source language
was used to create the SPIR-V module.

2. Modifies GLSL to be a source language for creating SPIR-V modules
for OpenGL consumption. Such GLSL can be used to create such SPIR-V
modules, outside of the OpenGL runtime.


Alles andere würde auch nicht in die CUDA Strategie passen. BTW, lange werden wir auf OpenCL bei NV nicht warten müssen, da Intel sich endlich durch gerungen hat OpenCL 2 zu unterstützen um man den HPC Markt sicherlich nicht NV überlassen will.

[iuno]

Ist auch Quatsch und ausserdem OT.

[Gizmo1200]

Kann man eigentlich irgendwie schnell zwischen amdgpu und amdgpu-pro wechseln?

Wie soll das bitte gehen? Der AMDGPU-Pro baut sich ganz anders auf und hat andere Abhängigkeiten. Die Dinge die er braucht installiert er und wirft das ganze Mesa Zeug raus. Beides gleich laufen lassen funktioniert nicht.

Bei Arch fängt es mit AMDGPU mit dem xf86-video-amdgpu und AMDGPU-Pro mit xf86-video-amdgpu-pro an. Weiter sind eine Menge andere Dinge am Werk um jedes laufen zu lassen.

Dafür bräuchte es direkt beim laden ein Script, der die ganzen Dateien tauschen / umbenennen müsste. Also viel Aufwand und das ganze ohne Fehler.

Es wer auch von Nöten, bei Umstellung, immer das System neu zu starten. Ein Wechsel im laufenden Betrieb o. Ab- und Anmelden des Benutzers, sollte nicht gehen.

Im ganzen wer ein installieren von zwei Systemen das einfachste.

Mich kotzt es einfach an, das AMD als auch MESA zwei halbgare Dinge machen. Die einen machen wunderbar OPENGL und die anderen wunderbar Vulkan. Warum nicht als Team beides zusammen?

Obwohl ich muss vorsichtig sein. Keine Ahnung wer bei Vulkan überhaupt die Hände darin hat.

[aufkrawall]

Wie kann es eigentlich sein, dass der Pro-Treiber teilweise langsamer ist als Mesa bei OGL?

[iuno]

Mich kotzt es einfach an, das AMD als auch MESA zwei halbgare Dinge machen. Die einen machen wunderbar OPENGL und die anderen wunderbar Vulkan. Warum nicht als Team beides zusammen?

Obwohl ich muss vorsichtig sein. Keine Ahnung wer bei Vulkan überhaupt die Hände darin hat.
Man arbeitet doch quasi ausschliesslich gemeinsam. afaik gehoert Bas auch zu AMD, Dave als DRM Maintainer von RedHat ist ein Externer, aber ansonsten kommt eh fast alles von AMD Devs. Deren proprietaere Vulkan und OpenCL Treiber sollen eh noch irgendwann "befreit" werden, wobei neuere Karten bei OCL eh auf den ROC aufsetzen werden.

Der proprietaere OpenGL Treiber ist halt noch da. Den braucht man noch fuer FirePRO Kram, fuer Kompatibilitaetsprofile usw. DDX Treiber? Ist halt noch da, braucht man eigentlich auch nicht mehr. Multimedia (VA-API & VDPAU) ist eh alles in Mesa. radeonsi unterstuetzt jetzt OGL 4.5 und taugt fuer die Allermeisten.

Ein freier, oder noch hybrider Stack macht fuer den normalen Desktopuser imho immer noch am meisten Sinn: Mainline Kernel mit amdgpu, libdrm, radeonsi (ogl, vaapi, vdpau), modesetting/glamor, ggf. noch radv.
Wenn es sein muss noch gepatchte libdrm und proprietaere opencl/vulkan Treiber.
Fuer den vollen -pro Stack sehe ich eigentlich keinen Grund, ausser vielleicht wenn man unbedingt FreeSync haben will. Aber dann gibt es eh keine entsprechenden Spiele fuer Linux also ist es mir auch egal.

Wie kann es eigentlich sein, dass der Pro-Treiber teilweise langsamer ist als Mesa bei OGL?
Weil radeonsi mitunter bugs hat und wenn die Haelfte nicht gemacht wird, ist man halt schneller ;p
Im Ernst: radeonsi ist jetzt auch auf OGL 4.5, jetzt geht es an die Optimierung. Am Proprietaeren wird doch schon lange kaum mehr was gemacht. Die Mesa devs suchen sich halt raus, was so gespielt wird (oder was sie auch mal selber spielen) und schauen sich das dann auch mal naeher an. Dafuer ist man vielleicht anderswo immer noch deutlich langsamer, so ist das halt bei komplett unterschiedlichen Implementierungen.

[aufkrawall]

Thx. Also ist es nicht wie bei NV, dass der proprietäre OGL-Treiber dem von Windows entspricht?
Und wieso funktioniert FreeSync auch mit dem Pro-Treiber nicht richtig?

[iuno]

Ich glaube schon, dass der OGL Treiber derselbe ist wie unter Windows, aber ueber dessen Ruf weisst du glaube ich genauso gut Bescheid wie ich ;)
Viele portierten Spiele laufen ja auf Windows mit d3d, nicht ogl, insofern hat der Treiber dort dann auch keine Optimierungen fuer diese Titel.

Ich habe nicht gesagt, dass FreeSync nicht funktioniert, sondern dass ich persoenlich es nicht brauche, weil ich eh keine passenden und guten Spiele fuer Linux habe (sowas wie Rocket League oder CS laufen eh ueber 120 FPS).
Ich habe FS daher auch noch nie ausprobiert, geschweige denn kuerzlich mal wieder den kompletten -pro Stack getestet. Aber das sagt AMD selbst:

Limitation of AMD FreeSync on Linux


For FreeSync to work in OpenGL applications, V-Sync must be turned ON. If V-Sync is OFF, flipping may not occur hence FreeSync will not be engaged. Please note that if the individual application does not have V-Sync options, you can set it globally by modifying /etc/amd/amdrc (change the parameter ‘OGLWaitVerticalSync’ from 1 to 3)
FreeSync should not be engaged on desktop or video playback
FreeSync enable setting is set on a per-display connection basis
FreeSync enable setting does not retain after display hotplug or system restart (e.g., need to manually re-enable FreeSync via terminal command)
In multi-display configurations, FreeSync will NOT be engaged (even if both FreeSync displays are identical)
FreeSync via HDMI is not supported for this feature. Only DP FreeSync displays will work.

Currently AMD Freesync is supported on the following applications


Phoronix test suite (PTS)
Unigine Valley
Unigine Heaven
Metro Last Light
Civilization 5
Witcher 2
DOTA2
TF 2
Counter Strike Source
Rocket League
Ark Survival Evolved
XCOM2
glxgears