Mesa3D 7.6.1 (3D-Beschleunigung für ATi Radeon HD2000 bis HD4000 Serie) committet

Yamagi

Yamagi

Possessed With Psi Powers
Teammitglied
So, lange hat es gedauert, da es hunderte technische Probleme gab. Aber nun ist es endlich passiert, nork@ hat vorhin Mesa3D 7.6.1 in die Ports committet. Damit wird in erster Linie 3D-Beschleunigung für die ATi Radeon HD2000 bis HD4000 Serien ermöglicht, aber auch einige andere Neuerungen in der OpenGL-Unterstützung, von denen Intel- und VIA-Chips profitieren.

Zwei Dinge muss man beachten:

- 3D für die Radeons braucht ein 8-STABLE oder 9-CURRENT. Das 8.0-RELEASE reicht nicht aus, außer man patcht den Kernel. Was natürlich nicht empfohlen ist, auch da 8-STABLE gegenüber 8.0 schon eine Reihe Bugfixes enthält.

- Um Nouveau nicht zu brechen, wird noch immer die alte Version 7.4.4 installiert. Außer man schreibt sich "WITHOUT_NOUVEAU=yes" in seine /etc/make.conf. Die Ports identifizieren sich daher bei Freshports weiter als Version 7.4.4.

Der Commit:
Code: 
Limited Update to Mesa3D 7.6.1 and libdrm 2.4.17.

[MEMO]
In this commit, no version changed.  But if you put
'WITHOUT_NOUVEAU' on /etc/make.conf, you can use
new version of Mesa3D and libdrm.

Discussed with: rnoland on freebsd-ports/freebsd-x11.
 
Kleines Update: Mit 8-STABLE und einem Patch von Robert Noland kommt meine HD4870 unter Quake III Arena nun auf 140FPS. Das ist grob doppelt soviel wie vor dem Patch. Natürlich nicht optimal, was nach wie vor daran liegt, dass R600 keine IRQ kann, aber es ist nun wirklich uneingeschränkt spielbar. Quake III zeigt auch keinerlei Grafikfehler mehr. In Blender (eine gute Anwendung um OpenGL-GUIs zu testen) sind sie Menüs nun auch endlich ohne Lag nutzbar. Also es geht klar voran und wenn eines Tages die blöden IRQ denn endlich mal kommen, dürfte da auch halbwegs konkurrenzfähige Performance drin sein. :)

Der Patch: http://people.freebsd.org/~rnoland/drm-radeon-8-test.patch
 
Hm, hat bei mir nichts gebracht. glxgears immernoch < 500fps. Nexuiz-glx <3fps :(
Mit Mesa 7.7…
 
Das klingt nicht wirklich so, als würde es funktionieren wie es sollte. Setze mal die Umgebungsvariable "MESA_DEBUG" auf 1 und rufe dann "glxgears -info" auf. Die Ausgabe kopierst du hier rein. Idealerweise kann man draus erkennen, was ihm fehlt :)
 
Was genau aus den Ports muss hier eigentlich alles neu gebaut werden? Einfach nur libdrm?
 
Nein. Du setzt das "WITHOUT_NOUVEAU=yes" in die make.conf, was Magie in der bsd.mesalib.mk aktiviert, wodurch die neue Mesa-Version genutzt wird. Das ist nötig, da der Nouveau nicht mit der neuen Mesa-Lib zusammenarbeitet. Man kann ihn auch nicht ohne Probleme aktualisieren, da er wieder Änderungen am Kernel bräuchte, die noch nicht portiert sind. War sozusagen der Kompromiss um das neue Mesa noch in diesem Jahrhundert reinzubekommen.

Auf jeden Fall zieht Portmaster mit der Variable gesetzt dann alle relevanten Ports durch. Das sind mindestens libdrm und libGL, auf vielen Systemen aber noch mehr Mesa-Komponenten wie z.B. libGLU, libGLw oder libglut sein. Lässt sich also nicht pauschal beantworten, kommt drauf an, was andere Programme wieder benötigen.
 
OK, das heißt also mein geliebtes pkg_version -Iol\< scheitert an dem Hack. Nun, dann lasse ich jetzt einfach mal portmaster darauf los. Danke für die Auskunft.
 
Yamagi schrieb:
Das klingt nicht wirklich so, als würde es funktionieren wie es sollte. Setze mal die Umgebungsvariable "MESA_DEBUG" auf 1 und rufe dann "glxgears -info" auf. Die Ausgabe kopierst du hier rein. Idealerweise kann man draus erkennen, was ihm fehlt :)
Zum Vergrößern anklicken....

So, habe ich angehangen! Danke :)
 

Anhänge

  • glxgears.txt
    2,8 KB · Aufrufe: 228
Schlechte Nachrichten. Es sieht alles so aus, wie es aussehen soll. Das XIO nörgelt, ist nichts weiter Schlimmes, hat man mal mit. Vor allem, da XIO am eigentlichen Rendering gar nicht beteiligt es, es wird ja direkt, also unter Umgehung des X-Server gerendert. Das Problem ist einfach, dass deine Karte zu langsam ist.

Ein Bisschen ausführlicher: "Mesa DRI R600 (RS780 9614) 20090101 TCL" sagt ja, dass es sich um einen RS780 Chip handelt. Der RS780 ist ein IGP-Chip, also in die Northbridge eingebaut. Die Dinger sind zwar für IGP immer noch recht schnell, aber dennoch gehören sie natürlich eher zum Low End Bereich. Technisch sind es trotz des Names im Wesentlichen unveränderte R600 Chips, die von AMD um ein paar neue Videofilter erweitert und umbenannt wurden. Was dich jetzt beißt, ist die miserable Performance der freien Treiber. Meine HD4870 hat einen R770 Chip. Der war zu Beginn das Topmodell der HD4000 Serie, wurde später durch den R790 ersetzt. Gemessen an aktuellen Karten ist meine noch immer untere Oberklasse, sie schafft unter Windows so ziemlich alles in FullHD-Auflösung flüssig. Der Leistungsunterschied zwischen dem RV780 und dem R770 liegt mal grob geschätzt irgendwo im Bereich des Faktor 12 bis 15. Da liegen also ganze Lichtjahre zwischen.
Nun schafft die HD4870 unter Windows in ioQuake3 etwa 850FPS, unter FreeBSD aber nur 150FPS. Sie ist also grob um den Faktor 5,5 schneller, wenn man den offiziellen Treiber nutzt. Quake III ist dabei noch nicht einmal ein anspruchsvolles Spiel bei dme die Grafikkarte ihre Kraft nicht einmal einmal entfalten kann. Ich will gar nicht wissen, was bei wirklich aktuellen Titel passieren würde. Machen wir mal eine Milchmädchenrechnung: 850FPS / 12 = 70FPS. Das wäre die Leistung der IGP unter Windows. Man mag nun argumentieren, dass es so nicht stimmt und man dort sicher auch >200FPS schafft. Denn wie ich sagte, Quake III lastet moderne Grafikkarten nicht einmal im Ansatz aus, weshalb die Framerate nicht linear zur Leistung skaliert. Aber das ist egal, wir wollen ja für FreeBSD rechnen, wo der Treiber klemmt. Nehmen wir nun 70/5,5 kommen wir auf ~13FPS unter Quake III und FreeBSD. Oder andersherum meine 150FPS / 12 = 12,5FPS für dich unter FreeBSD, was ähnlich bis gleich ist.
Nexuiz basiert nun auf der Darkplaces-Engine, ein stark verändertes Quake I Derivat. Es ist aufwändiger als Quake III, es ist ja auch neuer. Die 3FPS sind da nicht einmal so ungewöhnlich. So Leid es mir tut, solange der Treiber keine IRQ kann, wirst du kaum auf spielbare Framerates kommen. Und selbst mit IRQ würde ich mir keine großen Hoffungen auf >20FPS machen. Zumindest nicht, solange der Treiber an sich nicht noch deutlich schneller wird. :/
 
@yamagi:
Danke für die Ausführeungen. Ich hab mich damals für IGP entschieden, weil ja nicht abzuschätzen war, wie sich das mit den Treibern entwickelt und ich nicht Geld für ne Karte ausgeben wollte, die erst funktioniert, wenn sie wieder veraltet ist. Außerdem gabs da ja noch Gerüchte über die Intel-Standalone-karten mit zig GPUs (die irgendwie in der Versenke verschwunden sind).

Trotzdem hatte ich gehofft, dass da ein bisschen mehr möglich ist. Ich meine ioquake auf höchster Auflösung kriege ich sogar auf meinem Notebook hin (intel i945, auch mit externem Monitor). UT2003 konnte ich mit meinem alten Rechner (1400Mhz, nV FX5600/proprietär) sogar spielen. Ich hatte gehofft, dass das heutige low-end darankommt irgendwann mit den freien Treibern, zumindest da ich ja jetzt auch von 1x1400Mhz auf 4x3000Mhz in der CPU gesprungen bin.

Also ich kriege momentan ioquake3 auf 1024x768 gerade flüssig hin (aber mit crashes hier und da). Anscheinend geht das mit einer 50€-nVidia Karte und den reverse-enginierten, auf dem experimentellen Gallium aufsetzenden nouveau schon wesentlich besser[1]. Leicht ernüchternd :rolleyes:

Was mich aber schon überraschte, war dass die ganzen Dinge der letzten Zeit (wie diese Patche) null Verbesserung gebracht haben. Ich meine, wenn das auf anderen Karten 100% Steigerung gibt, müsste das dann hier nicht wenigstens 10% geben?


[1] http://www.phoronix.com/scan.php?page=article&item=nouveau_gallium3d_first
 
Bei mir hat das Update auch überhaupt keine Veränderungen gebracht (Intel Onboard mit shared Memory). Ich habe das auch nicht wirklich erwartet.

Zu ioq3 ist zu sagen, dass ich die Entwicklungsversion für zuverlässiger halte als das Release. Vielleicht hast du damit ja mehr Glück (nicht von der Performance her, aber von der Stabilität).
 
Für Intel wirkt der Patch praktisch nicht. Im Wesentlichen korrigiert er Bugs im Memory Mapping des DRM für Radeon-Karten, die ausbremsten und vor allem 3D-Anwendungen instabil machten. Wie weit sich das jetzt auswirkt, scheint sehr unterschiedlich zu sein. Hier brachte es viel, bei anderen nichts... Ich denke mal, dass Robert den Patch demnächst auch offiziell ins 8-STABLE committen wird. Dann haben alle was davon und vielleicht macht er es für einige besser.

Und sonst. Tja, wie ich letzten gerade erst schrieb. Es ist traurig, aber in Sachen Manpower und Entwicklungsgeschwindigkeit liegt Nouveau vorn. Und das, obwohl nVidias Architektur angeblich schwerer als die Radeons zu programmieren sein soll. Heißt es zumindest im Buschfunk. Intel liegt auf auf Platz zwei, ist ja der Referenztreiber für den X.org Umbau in Richtung KMS. Radeon kommt irgendwo unter ferner liefen. Also hilft nur warten oder in den vergifteten Apfel beißen...
 
Theoretisch ja. Aber Doom III und Konsorten kannst du nur unter FreeBSD/i386 spielen, da du unter FreeBSD/amd64 im Linuxulator keine Beschleunigung mit den Radeons bekommst. Allerdings würde ich keine spielbaren Bildwiederholraten erwarten. Wenn wir den Faktor 5,5 weiterhin zugrunde legen: Unter Windows habe ich in Doom 3 158FPS. 158 / 5,5 = 27 FPS -> Stark an der Grenze der Spielbarkeit. Bei 1680x1050.
 
Hi,
ich habe jetzt ein Stable mit dem neuen LibDRM jedoch ohne Patch. Als Root habe ich 3D Beschleunigung. Bloß als Normaler User nicht. In der xorg.conf steht:
Section "DRI"
Mode 0666
EndSection

Section "Extensions"
Option "Composite" "Enable"
EndSection
Zum Vergrößern anklicken....


Wenn das neue LibDRM nur für 8.0 Stable gedacht ist wieso steht es denn dann in 7.2 in Updating? Klar das die Datei die gleich ist egal welche Version läuft. Aber in den notes steht nichts von 8.0 Stable.

Mfg KO
 
Wenn das neue LibDRM nur für 8.0 Stable gedacht ist wieso steht es denn dann in 7.2 in Updating? Klar das die Datei die gleich ist egal welche Version läuft. Aber in den notes steht nichts von 8.0 Stable.
Zum Vergrößern anklicken....

Also das hätte ich jetzt auch gerne genauer gewußt. In Updating steht wirklich nichts davon. Wäre es nicht also doch möglich, libdrm und was noch dazu gehört, unter FreeBSD 7.2 neu zu compilieren, um so Mesa 7.6 zu bekommen?
 
Ihr verwechselt das was. Freie 3D-Beschleunigung besteht aus zwei grundsätzlichen Teilen:

Im Kernel der "Direct Rendering Manager" oder kurz DRM. Seine Aufgabe ist es, die Hardware zu steuern. Der DRM ist also von der eingesetzten FreeBSD-Version abhängig, solange man nicht am Kernel rumpatchen möchte. Was im Moment auch zugegeben nicht so einfach geht, das -CURRENT und die drei -STABLEs etwas auseinandergelaufen sind.

Im Userland eine Kette aus Mesa3D, libdrm und einem X.org-Treiber. Alle Magie liegt in dieser Kette. Die OpenGL-Aufrufe werden in Befehle für die Grafikkarte umgesetzt, diese per libdrm an den DRM im Kernel übergeben, welcher sie an die Grafikkarte schickt. Wichtig ist, dass Mesa3D und libdrm zusammenpassen müssen. Wenn ihr also Mesa3D - meist in Form von graphics/libGL - aktualisiert, MÜSST ihr auch libdrm aktualisieren.

Natürlich könnt ihr auch auf einem 7.x oder sogar 6.x das Mesa3D 7.6 mit zugehöriger libDRM nutzen. Wenn ihr nicht gerade den xf86-video-nouveau nutzt, ist das sogar sehr zu empfehlen. Denn es bringt bessere OpenGL-Unterstützung, diverse Fehlerkorrekturen und in der Theorie eine höhere Geschwindigkeit. Aber es bringt euch halt nur etwas für Grafikkarten, die der DRM im Kernel dieser älteren FreeBSD-Versionen auch unterstützt. FreeBSD 7 unterstützt zum Beispiel alle ATI-Grafikprozessoren von R100 (Radeon 7000) bis R500 (Radeon X1000). Die R600 (Radeon HD2000 und HD3000) bis R700 (Radeon HD4000) werden allerdings ausschließlich in FreeBSD 8 unterstützt, da auch nur in -STABLE. Wer also einen der letzten beiden Chips hat, kann auf seinem FreeBSD 7 gern das neue Mesa3D einspielen, es wird ihm aber nichts bringen, da die Kernelunterstützung fehlt.
 
OK, vielen Dank, das hilft auf jeden Fall weiter.
Da ich auf dem Notebook eine Radeon M X700 habe, und 3D bisher problemlos geklappt hatte, kann ich es also mit FreeBSD 7.2 ohne einen Kernelpatch versuchen.
Bin jetzt allerdings auf folgendes Problem gestoßen:

Zunächst "WITHOUT_NOUVEAU=yes" in die /etc/Make.conf eingetragen.

Ein portupgrade von libdrm, libGLU, libGL, libglut lief problemlos, man konnte im Text des Terminals auch immer sehen, dass von "Mesa 7.6.1" die Rede war.

Allerdings bekomme ich immer eine Fehlermeldung mit Abbruch beim port dri:

Code: 
DI915 -DDRM_VBLANK_FLIP=DRM_VBLANK_FLIP i830_context.c -o i830_context.o                           
In file included from i830_context.h:31,                                                           
                 from i830_context.c:28:                                                           
../intel/intel_context.h:38:26: error: intel_bufmgr.h: No such file or directory                   
In file included from ../intel/intel_context.h:40,                                                 
                 from i830_context.h:31,                                                           
                 from i830_context.c:28:                                                           
../intel/intel_screen.h:81: error: expected specifier-qualifier-list before 'dri_bufmgr'           
In file included from i830_context.h:31,                                                           
                 from i830_context.c:28:                                                           
../intel/intel_context.h:93: error: expected specifier-qualifier-list before 'drm_intel_bo'        
../intel/intel_context.h:166: error: expected declaration specifiers or '...' before 'dri_bo'      
../intel/intel_context.h:183: error: expected specifier-qualifier-list before 'dri_bufmgr'         
In file included from i830_context.c:28:
i830_context.h:133: error: expected specifier-qualifier-list before 'dri_bo'
i830_context.c: In function 'i830CreateContext':
i830_context.c:75: error: 'struct intel_context' has no member named 'ViewportMatrix'
i830_context.c:85: error: 'struct intel_context' has no member named 'no_rast'
i830_context.c:108: error: 'struct intel_context' has no member named 'verts'
gmake[5]: *** [i830_context.o] Error 1
gmake[5]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/mesa/drivers/dri/i915'
gmake[4]: *** [subdirs] Error 1
gmake[4]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/mesa/drivers/dri'
gmake[3]: *** [default] Error 1
gmake[3]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/mesa/drivers'
gmake[2]: *** [driver_subdirs] Error 2
gmake[2]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/mesa'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src'
gmake: *** [default] Error 1
** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portinstall20100307-41546-14wikp8-0 env make
** Fix the problem and try again.
** Listing the failed packages (-:ignored / *:skipped / !:failed)
        ! graphics/dri  (missing header)
elvis69#

Was ist hier los? Weiß nicht, was ich da vorher "fixen" kann. Es taucht da irgendwas von Intel, bzw. i915 auf, aber das habe ich nicht und das interessiert mich auch nicht.
Auch ein "make deinstall" und "make reinstall" in dri hat nichts gebracht, ebensowenig wie ein freebsd-update fetch install, damit werden doch auch die Kernel-Sourcen upgedatet, soweit ich das verstehe. Was soll ich also tun, um dri bauen zu können?
 
Seit geraumer Zeit habe ich nun auch unter FreeBSD 8.0-STABLE die neue MESA Bibliothek inkl. libdrm. Um es vorwegzunehmen: auf meinem System mit einer HD4830 kann ich so gut wie keine Veränderungen zu vorher feststellen - auch nicht mit/in Blender. (ich verwende den RADEONHD-Treiber, hier die DEVEL Version, neuester Stand gemäß Ports). Nach wie vor funktionieren kleine HD4000er Karten nicht. Mein Laborrechner ist eine Quad-Core Q6600 Maschine mit 8 GB RAM, die ebenfalls FreeBSD 8.0 fährt. Auch hier die neue MESA Bibliotke samt libdrm eingerichtet wie empfohlen. Sowohl eine HD4670 als auch eine extra alternativ angeschaffte HD4770 können nicht mit aktiviertem DRI betrieben werden, nach Verlassen der Sitzung crasht die Kiste bzw. friert der Schirm ein - das Sprite des Mauszeigers wird rasterisiert dargestellt und die Kiste steht. Mit aktiviertem DRI (Option DRI ON) komme ich meist gerade bis zum Login des xdm, dann Frost/Frust. ich hatte schon das SMP im Verdacht, aber selbst Abschalten dessen und Reduktion des physikalischen Speichers von 8Gb auf 2GB bringt nichts. Das problem tritt auch auf anderen Maschinen unter FreeBSD 8.0 mit diesen beiden Karten auf. Schade. Die Vernunft und Geldmittel rechtfertigen in keinster Weise eine HD4850 oder HD4870, ganz zu schwigen von HD5000 Karten (und Neuanschaffungen kommen nun mal nicht mit Uralt-Karten). In meinem Institut war das leider das Todesurteil für FreeBSD - und das mit gutem Recht.
 
Was sagt denn Xorg.0.log? Hast du mal den »radeon«-Treiber probiert? Oder die »normale« (nicht-devel) Version des radeonhd?
 
Also ich habe seit kurzem einen Rechner mit ATI-Chipsatz und integriertem Grafikchip. Hatte davor eine Nvidia-Grafikkarte die gut mit dem Blob funktioniert hat und hatte Bedenken, dass ich mit der Radeon auf einen unbeschleunigten Desktop ohne Compositing zurückfallen werde.

Dem war aber nicht so und ich war sehr positiv überrascht:
Compositing mit KWin unter KDE4 funktioniert tadellos mit ausreichender Leistung. Auch HD-Filme (720p) sind kein Problem.

dmesg
Code: 
drm0: <ATI Radeon HD 4200> on vgapci0
...
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

glxinfo
Code: 
name of display: :0.0                                                                  
IRQ's not enabled, falling back to busy waits: 2 0                                     
display: :0  screen: 0                                                                 
direct rendering: Yes    
...
OpenGL vendor string: Advanced Micro Devices, Inc.                                     
OpenGL renderer string: Mesa DRI R600 (RS880 9710) 20090101 x86/MMX+/3DNow!+/SSE2 TCL  
OpenGL version string: 1.2 Mesa 7.6.1  
...

xorg.conf
Code: 
...
Option      "AccelMethod" "EXA"                              
Identifier  "Card0"                                          
Driver      "radeon"                                         
VendorName  "ATI Technologies Inc"                           
BoardName   "RS880 [Radeon HD 4200]"
...
 
@true: Aus reinem Interesse: Funktionieren bei dir alle KDE4-Desktop-Effekte? Und geht OpenGL? (Bei mir nämlich nur XRender).
 
waki87 schrieb:
Was sagt denn Xorg.0.log? Hast du mal den »radeon«-Treiber probiert? Oder die »normale« (nicht-devel) Version des radeonhd?
Zum Vergrößern anklicken....

Xorg.0.log sagt überhaupt nichts Verdächtiges. Da das Spielchen nun seit über 5 Monaten schon so geht, sind die Permutationsmöglichkeiten schnell erschöpft gewesen. Bis vor erreichen des radeonhd-1.3 Treibers funktionierte der letzte radeonhd-1.2-devel aus den ports. Alle anderen, radeon inkl., zeigten ähnliche wenn nicht gar schlimmere Probleme. Mit einer HD4770 kann ich den radeonhd-devel (1.3.XXX) ohne DRI verwenden, mit besagten Unannehmlichkeiten. Die anderen Treiber frieren den Rechner nach Starten des xdm ein, kein coredump, nichts, die Kiste steht. Die HD4670 macht mit allen Treibern nur noch Unsinn.

Noch zur Vollständigkeit; Alle Systeme laufen ohne Ausnahme 64bittig ...
 
@waki87: Alle Desktop Effekte funktionieren und es ist auf Compositing Type "OpenGL" gestellt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben