ATI R300 Treiber/Hardware

[Mad--Marty]

Hi,

also mal was zum Thema ATI Treiber,
speziell für Leute wie OW, die von einer RXXX auf eine R300 schlussfolgern...

(@ ow: kein flame)

Das funktioniert in keinster Weise, da sich diese Karte vollkommen anders verhält, es existiert zum Beispiel die blöckchenbildung bei UT2 in Anatalus am Himmel nicht,
die Slowdowns sind auch weg.

Und die Tatsache das die fps recht konstant sind spricht auch für
sich, kaum schwankungen in diversen UT LEveln.

gesehen auf P4 2,8 mit R9700 PRO, auch sonst keine Probleme

OS: 2K
Treiber 6193


IMHO wurde das Chipdesign gut ausgelegt (keine slowdowns),
sowie der Treiber, welcher die bugs bei ut nicht hat.

(mal ganz abgesehen davon dass ut @ 1024 mit 4x FSAA / 16xAF genial ist bei 60 fps)


Fazit: definitiv kein UDA Treiber, oder genauer gesagt schon einer, aber mit unterschiedlichen anpassungen/dateien für jeden chip.


PS: alles Vermutungen

btw, welches ist eigentlich bei ATI treiber die D3D datei ?

[StefanV]

Bei solch unterschiedlicher Hardware glaube ich kaum, daß man ein Unified Driver machen kann.

Für den 2D Core und einige 'Basic 3D Functions' vielleicht, aber das meiste dürfte nur schwer möglich sein.

[Pussycat]

Und doch hat der R300 noch treiberfehler vom R200 (kann den Thread nicht finden, irgendwas mit PowerVR grafikdemos).

Aber Große Probleme hat ATI nicht eingebaut, womit sie wieder einen Schwachpunkt beseitigt haben. Ich jedenfalls würde eine ATI karte ohne Treiber-angst kaufen.

[ow]

Originally posted by Stefan Payne
Bei solch unterschiedlicher Hardware glaube ich kaum, daß man ein Unified Driver machen kann.

Für den 2D Core und einige 'Basic 3D Functions' vielleicht, aber das meiste dürfte nur schwer möglich sein.



Na SP, NVidia kriegt das doch auch hin.
Auch ein Deto 40.71 laeuft immer noch auf einer TNT. Und das nicht schlechter als auf einer Gf4 auch.

[ow]

Originally posted by Mad--Marty

btw, welches ist eigentlich bei ATI treiber die D3D datei ?


Das sind 3 Dateien, jeweils eine fuer die Radeon1, eine fuer die 8500er Serie und eine fuer die 9700.

AFAIR:

ati3d1ag.dll
ati3d2ag.dll
ati3duag.dll



Insofern ist der Treiber nicht unified wie bei NV, ich vermute dass die ATi Treiber 'statisch unified' sind (eine Source -> 3 *.DLLs beim Kompilieren), die NV Treiber funzen dynamisch.

[aths]

Originally posted by ow
Na SP, NVidia kriegt das doch auch hin.
Auch ein Deto 40.71 laeuft immer noch auf einer TNT. Und das nicht schlechter als auf einer Gf4 auch. Für den TNT werden meistens andere Routinen als für GF4 genutzt. Da gibt es kaum Code, der auf beiden gleichzeitig Verwendung findet. nVidia preist ihre "unified" Architektur zwar an wie sauer Bier, aber eigentlich lädt man mit jedem Deto ein halt Treiberpaket herunter. Dass bei der Entwicklung gewisse Teile für alle Karten verwendet werden können wäre auch machbar, wenn es TNT1/2 und GF3/4-Treiber getrennt downloaden könnte.

Dass "der" Treiber (in diesem Falle Deto 40.71) auch auf TNT läuft imho zu kurz ausgedrückt, denn TNT und GF4 verwenden nur oberflächlich gesehen den gleichen Treiber.

Hast du btw eine GF4, um einschätzen zu können wie der Deto40.71 darauf läuft?

[Demirug]

aths, das würde ich nicht unbedingt so sehen. Die benutzen Codepfade hängen von den im Chip vorhandenen Teile ab. Da die AGP Ansteuerung sich im wesentliche nie geändert wird da wohl bei allen Karten die gleiche Komponente benutzt. Sehr schön daran zu erkennen das mit den 40.?? der AGP Rückkanal auf allen Karten plötzlich geht.

Das nennt man wohl OOP auf Treiberebene.

[aths]

Originally posted by Demirug
aths, das würde ich nicht unbedingt so sehen. Die benutzen Codepfade hängen von den im Chip vorhandenen Teile ab. Da die AGP Ansteuerung sich im wesentliche nie geändert wird da wohl bei allen Karten die gleiche Komponente benutzt. Sehr schön daran zu erkennen das mit den 40.?? der AGP Rückkanal auf allen Karten plötzlich geht.

Das nennt man wohl OOP auf Treiberebene. Vor allem im Highlevel-Bereich kann wohl eine Menge unified gemacht werden. Für die Geschwindigkeits-Optimierung des Rendering wäre dann aber die jeweilige Architektur genau zu berücksichtigen. Ich glaube z.B. kaum, dass beim TNT der Code für die Register Combiner mitgeladen wird (wenn ja, wäre es Ressourcenverschwendung.) Beim TNT gäbe es massig Overhead, wenn auf ihm ein GF4-Treiber mit vielen "if"-Anweisungen laufen würde. Das kann ich mir schwer vorstellen.

Ich sehe die "unified" Architektur auch als Problemquelle. (Dass man für bestimmte Spiele bestimmte Detos brauchte ist ja noch nicht so lange her.) Klar ist das für nV günstiger, aber ein von Grund auf neu geschriebener NV25-Treiber wäre wohl noch ein wenig effizuenter.

[Demirug]

Wer spricht den von IFs?

Ich sagte ja das der Treiber wohl nur Code für die Teile lädt die es auch im Chip gibt. So ist es aber IMO durchaus möglich das man z.B. für die Register Combiner eine Basis Klasse hat und es davon entsprechend den Änderungen und Erweiterungen ableitungen gibt. Bei Start des Treibers wird dann eben eine Instance die richtige Klasse erzeugt. Mit dem richtigen Desgin läst sich da schon eine ganze menge Arbeit sparen.

[aths]

Originally posted by Demirug
Wer spricht den von IFs?Ich :sulkoff:
Originally posted by Demirug
Ich sagte ja das der Treiber wohl nur Code für die Teile lädt die es auch im Chip gibt. So ist es aber IMO durchaus möglich das man z.B. für die Register Combiner eine Basis Klasse hat und es davon entsprechend den Änderungen und Erweiterungen ableitungen gibt. Bei Start des Treibers wird dann eben eine Instance die richtige Klasse erzeugt. Mit dem richtigen Desgin läst sich da schon eine ganze menge Arbeit sparen. Sollte ich mich so täuschen, dass die Lowlevel-Funktionen bei Grafiktreibern nicht mehr in Assember geschrieben werden?

[Demirug]

Originally posted by aths
Sollte ich mich so täuschen, dass die Lowlevel-Funktionen bei Grafiktreibern nicht mehr in Assember geschrieben werden?

Schon lange nicht mehr. Der NT Kern war von Anfang an dafür ausgelegt das man die Treiber in C schreibt. Das hatte den Vorteil das man einen Treibercode fast unverändert für alle 4 Hardwareplatformen benutzen kann/konnte.

Inzwischen kann man einen Treiber auch in C++ schreiben. C++ passt sowieso besser zum NT-Kern. Cutler hat damals einen schönen OOP Kern gebaut und dann eine C API darüber gesetzt. Aus diesem Grund kann man diese API wiederum ganz leicht durch Objekte einkapseln.

[Pitchfork]

Einige NVidia Entwickler haben mal öffentlich geäußert, daß über 95% des Treibers in C/C++ geschrieben sind...
Ein Gfx Treiber ist viel zu komplex, um ihn den Assemblerfreaks zu überlassen *g*
Das wichtigste beim Gfx Treiber ist die optimierung der Datenströme, nicht die der Instruktionen...

[Demirug]

ja, und bei > DX8 Treibern kommt noch hinzu die Shader (Vertex und Pixel) möglichst gut zu optimieren damit sie so wenige wir nur möglich Takte im Chip brauchen.

[Desti]

Wer mal sich mal genauer die Treiberarchitektur von ATI ansehen will, kann ja einen Blick in die OpenSource DRI Treiber für R100 und R200 werfen oder mal bei den Jungs nachfragen. ;)

[Liszca]

Originally posted by ow




Na SP, NVidia kriegt das doch auch hin.
Auch ein Deto 40.71 laeuft immer noch auf einer TNT. Und das nicht schlechter als auf einer Gf4 auch.

Da ist mir neulich aufgefallen, dass die frueheren detonator treiber teilweise nur 3 mb gross waren, also auch kein unified driver architecture, was mir eigentlich auch nicht wichtig ist, wichtiger ist, dass man immer nen funktionierenden referenztreiber bekommt, egal ob uda oder nicht!