T&L: Gießen wir ein wenig Öl ins Feuer :-)))

[Leonidas]

http://www.computerchannel.de/hardwaretest/grafik_video/3d_prophet_4500/3d_prophet_4500_1.phtml




Hercules/Guillemot 3D Prophet 4500: Bleibt hinter den Erwartungen zurück.


Auf der 3D Prophet 4500 setzt der Grafikkarten-Hersteller Hercules/Guillemot erstmals den Pixelbeschleuniger Kyro-II ein. Die von STMicroelectronics stammende GPU (Graphic Processing Unit) tritt ebenso wie ATIs Radeon-Chip gegen Nvidias-GeForce2-MX-Grafikprozessoren an.

Doch beim Test enttäuscht der Hoffnungsträger: Trotz eines großen Speichers von 64 MB SDRAM und einer schnellen Zugriffszeit der Speicherbausteine von fünf Nanosekunden trägt die 3D Prophet 4500 die rote Laterne unseres Testzugs.

Für die schlechten Leistungswerte und den mageren Lieferumfang ist die rund 340 Mark (Stand August 2001) teure 3D Prophet 4500 keine echte Alternative zu den GeForce2-MX-basierenden Grafikkarten. Außerdem sind einige BIOS-Einstellungen notwenig, um die 3D Prophet 4500 überhaupt zum Laufen zu bringen. Auch der Anschluss von zusätzlichen Geräten bleibt dem Anwender verwehrt, da weitere Ausgänge fehlen.



Ausrüstung mager

Das Design der 3D Prophet 4500 hebt sich durch das metallisch blaue Layout von den üblicherweise grünen Boards deutlich ab – das ist zwar schön, bringt der Karte aber keinen Pluspunkt ein.

Die Kühlung des Kyro-II-Grafikprozessors übernimmt ein aktiver Lüfter in Kombination mit einem Kühlkörper. Der Takt des Chips und der Takt des auf vier Samsung-Speicherbausteinen aufgeteilten Grafikspeichers laufen mit 175 MHz synchron zueinander. Sie kommunizieren über ein 128 Bit breites Speicherinterface (die Schnittstelle zwischen Grafikkontroller und Speicher) miteinander.

Die von STMicroelectronics stammende GPU ist wie der Kyro der ersten Generation noch nicht mit der T&L-Einheit (Transformation & Lighting) ausgestattet. Dieser technologische Rückstand gegenüber dem Konkurrenzchip GeForce2-MX soll aber mit der nachfolgenden GPU beseitigt werden. Dafür besitzt die 3D Prophet 4500 die Tile-Based-Rendering-Funktion. Damit werden nur sichtbare Flächen berechnet, versteckte Flächen lässt der Kyro II dagegen aus.

Leider beschränkt die Karte den Datentransfer zwischen Hauptprozessor und Grafiksysteme auf AGPx2. Das ist nur halb so viel, wie aktuelle AGPx4-GeForce2-Karten bewältigen können: Maximal 1.066 Megabyte pro Sekunde (2 Datenwörter = 8 Bytes mal 133 Megahertz) fließen über die Schnittstelle.

Auch der Inhalt des kompletten Pakets sieht etwas mager aus: kein softwarebasierender DVD-Player, keine zusätzlichen Anwendungen und kein Spielebundle.

Als maximale Auflösung gibt der französische Kartenproduzent 1.920 x 1.440 Bildpunkte bei 75 Hertz an.


Eingriff im BIOS nötig

Die Grafikkarten-Treiber auf der Installations-CD-ROM (Version 7.89) ließen sich problemlos in unser Testsystem einlesen. Beim Booten nach der Installation gab es jedoch Probleme, die sogar zu einem Blue Screen (Totalabsturz des Rechners) führten. Erst nachdem die Graphics Aperture Size im BIOS von 256 MB auf 64 MB und "Video Memory Cache Mode" von USWC auf UC gesetzt wurden, lief das System stabil.

Die Benchmarks liefen fehlerfrei und ohne Absturz. Um die Karte mit dem restlichen Testfeld vergleichen zu können, mussten wir die softwaremäßige T&L-Unterstützung aktivieren. Die anderen Probanden haben diese Technik, die für bessere 3D-Darstellungen sorgt, bereits hardwareseitig implementiert. So sind noch mehr Polygone mit realistischeren Lichtverhältnissen darzustellen. T&L gibt es in ähnlicher Form bei OpenGL-Grafikkarten in High-End-Workstations schon seit längerer Zeit.

Mit 58 Leistungs-Punkten liegt die 3D Prophet 4500 etwa 10 Prozent hinter den Spitzenreitern der GeForce2-MX-basierenden Grafikarten (64 Punkten). Ein mageres Handbuch und die knappe Ausstattung werfen das Board deutlich zurück.



Guillemot 3D Prophet 4500

Gesamtpunkte: 39

Durchschnitts-Preis: 335 Mark

Vorteile:
-

Nachteile:
Kein Hardware T&L
AGP2x
Einstellungen im BIOS notwendig



Guillemot 3D Prophet 4500 - Leistung 58


3DMark2001 1024x768 2.573 Punkte
3DMark2000 1280x1024 2.232 Punkte
ViewPerf AWasds-04 1280x1024x32 9,8 fps
ViewPerf DRV-07 1280x1024x32 3,0 fps
ViewPerf DX-06 1280x1024x32 4,2 fps
ViewPerf Light-04 1280x1024x32 1,6 fps
ViewPerf MedMCAD-01 1280x1024x32 3,9 fps
ViewPerf ProCDRS-03 1280x1024x32 2,2 fps
Quake3A 1024x768x32 98,8 fps
Quake3A 1280x1024x32 57,2 fps
AquaMark 1024x768x32 1,0 fps
AquaMark max.1024x768x32 33,1 fps
AquaMark mitte 1024x768x32 13,1 fps
AquaMark min. 1280x1024x32 1,0 fps
AquaMark max. 1280x1024x32 21,0 fps
AquaMark mittel 1280x1024x32 8,5 fps


AMD Athlon Prozessor mit einer Taktfrequenz von 1333 MHz
256 MB PC2100 DDR-SDRAM /2.5/3/3) von MemorySolution
Asus Motherboard A7M266 (AMD 761 / VIA 686B)
30 GB Festplatte IBM DTLA-307030
Soundkarte C-Media CMI8738 (onboard)
Netzwerkkarte 3Com 3C903C-TX-M (beim Test deaktiviert)
Windows ME als Betriebssystem
Microsoft DirectX 8.0a

[Andre]

Wer hat denn den Artikel verbockt ?
Also, das sind ja richtig viele Fehler drin, ich kann die Argumente nur bedingt nachvollziehen.

[Unregistered]

Welche Plebse haben sich das ausgedacht, bzw. wer hat das verfasst.
Die verwendeten Benchmarks sind ja schon klasse.
Warum bitte ViewPerf, das ist ein Profi-Programm, der Kyro ist eine Spiele-GPU.
Und selbst wenn die 3Dmark Ergebnisse nicht zählen,
warum sind die so niedrig.
Und wie oft wird hier von der Geforce gesprochen, ich denke das ist review einer Kyro-Karte.
Und die glauben scheinbar immer noch das AGP4x die Erlösung sei.
Insgesamt sind die Benchmarks irgenwie seltsam.
Vor allem mit einem Athlon 1333.
Vielleicht hätte man mal neue Treiber verwenden sollen?!
Oder die Site ist von Nvidia gesponsert.

[tikiman]

Jo, cooles Review...wiederspricht in seiner Gesamtaussage lediglich 95% aller sonstigen Kyro2-Review´s.

3DMark2000, Aquamark...tststs. :P

[StefanV]

Das beweist mal wieder eins:

Die meisten Tester sind UNFÄHIG...

Einfach unkompetent...

Siehe F. Völkel von THG...

[Korak]

Solangsam fängt der Herr Volker an mir leid zutun =)

[ow]

Originally posted by Unregistered

Die verwendeten Benchmarks sind ja schon klasse.
Warum bitte ViewPerf, das ist ein Profi-Programm, der Kyro ist eine Spiele-GPU.




Eben, NVidia stellt professionelle Grafikchips her, der Rest (Ati, powervr) halt nur Spielzeug.
Schoen, dass das mal in aller Deutlichkeit gezeigt wird.

Die Viewperf Werte erreiche ich locker mit der Riva TNT, vom GF2MX rede ich lieber mal nicht hier.

[Unregistered]

Weil du bestimmt auch mit solchen Programmen arbeitest.
Erreichste mit deiner Riva TNT auch solche Q3A-Werte, du?

by S.Payne
Etwas freudlicher Guest!

[Andre]

Was sollen eigentlich immer die verbalen Angriffe gegen ow, verdammt ?
Kann man sich hier nicht sachlich ausdrücken ?

[Korak]

Wieviel T&L Threads gibts jetzt eigentlich schon???
Da kommt man ja ganz durcheinander was man wo zu was geschrieben hat.
Hier krigt man ja vor lauter T&L die Krise. :bawling::sulkoff:

[Unregistered]

Originally posted by Unregistered
Weil du bestimmt auch mit solchen Programmen arbeitest.
Erreichste mit deiner Riva TNT auch solche Q3A-Werte, du?

by S.Payne
Etwas freudlicher Guest!


@ Guest: Was glaubst du denn, mit welchen Karten die 3D Models und Levels in Q3 etc. entworfen werden??

Meinst du, du braeuchtest nur eine Knopf zu druecken und...klick.... komplett texturiertes Szenario ???
Also meinerseits faengt das immer mit Vertices -Wireframe - flat/gouraud shading -coloring an.


Poll:
Wer hier begreift denn, dass es ohne die sog. "brute force renderer' ueberhaupt keine 3D Szenarien und eben auch Game-Levels/-Models gaebe??

mfg

-ow-

[Unregistered]

Ich find es nur toll, dass Herr ow nicht den gesamten Artikel gelesen hat(scheinbar), denn was da noch so drin steht ist ja wohl unter aller Kanone.
Und wie 3D-Grafik entsteht ist wohl klar, also was willst du mir damit sagen, ich glaub ich krieg den Anschluß nicht.

[Unregistered]

Ach so.
Seit wann glaubst du gibt es denn schon die Powervr-Technologie?
Auf jeden Fall schon länger als der erste ernstzunehmende Nvidia-Chip(NV3).

[ow]

@ Guest


Ich hab den Artikel gar nicht gelesen, wollte nur... etwas Öl ins Feuer giessen...s. Topic:D:D

Aber anders als viele im Forum bin ich nicht der Meinung, dass TBRs eine Allzewckmittel darstellen, dass sämtliche Probleme des Rendering Vorgangs löst (->Speicherbandbreite).

Nicht umsonst sind alle Profi-OGL-Karten klassische 'brute force renderer' mit HW T&L.
Deshalb mein Hinweis auf die Leistung der Kyro in Profi-Anwendungen/Benches.

Bin mal gespannt, wie die neue (Ati) FireGL8800 sich hier schlägt.

[Kai]

Ich bin da mit Ow einer Meinung. Wo wären wir denn jetzt ohne BruteForce rendering bei den aktuellen Spiele-Titeln? Vielleicht mal knapp oberhalb des FPS-mässigen "Urschleims" ...

Eine Idee zu haben ist gut ... eine Idee dann auch umzusetzen ist besser. Und bisher hat Nvidia noch jede Idee verwirklicht ... auch T&L - und das war bei weitem nicht die einzige Idee.

TBA ist eine gute Idee ... aber warum hab ich nur so das Gefühl das ich genausogut über TBA wie jetzt hier über T&L "herziehen" könnte?

[StefanV]

@ow

TBR löst das Bandbreiten Problem...

Leider schafft es neue...

Aber irgendwann wird der SGI Renderer am Ende sein...

Auch eDRAM ist kein Allheilmittel...

ERGO:

Es gibt ein 'kleineres' Problem...

Denn TBR soll ja ein 'kleines' Problemchen mit großen Poligonmengen haben...
Insbesondere eDRAM halte ich für schwachsinnig...

[ow]

@ Stefan

Volle Zustimmung. Sowohl 'TBRs' als auch 'SGIs' lösen Probleme und haben dafür andere Probleme.

Eine Zeitlang werden beide Architekturen noch brauchbar sein. Die Halbleiterphysik hat da noch einige Reserven, Chips unter 5nm Strukturbreite, 500Mio. Transistoren und bis 2GHz sollten machbar sein.

Ich denke, beide Chip-Archiktekturen werden bis zur Grenze der klassischen CMOS-Bauteile noch existieren.

[Thowe]

Originally posted by Andre
Was sollen eigentlich immer die verbalen Angriffe gegen ow, verdammt ?
Kann man sich hier nicht sachlich ausdrücken ?

Wenn der Person der technische Sachverstand fehlt? AFAIK Nein.

[aths]

"Denn TBR soll ja ein 'kleines' Problemchen mit großen Poligonmengen haben..."

Das ist meines Wissens (ich lasse mich vom Gegenteil überzeugen, wenn eine Quelle genannt wird) nur ein Gerücht. Der Kyro hat keine Probleme bei vielen Polys. Die defered renderunit ist genügend breit ausgelegt.

[ow]

Originally posted by aths
"Denn TBR soll ja ein 'kleines' Problemchen mit großen Poligonmengen haben..."

Das ist meines Wissens (ich lasse mich vom Gegenteil überzeugen, wenn eine Quelle genannt wird) nur ein Gerücht. Der Kyro hat keine Probleme bei vielen Polys. Die defered renderunit ist genügend breit ausgelegt.


Bist du eigentlich nur zu faul zum Denken, oder was soll das Gefasel mit den Quellen??

Dem Kyro muessen ALLE Dreiecke der Szene bekannt sein, bevor er seine Arbeit aufnimmt. Hierzu verwaltet er intern eine Liste, deren Speicherkapazitaet nun mal begrenzt ist.

Hieraus folgt: Fuer TBRs gibt es eine Obergrenze der Polygone, die in einen Frame vorkommen duerfen.

Klassische Renderer arbeiten nicht mit Polygonlisten, hier gibt es keinerlei Beschraenkung fuer den Polygoncount.

[Legolas]

Aber die Größe dieser Dreieckslisten wird doch mit dem technischen Fortschritt vergrößert werden. Also sollten künftige Generationen des Kyro auch mehr Dreiecke verarbeiten können. SGI Renderer haben zwar keine theoretische Grenze, was die Anzahl der zu verarbeitenden Polys angeht, aber sehr wohl eine praktische, weil sie ab einer gewissen Masse ganz einfach ziemlich langsam werden, weil sie auch nur eine gewissen Polygonmenge genügend schnell verarbeiten können.

[ow]

@Legolas

Absolut richtig.
Es ist zu erwarten, dass der Speicher fuer die Dreieckslisten angepasst wird.

Zu den theoretischen Grenzen:
Es sind die T&L/ Triangle Setup-Engine im Chip und der AGP-Bus, die derzeit den Polygoncount fuer 'Echtzeit-3D-berechnungen' (...genügend schnell verarbeiten können..) in SGI-Renderen begrenzen.

[Xmas]

Der Kyro hat durchaus bewiesen, dass er noch genügend Reserven bei der Anzahl der Polygone hat. Außerdem kann man das Problem im Extremfall auch umgehen, indem man den externen Z-Buffer einschaltet, einen Teil der Dreiecke rendert, die Dreieckslisten löscht und dann die restlichen Dreiecke rendert.

Die eigentlichen Probleme sehe ich eher in der Tatsache, dass keine ganzen Dreiecke, sondern Pixel für Pixel gerendert wird. Das bedeutet eine geringere Effizienz des Texturcaches und deutlich mehr State Changes, was insbesondere bei der Implementation eines Pixel Shaders Probleme bereiten kann. Außerdem wüsste ich gern mal, wie der Kyro mit sehr vielen Schichten von transparenten Polygonen umgeht. Denn die muss er ja trotzdem übereinander Rendern. Und irgendwo müssen die entsprechenden Daten hin. Mal sehen, was PowerVR uns da noch an Ideen vorstellt...

Das "Bandbreitenproblem" müsste man eigentlich das "bezahlbare Bandbreiten-Problem" nennen. eDRAM ist kein Schwachsinn, wenn es bezahlbar ist. Insbesondere ist das Verhältnis Bandbreite/Renderleistung ja immer gleich, weil der Takt gleich ist. Und hier kommt es eben darauf an, eine recht ausgewogene Architektur zu bauen. Beim Kyro ist das sehr gut gelungen, bei anisotropischem Filtern kommt der Chip langsam an seine Grenzen. Es bringt nichts, einen Flaschenhals durch einen anderen zu ersetzen. Wer einen Chip mit eDRAM baut, darf auch an der Renderleistung nicht sparen. Von daher kann man von den Bitboys eigentlich einiges erwarten - auch preislich.

samX

[aths]

ow:

"Bist du eigentlich nur zu faul zum Denken, oder was soll das Gefasel mit den Quellen??"

Ich vermute, du machst absichtlich die harte Tour, damit der Gegenüber unsachlich wird -> ich verbitte mir persönliche Anmache!

"Dem Kyro muessen ALLE Dreiecke der Szene bekannt sein, bevor er seine Arbeit aufnimmt. Hierzu verwaltet er intern eine Liste, deren Speicherkapazitaet nun mal begrenzt ist."

Ja und? Die AGP-Bandbreite ist ebenfalls begrenzt.

"Hieraus folgt: Fuer TBRs gibt es eine Obergrenze der Polygone, die in einen Frame vorkommen duerfen."

Wen kümmert das, da auch die Renderleistung limitiert? Der Kyro ist so ausgelegt, dass er zu seiner Lebzeit nicht durch die Anzahl der Polygone limitiert ist.

"Klassische Renderer arbeiten nicht mit Polygonlisten, hier gibt es keinerlei Beschraenkung fuer den Polygoncount."

Mir fallen ein paar ein: AGP-Bandbreite, Speicherbandbreite der Grafikkarte, sinkende Effizienz pro zusätzliches Polygon... Löse dich doch mal von deinen abstrakten Theorien! Grafikkarten sollen Grafik erzeugen. Das ist etwas, was man - ganz praktisch - sehen kann.

Der Kyro kann mit ca. 180000 Dreiecken umgehen. Damit ist zu seiner Lebzeit GENUG Luft nach oben! Du haust hier fett auf den Putz in Fragen, die sich gar nicht stellen.

[Unregistered]

Originally posted by aths
ow:

"Dem Kyro muessen ALLE Dreiecke der Szene bekannt sein, bevor er seine Arbeit aufnimmt. Hierzu verwaltet er intern eine Liste, deren Speicherkapazitaet nun mal begrenzt ist."

Ja und? Die AGP-Bandbreite ist ebenfalls begrenzt.

--> Aha, wir vergleichen jetzt also die Groesse eines Speichers mit der Bandbreite eines Busses, sehr interessant.
Aber wenn wir doch schon dabei sind: Du hast in deinem Artikel da mit ein paar Zahlen bzgl. des AGP rumgeworfen, RECHNE da doch bitte mal vor, fuer ALLE hier.


"Klassische Renderer arbeiten nicht mit Polygonlisten, hier gibt es keinerlei Beschraenkung fuer den Polygoncount."

Mir fallen ein paar ein: AGP-Bandbreite, Speicherbandbreite der Grafikkarte, sinkende Effizienz pro zusätzliches Polygon... Löse dich doch mal von deinen abstrakten Theorien! Grafikkarten sollen Grafik erzeugen. Das ist etwas, was man - ganz praktisch - sehen kann.

--> Und wieder falsch!
Was haben dein Argumente hier denn mit dem Polygoncount zu tun??? Jede Wette, das ein SGI-Renderer selbst Szenen mit 10 Milliarden Polygonen rendert, wir reden hier eben NICHT von der Leistung, sondern lediglich von theoretischen Beschraenkungen der Architekturen.




-ow-

[MadManniMan]

@aths: hab noch mal beim kyro2-test auf 3dconcept(R.I.P) durchgeschaut...

http://www.3dconcepts.de/reviews/3dprophet4500/7.htm

auf dieser seite redet ram von 180000 polsy bie 60fps! also doch einiges mehr!

@ohweh:

tja, zu deinem kommentar könnt ich ja erwieder, daß ne gts nur maximal (theoretisch! praktisch wird sie das nie erreichen) gute 254fps in 2048*1536(bei NULL overdraw und unter misauchtung aller anderer beschränkungen!) darstellen könnte(800mpxiel / 2048*1536)

richtig, die würden immernoch reichen und in dieser auflösung wird kaum jemand spielen, ich wollte dir damit jedoch nur aufzeigen, daß alles bei irgendwelchen EXTREMEN werten auch theoretische begrenzungen hat! sogar ne nvidia-karte...

[ow]

Originally posted by MadManniMan der Rula
daß alles bei irgendwelchen EXTREMEN werten auch theoretische begrenzungen hat! sogar ne nvidia-karte...


Und du meinst jetzt, dass wüsste ich nicht??

Es ging aber nun mal um das Problem eines TBRs bei hohen Polygonzahlen.

[b0wle`]

ach @ow, wir wissen jetzt ja das die TBRs ein Problem mit zu hohen Polygonenanzahl haben, dass streitet ja keiner ab NUR das ist absolut unrelevant da die derzeitige max. Polygonenanzahl wie von den anderen bereits erwähnt heute vollkommen ausreicht. In der Zukunft wird man diese Zahl erhöhn können sofern es eben nötig ist. Also als Argument gegen das TBR würd ich das nicht sehen...

Ciao

[ow]

Originally posted by Spider
Also als Argument gegen das TBR würd ich das nicht sehen...

Ciao

Wo hab ich denn geschrieben, dass das ein Argument gegen TBRs ist?

[verrueckter2001]

Also ich habe die Herkules Prophet 4500 und ich muss sagen ich hatte keine Probleme sie zum laufen zubringen.Ich habe mir auch sofort die neusten Treiben ausm Internet geholt. Also eins kann ich sagen, zum Zecken ist diese Karten einfach genial. Ich warte schon gespannt auf die Kyro III und werde mir diese dann auch holen.
Ich setze auf innovative Technik für wenig Geld.
Ne NVIDIA werde ich mir auf keinen fall mehr holen weil die mir für die Leistung zu teuer sind.
Mir ist es auch egal was die Medien dazu sagen denn ich habe mich selber davon überzeugt.
Also: NIE WIEDER NVIDIA

[Xmas]

Wie ich schon geschrieben habe, hat TBR kein Problem mit hohen Polygoncounts - wenn die Treiber für diesen Fall vorbereitet sind.
Die Vorgehensweise ist einfach:
1. externen Z-Buffer aktivieren
2. Polygone sammeln, bis eine bestimmte Zahl (100000 oder so) erreicht ist, dann
3. normal rendern
4. Dreieckslisten löschen, Framebuffer und Z-Buffer bleiben erhalten
5. zurück zu 2.

Wo ist das Problem?

samX

[aths]

"--> Aha, wir vergleichen jetzt also die Groesse eines Speichers mit der Bandbreite eines Busses, sehr interessant."

Es stellt sich die Frage, ob das Limit des Kyro überhaupt relevant ist. Ist es das nicht, kann man nicht ernsthaft von einem Limit sprechen. Limit heisst Grenze, ist sie aber aus anderen Gründen nicht erreichbar ist es das gleiche, als gäbe es diese Grenze nicht.

"Aber wenn wir doch schon dabei sind: Du hast in deinem Artikel da mit ein paar Zahlen bzgl. des AGP rumgeworfen, RECHNE da doch bitte mal vor, fuer ALLE hier."

Ich warf nicht rum, sondern las vorher aufmerksam den T&L-Artikel von Raphael auf der Maur. Der Link zu seinem (Vorzeige-)Werk ist in meinem Artikel enthalten.

"--> Und wieder falsch!
Was haben dein Argumente hier denn mit dem Polygoncount zu tun"

Dass das Limit des Kyro eh nicht ins Gewicht fällt. Also kann man bezüglich der Polygonzahlen NICHT von Nachteilen des TBR sprechen.

"Jede Wette, das ein SGI-Renderer selbst Szenen mit 10 Milliarden Polygonen rendert, wir reden hier eben NICHT von der Leistung,"

Ich schon.

"sondern lediglich von theoretischen Beschraenkungen der Architekturen."

Na dann red mal über theoretische Beschränkungen. Ich halte das für beschränkt, sich an theoretischen Zahlen zu klammern. Es zählt, was die Karte bringt und hier wurden Nachteile des TBR angesprochen. Polygoncount ist jedoch in der Praxis für eine Kyro-Karte kein Problem. Also ist es Unsinn, dieser Technologie hier Schwächen zu unterstellen.

Beispiel: So zweifel ich ernsthaft an, dass ein GeForce2 MX-Chip in jedem Fall 20 Millionen Dreicke / Sekunde durch sein Triangle Setup kriegt. Daher ist es müßig, über seine "20 Mi. Dreiecke" zu reden.

[Legolas]

@ow

Naja, ich meine die erste Grenze für den Dreiecksdurchsatz bei SGI Renderern stellt im Moment wohl die Bandbreite des Grafikchips zum lokalen GrafikRAM dar, zumindest bei Spielen, weil dort ja sogut wie jeder Pixel texturiert wird. Bei professionellen Anwendungen, die vorwiegend mit Wireframemodellen arbeiten, muss die Grenze natürlich nicht unbedingt bei der Bandbreite des lokalen GrafikRAMs liegen, weil dort ja die rechen- und bandbreitenintensivste Berechnung im 3DGrafikchip, nämlich das eigentlich Texturing, nicht durchgeführt werden. Aber so ziemlich alle Betrachtungen zu T&L hier im Moment in diesem Forum beziehen sich ja fast ausschließlich auf T&L und dessen Nutzen in Spielen.

[ow]

Originally posted by Xmas
Wie ich schon geschrieben habe, hat TBR kein Problem mit hohen Polygoncounts - wenn die Treiber für diesen Fall vorbereitet sind.
Die Vorgehensweise ist einfach:
1. externen Z-Buffer aktivieren
2. Polygone sammeln, bis eine bestimmte Zahl (100000 oder so) erreicht ist, dann
3. normal rendern
4. Dreieckslisten löschen, Framebuffer und Z-Buffer bleiben erhalten
5. zurück zu 2.

Wo ist das Problem?

samX




Das Problem ist, dass der Kyro dann nicht mehr als TBR arbeitet, ganz einfach.

[Legolas]

Die Effizienz des TBR ist dann halt nicht mehr 100%, aber trotzdem wird ein Teil des Overdraw entfernt.

[ow]

Originally posted by Legolas
@ow
Aber so ziemlich alle Betrachtungen zu T&L hier im Moment in diesem Forum beziehen sich ja fast ausschließlich auf T&L und dessen Nutzen in Spielen.


Oder auch nicht.
Es wird vielmehr generell behauptet, das T&L Unsinn ist und eine CPU dieselbe T&L Leistung in SW erbringt.

Du hast ja absolut recht. Der Nutzen von T&L in Spielen ist bis heute (bei starker CPU) 'gering' bis 'nicht vorhanden'. Aber deshalb T&L als Unsinn zu sehen...

Angesichts der heissen Diskussionen um T&L hier, ware NV vielleicht besser beraten gewesen, die T&L Unit dem 'Profi'-Ableger Quadro vorzubehalten und fuer Gamer ein G-Force ohne T&L zu bringen.


Aber in dem Artikel werden ja sowieso Aepfel mit Birnen verglichen!

Um den Nutzen von T&L zu zeigen (oder auch nicht), MUSS man eine T&L faehige Karte MIT bzw. OHNE aktiviertem T&L benchen, dazu eignen sich ALLE Spiele (mit eingebautem Bench-Mode) nach DX7 Standard oder auch DX7 Benchmarks.

Dann testet man einmal "D3D HAL" und einmal "D3D T&L HAL" (die sind halt getrennt unter D3D).
Vergleiche mit nicht T&L faehigen Karten sind schlichtweg UNZULAESSIG.

[Xmas]

Originally posted by ow
Das Problem ist, dass der Kyro dann nicht mehr als TBR arbeitet, ganz einfach.

TBR bedeutet nur Tile Based Rendering, nichts anderes. Rendert der Kyro dann keine Tiles mehr?

Die Effizienz nimmt mit dieser Lösung ab, das ist klar, aber der Overdraw (transparenter Overdraw ausgenommen) ist maximal so hoch wie die Anzahl der "Sammelvorgänge" und immer geringer als bei IMRs.

[StefanV]

@ow

Richtig, nur leider halten sich die meisten Spiele nicht an die MS Spezi mit dem Auswahl Menü, das es ja schon seit DX 3 gibt und in JEDEM spiel drin sein sollte...

[ow]

Originally posted by Xmas


TBR bedeutet nur Tile Based Rendering, nichts anderes. Rendert der Kyro dann keine Tiles mehr?

Die Effizienz nimmt mit dieser Lösung ab, das ist klar, aber der Overdraw (transparenter Overdraw ausgenommen) ist maximal so hoch wie die Anzahl der "Sammelvorgänge" und immer geringer als bei IMRs.


Und zwischendurch sollte der Kyro auch den Framebuffer mal wieder auslesen (->Speicherbandfbreite), oder etwa nicht??


Mein Formulierung war falsch, richtig erkannt.
Ich meinte, das eben der Vorteil des TBRs zu einem guten Stück auf der Strecke bleibt (->externer Z-Buffer,..)

[nggalai]

> Ich meinte, das eben der Vorteil des TBRs zu einem guten Stück auf der Strecke bleibt (->externer Z-Buffer,..)

Da muss ich ow recht geben, die Performance geht da gewaltigst in die Knie. Der grosse Vorteil der TBR ist ja gerade dass die keine Z-Buffer im Video RAM halten müssen und so keine zusätzlichen passes für den Z-test benötigen. Wer's nicht glaubt darf ja gerne mal mit seiner Kyro den stencil buffer im D3D modus aktivieren. Bei Clive Barker's Undying z.B. sinkt die Framerate um ein volles Drittel, auf meinem System ...

ta,
.rb

[Thowe]

Originally posted by nggalai
> Ich meinte, das eben der Vorteil des TBRs zu einem guten Stück auf der Strecke bleibt (->externer Z-Buffer,..)

Da muss ich ow recht geben, die Performance geht da gewaltigst in die Knie. Der grosse Vorteil der TBR ist ja gerade dass die keine Z-Buffer im Video RAM halten müssen und so keine zusätzlichen passes für den Z-test benötigen. Wer's nicht glaubt darf ja gerne mal mit seiner Kyro den stencil buffer im D3D modus aktivieren. Bei Clive Barker's Undying z.B. sinkt die Framerate um ein volles Drittel, auf meinem System ...

ta,
.rb



Richtig.

Ich denke wenn hier die Vor- und Nachteile von TBR diskutiert werden sollen ist das neue Technologie Forum die bessere Adresse. Wer eine weitere Diskution darüber möchte kann gerne einen Thementhread dazu aufmachen.

Thread ist eröffnet worden von Xmas -> hier (http://www.3dcenter.de/vbulletin/showthread.php?s=&threadid=3532) -> Vor- und Nachteile der TBR

Bitte keine TBR Postings mehr in diesem Thread

[Xmas]

Die Vor- und Nachteile von TBR? Na da bin ich mal gespannt, was für Antworten kommen.

Ich habe bei obigem Beispiel lediglich darauf hingewiesen dass für den Kyro auch keine Obergrenze an Dreiecken existiert. Mit Millionen von Polygonen ist die Renderleistung sowohl bei TBR als auch bei IMR ziemlich schwach. Doch um die Leistung ging es ja gar nicht (jedenfalls kam es mir so vor ;)).

[mac770]

Originally posted by Unregistered
Welche Plebse haben sich das ausgedacht, bzw. wer hat das verfasst.
Die verwendeten Benchmarks sind ja schon klasse.
Warum bitte ViewPerf, das ist ein Profi-Programm, der Kyro ist eine Spiele-GPU.
Und selbst wenn die 3Dmark Ergebnisse nicht zählen,
warum sind die so niedrig.
Und wie oft wird hier von der Geforce gesprochen, ich denke das ist review einer Kyro-Karte.
Und die glauben scheinbar immer noch das AGP4x die Erlösung sei.
Insgesamt sind die Benchmarks irgenwie seltsam.
Vor allem mit einem Athlon 1333.
Vielleicht hätte man mal neue Treiber verwenden sollen?!
Oder die Site ist von Nvidia gesponsert.

Meine Meinung! :D

Greetz,
mac770

[mac770]

Originally posted by ow
... Es wird vielmehr generell behauptet, das T&L Unsinn ist und eine CPU dieselbe T&L Leistung in SW erbringt.

Du hast ja absolut recht. Der Nutzen von T&L in Spielen ist bis heute (bei starker CPU) 'gering' bis 'nicht vorhanden'. Aber deshalb T&L als Unsinn zu sehen...

@ow
Möglicherweise hast du mich bisher auch so verstanden.

Aber es ging mir NIE darum, die Sinnhaftigkeit von T&L (HW) zu bestreiten. Wer das tut sollte mir erstmal Gründe dafür nennen.

Meine Hauptaussage war einzig und allein, daß es sich bislang einfach nicht lohnt für Ottonormalgamer -user. Aber die Marketingstrategen von nVidia wollten uns genau das seit geraumer Zeit (seit GF1) weissmachen. Und diese Vorgehensweis ist ziemlich komplex. Preventiv: Ich betreite nicht, dass es auch einige objetive Berichte hierzu gab. Aber eben nicht auf breiter Masse und für o.g. Käuferschicht zugänglich. nVidia läßt sich dieses Feature (T6L der GF-Reihe) entsprechend bezahlen. Ein Feature das nunmal von eben genannten Personengruppen nicht benötigt wird.

Und so habe ich auch den Artikel als einer der Aussage von aths verstanden. Was ich nicht verstehe: warum du gegen die Darlegung dieses Sachverhaltens derart rüde und teilweise unfair angehst.

Greetz,
mac770

[aths]

ow:

"Es wird vielmehr generell behauptet, das T&L Unsinn ist"

Wo wird das "generell behauptet"? Zitat, bitte.

"und eine CPU dieselbe T&L Leistung in SW erbringt."

Nicht "eine", sondern eine moderne CPU.

[Nutzen in Games nur bedingt]
"Aber deshalb T&L als Unsinn zu sehen..."

Der ganze Artikel ist sichtlich mit den Augen eines Gamers geschrieben. Das ist bereits in der Einleitung erkennbar.

"Vergleiche mit nicht T&L faehigen Karten sind schlichtweg UNZULAESSIG."

Das verstehe ich nicht. Um den Nutzen von T&L zu werten, würde ich eher Karten mit T&L gegen Karten ohne T&L benchen. Denn T&L wurde ja zum "must-have" Feature hoch stilisiert. Genau diese Wichtigkeit wird im Artikel aber angezweifelt.

[Dunkeltier]

T&L ist wie ein dicker Motor im amerikansichen Chevrolet. Fett, protzig, nicht gerade sparsam mit Rechenleistung, ineffizient. TBR ist so etwas wie ein getuntes 3 Liter Auto. Unaufällig, sparsam, effizient. So siehts aus. Und nochwas. Je weiter die sich die Polygonzahlen erhöhen, destso effizienter wird ein TBR. Notfalls ein paar zusätzliche Pipelines einstreuen, um schneller den Overdraw wegrechnen zu können. Die Kyro ist auf jeden Fall ein intelligentes Produkt.

[ow]

Originally posted by Das Kriterium
Die Kyro ist auf jeden Fall ein intelligentes Produkt.


Dagegen kann man nichts sagen.

Aber ansonsten scheinst du nicht viel vom 3D Rendering Prozess zu verstehen, sorry.

[Unregistered]

"Aber ansonsten scheinst du nicht viel vom 3D Rendering Prozess zu verstehen, sorry."

Und können wir mal eine Kostprobe *deines* Könnens bekommen?

Wie immer kanzelst du kurz jemanden ab, ohne das zu begründen. Oder du begründest deine Argumente mit dem Hinweis, dass 2+2=4 ist.

Echt toll.

[Thowe]

Originally posted by Unregistered
"Aber ansonsten scheinst du nicht viel vom 3D Rendering Prozess zu verstehen, sorry."

Und können wir mal eine Kostprobe *deines* Könnens bekommen?

Wie immer kanzelst du kurz jemanden ab, ohne das zu begründen. Oder du begründest deine Argumente mit dem Hinweis, dass 2+2=4 ist.

Echt toll.

2+2=4 ist doch richtig?

Vielleicht solltes du einfach etwas genauer deine Fragen/Antworten formulieren, dann ist die Chance eine bessere Antwort zu erhalten höher.