Mesa 7.6 mit 3D für ATi Radeon R600 bis R800 erschienen

Yamagi schrieb:
Was? Mesa3D? Einzig von libdrm. Sonst nichts.
Zum Vergrößern anklicken....

Lol, da habe ich mich vielleicht missverständlich ausgedrückt. Ich meinte, welche der vier Dinge (DRM, libDRM, Mesa3D und Treiber), denn für (mangelndnes) Compositing verantwortlich seien, weil du nur meintest "Git-Head nehmen".
Den Treiber aus neubauen würde ich ja noch, weil ich zur Not eh wieder auf radeonhd wechseln kann, an DRM/libDRM würde ich ungern rumfuschen, weil dann alles vielleicht kaputt geht, if you know what I mean ;)
 
Achso. Hatte ich falsch verstanden. :)

Also, um 3D-Beschleunigung zu bekommen und damit auch Compositing, brauchst du vier Dinge: DRM (im Kernel) und libdrm (im Userland), Mesa3D aka libGL, DDX (Device Depended X11, Teil des xorg-server) und einen X.org-Treiber. Das Compositing scheitert sehr wahrscheinlich ausschließlich am Mesa3D. Denn DRM und libdrm musst du eh aktualisieren, der xorg-server ist in den Ports zwar eine Version hinterher, aber der 1.7 hat keine nennenswerten Änderungen am DDX. Mit den aktuellen Treibern funktioniert es außerdem mit älteren Radeons. Also kurz um, nehme Git-Head von Mesa3D, bedenke aber, dass der Checkout gute Nerven braucht. Es dauert seine Zeit...

EDIT: Ohne ganz aktuelles DRM und der aktuellsten libdrm wird da aber eh gar nichts gehen. Mesa3D wird sich weder bauen lassen, noch funktionieren.
 
Yamagi schrieb:
Achso. Hatte ich falsch verstanden. :)

Also, um 3D-Beschleunigung zu bekommen und damit auch Compositing, brauchst du vier Dinge: DRM (im Kernel) und libdrm (im Userland), Mesa3D aka libGL, DDX (Device Depended X11, Teil des xorg-server) und einen X.org-Treiber. Das Compositing scheitert sehr wahrscheinlich ausschließlich am Mesa3D. Denn DRM und libdrm musst du eh aktualisieren, der xorg-server ist in den Ports zwar eine Version hinterher, aber der 1.7 hat keine nennenswerten Änderungen am DDX. Mit den aktuellen Treibern funktioniert es außerdem mit älteren Radeons. Also kurz um, nehme Git-Head von Mesa3D, bedenke aber, dass der Checkout gute Nerven braucht. Es dauert seine Zeit...

EDIT: Ohne ganz aktuelles DRM und der aktuellsten libdrm wird da aber eh gar nichts gehen. Mesa3D wird sich weder bauen lassen, noch funktionieren.
Zum Vergrößern anklicken....

Ok, danke für die ausführliche Bschreibung. Ich warte lieber mal bis es da News gibt, bevor ich mir das frische System zerschieße.
 
Wenn ich das richtig sehe, wurden die Kernel DRM module mit r198685/r198686 nach stable-8 und sogar stable-7 MFC'd!
 
bost schrieb:
Wenn ich das richtig sehe, wurden die Kernel DRM module mit r198685/r198686 nach stable-8 und sogar stable-7 MFC'd!
Zum Vergrößern anklicken....

Genial!

An anderer Stelle wurde ja behauptet Compositing sei garnicht broken, nur Compiz. kann jemand bestätigen dass Compositing mit KDE oder E17 geht?
 
Zumindest der RC1 lies sich nach meiner Anleitung installieren. Benötigt bloß eine aktuelle libDRM, nicht oben von mir genannte Version. Mit 7.7 läuft es nicht schneller, aber merklich stabiler. Diverse Bugs sind behoben, es treten weniger Renderfehler auf und auch crasht es nicht mehr ständig. Auch Compiz sollte nun gehen.
 
Ich habe nun meine base auf aktuelles stable aktualisiert, die mesa-ports erst mit dem patch auf 7.6.1 und dann "dirty" (nur Version geändert und make makesum) auf 7.7. libdrm habe ich so auch auf die neuste Version gebracht (musste ich leicht die plist anpassen).(amd64-Pakete könnte ich anbieten)
xf86-video-ati ist schon die neuste Version.

Alles sieht gut aus, aber ich kriege nicht mehr frames als vorher und compositing geht auch nicht. Das einzig merkwürdige ist, dass ich immer folgendes kriege wenn ich glxgears oder glxinfo aufrufe:
Code: 
IRQ's not enabled, falling back to busy waits: 2 0

Die kernel meldet, dass der microcode geladen wurde:
Code: 
dmesg | grep drm
drm0: <ATI Radeon 3300 Graphics> on vgapci0
info: [drm] MSI enabled 1 message(s)
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] Initialized radeon 1.31.0 20080613
info: [drm] Setting GART location based on new memory map
info: [drm] Loading RS780/RS880 Microcode
info: [drm] Resetting GPU
info: [drm] writeback test succeeded in 1 usecs
drm0: [ITHREAD]

Die Xorg-log ist leicht widersrpüchlich, es heißt dass Direct rendering geht, EXA erfolgreich geladen wurde etc, und dann ganz am Ende:
Code: 
(II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so
(II) GLX: Initialized DRISWRAST GL provider for screen 0
Was ja wiederum heißt dass der SW-Renderer geladen wurde oder nicht?
Die ganze xorg.log habe ich mal angehangen.

Vielen Dank für euere Hilfe!
 

Anhänge

  • Xorg.0.log.txt
    34,7 KB · Aufrufe: 261
Nein, nein. Ist schon korrekt. Das R600-DRM kann im Moment noch keine IRQ, er muss also Busy Waits nutzen. Daher ist es auch so grottenlahm. :) Ob er nun Hardwarerendert oder nicht testest du am besten mit einem richtigen Benchmark wie Quake III oder meinetwegen auch glxgears. Was dann über 1000 FPS bringen sollte.
 
Yamagi schrieb:
Nein, nein. Ist schon korrekt. Das R600-DRM kann im Moment noch keine IRQ, er muss also Busy Waits nutzen. Daher ist es auch so grottenlahm. :) Ob er nun Hardwarerendert oder nicht testest du am besten mit einem richtigen Benchmark wie Quake III oder meinetwegen auch glxgears. Was dann über 1000 FPS bringen sollte.
Zum Vergrößern anklicken....

Na, leider eben nicht. Mit dem Radeon-Treiber gibts bei glxgears ~500fps, genau so viel wie vorher mit altem mesa und alter base. Zumindest gab es gestern den ganzen abend noch 500fps, wenn ich glxgears jetzt starte, dann gibts die auch, aber der Rechner verabschiedet sich beim beenden von glxgears (Bildschirm geht aus und reagiert auf nichts mehr).

Das habe ich jetzt zweimal versucht und lass jetzt erstmal die disk-checks durchlaufen. Ich habe außerdem mal mit radeonhd gestartet, obwohl da gleich der e17-Begrüßungsbildschirm "zuckte", so dass ich glaube, dass der auch nicht schneller geworden ist.

Wie gesagt, in der Xorg.0.log ist ja auch immer von swrast_dri.so die Rede und nicht von dem neuen r600_dri.so…

edit: der RadeonHD scheint tatsächlich ~690fps zu bringen (vs ~380fps vorher wenn ich mich richtig erinnere). Auch stürzt er das System nicht ab, wobei ich glxgears jetzt auch SIGINT habe statt SIGTERM.
 
Zuletzt bearbeitet:
Der RadeonHD scheint aber auch nicht wirklich beschleunigt zu sein. Wie vorher überfordern ihn schon die XRender-Effekte von E17. Also der animierte Desktop-Wechsel z.B. ist total stotternd, das ging mit dem Radeon schon vorher flawless.
 
Quick and dirty ging ich auch mal den Patch an, die Stabilität und Qualität in einigen Programmen ist damit ein Iota besser. Bei mir verhält es sich jedoch "umgekehrt": radeonhd ist nicht wirklich der Bringer (auch -devel nicht), hingegen verhält sich xf86-video-ati am besten. Insbesondere ist bei darkplaces (Quake1 port) die glx-Version nutzbar, die spürbar Geschwindigkeit bringt. Die sdl Version hingegen, die man mit radeonhd nutzen muß, kommt schnell ins stottern. ioquake3-devel _scheint_ auch ein Stück flüssiger zu laufen, als denn mit radeonhd. Das wiederum ist nur ein subjektiver Eindruck, mittels timedemo habe ich da nichts gemessen.
 
olhe schrieb:
Quick and dirty ging ich auch mal den Patch an, die Stabilität und Qualität in einigen Programmen ist damit ein Iota besser. Bei mir verhält es sich jedoch "umgekehrt": radeonhd ist nicht wirklich der Bringer (auch -devel nicht), hingegen verhält sich xf86-video-ati am besten. Insbesondere ist bei darkplaces (Quake1 port) die glx-Version nutzbar, die spürbar Geschwindigkeit bringt. Die sdl Version hingegen, die man mit radeonhd nutzen muß, kommt schnell ins stottern. ioquake3-devel _scheint_ auch ein Stück flüssiger zu laufen, als denn mit radeonhd. Das wiederum ist nur ein subjektiver Eindruck, mittels timedemo habe ich da nichts gemessen.
Zum Vergrößern anklicken....

Ja, bei mir geht der Radeon eigentlich auch besser, nur glxgears tötet das System :rolleyes:. Ich habe es aber nun tatsächlich geschafft Compositing mit KDE4 hinzukriegen. Die CPU wird zwar ordentlich belastet (bei Effekten), aber insgesamt läufts sehr flüssig. Also was jetzt genau alles geht und was nicht durchschaue ich nicht ganz. Ich bin erstmal froh dass Compositing einigermaßen geht (transparentes yakuake und so).

edit: falls jemand pakete will, kann er sich melden, dann lade ich die irgendwo hoch.
 
Zuletzt bearbeitet:
Also ioquake läuft auch, aber bei 2048x1152 oder 1680x1050 nicht mehr flüssig. Und KDE-Compositing muss man ausschalten, aber das geht ja gottseidank mit ner Tastenkombination an und aus.

Insgesamt stimmt mich das aber schon mal positiv. Rendering-Probleme habe ich auch so gut wie keine mehr.

Demnächst werde ich mich mal an einer wine-32-jail versuchen, da wurde ja schon einiges berichtet hier. 3D-linuxulator wäre wohl mehr Frickelei als gut tut ;)
 
Wie schon geschrieben, ob nun "radeon" oder "radeonhd" besser läuft, kommt vor allem auf die Karte drauf an. Das scheint irgendwie an ihrer Firmware zu hängen. Mit dem xf86-video-ati in der kommenden Version 7.0 wird sich wohl noch einiges Verbessern. Sie haben da wirklich viel Arbeit reingesteckt, große Teile neu geschrieben und so weiter. Muss man mal schauen. Gab da auch den Plan, radeonhd mittelfristig aufzugeben.

Das Quake III in sehr hohen Auflösungen nicht mehr flüssig will, wundert mich nicht. Ohne IRQ ist da einfach nicht mehr drin. Selbst die fette, stromfressende HD4870 hier bringt in 1680x1050 nur knappe 80 FPS. Das ist zwar spielbar, aber doch merklich weniger als die >750 FPS unter Windows 7. ;)

Das mit Wine und Linuxulator wird nicht gehen. Ein 64-Bit DRM kann unter FreeBSD auch nur 64-Bit Anwendungen beschleunigen. Wine und Linuxulator sind aber nur 32-Bit, er wird also sagen, dass Direct Rendering möglich ist, fällt dann aber dennoch auf den Softrenderer zurück. Es ist auch unwahrscheinlich, dass sich daran in naher Zukunft etwas ändern wird. Mixed Mode DRM ist eine riesige Aufgabe, sehr eklig umzusetzen und so weiter. Robert Noland wollte seine Zeit daher lieber in kernelbasierte Speichermanager (nicht zu verwechseln mit Kernel Modesettung) investieren, da die einfach dringender sind. Sonst gäbe es wahrscheinlich bald keine neuen Treiberversionen mehr.
 
Yamagi schrieb:
Wie schon geschrieben, ob nun "radeon" oder "radeonhd" besser läuft, kommt vor allem auf die Karte drauf an. Das scheint irgendwie an ihrer Firmware zu hängen. Mit dem xf86-video-ati in der kommenden Version 7.0 wird sich wohl noch einiges Verbessern. Sie haben da wirklich viel Arbeit reingesteckt, große Teile neu geschrieben und so weiter. Muss man mal schauen. Gab da auch den Plan, radeonhd mittelfristig aufzugeben.
Zum Vergrößern anklicken....
Hm, meines Wissens kann der RadeonHD halt Sachen, die der Radeon nicht kann, z.B. Audio über HDMI, dynamisches Takten der GPU zu Stromsparen etc. Aber eigentlich wollen wir ja alle nur Frames ;) (Naja, weniger Stromverbrauch wäre schon nicht schlecht, gerade da auch meine CPU ja nicht runtertaktet [1] :/ )
Das Quake III in sehr hohen Auflösungen nicht mehr flüssig will, wundert mich nicht. Ohne IRQ ist da einfach nicht mehr drin. Selbst die fette, stromfressende HD4870 hier bringt in 1680x1050 nur knappe 80 FPS. Das ist zwar spielbar, aber doch merklich weniger als die >750 FPS unter Windows 7. ;)
Zum Vergrößern anklicken....
Hm, hast du da Informationen wann das mit dem IRQ gehen wird? ^^
Das mit Wine und Linuxulator wird nicht gehen. Ein 64-Bit DRM kann unter FreeBSD auch nur 64-Bit Anwendungen beschleunigen. Wine und Linuxulator sind aber nur 32-Bit, er wird also sagen, dass Direct Rendering möglich ist, fällt dann aber dennoch auf den Softrenderer zurück. Es ist auch unwahrscheinlich, dass sich daran in naher Zukunft etwas ändern wird. Mixed Mode DRM ist eine riesige Aufgabe, sehr eklig umzusetzen und so weiter. Robert Noland wollte seine Zeit daher lieber in kernelbasierte Speichermanager (nicht zu verwechseln mit Kernel Modesettung) investieren, da die einfach dringender sind. Sonst gäbe es wahrscheinlich bald keine neuen Treiberversionen mehr.
Zum Vergrößern anklicken....

Ach so, ich hatte irgendwie gedacht, dass ich in einer 32Bit-Jail auch 3D kriege, dass es also vom Userland abhängt und nicht dem DRM. Dann hätte das mit Wine ja geklappt.

Ach ja, ich sehe gerade auf [2], dass es mit dem proprietären Gesocks gehen soll. Aber das heißt ja nichts für mich, weil der Blob garkein DRM nutzt, oder? Und da ist auch die Rede von einem experimentellen kinderfressenden wine-amd64-Paket... hat das mal jemand getestet?
Diskussion hierzu vielleicht besser in [3]


[1] http://www.bsdforen.de/showthread.php?t=23625&page=2
[2] http://wiki.freebsd.org/Wine
[3] http://www.bsdforen.de/showthread.php?t=23733
 
Ja, RadeonHD kann so einigermaßen grottiges Powermanagement. Das ist besser als nichts und senkt hier den Stromverbrauch auch deutlich. Generell wollen sie das Powermanagement aber gern in den Kernel packen, ich habe keine Ahnung wie das unter FreeBSD umgesetzt werden wird. Aber da müssen die Linux-Kinders erst einmal in die Gänge kommen und es implementieren.

Mit den IRQ weiß ich ehrlich gesagt nicht vieles. Nur, dass es recht weit oben auf der Agenda steht. Vielleicht mit Mesa3D 7.8, aber das ist nun blind geraten.

Das Problem ist, dass DRM Daten zwischen Kernel und Userland hinundherschaufeln muss, aber deren Größe nicht kennt. Hat man nun unterschiedliche Bittiefen, passen die größen nicht mehr zusammen, die Folge sind interessante Fehler. Daher geht es nicht. Die Linux-Lösung ist nun, dass man in den Kernel zwei(!) DRM implementiert. Einen nativen und einen eklig zusammengefummelten für 32 Bit Anwendungen. Das funktioniert auch halbwegs gut, aber ist eben unter FreeBSD nicht verfügbar und nicht trivial zu porten. Mit dem bekannten Blob geht es, da nVidia ein eigenes Rendersystem nutzt und gänzlich ohne DRM auskommt. Man kann ja nicht wirklich reinschauen, aber es gibt Grund zu der Annahme, dass ihre Lösung ein wenig zeitgemäßer ist und Macken wie diese Bittiefen-Sache nicht in dem Ausmaß hat. Zumindest funktionieren mit Blob 32-Bit Anwendungen unter amd64 einwandfrei.

Das Wine-Paket ist aber auch ein 32-Bit Wine. Halt nur ohne chroot. Wine muss leider als 32 Bit Prozess laufen, da es einen 32-Bit Windows-Prozess vergaukelt. Man arbeitet an einem Wine64, aber das dauert sicher noch. :/
 
Hm, dann heißt es an der Front wohl einfach warten. Starcraft kriege ich immerhin mit wine und CPU flüssig hin, das ist ja schonmal was!

Nexuiz kommt allerdings nur auf 3 frames, auch in bescheidenen Einstellungen...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben