Nachtrag zum TnL-Artikel [Archiv]

mac770

2001-09-18, 02:16:17

Man sollte sich halt immer an die Fakten halten ....

Bin übrigens gestern durch einen Links nochmal auf das interne nVidia Papier zum Vergleich von GF2 MX und Kyro II gestossen. ( http://www.hardtecs4u.com/reviews/2001/nvidia_vs_kyro2/ )Was fürn Brüller! :lol: (Wenns nicht ernst gemeint wäre)

Bis zur TNT2 war bei mir übrigens die nVidia-Welt noch in Ordnung, die GF2 Ultra waren mir dann mit DM 1.800,- seiner Zeit doch etwas zu teuer, das Geld in die GF2 MX war nach heutiger Sicht falsch investiert, aber nach dem 3Dfx-Tot und vor der Konkurenz von ATI und PowerVr/ImTec, war nVidia nun mal der Einzige Hersteller in diesem Bereich und hat die Preise diktiert.

Egal, wie man zu nVidia-Produkten steht, ob man sie für seine Bedürfnisse als sehr gut oder weniger gut, als preisgünstig oder teuer einstuft. Das belibt jedem selbst überlassen und ist recht subjektiv. Darüber kann man sich gar nicht streiten, finde ich.

Was die Machenschaften von nVidia im Bereich Preisgestaltung, Treibertaktik, Marketingstrategie, Manupulation von Kunden (gefakte Lieferengpässe, ...) und derlei angeht, so kann ich wohl mit Fug und Recht behaupten, dass mir nVidia im höchsten Maße unsympathisch geworden ist und nachdem ich meine GF2 MX verkauft habe steht auch für mich "nVidia" vorerst für "nieVida". Solch ein Gebaren einer Firma kann ich nicht tolerieren. Ich möchte mich keines Falls weiterhin als (indirekter) Kunde einer solchen Firma bezeichnen.

Und nochmal: Der letzte Absatz sagt rein gar nichts über die Güte der Produkte von nVidia aus

Greetz,
mac770

2001-09-18, 13:20:20

Denselben Schwachsinn ueber T&L und Tiler nochmal loszulassen, macht den Artikel keineswegs besser.
Solange hier Aepfel mir Birnen verglichen werden, ist der Artikel absolut wertlos.

StefanV

2001-09-18, 14:17:20

@ow

Es geht hier um Spiele, nicht um 'sinnvolle' Anwendungen!!...

Und für Spiele ist eine feste T&L, und dafür ein SGI Renderer 'pure' nunmal nicht so sinnvoll wie ein TBR oder ein SGI Renderer mit vorgezogenem Z Test, Z Buffer Komprimierung usw...

Frank

2001-09-18, 16:00:25

Zumal wenn man für "Anwendungen" sich eine Karte holt - dort garantiert nicht nVidia drauf steht. Bei uns in Uni hamm die bei solchen Aufgaben gleich ne FireGL. Oder ne Matrox G100 für Standardrechner.

2001-09-18, 16:10:44

@ Stefan & Frank

Darum geht es mir nicht. Es werden hier Tiler mit T&L verglichen und da ist eben nichts zu vergleichen!

ZITAT:

"Ist es nicht wesentlich sinnvoller, diese Entwicklung (Anm.: Tiler) vor T&L zu setzen?"

ZITATENDE

Frage: Was soll daran sinnvoll sein?
Nochmals: TBR stellt kein 'Allheilmittel' fuer den Rendering-Prozess dar, es ist lediglich eine andere Umsetzung
des Rasterizers.

Die Vorzuege von TBR (Bandbreite) den traditionellen Renderen mit T&L daher als Nachteil anzulasten, ist unsinnig.
WIe wuerde der Artikel denn aussehen, wenn es die Geforce Chips ohne T&L gaebe?? Denkt mal drueber nach.

Frank

2001-09-18, 16:37:19

Ich frag mich grad wie der Artikel aussehen würde, wenn es überhaupt keine Geforce Chips geben würde.

RAL

2001-09-18, 16:44:50

Natürlich kann man zwei völlig verschiedene Strategien, die Leistungsfähigkeit von Spielegrafikkarten zu verbessern, vergleichen. Es ist nicht ganz einfach, zugegeben, aber prinzipiell natürlich zulässig. Wenn man das nicht dürfte, dann dürfte man auch nicht darüber diskutieren, ob nun z.B. CRT- oder TFT-Bildschirme in diesen oder jenen Fällen besser geeignet sind, nur weil sie auf einer völlig anderen Technik beruhen. Man betrachtet einfach die Aspekte, die einen interessieren, und guckt, was hinten raus kommt. Bei Spielegrafikkarten ist das z.B. Darstellungsqualität und Geschwindigkeit bei einem Durchschnitt an aktuellen Referenzspielen. Bei Äpfeln und Birnen könnte man zum Beispiel fragen: "Was wird besser vom Durchschnittsuser verdaut" und schaut was hinten rauskommt. Du siehst, es ist überhaupt kein Problem, Äpfel mit Birnen zu vergleichen, solange man sich vorher überlegt, was für Effekte man vergleichen will.

Originally posted by ow
WIe wuerde der Artikel denn aussehen, wenn es die Geforce Chips ohne T&L gaebe?? Denkt mal drueber nach.

So wie ein Vergleich von Äpfeln mit Birnen, in dem die Äpfel fehlen? Denk mal darüber nach.

aths

2001-09-18, 18:55:47

2ow:

"Darum geht es mir nicht. Es werden hier Tiler mit T&L verglichen und da ist eben nichts zu vergleichen!"

Ich vergleiche die Leistungssteigerung von Tiler- mit T&L-Karten. Warum? Weil T&L als ideales Mittel gefeiert wurde. Obwohl es sich nur bedingt bewährte. HSR-Tiler hingegen überzeugen auch in der Praxis.

> ZITAT:
> "Ist es nicht wesentlich sinnvoller, diese Entwicklung (Anm.: Tiler) vor T&L zu setzen?"
> ZITATENDE
> Frage: Was soll daran sinnvoll sein?

Daran ist sinnvoll, dass erstmal die Renderunit entlastet wird.

> Nochmals: TBR stellt kein 'Allheilmittel' fuer den Rendering-Prozess dar,

Das wurde an keiner Stelle behauptet. Du versuchst wieder einmal, mir Dinge unterzuschieben die ich nie gesagt habe. Und das "widerlegst" du dann.

> Die Vorzuege von TBR (Bandbreite) den traditionellen Renderen mit T&L daher als Nachteil anzulasten, ist unsinnig.

Diese Ansicht akzeptiere ich sofort. Genauso unsinnig ist es dann aber auch, T&L-losen Karten das Fehlen von T&L anzulasten. Das ist aber gängige Praxis, SEIT JAHREN! Meine Bemerkung im Nachtrag dazu: "hätte man seit dem Kyro allen entsprechenden Karten fehlende Effizienz-steigernde Maßnahmen ankreiden können"

"hätte ... können". Das ist also vorsichtig ausgedrückt. Ich laste den traditionellen Rendern (egal ob mit oder ohne T&L) das fehlende TBR nicht an. Aber ehrlich gesagt kotzt es mich an, dass du ständig die Dinge die im Artikel stehen verbiegst, bevor du dagegen was schreibst.

> WIe wuerde der Artikel denn aussehen, wenn es die Geforce Chips ohne T&L gaebe??

Generell oder nur einige Varianten ohne T&L? GeForce kommt btw von Geometry Force und da ist T&L Programm. Denk mal drüber nach.

> Solange hier Aepfel mir Birnen verglichen werden, ist der Artikel absolut wertlos.

Schreib einen besseren, wenn du kannst. Zumal dieser "Vergleich" nur einen (sogar recht geringen) Teil im Nachtrag einnahmen.

Ich konnte alle deine Kritik-Punkte "abwenden" weil du Dinge kritisierst, die da gar nicht stehen.

Thowe

2001-09-18, 20:51:31

Also ich find den Nachtrag sehr gelungen, obwohl ich ja auch den ersten Artikel etwas kritisiert habe.

2001-09-18, 21:08:54

Originally posted by RAL
Natürlich kann man zwei völlig verschiedene Strategien, die Leistungsfähigkeit von Spielegrafikkarten zu verbessern, vergleichen. Es ist nicht ganz einfach, zugegeben, aber prinzipiell natürlich zulässig.

Das sehe ich in diesem Fall anders. Natürlich ist es zulässig, verschiedene Konzepte des 3D-Rendering zu vergleichen, aber nicht hier.

Es geht aber in dem originalen Artikel darum, Vorteile (oder auch Nachteile) einer T&L zu zeigen.

Streng genommen, darf man hier nur zwei Chips, die sich ausschliesslich durch eine T&L Unit unterscheiden vergleichen.
Also beispielsweise GF2 mit T&L gegen GF2 ohne T&L.

Also kann ich vergleichen:
Tiler ohne T&L mit klassischem Renderer ohne T&L (um Vor-/Nachteile des TBR zu zeigen),

dito, beide mit T&L,

klassischer Renderer mit T&L gegen einen solchen ohne T&L (um eben Vor-/Nachteile einer T&L zu zeigen).

Der im Artikel angestellte Vergleich 'vermischt' zu sehr TBR/T&L-Eigenschaften, um hieraus eine Aussage über T&L treffen zu können.

aths

2001-09-19, 02:27:18

2ow:

"Es geht aber in dem originalen Artikel darum, Vorteile (oder auch Nachteile) einer T&L zu zeigen."

Negativ. Es ging darum, nachzuweisen, dass der Hype um T&L nicht gerechtfertigt ist.

"Streng genommen, darf man hier nur zwei Chips, die sich ausschliesslich durch eine T&L Unit unterscheiden vergleichen."

Wie kommst du zu dieser Behauptung? Wenn Firmen ihre Karten mit T&L anpreisen ist es doch interessant zu sehen, wie Karten ohne T&L abschneiden.

"Der im Artikel angestellte Vergleich 'vermischt' zu sehr TBR/T&L-Eigenschaften, um hieraus eine Aussage über T&L treffen zu können."

Seufz. Nochmal: Es ist ersichtlich, dass das HSR-Tiler-Feature in der Praxis deutlich mehr bringt, als T&L. Es ist mir doch Wurst, WIE das nun genau erreicht wird. Es zählt für mich nur, *dass* vorgezogenes HSR der viel grössere Bringer als T&L ist.

Das hat eigentlich nichts mit T&L zu tun, stimmt. Allerdings wird hier deutlich weniger Wind drum gemacht als um T&L, obwohl es deutlich mehr bringt. Dieses Beispiel soll die einseitige Blindheit einschlägiger Medien zeigen, die nicht in der Lage sind, Features realistisch einzuschätzen. Ausserdem ging auch eine Kritik an all diejenigen, die nVidia für technisch führend halten. Der Kyro nutzt die Hardware mit einer unübertroffenen Effizienz. Der Kunde spart bares Geld. Ich vermute, so wurde Artikel+Nachtrag auch von allen verstanden. Ausser von dir.

nggalai

2001-09-19, 09:24:42

Hi aths,

danke für den ausgezeichneten Nachtrag zu deinem TnL Artikel. Leider haben sich wieder einige kleine Ungenauigkeiten reingeschlichen, aber nix wildes. :)

In der Einleitung des originalen Artikels wurde Max Payne erwähnt, das aus T&L nun doch deutlichen Nutzen ziehen kann, wie einige nachwiesen. Diese Max Payne T&L-"Optimierung" sollte kritisch gesehen werden: Technisch ist das Spiel eher mit dem 3DMark2000 (DX7) als seinem Nachfolger (zum Teil schon DX8) zu vergleichen. Beim 3DMark2000 konnte man noch eine 3DNow!- bzw. SSE-Optimierung wählen. Es ist kein Geheimnis, dass Direct3D Software T&L weniger bringt als eine an das Spiel angepasste Handoptimierung. Man ermöglichte dem Max-Payne-Spieler also einfach nicht mehr das schnellstmögliche Software-T&L.Das ist so falsch. Spätere releases der MaxFX engine unterstützen sehr wohl 3DNow! als auch SSE Optimierungen--die lassen sich, anders als beim 3DMark2000, einfach nicht mehr DEAKTIVIEREN. Die Engine merkt selbst, welche Optimierungen angebracht sind, und verwendet dann automatisch den "richtigen" branch im Code. Falls keine HW TnL Einheit vorhanden ist, dann läuft Max Payne also sehr wohl mit "dem schnellstmöglichen Software-T&L." Weshalb läuft's dann ned ähnlich flott wie der 3DMark2000? Das hat mit den geometrisch immergleichen, aber anders texturierten Gegnern zu tun. (s. unten)

Ist das ein Grund, die heutige Brauchbarkeit von DirectX7 T&L anzuzweifeln? Folgende Überlegung: Dieses T&L kann die CPU-Entlastung nur bei starrer Geometrie voll ausspielen. Was lässt sich damit alles darstellen? Zum einen natürlich Gebäude. Wände kommen allerdings eh mit sehr wenigen Dreiecken aus. Problematisch, weil CPU-lastig, sind eher die vielen kleinen Objekte. Wie zum Beispiel die Bäume und Gräser in Landschaften. Nun fällt auf, dass diese Objekte in DirectX7 T&L-Demos starr sind. Ok, lieber unbewegliche Grashalme als keine, aber ob der Realismus auf diese Weise durch T&L gesteigert werden kann, wage ich zu bezweifeln. In Zukunft werden die geometrischen Modelle verstärkt den Gesetzen der Physik angepasst und das schreit nach einer programmierbaren T&L-Engine (DirectX8 compliant). JA zum Schreien nach programmierbarem TnL. NEIN zum Thema "starre Geometrie". Man kann sehr wohl mit einer DX7 TnL Engine "nicht-starre" Dinger TnL beschleunigen, das ist nur ein wenig aufwendiger. Faktisch gesehen heisst DX7 TnL (neben so Sachen wie "keine Änderung am Mesh möglich") nix anderes, als dass nur ein Koordinatensystem für Transformationen zur Verfügung steht (world). In anderen Worten, Du kannst mit HW TnL keine "relativen Verformungen" an Objekten durchziehen--Du kannst diese aber sehr wohl auf das Welt-System umrechnen und DANN von der TnL Engine durchführen lassen, solange sich nicht die Anzahl Punkte am Objekt ändern soll.

Was leider in deinem Artikel komplett unterging ist der eine riesengrosse Vorteil, den eine On-Chip TnL Lösung gegenüber einer CPU TnL Lösung haben kann: Modelle, mit noch so hohen Polygonzahlen, müssen nur EINMAL über den AGP Bus gejagt werden, und können dann von der GPU wiederverwendet werden. Bei einer nicht-HW TnL Lösung muss jede einzelne Instanz eines Objektes komplett über den AGP Bus--das transforming und lighting passiert ja aufm System RAM/CPU. Dies kann besonders grosse Vorteile haben bei Spielen mit vielen, vielen (geometrisch gleichaussehenden) Gegnern, Rennspielen und Flugsimulatoren. Das ist übrigens auch der Grund, weshalb 3DRealms die UT Engine für TnL Support umgeschrieben hat, für DNF: mehr Gegner onscreen ohne Ruckler. Kann sich noch wer an DeusEx erinnern? Wenn mehr als 6 Gegner onscreen waren, dann ruckelt das selbst auf einem 1.4GHz Athlon mit Kyro-II ...

Auch ohne dass man die Geometrie von Objekten substantiell ändern können muss (also Punkte hinzufügen oder entfernen) macht TnL Sinn. DX7 TnL einfach wegen der fehlenden "Flexibilität" als nonsens zu verwerfen halte ich für übertrieben. John Carmack hat Pixel Shadern auch fehlende Flexibilität vorgeworfen, aber kann trotzdem alles damit machen, was er für DooM 3 braucht.

Grundsätzlich muss ich aber wie schon beim Ursprungsartikel sagen: ich stimme mit deiner Hauptaussage überein:Mit dem Feature "T&L in Hardware" alleine ist es nicht getan und GeForce-Karten bis zur Ultra können (wie alle anderen grossen Karten der gleichen Generation) ihre Power nur mit kostenintensivem Siliziumeinsatz statt Schlauheit erreichen.

ta,
-Sascha.rb

aths

2001-09-19, 20:35:35

nggalai: Es macht Spass mit jemanden zu reden, der Ahnung hat! Zu den Punkten: Wenn ich DX SW T&L einstelle, wird er das vermutlich auch nutzen. Intern mag MaxFX weitere Optimierungen nutzen, er kann sicher sowohl T&L als auch 3dnow/SSE nutzen. DX7 selbst nutzt ja auch 3dnow oder SSE, wenn vorhanden. Eine handoptimierte Engine könnte aber noch effektiver sein. Diese Behauptung geht davon aus, dass bei der Einstellung DX SW T&L das tatsächlich genutzt wird (auch mit weiteren internen Optimierungen.) Mir ist nicht bekannt, dass diese Einstellung bedeutet entweder die interne 3dnow oder SSE-Optimierung oder DX7 SW T&L zu nutzen.

Zu starrer Geometrie steht im Nachtrag: "Dieses T&L kann die CPU-Entlastung nur bei starrer Geometrie voll ausspielen." Es steht ja nicht da, dass sie die Entlastung nur bei starrer Geometrie bringt.

"Dies kann besonders grosse Vorteile haben bei Spielen mit vielen, vielen (geometrisch gleichaussehenden) Gegnern, Rennspielen und Flugsimulatoren." Ich stimme dir zu. Allerdings mit der Einschränkung der Lebenszeit einer 3D-Karte. Bis diese Dinge Realität werden, wird die Entwicklung wohl so weit sein, dass der Spieler bereits Abwechlung bei den Gegnern erfordert, nicht nur bei den Texturen, sondern auch geometrisch. Es lassen sich in der Theorie eine Menge Punkte zusammen tragen, in denen T&L wirklich ein Plus bringt. Nur wenn man sich die Spiele ansieht, vermisst man das. Der Artikel wollte den Hype als substanzlos entlarven und nicht T&L generell als sinnlos hinstellen.

"DX7 TnL einfach wegen der fehlenden "Flexibilität" als nonsens zu verwerfen halte ich für übertrieben." Ich weiss jetzt nicht, auf welches Zitat du dich berufst, denn so krass würde ich es nicht sagen. T&L ist eines von vielen Features, aber meines Erachtens weniger nützlich als z.B. Enviromental Bump Mapping. Im Nachtrag steht ja auch: "Eine unflexible Hardware T&L-Einheit ist natürlich trotzdem besser, als keine Hardware T&L-Einheit."

"John Carmack hat Pixel Shadern auch fehlende Flexibilität vorgeworfen, aber kann trotzdem alles damit machen, was er für DooM 3 braucht." Es gibt Künstler, die schaffen dir aus nassem Lehm wahre Kunstwerke, während die meisten nur dilettantisch rumkleistern. Carmack würde ähnliche Effekte vielleicht sogar ohne Shader ermöglichen (8x dynamische Lightmaps oder so :))

HOT

2001-09-25, 11:47:52

IMHO ist es zwar interessant, wie eine T&L GraKa ohne T&L abschneidet, doch muss man glaub ich auch erwähnen, dass die Software-T&L-Implementierungen im Detonator bestimmt nicht so rosig sind. Wenn man beispielsweise die Treiberoptimierung in der 3DMark2k beim Geforce von der jeweiligen CPU Optimierung auf Software T&L umstellt, bekommt man einige 100 Punkte weniger hin. Beim Kyro jedoch bringt Software T&L deutlich mehr als die jeweilige CPU Optimierung. Laut PowerVR sollen aber Optimierungen auf die CPU Befehlssätze (vor allem 3DNow!) implementiert sein.
Ein fairer direkter Vergelich zwischen HW und SW T&L ist also mit Geforce-Karten leider unmöglich. Wie stehts in dieser Hinsicht mit dem Radeon? Das wär mal interessant ;)

Quasar

2001-09-25, 13:38:00

Originally posted by HOT
.... doch muss man glaub ich auch erwähnen, dass die Software-T&L-Implementierungen im Detonator bestimmt nicht so rosig sind. Wenn man beispielsweise die Treiberoptimierung in der 3DMark2k beim Geforce von der jeweiligen CPU Optimierung auf Software T&L umstellt, bekommt man einige 100 Punkte weniger hin....

Ich denke mal, daß wird daran liegen, daß der 3DMark halbwegs vernünftige SIMD-Optimierungen (SSE mehr als 3DNow..) mit auf den Weg bekommen hat und da kann eine normal angesteuerte FPU dann doch nicht so recht mithhalten...deswegen ein paar hundert Punkte weniger.
Wieviel das jedoch in Spielen bringt, sei mal dahingestellt...
btw, 3DNow und SSE sind auch Software TnL....

Eine "Software TnL"-Implementierung auf dem Grafikchip kann ich mir schlecht vorstellen, es wird imho einfach kein TnL in HW ausgeführt.

HOT

2001-09-25, 18:02:06

Nicht auf dem Chip! Der Treiber und DX sind optimiert! Es kommt darauf an, ob das Programm DX normal oder DX T&L anspricht. Der Treiber wird dann über die entsprechende Optimierung (3DNow!,SSE(2) oder FPU) oder per T&L angesprochen. Wenn das Programm auf T&L ausgelegt wurde (muss bei DX7 ja separat passieren), dann wird beim DX7-Treiber entweder per Hardware angesprochen oder per Software emuliert. NV wäre ja schön blöd, den Geforce Treiber auf SW T&L zu optimieren, denn dann wäre eine Geforce2 Karte in fillratelastigen Scenen (sprich hohe Auflösung und Farbtiefe oder FSAA) schneller mit Software als mit Hardware T&L, aufgrund von Einsparungen der Speicherbandbreite ;)

aths

2001-09-25, 18:43:09

Das mit der Einsparung von Speicherbandbreite ohne T&L stimmt nicht, zumindest nicht generell. Wenn man Bandbreite spart, weil weniger Dreiecke sichtbar sind, ist es kein richtiger Vergleich.

Im Artikel steht, dass trotz T&L die Bandbreiten-Anforderungen sehr hoch sind. Sie könnten bei gleicher (unrealistischer) Dreieckmenge, aber ohne T&L, noch grösser sein.

Die könnte auch mit T&L deutlich kleiner sein, wenn die Karten einen eigenen Bus für T&L hätten.

Es lassen sich kaum pauschale Aussagen treffen.

nggalai

2001-09-25, 21:02:42

Hi aths,

danke für deine ausführliche Antwort; ich denke, wir sind uns mitlerweile einig geworden. :)

Jetzt aber was "neues", und zwar Hype:Der Artikel wollte den Hype als substanzlos entlarven und nicht T&L generell als sinnlos hinstellen. Dann freu' dich auf Unreal 2 ... die Programmierer von Legend machen momentan bös Laune für TnL Karten (und zwar DX7 TnL): http://ina-community.com/forums/showthread.php?threadid=134263Die ganzen Punkte, die Du in deinen Artikeln als Hype-Mittel aufgezeigt hast werden hier nochmals recycliert--dieses mal vielleicht sogar begründet, aber lest's euch selbst durch.

Hauptargument vno Legend gegen nicht-TnL Karten: "die Unreal Warfare Engine macht nicht nur Transform, sondern auch Vertex Lighting. Ausserdem hat eine durchschnittliche Aussenszene bei einem Overdraw von 2 rund 100,000 Polygone. Vielleicht machen nicht-TnL Karten momentan noch mit, aber so sicher nicht, besonders nicht, wenn man bedenkt, was die CPU in Unreal 2 noch sonst so zu machen hat. Und U2 ist nur die Speerspitze der TnL Bewegung ..."

Klingt bekannt? ;)

Ist lustig zu lesen, wenn man ein wenig Distanz bewahrt. Die Angriffe gegen Kyro-II sind jedoch eher lächerlich, besonders wenn man bedenkt, dass die Leute selbst zugeben, nie U2 auf einer Kyro-II ausprobiert zu haben ... andererseits deckt sich die Aussage, dass erst jetzt HW-TnL optimierte Spiele auf den Markt kommen, mit der anderer Produzenten. Spieleentwicklung kostet halt Zeit.

Have fun,
-Sascha.rb

HOT

2001-09-25, 22:31:46

Wenn das stimmt, das sie es nichtmal probiert haben, ist das IMHO ein absolutes Armutszeugnis. Probiert man die Engine nicht erstmal auf allen halbwegs verbreiteten Grafikchips, bevor man ein ganzes Spiel darauf auslegt? Davon hängt doch unmittelbar die Konkurrenzfähigkeit des Games ab....

Quasar

2001-09-25, 23:15:14

Ich glaube, die Verbreitung der Kyro wird immer noch überschätzt...in unseren Kreisen mag zwar mittlerweile eine durchsetzung des Marktes von 30% oder so stattgefunden haben, aber der Komplett-PC Markt ist bis jetzt, soweit ich weis, beinahe Kyro-freie Zone und dort werden die Stückzahlen umgesetzt...
Und die heißen seit ca einem Jahr GeforceMX, was auch immer man von ihr halten mag, ist sie mittlerweile doch sicher einer der verbreitetsten Chips im Mainstream segment....und darauf werden nun mal kommende Spiele abgestimmt....wenn es nur nach dem Machbaren ginge, hätten wir längst das Niveau der PS2-Grafik übertroffen....

Doomtrain

2001-09-25, 23:42:33

Das ist leider Fakt. Wenn der KyroII die Referenz wäre, hätten wir schon ganz andere Dinge gesehen, oder? "Hoff"

Ceiser Söze

2001-09-26, 00:32:09

Man sollte aber auch bedenken, dass die meisten Stückzahlen von Spielen wie Unreal2 auch genau von Usern gekauft werden, die mittlerweile mindestens eine GeForceMX - wenn nicht sogar etwas besseres - im Rechner haben.
Die meisten Home-PCs haben natürlich immer noch lahme TNT2 M64- oder Rage128-Chips im Rechner. Aber User mit solchen Rechner kaufen sich vermutlich auch keine Spiele - und wenn, dann Titel à la Myst III, Moorhuhn und Tomb Raider (evt. auch mal ein C&C).
Unreal 2 darf hingegen schon als ein Spiel für den "ernsthaften" PC-Zocker angesehen werden - und da ist der Anteil von Kyro/Kyro2-Karten bestimmt nicht zu unterschätzen.

HOT

2001-09-26, 12:28:16

Klar, die KyroII war ja auch ausschliesslich auf den Gamermarkt abgestimmt. Das ist ja auch PowerVRs Zielgruppe. Geforce2 Karten werden zwar oft von OEMs verbaut, aber die ein grossteil der Rechner davon wandern eh in den Business-Bereich. Sehr viele Gamer verwenden eh Retrail Klamotten, da sie ihre Mühlen selbst zusammenschrauben.
ST und Hercules scheinen auch mit den Verkäufen der Kyro Karten sehr zufrieden zu sein.

Razor

2001-09-26, 15:31:17

Treiber-optimiertes Software T&L ?

Sagt mal, Leute, seit Ihr noch zu retten ?
DirectX ist die einzige Schnittstelle, die entscheidet, was über die GraKa laufen soll und was über die CPU ! Dieser Automatismus kann natürlich auch manipuliert werden, indem eine Applikation 'sagt', daß explicit kein HW T&L genutzt werden soll.

Der Treiber der GraKa muß lediglich die Funktionalitäten der GraKa an das OS und damit an die API heraus führen. Mehr nicht. Daß der Treiber für bestimmte Dinge eben auch die CPU benutzt steht auf einem anden Blatt (SSE/3DNow), denn die API, das OS und letztendlich auch die Applikation tuen dieses auch wenn unterstützt. Daß also Software T&L auf einer geforce nicht 'so gut' implementiert sei, ist absoluter Dünnsinn !

-

Was die Tiler von ImgTech angeht:
Sie sind aufgrund ihrer Bandbreitenoptimierung unheimlich schnell und deswegen in dieser Hinsicht schneller, als SGI-Renderer, die so ihre Probleme damit haben. Ist aber T&L gefragt, muß die CPU ran und die sollte dann schon richtig 'fett' ausgelegt sein. Aber auch die schnellste CPU muß irgendwann streiken, wenn das zu berechnende Volumen ihre Fähigkeiten übersteigt, zumal sie ja auch noch so einiges Anderes zu leisten hat.

Ich stimme nggalai zu, denn T&L-games sind gerade jetzt erst am Kommen (das erste 'richtige' war Max Payne und eben nur der Anfang). Wie's dann mit der Leistungsfähigkeit der CPU aussieht, dieses noch vernünftig berechnen zu können (die GraKa hat dann nur noch wenig damit zu tun) wird sich dann schon zeigen, bzw. hat es schon bei MaxPayne gezeigt. Nicht unbedingt, was die durchschnittliche Framerate angeht, aber was mich viel mehr interessiert ist die minimale Framerate, die in den Boden sackt, wenn der CPU die Luft ausgeht. Hardware gestützte T&L-Berechnungen garantieren aber eine bestimmte Leistung und somit können sich die Entwickler auch daruf stützen...

-

Hardware T&L hat sicherlich sehr viel mehr Zeit gebraucht, sinnvoll zu sein, als es uns das Marketing (vor allem nVidia's) weiß machen wollte, aber langsam kommen tatsächlich Games, die davon auch wirklich profitieren. Und wenn ich mir Unreal2 so anschaue, dann kann ich nur jedem sagen, daß spätestens dann Hardware T&L sehr wohl Sinn macht (für mich macht es auch jetzt schon bei Max Payne Sinn). Und Unreal2 wird erst das erste Game sein, was auf dieser Engine basiert !

Aber all dies hatten wir ja schon mal, gelle ?

Razor

aths

2001-09-27, 21:26:02

"Die Angriffe gegen Kyro-II sind jedoch eher lächerlich, besonders wenn man bedenkt, dass die Leute selbst zugeben, nie U2 auf einer Kyro-II ausprobiert zu haben"

Sweeny sah den Kyro auf "TNT2"-Niveau. Lächerlich! Erst war er totaler 3dfx-Fan und verfluchte den PowerVR, jetzt offenbar nVidia-Fan und verflucht weiterhin den PowerVR. Peinlich!

Razor: Für EIN Spiel auf DX7 T&L zu achten, lohnt das? Und ich denke, dass ein Athlon 1.4 mit Voodoo5 wohl doch besser ist, als ein PIII 700 mit Geforce2MX. Auch bei U2. (Vermutung, warten wir die Benchmarks ab.)

AMC

2001-09-30, 05:07:43

Hehjo.

*grüsstalleausdemalten3Dconceptsforum*

Habt ihr vielleicht mal über die Tatsache nachgedacht, dass TBR nur EINMAL effizientssteigernd wirkt? Es ist nicht möglich einen NOCH effizienteren TBR Renderer zu entwickeln, da es nach dem entfernen des Overdraws keinen weiteren Schritt gibt, noch mehr verdeckte Dreiecke etc. zu reduzieren? (Bis zum schwarzen Bildschirm???? *LOL*) Das TBR, wenn es denn funktioniert (wie im kyro1/2), lässt sich NICHT mehr verbesssern. Um eine Kyro schneller zu machen, könnte PowerVR zusätzliche Pipelines, höheren Chiptakt, etc. implementieren! Aber was wäre das? Richtig, das gute alte Brute-Force Prinzip! Denkt mal genau darüber nach, WARUM der kommende Kyro III wohl schneller sein wird, als der Kyro II. Nicht nur aufgrund des höheren Chiptaktes, sondern durch die geläufigen Verbesserungen aller neuen Brute-Force Renderer. (Mehr Takt, Pipelines, Speicheranbindung) TBR sollte wie T&L in jede Grafikkarte implementiert werden, trotzdem ist es nur EIN Feature unter vielen und nicht der heilige Gral. Die Ansätze dazu sind bei ATI und nVidia schon sehr deutlich zu erkennen. (HyperZ, Z-Occlussion Culling....)
Also, versteht mich nicht falsch, aber TBR braucht nur einmal entwickelt und implementiert zu werden und reiht sich danach in die Featureliste mit ein. Es kann keine NOCH effizienteren TBR´s geben. Wo nix mehr is, was verdeckt wird, lässt sich auch nichts mehr entfernen. (Es geht nur schneller=höherer Chiptakt, wieder das alte Prinzip.)
Siehe Unterschied in der T&L Leistung der GeForce 2:

GeForce 2 MX 22 Mio. Polygone (166-175 MHz)
GeForce 2 GTS/Pro 25 Mio. Polygone (200 Mhz)
GeForce 2 Ultra 31 Mio. Polygone (250 Mhz)

MfG,

AMC

HOT

2001-09-30, 11:44:34

So ein blödsinn. Das TBR lässt sich sehr wohl noch verbessern :D
Du kannst zum Beispiel noch effizienzsteigernde Massnahemn einbauen wie z.B. variable Tiles, also mit Objekterkennung (vergleichbar wie MPEG1 zu MPEG4) und du könntest den Framebuffer komprimieren. Zudem ist noch eine bessere Texturkompression möglich. Was noch hinzukommt, ist, dass du die Anzahl der Z-Checks/Takt von 32 auf 128 oder so steigern könntest. Du kannst zwar nur einmal den Overdraw entfernen, aber das geht noch weitaus effizienter als beim Kyro ;) Dieser Chip ist eben nur ein weiterer Schritt in Richtung pwerfektion, wie bei den Bruteforce Chips auch. Ausserdem möchte ich dir widersprechen, wenn du sagst, dass ein 1000MPixel Tiler ein bruteforcs Chip ist, es ist immernoch das deferred TBR Prinzip und nicht SGI Rendern.
Was den Polygondurchsatz der T&L Einheiten der Geforce angeht: mit der T&L Leistung der Geforce1 wäre eine Geforce2 Ultra bei Spielen genausoschnell wie mit der T&L Einheit der Ultra. Der mximale Polygondurchsatz, selbst der von der Geforce1 wird selbst von der Geforce2 Ultra schlichtweg nicht erreicht :D

Thowe

2001-09-30, 11:55:38

Geometriekompression dürfte aber mehr als Framebufferkompression bringen. :)

StefanV

2001-09-30, 12:03:14

Besser wäre ein Seperater Geometrie Buffer...

PS: Muß der Eigentlich schnell sein???

Oder reicht dafür auch ein 200Mhz/16bit DDR Interface??

HOT

2001-10-01, 12:10:50

Eigentlich sollte ein 64Bit SDR Interface reichen - das kommt auf die Menge der Geometriedaten an, die zum Rendern übertragen werden. Halten wir also fest: separater ggf. verlustfrei komprimierter Geometriepuffer und Framebufferkompression ;)

2001-10-01, 12:13:47

Originally posted by HOT
Eigentlich sollte ein 64Bit SDR Interface reichen - das kommt auf die Menge der Geometriedaten an, die zum Rendern übertragen werden. Halten wir also fest: separater ggf. verlustfrei komprimierter Geometriepuffer und Framebufferkompression ;)

Was willst du denn nur mit Framebufferkompression?
Der Kyro beschreibt den doch sowieso nur einmal, was willst du da sparen??

Ausserdem: Kannst du mir verraten, wer oder was denn den komprimierten FB auf dem Display ausgeben soll?

HOT

2001-10-01, 13:26:05

Das sind aber neben Texturzugriffen die einzigen Speicherzugriffe die ein Kyro beim Rendern noch hat. Zugegebenermassen wäre der Nutzen relativ gering, aber in diesen Leistungsklassen (1000MPixel und mehr) könnte sich das schon bemerkbar machen. Natürlich müssen die Daten wieder beim RAMDAC bzw DVI Zugriff dekomprimiert werden, aber ich denke nicht, dass das ein Problem darstellt.

2001-10-01, 19:39:02

Originally posted by HOT
Das sind aber neben Texturzugriffen die einzigen Speicherzugriffe die ein Kyro beim Rendern noch hat. Zugegebenermassen wäre der Nutzen relativ gering, aber in diesen Leistungsklassen (1000MPixel und mehr) könnte sich das schon bemerkbar machen. Natürlich müssen die Daten wieder beim RAMDAC bzw DVI Zugriff dekomprimiert werden, aber ich denke nicht, dass das ein Problem darstellt.

Aber die Texturzugriffe machen sowieso den weitaus grössten Teil der Speicherzugriffe aus. Wenn man bedenkt, wieviele Texel man für ein 8-fach texturiertes, anisotropisch gefiltertes Pixel lesen muss.
Und schreiben (Framebuffer) ist auch schneller als lesen aus dem Texturspeicher.

Der Aufwand einer FB-Kompression dürfte für ihren Nutzwert viel zu hoch sein.

HOT

2001-10-01, 20:30:34

Nicht zwingend, passende Verfahren dazu sind kein Problem. Z.B. könnte man ATi's Verfahren zur Kompression der Z-Daten ind HyperZ dafür verwenden ;) Das kostet nur ein bisschen Silizium. Übrigens hat anisotropic Filtering etc keinen Einfluss beim Textureneinlesen, sondern lediglich bei der Bearbeitung dieser. Beim Kyro werden die Daten, die während der Bearbeitung entstehen, ja nicht mehr wie beim Geforce in den Grafikspeicher geschrieben, sondern in den sehr schnellen internen Tilebuffer. Hier verursacht lediglich das einmalige Schreiben und Einlesen der Geometrie bzw. Texturdaten speicherzugriffe und eben hinterher der Framebuffer, wobei ein Singlebuffer durchaus reicht, um das Bild fehlerfrei abzubilden. Das ist auch der Grund, warum die Texturkompression auf dem Kyro mehr bringt, als auf der Geforce: es werden prozentual mehr Speicherzugriffe dadurch gespaart als beim Geforce. Der KyroIII kann durchaus bei entsprechender Pipelineoptimierungen bei 250MHz mit 5ns (200MHz) DDR-SDRAM auskommen. Schnellerer Speicher wäre nicht unbedingt notwendig :D

Razor

2001-10-02, 02:24:25

Ich bin immer noch der Meinung, daß der Overdraw von der Spiele-Engine vermieden werden soll. Wenn dann ein Overdraw von 2 dabei heraus kommt, dann nützt auch ein Tiler nicht mehr viel, denn die Tiefenprüfungen kosten ja auch Zeit...

Wenn's Unreal2 tatsächlich wahr macht, den Overdraw bei 2 zu halten (und das bei den Polygonmengen), dann macht ein Tiler nicht mehr viel Sinn. Punkt.

Ich persönlich finde es 'intelligenter' wenn man eine Engine 'vernünftig' designt und damit überflüssige Dinge vermeidet, denn schließlich macht es ja eigentlich auch keinen Sinn, es der Grafikkarte aufzubürden, Dinge heraus zu filtern die ja sowieso nicht dargestellt werden, oder ?

Nur meine Meinung

Razor

HOT

2001-10-02, 10:05:58

Sicher hat das auch weiterhin Sinn, denn du wird gerade bei High Detail Scenen den Geschwindigkeitsvorteil immernoch deutlich merken... auch wenns nur um den Faktor2 ist!!! Tiler sind einfach die Zukunft, da sich per Software der Overdraw schlichtweg nicht vermeiden lässt. Es gibt IMMER ungünstige Konstallationen, die ein Overdrawkillalgorithmus NICHT wegbekommt. Der weiterer Vorteil ist, dass bei Tilern eben lange nicht soviel Speicherzugriffe nötig sind, wie bei einem nicht-Tiler. Gerade bei transparenten Overdraw (Extremfälle sind z.b. Flammenwerfer ;)) macht sich eine entsprechende Fillrate und ein sauschneller entsprechend Dimensionierter Tilebuffer mit 8 Layer Multitexturing äusserst gut. Es geht noch weiter: Dank der Tilerarchitektur ist es sogar durchaus möglich effizientes RGSS oder sogar ein HardwareFSAA oder Hardware Anisotropic Filtering zu implementieren, da sich das Rendern eben auf die Tiles beschränkt und nicht abhängig von der Auflösung ist. Zudem brauchen diese Operationen keinen enzigen zusätzlichen Speicherzugriff!!! Wir müssen runter vom Rendern variabler Auflösungen, das macht einfach keinen Sinn mehr bei dieser Detailflut bei dem jetzt verwendeten Speicher. Tile Based Rendering bei Spielen und anderen 3D-MM-Anwendungen spart derart viel Rechenleistung, dass ein Tiler auch ohne Overdraw (was per Software nur bei entsprechendem Aufwand und bei Pixelshadern momentan absolut unmöglich ist, da dann die CPU Rendern müsste), gerade in Zeiten knapper Speicherbandbreiten immernoch vorteilhaft ist. Die Kombination von Tilern und Bruteforcerenderern (sozusagen Bruteforcetiler ;)) sind hier IMMER im Vorteil (in Spielen).
Bei Professionellen Anwendungen wie 3DStudio MAX bringt ein Tiler mit entsprechender Brutforcerendererfillrate (1000MPixel) und T&L gegen einen entsprechen dimensionieren SGI-Renderer keinen Vorteil, allerdings auch keinen Nachteil.

In diesem Sinne: TILERs ARE FUTURE :D

ATi geht mit dem 8500er übrigens auch in die Richtung: HyperZ II führt den Z-Test vor dem Blending durch, um Speicherzugriffe durch Blendingoperationen zu minimieren.
ATi nähert sich dieser Technologie eben auch langsam.

Razor

2001-10-02, 11:14:49

Ist ja alles schön und gut, was sein könnte...
Gibt es das alles auch schon ?
Eher nicht, oder ?
;-)

- beim Overdraw von 2 erreicht kein Tiler dieser Welt eine doppelte Geschwindigkeit !
- gerade beim Flammenwerfer geht 'ne Kyro so richtig in die Knie (siehe CS)
- bei den Kyro's gibt's wohl offensichtlich weder HardwareFSAA, noch vernünftige ansio-Filter
- gerade bei der anstehenden Detailflut, wird sich der einzige Tiler erst bewähren müssen
- Pixelshader und Tiler ? DAS will ich sehen...
- Bruteforcetiler ? Oh mann...

Bleib doch bitte auf dem Boden. Träumen ist ja ganz nett, aber sowas grenzt ja schon fast an Wunschdenken...
;-)

Wir werden sehen. Erst einmal möchte ich einen solchen Bruteforcetiler auch mal zu gesicht bekommen. Vorher gehöt so etwas in die gleiche Schublade, wie der Chip der Bitboys...

In diesem Sinne

Razor

nggalai

2001-10-02, 11:24:24

Dank der Tilerarchitektur ist es sogar durchaus möglich effizientes RGSS oder sogar ein HardwareFSAA oder Hardware Anisotropic Filtering zu implementieren, da sich das Rendern eben auf die Tiles beschränkt und nicht abhängig von der Auflösung ist. Zudem brauchen diese Operationen keinen enzigen zusätzlichen Speicherzugriff!!! Anisotropisches Filtern wird durch Tiler nicht effizienter. Das ist ned wie FSAA, einfach über den "Screen" angewandt, und ist kaum Füllraten- oder Bandbreitenlimitiert--sondern GPU, manchmal auch CPU-limitiert. Du musst eh im Rahmen des aniso-Patterns rendern, bei Tilern wird's dann sogar noch mühsamer, da diese Regions je nach Implementierung durchaus über 2-4 Tiles liegen können--Du also u.U. einen Pixel bis zu 4x Rendern musst. Für AF werden Cycles wie blöde verbraten, die meisten Karten können das jedoch einem Pass (dank Multi-Texture Pipelines). Trotz Tiler-Architektur verbrät die Kyro-II übrigens mit anisotropischem Filtering bis zu 60% Leistung.

ta,
.rb

Razor

2001-10-02, 11:34:44

Und das bei 8-tap AF !
;-)

Razor

P.S.: Sorry, 16-tap...

HOT

2001-10-02, 11:56:37

Der Kyro ist erst der erste Vorbote dieser Technologie und schöpft das Potenzial dieser Technologie nicht im mindesten aus. Ausserdem ist es Quatsch, dass Aniso Filtering über Tiles hinausgeht, es wird innerhalb der Tiles gefiltert... Deshalb haben die Tiles ja die Grösse von 16x8 Pixeln. Der Kyro macht durchaus echte Anisotropc Filtering, ohne "über die Tiles hinauszugreifen" ;) Es ist übrigens ein Gerücht, dass der Kyro das 4-Fache an Geschwindigkeit verliert, er braucht lediglich 2 Takte mehr als üblich, weil er keine zusätzlichen TMUs besitzt. Diese TMUs lassen sich jedoch durchaus durch spezielle Hardwareimplementation des Filteralgorithmus erreichen. Zum Vergleich: S3 hat in seinen savagekarten Trilineares Filtern in Hardware integriert.
Ich habe nie behauptet, dass die Technologie im mom dazu in der Lage wäre bei ALLEN Anwendungen "perfekt" zu arbeiten. Doch das Potenzial dazu besteht selbstverständlich.
Langsam glaub ich das es keinen Sinn macht mit euch darüber zu diskutieren, da es im moment keinen direkten Vergleich von wirklich leistungsfähigen Tilern und SGI Renderern gibt.
Fakt ist jedenfalls, dass ein Tiler sehr viel weniger Speicherbanbreite braucht, als sein SGI Pendant, da weder Z-Buffer noch zusätzlich Texturzugriffe, die durch Blending, Filtering, FSAA oder Multitexturing verursacht werden. Wie gesagt, wir haben im Grunde genommen mit dem Kyro erst die erste brauchbare Tilergeneration, das da noch mehr kommt ist doch irgendwie logisch :D

Nochwas muss ich loswerden: Es ist SCHWACHSINN von einer Spieleengine (Unreal2) auf den Rest der Engines auf dem Markt zu schliessen. IMHO wird jetzt wieder hochgehypt und in einem halben Jahr, wenn Unreal2 erscheit, hat sich die Situation (egal ob Hardware oder Software) wieder grundsätzlich geändert.
Nochwas: Der Flammenwerfer in der Wolfenstein-Techdemo zieht auf dem Kyro sehr wenig Leistung :D

nggalai

2001-10-02, 12:05:53

Hi HOT,

bitte lies doch meine Postings sorgfältiger:Ausserdem ist es Quatsch, dass Aniso Filtering über Tiles hinausgeht, es wird innerhalb der Tiles gefiltert...Ich sagte, je nach IMPLEMENTIERUNG kann das vorkommen. Dass eine saubere Filtering-Funktion eines Tilers das nicht machen sollte ist wohl klar.Es ist übrigens ein Gerücht, dass der Kyro das 4-Fache an Geschwindigkeit verliert, er braucht lediglich 2 Takte mehr als üblich, weil er keine zusätzlichen TMUs besitzt.Ich sag' ja auch nix anderes--das mitm 4x ist der worst case für eine schlechte Implementierung.

Fakt ist jedenfalls, dass ein Tiler sehr viel weniger Speicherbanbreite braucht, als sein SGI Pendant, da weder Z-Buffer noch zusätzlich Texturzugriffe, die durch Blending, Filtering, FSAA oder Multitexturing verursacht werden.Das ist so ned Richtig. Für viele Dinge BRAUCHST Du einen externen Z-Buffer, da bringt dir der Tiler nix. Die meisten modernen Brute-Force Karten brauchen dank grosser Texture Cashes fürs Filtering auch keinen zusätzlichen Texturzugriff, Multisampling FSAA geht auch ohne Tiler (oder ist sind V5 und R8500 Tiler?).Wie gesagt, wir haben im Grunde genommen mit dem Kyro erst die erste brauchbare Tilergeneration, das da noch mehr kommt ist doch irgendwie logisch.*unterschreib*
Nochwas muss ich loswerden: Es ist SCHWACHSINN von einer Spieleengine (Unreal2) auf den Rest der Engines auf dem Markt zu schliessen.*auchunterschreib* Aber das macht hier ja auch niemand explizit.Nochwas: Der Flammenwerfer in der Wolfenstein-Techdemo zieht auf dem Kyro sehr wenig LeistungSchönes Gegenbeispiel zu Razors Beispiel. Aber Beispiele sind nunmal keine Argumente ... lies dir mal den 3dconcept Artikel zu Tilern durch, da hast Du Argumente für/wider Transparenz und Tilern.

ta,
.rb

nggalai

2001-10-02, 12:18:36

P.S. wie ich oben schrieb, es SOLLTEN nicht mehr als ein Tile fürs AF gebraucht werden, pro Pixel. Allerdings ist noch die Frage da, wie das verhindert werden kann, mit Tilern--anders als FSAA, welches in 2D Filtert (die Bildschirmfläche, sozusagen) ist die Anisotropie abhängig vom Tiefenwinkel (wie stark ist die Textur geneigt?). Wenn Du echtes, perspektivenkorrektes AF machen willst, wird's immer Tile-Überschneidungen geben

Stellt's euch so vor, als ob ihr durch ein Gitter auf eine Strasse guckt--das sind die Render-Tiles. Die AF Sample-Bereiche werden jedoch je nach Tiefeninfo gelegt, also ein Gitter (oder eher, je nach Implementation, eine Kette von Ellipsen), welches auf der Strasse liegt. Da wirst Du immer Überschneidungen haben, oder aber das "Strassengitter" zu gunsten des "Bildschirmgitters" beeinträchtigen, i.e. die AF-Qualität runterschrauben müssen.

Kommentare?

ta,
.rb

HOT

2001-10-02, 13:08:38

:rofl:
Selten so gelacht :D;D:D
Wie kommst du auf so einen Quark? Die Textur wird erst geladen, und dann pixelweise hirarchisch gefiltert!!! Das rein gar nichts mit den Tiles zu tun! Nach deiner Theorie wäre davon nicht nur Anistropic sondern Tilineares Filtering genauso betroffen :D Beides funktioniert "seltsamerweise" auf dem Kyro absolut fehlerfrei.
Nee nee, Die Werte, die sich "unter dem Anistropic gefilterten Pixel" befinden (sehr bildlich geprochen) sind ja vorhanden, Der Pixel wird ja nur dadurch ermittelt. Bei Trilinear muss die Textur, die gefiltert werden soll eben 2x die TMU durchlaufen und bei 16 Tap Anisotropic (Der Kyro Treiber nutzt standartmässig diesen Modus) eben noch 2x mehr. Das macht in der Summe dann 4 Durchläufe insgesamt. Das hat rein garnix mit "übergreifen auf andere Tiles" zu tun, das gibt es sowieso erst beim Bildaufbau im Kyro, beim Rendervorgang an sich ist das gar nicht möglich.
Tiler haben weder mit Anisotropic Filtering noch mit FSAA irgendwelche Probleme.

Razor

2001-10-02, 13:29:18

Hey HOT, das ist doch Haarspalterei...

Ob die Kyro nun 4x die TMU durchläuft, oder aber benachbarte Tiles heran gezogen werden, macht IMHO doch keinen performance-seitigen Unterschied. Tatsache ist, daß dafür heftig Performance drauf' geht und damit aus meiner Sicht dieses 'Feature' (AF) eben nicht vernünftig implementiert ist, oder ?

Denn schließlich bricht die Perpormace bei aktiviertem AF (16-tap) so um 50% ein, während auf einem SGI-Renderer lediglich ein Einbruch von rund 25% zu verzeichnen ist (bei 32-tap AF !). Abhängig von der Auflösung selbstverständlich, was aber für beide Prinzipien gilt.

Einigen wir uns doch einfach darauf, daß der Kyro ein paar TMU's mehr nun wirklich nicht schaden würde, oder ?
;-)

Razor

nggalai

2001-10-02, 13:55:12

*lacht*

HOT, bitte, nochmals, lies meine messages sauber durch. Das macht in der Summe dann 4 Durchläufe insgesamt. Das hat rein garnix mit "übergreifen auf andere Tiles" zu tun, das gibt es sowieso erst beim Bildaufbau im Kyro, beim Rendervorgang an sich ist das gar nicht möglich.WO behaupte ich, dass das die schlechte AF Performance der Kyro mitm "übergreifen auf andere Tiles" zu tun hat? Ich gehe von einem theoretischen Fall von perspektivisch korrektem AF aus. Ich habe selbst eine Kyro und mich über den echt besch*ssenen Performance-Hit schlaugelesen. :)

In wiefern deine Ausführungen zum Thema AF und Tiler sich mit meinen beissen kann ich ned genau sagen--falls Du jedoch recht hast, gibt sich von Tilern gegenüber traditionellen Renderern keinen Geschwindigkeitsvorteil beim Filtern, wie Du das weiter oben noch geschildert hast--weil dann ganz einfach das ganze Gefiltere eh vorm "Malen" geschieht, also auch ned anders als bei einem traditionellen Renderer. Oder könntest Du dich noch ein wenig klarer ausdrücken, wie AF von Tilern profitieren soll?

ta,
.rb

Unregistered

2001-10-02, 13:56:32

Originally posted by nggalai
*lacht*

Oder könntest Du dich noch ein wenig klarer ausdrücken, wie AF von Tilern profitieren soll?

ta,
.rb

Ja, das wuerde mich auch interessieren, wo der Vorteil eines Tilers beim Texturfiltern sein soll.

nggalai

2001-10-02, 14:00:42

Die Textur wird erst geladen, und dann pixelweise hirarchisch gefiltert!!! Das rein gar nichts mit den Tiles zu tun! Das stimmt für die MIP-Maps, aber fürs Filtern? Wie soll das gehen?

ta,
.rb

Legolas

2001-10-02, 14:13:57

Power VR hat selber übrigens gesagt, daß die Implementierung von Anisotropischem Filtering beim Kyro I/II zu 100% der Implementierung von AF in den PowerVR SG Karten entspricht. Deswegen ist der Slowdown mit AF so groß, was sich aber wohl mit der nächsten Generation ändern wird. Der Kyro bricht halt bei AF so weg, weil er eine veraltete Implementierung dieses Features besitzt..

Quasar

2001-10-02, 14:50:55

Selber schuld....also quasi die gleiche Nachlässigkeit, die nVidia seit dem Q3a-Sky bug mit sich herumschleppt....nur daß beim Kyro nicht so draufrumgeritten wird :)

nggalai

2001-10-02, 15:43:05

Nachlässigkeit würde ich das nicht nennen ... ist ja kein Bug, sondern eine technische Design-Entscheidung, die einfach reiteriert wurde--ähnlich wie mitm Textur-Filtering der R8500. Dass da nur bilinear-anisotrop gefiltert wird ist auch kein Bug sondern volle Absicht.

ta,
.rb

HOT

2001-10-02, 15:45:37

Der Kyro bricht hauptsächlich so ein bei der Leistung, weil er dahingehen keinerlei Hardwareimplementationen besitzt! Deshalb MUSS das Filtern eben 4x durch die TMU laufen! Da nicht alle Texturen gefiltert werden (Lightmaps z.B.) hält sich der Performancehit bei triliear in Grenzen; hier werden für trilineare Texturen 2 Pass berücksichtigt. Benutzt man allerding Anisotropic, werden gleich 4 Pass in anspruch genommen! Das ist dann, als hätte man 4 übereinanderliegende bilinear gefilterte Texturen - und das überall! So ist es nicht verwunderlich, dass der Kyro, abhängig von der Texturgrösse der Textur, die gefiltert wird, die Hälfte bis 2/3 an Performance verliert.
Bei Zukünftigen Chips denke ich auch, das PowerVR demnächst per Hardware trilinear filtert. Im moment jedenfalls funktioniert der Kyro Filtertechnisch nicht anders wie eine Voodoo5.

nggalai

2001-10-02, 15:51:19

Da nicht alle Texturen gefiltert werden (Lightmaps z.B.) hält sich der Performancehit bei triliear in Grenzen; hier werden für trilineare Texturen 2 Pass berücksichtigt. Benutzt man allerding Anisotropic, werden gleich 4 Pass in anspruch genommen! Das ist dann, als hätte man 4 übereinanderliegende bilinear gefilterte Texturen - und das überall! So ist es nicht verwunderlich, dass der Kyro, abhängig von der Texturgrösse der Textur, die gefiltert wird, die Hälfte bis 2/3 an Performance verliert.

und ...

Dank der Tilerarchitektur ist es sogar durchaus möglich effizientes RGSS oder sogar ein HardwareFSAA oder Hardware Anisotropic Filtering zu implementieren, da sich das Rendern eben auf die Tiles beschränkt und nicht abhängig von der Auflösung ist. Zudem brauchen diese Operationen keinen enzigen zusätzlichen Speicherzugriff!!!Mal abgesehen von den drei AUsrufezeichen ... was gilt denn nun? "Kein einziger zusätzlicher Speicherzugriff" oder "trilinear = 2 pass, anisotrop = 4 pass"?

Bitte, fühl dich nicht angegriffen. Ich versuche lediglich, deiner Argumentation zum Thema Tilern zu folgen.

ta,
.rb

HOT

2001-10-02, 16:02:14

Texturmenge <= 8 (Pass) = 0 Speicherzugriffe aber auch <= 8 Takte. Der Kyro kann 8 Texturen in einem Pass, also ohne Speicherzugriff. Erst, wenn diese Grenze (die übrigens von Microsoft in DX7/8 festgelegt wurde) macht der Kyro einen Speicherzugriff. Während der 8 Passes speichert der Kyro in einem internen Buffer.
Somit gibt es weder Bandbreitenverschwendung durch Filtern noch durch FSAA ;)

HOT

2001-10-02, 16:03:41

PS, ich bin doch nicht beleidigt, ich freu mich über jede Diskussion :D
Es macht einfach nur Spass :D

nggalai

2001-10-02, 16:14:58

Texturmenge <= 8 (Pass) = 0 Speicherzugriffe aber auch <= 8 Takte.Also, für dich ist eine Textur ein Pass, 8 Texturen 8 passes?Der Kyro kann 8 Texturen in einem Pass, also ohne Speicherzugriff.Ah, doch ned. Sondern 1 pass = 1 Speicherzugriff, 8 Texturen in einem pass?Erst, wenn diese Grenze (die übrigens von Microsoft in DX7/8 festgelegt wurde) macht der Kyro einen Speicherzugriff.Microsoft gibt nur die min. Anzahl Texturen pro pass an, um die "compliance" zu D3D zu vergeben--für DX8.1 wären das 6 Texturen pro pass.Während der 8 Passes speichert der Kyro in einem internen Buffer.Hä? Jetzt also doch wieder 8 passes? Kann die Kyro also 64 Texturen im Chip-Cache halten? ???Somit gibt es weder Bandbreitenverschwendung durch Filtern noch durch FSAA. ;)Wegen eines internen Textur-Buffers gibt's keine Bandbreitenverschwendung--ACK. Das ist aber auch bei der GF3 / R8500 so (obwohl brute-force renderer).

Sorry, ich kann dir noch immer nicht ganz folgen--was ist ein "pass" für dich? Ein Speicherzugriff? Eine gehandelte Textur?

ta,
-rb

HOT

2001-10-02, 16:43:04

Ahhh, jetzt erkenn ich dein Problem :D Vielleicht sollte ich mal besser darauf aufpassen, was ich da schreibe ;)
Das ist natürlich falsch formuliert gewesen von mir. Als Pass sind meines Wissens die maximale Texturmenge bezeichnet, die ohne separaten Speicherzugriff bearbeitet werden kann. Der Geforce2 kann 2 Texturen pro Pass berechnen. Das heisst, er kann zwar 4 Texturen auf einem Polygon berechnen, aber nur in 2 Passes, macht also einen zusätzlichen Speicherzugriff. Bei 8 Texturschichten wären das also 4 Passes ;) Der Geforce kann die 4 Passes allerdings in einem Taktzykus Rechnen und muss dann darauf warten, bis die gerenderten Pixel in den Speicher geschrieben werden können. Wenn man mal darüber nachdenkt, bei G2 muss ja ein verdammter Verkehr auf dem Bus sein :D
Ok, Der Geforce3 sowie der Savage2000 können also 4 Texturen in einem Pass bearbeiten, das Ganze in 2 Takten. Der G3 das Ganze sogar 4x. Somit braucht der Geforce3 für 4x4 Texuren (2x8 Schichten) 4 Passes bzw. 2 Takte. Also für 8 Texturelayer 2 Passes. Der Savage2000 schafft die 8 Texturschichten auch in 2 Passes, also 2 Speicherzugriffe.
BeimKyro siehts jetzt volgendermassen aus:
Der Kyro schafft 8 Texturschichten in einem Pass, d.h. ohne weitere Speicherzugriffe.
So jetzt die Überleitung zum eigentlichen Thema :D
Da der Kyro keine Hardwareunterstützung zum Filtern besitzt, muss die Textur bei trilinear Filtering 2x durch die TMU. So. Da das ganze innerhalb der 8 texturlagen passiert, braucht der Kyro NUR EINEN PASS, allerdings 2 Takte dafür. Wird noch eine Lightmap mitgerendert, wird die soweit ich weiss mit dazu gerendert. 1 Trilinear gefilterter Texel+Lighmap braucht also 3 Takte, aber passiert in einem Pass. Bei anisotropic Filtering (16Tap) benötigt der Kyro für eine solche Textur 4x die TMU. D.h. also, dass die Textur+Lightmap 5 Takte in der TMU verbingt, aber das alles in einem Pass, also ohne zusätzliche Speicherzugriffe.
Ich hoffe, jetzt ist der Performanceeinbruch geklärt.
Bei Geforce Karten können soweit ich weiss das trilineare Filtern auch keine weiteren Speicherzugriffe und kann 1 Trilinear gefilterten Texel + Lightmap trotz seiner Beschränkung in einem Pass, dann aber in 2 Takten bearbeiten. Da der Geforce sowieso die meiste Zeit auf seinen Speicher wartet, merkt man bei trilinearer Filterung keinen oder einen nur sehr geringen Performanceeinbruch. (bin mir bei Geforce aber nicht 100%ig sicher)

nggalai

2001-10-02, 16:54:45

Aaah, danke. JETZT kann ich dir folgen. :)

Wie schon gesagt, mir ist vollkommen klar, woher der Kyro-Performanceeinbruch kommt--meine Ausführungen übers Textur-Filtern mit Tilern waren theoretischer Natur und nicht Kyro-Spezifisch (und gehören wohl eher ins Techno-Forum). Ich war nur verwirrt, wie Du "Pass", "Takt" und "Kyro" sowie "Tiler" verwendet hast. Aber jetzt sind wir ja die Begriffsverwirrung los. ;)

Woran ich mich ursprünglich gestossen habe war eigentlich einfach nur deine Aussage, dass ein TILER durch seine Technik bevorzugt anisotropisches Filtering ohne Extra-Pass erledigen kann.

Hier also nochmals meine Frage: WIE kann ein Tiler Textur-Filterung unterstützen? Die von dir geschilderten Vorteile können von jeder Multipass Texture Pipeline gesagt werden, ned nur von Tilern--sondern eben auch von GF3, Radeon, und zu geringerem Masse auch GF1/GF2.

ta,
.rb