AMD Radeon Software AMDGPU PRO 16.50-362463

[d2kx]

AMD Radeon Software AMDGPU PRO 16.50-362463

TREIBER BUILD

16.50-362463

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

FreeSync
Provides support for
* AMD Radeon™ R7 M465X
* AMD Radeon™ R7 M370
* AMD Radeon™ R7 M350
Install scripts for RedHat Enterprise Linux 7.3, CentOS 7.3, CentOS 6.8, and SLED/SLES 12 SP2
DirectGMA for OpenGL

BEKANNTE FEHLER

RHEL 7.3 does not detect modeset on hotplug of new monitor.
Hard-hang is sometimes observed during display hot-plug.
Ensight 10 benchmark test intermittently fails to complete.

DOWNLOAD

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

ONE MORE THING

GCN1 Support ist noch instabil, GCN2/3/4 werden vollständig unterstützt.

[Pirx]

:massa:

[Locuza]

Scheint so, als müsse man sich auch noch eine lange Zeit mit den closed Treibern anfreunden, da Display-Core (DAL) eine klare Absage vom toplevel maintainer erhalten hat:
Daniel has said this all very nicely, I'm going to try and be a bit more direct,because apparently I've possibly been too subtle up until now.

No HALs. We don't do HALs in the kernel. We might do midlayers sometimes we try not to do midlayers.
In the DRM we don't do either unless the maintainers are asleep.
They might be worth the effort for AMD, however for the Linux kernel they don't provide a benefit and make maintaining the code a lot harder.
I've maintained this code base for over 10 years now and I'd like to think I've only merged something for semi-political reasons once (initial exynos was still more Linuxy than DC), and that thing took a lot of time to cleanup, I really don't feel like saying yes again.

Given the choice between maintaining Linus' trust that I won't merge 100,000 lines of abstracted HAL code and merging 100,000 lines of abstracted HAL code
I'll give you one guess where my loyalties lie.
The reason the toplevel maintainer (me) doesn't work for Intel or AMD or any vendors, is that I can say NO when your maintainers can't or won't say it.

I've only got one true power as a maintainer, and that is to say No.
The other option is I personally sit down and rewrite all the code in an acceptable manner, and merge that instead.
But I've discovered I probably don't scale to that level, so again it leaves me with just the one actual power.

AMD can't threaten not to support new GPUs in upstream kernels without merging this, that is totally something you can do, and here's the thing Linux will
survive, we'll piss off a bunch of people, but the Linux kernel will just keep on rolling forward, maybe at some point someone will get pissed about lacking upstream support for your HW and go write support and submit it, maybe they won't.
The kernel is bigger than any of us and has standards about what is acceptable.
Read up on the whole mac80211 problems we had years ago, where every wireless vendor wrote their own 80211 layer inside their driver,
there was a lot of time spent creating a central 80211 before any of those drivers were suitable for merge, well we've spent our time creating a central
modesetting infrastructure, bypassing it is taking a driver in totally the wrong direction.

I've also wondered if the DC code is ready for being part of the kernel anyways, what happens if I merge this, and some external contributor rewrites 50% of it and removes a bunch of stuff that the kernel doesn't need. By any kernel standards
I'll merge that sort of change over your heads if Alex doesn't, it might mean you have to rewrite a chunk of your internal validation code, or some other interactions, but those won't be reasons to block the changes from my POV.
I'd like some serious introspection on your team's part on how you got into this situation and how even if I was feeling like merging this
(which I'm not) how you'd actually deal with being part of the Linux kernel and not hiding in nicely framed orgchart silo behind a HAL.
I honestly don't think the code is Linux worthy code, and I also really dislike having to spend my Friday morning being negative about it, but hey at least I can have a shower now.

No.

Dave.
https://lists.freedesktop.org/archives/dri-devel/2016-December/126516.html

[Gast]

Freesync unter Linux wird also nur mit den closed source Treiber unterstützt, der laut einiger Experten im forum ja gar nicht zum zocken gedacht ist!?

Eiskalte Absage für DAL im Linux Kernel:

It Looks Like AMDGPU DC (DAL) Will Not Be Accepted In The Linux Kernel
http://phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-DRM-No

Schade, mal wieder nichts ganzes und nichts halbes.
Bin ich der einzige der AMDs Treiberstrategie nicht versteht?

[iuno]

Scheint so, als müsse man sich auch noch eine lange Zeit mit den closed Treibern anfreunden, da Display-Core (DAL) eine klare Absage vom toplevel maintainer erhalten hat
Wenn man denn entsprechende Funktionen braucht.
Naja, es war eigentlich abzusehen, dass es so nicht geht. Ich bin mal gespannt was jetzt passiert.

Zum Thema: OpenCL Leistung scheint wieder etwas besser mit dem 16.50er.

[Gast]

Na das ist ja eine schöne Bescherung, würde mich nicht wundern wenn Dave das Handtuch wirft.

[Noebbie]

Ich mache gerade erste Erfahrungen mit meiner 290X unter Ubuntu.

Habe dort den neuen amdgpu pro Treiber installiert.

dpkg -l amdgpu-pro zeigt mir die korrekte Version an und mit lcpsi | grep VGA bekomme ich die 290X angezeigt.

Nur... existiert dort sowas wie Radeon Settings? Finde dazu nix! :redface:

[iuno]

Freesync unter Linux wird also nur mit den closed source Treiber unterstützt [...]
Bin ich der einzige der AMDs Treiberstrategie nicht versteht?
Dass das vorerst nur im pro stack Verwendung findet, war doch voellig klar. Die ganze DAL Geschichte ist schon lange bekannt, insofern keine Ueberraschung.
Die Strategie ist nicht besonders schwer zu verstehen; es ist ja ganz offensichtlich weiterhin geplant den Kram irgendwann noch Upstream zu bekommen. Imho ist es gut, dass klare Worte fallen, sonst kommt bei den Entscheidungstraegern ja eh nichts an. Die sind das Thema ja so angegangen, als wuerde Linux Support halt nebenbei abfallen und man brauch sich nicht weiter darum zu scheren. Das ganze ist ja um so laecherlicher, weil der Display Kram ja nur eine von vielen Komponenten im ganzen Stack ist.

Na das ist ja eine schöne Bescherung, würde mich nicht wundern wenn Dave das Handtuch wirft.
Ganz bestimmt ;D nicht.
Nur... existiert dort sowas wie Radeon Settings? Finde dazu nix! :redface:
Nein

[DevilX]

Leider läuft der pro Treiber mit nem aktuellen Kernel sehr bescheiden...

[iuno]

Leider läuft der pro Treiber mit nem aktuellen Kernel sehr bescheiden...

Hat ja auch keinen offiziellen support. Ich benutzte aktuell den ocl blob mit dem freien stack, also aktueller kernel und mesa. Davon abgesehen dass ich die libdrm doppelt habe funktioniert das ganz gut.

[Achill]

Das Thema war schon im letzten Thread. Einfach den Kernel der unterstützten Distributionen nehmen oder wenn man z.B. Arch nimmt diesen auf die Version von Ubuntu / RHEL Downgrade.

[DevilX]

Läuft bei mir auch gut, ich würde nur gerne Freesync nutzen ;-)

@achill, ist klar das das gehen würde, wäre trotzdem schön wenn amd mal neuere Kernel unterstützt.

[Noebbie]

Nein

Schade. Dachte ich mir schon.

Kann ich denn sonst wo Einstellungen reinschreiben? Ich vermute ja hier (/etc/X11/ xorg.conf.d/20-amdgpu.conf)

Nur dann müsste man noch die Parameter wissen...

[iuno]

Was möchtest du denn einstellen?
Ich benutzte aktuell den ocl blob mit dem freien stack, also aktueller kernel und mesa. Davon abgesehen dass ich die libdrm doppelt habe funktioniert das ganz gut.
BTW, fuer Arch Nutzer: https://aur.archlinux.org/packages/opencl-amd/

[Noebbie]

Freesync an/aus, vsync etc... Wobei ich letzteres auch in Tomb Raider ingame konnte.

[iuno]

Zu FreeSync kann ich nichts sagen, V-Sync ist imho Sache des Compositors.
Ansonsten, wenn du es erzwingen willst, kommt
Option "TearFree" "true"
in die X config (device section natuerlich). Das wird halt eklig wenn die Anwendung selbst auch schon synct und der Compositor dann im schlimmsten Fall auch noch dazwischenfunkt :usad:

[Noebbie]

Zu FreeSync kann ich nichts sagen, V-Sync ist imho Sache des Compositors.
Ansonsten, wenn du es erzwingen willst, kommt
Option "TearFree" "true"
in die X config (device section natuerlich). Das wird halt eklig wenn die Anwendung selbst auch schon synct und der Compositor dann im schlimmsten Fall auch noch dazwischenfunkt :usad:

Ich danke! (y)

Dann lasse ich das mal weg.

BTW: Ich hätte nicht gedacht, dass das Tomb Raider (2013) so gut unter Ubuntu auf der 290X läuft. Hatte noch nie ein solches Spiel auf ner Linux-Kiste angezockt und ich war echt begeistert. Hatte schlimmeres erwartet! :freak:

Je nach Zeit probiere ich mal noch Metro und American Truck Simulator. Letzteres sollte ja auch problemlos laufen... :redface:

Habe sogar den XBOX 360 Controller angeschlossen und ich musste nichts konfigurieren. Lara lief damit direkt los! :D

CPU ist übrigens ein alter i5 2400.

Wenn das so weiter läuft, stell ich mir die Testkiste (Ubuntu +Steam mit Big Picture) bald ins Wohnzimmer!

[aufkrawall]

Läuft es denn ohne Einbrüche/Stocker?
Hab das leider nicht in meiner Steam-Bilbiothek.

[Noebbie]

Läuft es denn ohne Einbrüche/Stocker?
Hab das leider nicht in meiner Steam-Bilbiothek.

Ich lief nur am Anfang in der Höhle mit diversen Settings umher und das lief ganz gut. Leichte Stocker hatte ich nur im Intro.

Das Spielchen zeigte mir beim Starten noch eine Treiberwarnung an (wäre nicht der passende für das Spiel). Lag dann aber wohl eher an der Aktualität. :confused:

Edit: Ich hoffe ich komme heute Abend noch etwas dazu, dann kann ich mal sagen wie das in den Außenarealen so ist. Bis zu deiner Frage hatte ich dazu aber noch keine Bedenken....

[planet1]

Guten Abend,

anbei meine bisherigen Erfahrungen mit dem neuen AMD Treiber auf UbuntuStudio 16.04:


Lobenswert:

+ läuft sehr stabil (die letzten AMD-Treibergenerationen auf Linux waren alles andere als laufsicher)

+ Funktionierende OpenGL (http://opengl.gpuinfo.org/gl_comparereports.php?reports_length=50&compare=compare&id%5B1619%5D=on&id%5B1614%5D=on) + Vulkan (http://vulkan.gpuinfo.org/compare.php?compare=compare&id%5B922%5D=on&id%5B914%5D=on) 3D-APIs

+ Videobeschleunigung (VDPAU) (siehe Anhang)



Tadelnswert:

+ Installation macht bei Safebootsystemen (UEFI Sicherheitsfeature) Ärger

+ Kein GUI

+ Manuelle Anpassungen nötig die über das übliche „Linux-Gefrickel“ hinausgehen (bspw. LunarG SDK)

+ Vulkantreiber kommen leider mit einer FPS-Limitierung pro Anwendung daher (~180fps) (siehe Anhang)

+ VDPAU Treiberkomponente landet im falschen Verzeichnis (soviel zum Install-Skript) 1. Aufruf der VDPAU Werte läuft auf Fehler vdpauinfo
display: :0.0 screen: 0
Failed to open VDPAU backend libvdpau_amdgpu.so: cannot open shared object file: No such file or directory
Error creating VDPAU device: 1
2. Vermisste Datei liegt in /opt/amdgpu-pro/lib/x86_64-linux-gnu/vdpau/
statt in /usr/lib/x86_64-linux-gnu/vdpau/
3. Manuelles Rüberkopieren nötig
sudo ln -s /opt/amdgpu-pro/lib/x86_64-linux-gnu/vdpau/libvdpau_amdgpu.so.1 /usr/lib/x86_64-linux-gnu/vdpau/
sudo ln -s /opt/amdgpu-pro/lib/i386-linux-gnu/vdpau/libvdpau_amdgpu.so.1 /usr/lib/i386-linux-gnu/vdpau/

4. VDPAU Hardwarevideobeschleunigung nun möglich - bei meiner Fury auf UVD 6.0 Level
vdpauinfo
display: :0.0 screen: 0
Warning: LLVM emitted unknown config register: 0x4
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

name width height types
-------------------------------------------
420 16384 16384 NV12 YV12
422 16384 16384 UYVY YUYV
444 16384 16384 Y8U8V8A8 V8U8Y8A8

Decoder capabilities:

name level macbs width height
----------------------------------------------------
MPEG1 --- not supported ---
MPEG2_SIMPLE 3 65536 4096 4096
MPEG2_MAIN 3 65536 4096 4096
H264_BASELINE 52 65536 4096 4096
H264_MAIN 52 65536 4096 4096
H264_HIGH 52 65536 4096 4096
VC1_SIMPLE 1 65536 4096 4096
VC1_MAIN 2 65536 4096 4096
VC1_ADVANCED 4 65536 4096 4096
MPEG4_PART2_SP 3 65536 4096 4096
MPEG4_PART2_ASP 5 65536 4096 4096
DIVX4_QMOBILE --- not supported ---
DIVX4_MOBILE --- not supported ---
DIVX4_HOME_THEATER --- not supported ---
DIVX4_HD_1080P --- not supported ---
DIVX5_QMOBILE --- not supported ---
DIVX5_MOBILE --- not supported ---
DIVX5_HOME_THEATER --- not supported ---
DIVX5_HD_1080P --- not supported ---
H264_CONSTRAINED_BASELINE --- not supported ---
H264_EXTENDED --- not supported ---
H264_PROGRESSIVE_HIGH --- not supported ---
H264_CONSTRAINED_HIGH --- not supported ---
H264_HIGH_444_PREDICTIVE --- not supported ---
HEVC_MAIN 186 65536 4096 4096
HEVC_MAIN_10 --- not supported ---
HEVC_MAIN_STILL --- not supported ---
HEVC_MAIN_12 --- not supported ---
HEVC_MAIN_444 --- not supported ---

Output surface:

name width height nat types
----------------------------------------------------
B8G8R8A8 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8
R8G8B8A8 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8
R10G10B10A2 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8
B10G10R10A2 16384 16384 y NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 A8I8 I8A8

Bitmap surface:

name width height
------------------------------
B8G8R8A8 16384 16384
R8G8B8A8 16384 16384
R10G10B10A2 16384 16384
B10G10R10A2 16384 16384
A8 16384 16384

Video mixer:

feature name sup
------------------------------------
DEINTERLACE_TEMPORAL y
DEINTERLACE_TEMPORAL_SPATIAL -
INVERSE_TELECINE -
NOISE_REDUCTION y
SHARPNESS y
LUMA_KEY -
HIGH QUALITY SCALING - L1 -
HIGH QUALITY SCALING - L2 -
HIGH QUALITY SCALING - L3 -
HIGH QUALITY SCALING - L4 -
HIGH QUALITY SCALING - L5 -
HIGH QUALITY SCALING - L6 -
HIGH QUALITY SCALING - L7 -
HIGH QUALITY SCALING - L8 -
HIGH QUALITY SCALING - L9 -

parameter name sup min max
-----------------------------------------------------
VIDEO_SURFACE_WIDTH y 48 4096
VIDEO_SURFACE_HEIGHT y 48 4096
CHROMA_TYPE y
LAYERS y 0 4

attribute name sup min max
-----------------------------------------------------
BACKGROUND_COLOR y
CSC_MATRIX y
NOISE_REDUCTION_LEVEL y 0.00 1.00
SHARPNESS_LEVEL y -1.00 1.00
LUMA_KEY_MIN_LUMA y
LUMA_KEY_MAX_LUMA y

{6. Es ist fraglich ob eine MPEG1 Beschleunigung durch Einbau bspw. einer Matrox Millenium mit daughtercard (MediaXL) erzielt werden kann :-)))) }





Kurz um es klappt alles was muss, aber nicht alles auf Anhieb.

Für eine VDPAU Infoausgabe auf einer Polariskarte wäre ich dankbar.

[aufkrawall]

+ Installation macht bei Safebootsystemen (UEFI Sicherheitsfeature) Ärger

Dürfte doch normal sein, wenn man den Treiber selbst kompilieren muss?

[planet1]

Bei Treiberersion 16.60 starte ich nochmal ein Versuch - sofern Ubuntu nach der Deinstallation von v16.50 noch "safebooten" will.

[aufkrawall]

Liegt wohl an Ubuntu. Damit funktionieren hier mit Secure Boot weder übers offizielle Repo angebotene, übers Nvidia-PPA und auch nicht manuell installierte Treiber. Mit OpenSuse funktionieren hingegen alle genannten Quellen mit Secure Boot. :freak:

Btw: Muss man für GPU PRO immer noch Kernel 4.4 wegen der Performance Regression installieren?