Kyro III [Archiv] - 3DCenter Forum

loewe

2002-03-04, 20:13:22

Ja natürlich!

Wenn eine Szene einen Overdraw von sagen wir mal 2 hat bedeutet das, dass ein IR die Hälfte seiner Füllrate verschleudert da er ja die hälfte Pixel völlig umsonst rendern muss, sie sind später nicht mehr zu sehen. Der TBR tut dies nicht, er setzt seine gesamte Füllrate in sichtbare Füllrate um, was bedeutet das ein IR die doppelte Füllrate haben müsste, um das gleiche Ergebnis erzielen zu können.

Die Rechnung geht natürlich nicht mehr ganz so auf, heutzutage nutzen auch alle IR entsprechende Maßnahmen, um den Overdraw wenigstens ein wenig zu drücken, aus diesem Grunde halte ich auch nichts von solchen Rechnereien mit Faktoren von 4 und ähnlichem. Aber ein Faktor von zwei ist für TBR trotzdem drin, da natürlich alle diese Lösungen die Nvidia uns ATI da erfunden haben niemals die Effektivität eines TBR erreichen werden.

Ein Problem bleibt aber, KYRO II zeigt es immer wieder sehr schön. Der TBR kann sich wenn alles gut funktioniert durchaus mit Chips messen, die wesentlich mehr Füllrate haben. Wenn aber eine Szene da ist, die die füllrate braucht z.b. Nebelgranaten oder viel Glas und ähnliches, dann bricht der TBR auf Grund seiner zu geringen echten Füllrate massiv ein.
Um dieses Problem zu beseitigen gibt man KYRO III eben die echte Füllrate eines IR mit, ob hier 250 MHz oder 300 MHz erreicht werden ist schon fast egal.

:)

Andre

2002-03-04, 20:48:23

Originally posted by Liszca

bis wir ein powervr forum kriegen!

Jetzt gar nicht mehr :P

mirp

2002-03-04, 21:57:01

Originally posted by Major J
Über die tausende von R8500-Threads regt sich doch auch niemand auf.

Es gibt ja auch tausende mit einer R8500, aber niemanden mit einer Kyro III... ;)

Major J

2002-03-04, 22:24:22

Originally posted by mirp

Es gibt ja auch tausende mit einer R8500, aber niemanden mit einer Kyro III... ;)

LOL... wenn man das so sieht, natürlich. ;)

Unregistered

2002-03-05, 00:12:57

also als moderator solltest du keine so dümmlichen comments abgeben @ andre

Quasar

2002-03-05, 00:49:54

Naomi II war aber die Grafikeinheit von Spielhallenautomaten. Auf denen erledigte AFAIK ein separater Prozessor das TnL.

Liszca

2002-03-05, 00:57:17

Originally posted by Quasar
Naomi II war aber die Grafikeinheit von Spielhallenautomaten. Auf denen erledigte AFAIK ein separater Prozessor das TnL.

ok wenn er jetzt im chip integriert gewesen wäre hätte dein argument nicht gezählt, aber als extra chip, naja, dann ist es was anderes!

Liszca

2002-03-05, 00:58:01

Originally posted by Andre

Jetzt gar nicht mehr :P

Sicher ???

Unregistered

2002-03-05, 08:45:51

Hi all;

also das mit dem Overdraw war der einzig gravierende Fehler in Löwes Artikel über den KyroIII. Heutige Spiele haben meistens einen Overdraw von 1,2 - 1,5 mehr nicht !!

Die Spieleengines sind natürlich für IMR optimiert und ein größerer Overdraw würde die Framerate jedes normalen Chips killen ( der Overdraw wird bei z.B. Quake3 bereits in der CPU auf einen Wert von 1.2 reduziert ).
Der größte Vorteil des TBR-Konzepts ist die wesentlich bessere Ausnutzung der vorhandenen Bandbreite, da die framebuffer-Bandbreite wesentlich niedriger ist ( da Multisampling wenn möglich komplett im Tile-Cache ablaufen + nur die kompletten Pixel in den Speicher geschrieben werden + Pixel nicht nachträglich überschrieben werden ( wieder der Overdraw )) und natürlich das kein Z-Buffer notwendig ist.

ZB.:

Quake3 hat einen Overdraw von ca. 1,2 + 3 x Multitexturing (2Texturen pro Polygon + Alpha ) =>

175MHz x 2Pipelines = 350 MPixel / sec

bei einer Auflösung von 1280 x 1024 benötigt Quake also eine Füllrate von 1280x1024x3 = 3,93MPixel/Frame

mit dem KyroII sollten also THEORETISCH 89 Frames/sec möglich sein.
durch die zusätzlichen Speicherzugriffe für den Polygon-sort - Cache + andere Bandbreitenmindernde Vorgänge erreicht der KyroII ca. 75-80% dieser theoretischen fps also ~ 66 fps.

( das ist jetzt ein rein theoretischer Wert aus dem Gedächtnis, die aktuellen fps-Werte habe ich jetzt nicht im Kopf ).

Wenn man diesen Wert mit einem IMR-Renderer vergleichen will, dann muss man sich die 16bit-Resultate anschauen, da viele IMR-Chips nur dort ihre theoretischen MPixel auch wirklich erreichen. Am besten würde sich die GeforceDDR als Vergleich eignen (so aus dem Gedächtnis) da der Chip unter 16bit nicht Bandbreitenbeschränkt ist.

grüsse

Manfred

ActionNews

2002-03-05, 09:15:16

Naja! Ganz so effektiv ist das HSR per Software ja wohl nicht, oder? Ich meine soweit ich das weiß funktioniert das per Software ja so, dass die Engine praktisch nur einen Raum rendern lässt und die dahinterliegenden (durch Türen und Wände) nicht sichtbaren eben nicht! Aber im Raum sehber kann es durch Objekte immer noch zu großem Overdraw kommen (z.B. Feind hinter einer Säule; oder Fahrzeuge, Maschinen usw...)! Und bei großen Außenlevels ebenfalls (Bäume, Felsen, Häuser....)! Soweit ich weiß wird da nicht per Engine Overdraw reduziert! Und gerade bei solchen Situationen werden die Szenen immer Komplexer (siehe Kreed, Unreal2 usw....). Hmm...und außer der Quake(3)-Engine fällt mir momentan auch keine andere Engine ein die, das macht. Obwohl...wie ist das bei der Unreal/UT-Engine? Und wenn man bedenkt, dass mittlerweile etwa normalerwweise ein Overdraw von 3-4 vorherrscht, dann ist die Reduktion des Overdraws auf 2 durch solche Engine-Eingriffe schon realistisch!

CU ActionNews

HOT

2002-03-05, 10:55:54

Originally posted by Unregistered
Hi all;

also das mit dem Overdraw war der einzig gravierende Fehler in Löwes Artikel über den KyroIII. Heutige Spiele haben meistens einen Overdraw von 1,2 - 1,5 mehr nicht !!

Die Spieleengines sind natürlich für IMR optimiert und ein größerer Overdraw würde die Framerate jedes normalen Chips killen ( der Overdraw wird bei z.B. Quake3 bereits in der CPU auf einen Wert von 1.2 reduziert ).
Der größte Vorteil des TBR-Konzepts ist die wesentlich bessere Ausnutzung der vorhandenen Bandbreite, da die framebuffer-Bandbreite wesentlich niedriger ist ( da Multisampling wenn möglich komplett im Tile-Cache ablaufen + nur die kompletten Pixel in den Speicher geschrieben werden + Pixel nicht nachträglich überschrieben werden ( wieder der Overdraw )) und natürlich das kein Z-Buffer notwendig ist.

ZB.:

Quake3 hat einen Overdraw von ca. 1,2 + 3 x Multitexturing (2Texturen pro Polygon + Alpha ) =>

175MHz x 2Pipelines = 350 MPixel / sec

bei einer Auflösung von 1280 x 1024 benötigt Quake also eine Füllrate von 1280x1024x3 = 3,93MPixel/Frame

mit dem KyroII sollten also THEORETISCH 89 Frames/sec möglich sein.
durch die zusätzlichen Speicherzugriffe für den Polygon-sort - Cache + andere Bandbreitenmindernde Vorgänge erreicht der KyroII ca. 75-80% dieser theoretischen fps also ~ 66 fps.

( das ist jetzt ein rein theoretischer Wert aus dem Gedächtnis, die aktuellen fps-Werte habe ich jetzt nicht im Kopf ).

Wenn man diesen Wert mit einem IMR-Renderer vergleichen will, dann muss man sich die 16bit-Resultate anschauen, da viele IMR-Chips nur dort ihre theoretischen MPixel auch wirklich erreichen. Am besten würde sich die GeforceDDR als Vergleich eignen (so aus dem Gedächtnis) da der Chip unter 16bit nicht Bandbreitenbeschränkt ist.

grüsse

Manfred

Totaler Blödsinn. Es ist softwaretechnisch in moderatem Aufwand gar nicht möglich, den Overdraw wirklich zu eliminieren. Q3 hat nie und nimmer einen Overdraw von 1,2; vielmehr ist hier von 2-3 die Rede. Das Problem ist, dass du hier sehr deutlich abwägen musst, wofür die die (begrenzte) Leistung des Prozessors verwenden möchtest; du hast hier natürlich die Möglichkeit effektives HSR durchzuführen. Allerdings würde das jeden Rahmen des Sinnvollen sprengen, da du keinen Athlon 1000 als Minimum vorschreiben kannst. Desweiteren ist es nicht nur abhängig vom Renderung, sondern auch von der höhe des Polygoncounts und entsprechende Softwareoptimierungen, ob es möglich ist, das Rendering überhaupt auszunutzen. Das sieht man bei der neuen Unreal Engine ganz deutlich: Hier wird auf massives Rendering gesetzt und dort lässt auch der Kyro seine Muskeln spielen. Geht es jedoch um Scenen mit erheblichem Geometrieaufwand (z.B. 3DMark2001) dann sieht die Welt auf einmal ganz anders aus, da die Kyro nicht an ihrem Limit laufen kann. Man sollte deseiteren nicht vergessen, dass der Kyro auch beim transparenten Overdraw Vorteile geniesst, da hierfür keine Speicherbandbreite benötigt wird.
Ausserdem hast du die Rechnung ohne den Wirt gemacht. der Geforce benötigt bei 16Bit Rendering WENIGER FILLRATE und nicht nur Bandbreite!!! Der Geforce rechnet dann intern auch nur mit 16 Bit und NICHT mit 32, sow es der Kyro tut. Da kannst allerhöchstens dern Chip runtertakten und den Speicher rauf, um ans 32Bit Limit zu kommen. DIESE Leistung kannst du dann hochrechnen und vergleichen, was anderes nicht!!!

Unregistered

2002-03-05, 11:08:23

Full akn.
Noch eine kleine Anmerkung von mir:
Originally posted by HOT
Man sollte desweiteren nicht vergessen, dass der Kyro auch beim transparenten Overdraw Vorteile geniesst, da hierfür keine Speicherbandbreite benötigt wird.Dieser theoretische Vorteil besteht ohne Zweifel, dafür muß bei transparentem Overdraw der Kyro (und alle anderen Chips natürlich auch) die jeweiligen Pixel mehrfach Rendern (was er ja sonst nicht macht). Dadurch geht ihm wertvolle Füllrate verloren.

GloomY

2002-03-05, 11:09:30

^^ Das war von mir...

Ach ja noch was: Der Kyro rendert alles in einem Pass, dadurch spart er (bei vielen Textures) in manchen Fällen noch einmal Speicherbandbreite gegenüber IR, die mehrere Passes benötigen...

Modulor

2002-03-05, 11:31:48

Jo, das sieht man sehr schön beim Templemark Ergebnis (multitextures used):

Geforce: 2+2+2 :finger:
Radeon: 3+3 :eyes:
Kyro: 6 :D

Selbst wenn der Overdraw durch Vorsortierung durch die CPU ständig gesenkt wird, steigen die Leistungsanforderungen an CPU und Grafikkarte durch immer mehr Polygone stetig an - das egalisiert sich auf einem IR also wieder. Ich denke schon daß ein Wert von 2 nach wie vor realistisch ist.

Die einfachen Berechnungen von *unregistered* lassen sich wohl mit folgendem Artikel auf Rivastation nachvollziehen:http://www.rivastation.com/review/3dprophet_4500/3dprophet_4500_11.htm
Dort werden bei 16 bit tatsächlich die genannten 66 fps erreicht. Demnach entsprächen die 94 fps der GF2 bei deren 800 MPixel z.B. nur einer Effektivität von 46%.

Aber so einfach läßt sich das ja alles nicht darlegen...

Unregistered

2002-03-05, 11:55:18

Schaut so aus, als ob meine obigen Zahlen nicht "so ganz" passen.

In den alten Quake3 Benchmarks ist die GF256-DDR bei einer Auflösung von 1280x1024 "nur" ca. 54fps schnell; bei 480 MPixel Füllrate.
Die Kyro2 erreicht aber ca. 66fps (bei Tomshardware.com) und 350 MPixel Füllrate:

66 / 54 x 480 / 350 = 1,67

Das heißt beim Quake 3 Timedemo ist der Overdraw ca. 1,67 wahrscheinlich aber etwas geringer, da ja die ersten Treiber für die GF256 bekanntlich noch nicht soo ausgereift waren. Andererseits erreichen auch die Kyro2-Treiber nicht 100% der möglichen Leistung, sondern nur ca. 75%. Also kann man von einem Overdraw von ca. 1.6 - 1.7 ausgehen.

Da Quake 3 immer als Referenz hergenommen wird und die Quake3-Engine mittlerweile für viele Spiele genutzt wird, kann man aus meiner Sicht nicht mit einer fiktiven Füllrate von 4000Mpixel für die KyroIII argumentieren, sondern allenfalls mit einer vergleichbaren Füllrate von 2000 Mpixel (bei 1200 MPixel Basis; was immer noch extrem hoch ist, da der Kyro3 diese Füllrate auch in den Spielen erreichen wird und nicht nur in fiktiven Benchmarks).

Selbst IMG hat beim Neon im Web immer mit einer Vergleichsfüllrate von 120Mpixel bei 100Mpixel echter Füllrate argumentiert. Daher, und vom Beyond3D-Forum kommen auch meine Info's zum Overdraw.

@ActionNews :

Bei Außenszenen liegt die Sache natürlich ganz anders, da man hier den Overdraw nicht, oder nur unzureichend reduzieren kann. Deshalb gab es bis vor kurzem auch nur sehr wenige Spiele die Außenszenen hatten.

grüsse

Manfred

HOT

2002-03-05, 13:09:19

Originally posted by Unregistered
Schaut so aus, als ob meine obigen Zahlen nicht "so ganz" passen.

In den alten Quake3 Benchmarks ist die GF256-DDR bei einer Auflösung von 1280x1024 "nur" ca. 54fps schnell; bei 480 MPixel Füllrate.
Die Kyro2 erreicht aber ca. 66fps (bei Tomshardware.com) und 350 MPixel Füllrate:

66 / 54 x 480 / 350 = 1,67

Das heißt beim Quake 3 Timedemo ist der Overdraw ca. 1,67 wahrscheinlich aber etwas geringer, da ja die ersten Treiber für die GF256 bekanntlich noch nicht soo ausgereift waren. Andererseits erreichen auch die Kyro2-Treiber nicht 100% der möglichen Leistung, sondern nur ca. 75%. Also kann man von einem Overdraw von ca. 1.6 - 1.7 ausgehen.

Da Quake 3 immer als Referenz hergenommen wird und die Quake3-Engine mittlerweile für viele Spiele genutzt wird, kann man aus meiner Sicht nicht mit einer fiktiven Füllrate von 4000Mpixel für die KyroIII argumentieren, sondern allenfalls mit einer vergleichbaren Füllrate von 2000 Mpixel (bei 1200 MPixel Basis; was immer noch extrem hoch ist, da der Kyro3 diese Füllrate auch in den Spielen erreichen wird und nicht nur in fiktiven Benchmarks).

Selbst IMG hat beim Neon im Web immer mit einer Vergleichsfüllrate von 120Mpixel bei 100Mpixel echter Füllrate argumentiert. Daher, und vom Beyond3D-Forum kommen auch meine Info's zum Overdraw.

@ActionNews :

Bei Außenszenen liegt die Sache natürlich ganz anders, da man hier den Overdraw nicht, oder nur unzureichend reduzieren kann. Deshalb gab es bis vor kurzem auch nur sehr wenige Spiele die Außenszenen hatten.

grüsse

Manfred

Auch diese Zahlen passen einfach nicht. Du kannst einfach die Ergebnisse so verrechnen, es spielen zu viele andere Faktoren mit. Bei der Geforce DDR ist es so, dass jede Textur einzeln in den Speicher abgelegt werden muss. Ausserdem besitzt die Geforce T&L. Ergo stellt sich eine weitere Frage: was für eine CPU wird verwendet? Sind die Optimierungen des Treibers auf die CPU mit der vom anderen Hersteller vergleichbar? Das Problem hierbei ist, dass niemand wirklich weiss, wieviel Overdraw eine Engine wirklich erzeugt. Nur das Problem liegt eben nicht beim Overdraw an sich sondern am Umfeld. So einfach wie du es dir machst, kannst du die Overdraw-Abhängigkeiten einfach nicht darstellen.
Es kommen noch weitere Faktoren hinzu: Wie gut arbeitet der Treiber der Karten? Wieviele Texturlagen benutzt das Spiel? Wird Bumpmapping verwendet? Was für eine Art zu Filtern wird benutzt? Wie effizient arbeiten die Filter?
Diese Liste lässt sich beliebig verlängern.
Fakt ist jedenfalls, dass der Kyro für seine Fillrate (vergl. TNT2U) einer verdammt hohe Leistung hinlegt - und das ist nicht allein auf die Optimierung der Pipeline, also Multitexturing und weitere Bandbreitenersparnisse, zurückzuführen.
Das HSR der Kyro bringt schon eine ganze Menge und es ist mit Sicherheit noch nicht voll optimiert. Mal sehen, was der KyroIII auch diesbezüglich für Verbesserungen bringt.

Unregistered

2002-03-05, 13:28:11

das ist ja der Brüller :

"
Ausserdem hast du die Rechnung ohne den Wirt gemacht. der Geforce benötigt bei 16Bit Rendering WENIGER FILLRATE und nicht nur Bandbreite!!! Der Geforce rechnet dann intern auch nur mit 16 Bit und NICHT mit 32, sow es der Kyro tut. Da kannst allerhöchstens dern Chip runtertakten und den Speicher rauf, um ans 32Bit Limit zu kommen. DIESE Leistung kannst du dann hochrechnen und vergleichen, was anderes nicht!!!
"

Hi HOT;

solange du nicht weißt von was du redest solltest du dich erst einmal informieren bevor du was sagst !

Weniger oder mehr Fillrate bei 16bit oder 32bit ich kringle mich vor lachen :) :) :)

HOT

2002-03-05, 13:37:17

Mir scheint, du hast garnichts verstanden. Die Verarbeitungsbreite IM Chip beträgt bei 16Bit Farbtiefe auch nur 16Bit! Du hast weniger Blending, weniger Z-Buffer usw.
16Bit auf der Geforce ist mit 16Bit auf der Kyro (also 32Bit) nicht vergleichbar. Du kannst kein Mofa mit nem Motorrad vegleichen!

2002-03-05, 13:43:33

@HOT

Kein Chip rechnet intern nur mit 16Bit bei 16Bit Framebuffer.

Und selbst wenn dem doch so waere, was hat das mit der Fuellrate des Chips zu tun? Die ist doch nicht von der Farbtiefe abhaengig.

Unregistered

2002-03-05, 14:54:09

Hi HOT;

tschuldige wegen meiner harschen Antwort :(, ich hätte mir wohl mehr Zeit nehmen müssen;

ABER;

die Füllrate ist völlig unabhängig von der Textur. Egal ob 8bit Texturen, 16bit Texturen oder 32bit Texturen gerendert werden, bleibt die Füllrate immer gleich.

Die Kyro2 z.B. hat 2 Pipelines mit je 8TU's das heißt die Kyro2 (ich hoffe weiblich geht?) kann pro Takt 2 bilinear oder trilinear gefilterte Pixel ausgeben. Diese Pixelfüllrate ist unabhängig von der bit-tiefe der verwendeten Textur, da der Pfad für die Texturen immer 32bit breit ist und auch die Verarbeitungslogik immer 32bit "breit" ist(ist ja schließlich in Hardware gegossen). Es wird nur eine unterschiedlich große Textur (4bit,8bit,16bit,24bit,32bit) über diesen 32bit-Pfad geschickt.
Dies ist auch bei einer Geforce-Karte so! Bei einer Geforce-Karte wird intern ebenfalls (wie bei der Kyro) immer in 32bit (oder sogar 36bit?) Farbtiefe gerendert !

Bei einer Geforce-Karte wird das Ergebnis aber bei einer 16bit-Einstellung in 16bit gedithered in den Framebuffer geschrieben. Wenn nun für Multitexturing diese Daten wieder benötigt werden und mit einer neuen Textur (8bit, 16bit oder 32bit) geblendet werden, dann kommt es zu den bekannten Darstellungsfehlern da die 16bit Genauigkeit des Framebuffers einfach nicht mehr ausreicht.

Modulor

2002-03-05, 15:56:47

Originally posted by Unregistered

Die Kyro2 z.B. hat 2 Pipelines mit je 8TU's

KYRO hat nur ein Textureinheit pro pipeline, somit kommt er auch auf nur 350 Gigatexel Füllrate - die aber aus bekannten Gründen wirklich effektiv genutzt werden. Die 8 Texturen pro renderpass ergeben sich ebenfalls daraus - Kyro braucht also keine 8TUs (hehe das wär ja was: Kyro mit 2,8 GigaTexel :o ).

2002-03-05, 16:04:45

Originally posted by Modulor

KYRO hat nur ein Textureinheit pro pipeline, somit kommt er auch auf nur 350 Gigatexel Füllrate

Megatexel nicht Gigatexel;)

Unregistered

2002-03-05, 16:12:01

Seufz,

dann eben hier die bessere Erklärung :

der Kyro hat 2 Pixelpipelines mit je 8 Texel-processing - Units.

=> 350 Mega-Pixel ( bilinear filtered ( 4texel/pixel ) oder trilinear filtered ( 8texel/pixel ) )

Um ein bilinear gefilteres Pixel zu rendern benötigt man 4 Texel (aus einer Textur) die in 4 Texel-units miteinander verblendet werden.

mit TU's hatte ich eben Texel-processing units gemeint keine Texture-processing units (ich dachte das wird aus dem Zusammenhang klar ).
Diese Texel-processing-Units haben aber nichts mit Multitexturing zu tun ( es sind also keine 3DFx-marketing-Texel sondern die echten Texel ).

Ich hoffe das macht es deutlicher (sehr wahrscheinlich verwendet außer mir niemand den Begriff Texel-Unit's für das normale bilineare Filtern ;) )

Manfred

Unregistered

2002-03-05, 16:18:14

Hi ow;

auch keine Megatexel sondern Megapixel :) :).

Wenn du von den echten Texeln sprichst dann hat der Kyro2 wirklich eine Verarbeitungsgeschwindigkeit von 2800Megatexeln ( aber eben nur 350 Megapixel Output ).

Wenn du aber die 3DFx-Marketing Texel meinst dann sind es eben 350 Megatexel-3DFx-style (das sind aber eben nicht die echten).

Manfred

ActionNews

2002-03-05, 16:47:20

Originally posted by Unregistered
Hi HOT;

tschuldige wegen meiner harschen Antwort :(, ich hätte mir wohl mehr Zeit nehmen müssen;

ABER;

die Füllrate ist völlig unabhängig von der Textur. Egal ob 8bit Texturen, 16bit Texturen oder 32bit Texturen gerendert werden, bleibt die Füllrate immer gleich.

Die Kyro2 z.B. hat 2 Pipelines mit je 8TU's das heißt die Kyro2 (ich hoffe weiblich geht?) kann pro Takt 2 bilinear oder trilinear gefilterte Pixel ausgeben. Diese Pixelfüllrate ist unabhängig von der bit-tiefe der verwendeten Textur, da der Pfad für die Texturen immer 32bit breit ist und auch die Verarbeitungslogik immer 32bit "breit" ist(ist ja schließlich in Hardware gegossen). Es wird nur eine unterschiedlich große Textur (4bit,8bit,16bit,24bit,32bit) über diesen 32bit-Pfad geschickt.
Dies ist auch bei einer Geforce-Karte so! Bei einer Geforce-Karte wird intern ebenfalls (wie bei der Kyro) immer in 32bit (oder sogar 36bit?) Farbtiefe gerendert !

Bei einer Geforce-Karte wird das Ergebnis aber bei einer 16bit-Einstellung in 16bit gedithered in den Framebuffer geschrieben. Wenn nun für Multitexturing diese Daten wieder benötigt werden und mit einer neuen Textur (8bit, 16bit oder 32bit) geblendet werden, dann kommt es zu den bekannten Darstellungsfehlern da die 16bit Genauigkeit des Framebuffers einfach nicht mehr ausreicht.

Meinst du damit eine Geforce würde intern mit 32bit (bzw. 36bit) rendern? ??? Das wäre mir aber neu!
Der Vorteil des KyroII ist doch, dass er intern mit 32bit auch bei 16bit rendert und erst beim Schreiben in den Speicher auf 16bit heruntergerechnet wird, wodurch die Qualität viel besser ist! Die Geforce hingegen rechnet intern mit 16 bei 16 bit und 32 bei 32bit! Oder hab ich was verpasst??

CU ActionNews

Xmas

2002-03-05, 17:26:55

Originally posted by ActionNews
Meinst du damit eine Geforce würde intern mit 32bit (bzw. 36bit) rendern? ??? Das wäre mir aber neu!
Der Vorteil des KyroII ist doch, dass er intern mit 32bit auch bei 16bit rendert und erst beim Schreiben in den Speicher auf 16bit heruntergerechnet wird, wodurch die Qualität viel besser ist! Die Geforce hingegen rechnet intern mit 16 bei 16 bit und 32 bei 32bit! Oder hab ich was verpasst??

CU ActionNews
GeForce-Karten rechnen immer mit 9 Bit pro Kanal, also 36 Bit gesamt (oder warens bei GF3/4 schon 40 Bit? *senilwerd*). Erst wenn das Ergebnis in den Framebuffer geschrieben wird, wird auch gedithert.
Der Vorteil bei Kyro ergibt sich daraus, dass der Tilebuffer in 32 Bit ist, deswegen muss nie ein 16-Bit-Wert aus dem Framebuffer gelesen werden. Zudem ist das Dithering besser.

Xmas

2002-03-05, 17:30:50

Originally posted by Unregistered
Ich hoffe das macht es deutlicher (sehr wahrscheinlich verwendet außer mir niemand den Begriff Texel-Unit's für das normale bilineare Filtern ;) )

Höchstwahrscheinlich nicht. Macht auch keinen Sinn, da die Texel nicht einzeln, sondern zusammen verarbeitet werden. Man redet ja auch nicht von Bit-Units.

Liszca

2002-03-05, 23:54:08

Originally posted by loewe
...die die füllrate braucht z.b. Nebelgranaten oder viel Glas und ähnliches, dann bricht der TBR auf Grund seiner zu geringen echten Füllrate massiv ein.

von dem problem mit dem nebel kann ich in cs mit 2x aa ein lied singen! trotzdem ist sie (sehr) gut!

Liszca

2002-03-05, 23:55:44

lies mal die white paper auf powervr.com durch da steht nichts, das sie irgend welche dings bums units hat1!

Tigershark

2002-03-06, 02:07:28

Originally posted by Liszca
lies mal die white paper auf powervr.com durch da steht nichts, das sie irgend welche dings bums units hat1!

:rofl:

@unreg :
Die "Dingsbums units" sind auch AFAIK keine Texture-Processing-Units, sondern Texture-Mapping-Units, also TMUs ;)

HOT

2002-03-06, 11:22:10

Hab nochmal nachgeschaut: Geforce Karten rechnen intern mit 36 Bit, das stimmt. nur: Bei 16 Bit Farbtiefe kann eine Geforce nur in 16 Bit Blendingoperationen durchführen, was eine erhebliche Verschlechterung darstellt. Desweiteren werden in 16Bit auch nur 16Bit Texturen verwendet, was die Datenmenge deutlich reduziert.
Der Kyro führt das Blending komplett im Tilebuffer durch, und zwar immer in 32Bit. Erst danach wird das Bild in 16Bit runtergerechnet, was etwas mehr Speicherbandbreite beim Framebuffer freigibt. Daher bekommt der Kyro auch keinerlei Vorteile bei 16Bit Farbtiefe, die Ergebnisse sind also absolut nicht vergleichbar.

2002-03-06, 12:10:22

Originally posted by HOT
Desweiteren werden in 16Bit auch nur 16Bit Texturen verwendet, was die Datenmenge deutlich reduziert.

Haettest besser mal richtig nachgeschaut. Was spricht denn gegen 32Bit Texturen bei 16Bit Framebuffer?

HOT

2002-03-06, 12:45:22

Da spricht nix gegen, das hab ich auch net gesagt. Nur machen es die meisten Programme so. Einstellen kannst du das eh nur in der 3DMark, von daher stimmt meine Aussage.

2002-03-06, 12:54:32

Originally posted by HOT
Da spricht nix gegen, das hab ich auch net gesagt. Nur machen es die meisten Programme so. Einstellen kannst du das eh nur in der 3DMark, von daher stimmt meine Aussage.

Eben nicht.
Ich kann kein Aussage verallgemeinern, wenn es Abweichungen davon gibt.
Ich glaube in MP kann man FB- und Texturfarbtiefe auch getrennt einstellen, oder irre ich da?

Unter OGL koennen praktisch alle Applikationen FB- und Texturfarbtiefe getrennt einstellen, oder hab ich nur ueberlesen, dass du von D3D redest?

Also stimmt deine Aussage nicht.

Und was tut deiner Meinung nach der Kyro denn bei 16Bit?
Du vergleichst ja GF und Kyro2.
Also wenn eine Applikation unter 16Bit FB nur 16Bit Texturen benutzt, dann gilt das ebenso fuer den Kyro. Egal wie der intern rechnet.

HOT

2002-03-06, 13:14:00

Auch da habe ich nichts gegen gesagt. Es bringt der Kyro nur auch keinen Vorteil, da die Speicherbandbreite gross genug ist.
Du hast übrigens Recht, dass man in allen Q3E Spielen die Texturfarbtiefe einstellen kann - mein Fehler. Nur wenn du dir Benchmarkergebnisse anschaust, die 16Bit benchen, werden immer 16Bit Texturen bei 16Bit Farbtiefe verwendet.

Unregistered

2002-03-06, 13:45:21

Hi HOT;

sorry; aber du konstruierst dir hier etwas zusammen, was einfach nicht stimmt.

Kyro :

16bit Textur -> 32bit internes Rendering -> 16bit Framebuffer

Geforce :

16bit Textur -> 36bit internes Rendering -> 16bit Framebuffer

Solange die Geforce keine Daten aus dem 16bit Framebuffer für Multitexturing auslesen muss, ist die Qualität beider Chips gleich, bzw. die Geforce ist sogar etwas besser.

Beim Bilinearen Filtern zum Beispiel werden 4Texel eingelesen um ein Pixel auszugeben. Die Texel werden intern mit 32bit oder 36bit Genauigkeit zusammen verrechnet und das Ergebnis bei beiden in 16bit Qualität ausgegeben. Wie kommst du darauf, das der Geforce beim 16bit Rendering einfach 50% der internen Chip-Resourcen abschaltet? Die werden natürlich weiterhin genutzt. Auch wenn man nur 4 16bit Texel miteinander verrechnet kann es sehr leicht vorkommen, das das Ergebnis oder auch Zwischenergebnisse eine höhere Genauigkeit erfordern, und da der Chip diese frei zur Verfügung stellt ( schließlich ist das ganze in Hardware verdrahtet ) werden sie natürlich genutzt.

Manfred

MadManniMan

2002-03-06, 14:00:01

manfred manfred...

schonmal ne one-layer demo gesehen, auf der der vorteil zum tragen kommt? ne? na sowas!!!

...dass übergedither erst bei mehreren schichten probs macht, sollte einleuchten. aber daß internes über 32 gerendere EINE 32bit textur besser aussehen lassen kann :D

mehr als 32bit sind nur für overbrightness sinnvoll, da allerdings sehr(siehe RAMs bericht in der pcgh)

HOT

2002-03-06, 14:28:22

Originally posted by Unregistered
Hi HOT;

sorry; aber du konstruierst dir hier etwas zusammen, was einfach nicht stimmt.

Kyro :

16bit Textur -> 32bit internes Rendering -> 16bit Framebuffer

Geforce :

16bit Textur -> 36bit internes Rendering -> 16bit Framebuffer

Solange die Geforce keine Daten aus dem 16bit Framebuffer für Multitexturing auslesen muss, ist die Qualität beider Chips gleich, bzw. die Geforce ist sogar etwas besser.

Beim Bilinearen Filtern zum Beispiel werden 4Texel eingelesen um ein Pixel auszugeben. Die Texel werden intern mit 32bit oder 36bit Genauigkeit zusammen verrechnet und das Ergebnis bei beiden in 16bit Qualität ausgegeben. Wie kommst du darauf, das der Geforce beim 16bit Rendering einfach 50% der internen Chip-Resourcen abschaltet? Die werden natürlich weiterhin genutzt. Auch wenn man nur 4 16bit Texel miteinander verrechnet kann es sehr leicht vorkommen, das das Ergebnis oder auch Zwischenergebnisse eine höhere Genauigkeit erfordern, und da der Chip diese frei zur Verfügung stellt ( schließlich ist das ganze in Hardware verdrahtet ) werden sie natürlich genutzt.

Manfred

Waaaa, ich hab nichts gegenteiliges behauptet, aber du hast leider 2 Klinigkeiten vergessen!!!

Klassisch
16/32Bit Texturen + Geometriedaten -> 32-36Bit genaue Chipinterne Bearbeitung -> Blending komplett in 16Bit + Dithering oder 32Bit -> Z-Buffer mit 16/24Bit Genauigkeit (+HSR) -> 16/32Bit Framebuffer, Double oder Tripple Buffering

Radeon8500
16/32Bit Texturen + Geometriedaten -> 48Bit genaue interne Bearbeitung -> 16/24/32Bit Z-Check + HSR -> Blending in 16/32Bit -> Framebuffer

Kyro
16/32Bit Texturen + Geometriedaten -> 32Bit Z-Check+HSR -> 32 Bit interne Bearbeitung -> Blending im Tilebuffer immer 32Bit, kein Dithering -> 16Bit Framebuffer, Single oder Dubblebuffering, Trippllbuffering ist Schwachsinn auf Kyro.

VSA100
16/32Bit Texturen + Geometriedaten -> 40Bit genaue Berechnungen (bin mir net ganz sicher) -> Blending in 16/32Bit mit Dithering+Post-Filter -> Z-Check mit 16/32Bit -> Framebuffer 16/32Bit Dubble oder Tripple.

Alle Geometriedaten sind schon transformiert in dieser Aufstellung.

Unregistered

2002-03-06, 15:54:17

Originally posted by MadManniMan
manfred manfred...

schonmal ne one-layer demo gesehen, auf der der vorteil zum tragen kommt? ne? na sowas!!!

...dass übergedither erst bei mehreren schichten probs macht, sollte einleuchten. aber daß internes über 32 gerendere EINE 32bit textur besser aussehen lassen kann :D

mehr als 32bit sind nur für overbrightness sinnvoll, da allerdings sehr(siehe RAMs bericht in der pcgh)

Hi;

nein, natürlich nicht. OneLayer - Demo's wären wirklich häßlich ( außer bei der PS1, die kann IMHO nichts anderes )

64bit ist auch für Multitexturing sinnvoll. Siehe auch den guten Artikel hier auf 3d-Center dazu. Deshalb wäre es auch Schwachsinn, die 32bit/36bit nicht bei 16bit Texturen zu nutzen (nur hilft das einer Geforce1 nicht so viel da der 16bit Framebuffer dazwischen funkt).

+

Auch eine Textur ist bilinear gefiltert. DH. jeder Pixel besteht aus 4Texeln als Source die intern miteinander verrechnet werden. Ergo hilft internes 32bit Rendering auch bei Single-Texturing etwas (aber nicht viel).

Manfred

Unregistered

2002-03-06, 16:30:50

Originally posted by HOT

Waaaa, ich hab nichts gegenteiliges behauptet, aber du hast leider 2 Klinigkeiten vergessen!!!

Klassisch
16/32Bit Texturen + Geometriedaten -> 32-36Bit genaue Chipinterne Bearbeitung -> Blending komplett in 16Bit + Dithering oder 32Bit -> Z-Buffer mit 16/24Bit Genauigkeit (+HSR) -> 16/32Bit Framebuffer, Double oder Tripple Buffering

Radeon8500
16/32Bit Texturen + Geometriedaten -> 48Bit genaue interne Bearbeitung -> 16/24/32Bit Z-Check + HSR -> Blending in 16/32Bit -> Framebuffer

Kyro
16/32Bit Texturen + Geometriedaten -> 32Bit Z-Check+HSR -> 32 Bit interne Bearbeitung -> Blending im Tilebuffer immer 32Bit, kein Dithering -> 16Bit Framebuffer, Single oder Dubblebuffering, Trippllbuffering ist Schwachsinn auf Kyro.

VSA100
16/32Bit Texturen + Geometriedaten -> 40Bit genaue Berechnungen (bin mir net ganz sicher) -> Blending in 16/32Bit mit Dithering+Post-Filter -> Z-Check mit 16/32Bit -> Framebuffer 16/32Bit Dubble oder Tripple.

Alle Geometriedaten sind schon transformiert in dieser Aufstellung.

hi HOT;

Was soll denn das jetzt???

Anscheinend hast du völlig vergessen worum wir uns hier streiten.

Ursprünglich ging es einmal um den Overdraw von ca. 1,6 bei Quake3 und dann um darum, das die GeforceDDR angeblich intern nur mit 16bit rendert(bei 16bit Texturen), was ja widerlegt wurde.

Also fangen wir noch einmal von vorne an (1.Klasse oder so) :

die Kyro2 ( 350MPixel Füllrate ) erreicht bei Quake3 @ 1280x1024 @ 16bit ca. 66fps

die GeforceDDR ( 480 MPixel Füllrate ) erreicht bei Quake3 @ 1280x1024 @ 16bit ca. 54fps

Beide Chips sind bei diesen Einstellungen nicht (oder nur sehr geringfügig) Bandbreitenbegrenzt.

Quake3 benutzt Multitexturing (2Texturen) auf den meisten oder gar allen Polygonen und darüber noch einen Layer Alpha (Stimmt natürlich nicht 100%ig aber so in etwa)

Dh. der Füllratenbedarf pro Frame liegt bei 3,93 MPixel

Die Kyro2 müßte also theoretisch 89fps erreichen, schafft aber nur 66fps ( Gründe : Treiber, Effizienz etc... )

Die GeforceDDR müßte theoretisch 122fps erreichen, schafft aber nur 54fps ( Gründe : Treiber, Effizienz, OVERDRAW etc... )

Da bei beiden Chips die Treiber bei den ersten Benchmarks noch nicht so ausgereift waren, nehme ich einmal an, das beide Chips (auch die GeforceDDR) nur ca. 75% der max. möglichen Füllrate/Framerate erreichen. Bei dem Kyro2 kann man das ja an der Framerate sehen, bei der GeforceDDR leider nicht, da hier der Overdraw noch dazu kommt.

Gibt also eine vereinfachte Rechnung :

Overdraw = 480 / 350 x 66 / 54 = 1,67

Das die Qualität des gerenderten Frames bei der GeforceDDR in 16bit schlechter ist, ist klar (wegen der 16bit Framebuffers der das Multitexturing verhagelt) siehe dazu meine alten Postings.

ABER trotzdem gilt :

Kyro :
16bit Textur -> 32bit internes Rendering -> 16bit Framebuffer

Geforce :
16bit Textur -> 36bit internes Rendering -> 16bit Framebuffer

Somit sind die Ergebnisse miteinander vergleichbar (schließlich geht es um den Overdraw und nicht um einen Schönheitswettbewerb ).

Manfred

Liszca

2002-03-06, 19:23:08

Originally posted by Unregistered

Solange die Geforce keine Daten aus dem 16bit Framebuffer für Multitexturing auslesen muss, ist die Qualität beider Chips gleich, bzw. die Geforce ist sogar etwas besser.

nur wann muss sie das nicht *eg*

HOT

2002-03-07, 10:18:12

Deine Overdrawberechnung ist totaler Blödsinn, da zuviele Faktoren eine Rolle spielen. Ich sag dazu nurnoch eine Sache, denn den kompletten Rest, den du da verzapft hast, ist eine Milchmädchenrechnung. Q3 ist hier ein sehr schlechtes Beispiel, da je nach Demo die Geometrielast oder Renderlast überwiegt. Welches Demo hast du gebencht? Quaver? Demo001? Jeder Level hat seine Eigenheiten und wird nicht von jeder Perspktive durchlaufen. Desweiteren rechnest du mit Singletexturing. Es GIBT KEINE Anwendung im Mom, die Singletexturing nutzt! Nahezu jedes Game nutzt schon Lightmaps.
Nur wenn du das Game auf 16Bit stellst und alle Renderingdestails runter, dann hast du noch das Problem, dass deine Prozessorkapazität begrenzt ist. Wenn du schon so wenig Rendering wie Möglich möchtest, um den Overdraw rauszufinden, arbeitet die CPU also zwangsläufig am Limit ihrer Leistungsfähigkeit -> ergo ist dein Ergebnis total fürn Arsch.
Den einzigen Overdrawtester, den man hier verwenden könnte, ist die Villagemark, da hier so gut wie keine Geometrieleistung gebraucht wird.

Also merke: Wenig Rendering -> System arbeitet an CPU/Speicherlimit -> keine Overdrawmessung möglich, da die Framerate duch Prozessor und Speicher begrenzt ist.

2002-03-07, 11:16:57

Originally posted by HOT

Also merke: Wenig Rendering -> System arbeitet an CPU/Speicherlimit -> keine Overdrawmessung möglich, da die Framerate duch Prozessor und Speicher begrenzt ist.

Jetzt erklaer mir mal, wie du darauf kommst, dass bei den von Manfred gewaehlten Setting von 1280x1024x16 eine CPU/RAM-Limitierung vorliegen soll.

Quake Demos in den die Geometrielast ueberwiegt gibt es nicht. Quake ist immer fuellratenlimitiert. Es ist NIEMALS moeglich einen Grafikchip in texturierten Szenen an die Grenzen seiner Geometriebelastbarkeit zu bringen.

HOT

2002-03-07, 12:00:15

Woher weisst du das?

2002-03-07, 12:10:43

Originally posted by HOT
Woher weisst du das?

Logik;)

Dr.Doom

2002-03-07, 13:22:12

Originally posted by ow
Logik;)

Wenn du spitze Ohren hast, glaube ich dir das :) .

Logik steht nicht am Ende aller Überlegungen, sondern nur am Anfang.

Haarmann

2002-03-07, 13:31:50

OW

*ähm* Der Level NV15 sagt Dir der zufälligerweise was?
Quake3 hat ja SW L und kein HW L, also muss die CPU da übel rumackern.

Manfred

Ich kann ja mal schnell nachmessen wie schnell ne Kyro2 sein kann im Q3 bei diesen Settings...

Fast HQ++ 16 Bit = 80.8 fps mit ner Kyro2

Das System war ein P4A auf 133 fsb mit 256mb Noname DDR mit 166MHz

Unregistered

2002-03-07, 13:34:52

Hi ow;

HOT scheint sich komplett verrannt zu haben. Er will nicht einsehen, was die ganze Welt weiß, denn dann müßte er ja zugeben, das er unrecht hat. Typischer Fall von Verstocktheit. Oder aber, er kann noch nicht einmal Benchmarks "lesen" (Glaub ich aber nicht).

Sei's drum er kann schließlich glauben was er will. Die Realität ist stärker. Er soll sich dann bloß nicht wundern, wenn er nicht die fps erreicht die er sich in seiner Phantasie ausmalt, bzw ein normaler IMR-Chip genauso schnell ist wie ein TBR-Chip.

Hi HOT;

Single-Texturing : Du scheinst dir noch nicht einmal meine Postings durchzulesen, denn dann wüßtest du, das ich bei Quake 3 fach Texturing angesetzt habe (2Texturen + 1xAlpha).

Natürlich habe ich Demo001 genommen, da das in allen Reviews zu finden ist; Quaver etc.. hätte ich speziell erwähnt, da (fast) alle Welt nur Demo001 bencht.

CPU : Entweder kannst du mit Benchmarks nichts anfangen, oder... Schau dir doch einfach einmal einen Benchmark an. Bei hohen Auflösungen ist die fps immer niedriger als bei niedrigen Auflösungen, obwohl die Geometrielast gleich hoch bleibt. Ergo (so stehts auch immer in den Reviews dabei) ist das Spiel bei hohen Auflösungen Füllrate-limitiert ( weiß eigentlich jeder ). Deshalb habe ich auch eine Auflösung von 1280x1024 für den Vergleich gewählt.

Villagemark : Hihi, selten so gelacht ! Ein Marketing-Tool von IMG als das einzig Wahre zu bezeichnen => Hihi; echt cooler gag.

Villagemark ist speziell darauf ausgelegt, die Vorteile eines TBR herauszustellen. Mit richtigen IMR-optimierten Spieleengines hat dieser "Benchmark" nicht viel zu tun.

Manfred

Unregistered

2002-03-07, 13:48:36

Originally posted by Haarmann
OW

*ähm* Der Level NV15 sagt Dir der zufälligerweise was?
Quake3 hat ja SW L und kein HW L, also muss die CPU da übel rumackern.

Ja, den NV15 Level habe ich.
Aber was hat deine Aussage mit der meinigen zu tun?

Seine hoechste Geometrieleistung (T&L resp. Triangle-Setup) erreicht JEDER Grafikchip in untexturierter Darstellung, wenn er rein Vertices transformiert und auch nur Vertices bzw. Wireframes auf dem Monitor ausgibt.

Sobald ein 3D Model auch nur flat oder gouraud shattiert ist, verringert sich die Geometrieleistung.
Wenn Texturen genutzt werden ist's dann ganz vorbei. Es bremst dann IMMER der Rasterizer, aber keine T&L Unit, egal ob in HW oder SW.

Laesst sich alles mit Benches wie Viewperf 6.1.1/6.1.2 zeigen.

2002-03-07, 13:50:34

argh... cookie gesetzt!

2002-03-07, 13:54:39

Originally posted by Unregistered
Bei hohen Auflösungen ist die fps immer niedriger als bei niedrigen Auflösungen, obwohl die Geometrielast gleich hoch bleibt. Ergo (so stehts auch immer in den Reviews dabei) ist das Spiel bei hohen Auflösungen Füllrate-limitiert ( weiß eigentlich jeder ).
Manfred

Das ist der springende Punkt.

Ist mir ebenfalls raetselhaft, was denn einige Leute als Ursache fuer die zurueckgehenden fps in hoeheren Aufloesungen ansehen;)

Umgekehrt scheinen aber viele zu wissen, dass CPU/Systemlimitierung vorliegt, wenn die fps beim Umschalten auf hoehere Aufloesungen NICHT fallen (zB. konstante 3Dmark Points (etwa 1050) von 640x480x16 bis 1024x768x32 auf GF2MX und K6-2 450).

SChon komisch...:D

2002-03-07, 13:57:50

Originally posted by Unregistered

Villagemark : Hihi, selten so gelacht ! Ein Marketing-Tool von IMG als das einzig Wahre zu bezeichnen => Hihi; echt cooler gag.

Villagemark ist speziell darauf ausgelegt, die Vorteile eines TBR herauszustellen. Mit richtigen IMR-optimierten Spieleengines hat dieser "Benchmark" nicht viel zu tun.

Manfred

Volle Zustimmung.
Ich koennte mir sogar vorstellen, dass der Villgemark ein back-to-front-sorting der Triangles vornimmt, um die IMRs noch schlechter dastehen zu lassen.

MadManniMan

2002-03-07, 14:44:15

ow, das mit dem back-to-front kann ich mir persönlich nicht vorstellen, dazu sind die leistungen von radeon und gf3/4 zu gut! (außerdem könnte ich mir nicht vorstellen, daß man die abfolge festlegen kann. @3d-progger: geht das? DANN könnte mans nämlich genausogut andersrum machen, wovon z-occlusiondetection und co. DERART profitiern würden, daß man effizienzen eines deferred renderers erreichen könnte. imho nicht praktisch erreicht.)hyperz und lma MÜSSEN da einfach greifen, ersteres hat man schon gut bei der radeon eins gesehen

imho ist meine k2 in 1280 gar nicht mal so unbedingt füllraten, sondern eher schon bandbreitenlimitiert, in jedem fall ist sie das ab 1600. das sollte auch bedacht werden

2002-03-07, 15:20:47

Originally posted by MadManniMan
ow, das mit dem back-to-front kann ich mir persönlich nicht vorstellen, dazu sind die leistungen von radeon und gf3/4 zu gut!

Sowohl GF3/4 wie Radeon besitzen ja "partielle HSR Features" (ich nenn das jetzt einfach mal so).

(außerdem könnte ich mir nicht vorstellen, daß man die abfolge festlegen kann. @3d-progger: geht das?

Bin zwar kein Progger, aber machbar ist sowas. Ganz sicher. (Ist aber ein Frage des Aufwandes)

DANN könnte mans nämlich genausogut andersrum machen, wovon z-occlusiondetection und co. DERART profitiern würden, daß man effizienzen eines deferred renderers erreichen könnte. imho nicht praktisch erreicht.)hyperz und lma MÜSSEN da einfach greifen, ersteres hat man schon gut bei der radeon eins gesehen

Nein. Die HSR-Features der GF3/4 und Radeon erreichen niemals die Effizienz eines deferred renderers. Auch nicht bei front-to-back Sortierung.
Es gibt uebrigens ein OGL Tool (synthetischer Bench), dass die Unterschied verdeutlicht. Nennt sich "GL_ext_reme" und rendert wahlweise f-to-b, b-to-f oder unsortiert.

imho ist meine k2 in 1280 gar nicht mal so unbedingt füllraten, sondern eher schon bandbreitenlimitiert, in jedem fall ist sie das ab 1600. das sollte auch bedacht werden

Da liegst du imho falsch.
Die Kyro ist in praktisch keiner Aufloesung bandbreitenlimitiert. Immer nur zuwenig fuellrate.

aths

2002-03-07, 15:59:14

ow, du hast einige wichtige Punkte betreffs der Geometrie-Last angesprochen. Darf ich fragen, warum du dich seinerzeit so scharf gegen die T&L-Kolumne wandtest, obwohl diese in ähnliche Richtung argumentiert?

Liszca

2002-03-07, 16:34:07

also viel weniger hat mein duron @900 MHz nicht *eg*

Unregistered

2002-03-07, 16:44:57

Originally posted by MadManniMan

imho ist meine k2 in 1280 gar nicht mal so unbedingt füllraten, sondern eher schon bandbreitenlimitiert, in jedem fall ist sie das ab 1600. das sollte auch bedacht werden

Nein; nicht bei 16bit :

350MPixel x 4 x 16bit x 0,33 (Cache) / 8 = ca. 924 MB / sec

1280 x 1024 x 80fps x 2 (Rendern + RamDAC) = ca. 400 MB / sec

Summe = ca. 1324 MB / sec

Da fehlt also noch sehr viel zu den 2800 MB/sec die der Kyro zur Verfügung hat.

Bei 32bit Farbtiefe schaut die Sache aber gleich anders aus. Da sich
hier der Bandbreitenbedarf (bei 32bit Texturen) glatt verdoppelt.

Manfred

PS: das mit dem Back to Front Sorting wurde auch auf Beyond3D diskutiert. Nach Aussage von Kristof und anderen die auch mit dem Tool herumgespielt haben, gibt es kein Sorting, dafür aber jede Menge Overdraw.

MadManniMan

2002-03-07, 16:51:23

@ow:

mir schon klar, daß gf3 und co hsr besitzen. hab ich ja auch geschrieben(du erinnerst dich? ;))

wenn das mit dem sortieren klappt, dürfte das auch ein probates und vor allem praktiziertes mittel bei aktuellen spielen sein, richtig?

das mit den 1600... naja, schau mal auf mitrax. loewe hat da in seinem k3-"preview" werte der k2 ausweinandergebastelt, da zeigen sich bei 1600(nicht 1280 wie ich fälschlich sagte) erste tendenzen von bandbreitenprobs

@manfred:

sorry, aber irgendwie sind das alles milchmädchenrechnungen. und pauschalisieren geht schon garnicht.

aths

2002-03-07, 18:14:27

MadManniMan,

ich habe das K3-Preview auf mitrax gelesen, aber finde, dass die Konkurrenz etwas zu schlecht bzw. der Kyro etwas zu gut dargestellt wurde. Zunächst wurde der alte Fehler gemacht, dem Kyro mehr "effektive" Bandbreite zuzuschustern, als er hat. Er nutzt seine Bandbreite besser als jede Konkurrenz, dadurch wird aber kein Bit mehr pro Sekunde übertragen.

Bei seinen Füllraten-Vergleichen zog er nur die Pixel- und nicht Texelfüllrate heran. (Ab GTS hat jede GeForce 2 TMUs pro Pipeline.)

Und warum der Kyro bei 1600x1200 nicht füllraten- sondern bandbreitenlimitiert sein soll, wurde mir nicht so recht klar. Bei höherer Auflösung steigen beide Werte jeweils gleich stark an.

Ein paar Kommentare zu seinem Artikel:

1. Auch Supersampling kann die Bilder parallel berechnen, es ist dennoch füllratenaufwändig. Multisampling berechnet ebenso 2 oder 4 Bilder, nur dass pro Pixel lediglich 1 (statt 2 oder 4) Texel gefiltert werden.

2. Er vergleicht die Füllrate mit einer GeForce4. Diese hat bekanntlich 2 TMUs pro Pipeline, so dass die Texelfüllrate doppelt so hoch ist. Von der effektiven Texelfüllrate her sind KyroIII und GeForce4 vergleichbar; er erweckt den Eindruck als ob die KyroIII deutlich schneller sei.

3. Er hat "effektive" Bandbreiten oder Füllraten angeben, in dem die Füllrate nach oben gerechnet wird. Eine KyroIII hat eben keine 3000 MPix/sek Füllrate, erst recht nicht effektiv. Effektiv hat sie ca. 1000 MPix - und das nur dann, falls es keine Transparenz gibt. Im Gegenteil ist die effektive Füllrate der GeForce4 hier entsprechend herunter zu rechnen.

4. Wegen Transparenz kann auch eine Kyro nicht seine volle Füllrate in sichtbare Pixel umsetzen. Lt. einem (recht altem) Test (von 3dconcept) kommen "normale" Brute Force Karten auf 25% "sichtbare" Füllrate, die Kyro auf ca. 40%. Aufgrund der verbesserten Bandbreiten-Ausnutzung und Mechanismen wie HyperZ oder Z-Culling liegt sie sichtbare Füllrate wohl schon mindestens bei 30%.

(Das hängt natürlich verdammt vom Spiel ab, denn bei Games die ganz ohne Transparenz auskommen skaliert Kyro sicherlich spürbar höher.)

5. Die GeForce4, mit der er vergleicht, enthält immerhin Overdraw reduzierende Maßnahmen, (die dank Front-to-Back-Rendering der meisten
Engines auch ganz gut klappen) d.h., die vorhandene Bandbreite kann sehr gut ausgeschöpft werden, hier stört eher dass noch immer Pixel umsonst gerendert werden (dreiecksbasierter Overdraw.) (Da ich die genauen Parameter nicht kenne, hänge ich mich hier lieber nicht zu weit aus dem Fenster, was die Effizienz-Vergleiche angeht.

6. Er schreibt: "Es ist aber gut vorstellbar das PowerVR im KYRO III "nur" einen Vertex Shader integrieren wird, wir es also eher mit einer DX7+ Einheit zu tun bekommen".

Wenn VertexShader, dann sollte es schon DX8 sein.

7. Mit 8-fach Multitexturing lassen sich in der Tat viele PixelShader-Effekte darstellen, vor allem dank Fähigkeiten wie EMBM. Die Frage ist, ob das gemacht wird. Ohne PixelShader keine entsprechenden DX8-Fähigkeiten, d.h., DX8-Titel laufen dann nicht oder nicht mit vollen Effekten. Außerdem sind PixelShader leichter zu handhaben, als Effekte via Multitexturing und speziellen DX7-Shadern zu verwirklichen.

Ich möchte meine Anmerkungen nicht als Nörgelei verstanden wissen! Sein Gerüchte-Preview halte ich im gesamten für gut brauchbar.

2002-03-07, 19:32:31

Originally posted by aths
ow, du hast einige wichtige Punkte betreffs der Geometrie-Last angesprochen. Darf ich fragen, warum du dich seinerzeit so scharf gegen die T&L-Kolumne wandtest, obwohl diese in ähnliche Richtung argumentiert?

Ich denke, dass hatten wir damals eigentlich schon ausreichend diskutiert.

Du vergleichst Dinge, die nicht zu vergleichen sind und das nur mangels echter Argumente.

Der Vergleich in Kürze mit Folgerung:

GF2MX200, T&L, 64Bit RAM-Interface
V4, KEIn T&L, 128Bit RI

-> V4 schneller->T&L also scheisse

ist ja wohl völlig daneben.
Der getroffene Ton bisweilen auch.

Ich könnte da sicher besser argumentieren.

Ein paar Benches (AMD XP1700, GF2MX, 3DM2k Default):

CPU Optimization: Intel(R) Pentium(R) III

RESULTS
Platform: Internal
3DMark Result: 5351 3D marks
CPU Speed: 492 CPU 3D marks
Game 1 - Helicopter - Low Detail: 94,8 FPS
Game 1 - Helicopter - Medium Detail: 71,6 FPS
Game 1 - Helicopter - High Detail: 35,5 FPS
Game 2 - Adventure - Low Detail: 102,4 FPS
Game 2 - Adventure - Medium Detail: 84,5 FPS
Game 2 - Adventure - High Detail: 57,1 FPS
High Polygon Count (1 Light): 11643 KTriangles/s
High Polygon Count (4 Lights): 10568 KTriangles/s
High Polygon Count (8 Lights): 8717 KTriangles/s

CPU Optimization: D3D Hardware T&L

RESULTS
Platform: Internal
3DMark Result: 5330 3D marks
CPU Speed: 594 CPU 3D marks
Game 1 - Helicopter - Low Detail: 94,5 FPS
Game 1 - Helicopter - Medium Detail: 71,5 FPS
Game 1 - Helicopter - High Detail: 35,4 FPS
Game 2 - Adventure - Low Detail: 100,1 FPS
Game 2 - Adventure - Medium Detail: 84,8 FPS
Game 2 - Adventure - High Detail: 58,0 FPS
High Polygon Count (1 Light): 12088 KTriangles/s
High Polygon Count (4 Lights): 7881 KTriangles/s
High Polygon Count (8 Lights): 4683 KTriangles/s

CPU Optimization: D3D Software T&L

RESULTS
Platform: Internal
3DMark Result: 4372 3D marks
CPU Speed: 371 CPU 3D marks
Game 1 - Helicopter - Low Detail: 72,7 FPS
Game 1 - Helicopter - Medium Detail: 55,3 FPS
Game 1 - Helicopter - High Detail: 29,0 FPS
Game 2 - Adventure - Low Detail: 92,4 FPS
Game 2 - Adventure - Medium Detail: 71,3 FPS
Game 2 - Adventure - High Detail: 43,7 FPS
High Polygon Count (1 Light): 8228 KTriangles/s
High Polygon Count (4 Lights): 8345 KTriangles/s
High Polygon Count (8 Lights): 5804 KTriangles/s

Wie man sieht, ergibt sich hier für HW T&L keine Vorteil gegenüber der P3 Optimierung.
Der Polygondurchsatz der HW T&L ist hierbei sogar sehr bescheiden gegenüber der T&L des AMD XP.

Da in voll(&mehrfach)texturierten Spielen die T&L Leistung eine untergeordnete Rolle spielt ist das Endresultat des 3DMark fast identisch. Nicht vergessen sollte man aber die durch HW T&L eingesparte CPU Leistung.

Ich seh gerade ich hab da noch einen:

DISPLAY
Platform NVIDIA GeForce2 MX/MX 400
CPU Optimization D3D Software T&L

RESULTS
3DMark Score 2376
Game 1 - Car Chase - Low Detail 43.7 fps
Game 1 - Car Chase - High Detail 19.3 fps
Game 2 - Dragothic - Low Detail 36.7 fps
Game 2 - Dragothic - High Detail 15.0 fps
Game 3 - Lobby - Low Detail 42.2 fps
Game 3 - Lobby - High Detail 23.3 fps
Game 4 - Nature Not supported by hardware
Fill Rate (Single-Texturing) 190.7 MTexels/s
Fill Rate (Multi-Texturing) 332.4 MTexels/s
High Polygon Count (1 Light) 9.4 MTriangles/s
High Polygon Count (8 Lights) 3.9 MTriangles/s
Environment Bump Mapping Not supported by hardware
DOT3 Bump Mapping 24.7 fps
Vertex Shader 31.8 fps
Pixel Shader Not supported by hardware
Point Sprites 4.6 MSprites/s

DISPLAY
Platform NVIDIA GeForce2 MX/MX 400
CPU Optimization D3D Hardware T&L

RESULTS
3DMark Score 2629
Game 1 - Car Chase - Low Detail 41.5 fps
Game 1 - Car Chase - High Detail 23.1 fps
Game 2 - Dragothic - Low Detail 42.0 fps
Game 2 - Dragothic - High Detail 22.3 fps
Game 3 - Lobby - Low Detail 40.8 fps
Game 3 - Lobby - High Detail 23.9 fps
Game 4 - Nature Not supported by hardware
Fill Rate (Single-Texturing) 190.7 MTexels/s
Fill Rate (Multi-Texturing) 332.4 MTexels/s
High Polygon Count (1 Light) 12.7 MTriangles/s
High Polygon Count (8 Lights) 2.5 MTriangles/s
Environment Bump Mapping Not supported by hardware
DOT3 Bump Mapping 24.9 fps
Vertex Shader 31.9 fps
Pixel Shader Not supported by hardware
Point Sprites 5.0 MSprites/s

Hier liegt HW T&L leicht vorne, insbesondere bei den High Detail Szenen. Man beachte auch die PolygonCount Tests.

Hiermit wäre gezeigt:

Behauptungen, die 3DMarks würden HW T&L bevorzugen, kann man als Unsinn bezeichnen;)

Bei entsprechend starker CPU (wie es sie allerdings zu GF1 Zeiten noch nicht gab) bringt HW T&L bei heutigen und in absehbarer Zeit erhältlichen Games nicht viel oder gar keine Performance-Zuwachs. Spiele sind nun mal füllrate-limitiert (Ausnahme: CPU-Limitierung).

Was die sonstigen Inhalte deines Artikels betrifft, sieht das ja nur ähnlich aus wie im jetzigen. Das Marketing NVs wird angegriffen und was von Marketing generell zu halten ist.... wurde auch schon diskutiert.

Das T&L in professionellen OGL Applikationen unverzichtbar ist und auch nur dort einen grossen Teil seiner Leistung zeigen kann ist unbestritten.
Darum geht es zwar in deinem Artikel nicht, es sollte aber nicht unerwähnt bleiben, denn die Gf Reihe wurde sicher nicht nur zum Spielen entwickelt.
Vielleicht hätte es dir besser getan, NV hätte den Quadro für den Gamermarkt um die T&L kastriert;)

/edit:

Wie wäre es mit einem Vergleich meiner GF2MX mit SW T&L und deiner V4?

aths

2002-03-07, 20:15:34

ow, hast du wenigstens den ganzen Text gelesen? Im Nachtrag steht btw dazu: "Zum Einsteig wurde die GeForce2 MX-200 mit einer Voodoo4 4500 verglichen. Das führte zu kritischen Bemerkungen. Der Sinn des Vergleiches war nicht, die Sinnlosigkeit von T&L zu zeigen. Sondern die Sinnlosigkeit von T&L, wenn die restlichen Parameter nicht stimmen."

Wenn du es besser könntest, wie geschrieben, ("Ich könnte da sicher besser argumentieren.") - warum machst du es dann nicht?! Ich kann dir nur den Nachtrag empfehlen, wo es nicht mehr um Marketing geht, sondern um technische Überlegungen.

Du schreibst weiter: "Das T&L in professionellen OGL Applikationen unverzichtbar ist und auch nur dort einen grossen Teil seiner Leistung zeigen kann ist unbestritten."

Die Kolumne bezog sich ausdrücklich auf PC-Spiele. Das Argument zieht also nicht. Im Nachtrag ist das ganze deutlich formuliert: "Im professionellen Bereich, zum Beispiel bei Echtzeit-Modellierung (wenn nur Farben statt Texturen zum Einsatz kommen oder aus anderen Gründen die Rendereinheit nur wenig belastet ist) kann sich eine dedizierte Hardware-T&L-Einheit sehr positiv bemerkbar machen. Für den allergrössten Teil der 3D-Karten-Käufer ist das aber nicht relevant."

Ich gehe davon aus, dass du keine MX-200 hast. Die normale MX ist dank höherer Füllrate gegenüber der V4 zumindest bei 16 Bit natürlich schneller.

edit: Danke für die Benches.

Unregistered

2002-03-07, 21:08:48

Originally posted by MadManniMan
@manfred:

sorry, aber irgendwie sind das alles milchmädchenrechnungen. und pauschalisieren geht schon garnicht.

Doch das kann man schon, da ein TBR-Chip nur von Luft und Liebe lebt ähh.. nur Texturen benötigt und die fertig gerenderten Pixel wieder ausgibt.

Für die Texturen benötigt der Kyro bei Bilinearem Filtern und 16bit Texturen eben :

350 x 4 x 16bit x 0,33 (Cache) /8 = 924 MB / sec

Mehr Texturbandbreite geht nicht mehr, da die max. Füllrate eben bei 350MPixel liegt. Die 33% Cache-Missrate kommen aus einem PowerVR-Doc von IMG.

Da der komplette Render-Vorgang im Chip abläuft, muss der Kyro die fertigen Pixel nur noch in den Framebuffer schreiben und später wieder auslesen um sie über den RAMDAC an den Monitor auszugeben.

Also bei 80fps und 80Hz Monitoreinstellungen bei 1280x1024 @16bit :

1280*1024*16*80*2 = 400 MB / sec

Dazu kommt natürlich noch die benötigte Bandbreite für den TBR-spezifischen HSR-Algo, die ich beim ersten Posting wirklich glatt vergessen habe.
Aber da Quake3 nur (aus der Erinnerung) ca. 30K Polygone/Vertex pro Frame hat ist das auch nicht so viel. Selbst beim max. Wert von 3MB Polygondaten pro Frame ist die benötigte Bandbreite nicht so hoch :

80 x 3 x 2 (wegen des zusätzlichen Speichers für die gesorteten Polygone) x 2 (schreiben und lesen) = 960 MB / sec
(sehr wahrscheinlich liegt der tatsächliche Bandbreitenbedarf niedriger, da viele Polygone bereits beim Sorting komplett wegfallen)

Bei Quake3 dürfte der Speicherbedarf aber bei nur :
30000 x 64byte = 1,875MB liegen => <= 600MB/sec

Manfred

2002-03-07, 22:01:19

Originally posted by aths
[B]ow, hast du wenigstens den ganzen Text gelesen? Im Nachtrag steht btw dazu: "Zum Einsteig wurde die GeForce2 MX-200 mit einer Voodoo4 4500 verglichen. Das führte zu kritischen Bemerkungen. Der Sinn des Vergleiches war nicht, die Sinnlosigkeit von T&L zu zeigen. Sondern die Sinnlosigkeit von T&L, wenn die restlichen Parameter nicht stimmen."

Ich kann von jeder x-beliebigen Sache die Sinnlosigkeit zeigen, wenn restliche Parameter nicht stimmen. (Das geht sogar mit hypothetischer HW: es ist ebenso sinnlos 16 Renderpipes in einem Chip mit 32Bit Raminterface zu haben wie 1 Renderpipe mit 1024 Bit Raminterface). Jedes System ist nur so leistungsfähig, wie seine schwächste Komponente.
Oder soll hier NV der Vorwurf gemacht werden, die T&L aus dem MX200 nicht entfernt zu haben?
Ich glaube auch kaum, dass mit dem MX200 Marketing für HW T&L betrieben wurde.;)

Wenn du es besser könntest, wie geschrieben, ("Ich könnte da sicher besser argumentieren.") - warum machst du es dann nicht?!

Keine Zeit.

[QUOTE]
Du schreibst weiter: "Das T&L in professionellen OGL Applikationen unverzichtbar ist und auch nur dort einen grossen Teil seiner Leistung zeigen kann ist unbestritten."

Die Kolumne bezog sich ausdrücklich auf PC-Spiele. Das Argument zieht also nicht. Im Nachtrag ist das ganze deutlich formuliert: "Im professionellen Bereich, zum Beispiel bei Echtzeit-Modellierung (wenn nur Farben statt Texturen zum Einsatz kommen oder aus anderen Gründen die Rendereinheit nur wenig belastet ist) kann sich eine dedizierte Hardware-T&L-Einheit sehr positiv bemerkbar machen. Für den allergrössten Teil der 3D-Karten-Käufer ist das aber nicht relevant."

Ok, der Satz muss mir entfallen sein. Das kann man so stehen lasen;)

Ich gehe davon aus, dass du keine MX-200 hast. Die normale MX ist dank höherer Füllrate gegenüber der V4 zumindest bei 16 Bit natürlich schneller.

edit: Danke für die Benches.

Hab eine "Standard" MX, 32MB 175/166 (Leadtek).
Meinst du eine Vergleich mit deiner V4 unter 3DMark2k/2k1, 1024x768x32Bit FB, Texturfarbtiefe 32Bit, 24Bit Z, SW T&L wäre zulässig?
Kann auch gerne runtertakten (V4 = 166/166?).

Tigershark

2002-03-08, 02:14:08

@ow :
Ich frag mich wie Du bei dem Bench den Du zum Vergleich heranziehst und der angeblich auf einem XP 1700+ gemacht wurde die "Intel Pentium III (R)" Optimierung verwenden konntest, wo es doch ein AMD Prozz. ist ?
Oder sind Dir da irgendwelche falschen Werte reingerasselt, wenn ja, wäre natürlich eine echte Vergleichbarkeit nicht mehr gegeben...

MfG, Tiger.

Modulor

2002-03-08, 07:34:34

3DMark2k kennt den XP nicht, weswegen die SSE des Prozessors nicht genutzt werden - bei der Einstellung PIII ist dies jedoch der Fall.

2002-03-08, 12:03:45

Originally posted by Tigershark
@ow :
Ich frag mich wie Du bei dem Bench den Du zum Vergleich heranziehst und der angeblich auf einem XP 1700+ gemacht wurde die "Intel Pentium III (R)" Optimierung verwenden konntest, wo es doch ein AMD Prozz. ist ?
Oder sind Dir da irgendwelche falschen Werte reingerasselt, wenn ja, wäre natürlich eine echte Vergleichbarkeit nicht mehr gegeben...

MfG, Tiger.

Du wirst es nicht glauben, aber mit dem AMD XP laufen ALLE 6 Einstellungen:

3DNow! /Athlon /P III /Pentium /SW T&L /HW T&L

P3 Optimierung laeuft deshalb, weil der XP SSE Befehle beherrscht, ich habe sie hier gewaehlt, weil sie die schnellste SW-Optimierungsart ist (3DNow/Athlon Opt. sind geringfuegig langsamer)

Tigershark

2002-03-08, 12:43:32

Originally posted by ow

Du wirst es nicht glauben, aber mit dem AMD XP laufen ALLE 6 Einstellungen:

3DNow! /Athlon /P III /Pentium /SW T&L /HW T&L

:rofl: Wow ! Ich glaube ich sollte doch nochmal den 3D Mark 2k draufmachen um nen Screenie von einem AMD System zu machen, dass mit einer Intel-Prozessoroptimierung läuft :D

Thx für die Antwort ow ;)

Tiger.

2002-03-08, 12:58:46

Originally posted by Tigershark

:rofl: Wow ! Ich glaube ich sollte doch nochmal den 3D Mark 2k draufmachen um nen Screenie von einem AMD System zu machen, dass mit einer Intel-Prozessoroptimierung läuft :D

Thx für die Antwort ow ;)

Tiger.

Ja ist schon geil, so ein AMD XP :D

Es hat mich auch etwas erstaunt, dass die P3 Optimierung des 3DMark2k so gut darauf laeuft. Insbesondere der Polygondurchsatz (T&L Leistung) ist beeindruckend und ein Stueck hoeher als bei 3DNow/Athlon Optimierung. Die Punktzahl (Marks) beeinflusst das aber recht wenig. Ausser MS SW T&L (s.o.) bringen alle anderen Einstellungen ueber 5200 Punkte.

HOT

2002-03-08, 13:49:22

Originally posted by ow

Du wirst es nicht glauben, aber mit dem AMD XP laufen ALLE 6 Einstellungen:

3DNow! /Athlon /P III /Pentium /SW T&L /HW T&L

P3 Optimierung laeuft deshalb, weil der XP SSE Befehle beherrscht, ich habe sie hier gewaehlt, weil sie die schnellste SW-Optimierungsart ist (3DNow/Athlon Opt. sind geringfuegig langsamer)

Das kommt darauf an, was du für eine Graka verwendest ;)

Bei Geforce ist das die schnellste Einstellung, bei der Kyro aber ist Soft T&L die schnellste.

2002-03-08, 14:01:28

Originally posted by HOT

Das kommt darauf an, was du für eine Graka verwendest ;)

Bei Geforce ist das die schnellste Einstellung, bei der Kyro aber ist Soft T&L die schnellste.

Das ist interessant und mir derzeit auch unerklaerlich.

Vielleicht koennte jemand mit starker CPU und anderer Graka (Radeon7500/8500, V4/5, Kyro) mal die Tests des 3DMark2k in verschieden Optimierungen durchlaufen lassen??

Fuer die MX ist SW T&L mit Abstand (s.o.) am langsamsten, die restlichen 5 Optimierungen sind ungefaehr gleich schnell (nur max. 1-3% Unterschied).

Unregistered

2002-03-08, 16:16:27

@OW

Habe meinem Bruder neulich folgendes System zusammengebaut:

Windows XP Pro
Asus A7V266-E
AMD Athlon 1700 XP
ATI Radeon 7500 Retail
256 MB Infineon CL2

Nur wie speichere ich die Ergebnise vernünftig ab, ohne die Pro Version zu benutzen?! werde mir das nach den Benchmarkdurchläufen mal genauer anschauen, ich meine man konnte das als TXT oder so aufrufen7abspeichern, richtig?

mfG
BigBen

Quasar

2002-03-08, 17:33:31

Jup, als .txt-File geht's auch ohne Pro-Version. Sogar als Result-Browser File kann man es abspeichern, nur leider nicht mehr betrachten :(

P.S.:
Jemand an werten einer MX200 auf nem AthlonXP 1900+ interessiert?

BigBen

2002-03-08, 18:00:36

Servus Leute,

ich habe mich noch schnell hier im Forum angemeldet und nun kommen die heiss erwarteten Benchmarks:

System:
Windows XP Pro
3DMark 2000 v 1.1 ( defaul settings )
Asus A7V266-E (KT266A, BIOS 1006)
Processor Type AMD Athlon(TM) XP1700+ [1477MHz]
ATI Radeon 7500 Retail (Omega XP 1.1.32)
256 MB DDR Infineon CL2 Speicher mit schnellen Einstellungen

CPU Optimization: D3D Hardware T&L:

3DMark Result: 8258 3D marks
CPU Speed: 606 CPU 3D marks
Game 1 - Helicopter - Low Detail: 169,6 FPS
Game 1 - Helicopter - Medium Detail: 119,8 FPS
Game 1 - Helicopter - High Detail: 58,5 FPS
Game 2 - Adventure - Low Detail: 172,6 FPS
Game 2 - Adventure - Medium Detail: 103,7 FPS
Game 2 - Adventure - High Detail: 64,0 FPS
Fill Rate (Single-Texturing): 390,5 MTexels/s
Fill Rate (Multi-Texturing): 856,1 MTexels/s
High Polygon Count (1 Light): 16710 KTriangles/s
High Polygon Count (4 Lights): 10246 KTriangles/s
High Polygon Count (8 Lights): 6866 KTriangles/s
8MB Texture Rendering Speed: 472,6 FPS
16MB Texture Rendering Speed: 397,1 FPS
32MB Texture Rendering Speed: 217,5 FPS
64MB Texture Rendering Speed: 112,9 FPS
Bump Mapping (Emboss, 3-pass): 246,2 FPS
Bump Mapping (Emboss, 2-pass): 329,1 FPS
Bump Mapping (Emboss, 1-pass): 674,4 FPS
Bump Mapping (Environment): 173,6 FPS

CPU Optimization: AMD Athlon(tm):

3DMark Result: 6102 3D marks
CPU Speed: 400 CPU 3D marks
Game 1 - Helicopter - Low Detail: 111,5 FPS
Game 1 - Helicopter - Medium Detail: 77,9 FPS
Game 1 - Helicopter - High Detail: 41,4 FPS
Game 2 - Adventure - Low Detail: 143,9 FPS
Game 2 - Adventure - Medium Detail: 82,5 FPS
Game 2 - Adventure - High Detail: 51,2 FPS
Fill Rate (Single-Texturing): 390,5 MTexels/s
Fill Rate (Multi-Texturing): 857,2 MTexels/s
High Polygon Count (1 Light): 7325 KTriangles/s
High Polygon Count (4 Lights): 6523 KTriangles/s
High Polygon Count (8 Lights): 5458 KTriangles/s
8MB Texture Rendering Speed: 475,3 FPS
16MB Texture Rendering Speed: 428,4 FPS
32MB Texture Rendering Speed: 275,5 FPS
64MB Texture Rendering Speed: 150,4 FPS
Bump Mapping (Emboss, 3-pass): 249,8 FPS
Bump Mapping (Emboss, 2-pass): 332,7 FPS
Bump Mapping (Emboss, 1-pass): 681,6 FPS
Bump Mapping (Environment): 176,5 FPS

CPU Optimization: Intel(R) Pentium(R) III:

3DMark Result: 6692 3D marks
CPU Speed: 430 CPU 3D marks
Game 1 - Helicopter - Low Detail: 125,3 FPS
Game 1 - Helicopter - Medium Detail: 85,4 FPS
Game 1 - Helicopter - High Detail: 41,9 FPS
Game 2 - Adventure - Low Detail: 156,2 FPS
Game 2 - Adventure - Medium Detail: 92,2 FPS
Game 2 - Adventure - High Detail: 56,7 FPS
Fill Rate (Single-Texturing): 390,5 MTexels/s
Fill Rate (Multi-Texturing): 857,2 MTexels/s
High Polygon Count (1 Light): 6325 KTriangles/s
High Polygon Count (4 Lights): 5418 KTriangles/s
High Polygon Count (8 Lights): 4592 KTriangles/s
8MB Texture Rendering Speed: 474,3 FPS
16MB Texture Rendering Speed: 420,4 FPS
32MB Texture Rendering Speed: 274,9 FPS
64MB Texture Rendering Speed: 153,2 FPS
Bump Mapping (Emboss, 3-pass): 249,5 FPS
Bump Mapping (Emboss, 2-pass): 332,6 FPS
Bump Mapping (Emboss, 1-pass): 681,6 FPS
Bump Mapping (Environment): 176,5 FPS

CPU Optimization: AMD 3DNow!(tm):

3DMark Result: 6195 3D marks
CPU Speed: 402 CPU 3D marks
Game 1 - Helicopter - Low Detail: 116,2 FPS
Game 1 - Helicopter - Medium Detail: 80,8 FPS
Game 1 - Helicopter - High Detail: 42,2 FPS
Game 2 - Adventure - Low Detail: 142,9 FPS
Game 2 - Adventure - Medium Detail: 82,7 FPS
Game 2 - Adventure - High Detail: 51,4 FPS
Fill Rate (Single-Texturing): 390,4 MTexels/s
Fill Rate (Multi-Texturing): 857,1 MTexels/s
High Polygon Count (1 Light): 7792 KTriangles/s
High Polygon Count (4 Lights): 6851 KTriangles/s
High Polygon Count (8 Lights): 5580 KTriangles/s
8MB Texture Rendering Speed: 475,3 FPS
16MB Texture Rendering Speed: 428,2 FPS
32MB Texture Rendering Speed: 274,2 FPS
64MB Texture Rendering Speed: 148,6 FPS
Bump Mapping (Emboss, 3-pass): 249,8 FPS
Bump Mapping (Emboss, 2-pass): 332,7 FPS
Bump Mapping (Emboss, 1-pass): 681,6 FPS
Bump Mapping (Environment): 176,5 FPS

CPU Optimization: D3D Software T&L:

3DMark Result: 6644 3D marks
CPU Speed: 367 CPU 3D marks
Game 1 - Helicopter - Low Detail: 142,2 FPS
Game 1 - Helicopter - Medium Detail: 96,1 FPS
Game 1 - Helicopter - High Detail: 47,3 FPS
Game 2 - Adventure - Low Detail: 145,4 FPS
Game 2 - Adventure - Medium Detail: 77,6 FPS
Game 2 - Adventure - High Detail: 45,1 FPS
Fill Rate (Single-Texturing): 390,5 MTexels/s
Fill Rate (Multi-Texturing): 857,2 MTexels/s
High Polygon Count (1 Light): 5203 KTriangles/s
High Polygon Count (4 Lights): 4082 KTriangles/s
High Polygon Count (8 Lights): 3262 KTriangles/s
8MB Texture Rendering Speed: 474,3 FPS
16MB Texture Rendering Speed: 442,1 FPS
32MB Texture Rendering Speed: 285,5 FPS
64MB Texture Rendering Speed: 157,6 FPS
Bump Mapping (Emboss, 3-pass): 249,8 FPS
Bump Mapping (Emboss, 2-pass): 332,7 FPS
Bump Mapping (Emboss, 1-pass): 681,8 FPS
Bump Mapping (Environment): 176,5 FPS

Wirklich äusserst interessante Werte! das die Benchmarks so verschieden ausfallen hätte ich nicht gedacht. Aber es gab ein paar Stabilitätsprobleme ( einmal 3dMakr 2000 abgeschmiert und zweimal der ganze Rechner ) und die Ergebnisse scheinen sich nach mehreren Durchläufen auch etwas zu verändern!

mfG
BigBen