Arch Linux @ Steam: Eure Erfahrungen

[Gizmo1200]

Hi Leute!
Für mein Teil benutze ich gerne Arch. Aber wenn es um Gaming geht, besonders mit Steam, dann bekomme ich leichte Ernüchterung bei diesem System.

Meine Hardware ist ein XEON 1230, 8GB, Radeon HD 7950, einfache 3TB 7200U/min Platte.

Als Grafiktreiber lasse ich unter jedem Linux (Arch, Ubuntu, Manjaro usw.) die Mesa Treiber laufen.

Besonders unter Arch fällt mir auf, das die meisten Spiele nicht funktionieren. Das hängt wohl mit den Steam Bibliotheken ab, die in diesen Steam-Ubuntu Verzeichnis sind. Arch greift wohl auf seine eigenen und verlinkt wohl nicht in diesen Ordner. Dadurch gehen die meisten Games nicht. So verstehe ich das. Wenn es falsch sein sollte, dann kann das gerne einer richtig stellen.

Ich gebe in meinen alter nicht mehr soviel aus an Geld für Spiele. Darum erfreut es mich auch Freeware oder Demos zu Gamen. STAR CONFLICT, BomberZone o. Romopolis mal als Beispiele. Dieses drei laufen unter Ubuntu o. Debian tadellos. Leider nicht unter Arch.

Hat jemand Erfahrungen wie man das Regeln könnte?

Hinzu würde ich auch NVIDIA Benutzer aufrufen mal ihre Erfahrung kundzutun.

Auf ein freudigen Austausch.

[aufkrawall]

Seit dem letzten Steam-Update nimmt er weniger Komponenten aus dem eigenen Runtime, das soll z.B. für OpenSuse die Kompatibilität mit Feral-Spielen verbessert haben. Davor hatte es aber funktioniert, ihm die richtigen Libs per symbolischen Verknüpfungen anzudrehen (das alte Verhalten lässt sich per Commandline wiederherstellen). Ich habe allerdings selber keine Feral-Spiele und geb nur das wieder, was ich gelesen hab.
Ich kenn mich mit Arch überhaupt nicht aus, aber ich geh mal stark davon aus, dass das entweder in den dortigen Foren schon Thema war, oder dass einem in einem eigenen Thread gut geholfen würde.

[DevilX]

Hast du dir mal die Tipps aus dem Wiki angesehen?
https://wiki.archlinux.org/index.php/Steam/Troubleshooting
https://wiki.archlinux.org/index.php/Steam/Game-specific_troubleshooting

welche steam variante verwendest du?
native oder runtime?

Probiere mal
/home/[your username]/.local/share/Steam/ubuntu12_32/steam-runtime/run.sh %command%
als startoption bei den Spielen aus.

[DevilX]

Bei mir läuft es tipp topp ;-) (habe aber nicht die gleichen Spiele)

[Ganon]

Also in kurz:


$ pacman -Sy steam
$ pacman -Sy steam-native-runtime
$ steam-native

[Ganon]

Und in lang:

ArchLinux liefert eine deutlich aktuellere Fassung sämtlicher Bibliotheken aus. D.h. auch, dass sämtliche Treiber gegen aktuellere Bibliotheken gelinkt sind und entsprechend auch Features dieser nehmen. Das betrifft dann gerade die OpenSource-Treiber.

Nun kommt Steam daher und lädt nun für die Spiele Uralt-Bibliotheken aus Uralt-Ubuntus. Diese sind nun nicht mehr kompatibel mit den Treibern die ArchLinux mitliefert, weil einfach zu alt. Das betrifft nicht nur Grafik sondern auch den Sound. Wenn man z.B. sein ArchLinux ohne Pulseaudio einrichtet, dann sind die ALSA-Bibliotheken viel zu alt für einen aktuellen Kernel mit aktuellem ALSA.

Nun gibt es die Möglichkeit Steam zu sagen, er soll das bitte lassen und die Bibliotheken vom System selbst nehmen. Unter ArchLinux geht dafür der steam-native Befehl, welcher nichts anderes tut als:

export STEAM_RUNTIME=0

zu setzen, bevor Steam aufgerufen wird. Weiterhin sorgt das optionale Paket steam-native-runtime (https://www.archlinux.org/packages/multilib/x86_64/steam-native-runtime/) dafür, dass alle von Steam benötigten Bibliotheken auch installiert sind.

[iuno]

"native" laeuft auch hier deutlich problemfreier. Wie aufkrawall schon angemerkt hat, kommt Valve auch doch noch langsam auf den Trichter und schmeisst die veraltete mitgelieferte runtime wohl langsam raus. Also keine falsche Scheu ;p

[Gast]

Danke Euch.

@Ganon
Hat mir das mal verständlich rübergebracht, wie da Arch tickt.

Einige Demos gehen zwar noch immer nicht. Aber egal. Sind Demos.

Die Freeware Dinge, besonders für mich Star Conflict, laufen jetzt.

[Gizmo1200]

Ich hoffe ihr könnt noch mal helfen?

Folgendes:
Ein Teil an Games & Demos läuft mit steam-native und der andere mit steam-runtime.

Alles was mit steam-runtime läuft, dass lässt sich nur einmal starten. Die Beschreibung ist nicht richtig. Es lässt sich auch ein zweites oder drittes mal starten. Der Prozess läuft, in der Systemüberwachung zu erkennen, kann den Prozess des Spiels auch beenden und in Steam ebenfalls zu erkennen.

Nur beim zweiten Start, wird das Bild schwarz, oben der Rand mit dem Namen des Games und dann schließt sich das wieder und man ist wieder auf den Desktop. Ein Switch (tabben) zwischen Desktop und Game gibt es nicht. Also keine Ahnung wo das hin wandert.

Konnte das an den Demos von:
Shadow Tactics: Blades of the Shogun und BomberZone feststellen.

Gibt es da ein Fix oder was anderes?

[Gizmo1200]

Nachtrag:
Das ganze ist wirklich schon ein Phänomen und ich kann es nicht begreifen, dass dieses nur bei mir sein soll unter Arch.

Shadow Tactics: Blades of the Shogun und BomberZone (noch ein paar andere Games) laufen auch beide unter steam-native. Dafür muss ich aber jedes mal vor Start, die Dateien reparieren lassen. Ich denke das dieses oben geschriebene Problem, bei mehreren ist. Ich habe dieses Problem schon öfters ausgemacht. Egal welche Dektop-Umgebung ich benutze unter Arch.

Ganz ehrlich Leute. Konnte das keiner bis jetzt mit einer AMD feststellen ?

[DekWizArt]

Hab Ubuntu und Nvidia, kann da nicht wirklich helfen. ;)

[Gizmo1200]

Das ist unter Arch bei mir.

Bei Ubuntu oder Debian habe ich auch keine Probleme.

[Ganon]

Also zumindest BomberZone startet bei mir auf gar keinem Rechner. Das verreckt irgendwo in der eigenen Mono-Bibliothek.

[Gizmo1200]

Öffne Steam, Dateien reparieren lassen und dann starten. Geht bei mir jedes mal. Aber normal ist das nicht, dass man das bei einigen Games machen muss und bei anderen nicht.

Habe zwischendurch Arch neu installiert und das verhalten bleibt einfach gleich.

[lumines]

Generell ändert sich bei Arch durch eine Neuinstallation eher wenig. ;)

[aufkrawall]

Gibt es SteamTricks für Arch?

[DevilX]

Ich habe die genannten Spiele nicht.

[Ganon]

Es gibt Demos von den Spielen. Auch "Dateien reparieren" hilft bei mir nicht. Es semmelt direkt beim Start weg.

[Ganon]

So, gerade mal intensiver nachgesehen. Also er schmiert in der libmono weg, im Zusammenhang mit den pthreads.

Ich vermute schlicht und ergreifend, dass hier die libmono (es scheint generell hier wohl nur Mono-Spiele zu betreffen, Shadow Tactics ist auch eines) irgend eine Race-Condition (aka Bug) hat und dass "Lokale Dateien reparieren" eher ein Placebo ist.

Warum die jetzt verstärkt bei Arch auftritt kann nun zehntausend andere Gründe haben. Ein "zu neues Xorg", irgendwelche Probleme mit udev usw. usw.

[aufkrawall]

Kurz vermerkt: Läuft auf Tumbleweed mit Nvidia.

[Gizmo1200]

Dann versuche es jetzt noch mal zu starten. Wenn es geht, dann scheint AMD einfach ein Problem zu haben bzw. STEAM unter Arch.

[Ganon]

Oder ein Bug der mit einem aktuellen Mesa triggert. In ein paar Tagen kommt Mesa 17 raus, dann kannst'e es ja noch mal testen.

[Gizmo1200]

Da könnte ich gleich mal mit "mesa-test-git" etwas machen.

[Ganon]

Ach, sag mir doch einer, dass das alles Unity-Spiele sind.... :ugly:

Einfach dem Spiel den Startparameter "-force-opengl" geben... dann geht's auch. Siehe auch http://bwyan.dk/working-fix-for-unity-based-games-crashing-when-using-mesa-tested-on-ubuntu-debian-and-opensuse/

edit: Weiter unten steht auch, dass das wohl auch jetzt unter Linux einen anderen OpenGL Modus nimmt. Sehr verwirrend alles. Kannst ja trotzdem mal die andere Mesa-Version testen. Oder eben warten

edit2: Just for fun mal weitergetestet. Ich vermute Unity, oder Mesa hat irgend ein Bug in der Versionerkennung. Ich vermute Unity rotzt in der Versionserkennung weg oder bei der Suche nach Extensions.

Starte ich z.B. das Spiel mit der Umgebungsvariable MESA_GL_VERSION_OVERRIDE=4.5, dann startet es auch ohne diesen "-force-opengl" Flag. Da Mesa 17 aber in den nächsten Tagen sowieso offiziell (für mich) OpenGL 4.5 Support bringt, erübrigt sich auch dieser Flag.

[Gizmo1200]

Vielen, vielen Dank für die ganzen Infos.

Lasse es jetzt mit "MESA_GL_VERSION_OVERRIDE=4.5" starten über angelegte Scripte. Das geht schnell mit einen Doppeklick und es braucht kein starten von Steam.

Bei "-force-opengl" bringt er zumindest bei Shadow Tactics: Blades of the Shogun ein Darstellungsproblem beim Boden.

Ich beobachte das weiter mit Mesa 17. Hatte gestern mit "mesa-test-git" mal angefangen, aber das dauert unheimlich lange bis er ein Paket fertig hat. Für mich zu intensiv an Zeit und so bleibe ich erst mal bei Mesa 13.04-1 oder bis Mesa 17 aus dem "Git" ist.

[iuno]

Ich beobachte das weiter mit Mesa 17. Hatte gestern mit "mesa-test-git" mal angefangen, aber das dauert unheimlich lange bis er ein Paket fertig hat.
Ja, weil es vom Quellcode gebaut wird und kein fertiges Paket installiert. Um das ganze etwas zu beschleunigen kannst du im PKGBUILD statt `make` auch `make -jx` aufrufen lassen, wobei x die Anzahl der Threads ist (bei einem Quad Core mit Hyper-Threading also z.B. 8)

[DevilX]

Ich nutze mesa-test-git und hab es irgendwo in einer config so eingestellt das er immer 8 Threads nutzt bei make, da geht es recht flott.
Es gibt übrigens auch das aktuelle Mesa als Paket. Ich suche gleich mal.

EDIT:
[mesa-git]
SigLevel = PackageOptional
Server = http://pkgbuild.com/~lcarlier/$repo/$arch

[llvm-svn]
Server= http://repos.uni-plovdiv.net/archlinux/$repo/$arch

EDIT2:
Optimierung beim Pakete bauen
https://wiki.archlinux.org/index.php/Makepkg

[Gizmo1200]

... hab es irgendwo in einer config so eingestellt das er immer 8 Threads nutzt bei make ...

Hier muss die Datei /etc/makepkg.conf bearbeiten werden. Zeile #MAKEFLAGS="-j2" entsprechend in MAKEFLAGS="-j2" ändern und "-j2" anpassend. Beispiel bei einer XEON oder I7 CPU in "-j8"
---
Es gibt übrigens auch das aktuelle Mesa als Paket ...

Meinst du damit die 13.1.0 im "mesa-git 13.1.0_devel"?

Mit Eurer Hilfe bin ich jetzt mal wieder sehr weit gekommen. Super Leute hier :up:

[DevilX]

Als ich es das letzte mal genutzt hab gab es da ne 17x, aber wie gesagt ich baue meine Pakete jetzt selber.
Sobald man das llvm aktuell hat ist nur das Mesa aktualisieren halb so wild.

[Gizmo1200]

"mesa-git" Version 13.1.0
"mesa-test-git" Version 17.1.0


[llvm-svn]
Server = http://repos.uni-plovdiv.net/archlinux/$repo/$arch

Hier ist ein Fehler. Trägt mein es ein in pacman.conf, kommt ein Fehler bei der Aktualisierung von Pacman. Liegt wohl daran, das kein SigLevel angeben ist oder vorab eine Key-ID angeben / eingetragen werden muss.

Arch ist für ein Anfänger / halbwegs Linux Wissender .. nicht ganz so einfach. Ich tue mich schon schwer bei den Pakten. Darum gehe ich den normalen Weg und schaue das ich nicht soviel aus dem AUR nehme.

[DevilX]

Was für ein Fehler kommt denn?
Du musst wahrscheinlich die Keys importieren.
sieht aber so aus als wenn mesa-git etwas veraltet ist.

[Ganon]

-git Pakete ziehen normalerweise den aktuellen git master branch und können dementsprechend nicht veraltet sein, außer es gibt Probleme, weil eine neuere Version anders gebaut werden muss.

Die Version des Pakets wird dann nach Kompilierung neu gesetzt.

[iuno]

Mesa macht einen Versionssprung von 13 auf 17, weil man jetzt eine Datumsbasierte Versionierung hat. Da wird einfach die falsche Versionsnummer drin stehen. Wie Ganon sagt, ist das -git package auf jeden Fall nicht veraltet ;)
edit: jo, im PKGBUILD steht einfach noch 13 drin. Ist aber egal, weil beim Bauen sowieso aus dem hash des letzten commits eine "Versionsnummer" gemacht wird.

[DevilX]

Dann ist ja fein. Das das das mesa-testing-git macht wusste ich. Hab gedacht das ohne testing nimmt ne feste Version.

[Gizmo1200]

Mal etwas ganz schwieriges. Welche Konstellation aus Kernel, Xorg, Mesa, Radeon o. AMDGPU und Desktop sollte man den bei Arch nutzen?

[iuno]

Na das kommt darauf an ;p
Brauchst du den pro-stack? Spielst du? Brauchst du OpenCL?

Ich persoenlich benutze momentan das naheliegendsten Pakete; das sind fuer mich die aktuellen aus den offiziellen Repos. Also 4.9er Kernel, xorg 1.19 und Mesa 13.

[Gizmo1200]

Es bezieht sich auf ein System für den täglichen Alltag. Gamen, Internet, Musik, Video .. kleine Kleinigkeiten.

Persönlich habe ich das jetzt am laufen:

Display Manager : GDM
Desktop : Budgie Desktop
Kernel : 4.10.0-rc7-mainline
Xorg : Xorg-Server 1.19.1-2
Mesa : 13.0.4-1
Grafik : Radeaon HD 7950 - AMDGPU (nicht mehr auf Radeon), Vulkan-Radeon

Frage zu OpenCl. Ist das wichtig bei Games? Was soll opencl-mesa und opencl-amd ?

Verstehe das so das opencl-amd die Bibliotheken direkt aus dem AMD AMDGPU-Pro Treiber sind und das bei Arch dieses opencl-amd Paket mit dem normalen Mesa Treiber zusammenarbeitet. Ist das den damit getan, wenn man es braucht, das Paket opencl-amd einfach zu installieren? Oder ist da noch eine gesonderte Bearbeitung dafür? Sprich, das man in einer Datei noch Änderungen vornehmen muss.

[iuno]

OpenCL brauchst du fuer spiele nicht, sondern fuer GPGPU, z.B. fuer Programme die fuers ray tracing oder zur Videobearbeitung die GPU nutzen koennen.
Ja, opencl-amd nimmt es direkt vom amdgpu-pro Paket, opencl-mesa ist eine freie Implementierung, die allerdings nicht wirklich taugt.
opencl-amd ist genau dafuer da, auch mit mesa zusammenzuarbeiten, ansonsten koennte man ja gleich den vollen pro stack nehmen. Aendern sollte man fuer die Funktionalitaet nichts muessen.

[HeldImZelt]

Für AUR benutze ich Pacaur. Ist ein Pacman Wrapper, der ihn auf AUR Pakete erweitert (und auch deren Updates verwaltet/überprüft). Ist sehr praktisch im Umgang mit AUR.

Warum benutzt du einen rc/non-stable Kernel?

[Gizmo1200]

@iuno
Danke für die Erklärung.

@HeldImZelt
Ich benutze Pacaur. Bin damit heute schon auf Widerstand gestoßen. Und zwar bei wine-gaming-nine 2.1-2. Wollte nicht updaten von 2.1. Lag an den DLL Patches die reinkommen. Wurde mit Ja/Nein Fragen gelöchert. Da habe ich es mit makepkg gebaut und anschließend installiert mit pacaur -U . Das klappte ohne weiteres.

Warum benutzt du einen rc/non-stable Kernel?

Irgendwie mag Kernel 4.9 nicht bei mir von Radeon auf AMDGPU. Und ich habe diesen ACPI_CPU Fehler. Fehler? Weiß ich eigentlich nicht so richtig. Jedenfalls erscheint oben auf dem Schirm etwas deswegen. Auf Youtube habe ich das schon bei einigen gesehen und einige haben das nicht. Keine Ahnung was da der Grund ist.

Weiter zu Kernel 4.10. Der Mainline scheint bei Arch nur der einzige in der Test Version zu sein. Oder?

[HeldImZelt]

Wollte nicht updaten von 2.1.
Ein, zwei mal hatte ich das auch schon. Konnte ich bisher aber immer durch De- und Re-installieren des Pakets lösen. Manchmal hilft es den 'Pacaur dest cache' (und ggf. andere caches) zu löschen (pacaur -Sca), falls es rumzickt.

Irgendwie mag Kernel 4.9 nicht bei mir von Radeon auf AMDGPU.
Hier (https://aur.archlinux.org/packages/linux-cik/) vielleicht mal die Kommentare lesen (oder den Kernel testen, sofern zutreffend).

Und ich habe diesen ACPI_CPU Fehler. Fehler? Weiß ich eigentlich nicht so richtig. Jedenfalls erscheint oben auf dem Schirm etwas deswegen. Auf Youtube habe ich das schon bei einigen gesehen und einige haben das nicht. Keine Ahnung was da der Grund ist.
Kannst das ja mal posten (dmesg).

Weiter zu Kernel 4.10. Der Mainline scheint bei Arch nur der einzige in der Test Version zu sein. Oder?
Die Unterschiede zwischen Mainline- und Archkernel sind glaube ich eh zu gering. Die tun sich nichts.

[iuno]

amdgpu hat ja erst im 4.9er experimentellen Support fuer SI erhalten, kann schon sein, dass es da noch vermehrt Probleme gibt.
Aber wieso willst du ueberhaupt amdgpu nutzen?

[Ganon]

Ihr braucht übrigens nicht rätseln was in ArchLinux "Vanilla" ist und was nicht.

Ihr geht auf https://www.archlinux.de, sucht in der Paketsuche nach dem gewünschten Paket z.B. "linux", klickt auf "linux" aus dem Core-Repo und dort auf Quelldateien.

Dort werden dann, wenn vorhanden die .patch Dateien aufgelistet. Hier in dem Fall aktuell:
0001-x86-fpu-Fix-invalid-FPU-ptrace-state-after-execve.patch und change-default-console-loglevel.patch.

Das sind die einzigen Abweichungen von "Vanilla". Relativ oft sind diese aber nur Backports von der nächst kommenden Version, um Bugs zu fixen die Nutzer aktuell schon haben.

[Gizmo1200]

Ein, zwei mal hatte ich das auch schon. Konnte ich bisher aber immer durch De- und Re-installieren des Pakets lösen. Manchmal hilft es den 'Pacaur dest cache' (und ggf. andere caches) zu löschen (pacaur -Sca), falls es rumzickt.

Danke für den Tipp :up:

Kannst das ja mal posten (dmesg).
Es geht um diese Zeilen. Macht nichts, dass haben einige beim dem Kernel 4.9.

[0.926331] ACPI Error: [\_PR_.CPU0._PPC] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[0.926339] ACPI Error: Method parse/execution failed [\_PR.CPU0._PDC] (Node ffff8802150ccb68), AE_NOT_FOUND (20160831/psparse-543)


Bin das ganze mal durch heute Nachmittag. Habe Arch auch nochmal auf eine andere Platte neu installiert.
Das einfachste war in pacman.conf das Einzutragen:
[mesa-git]
SigLevel = PackageOptional
Server = http://pkgbuild.com/~lcarlier/$repo/$arch

Und dann mit pacman machen lassen.

Die Steam Start Fehler sind weg und bei Shadow Tactics: Blades of the Shogun funktioniert auch VSYNC. Was vorher nicht war. Da blieb es im Spiel immer auf 30FPS.

Morgen teste ich ob Doom2016 mit Mesa unter Wine läuft :cool:

[Ganon]

Mesa 17.0 ist nun im testing unter ArchLinux verfügbar

https://www.archlinux.org/packages/testing/x86_64/mesa/

[Gizmo1200]

Bis jetzt nur im Netz.

Ich sehe nichts, wenn ich Testing schalte und suche am PC. Sehe nur da die 13. Wird noch ein wenig dauern. Die letzten Tage ist bei den Paketen eh der Wurm drin, weil viele Updaten. Da verändern sich hier und da mal eben die PGP Keys und SigLevel oder einiges ist nicht zu erreichen und so weiter und sofort.

[iuno]

pacman -Syy ;p

[Ganon]

Es dauert natürlich bis so eine Änderung sich durch alle Mirror verbreitet haben. Also entweder Mirror wechseln oder noch _etwas_ Geduld haben ;) Als ich das gepostet hatte, war das noch nicht mal 1h Online :D

edit:
Und allgemein: Es ist testing... das ist ultraheißer Code frisch aus dem git master. Wer von den Standard-Repos core,extra, community und multilib abweicht, der sollte immer mit Problemen rechnen.

[iuno]

Jo, der Name kommt ja nicht von ungefaehr ;)
Mich stoert es auch nicht noch das bisschen zu warten, so habe ich kein Theater. Wer es gerne macht (oder sogar braucht), bitteschoen :D

[Gizmo1200]

Hauptsystem jetzt mal über Testing auf Mesa 17 gebracht und es läuft so wie gewünscht. Auf den Testsystem gab es heute Nachmittag doch seine Schwierigkeiten.

Es gibt auch eine neue X-Server (1.19-3) und ich glaube die bringt das alles so richtig ans laufen bei Arch.

VSYNC - FPS und auch Texturen kann ich in einigen Games als besser bezeichnen mit der ganzen Sache. Meine Radeon HD 7950 lebt dann noch ordenlich weiter.

Jetzt muss ich mal irgendwie Vulkan testen.

[DevilX]

Ich hoffe Doom geht bald mit Mesa/Amdgpu

[iuno]

Meinst du jetzt OpenGL oder Vulkan?
Geht es nicht mit radeonsi?

[Ganon]

Wenn dann nur mittels Vulkan. DOOM will bei OpenGL ein Kompatibilitätsprofil haben, was Mesa nicht unterstützen will. Man diskutiert aber wohl intern (auch wenn es zur Zeit auf nicht viel Gegenliebe stößt) für bestimmte Spiele das Kompatibilitätsprofil einfach zu fälschen bzw. eine Option dafür einzubauen.

Wobei im Falle von DOOM das WINE machen müsste.

[aufkrawall]

Kommt mir angesichts der Performance von OGL unter Wine im Vergleich zu Vulkan nicht sehr sinnig vor, dafür auch nur eine Zeile Code zu verschwenden.

[Ganon]

Naja, DOOM ist nicht das einzige Spiel was ein Kompatibilitätsprofil anfordert, ohne dessen Daseinsgrund zu nutzen, und deshalb nicht unter Mesa-Treibern läuft. Bei der Diskussion geht's nicht DOOM, da das nicht mal Linux-nativ ist.

[aufkrawall]

Für Wine-Anwendungen wird also so etwas nicht gebastelt, bzw. wenn dann wohl eher in Wine selbst?

[Ganon]

Es wird generell an einer Möglichkeit gebastelt per-App / per-Game bestimmte Mesa-Interne Sachen zu aktivieren bzw. deaktivieren. Anderes Beispiel Mesa-Internes Threading, was bei einer handvoll Spielen zu deutlich mehr Performance führt, bei Anderen aber zu deutlich schlechterer Performance.

Die größte Punkt dagegen ist, dass man befürchtet am Ende nur noch eine immer größer werdende Sammlung an Workarounds zu haben, statt Anwendungen die ihre Bugs fixen.

Was da nun bei rauskommt, kA. Angeblich will Valve da wohl für SteamOS bestimmte Sachen selbst reinpatchen, auch wenn es nicht Mainline ist.

[aufkrawall]

Schöne Aussichten. :freak:
Hoffentlich kneift OGL für Linux-Spiele bald mal den Arsch zu.

[iuno]

die radv devs schauen sich glaube ich insbesondere DOOM an, eignet sich ja auch als testcase gut. bis das was wird, kann es aber schon noch dauern.

Ansonsten geht derselbe Ansatz wie opencl-amd auch mit dem Vulkan Treiber, wenn man sich nicht den ganzen -pro stack aufhalsen will. Damit waere doom mit wine kein Problem.

[Ganon]

Oh, ich sehe gerade, dass man bei Mesa 17 und im nvidia-libgl package (beides noch in testing) in ArchLinux wohl libglvnd aktiviert hat. Na da bin ich ja mal gespannt...

[iuno]

mesa 17 ist jetzt auch in extra ;)

[Gizmo1200]

Schon am laufen :up:

Mehr oder weniger. Meine Gigabyte 7950 Boost (GCN 1) scheint vor dem Verfalldatum zu sein. Mit Kernel 4.9 ist sie jetzt mit AMDGPU am laufen. Nur so macht das bei der Sinn, in Sache Vulkan. Und Vulkan wieder unterstützt die Karte nicht richtig. OpenGL :up: Vulkan :O

Bei AMDGPU-Pro Treiber unter Ubuntu sieht OpenGL :O und Vulkan :up:

Schade das man kein Mix machen kann.

Ein versuch unter Arch habe ich versucht. Es bringt nichts. Es geht nicht, als nicht Programmierer, etwas zu machen.

[iuno]

Mit Kernel 4.9 ist sie jetzt mit AMDGPU am laufen. Nur so macht das bei der Sinn, in Sache Vulkan. Und Vulkan wieder unterstützt die Karte nicht richtig. OpenGL :up: Vulkan :O
Verstehe ich jetzt nicht. Hast du nun amdgpu-pro oder nicht? Oder amdgpu und radv? Ist das ueberhaupt noch auf arch?

Was fuer Probleme hast du mit dem -pro stack mit opengl?

Man kann schon mixen, aber es stimmt dass man dafuer etwas machen muss. Mit Programmieren hat das aber nichts zu tun ;)

[Gizmo1200]

Ich kann durch meine Platten mehrere Dinge probieren. So habe ich jetzt Arch, ein Ubuntu 16.04 und 16.10 am laufen. Zwischen drin auch mal Centos7.3.

Unter Arch ist es so, dass meine Karte mit Radeon und AMDGPU spricht.

Mesa 17 ist jetzt im Extra und so ein einfaches installieren. So ist es auch mit Vulkan.

Nach Anleitung muss ich Radeon auf Blacklist setzen oder die Enable early KMS Sache ausführen, das Mesa & Vulkan arbeiten.
Nur so spuckt mir vulkaninfo & vulkanCapsViewer Infos aus.

Bei Dota2 habe ich mit OpenGL eine vernünftige FPS von 85 - 120. Bei Vulkan ist es so, das Dota2 startet bis zur Spiel Oberfläche, dann aber abschmiert.
Das reißt das ganze System mit. Sound spielt noch, Maus lässt sich auch noch bewegen, der Rest funktioniert nicht mehr. Ein Reset muss gemacht werden.

Dieses Vulkan nicht arbeiten, bestätigten mir auch die Infos aus vulkanCapsViewer. Hier liegt noch eine Inkompatibilität vor.
-------------------------------------------------------------------------------------------------------------------------------

Ubuntu 16.04
Unter diesem System lässt sich der AMD AMDGPU-PRO installieren.
Ganz einfach nach der AMD Anleitung. Vulkan arbeitet hier richtig.
Bringt mir bei Dota2 mit Vulkan 95-120FPS.

OpenGL ..... lächerliche 45-65FPS. Die Hälfte gegenüber Mesa OpenGL.
................................................................................ ................................................................................ .

Ubuntu 16.10
Hier geht nur wieder Mesa. Über ppa (ob von Oibaf oder Paulo Dias) beides verhält sich gleich bei mir.

OpenGL:
Dota2 die selben FPS (85 - 120) wie unter Arch.

Vulkan arbeitet überhaupt nicht.
................................................................................ ...............................................................................

Zum Schluss:
AMD AMDGPU-Pro unter Centos 7.3.
Das selbe Ergebnis mit OpenGL (Dota2 - lächerliche 45-65FPS) wie unter Ubuntu 16.04.
Hinzu, Schatten Fehler im Spiel. Ewiges blitzen.

Vulkan lief perfekt und hatte auch hier die selben FPS wie unter Ubuntu 16.04 und hatte keine Fehler.

Das ist meine Geschichte :biggrin:

[DevilX]

Ich installiere mal DOTA2 und teste Vulkan

EDIT: reicht es als Startoption -vulkan zu setzen?

[iuno]

Unter Arch ist es so, dass meine Karte mit Radeon und AMDGPU spricht.

Mesa 17 ist jetzt im Extra und so ein einfaches installieren. So ist es auch mit Vulkan. [Anm: radv]

Nach Anleitung muss ich Radeon auf Blacklist setzen oder die Enable early KMS Sache ausführen, das Mesa & Vulkan arbeiten.
Nur so spuckt mir vulkaninfo & vulkanCapsViewer Infos aus.
Das hat mit Mesa aber nichts zu tun. Der Arch Kernel ist jetzt standardmaessig so konfiguriert, dass er amdgpu fuer alle GCN Karten unterstuetzt. Standardmaessig wird trotzdem radeon genommen, also muss man den blacklisten. Mesa geht prinzipiell natuerlich auch mit radeon, radv aber halt nicht.

Bei Dota2 habe ich mit OpenGL eine vernünftige FPS von 85 - 120. Bei Vulkan ist es so, das Dota2 startet bis zur Spiel Oberfläche, dann aber abschmiert.
Das reißt das ganze System mit. Sound spielt noch, Maus lässt sich auch noch bewegen, der Rest funktioniert nicht mehr. Ein Reset muss gemacht werden.
Also macht radv hier Probleme. Kann schon sein, dass das auch an der alten Karte liegt.

Wenn du willst kann ich dir eine PKGBUILD geben, dass du auf Arch einfach mal den Vulkan Treiber aus dem -pro testen kannst.

[Gizmo1200]

Wenn du willst kann ich dir eine PKGBUILD geben, dass du auf Arch einfach mal den Vulkan Treiber aus dem -pro testen kannst.

Ja, bitte. Gibt mir den Schatz. SOFORT :biggrin:

[iuno]

Was du brauchst ist
- ein 4.10er Kernel (also von git oder einem RC selber bauen), linux-mainline (AUR) (https://aur.archlinux.org/packages/linux-mainline/) bietet sich hier an. Dann wie gehabt radeon blacklisten oder in der config noch ganz rausschmeissen
- gepatchte libdrm (https://github.com/libcg/archlinux-libdrm-amd/blob/master/PKGBUILD), die hier basiert auf 2.4.74 (aktuell ist 2.4.75)
- und schliesslich den Vulkan-Treiber (https://github.com/libcg/archlinux-libdrm-amd/blob/master/PKGBUILD) aus amdgpu-pro

Ich habe ein split package mit den drei Komponenten, inkl. gepatchter libdrm 2.4.75, aber gerade nicht zur Hand. Ich bin aber zugegebenermassen nicht sicher, wie es mit dem 4.10er Kernel mit GCN Gen. 1 und 2 funktioniert, also ausprobieren ;)

[DevilX]

Klingt interessant ^^
kann man auch die libdrm aus dem aur nehmen (amdgpu-pro-libdrm 16.60.379184-2 ), und amdgpu-pro-vulkan 16.60.379184-2 ?

[Gizmo1200]

kann man auch die libdrm aus dem aur nehmen (amdgpu-pro-libdrm 16.60.379184-2 ), und amdgpu-pro-vulkan 16.60.379184-2 ?

Nein ... das System zerschießt sich.

[iuno]

Stimmt, die sind ja inzwischen aktualisiert. Kannst es ja mal probieren, ich habe das selbst noch nicht gemacht.

@Gizmo1200: ist auch ein split package, kann es sein, dass du einen "schlechteren" AUR helper benutzt hast, der damit nicht klar kommt?
Nur diese zwei Pakete zu installieren koennte schon klappen.

[Gizmo1200]

Leider geht es bei mir nicht.

amdgpu-pro-vulkan (16.60.379184-2) bleibt abhängig von der amdgpu-pro-libdrm (16.60.379184-2)

Die gepatchte libdrm 2.4.74 läuft für sich alleine auf meinen System.

Ich brauche wohl die 2.4.75 Version oder wird das auch nichts bringen in meinen Fall?

Habe mit der gepatchten libdrm 2.4.74, den amdgpu-pro-installer (https://aur.archlinux.org/pkgbase/amdgpu-pro-installer/) mit makepkg -s PKGBUILD nochmal bauen lassen und versucht mit sudo pacman -U zu installieren.

Es bleibt bei mir mit der Abhängigkeit.

Wie schon geschrieben .. installiert man trotzdem beides amdgpu-pro-libdrm (16.60.379184-2) & amdgpu-pro-vulkan (16.60.379184-2) dann hängt sich das System beim nächsten Booten mittendrin auf.

[DevilX]

bin gerade an der amdgpu-pro-libdrm, boot cd liegt eh noch drin wenns mir das system schießt ^^.

EDIT:
Hmm yaourt will mir den ganzen wust installieren:
bcunit-3.0-2 lib32-libdrm-2.4.75-1 [Entferne] libdrm-2.4.75-1 [Entferne]
amdgpu-pro-dkms-16.60.379184-2 amdgpu-pro-libdrm-16.60.379184-2 amdgpu-pro-opencl-16.60.379184-2
amdgpu-pro-vulkan-16.60.379184-2 lib32-amdgpu-pro-libdrm-16.60.379184-2
lib32-amdgpu-pro-opencl-16.60.379184-2 lib32-amdgpu-pro-vulkan-16.60.379184-2

könnt ihr mir nen anderen AUR helper empfehlen?

[Gast]

Du versuchst gerade den ganzen Treiber zu installieren. Was aber nicht gehen wird, wenn du den Xorg-Server 1.19 verwendest.

[aufkrawall]

Mesa 17 wird jetzt auch via Tumbleweed ausgerollt, falls diese Erwähnung hier gestattet sei.
amdgpu + OpenCL geht auch mit etwas Gebastel. Vielleicht auch gpu OGL + gpu-pro Vulkan, aber das hat pontostroy (der Gears on Gallium-Maintainer) nicht beschrieben. Würde er aber vielleicht, wenn man ihn drauf anspricht.

[HeldImZelt]

könnt ihr mir nen anderen AUR helper empfehlen?
pacaur

[raffa]

https://wiki.archlinux.org/index.php/AUR_helpers#Comparison_table

ich benutz aurutils, bin soweit zufrieden, hab aber keinen Vergleich zu pacaur
yaourt sollte man aus verschiedenen Gründen meiden

[DevilX]

Weiß jemand bescheid, welche libdrm ich zum linux-amd-staging-git kernel nehmen sollte?
Mit der vom amdgpu-pro startet die grafische Oberfläche nicht mehr.

Mit der regulären hat das aktivieren von freesync über xrandr keine Auswirkung.

[aufkrawall]

Ist FreeSync denn schon funktionsfähig?

[iuno]

Die libdrm von -pro aus dem AUR ist lange veraltet. Es gibt hier (https://cgit.freedesktop.org/~agd5f/drm/log/?h=amd-mainline-hybrid-master20170517) eine libdrm fuer den mainline-hybrid Branch, anders als die aus -pro natuerlich auch in Form des Quellcodes. Auswendig weiss ich nicht, wie sich der mit dem staging unterscheidet, wuerde aber bei einem Versuch eher mit beiden auf mainline gehen.

AFAIK ist FreeSync aber gerade eh kaputt, unabhaengig davon, dass es glaube ich immer noch an Mesa fehlt. Man war sich aber auch noch nicht so wirklich einig, wie man es mal fuer Upstream hinbekommen soll. Schade dass da auch von Intel nichts kommt, und rein theoretisch waere es ja sogar mit Noveau mal moeglich :ulol:

[DevilX]

Danke :-)

[exzentrik]

Ich pack's mal hier rein, weil Manjaro auf Arch basiert und es in den allgemeinen Linux-Threads schnell untergehen würde:

Unter Linux verweilt Steam, selbst wenn's eigentlich minimiert ist, dauerhaft in der Taskleiste. Das kann man unterbinden, indem man in "usr/bin/" das Skript "steam" bearbeitet und

export STEAM_FRAME_FORCE_CLOSE=${STEAM_FRAME_FORCE_CLOSE:-0}

in

export STEAM_FRAME_FORCE_CLOSE=1

ändert. Danach verhält sich der Client wie unter Windows, ist also in der Taskleiste nur sichtbar, wenn eines seiner Fenster gerade geöffnet ist. Kleiner Schönheitsfehler: Linksklicks aufs Systray-Icon sind ohne Effekt bzw. öffnen lediglich das Kontextmenü. Kontaktliste, Bibliothek und Co erreicht man also nur noch darüber. In den Steam-Optionen ist es möglich, die Menü-Einträge einzustellen.

Hinweis: Unter Manjaro Cinnamon (und Manjaro XFCE) funktioniert das wie beschrieben. Je nach Distro oder GUI kann das aber weitere Nebeneffekte haben. Notfalls reicht es, die obige Änderung wieder rückgängig zu machen.

[aufkrawall]

Dieses seltsame Verhalten gibt es im normalen Arch nicht. Keine Ahnung, was Manjaro da macht. Man kann auch nicht einfach steam-native aufrufen...

[exzentrik]

Das ist nix Manjaro-Spezifisches, sondern zieht sich über viele Distros und GUIs. Siehe hier (https://github.com/ValveSoftware/steam-for-linux/issues/1025). Womöglich liefert Arch den Client einfach schon länger mit integriertem STEAM_FRAME_FORCE_CLOSE=1 aus?

[Ganon]

Ne, ArchLinux liefert das Startskript aus was Steam liefert. Du musst übrigens nicht das Skript bearbeiten. Du musst nur STEAM_FRAME_FORCE_CLOSE=1 in deine Umgebungsvariablen (https://wiki.archlinux.org/index.php/Environment_variables) aufnehmen.

Das ":-" im Skript bedeutet, dass er nur den Wert auf 0 setzt, falls STEAM_FRAME_FORCE_CLOSE nicht bereits gesetzt ist.