Grafikkarten-Treiber??

[Karümel]

Öhm, mal eine ganz doofe Frage. Wie funktionieren eigentlich genau Grafik-Kartentreiber“?
Und wie kommt es es das nur durch Treiberoptimierung so große Performance-Sprünge, jetzt in Bezug auf die fps, möglich sind?

[zeckensack]

Ein Grafikkartentreiber schnappt sich eine herstellerübergreifende Spezifikation (2D-GDI, D3D, OGL, Heidi etc) und setzt sie so um, daß die Grafikkarte direkt angesprochen werden kann.

Anders gesagt übersetzt der Treiber die Kommandos einer herstellerunabhängigen Sprache in für die jeweilige Graka passende Hardwarezugriffe.

Optimierung ist mir jetzt zu kompliziert :D

[Karümel]

Könntest Du das bitte etwas ausführlicher beschreiben?
Keine Ahnung ob man das jetzt überhaupt ausführlicher beschrieben kann?

[zeckensack]

Äh, was willst denn wissen?
Ich habe doch schon alles gesagt =)

Also, da einigen sich ein paar Firmen auf eine Spezifikation, daraus wird dann eine Programmierschnittstelle (=API). Diese ist einheitlich, wodurch sichergestellt wird, daß ein Programm das eine bestimmte API nutzt auf allen Karten läuft, die für diese API 'Treiber' haben.

ZB der Teil von Windows der die Fensterinhalte verwaltet ist eine solche API (GDI, graphics device interface oder so).

Die Spezifikation dieser API definiert zB eine Funktion namens DrawRectangle, die ein Rechteck ins aktive Fenster malen soll.

Diese muß dann im Grafiktreiber enthalten sein. Wann immer ein Programm DrawRectangle aufruft, benutzt es diese Fuunktion direkt in der Treiber-DLL. Kann die dazugehörige Graka das alleine in Hardware, dann macht der Treiber beim Aufruf nichts anderes als an ein paar Hardware-Registern rumzuspielen und ist fertig.

Kann die Graka es nicht in Hardware, hat der Treiber dafür zu sorgen daß es trotzdem funktioniert, ie das Rechteck muß irgendwo mittels CPU in den Hauptspeicher gemalt und dann auf die Graka geschoben werden.

Oder wenn du mit dem Begriff vielleicht was anfangen kannst
Treiber = Abstraktionsschicht zwischen Software und Hardware

[Mad-Marty]

Warum durch optimierung so grosse Sprünge möglich sind ist
ebenfalls ganz einfach meiner meinung nach.
Ich denke da wurde gewissen Funktionen nicht die gebührende
saubere programmierung genutzt, weil es niemand nutzte am Anfang,
und deswegen eben die Parallelität und Auslastung aller Einheiten nicht gut war.


Stell dir vor du hast ein programm was so aussieht


mov eax, 00000001
cpuid
mov [memory], edx
and [memory], 00800000
jnz mmx_vorhanden


schlecht, da sinnloses kopieren von daten im RAM

das selbe könnte auch so aussehen :

mov eax, 00000001
cpuid
and edx, 00800000
jz mmx_vorhanden

mittelmässig da eine addition vorliegt

oder noch besser:

mov eax,00000001
cpuid
test edx,00800000h
jnz mmx_vorhanden

optimal, da nur check ob entsprechendes bit gesetzt

Damit sparst du schoneinmal ein wenig, geht man allerdings
davon aus das gewisse funktionen pro sekunde 100 mal oder so durchlaufen werden, ist der Gewinn gross.

Das dient nur zur Veranschaulichung, da ich denke real mehr auf
SIMD gesetzt wird. Zusätzlich spielt auch die auslastung der Pipes
der Grafikkarte selbst eine Rolle, je öfter diese Brachliegt und auf etwas wartet desto schlechter die effizienz.

Pipes sind denke ich mal auch bei GPU's multistaged, sprich funktion 1,2,3 einer Pipe können gleichzeitig gewisse teilaufgaben einer anderen Aufgabe erledigen.

Dies muss mit allen Pipes harmonieren für beste Leistungen,
was die Sache unwahrscheinlich kompliziert macht, eine optimale Harmonie zu erreichen.


Programmierstil #3 kombiniert mit sehr guter pipeauslastung ist
der Killertreiber, sprich geringe Prozessorauslastung und optimale
nutzung der Karte.

Und zu guter letzt ist da noch die von nvidia evtl. rückhaltung der optimierten treiber für gewisse Situationen.

Hoffe die sache erklärt zu haben.

[Demirug]

Mad-Marty: Deine Assembler Beispiele sind zwar schön aber es wird wohl nur ein sehr kleiner Teil der Treiber wirklich Assembler Code enthalten. Das meiste wird in C und C++ geschrieben sein. Um solche Optimierungen kümmdert sich der Compiler. Es gibt auch extra Compiler die Code für SSE, MMX und 3dnow optimieren können.

Was nun die optimierungen angeht so muss man zwei Möglichkeiten unterscheiden.

Bessere Ausnutzung der Chipmöglichkeiten. Jeder Chip enthält Dinge die Programmierbar sind aber durch keine API offengelgt sind. Findet man nun einen Weg eine OpenGL oder D3D Anweisung besser vom Chip realisieren zu lassen ergibt sich ein Performancegewinn

Bessere Treiberverfahren: Gelingt es durch Änderung eines Algorithmus einzelne Funktionen beim Umsetzten von der API in die Chip-Steuercodes zu beschleunigen. Dadurch bleiben mehr CPU-Zyklen für das Spiel übrig.

[Mad-Marty]

Originally posted by Demirug
...Es gibt auch extra Compiler die Code für SSE, MMX und 3dnow optimieren können. ...

Bessere Treiberverfahren: Gelingt es durch Änderung eines Algorithmus einzelne Funktionen beim Umsetzten von der API in die Chip-Steuercodes zu beschleunigen. Dadurch bleiben mehr CPU-Zyklen für das Spiel übrig.


Demirug, sicherlich gebe ich dir da Recht das ein grossteil in C
geschrieben ist, aber ich würde es effizienter finder wenn die ~10%
wo das programm seine ~90% laufzeit verbringt entsprechend zu optimieren. Und ich denke genau das wird auch gemacht.

Ein compiler kann zwar gewisse optimierungen vornehmen, aber
bei manchen vermurksten Programmierstilen nützt das auch nix mehr ;-)

Auserdem könnte ich mir vorstellen das wenn die Balance nicht stimmt
wahnsinnig viele Zyklen einfach so "ver-wartet" werden.

siehe ATI OGL auf Athlons .... ein schönes Beispiel für ineffizienz ;-) durch mangelnde Optimierung i. Vergleich zu Detonator.


Gibt's bei GPU's auch so sachen wie bei CPU'? sprich TLB's und Branch
Prediction? ich denke schon ... oder könnte das einer der nachträglich
Programmierbaren Teile sein ?

[Demirug]

Mad-Marty:

Die Intel-Compiler sind zum Beispiel nur noch sehr schwer von Hand zu schlagen. In über 99% aller Fälle bringt ein besserer Algorithmus viel mehr als den schlechten in Assembler zu optimieren.

"Gibt's bei GPU's auch so sachen wie bei CPU'? sprich TLB's und Branch Prediction? ich denke schon ... oder könnte das einer der nachträglich Programmierbaren Teile sein ?"

Bisher war das ja nicht notwendig da es keine Branches gab. Und ich glaube irgendwo gelesen zu haben das man es im Moment nicht für sinnvoll hält solche Dinge in GPUs zu verbauen.

[Mad-Marty]

d.h. im nv30 gibts keine Branch Prediction :-(


nunja, ich würde denken das es später vielleicht doch einmal hinzukommt, spätestens wenn eine Firma überagende Shaderleistung bei c-jumps erreichen will.

Oder würde der nutzen nicht den Aufwand, sprich Preis lohnen

=)

[Xmas]

Originally posted by Mad-Marty
d.h. im nv30 gibts keine Branch Prediction :-(


nunja, ich würde denken das es später vielleicht doch einmal hinzukommt, spätestens wenn eine Firma überagende Shaderleistung bei c-jumps erreichen will.

Oder würde der nutzen nicht den Aufwand, sprich Preis lohnen

=)

Erst mal zum TLB, ein TLB ist doch für virtuelle Adressierung und Page-Tabellen, oder? Komplett virtualisierten Speicher hat aber AFAIK nur der P10, das würde also beim NV30 nicht viel Sinn machen.
Dynamic Flow Control gibt es doch auch nur im Vertex Shader, und ob dort Branch Prediction den Aufwand lohnen würde, wage ich zu bezweifeln.
Ansonsten ist es oft sogar schneller, mehrere Rechnungen auszuführen und dann ein Conditional Assignment zu machen, statt einen Jump zu nehmen.