Beiträge von CryptonNite

Ja, sehr dominierendes Kühlaggregat, das du da hast.

http://cgi.ebay.de/3DFX-Voodoo-4-…A1%7C240%3A1318

ne V4 4500 AGP. Angeblich schon zehn (10) Jahre im Besitz...

DU TOTENGRÄBER

Guck mal aufs Datum!

Ja, oder die Treiber im Quelltext veröffentlichen, wenn man maximalen Speed haben möchte.

Nein, wenn du den Laufwerksbuchstaben z.B. auf D: festlegst, ist die nächste Partition halt E:, es wird nur anders geordnet, der Übersicht halber.

Du kannst im Gerätemanager deinem CD-ROM-Laufwerk einen Laufwerksbuchstaben fest zuweisen. --> Laufwerk auswählen --> Erster Laufwerksbuchstabe und Zweiter Laufwerksbuchstabe auf den selben setzen. Problem ist jetzt aber, daß du die Partition schon erstellt hast.

Das könnte eine der ersten verkauften V5 5k5 AGP sein. Die mit den Problemen mit dem Stromanschluß oder was das war.

Also, ich hab folgende Einstellungen im Rivatuner verwendet:

- Treiber Version 94.24
- LOD -3.0
- Intellisample: High Quality
- Degree of anisotropy: force level 16
- Antialiasing method: 8xS
- Transparency antialiasing: supersampling

Und heraus kommt das:
[Blockierte Grafik: http://www.abload.de/img/ut2k4weuy.jpg]

UT2k3/4 auf OpenGL mit ner Voodoo 4/5 ist schon etwas schwerer anzustellen, denn eine OpenGL-Extension ("brga-textures" oder so) ist nicht supportet, sowohl unter Linux als auch unter Windows.

Bei neueren Treibern funzt teilweise das Supersampling nicht mehr, was bei LOD -3.0 angebracht wäre, weil es das ganze Bild glättet. Soviel ich weis, unterstützen alle ab der GeForce 8 kein Supersampling mehr, sondern nur noch Multisampling. Dadurch hast du auch bei der höchsten Einstellung das Texturflimmern durch den negativen LOD, da Multisampling nicht das gesamte Bild glättet.
OpenGL kannst du bie UT2004 nur über die ini einstellen.
In der Sektion [Engine.Engine] der UT2004.ini einfach das Semikolon vor der Option "RenderDevice=OpenGLDrv.OpenGLRenderDevice" löschen und bei "RenderDevice=D3DDrv.D3DRenderDevice" setzen.
Bedenke aber, daß der OpenGL-Part des 2x-Builds der Unreal Engine nicht mehr offiziell ist.

Versuchs mal mit KernelEX http://x86.neostrada.pl/KernelEx
Damit kannst du dem Installer ein anderes Windows vorgaukeln und gewisse NT-spezifische Sachen unter 9x verfügbar machen. Damit habe ich u.a. Firefox 3 und Code::Blocks 8.02 (beide sind 2k/XP-only) am Laufen.
Aber vorher die README lesen!

[Blockierte Grafik: http://www.abload.de/img/codeblocks_winmehfpx.png]

Zitat von RaVeNsClaw

Mal ne ganz blöde Frage :
Warum Kompilieren sich Treiber nicht "einfach" bei der Treiberinstallation?

Ganz einfach:
Am Aufbau eines Treibers kann man die Funktionsweise der Hardware oder einzelner Techniken erkennen.
Da man in einem ständigen Konkurrenzkampf arbeitet, sind die Sourcen geschlossen, denn man will ja nicht, daß die Konkurrenz diese Technik ohne Weiteres nachbaut.
Die Linux-Treiber für ATi (igitt, die sind noch schlechter, als die Treiber für Windows) und nVidia ( ) beinhalten aber auch Treiber-Sourcen, z.B. für das Control Panel und das Kernelmodul. Unter Linux ist das auch egal, denn Linux hat nur OpenGL (oder auch Glide) als Schnittstelle zur 3D-Hardwarebeschleunigung und die Spezifikation zu OpenGL ist für jeden auf http://www.opengl.org einsehbar, wobei Closed-Source Treiber unter Linux ne Grauzone ist. Auf alle Fälle gilt dann der Kernel als "tainted", beschmutzt.

Eine Optimierung auf nem P4 für nen Athlon XP ist nicht möglich, da die Funktionsweise der Prozessoren unterschiedlich ist. Sie sind zwar beide x86, aber sie sind technisch völlig unterschiedlich aufgebaut, daher kann ein Compiler auf nem P4 nicht auf einen Athlon XP optimieren.

Wenn du Sourcen auf nem P4 kompilierst, dann sind die eben auf deinen P4 zugeschnitten und optimiert, weil der Compiler für eben diesen P4 den schnellsten Binärcode erzeugen muß.

Man kann allerdings auch dem Compiler sagen, daß er den Code auf Speed optimieren soll (geht z.B. beim GCC), was auch auf fremden Prozessoren etwas bringt. Allerdings ist der entstehende Binärcode auch nur auf dem Rechner am schnellsten, auf dem er erzeugt wurde.

Wenn du maximale Geschwindigkeit für ein Programm auf deinem Rechner haben willst, kommst du aber NIEMALS um das Kompilieren herum.
Mit Optimierungen kannst du zwar auch Speed erreichen, aber selbst kompiliert ist immer schneller.

Ob die Binary aber sich großartig in der Größe ändern würde, weis ich aber auch nicht. Ich denke aber, daß sich die Größe unterscheiden wird, denn es müsste ja einmal für den P4 und einmal für den AthlonXP optimierter Binärcode eingearbeitet werden.

Zitat von GrandAdmiralThrawn

Ich hab zwar auch schon viel Code gebaut (oder eher: Dem Build System / Compiler gesagt, er soll tun, ohne selbst viel Hand anzulegen), aber eines möchte ich gerne wissen!

Ich es nicht möglich, Code für unterschiedliche Zielarchitekturen und CPU Features zu bauen (sodaß der Code einfach die CPU und ihre Feature Flags entsprechend detektiert, und nutzt, wenn vorhanden?)? Also sagen wir, ich baue ein Binary mit SSE2 Support, optimiert für eine P4 Pipeline. Aber ich baue auch einen Codepfad mit rein, der sauber und schnell auf Athlon64 CPUs rennt? Geht das nicht? Ein Binary, das auf mehrere Architekturen gleichzeitig optimiert ist..

Also, wenn ich dich richtig verstehe, fragst du, ob man z.B. X86 und X86_64 in einer Binary mischen kann. Das geht nicht, oder ist mir nicht bekannt. Der Binärcode ist zu unterschiedlich. Das merkt man z.B. schon an unterschiedlichen Varianten von Assembler, da gibts sogar Unterschiede zwischen Linux und Windows X86-Assembler.
Ein Programm, daß für X86 in Assembler geschrieben ist, sieht z.B. ganz anders aus, als das selbe Programm mit der selben Funktion für PPC in Assembler.
Unterstützt der Compiler allerdings die Architektur, z.B. X86_64, dann kann man dem Compiler beim Übersetzen mitteilen, daß er dafür optimieren und kompilieren soll. Man sollte die Sourcen aber auch an die architekturspezifischen Limitierungen (z.B. maximale Größe einer Variable) anpassen.

Man kann aber natürlich Unterstützung für Extensions wie MMX, SSE oder 3DNow! natürlich in eine Binary einkompilieren, die dann aktiv wird, falls die CPU diese unterstützt.
Allerdings MUSS man dann eine Funktion schreiben, die dies auch vorher ausliest, sonst hat man am Ende z.B. eine Binary, die auf nen Athlon einwandfrei läuft, aber auf nem Pentium ständig abstürzt, weil der Pentium kein 3DNow! unterstützt.
Aber hin oder her, der Compiler optimiert immer auf die laufende Maschine, mit Ausnahme von Cross-Compilern.
Darum hatte man auch früher Programme ausschließlich im Quellcode verkauft, getauscht und weitergegeben. Eingefleischte Linuxer, so wie ich ( :] ), bauen unter anderem aus gerade diesem Grund ihr Linux selbst aus den Quellen auf. Es ist zwar harte Arbeit und langwierig, aber die Geschwindigkeit entschädigt am Ende.

Theoretisch schon, da ein Grafiktreiber am Ende auch nur auf der CPU abläuft, damit die CPU weis, wie sie die Grafikkarte ansprechen soll und was die Grafikkarte überhaupt kann.
Je schneller der Treiber auf der CPU läuft, desto schneller wird die Graka mit Anweisungen und Daten gefüttert und umso effizienter kann die Graka arbeiten und ist somit auch schneller.
Besonders bei 3Dfx würde man das bei Win9x/ME-Systemen spüren, denn diese Treiber für V3/4/5 haben diese 2 T&L-Emulationen (Referenz und optimierte Emulation), die dadurch auch schneller sein würden.

Manchmal kann es, gerade bei übertakteten Systemen, sein, daß diese nur mit einem RAM-Riegel stabil laufen. Meistens hilft da nur runtertakten.
Startet dein WinXP auch nicht?

Zitat von rockys82

Ansich will ich da die FX5800Ultra als AGP Karte lassen für Spiele und für Glide kommt da meine V5-PCI rein. Ich weiß nur nicht ob es eine art Adapter gibt womit ich mit einem Monitor auf 2 Grafikkarten gehen kann und dann immer per Schalter umschalte.

Ja, solche Umschalter gibt es. Bei mir gibts nen Eletronic Partner, der verkauft diese Dinger für 5 EUR oder so. Du kannst dann bequem zwischen Graka1 und Graka2 umschalten.

Für alle, die glauben, daß ein Programm in Binärform immer gut und schnell läuft, sei einmal folgendes Beispiel des Performance-Vorteils, der durch das Kompilieren auf der eigenen Maschine entsteht, aufgezeigt. Der Vorteil dieser Optimierung ist teilweise sehr gravierend, da der Compiler den für die eigene Maschine am schnellsten ausführbaren Binärcode erzeugt.
Ich habe dazu ein wirklich kleines und einfaches Programm in C geschrieben, daß im Prinzip nur aus einer For-Schleife besteht, die 100.000 Mal "Hallo Welt" ausgibt und die für die For-Schleife benötigte Zeit misst. Die genutzte IDE ist Code::Blocks 8.02, der Compiler dazu ist der GCC.
Einmal habe ich den Code auf meiner Voodoo-Kiste (siehe Sig) übersetzt und einmal auf meinem aktuellen System mit Athlon64 X2 4200+ @ 2500 MHz, beide Male im Debug-Modus, also ohne jegliche Optimierung. Beide Programme liefen anschließend auf meinem Athlon64 X2.

Das hier ist der Code des "Programms":

/* Dieses Programm gibt 100.000 Mal "Hallo Welt" aus und misst die dafür benötigte Zeit */


#include <stdio.h>
#include <time.h>


#define GRENZE 100000. /* Anzahl der "Hallo Welt"-Meldungen */


int main(void)
{
        int i;
	for(i=0; i <= GRENZE; i++)
		{
			printf("Hallo Welt, zum %i. Mal\n", i);
		}
		printf("\nEnde erreicht! \nZeit: %8.3lf Sekunden\n", (double) clock() /CLOCKS_PER_SEC);
		getchar(); /* Damit man das Ergebnis sehen kann */
		return 0;
}

Folgendes Ergebnis eröffnete sich mir:

Code kompiliert auf AMD Athlon Thunderbird 900 MHz, Windows XP, Debugmodus (keine Optimierungen), ausgeführt auf Athlon 64 X2 4200+ @ 2500 MHz
[Blockierte Grafik: http://www.abload.de/img/athlon91go.png]

Code kompiliert auf AMD Athlon64 X2 4200+ @ 2500 MHz, Windows XP, Debugmodus (keine Optimierungen), ausgeführt auf Athlon 64 X2 4200+ @ 2500 MHz
[Blockierte Grafik: http://www.abload.de/img/athlon64x2h2nq.png]

Man sieht also, daß der für die eigene Maschine generierte Binärcode ~14 mal schneller ist, als der fremde Binärcode. Umgedreht ergibt sich ein ähnliches Ergebnis auf meiner Voodoo-Kiste.

Ein ähnliches Ergebnis habe ich auch schon beobachtet, wenn man den Code auf einem Athlon XP 2600+ ausführt. Die Unterschiede sind zwar nicht so extrem wie in diesem Beispiel, aber deutlich zu bemerken.
Auf meinem Voodoo-System schaffe ich es auf eine Laufzeit von unter 20 Sekunden (~19,2s, Shot reiche ich eventuell noch nach), auf meinem alten Hauptsystem mit dem Athlon XP 2600+ schaffte ich es NICHT unter 23 Sekunden, obwohl das System deutlich schneller war, als meine Voodoo-Kiste.

Dieses Programm lässt sich übrigens besonders dafür misbrauchen, den Geschwindigkeitszuwachs, der durch das Übertakten entsteht, anzuzeigen und zu messen. Es reagiert auch auf Timing-Änderungen des RAM's. Ein Single-Core-Prozessor wird zu 100% ausgelastet und stürzt bei der Ausführung des Programms normal nicht ab, wenn er durch Übertakten instabil ist, das Programm stockt dann lediglich (zumindest bei meinen Experimenten) und die benötigte Zeit zum Ausführen wird mehr.

Daraus folgt: Wenn man z.B. den Grafiktreiber der Voodoo's eigens auf dem eigenem System kompiliert, ist die Chance SEHR HOCH, deutlich BESSERE Performance aus seiner Voodoo herauszuholen. Man muß den Code aber leider so anpassen, damit man ihn auch mit einem modernen Compiler übersetzen kann.

EDIT: Ich sollte nicht so große Postings machen, denn da entstehen viele Fehler

[Blockierte Grafik: http://www.abload.de/img/screenshot14igf.jpg]

30 EUR... Das geht ja mal gar nicht.