freie Grafikkarte, die geht

h^2

hat ne Keule +1
Da freies 3D ja nicht wirklich zu Potte kommt mit den neuen Radeons und wenn der Support mal da ist, sicher Dinge wie Gallium/DRI2 oder anderes FOO benötigen wird, den es für FreeBSD noch nicht absehbar gibt, überlege ich mir eine ältere, besser unterstützte Karte zu kaufen. Gebraucht ist das ja nicht so teuer.

Laut free3d.org ist eine Radeon 850XT das Beste was man kriegen kann, mit bis zu 9000 fps bei glxgears. Das müsste ja eine r500 sein, wenn ich mich nicht irre. Könnt ihr bestätigen, dass die gut unter FreeBSD läuft?
Ich hätte gern compositing, dass die Reaktionszeit des Systems nicht runtersetzt, und wenigstens freie Spiele (ioquake-Derivate, Nexuiz etc) sollten gut laufen. Wenn irgendwann linux-emu unter amd64 3D kann, wären Dinge wie ut2004 auch schön…
Ich würde mich auch freuen wenn mplayer nicht generell 100% CPU braucht, und sein Speicherverbrauch nicht pro Minute 720p-Film um 40MB steigt…

Danke!
 
Also, wir können das gern alles nochmal durchkauen, aber für das Erste beschränke ich mich auf die Kurzfassung. Intel-Chips sind allgemein gut unterstützt, leider hat es in den letzten Jahren durch recht diskoordiniertes Gefrickel seitens der Treiberentwickler, einer verfrühten Umstellung auf GEM und KMS und dem Abschaffen von Entwicklungszweigen stark gelitten. Vor allem unter BSD, wo es noch kein GEM und kein KMS gibt. Besonders toll ist, dass die aktuellen Versionen des Treibers ohne GEM und KMS gar nicht mehr laufen, man sie aber für aktuelle Intel-Chips wie den Ironlake (die GPU der Core i3 und i5 Serien) benötigt. Dazu kommt, dass Intel-Chips technisch gesehen halt reine Desktop-GPUs sind. In Sachen 3D bilden sie im Moment den Bodensatz, technisch sind die irgendwo im Bereich einer Geforce 3 oder so. Zwar wird zumindest GEM wohl in absehbarer zeit auf FreeBSD portiert werden, doch alles in allem sind Intel-GPUs schlicht keine Option, solange man nicht sehr niedrige Ansprüche hat.

Bleibt also Radeon. Die Radeon-Familie unterteilt sich grob in vier Hauptgenerationen, welche jeweils durch einen DRM-Treiber abgedeckt wird. Der X.org-Treiber xf86-video-radeon unterstützt sie alle:

r100 -> ATIs erste echte 3D-Karte, im modernen Sinne. Stand damals gegen nVidias Geforce 2, war an sich keine schlechte Hardware doch mieserable Treiber, schlechte Firmware und einige schwer verständliche Designentscheidungen beim Chip verhagelten den Erfolg. Daher blieb die darauf basierende Radeon 7000 Serie ein Achtungserfolg. Ist zwar vollständig unterstützt, aber nur noch historisch relevant.

r200 -> ATIs zweiter Versuch, stand gegen die Geforce 3. Machte eine weitaus bessere Figur als der Vorgänger, hatte aber weiterhin starke Treiberprobleme. Heute auch nur noch historisch interessant, aber vollständig unterstützt. War als Radeon 8000 Serie im Handel.

r300, r400, r500 -> Mit dem R300 schaffte ATI seinerzeit den wirklich großen Durchbruch. Es war streng genommen keine Eigenentwicklung, stattdessen basierte der R300 zum größten Teil auf den Entwicklungen der von ATI gekauften SGI-Ausgründung ArtX. Der R300 war ein Monster, teils um bis zu 150% schneller als die dagegen stehende Geforce 4. John Carmack bezeichnete den R300 einmal neben dem 3Dfx Voodoo und der Geforce 256 als den wichtigsten Chip der Grafikgeschichte, da er Dingen wie Antialiasing zum Durchbruch verhalf. Der R300 bekam nur leicht überarbeitete zwei Nachfolger, den R400 und den R500. Die ganze Familie wurde anders als ihre beiden Vorgänger von ATI lange nicht mit Spezifikationen versorgt, die freien Treiber entstanden fast ausschließlich aus Reverse Engineering. Als ATI die Spezifikationen offen legte, war es es nur noch eine Frage von Wochen, die Karten komplett zu unterstützen. Die freien Treiber sind die im Moment vielleicht besten, der "r500" Treiber unterstützt die R300, R400 und R500 Familien. Die Handelsnamen waren: R300 -> Radeon 9000 Serie ; R400 -> Raden X800 Serie ; R500 -> Radeon X1000 Serie. Dazu einige Zwischengenerationen. Diese Karten sind natürlich durchgehend veraltet, wirklich empfehlen kann man nur noch die X1000 Serie, da sie als einzige ein sinnvolles Verhältnis aus Leistung und Stromverbrauch bietet. Ich habe hier einen Test einer X1950 pro geschrieben, dem damaligen "Performance Modell" der Serie: http://www.bsdforen.de/showpost.php?p=196839&postcount=2

r600, r700, r800 -> Die Serie ist die derzeit aktuelle, sie wird vom "r600"-Treiber unterstützt. Sie basiert auf dem "Xenos"-Chip, welchen ATI für die Xbox 360 entwickelte. Anders als alle Vorgänger ist es weitgehend eine "Unified Architekture", es gibt also keine speziellen Recheneinheiten mehr, stattdessen nur noch SIMD-Gatter (sogenannte Shader, welche zu Quads angeordnet sind). Das macht die Architektur sehr einfach, kostengünstig und gut zu erweitern, aber das Programmieren wird sehr schwer. Da benötigt man Just in Time VLIW-Compiler und solche Nettigkeiten, das ist alles nicht ohne. Auch wenn es Spezifikationen gibt, wirkt es sich auf die freien Treiber aus, es geht nur langsam voran. Vollständig ist noch keiner, doch es wird langsam. Im Handel sind: R600 -> Radeon HD2000 Serie, Radeon HD3000 Serie ; R700 -> HD4000 Serie (derzeit am besten von allen r600-Abarten unterstützt); R740 -> Radeon HD4700 Serie, eine Zwischengeneration, erst ab X.org 7.5 wirklich sauber unterstützt ; R800 -> Radeon HD5000 Serie, unter Linux nur unbeschleunigtes 2D, unter FreeBSD nicht unterstützt.

==> Wenn du heute halbwegs optimales 3D willst, kaufe eine X1950 Pro. Sofern du noch eine auftreiben kannst. Wenn du bereit bist zu warten, eine HD4850. In Sachen realer Leistung mit freien Treibern sind beide grob gleich, in der Theorie ist die HD4850 natürlich deutlich schneller. Sie benötigt aber auch viel mehr Strom, vor allem kann sie anders als eine X1950 Pro im freien Treiber nur verkrüppeltes Powermanagement.
 
Moin.
Wann ist es das nicht wenn er was schreibt. Für mich eigentlich immer erhellend.
Da wird das Niveau in die Höhe geschraubt :-)

Gruss TODuke
 
Jetzt kommt es auf den einen Off Topic Post auch nicht mehr an! :D

Ich finde Yamagis Beiträge auch immer sehr interessant und informativ. Ein Dank an Yamagi dafür an dieser Stelle.

Apropos Danke, kann man eine Danke-Button einbauen, wie es andere Foren auch teilweise bieten?

c.
 
@Yamagi: auch danke von mir natürlich für die Ausführungen, besonders der Link zu deinem anderen Post mit ausführlichen Tests war hilfreich.

Ich hatte besonders daran gedacht eine ältere Karte zu holen, weil nach vielen Berichten, auch die Entwicklung der Radeon-Treiber gerade auf Gallium umgestellt wird. Den r300g für r300,r400,r500 gibts schon und einen experimentellen r600g für die anderen auch. Wahrscheinlich landet der ganze Fortschritt bald darin, und nicht mehr in dem xf86-video-ati, oder? Also wenn man sich das bei Intel und Nouveau anguckt, glaube ich nicht, dass sie die alten Schnittstellen noch lange weitersupporten…
(deswegen kam die HD4850 erstmal nicht in Frage)

Bezüglich der X1950Pro, wie erklärst du dir, dass du damit 3000fps (glxgears) bekommen hast und Leute bei free3d.org mit der X850 fast 9000fps? Ich weiß glxgears ist kein benchmark in dem Sinne, dass sich eine Korrelation oder gar Linearität zur "echten" Performance ergibt, aber meine persönliche Erfahrung hat eigentlich immer gezeigt, dass mehr glxgears frames grundsätzlich auch mehr Leistung in anderen Bereichen bedeutet.

Die Kaufempfehlung von free3d.org ist auch X850 und nicht die X1950Pro, obwohl es zu der auch Test-Results gibt…
 
Ja, ja. Danke, danke... Ich bin ein bescheidener Mensch, da braucht man sich nicht zu bedanken. :)

Ja, Gallium ist natürlich ein Argument. Wie gesagt, die R300 bis R500 sind sicherlich die beste Wahl, wenn es um Unterstützung geht. Ob nun eine X850 (R400) oder eine X1950 Pro (R500) dürfte in Sachen Unterstützung nun nicht so wahnsinnig viel Unterschied machen, es ist schließlich der gleiche Code. Ich stand im letzten Frühjahr vor der gleichen Entscheidung, die X850 wäre mein Favorit gewesen. Doch es gab schon damals keine PCIe-Karten mehr neu und gebrauchte Hardware kaufe ich nicht. Ist mir zu unsicher. So blieb nur die X1950 Pro. :)

Tja, glxgears(1). Wie du selbst sagst, es ist kein Benchmark. Das Programm testet eigentlich nur, wie schnell du die Framebuffer tauschen kannst. glxgears ist daher extrem vom Gesamtsystem abhängig. Der verwendete Kernel, Linux ist da fast immer schneller als jedes BSD. Die Systemarchitektur, also wie sind Grafikkarte, RAM und CPU verbunden? Und auch wichtig, welche X.org-Version und welche Treiber kommen zum Einsatz? Sorry, aber ich halte glxgears für gänzlich ungeeignet, außer man will feststellen, ob Direct Rendering genutzt wird. Dennoch, hier noch einmal eine aktuelle Ausgabe von gerade eben:
Code:
15740 frames in 5.0 seconds = 3147.901 FPS
16503 frames in 5.0 seconds = 3300.551 FPS
16566 frames in 5.0 seconds = 3313.042 FPS
16594 frames in 5.0 seconds = 3318.756 FPS

Es hat sich also im letzten Jahr für mich nicht wahnsinnig etwas geändert, dennoch läuft ioQuake3 seit Mesa 7.6 besser als jemals zuvor. Irgendwie flüssiger, gradliniger, die Framerate ist stabiler.
 
Also ich glaube so langsam kann man ATI wieder kaufen. Der üble Treiber von früher hängt mir immer noch im Gedachtnis.
Weißt du zufällig wie es mit HDTV unterstützung ist, sprich; Kann Video auf der GPU dekodiert werden?
 
Nein. Kann es derzeit nicht und wird es auch nie können. ATI sagte erst letztens in einem Interview ganz klar, dass sie die Schittstelle zur Videodekodierung nicht freigegeben wird. Vermutlich, da darauf Rechte Dritter liegen und / oder man eventuell vorhandene DRM-Ketten per HDCP unterbrechen würde. Eine Alternative wäre natürlich das Video per OpenCL zu dekodieren, aber das ist noch sehr ferne Zukunft für freie Treiber.

Kurz um, wenn du Video-Dekodierung willst, kommst du um nVidia und den zugehörigen Blob (für FreeBSD/amd64 seit gestern in neuer Beta-Version) nicht drum herum. Mit Intel ginge es theoretisch auch, aber da ist noch nichts auf FreeBSD portiert. Außerdem ist Intels Video-Engine recht eingeschränkt, was die unterstützen Formate betrifft.

EDIT: Um Missverständnissen vorzubeugen, XVideo aka xv geht natürlich.
 
Ja, Gallium ist natürlich ein Argument. Wie gesagt, die R300 bis R500 sind sicherlich die beste Wahl, wenn es um Unterstützung geht. Ob nun eine X850 (R400) oder eine X1950 Pro (R500) dürfte in Sachen Unterstützung nun nicht so wahnsinnig viel Unterschied machen, es ist schließlich der gleiche Code. Ich stand im letzten Frühjahr vor der gleichen Entscheidung, die X850 wäre mein Favorit gewesen. Doch es gab schon damals keine PCIe-Karten mehr neu und gebrauchte Hardware kaufe ich nicht. Ist mir zu unsicher. So blieb nur die X1950 Pro. :).
Ok :) Ich glaube ich schau trotzdem mal nach einer gebrauchten. Ist ja nur Übergangsweise, und mit 10-20€ kann man auch nicht so viel falsch machen!

Nein. Kann es derzeit nicht und wird es auch nie können.
Hm? Aber es gibt doch jetzt Video-Beschleunigung über Gallium (XvMC ist wohl schon auf dem Weg). Ein SoC-Projekt dieses Jahr ist, h264 Decoder Support mit Gallium[1]. Und da das transparent ist, also über die Shader-API läuft, wenn ich das richtig verstanden habe, müsste es mit allen Treibern gehen die Gallium nutzen, also auch den zukünftigen Radeon-Treibern. Oder hab ich das falsch verstanden?


[1] http://www.phoronix.com/scan.php?page=news_item&px=ODA0Ng
 
Ich sprach von ATIs AVIVO-Video-Decoder. Das ist eine Hardwareimplementierung, die diverse Videoformate dekodiert. Sie kann außerdem Bildverbesserungen vornehmen. Nur leider ist sie anscheinend nicht von ATI selbst entwickelt worden, stattdessen zugekauft und sie ist Teil der DRM-Kette. Echtes AVIVO gibt es daher nur unter Windows. Wikilöschia schreibt dazu: "Der Unified Video Decoder (UVD) (früher auch „Universal Video Decoder“) ist ein Videoprozessor der Firma AMD und basiert auf der Technik der Multimedia-Prozessoren Xilleon. Die ersten Produkte, in die er integriert wurde, waren die ATI Radeon HD 2400 und 2600 der Radeon-HD-2000-Serie. UVD wird für Avivo HD benötigt."

Was Gallium da plant, ist mir zugegeben neu, da ich mich mit Gallium noch nicht wirklich beschäftigt habe. XvBA, XvMC und VDPAU sind drei Techniken, die das gleiche machen. Sie lagern Teile der Videoberechnung auf die Grafikkarte aus. Das sind einmal die Bewegungskompensation, genauso wie bei früheren MPEG-Beschleunigern, aber auch die sehr aufwändige diskrete Kosinustransformation. Die Grafikkarte entlastet den Prozessor dabei extrem, aber eben nicht vollständig. Es ist sozusagen die logische Weiterführung von XVideo.

Also, ich korrigiere mich. Wird eines Tages Gallium unter FreeBSD laufen, wird man vielleicht HD-Videos über die Grafikkarte beschleunigt dekodieren können. :)
 
So, ich habe jetzt für stolze 4€ eine X850XT ersteigert, die zwar ne Menge Krach macht, aber noch funktioniert! Das Stromkabel dafür hat schon 8€ gekostet :| (ich weiß man kriegt die auch per Mail-Order für ~1€ aber ich wollte nicht warten)

D.h. nicht so wirklich alles geht glatt, liegt aber glaube ich nicht an der Hardware.

Also erstmal die positiven Punkte:
* mit einem Athlon 2 X2 2.8Ghz kommts auf knapp 3200fps glxgears
* compositing mit KDE4 läuft flüssig. Selbt der Bildschirm-Würfel auf 2048x1152 ist kein Problem. Also so richtig flüssig.

Das Hauptproblem, was ziemlich aggressiv macht:
* wenn immer die Auflösung sich ändert (beim ersten Starten von X, beim Starten eines Spiels, xrandr…) bleibt der Bildschirm schwarz. Aus-Anschalten, Stecker rein-raus, oder "video-quelle-wechseln" am Monitor beheben das Problem, ist aber nervig. Ich weiß, das hört sich wie ein Monitorproblem an, ist es aber nicht (andere Systeme machen keine Probleme). Das Problem gibt es auch erst seit ich Xorg auf den neusten Stand gebracht habe (ich hatte den Rechner noch kurz auf einer ziemlich alten Version).

Inzwischen habe ich auch mal auf Mesa-7.8.1 upgedatet, was einige kleine Zeichenfehler behoben hat, die es vorher gab. Das Bildschirm-Schwarz-Problem ist aber nicht weggegangen.

Ansonsten schaffe ich es irgendwie nur nexuiz zum Laufen zu kriegen, was besonders kurios ist, da das sonst nie geklappt hat wegen seinen unglaublichen verschwenderischen Ansprüchen.
Alles andere macht Probleme:
* ioquake3 segfaultet beim Start
* linux-quake3 auch (das segfaultete nicht als ich noch linux_dri-7.0 hatte, jetzt habe ich linux-dri(7.4) )
* ut2003 startet problemlos, aber im Spiel funktionieren Maus und Tastatur nicht (im Menü schon :S ), d.h. man sieht alles schön animiert, nichts friert ein, aber man kann nicht joinen
* linux-doom3-demo, Bild im Spiel bleibt schwarz (Menü und Intro-Video gehen noch)

Mir ist nichts aufgefallen in den logs, aber ich hab sie mal angehangen!

Vielen Dank für eure Hilfe schonmal!
 

Anhänge

Das bekommen wir hin. Also erst einmal sind 3200 FPS in glxgears schon okay. Deine CPU ist eher langsam und AMD-Prozessoren sind da grundsätzlich langsamer als Intel. Wieso auch immer, eine logische Erklärung gibt es zumindest nicht. Außerdem ist glxgears ja kein Benchmark. Ein flüssiger Desktop und die Tatsache, dass Nexuiz flüssig läuft sind das schon wesentlich aussagekräftiger.

So, du hast FreeBSD 8.1-BETA1 oder irgendwie um den Dreh. Das sieht gut aus. Außerdem hast du ein aktuelles X.org, auch das ist gut. Der xf86-video-radeon ist aktuell. Bevor wir irgendwas weiteres machen, würde ich dich bitten, einmal den "Memory Scattering"-Patch einzuspielen: http://people.freebsd.org/~rnoland/drm-map_sg_rework-8.patch Er verbessert das Speichermanagement enorm und kann gegen seltsame Fehler helfen.
 
Hast du zufällig auch die ioquake3-devel ausprobiert? Die halte ich für die zuverlässigere Version. Die wichtigsten Patches portiere ich zwar zurück zum Release, aber eben nicht jede Kleinigkeit.
 
So, du hast FreeBSD 8.1-BETA1 oder irgendwie um den Dreh. Das sieht gut aus. Außerdem hast du ein aktuelles X.org, auch das ist gut. Der xf86-video-radeon ist aktuell. Bevor wir irgendwas weiteres machen, würde ich dich bitten, einmal den "Memory Scattering"-Patch einzuspielen: http://people.freebsd.org/~rnoland/drm-map_sg_rework-8.patch Er verbessert das Speichermanagement enorm und kann gegen seltsame Fehler helfen.

Hm, mit dem patch kreige ich drm nicht neugebaut (ich versuche aber mal gerade die ganze kernel zu cleanen und neuzubauen):
Code:
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common  -mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -c /crypt/usr/src/sys/modules/drm/drm/../../../dev/drm/drm_scatter.c
cc1: warnings being treated as errors
/crypt/usr/src/sys/modules/drm/drm/../../../dev/drm/drm_scatter.c: In function 'drm_sg_alloc':
/crypt/usr/src/sys/modules/drm/drm/../../../dev/drm/drm_scatter.c:101: warning: format '%ld' expects type 'long int', but argument 4 has type 'vm_pindex_t'
/crypt/usr/src/sys/modules/drm/drm/../../../dev/drm/drm_scatter.c:101: warning: format '%08lx' expects type 'long unsigned int', but argument 5 has type 'vm_offset_t'
/crypt/usr/src/sys/modules/drm/drm/../../../dev/drm/drm_scatter.c: In function 'drm_sg_free':
/crypt/usr/src/sys/modules/drm/drm/../../../dev/drm/drm_scatter.c:155: warning: format '%lx' expects type 'long unsigned int', but argument 4 has type 'vm_offset_t'
*** Error code 1

Stop in /crypt/usr/src/sys/modules/drm/drm.
*** Error code 1

Stop in /crypt/usr/src/sys/modules/drm.

Hast du zufällig auch die ioquake3-devel ausprobiert? Die halte ich für die zuverlässigere Version. Die wichtigsten Patches portiere ich zwar zurück zum Release, aber eben nicht jede Kleinigkeit.
Selbes Problem bei ioquake3-devel, hier mal der output bis zum crash:
Code:
%ioquake3-devel
ioq3 1.36_SVN1784 freebsd-i386 May 23 2010
----- FS_Startup -----
Current search path:
/home/user/.ioquake3-devel/baseq3/pak0.pk3 (3539 files)
/home/user/.ioquake3-devel/baseq3
/usr/local/share/quake3/baseq3/pak8.pk3 (9 files)
/usr/local/share/quake3/baseq3/pak7.pk3 (4 files)
/usr/local/share/quake3/baseq3/pak6.pk3 (64 files)
/usr/local/share/quake3/baseq3/pak5.pk3 (7 files)
/usr/local/share/quake3/baseq3/pak4.pk3 (272 files)
/usr/local/share/quake3/baseq3/pak3.pk3 (4 files)
/usr/local/share/quake3/baseq3/pak2.pk3 (148 files)
/usr/local/share/quake3/baseq3/pak1.pk3 (26 files)
/usr/local/share/quake3/baseq3

----------------------
4073 files in pk3 files
execing default.cfg
couldn't exec q3config.cfg
couldn't exec autoexec.cfg
Hunk_Clear: reset the hunk ok
----- Client Initialization -----
Couldn't read q3history.
----- Initializing Renderer ----
-------------------------------
QKEY found.
----- Client Initialization Complete -----
----- R_Init -----
SDL using driver "x11"
Initializing OpenGL display
Estimated display aspect: 1.778
...setting mode 3: 640 480
Using 8/8/8 Color bits, 24 depth, 8 stencil display.
Available modes: '2048x1152 1280x800 1440x900 1680x1050 640x480 800x600 1024x768 1280x960 1280x1024'
GL_RENDERER: Mesa DRI R300 (R420 5D52) 20090101 x86/MMX+/3DNow!+/SSE2 TCL
Initializing OpenGL extensions
...GL_EXT_texture_compression_s3tc not found
...GL_S3_s3tc not found
...using GL_EXT_texture_env_add
...using GL_ARB_multitexture
...using GL_EXT_compiled_vertex_array
...ignoring GL_EXT_texture_filter_anisotropic

GL_VENDOR: DRI R300 Project
GL_RENDERER: Mesa DRI R300 (R420 5D52) 20090101 x86/MMX+/3DNow!+/SSE2 TCL
GL_VERSION: 1.5 Mesa 7.8.1
GL_EXTENSIONS: GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_provoking_vertex GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_MESAX_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_gpu_program_parameters GL_EXT_histogram GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_APPLE_packed_pixels GL_ATI_blend_equation_separate GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_ATI_separate_stencil GL_IBM_multimode_draw_arrays GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texture_rectangle GL_NV_texgen_reflection GL_NV_vertex_program GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SUN_multi_draw_arrays
GL_MAX_TEXTURE_SIZE: 2048
GL_MAX_TEXTURE_UNITS_ARB: 8

PIXELFORMAT: color(24-bits) Z(24-bit) stencil(8-bits)
MODE: 3, 640 x 480 windowed hz:N/A
GAMMA: hardware w/ 0 overbright bits
rendering primitives: single glDrawElements
texturemode: GL_LINEAR_MIPMAP_NEAREST
picmip: 1
texture bits: 0
multitexture: enabled
compiled vertex arrays: enabled
texenv add: enabled
compressed textures: disabled
Initializing Shaders
----- finished R_Init -----
------ Initializing Sound ------
Loading "libopenal.so.1"...
Segmentation fault (core dumped)

OpenAL ist openal-soft-1.12.854, das die ports mitgezogen haben…

BT gibts nich wrklich, nur
Code:
(gdb) bt
#0  0x284dd03d in strlen () from /lib/libc.so.7
(gdb)

edit: Kernel neuabuen gehen definitiv nicht mit dem patch
 
Zuletzt bearbeitet:
Hmm. Das ist interessant. Ich habe jetzt mal von OpenAL auf OpenAL-Soft gewechselt und ich kann das Problem nicht reproduzieren. Wahrscheinlich hat es nichts mit OpenAL zu tun.

Starte mal mit folgendem Kommando:

ioquake3 +set vm_ui 0 +set vm_cgame 0 +set vm_game 0
 
Hmm. Das ist interessant. Ich habe jetzt mal von OpenAL auf OpenAL-Soft gewechselt und ich kann das Problem nicht reproduzieren. Wahrscheinlich hat es nichts mit OpenAL zu tun.

Starte mal mit folgendem Kommando:

ioquake3 +set vm_ui 0 +set vm_cgame 0 +set vm_game 0

Hm, hilft nicht. Schon seltsam. Quake3 ist das so fehlerunanfälligste was ich kenne, eigentlich...

edit: linux-ut2004-demo funktioniert problemlos mit sehr guter performance. Irgendwie glaube ich da würfelt jemand :rolleyes:
 
Zuletzt bearbeitet:
Aargh. Das ist jetzt zugegebenermaßen problematisch. Da du auch amd64 verwendest erscheint mir das noch seltsamer.

Vielleicht gibt die Ausgabe von
> pkg_info -rx ioquake3
noch Hinweise aber ich glaube nicht daran.

Es gibt noch einen 64Bit Fix in r1785 im VM Interpreter, aber da das Problem ohne VM auch auftritt, wird das wohl kaum weiterhelfen.
 
h^2 schrieb:
Hm, mit dem patch kreige ich drm nicht neugebaut
Ach Mist, dann passt der Patch nicht mehr auf den Rest des Systems. Dann vergiss es. Da du keine Intel-CPU hast, wird er dir wahrscheinlich eh nichts bringen. Du kannst ohne ihn das radeon.ko lediglich nicht neu laden, wenn du es einmal entladen hast. Aber damit kann man leben.

So, wegen Quake 3 und anderen Abstürzen. Da wäre es sehr wichtig erst einmal herauszufinden, ob er wirklich an Mesa3D crasht. Das geht ganz einfach. Du schaltest in der xorg.conf einfach DRI ab: 'Option "DRI" "false"' in die Device-Sektion zur Grafikkarte und Ruhe ist. Crasht er dann noch immer, sind wir genauso schlau wie vorher. Crasht er nicht mehr und beginnt grottenlahm da indirekt gerendert das Menü darzustellen, wissen wir, dass DRI schuld ist.

Auch mit den Monitoren und ihren Aussetzern wäre es das Erste, was ich mal versuchen würde. Nur, um es einzugrenzen. Bringt das nichts, bleiben noch mehrere Möglichkeiten und Optionen in der xorg.conf, an denen man drehen kann. So ist das leider mit freien Treiber. Vor dem Spaß muss man ein wenig leiden. Was wiederum nVidia die Leute in Arme treibt...
 
Beide Probleme (Schwarzer Bildschirm nach Auflösungsänderung und ioq3-crash) passieren auch mit deaktiviertem DRI.
 
Zurück
Oben