News Linux: Mesa 12.0 bringt OpenGL 4.3 für freie Treiber

[obz245]

In den Kommentaren steht, das er Mesa 12.1 probiert hatte, er hatte die gleichen Grafikfehler unter AMD & /url]

Im nächst vielleicht ein Hinweis worauf du anspielst. Die Überschrift vom Video passt nicht so zum Thema.

Zum Video. Wenn ich mir das System ansehe, dann bekomme ich einen Schmerz bei der Zusammensetzung.

Da kann das wirklich mit den Fehlern sein. Andere Videos zu Rust zeigen da nichts oder andere Videos zu anderen Games.

 

[XimeX]

Habs jetzt mit beiden PPAs für Ubuntu (Gnome) 16.04 probiert. Hab dann aber Boot probleme. Die gleiche Probleme hab ich aber auch wenn ich vom open source treiber auf den Nvidia treiber umstelle.
Hab Intel onboard und Nvidia in kombination im Notebook.

Kann mir wer helfen woran es da scheitert?
Hier gehts zu den Logs

 

[Piktogramm]

Such nach "error" und "warning" und du wirst fündig. Das in ~50% der Fälle in der selben Zeile etwas von freedesktop und/oder dem X-Server steht sollte nicht verwundern. Lass einfach Spielereien mit den Systeminnereien, auch wenn es in Repos angeboten wird . Alternativ musst do wohl oder übel viel Zeit einplanen und für solche Fragen wohl auch noch andere Communities bemühen, da der Spaß schon sehr spezielles Wissen benötigt.

 

[Marco^^]

Andere Videos zu Rust zeigen da nichts oder andere Videos zu anderen Games.

Ohh, OK auf die Hardware habe ich nicht geachtet.

Ergänzung (13. Juli 2016)

Kann mir wer helfen woran es da scheitert?
Hier gehts zu den Logs

Zeile 21 log: Dbus & Avahi haben das erste Problem
Zeile 58 Boot: Avahi
https://de.wikipedia.org/wiki/Avahi_(Software)
https://de.wikipedia.org/wiki/D-Bus#Funktionsweise
http://manpages.ubuntu.com/manpages/trusty/man1/dbus-daemon.1.html
Zeile 37 log: realmd gibt auf

SystemD
Polkitd
https://de.wikipedia.org/wiki/Polkit#Berechtigungen

Ubuntu benutzt ja nicht 2 getrennte Konten, /root & /home sondern SUDO

Zeile 93 Boot: Starting TeamViewer remote control daemon... WATT, warum ? Nettes OS

Ist die Festplatte kaputt ?
Falsche Berechtigungen ?
Da steht was von LVM Bootprobleme

Fallst Du eine SSD hast, versuch mal mit hdparm sie zu überprüfen

hdparm -I /dev/sda | grep TRIM

http://manpages.ubuntu.com/manpages/trusty/man8/hdparm.8.html

Ansonsten ist man eher in den Foren von Ubuntu besser aufgehoben, das ganze sieht mir nach einer auto installation & Formatierung aus ...

Versuche mal den Boot zu unterbrechen mit E wenn dein Laptop zurz vorm Kernel laden ist, da steht was von:

Kernel command line: BOOT_IMAGE=/vmlinuz-4.4.0-28-generic.efi.signed root=/dev/mapper/ubuntu--gnome--vg-root ro quiet splash vt.handoff=7

Wenn Du das QUIET entfernst, kannst Du den Kernel laden sehen mit den eventuellen Fehlermeldungen.

 

[fethomm]

Und in welcher Linux Distribution ist das integriert, oder mit einem Mausklick, sicher, zu nutzen?

Immer das gleiche Problem mit Neuheiten bei Linux... Sieht man sehr gut beim Linux Kernel... Bis da mal der aktuelle bei der Ditribution an kommt, kann schon mal ein halbes Jahr vergehen...
Ich benutze Mint18.0 und ich schätze das es das Mesa12 update wahrscheinlich nie geben wird...

Dann musst Du eine aktuellere Distribution nutzen oder eine wie Debian, die Backports zur Verfügung stellt.

 

[MotherPink]

So, grad mal Mesa 12.0.1 mit dem Tomb Raider Reboot unter Verwendung einer Tahiti Karte ausprobiert.

Tessellation ist immer noch recht fordern, aber die FPS brechen nur noch auf 48 statt 28 ein.
Szenen, in denen ich im CPU-Overhead nur noch 45-50 fps hatte, laufen nun mit 58-60 (Vsync).

Durch und durch eine Verbesserung gegenüber Mesa 11.2.2.

 

[obz245]

@MotherPink

Gebe mal deine Einstellungen und das Gebiet durch. Am besten mach mal ein Video mit Hardware Angaben. Auf Seite zwei siehst du meins und ich muss sagen, das der Teil des Spiels eine ruhige Gegend ist. Ich konnte keine Verbesserung auf Grund der Mesa Versionen feststellen. Teils bricht es auf 3 FPS ein. Allein das Einführungsvideo ist eine Katastrophe. Die Nativ Version insgesamt bleibt für mich eine Katastrophe. Da kann man besser die Windows Version unter Wine spielen.

 

[MotherPink]

Die Stelle ist Folgende und war mir noch aus der Windows Version als fordernd in Erinnerung, speziell wenn es regnet.
https://www.youtube.com/watch?v=E6lThTFA2ok&feature=youtu.be
Die Fps werden durch das Aufnahme Programm(Simplescreenrecorder) beeinträchtigt und liegen normalerweise im Bereich 56-60fps.

Einstellungen sind Folgende:
http://i.imgur.com/d3QAkYZ.jpg
http://i.imgur.com/oiCzEdq.jpg


Mit obigen Einstellungen ist sogar 2xSSAA möglich ohne unter die 50fps Marke zu Fallen, was noch Reserven hin zum GPU-Limit impliziert.
Wie gesagt, Tesselation, was schon immer eine radeonsi Schwäche war(http://www.phoronix.com/scan.php?page=news_item&px=RadeonSI-Offchip-Tess), zwackt nun circa moderate 10fps ab und Ultraschatten noch mal 10-20fps(CPU-Limit).

Mesa 12.0.1 gewinnt vor allem durch den niedrigeren CPU-Overhead, welcher vorher 20fps niedriger lag und die Tesselation ist nun auch ca. 50% günstiger zu haben.
Einbrüche unter die 30fps Marke waren jedoch schon mit Mesa 11.2.2. nicht vorhanden.
Vielleicht ist ein dlevel Treiber nicht immer die beste Wahl.

Hardware:
i5 2500k@4ghz - HD7950@800mhz - 8GB Ram

Software:
Kernel 4.6.4 - Mesa 12.0.1 - LLVM 3.8.0 - DRI 3

 

[obz245]

Ich bleibe bei meiner Meinung mit Tomb Raider und ich kann es nicht nachvollziehen das sich etwas verbessert hat.

Habe Linux Arch Kernel 4.6.4 - Mesa 12.0.1 - LLVM 3.8.0 - DRI 3 installiert und eingestellt. In den Optionen die selben Werte eingestellt wie @MotherPink.

Wenn ich jetzt wieder die selbe Stelle spiele, die ich in meinen Video zeige, dann fallen die FPS auch mal auf 28 und auch etwas weiter. An einigen Stellen ist sie auch auf 60FPS. Also wieder quer durch.

Meine 7950 ist noch eine Boost Karte und arbeitet mit 1000 / 1250. Ich kann es mir nur erklären, das die übertakte CPU bei @MotherPink eine Rolle spielen könnte. Besonders wenn jeder Kern auf 4Ghz laufen sollte.

 

[MotherPink]

Sofern mich mein Erinnerungsvermögen nicht trügt, sollte deine Benchmarkstelle nicht mehr weit sein.
Ich Spiel mal weiter und gebe, sobald soweit bin, mein feedback.

Nachtrag:
Hab nun die Stelle deines Videos erreicht und dort cica 52-60fps festgestellt.
Mit Ausnahme der folgenden Position welche mit Abstand den worst case bildet.

800x600:
http://i.imgur.com/oTiui23.jpg

1080p:
http://i.imgur.com/nIghv7t.jpg

4k:
http://i.imgur.com/CTMTqGX.jpg

Wie man sieht sind die fps auflösungsunabhängig, was ein Cpu-Limit oder einen Treiber-Overhead bestätigt.
Um nun die drawcalls zu minimieren. hab ich mich mal an den Detailregler für Level-of-Detail vergriffen, wobei obige Bilder mit der hohen Einstellung enstanden sind.

Mittlere/Normale Einstellung:
http://i.imgur.com/PYNHQvs.jpg

Niedrig:
http://i.imgur.com/1wMSDbs.jpg

Um es noch mal zu betonen, stellt diese Stelle den mit Abstand schlimmsten Fall dar.
Anderenorts sind bereits mit normalen level of detail fluffige 60fps drin und 50-60fps mit hohen.

@obz245
Da unsere Hardware und Software ziemlich identisch ist, fallen mir eigentlich nur noch zwei Möglichkeiten ein.

1. Der größte Unterschied zwischen unserer Sandy Bridge Cpu ist wohl, dass deiner HT beherscht.
Versuch mal das abzuschalten, es war nicht unüblich, dass Spiele aus dem Zeitraum noch davon ausgebremst wurden und Tomb Raider Linux scheint eh Cpu limitiert zu sein.
Was meine Übertaktung betrifft, so beträgt diese gerade mal 300mhz, da der i5 2500k schon im stock bei Bedarf auf 3.7ghz taktet. Bei deinem Xeon E3-1230 (V1?) sollten es 3.6ghz sein. Das macht den Kohl nicht fett.

2. Dein compositor funkt dazwischen. Überprüfe mal ob sich dein compositor ordnungsgemäß bei Spielstart deaktiviert. Ich schalte meinen vorsichtshalber unter KDE immer manuel vor Spielstart über shift+alt+F12 ab.


Nachtrag 2:

Aus Neugierde hab ich mal das Spiel in Windows gestartet unter Verwendung von d3d11 und den selben Einstellungen, wie im letzten Beitrag aufgeführt.
Meine Vermutung hat sich noch mal bestätigt.
Die worst case Szene, ist die einzige, in der die CPU Last in d3d11 über 50% steigt.
Sofern würde ich mal behaupten Ferals OpenGL wrapper nutzt lediglich zwei Kerne, im Gegensatz zum nativen d3d11 Renderpfad, welcher die Last über 2+ Kerne verteilen kann und somit die 60fps hält.

 

[obz245]

1. HT macht bei mir nichts aus. Dein übertakten kann eine Rolle spielen. Mein Xeon arbeitet eher schlecht mit einen B75 Chipsatz. Ein Kern arbeitet gerade mal mit 3.6Ghz. Werden alle beansprucht, dann geht die Leistung bei mir auf 3.3 - 3.4Ghz zurück. Der ganze XEON hat auf mein Z68 Board (R.I.P) ganz anders gearbeitet. Deiner sollte so sein, das 3.7 ein Kern erreicht und die anderen Kerne jeweils um 100Mhz (K3-3.6Ghz, K2-3.5Ghz,K1-3.4Ghz) bei Last zurück gehen. Da du aber übertaktest und wahrscheinlich alle deine Kerne (All Core) auf 4Ghz stehen (nehme ich so an), könnte das eine Rolle spielen.

2. Benutze minimal Mate. Da ist keiner am laufen.

Ich würde meine Grafikkarte mal auf aufgedreht laufen lassen. Könnte sein, das meine an bestimmten Stellen nicht hoch takten möchte. Aber das bearbeiten der Datei "power_profile" im Ordner Pfad "/sys/class/drm/card0/device/" lässt sich nicht. Habe es direkt schon mit "Root" (sudo -i , sudo -s und sudo su) versucht und mit vi und nano. Der eingetragene "default" Wert möchte ich auf "high" setzen. Die Datei lässt sich öffnen, bearbeiten, aber nicht abspeichern.

Aus den Arch Wiki sollte es ganz einfach mit "# echo high > /sys/class/drm/card0/device/power_profile" gehen. Funktioniert aber nicht.

 

[MotherPink]

Um den Spaß mal weiter zu treiben, hab ich Tomb Raider unter Windows mit nur zwei Kernen laufen lassen und festgestellt, dass das CPU Limit unter d3d11 etwa 10 fps höher liegt. Also an obiger worst case Stelle bei 54 fps.
Beim Test in 8k kam heraus, dass das GPU Limit unter Mesa um die 39-43 fps schwankt und unter d3d11 um die 38-45 fps.

Unter Gallium Nine lag das CPU Limit bereits bei 25fps, was cica 7 fps unter dem von d3d11 liegt(32fps), sofern ich Tomb Raider mit nur einem Kern laufen lasse.

Summa summarum kann man attestieren, dass AMDs open source Treiber bereits mit dem d3d11 Treiber mithalten kann, was die Nutzung der GPU betrifft. Das niedrigere CPU-Limit schiebe ich mal spekulativ Ferals OpenGL Wrapper zu.


Nachtrag:

Um zu überprüfen, ob die mangelnde Mehrkernnutzung auf die Kappe von Ferals OpenGl wrapper, oder AMDs opensource Treiber geht, habe ich mich der kürzlich für Linux erschienenen System Shock Aplpha Demo bedient.
Unter Windows nutzt diese dabei d3d11, um eine Vergleichbarkeit zu Tomb Raider zu gewährleisten.

Die CPU Last lag um die 50%, wobei drei Kerne unter d3d11 etwa gelichstarkbelastet wurden und der mainthread circa 10-20% über den anderen lag.
Die Demo war, wie es zu erwarten ist, stets durch die GPU limitiert, wobei die fps 38-40fps betrugen.

Mit Linux unter Verwendung von Mesa 12.0.1 lagen die fps circa zwischen 37-39 fps und die Demo wurde ebenfalls stets durch die GPU limitiert.
Des Pudels Kern, die Mehrkernnutzung, spiegelte in etwa das Verhalten unter d3d11 wider.
Wobei sich der Mainthread von der Beanspruchung manchmal kurzfristig stärker von den übrigen Kernen absetzte, als es noch unter d3d11 der Fall war.

Somit bleibt festzuhalten, dass AMDs opensource Treiber (radeonsi/Mesa 12.0.1) durchaus zur Mehrkernnutzung im Stande ist und Ferals Opengl wrapper der Übeltäter für das CPU Limit in Tomb Raider ist.

Die reine GPU Leistung war dabei sowohl in Tomb Raider, als auch der System Shock Alpha Demo, überaschend gleichwertig zum Crimson Treiber 16.7.2(d3d11), was ich so nicht erwartet habe.

 

[Iapetos]

Solange eine Anwendung im GPU-Limit läuft, sollten alle Renderpfade vergleichbar schnell laufen, wenn keine künstliche Limitierung besteht.

Beachtlich finde ich, dass RadeonSI so langsam das Niveau der unfreien Treiber erreicht, ohne explizit auf spezifische Anwendungen optimiert zu sein. Dabei fehlen außerdem noch allgemeine Optimierungen, die in den unfreien Treibern (wahrscheinlich) bereits implementiert sind.

Dennoch sollte man nicht alles auf die Treiber schieben. Die größte Variable in Sachen Performance und Optimierung sind und bleiben die Spieleentwickler - die Probleme nicht selten aus Gleichgültigkeit ("auf Nvidia läuft es okay") oder Unfähigkeit oder mangels finanzieller Ressourcen ignorieren.

 

[Termy]

die Probleme nicht selten aus Gleichgültigkeit ("auf Nvidia läuft es okay")

Was primär deswegen ein Problem ist, weil Nvidia der IE unter den Grakaherstellern ist - "was interessieren mich Standards, ich mach mein Ding und die Leute sollen zusehen, dass ihre Sachen bei mir laufen"...
Sieht man auch wieder sehr schön an der Wayland GBM/EGL-Stream-Diskussion...