linuxgaming.de

Wundert mich jetzt, dass so "schnell" ein neuer Treiber veröffentlicht wird, aber gut.

--> Generelle Übersichtsseite für Linux-Treiber + Download + Release Notes <--

--> Installations How-To im Wiki <-- (Bräuchte mal ne Generalüberholung)

Der Catalyst-Treiber ist allgemein in Spielen performanter, der freie Radeon-Treiber kann aber bei älteren Source-Spielen durchaus mithalten. Evtl. müsst ihr selbst ausprobieren, welcher euch besser passt. Allgemein geht die Strategie eher in Richtung offener Treiber.

Was FEHLT:
- Kernel 4.1/4.2 Support?

Neue Eigenschaften:
- xorg-server 1.17 Support
- AMD PowerXpress support for laptops equipped with Intel 6th generation (Skylake) CPUs
- Linux Platform Atomics & SVM Fine Grain Buffer support for Carrizo APUs
- Multi-Device support for OpenCL 2.0

Bugfixes:
- Segmentation fault observed while launching some OpenGL games in RHEL7.1
- Error message observed during installation through rpm package in RHEL 6.5, 7.0
- System hangs while running Dying Light
- clinfo could not recognize up to four GPU devices

Bekannte Probleme:
- Vari-Bright on some configurations is not decreasing brightness as expected

Läuft übrigens ganz gut, die Performance ist überraschender Weise besser geworden. Siduction hat übrigens Pakete mit 15.7, die auch mit Kernel >=4.0 laufen

Code: Alles auswählen

crt0mega@Phenom9950:~$ uname -r
4.1.2-towo.1-siduction-amd64
crt0mega@Phenom9950:~$ apt-cache policy fglrx-driver
fglrx-driver:
  Installiert:           1:15.7-2.siduction.1
  Installationskandidat: 1:15.7-2.siduction.1
  Versionstabelle:
*** 1:15.7-2.siduction.1 0
        500 ftp://ftp.spline.de/pub/siduction/fixes/ unstable/non-free amd64 Packages
        100 /var/lib/dpkg/status
     1:15.7-1 0
        500 http://ftp.de.debian.org/debian/ unstable/non-free amd64 Packages
        500 http://ftp.de.debian.org/debian/ testing/non-free amd64 Packages

________
Note to myself: Endlich mal den Hostnamen korrigieren ~.~

Hallo,

bei mir läuft der Catalyst 15.7 auch super unter Arch mit aktuellem Kernel (4.1.2-2-ARCH) und aktuellem XServer (1.17.2). Ich kann letztlich keine Probleme beim Desktop-Betrieb feststellen und bei Spielen (z.B. The Talos Principle) kann ich gegenüber dem OpenSource-Treiber doch schon sehr große Geschwindigkeits- und Qualitäts-Sprünge feststellen. Beim OS-Treiber musste ich bei "The Talos Principle" weitaus mehr Einbußen bei der Grafik hinnehmen, als beim Catalyst. Beim Catalyst kann ich jetzt alle Grafikeinstellungen fast bei Ultra einstellen, bis auf einige kleine Einschnitte bei Anti-Ailasing, Anisotropische Filterung und den Schatten. Aber das ist jetzt in Ordnung. Beim OS-Treiber musste ich nahezu alle Grafikeinstellungen herunterregeln, wodurch das Spiel nicht wirklich Spaß gemacht hat. Das Auge spielt letztlich mit.

Bisher war ich zum OpenSource-Treiber "gezwungen" (aufgrund fehlender XServer 1.17 Unterstützung des Catalysts), aber nach meinen aktuellen Tests werde ich jetzt beim Catalyst bleiben. Insbesondere wegen den großen positiven Effekten bei Spielen. Der OS-Treiber war auch schon sehr gut, aber letztlich (im Vergleich zum Catalyst) nur eingeschränkt zum spielen geeignet.

Hier mal meine Grafikkarte:

Code: Alles auswählen

~ % lspci -nnk | grep -i VGA -A2                                                                                                                  :(
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Curacao XT [Radeon R9 270X] [1002:6810]
        Subsystem: PC Partner Limited / Sapphire Technology Device [174b:e271]
        Kernel driver in use: fglrx_pci


Kannst du in tty wechseln? Weil das soll verbuggt sein und dir nur einen schwarzen Bildschirm geben, also in Kombination mit x-server 1.17.

Ja, das ist tatsächlich verbuggt, aber es gibt einen Würgaround:

https://wiki.archlinux.org/index.php/Uvesafb

Einfach den v86d "Treiber" installieren, dann wie beschrieben die Änderung bei Grub vornehmen und den Hook "aktivieren". Anschließend wie beschrieben noch uvesafb konfigurieren und fertig.

Jetzt kann ich auch in tty wechseln, ohne v86d geht es leider nicht. Aber ich persönlich sehe mich eh größtenteils als (fortgeschrittener) Anwender und ins tty wechsle ich wenn überhaupt nur bei Problemen, was in den letzten 2,5 Jahren (seitdem ich Arch verwende) vielleicht schätzungsweise 3 oder 4 mal der Fall war. Ansonsten verirre ich mich nie ins tty, aber für den Fall das ich es doch mal brauche, habe ich halt die oben verlinkte Prozedur durchlaufen, um einfach gewappnet zu sein.

Joa, dann bleib ich mal lieber bei x-server 1.16. Ich nutze tty a) täglich und b) hab ich kein Grub.

Ich hatte das gleiche Problem, als ich in ein tty wechseln wollte. Brauche das zwar nicht so oft, werde mir aber mal den oben beschriebeben Workaround dafür ansehen, danke schonmal