Zum T&L Artikel

[ow]

.

[007]

Meint ihr nicht das zwei Threads langen, mittlerweile sinds 6 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[ow]

.

[Korak]

@ Ow

Bei den meisten Punkten muss ich zustimmen bei wenigen nicht.

@007

Jo hab auch kein Bock mehr. :)

Mehr Kommentare geb ich nich ab. Ich kan T&L nicht mehr hören. :)

[007]

na ja..., wenns ihrs übertreibt räumen wir einfach mal das ganze OffTopic ! *fg*

[Thowe]

Originally posted by Korak


Mehr Kommentare geb ich nich ab. Ich kan T&L nicht mehr hören. :)

Ach was, denke du meinst das fruchtlose Diskutieren über etwas was durchaus sinnig ist, aber z.Z. in der Spielerealität nicht bzw. kaum zum tragen kommt.

[Unregistered]

Originally posted by ow
[B]Was soll dieser Vergleich??? Ist ja wohl lachhaft, eine MX200 heranzuziehen.[i]

Wieso? MX200 wird von einigen Kartenherstellern als Gamer-Produkt produziert und beworben.


Seit wann ist die DX7 SW T&L denn frei programmierbar?


Er meinte Software T&L generell. Das ist seit dem i8086 frei programmierbar.


LOL, ich spiele selbst auf der Riva TNT in 32Bit,


Lustig. Unreal 800x600 bei 32bit: 10.7 fps

Was hat denn der Geometrieteil (T&L) mit dem Rasterizer zu tun?? NICHTS, absolut NICHTS. Beide arbeiten unabhängig voneinander.

Nicht ganz, sie teilen sich das Speicherinterface.


In welchen Spielen, ausgenommen der proprietäre Glide-Mist, ist die V5 schneller als der GTS?? Echter Sprung in der

Warum ausgenommen Glide? Ein Realitätsproblem?


Die MX ist zumeist auch in 32Bit schneller als eine Kyro1.

Das stimmt nicht. Eine KYRO1 ist in 32 bit fast immer schneller als eine MX, 3Dmark ausgenommen.


Und die 16Bit Qualität der MX kann sich ohne weiteres mit den 16Bit der Voodoos messen.


Das stimmt auch nicht, denn die MX hat keinen 22bit Filter. Den Unterschied ist enorm, als ehemaliger Besitzer einer V3, zwischendurch MX und nun Kyro2 kann ich bestätigen, dass MX in 16bit die schlechteste Grafik bietet.

[GAMaus]

hab ich mich dann mit dem Kauf einer GF2 MX selbst beschissen? (allen ernstes)

Da ich sowieso nur Everquest Spiele, waere ich dann mit einer Kyro II besser bedient?

Oh Mann!
Da bin ich schon wieder verunsichert !! :P

[StefanV]

@ow

Ich muß dir (jetzt) zustimmen...

Theoretisch gesehen ist der Artikel von fehlern übersät...

Nunja, das T&L in Heutigen Spielen kaum eingesetzt wird liegt wohl daran, weil:

1. Spiele brauchen ca. 2-3 Jahre (für ein 'durchsnitts' Spiel).
2. Teilweise erkauft man sich das mit weniger Flexiblität.


Genug davon.

PS: Ich halte es für sinniger, wenn ein 3D Beschleuniger einfach 'nur' eine Spezielle CPU wäre, die diese ganzen aufgaben berechnet...

ES gab da mal einen Ansatz, der leider nur von einem Hersteller verfolgt wurde...

Gerüchte zu folge soll Matrox auch eine 'mini CPU' in ihre Chips integriert haben, die nicht besonders schnell sind...

[ow]

.

[aths]

ow:

> mehr Arbeit hierin zu investieren lohnt eh nicht.

Ist in der Tat reichlich lau, was hier von dir kommt.

> "[Einleitung]"
> Was soll dieser Vergleich Ist ja wohl lachhaft, eine MX200 heranzuziehen.
> Das die T&L nicht für den 200MX entwickelt wurde ist doch wohl klar, oder?

1.) Warum ist das "klar"? 2.) Wenn T&L hier eh nichts bringt, hätte nVidia auf die entsprechenden Transistoren verzichten können um so den Preis des Chips zu senken.

> Hättest die 400MX nehmen sollen, aber dann zieht dein Argument ja schon nicht mehr.

Um die Unterschiede T&L vs. Speicherbandbreite zu zeigen, kann man hier keine 400-er nehmen.

> Mit diesem 'Einstieg' ist ja die Aussage des Artikels schon festgelegt.

Mag daran liegen, dass der Teil zum Schluss geschrieben wurde.

> "Denn der Vorteil einer Software-T&L-Engine liegt in der freien Programmierbarkeit."
> Seit wann ist die DX7 SW T&L denn frei programmierbar?

Rede ich da von DX7 SW T&L? -> Nein, also leg mir bitte nicht Dinge in den Mund die ich nicht gesagt habe.

> "Nun, ehe man die Polygonzahl erhöht, sollte man zunächst sicher stellen, dass die Spiele in 32 Bit keine drastischen Einbrüche mehr erleiden. Hier hat - CPU-Limitierung vernachlässigt - jede GeForce immer noch zu kämpfen"
> LOL, ich spiele selbst auf der Riva TNT in 32Bit, Performanceeinbrüche bei 32Bit gg. 16 Bit sind NORMAL, es sollten sich die anderen Hersteller mal um ihre 16Bit Implementierung sorgen, denn wo die NV Chips Leistungsreserven haben, gibt´s es dort KEINE.

TNT mit 32 Bit? Entweder hast du eine recht langsame CPU oder du magst keine flüssige Grafik. Bei Brute-Force-Karten ist der Einbruch "normal", als Ausnahme ist die Radeon zu nennen. Da erhöhte Polygonzahl auch die Bandbreiten-Erfordernisse erhöht (und nebenbei den dreiecksbasierten Overdraw, mehr dazu im Nachtrag den ich vorbereite) führen zu viele Polys bei 32 Bit eh zu Einbrüchen. Da das so ist, wozu dann noch T&L? Es mag heute, vorallem bei 16 Bit, noch Vorteile bringen, in Zukunft werden 32 Bit bei hohen Auflösungen eher verwendet, als heute. Wenn die Karten für diese Anfordernisse ausgelegt sind, dann ist auch T&L sinnvoll - sofern sie programmierbar ist.

> "Kurz, die Rendereinheit ist gar nicht auf extreme Polygonzahlen ausgelegt"
> Was hat denn der Geometrieteil (T&L) mit dem Rasterizer zu tun?? NICHTS, absolut NICHTS. Beide arbeiten unabhängig voneinander.

Beide Teile sollten harmonieren. Ist eine Einheit permanent überdimensioniert, kostet das den Endkunden nur Geld.

> "Wenn der Prozessor zum Beispiel 3 Millionen Eckpunkte in einer Sekunde liefert, kann die Karte auch nur diese 3 Millionen transformieren."
> Eben, und wenn die CPU diese 3 Mio. Dreiecke auch noch transformieren soll, dann kann sie diese Zahl eben NICHT an die Graka liefern.

Dass auch DX7 T&L die Polygonleistung steigern *kann*, wurde nirgendwo abgestritten.

> Wie kommst du überhaupt auf 3 Mio.??

Mir war gerade so.

> "Auf jeden Fall transformiert ein 1200er Athlon schneller als eine mit 120 MHz laufenden T&L-Einheit einer GeForce 256."
> HAHAHAHAHA, eindeutig der beste Witz diese Artikels.
> Es muss heissen: [blabla]

Eine GeForce kann selbst nicht ihre eigenen T&L-Polygonmengen verarbeiten. Hier rede ich von "Real-World"-Umgebung bei 1024x768x32 (= allgmein akteptierte Standard-Einstellung). Ich rede nicht von synthetische Tests, die mir als Gamer NICHTS bringen.

Vergleichen wir mal die pure Transformation: T&L bringt hier bei 120 MHz bis zu 14 Mio Dreiecke. Das sind 8,5 Takte pro Eckpunkt. Der Athlon läuft mit 1200 MHz und darf deshalb 85 Takte verbraten. Ausserdem hat er 3dnow! und kann daher bis zu vier Operationen aus der Menge {+, -, *} gleichzeitg ausführen.

> "[Marketinglüge]"
> Merke: theoretische Specs sind IMMER 'Fantasizahlen', weil sie in der Praxis NIE erreicht werden, egal welcher Chip.

20 Millionen Dreiecke zu sagen und 20 Millionen Eckpunkte zu meinen ist dreist. Denn die T&L-Einheit transformiert ja in der Tat Vertex-Daten. Entsprechend sollte auch die Angabe sein.

> Also sind alle Specs eines Chips sinnlos??

Der Kyro kann seine Füllrate nachweislich ausspielen. -> Von wegen "immer Fantasiezahlen".

> "Es wäre also richtiger, erst FSAA und dann T&L einzuführen. nVidia konterte später mit FSAA für ihre Produkte"
> Wen interessiert das FSAA, wenn ich dafür auf niedrige Auflösung zurückschrauben muss?

Bei 786 Zeilen kann der Monitor mit mehr Hz laufen als bei 1200 Zeilen. 768 Zeilen mit 2x FSAA á la T-Buffer sieht nicht nur besser als die 1200-Zeilen-Version ohne FSAA aus, sondern ist auch noch schneller. -> Also mich interessiert FSAA. Bei diesem genannten Beispiel steigen Qualität und Framerate *gleichzeitig*, dazu kann der Monitor in ergonomischeren Auflösungen betrieben werden. Ist doch eine tolle Sache, oder?

> Desweiteren: wieviele Polygone in einer Szene sind denn wirklich 'sichtbare' Kanten, die geglättet werden müssen?? 5%? 10%?

Ich fürchte, du hast vernünftiges FSAA noch nicht in Aktion erlebt.

> "[Reviews GTS vs V5]"
> In welchen Spielen, ausgenommen der proprietäre Glide-Mist, ist die V5 schneller als der GTS??

Zunächst ist Glide kein Mist, wenn auch propritär. Es wurde ausserdem, du kannst doch lesen?, die Frage ob höhere Geschwindigkeit oder bessere Qualität zählt, gestellt. Was du bemeckerst ist selten das, was im Artikel steht. Übrigens, wenn die GTS vergleichbare FSAA-Qualität wie eine V5 bringen soll, ist sie deutlich langsamer als die Voodoo. Es steht ausser Frage, dass AA in Zukunft an Bedeutung eher gewinnt denn verliert, während der Nutzen von DX7 T&L eher abnimmt.

> Echter Sprung in der Grafikqualität? Wo ist denn EMBM, DOT3, Matrix Skinning, Cube Mapping bei der V5??

Interessante Frage. Bump Mapping muss allerdings explizit unterstürt werden. Es stand im Artikel ausdrücklich "oder einem echten Sprung in der Grafik-Qualität bei allen 3D-Spielen". Das "alle" wirst du doch nicht überlesen haben? Übrigens kann auch die GeForce2 kein EMBM.

> Das AA ist doch nur für alte Spiele sinnvoll nutzbar wegen der dürftigen Leistung einer V5.

Hm, die Leistung einer Karte mit 5,3 GB/s Bandbreite und effektiverer Renderstruktur als GTS nennst du dürftig. Du hast ja voll Ahnung. In anderen Postings stutzt du Leute zurecht und tust so, als seist du voller Wissen, das die anderen eh nicht verstehen. Und offenbarst doch immer wieder eine weit reichende technische Ahnungslosigkeit. Schade.

> Die MX ist zumeist auch in 32Bit schneller als eine Kyro1.

In niedrigeren Auflösungen, ja. Da hohe Auflösungen in Zukunft an Bedeutung gewinnen, ist die Kyro1 - trotz deutlich niedrigeren Preises, trotz "fehlendem" T&L, zukunftssicherer als eine MX. Zumal die Kyro EMBM und 8-fach Multitexturing beherrscht.

> Und die 16Bit Qualität der MX kann sich ohne weiteres mit den 16Bit der Voodoos messen.

Die 16-Bit-Qualität einer Voodoo (vorallem ab Voodoo3) ist sichtlich besser als die einer MX. Übrigens wird das Bild nicht einfach weich gezeichnet, du scheinst die Funktionsweise des Filters nicht richtig zu kennen. Ich habe mit eigenen Augen die 3dmark2001-Demo in 16 Bit je auf einer MX und einer VSA-100-Karte gesehen. Letztere bietet schlicht das bessere Bild.

> So... genug jetzt

Und dafür hast du eine Woche gebraucht?

> Warum wird eigentlich Ati nicht erwähnt in dem Artikel??
> Oder heisst es da: Die haben nur wegen NV eine T&L in den Radeon implementiert??

ATI wird erwähnt, und zwar in Bezug auf HyperZ. Die Radeon T&L ist meines Wissens deutlich fortschrittlicher als die einer GeForce GTS.

> Oder der Savage2000 (wenn auch etwas misslungen, die T&L).

Ich wüsste nicht, dass die jemals zum Einsatz kam. S3 drückte S3TC durch, und S3TC ist die einzige Effizienz steigernde Maßnahme des GF256 im Vergleich zur TNT2.

[Ceiser Söze]

Zum Thema 16bit-Bildqualität von Voodoo vs. Kyro vs. GeForce(MX):
http://www.within3d.de/index.php?show=kyro2test&site=4
Ich glaube, der "Sieger" steht hier eindeutig fest und wer hier noch behauptet, das 16bit von nVidia sehe besser als das 16bit von 3dfx oder PowerVR aus, braucht definitiv eine Brille...

Und um dem Ganzen noch einen draufzusetzen, hier ein Screenshot aus Wheel of Time, den ich vor langer Zeit mal mit meiner TNT2 gemacht habe. Ihhhh, Dithering...

@ow: Ich wage hier übrigens ernsthaft in Frage zu stellen, ob du mal echtes RotatedGrid-SuperSampling und den 22bit-Postfilter der Voodoo5 (ist ein Tick besser als der auf der Voodoo3) in Aktion gesehen hast...

[nggalai]

Bitte nicht persönlich nehmen, ok?

Um die Unterschiede T&L vs. Speicherbandbreite zu zeigen, kann man hier keine 400-er nehmen. Erf? Weshalb denn das? Etwa, weil bedeutend mehr Anwender MX400 oder MX Classic besitzen als MX200? Oder weil die 400er die doppelte Speicherbandbreite der 200er hat, und daher mit der V4 gleichzieht?

Rede ich da von DX7 SW T&L? -> Nein, also leg mir bitte nicht Dinge in den Mund die ich nicht gesagt habe. Dein ganzer Artikel (mit dem ich, wie schonmal gesagt, im grossen-ganzen einverstanden bin) geht doch um Marketingversprechen über DX7-style TnL (also hardwired TnL), nicht?

TNT mit 32 Bit? Entweder hast du eine recht langsame CPU oder du magst keine flüssige Grafik. Bei Brute-Force-Karten ist der Einbruch "normal", als Ausnahme ist die Radeon zu nennen. Diese Einbrüche währen auch bei TBR normal. Bei der Kyro zieht das nicht, da sie intern eh mit 32bit rechnet, also in ows Perspektive nicht von einem schnelleren 16bit Modus profitiert. Und dass die Radeon nicht so stark einbricht liegt einfach daran, dass ihr Design auch schon bei 16bit limitiert i.e. es wird nichtmehr viel "schlimmer", mit 32bit. Das ist übrigens die Erklärung, die ich von einem ATi Techniker bekam und nicht auf meinen eigenen Mist gewachsen. Abgesehen davon, eine GF2 Pro oder gar GF3 bricht auch nichtmehr so krass ein.

Da erhöhte Polygonzahl auch die Bandbreiten-Erfordernisse erhöht (und nebenbei den dreiecksbasierten Overdraw, mehr dazu im Nachtrag den ich vorbereite) führen zu viele Polys bei 32 Bit eh zu Einbrüchen. Da das so ist, wozu dann noch T&L? Es mag heute, vorallem bei 16 Bit, noch Vorteile bringen, in Zukunft werden 32 Bit bei hohen Auflösungen eher verwendet, als heute. Wenn die Karten für diese Anfordernisse ausgelegt sind, dann ist auch T&L sinnvoll - sofern sie programmierbar ist. [my emphasis] Oh, schaut mal her--ein Zirkelschluss. :) Weshalb soll TnL nur dann sinnvoll sein--falls die Karte auf 32bit/hohe Auflösungen ausgelegt ist--wenn die Unit programmierbar ist? Reduzieren sich dann "die Bandbreiten-Erfordernisse?" Mit dieser Aussage beweist Du dein Argument mit den Schluss, zu dem Du kommen willst.

Eine GeForce kann selbst nicht ihre eigenen T&L-Polygonmengen verarbeiten. Hier rede ich von "Real-World"-Umgebung bei 1024x768x32 (= allgmein akteptierte Standard-Einstellung). Ich rede nicht von synthetische Tests, die mir als Gamer NICHTS bringen. Also verstehe ich dich richtig, wenn ich die Aussage dieses Absatzes (und der korrespondierenden Teile deines Artikels) so paraphrasiere?

"DX7-style TnL kann nur deshalb von einer schnellen CPU gleichschnell wie von einer dedizierten GPU ausgeführt werden, weil die gegenwärtigen Spiele nicht genug Polygone aufweisen, als dass die GPU glänzen könnte--daher wird die DX7-style TnL Einheit auch in Zukunft nix bringen."

Falls ich dich so richtig verstanden habe, hat's da nämlich nochmals einen klassischen Fehlschluss drin.

Vergleichen wir mal die pure Transformation: T&L bringt hier bei 120 MHz bis zu 14 Mio Dreiecke. Das sind 8,5 Takte pro Eckpunkt. Der Athlon läuft mit 1200 MHz und darf deshalb 85 Takte verbraten. Ausserdem hat er 3dnow! und kann daher bis zu vier Operationen aus der Menge {+, -, *} gleichzeitg ausführen.

Die TnL Unit hat auch pipelining und caches ... aber OK, in dem Fall hier ein Praxisbeispiel ausm Serious Sam Forum zum Thema hardwired TnL in OpenGL (von einem Programmierer, der meine eigene Argumentation gegen hardwired-TnL kommentierte):

"I wrote a little benchmarking program in OpenGL. It sets up a sphere with a single directional light, lots and lots of polygons on the screen. The only thing being done is drawing the sphere -- no AI, no sound processing, no physics engine with collision detection, etc. My CPU (Pentium III 550) can pull off about 1.6 million triangles per second running the benchmark.

My ex-girlfriend's GeForce 256 can pull off 12 million triangles per second.

There's quite a huge difference there, and if you account for the fact that in a game, the CPU has to perform all the other tasks mentioned above like physics and AI, it doesn't leave a lot of headroom. The point is, allowing the CPU to do less work is a good thing, and a well-written graphics engine can do exactly that if it makes good use of hardware T&L.

I just remembered one of your original points was about lighting not being done on the graphics card, and I had written another benchmark that only used constant colors without lighting. It maxed out at 2.6 Mtris/sec on my machine. That benchmark didn't use enough triangles to fully stress a T&L card, I think it acheived up to 7 Mtris on the GF256, which was rising proportionally with the number of triangles on screen.

Neither benchmark used VARs which would've gotten even higher performance on GeForce cards."

Ich denke, wir sind uns einig das im theoretischen Fall eine HW TnL Engine auch einem 2GHz Athlon überlegen wäre, aber dass das in der Praxis (noch?) nicht der Fall ist. Meiner Meinung nach ist der einzige Grund, weshalb wir nicht mehr Spiele mit sauberer TnL Unterstützung haben, das Fehlen von TnL Hardware auf der common user base, und nicht die Inflexibilität der Implementation. Ich habe bisher noch keine Spiele Engine gesehen, die nicht mit statischem TnL umgesetzt hätte werden können. Aber eben, Spieleprogrammierer wollen halt auch Geld machen und ihre Produkte aufm kleinsten gemeinsamen Nenner sauber laufen sehen, nicht nur auf hardware TnL Systemen.

Der Kyro kann seine Füllrate nachweislich ausspielen. -> Von wegen "immer Fantasiezahlen". Die Kyro kann ihre Füllrate auch nicht zu 100% ausspielen, in der Praxis. :)

Bei 786 Zeilen kann der Monitor mit mehr Hz laufen als bei 1200 Zeilen. 768 Zeilen mit 2x FSAA á la T-Buffer sieht nicht nur besser als die 1200-Zeilen-Version ohne FSAA aus, sondern ist auch noch schneller. ACK zum besser Aussehen, aber aus anderen Gründen (i.e. ich bevorzuge FSAA eh :) ). Wenn dein Monitor Mühe hat, bei 1200 Zeilen nicht auch mit mindestens 85Hz zu fahren, dann solltest Du diese Auflösung eh vergessen. Und "ist auch noch schneller" kann ich als Sometime-V5 user nicht bestätigen. (Bei 800x600 stimmt's wieder.)

Ich hatte mit deinem Artikel eigentlich weniger mit den FSAA Ausführungen selbst als eher damit ein Problem, dass Du von einer wirklich gelungenen TnL-Marketinglüge-Analyse plötzlich zu FSAA rüberwechselst, nachm Motto "aber DAS bringt was, qualitätsmässig, und nVidia ist da nur aufgesprungen." Ist ja schön, dass das qualitätsmässig was bringt, hat aber in einem TnL Artikel nichts verloren.

> Desweiteren: wieviele Polygone in einer Szene sind denn wirklich 'sichtbare' Kanten, die geglättet werden müssen?? 5%? 10%?

Ich fürchte, du hast vernünftiges FSAA noch nicht in Aktion erlebt. Wie schliesst Du das aus dieser Aussage? Nur weil ow nicht Textur/Pixelflimmern erwähnt hat?

Hm, die Leistung einer Karte mit 5,3 GB/s Bandbreite und effektiverer Renderstruktur als GTS nennst du dürftig. Was verstehst Du unter "effektiverer Renderstruktur?"

Die 16-Bit-Qualität einer Voodoo (vorallem ab Voodoo3) ist sichtlich besser als die einer MX. Das kann ich definitiv nicht bestätigen. Ich hab' extra nochmals meine V3 rausgekramt, und die 16bit Qualität hatte eine stark verwaschene Komponente. Mir gefällt das 16bit meiner Kyro immernoch am besten. :)

ATI wird erwähnt, und zwar in Bezug auf HyperZ. Die Radeon T&L ist meines Wissens deutlich fortschrittlicher als die einer GeForce GTS. Nö, ist praktisch identisch aufgebaut, und dazu noch langsamer als bei der GTS, was aber eher am Chiptakt hängt als an der Implementierung.

Weshalb haben wir hier schonwieder einen neuen Thread?

tata,
.rb

[Thowe]

Originally posted by nggalai

Weshalb haben wir hier schonwieder einen neuen Thread?

tata,
.rb

Hatte ow oben erwähnt, die anderen waren ihm schon zu lang. Mir in übrigem auch, da die Übersichtlichkeit gegen Null ging.

Ansonsten könnten man sich ja mal vielleicht darauf einigen was die wichtigsten und vor allem echten Streitpunkte im einzelnen sind.

Diese könnte man dann einzeln, ausführlich und sachlich im Technologie Forum abhandeln. Ansonsten dient die Länge der einzelnen Postings wirklich nicht der Übersichtlichkeit.

[StefanV]

Nochmal zum T&L der Radeon:

Ist es eigentlich möglich, daß ATI in diesem Fall eine langsamere Version der T&L Einheit gewählt hat, die man aber mit einem VS Kombinieren kann??

Die T&L der R1 ist ja schließlich ein 'halber' VS...

[Legolas]

Originally posted by nggalai

ACK zum besser Aussehen, aber aus anderen Gründen (i.e. ich bevorzuge FSAA eh :) ). Wenn dein Monitor Mühe hat, bei 1200 Zeilen nicht auch mit mindestens 85Hz zu fahren, dann solltest Du diese Auflösung eh vergessen. Und "ist auch noch schneller" kann ich als Sometime-V5 user nicht bestätigen. (Bei 800x600 stimmt's wieder.)



Also aths vergleicht hier 1024*768@2xFSAA mit 1600*1200, wenn ich das richtig verstehe. Und erstgenannteres ist sicher schneller, als das zweite.
Folgende kleine Rechnung zeigt das:

Bei 2xFSAA wird die doppelte Anzahl von Pixeln berechnte, wie ohne AA. Um nun die durch das AA erreichte 'virtuelle' Auflösung zu berechnen, muss man einfach die Ursprungsauflösung (Hier 1024*768) mit SQR(2) multiplizieren. So kommt man in diesem Beispiel auf eine 'virtuelle' Auflösung von ca. 1450x1090. Und das ist niedriger wie 1600x1200, also auch schneller.

[ow]

.

[Ceiser Söze]

Originally posted by ow

Sehr guter Witz!!
Also bei einer angenommenen Auflösung von 1024x768 (rund 800.000 Pixel) rendert dein Kyro also in allen Games immer runde 200fps (175MPix/s geteilt durch 0.8Mpix). So ist das doch zu verstehen, oder nicht??


Du vergisst die zusätzlichen Füllratenanforderungen für Multitexturing (so ziemlich jedes Spiel nutzt z.Z. mindestens 2 Texturen pro Polygon: Lightmap und Basistextur), womit sich die Füllrate bereits halbiert (--> 100Fps). Dann kommt noch der transparente Overdraw hinzu, der die Framerate ebenfalls stark nach unten ziehen kann...

[StefanV]

@ow

Technisch gesehen hast du recht.

Der Artikel steckt voller Fehler, die mit einer Näheren Erklärung vermieden werden könnten.

Und die Sache mit der T&L Spezi ist nicht von der Hand zu weise, daß NV unberechtigterweise das als ECKPUNKTE angibt!

Dreiecke wären korrekter gewesen.

Jetzt noch eine andere Sache:

Bei NVidia wird DDR-SDRAM auch IMMER (bei der DDR-GF1 teilweise) als verdoppelter Takt angegeben, bei ATI NICHT.

Dadurch hat sich halt in den Köpfen der Leute halt der irrglaube festgesetzt, daß DDR-SDRAM DOPPELT so schnell wie SDR-SDRAM ist, was nunmal nicht stimmt...

200Mhz SDR SDRAM ist nunmal schneller als 100MHz DDR SDRAM.

BTW: Es wurde sich über die Bezeichnung des VIA KZ133 aufgeregt, aber NICHT über die Bezeichnung DDR...

@aths
ow hat recht, der Artikel hat SEHR viele Fehler (technisch gesehen).

Sei es nun schlechte Vergleiche, oder einfach 'nur', daß du vergessen hast es etwas näher zu erklären.

Im beispiel der MX-200 gegen VSA-100 hätte wohl ein weiterer Satz gereicht.

[ow]

.

[ow]

.

[Thowe]

Originally posted by ow


DDR müsste eigentlich DEBB (doppelte effektive Busbreite:)) heisen, weil bei 128Bit DDR zwischen zwei Adressierungszycklen eben 256 Bit gelesen/geschrieben werden.
Man kann halt aber auch nicht von einem 256Bit Bus sprechen, da es nur 128 Datenleitungen gibt.




Guter Vorschlag wie wäre es mit email an die JEDEC (www.jedec.org)

am besten email hierhin -> arnaudl@eia.org

[StefanV]

Also man sollte eigentlich mal einen Artikel darüber schreiben, wie in Letzter Zeit die Leute verdummt werden...

[Unregistered]

"My ex-girlfriend's GeForce 256 can pull off 12 million triangles per second. "

Lustige Behauptung, das schafft nicht einmal nvidia mit eigenen Benchmarktools :)

[Unregistered]

Originally posted by ow
Man muss den Chip in der Umgebung messen, die zu seinem Erscheinen aktuell war. Und da gibt es praktisch keine Performanceverlust zwischen 16 u. 32 Bit.[/B]

Beweis durch Behauptung?

http://www.arstechnica.com/reviews/1q99/tnt-massive1-98.gif
http://www.arstechnica.com/reviews/1q99/tnt-unreal-98.gif

LOL! 17 fps bei Unreal 1 bei 640x480 (!) und 32bit.

[Kai]

Originally posted by Stefan Payne
@ow

Technisch gesehen hast du recht.

Der Artikel steckt voller Fehler, die mit einer Näheren Erklärung vermieden werden könnten.

Und die Sache mit der T&L Spezi ist nicht von der Hand zu weise, daß NV unberechtigterweise das als ECKPUNKTE angibt!

Dreiecke wären korrekter gewesen.

Jetzt noch eine andere Sache:

Bei NVidia wird DDR-SDRAM auch IMMER (bei der DDR-GF1 teilweise) als verdoppelter Takt angegeben, bei ATI NICHT.



Da ihr hier ja immer wieder die Unfehlbarkeit von ATI rauf und runterorakelt - und Nvidia ach so böse Marketinglügen andichtet, möchte ich da jetzt aber mal zurückschlagen. Und kommt mir danach bloss nicht mit einem "Aber .... "

In diesem Zusammenhang kommen wir mal auf ATI's geniale Tru-Form Revolution zu sprechen. Da heisst es:

"TRUFORM" hat einen entscheidenten Vorteil gegenüber den RT-Patches, man muss die 3D-Modelle nicht verändern oder mit Splines / Kurven designen. Man kann ganz normale 3D-Modelle aus jedem Spiel nehmen und sie per N-Patch verfeinern.

Ich hab unten mal ein Bild angehängt, welches mich doch sehr belustigt hat ;) "Dieser Fehler zeigt deutlich, wo das Problem bei N-Patches liegt, nämlich bei der Verbindung zweier Flächen, die durch gemeinsame Eckpunkte, die selben Normalen benutzten."

Dann noch eine Rüge gegen ATI wegen des "Durchboxens" des Tru-Form Verfahrens. Erinnert mich stark an damalige Nvidia-Methoden, nur das Nvidia sich diesesmal an die DirectX8.0 Konform gehalten hat - und ATI ihren eigenen Kuchen backen.

"Es ist zwar lobenswert, dass Microsoft es geschafft hat, beide Verfahren in DirectX 8 zu integrieren (sind in OpenGL dank Extensions auch kein Problem), andererseits hat Microsoft es aber nicht fertig gebracht, beide Verfahren als Pflicht zu erklären, um als voll DirectX 8 kompatibel zu gelten. So hat ATi das eine und NVIDIA das andere Verfahren integriert. Ich bin der festen Ansicht, dass sich N-Patches leichter durchsetzten werden. Die RT-Patches werden erst breite Verwendung finden, wenn mehr Hersteller sie in ihre GPU's integrieren. Schade, hier geht der Vorwurf also direkt an ATi. Bleibt abzuwarten, wie es bei anderen Herstellern (BitBoys, ST MICRO) aussieht"

PS: Viele Passagen dieses Textes wurden aus einem Artikel von "Tommti-Systems" zitiert - siehe hier: http://www.tommti-systems.de/main-Dateien/reviews/highordersurfaces/highordersurfaces.html

[nggalai]

"My ex-girlfriend's GeForce 256 can pull off 12 million triangles per second. "

Lustige Behauptung, das schafft nicht einmal nvidia mit eigenen BenchmarktoolsDer Autor sprach von nicht-schatterten Dreiecken pro Sekunde. Ich hab' jetzt gerade keine GF256 hier, aber zum Vergleich: eine GF3 kommt selbst beim Treemark auf gute 2-3 Mio Dreiecke pro Sekunde. Diese 12Mio sind für plain triangles echt nicht zu hoch gegriffen (laut nVidia macht eine GTS 25Mio davon, pro Sekunde).

*schulterzuck* ist ja eh schnurz, da theoretisches Resultat. :)

EDIT: "nicht-schattiert" oben heisst: einen fixen Lichtvektor pro triangle -> eine Farbe pro triangle (also kein "L" von TnL). Ausserdem sollte ich noch darauf hinweisen, dass diese 12Mio nicht ausm Prospekt sind, sondern das Ergebnis des kleinen Programmes, das der Autor einmal aufm P-III 500MHz (1.6Mio) und dann auf der GeForce256 (12Mio) laufen lies. Zwar immernoch synthetisch, aber trotzdem aufschlussreich, was den transform-part der GF anbelangt.

ta,
.rb

[ow]

.

[Kai]

Originally posted by ow


CPU limitierte Engines wie die von Unreal, die sowieso zu den beschis.... Engines zählt was OpenGL u. D3D Umsetzung angeht, sind zum Testen von Grafikkarten UNGEEIGNET.

*zustimm* @ Ow ...

[StefanV]

Originally posted by ow
CPU limitierte Engines wie die von Unreal, die sowieso zu den beschis.... Engines zählt was OpenGL u. D3D Umsetzung angeht, sind zum Testen von Grafikkarten UNGEEIGNET.

WER weiß das nicht??

Von daher ist deine Aussage so falsch wie 2x2=8;)...

[Legolas]

Da aber ziemlich viele Spiele eben genau auf der Engine von Unreal basieren, ist es trotzdem zu rechtfertigen die Performance von verschiedenen Grafikkarten mit dieser Engine zu vergleichen...

Wenn man aber, wie in diesem Fall, den Unterschied zw. 16 und 32 bit testen will, dann ist ein CPU-limitierter Benchmark nicht sooo sinnvoll, es sei denn, man wählt eine hohe Auflösung, weil Unreal dann doch durch die Grafikkarte limitiert ist.

[nggalai]

Ein Benchmark, der auf eine Game-Engine zurückgreift, sagt dir genau eines über die Hardware aus: wie gut die Hardware mitm Benchmark zurechtkommt. Von daher bin ich mit Legolas einer Meinung--angesichts der vielen U(T) Titel macht's Sinn, wenn schon benchen dennschon auch mit Unreal.

Aber um Hardware-features und Leistungsfähigkeiten zwischen Karten separat zu vergleichen? Neeeeeeeeee.

ta,
.rb

[Unregistered]

Originally posted by nggalai
einmal aufm P-III 500MHz (1.6Mio) und dann auf der GeForce256 (12Mio) laufen lies. Zwar immernoch synthetisch, aber trotzdem aufschlussreich, was den transform-part der GF anbelangt.[/B]

Sein Programm hätte ich gern. Ich hab eine GF256 und nvidias eigenes optimiertes t&l programm ("to show peak performance of todays GPUs"), dort erreiche ich keine 12 Mio. Wenn der Junge wirklich besser ist als nvidia - Respekt! Aber wahrscheinlich ist es nur ein Angeber.

[Unregistered]

Originally posted by ow CPU limitierte Engines wie die von Unreal

Typisch -ow-, unfundierte Pauschalbehauptung ohne sich zu informieren.

Unter http://www.arstechnica.com/reviews/1q99/tnt-unreal-98.gif sieht man, dass selbige Grafikkarte unter 16bit 25 fps leistet und unter 32bit 17 fps.

-> -> -> NICHT CPU-limitiert <- <- <-

Will heissen, die Pauschalbehauptung von -ow- dass zwischen 16bit und 32bit beim TNT zur damaligen Zeit kein Unterschied bestand ist wiederlegt. V2 liefert übrigens 55.2 fps, soviel zum Thema CPU limitiert :)
Die anderen verlinkten Benchmarks (Quake 2) zeigen das Selbe 32bit war und ist auf dem TNT unspielbar.

[Thowe]

@unreg

Hmm, vielleicht hilft es Aussagen besser zu interpretieren.

[Unregistered]

Originally posted by Unregistered


Beweis durch Behauptung?

http://www.arstechnica.com/reviews/1q99/tnt-massive1-98.gif
http://www.arstechnica.com/reviews/1q99/tnt-unreal-98.gif

LOL! 17 fps bei Unreal 1 bei 640x480 (!) und 32bit.

aah.. ich hatte eine RivaTNT 1 (auf einem Pii 400) und spielte lange Unreal 1 auf 800x600x32 (z.T. auf 1024x768) und war ruckelfrei?!? (und ich empfinde schon 20-25 FPS als ruckelig)

[Legolas]

Originally posted by Unregistered


aah.. ich hatte eine RivaTNT 1 (auf einem Pii 400) und spielte lange Unreal 1 auf 800x600x32 (z.T. auf 1024x768) und war ruckelfrei?!? (und ich empfinde schon 20-25 FPS als ruckelig)


Wie hast du das hinbekommen?? Ich hatte denselben Rechner, nur daß es im Singleplayer mit einer VooDoo1 besser gelaufen ist.. halt nur in 640x480... aber mit einer TNT.... was hattest du denn im Timedemo, damals?

[aths]

nggalai: Ich beschränke mich bei der Antwort mal überwiegend auf Dinge, die was mit T&L zu tun haben.

> Bitte nicht persönlich nehmen, ok?

Auf keinen Fall, hehe, ist es doch das erste mal, dass ich vernünftige Argumente lese.

> "[Warum MX-200?]"

Es geht hier um T&L vs. Speicherbandbreite. Also musste mit einer Karte verglichen werden, die zwar T&L, aber weniger Speicherbandbreite hat. Es ging darum, dass die meisten Käufer das Feature T&L kennen, aber Speicherbandbreite nur wenigen was sagt. Ich ging von einem eher durchschnittlichen Leser aus, wer sich in der Materie auskennt, erfährt in der Einleitung wirklich nichts neues oder gar aufregendes.

> "Rede ich da von DX7 SW T&L? -> Nein, also leg mir bitte nicht Dinge in den Mund die ich nicht gesagt habe."
> Dein ganzer Artikel (mit dem ich, wie schonmal gesagt, im grossen-ganzen einverstanden bin) geht doch um Marketingversprechen über DX7-style TnL (also hardwired TnL), nicht?

Ein Nachteil dieser DX7-T&L ist, dass sie im Gegensatz zu herkömmlicher SW T&L nicht programmierbar ist. Im Prinzip wurde der Vorwurf gemacht, dass DX7 T&L aus bestimmter Sicht ein Rückschritt war.


Beim Radeon hast du natürlich recht, das Ding ist bei 16 Bit rein füllratenlimitiert. Eine GF2 Pro mag deshalb weniger einbrechen, weil die CPU noch limitiert. Sie ist genauso unausgewogen wie eine normale GTS. (Wenn ich mich jetzt nicht irre, die Pro läuft doch mit 200/200?)

> "[Erst Bandbreite, dann T&L]"
> Oh, schaut mal her--ein Zirkelschluss. Weshalb soll TnL nur dann sinnvoll sein--falls die Karte auf 32bit/hohe Auflösungen ausgelegt ist--wenn die Unit programmierbar ist? Reduzieren sich dann "die Bandbreiten-Erfordernisse?" Mit dieser Aussage beweist Du dein Argument mit den Schluss, zu dem Du kommen willst.

Es geht im Artikel um die Praxistauglichkeit von T&L. Die wäre viel höher, wären a) die Bandbreiten dafür geschaffen und b) wäre die T&L programmierbar. Die Bandbreiten-Erfordernisse würden sich bei Geometriekompression reduzieren. Wenn sie schon nicht reduziert werden, sollte meines Erachtens genügend zur Verfügung stehen. Es sieht aber so aus, dass selbst bei geringer Polygonzahl, aber 32 Bit, die Bandbreite in der GF1/2 limitiert. Der Schluss, zu dem ich angesichts der GF1/2-Hardware komme ist, dass T&L gar keinen signifikanten Qualitätsschub bringen KANN.

Würde man mit erhöhter Polygonzahl die Details der Objekte hochschrauben, schlägt das Gesetz des abnehmenden Ertrages zu. Würde zusätzliche Polygone jedoch eingesetzt, um neue Objekte darzustellen, schlägt der dreiecksbasierte Overdraw zu. Das wird im Nachtrag noch etwas detaillierter ausgeführt. T&L hin oder her - damit allein kann uns nicht, wie aber versprochen, der grosse Schub in Dingen Detailreichtum gebracht werden.

Selbst wenn man mit T&L viel mehr Polygone darstellen kann, man aber mit starrer Geometrie, niedriger Auflösung und 16 Bit leben muss, bin ich nicht bereit, hier von einem Qualitätsschub zu sprechen. Das beanspruche nVidia aber für ihre GeForce GPU. "will look better" bezogen sie ausdrücklich auf den T&L-Effekt. Dieses Versprechen kann eine GeForce mit DX7 T&L nicht halten. Das versuchte der Artikel darzulegen.

> Also verstehe ich dich richtig, wenn ich die Aussage dieses Absatzes (und der korrespondierenden Teile deines Artikels) so paraphrasiere?
> "DX7-style TnL kann nur deshalb von einer schnellen CPU gleichschnell wie von einer dedizierten GPU ausgeführt werden, weil die gegenwärtigen Spiele nicht genug Polygone aufweisen, als dass die GPU glänzen könnte--daher wird die DX7-style TnL Einheit auch in Zukunft nix bringen."

Nur halb. Was soll denn nun verglichen werden? Spitzenleistung der T&L mit einer CPU die ebenfalls nur transformiert, oder jeweils das Grafikkarten- vs. CPU-Gesamtsystem? Es ist mir persönlich Wurst, wieviel eine GPU transformieren KANN. Wichtig ist, "was hinten rauskommt." Ich denke, ein moderner Athlon kann es mit einer GF256-GPU aufnehmen. Aber das ist auch nicht relevant, da der Athlon ja in der Praxis mehr tun muss, als nur zu transformieren. Mein Standpunkt ist also, dass DX7 HW T&L nicht daran zu messen ist, wieviel die GPU unter optimierten Bedingungen transformieren könnte. Übrigens ist der Maximalwert eh nicht relevant, da sie durch Flaschenhälse minimiert wird. Also muss sich ein Athlon auch nicht an theoretischen 14 Millionen Eckpunkten messen, erst recht nicht mit den "25 Millionen Dreicken" einer GTS.

Für die Zukunft ist meine Aussage folgende: Bei Anhebung der Polygonzahl steigt die Ineffizienz und der Overdraw, erst recht, wenn neue Objekte eingefügt werden. Das ist kein Grund, mehr Polys zu verwenden, WENN DENN die Rendereinheit mit der zusätzlichen Last auch fertig wird. In Zukunft wird nicht nur die Polygonzahl, sondern auch die Mehrfachheit des Multitexturing zunehmen. Die Auflösung wird steigen, 32 Bit wird sich durchsetzen. Wenn es soweit ist, dass die GPU theoretisch "glänzen könnte", dann überfordert sie erstens hoffnungslos die Rendereinheit und zweitens wird sie wegen der festen Verdrahtung vermutlich sowieso weniger genutzt.


> My ex-girlfriend's GeForce 256 can pull off 12 million triangles per second.

Das will ich sehen -> 12 Millionen Dreiecke pro Sekunde bei einer GF256. Die müssen immerhin gerendert werden.

> Ich denke, wir sind uns einig das im theoretischen Fall eine HW TnL Engine auch einem 2GHz Athlon überlegen wäre

1. Da der Athlon nebenbei noch andere Dinge zu tun hat, magst du recht haben. 2. Aus angeführten Gründen ist der theoretische Maxmial-Fall einer HW T&L nicht interessant. Es sei denn, man sitzt in der Marketing-Abteilung.

> Ich habe bisher noch keine Spiele Engine gesehen, die nicht mit statischem TnL umgesetzt hätte werden können.

Würden sie davon auch erheblich profitieren, so dass der Kauf einer T&L-Karte für vollen Genuss unweigerlich wird?

> Aber eben, Spieleprogrammierer wollen halt auch Geld machen und ihre Produkte aufm kleinsten gemeinsamen Nenner sauber laufen sehen, nicht nur auf hardware TnL Systemen.

Und sie wollen durch tolle Grafik auf sich aufmerksam machen. Ich denke, sie gehen nicht vom kleinsten gemeinsamen Nenner aus, oder läuft Ultima IX auf einem P200MMX passabel? Ich kenne Leute, die noch einen P133 (ohne MMX) nutzen. Wäre T&L der Bringer, gäbe es in den Optionen eine T&L-Option, der die Grafik in neuer Pracht erstrahlen liesse. Es sei denn, alle Spielehersteller hätten sich abgesprochen, dem Zocker den Segen durch T&L zu verwehren. Siehe die als bekannte Hardware fordernde Wing Commander Reihe. Um dem Anwender für WC5 die beste Grafik zur Verfügung zu stellen, gab es extra Glide-Support, und bot dem Voodoo-Besitzer so bessere Grafik als damals mit D3D möglich war. Es wurde nicht der kleinste gemeinsame Nenner gesucht. Um sich von der Konkurrenz abzusetzen, unterstützten sie eine Schnittstelle mit eingeschränkter Verbreitung.

> Die Kyro kann ihre Füllrate auch nicht zu 100% ausspielen, in der Praxis.

Da bliebe die Frage, ob man effektive oder sichtbare Füllrate misst. Der Overdraw durch Transparenz ist schliesslich unvermeidlich.

> "[1024x768x2xFSAA vs. 1600x1200]"
> Und "ist auch noch schneller" kann ich als Sometime-V5 user nicht bestätigen. (Bei 800x600 stimmt's wieder.)

Ich habs mit einer Voodoo4 getestet. Ausserdem kann man das nachrechnen.

> "[FSAA im T&L-Artikel]"

Immerhin erhöht eine erhöhte Polygonzahl auch die Aliasing-Effekte. Da erinnere ich an X-Isle. Der Knackpunkt war, dass FSAA *meiner Meinung* nach nicht "gerecht" in den Medien behandelt, während (DX7) T&L als Zukunft beschrieben wurde.

> "Ich fürchte, du hast vernünftiges FSAA noch nicht in Aktion erlebt."
> Wie schliesst Du das aus dieser Aussage? Nur weil ow nicht Textur/Pixelflimmern erwähnt hat?

Weil es mir *scheint*, dass er FSAA generell für wenig brauchbar hält.

> "Hm, die Leistung einer Karte mit 5,3 GB/s Bandbreite und effektiverer Renderstruktur als GTS nennst du dürftig."
> Was verstehst Du unter "effektiverer Renderstruktur?"

Das sind hier zwei Dinge. Gehen wir von Multitexturing aus. GF2 hat 4 MT-Pipelines, V5 nur 2. Allerdings sind die bei der V5 unabhängig im Speicherzugriff. Greift eine Pipeline der GF2 auf den RAM zu, können das die anderen drei in dieser Zeit *nicht*. Ausserdem ist ein 2x128-Bit-Interface deutlich effektiver als ein Quasi-256-Bit-Interface (wg. DDR-RAM.) Also kann die V5 die verfügbare Speicherbandbreitenmaximalgrösse zu einem grösserem Teil nutzten, als die GTS.

> "Die 16-Bit-Qualität einer Voodoo (vorallem ab Voodoo3) ist sichtlich besser als die einer MX."
> Das kann ich definitiv nicht bestätigen. Ich hab' extra nochmals meine V3 rausgekramt, und die 16bit Qualität hatte eine stark verwaschene Komponente. Mir gefällt das 16bit meiner Kyro immernoch am besten.

Andere, ich gehöre dazu, können das aber bestätigen. Der verwaschene Eindruck der Texturen kann je nach Spiel durch einen zu niedrigen LOD kommen.

> "[Radeon-T&L vs. GTS-T&L]"
> Nö, ist praktisch identisch aufgebaut, und dazu noch langsamer als bei der GTS, was aber eher am Chiptakt hängt als an der Implementierung.

Soweit ich informiert bin, hat die Radeon schon einen Vertex Shader 1.0. Also eine programmierbare T&L-Einheit, fortschrittlicher als eine GTS-T&L.

---

ow:

"Es wurde hier bewusst der Einstiegschip von NV (MX200) mit dem Topmodell von 3Dfx (VSA100) verglichen, um eben überhaupt ein (Schein-)Argument gg. T&L zu finden."

Das Topmodell mit 4 Chips bzw. die Mittelklasse mit 2 Chips kam gar nicht zur Sprache. Es wurde auch kein Argument gegen T&L gefunden. Sondern lediglich festgestellt, dass in der Praxis die Speicherbandbreite wichtiger als T&L ist. Du versuchst, und das finde ich ziemlich hässlich von dir, mir da Dinge unterzuschieben.

"Hier ist schon klar, das der Artikel nicht auf Objektivität zielt, sondern reine Anti-NV Propaganda ist."

Komisch, wie du das auffasst. Die meisten scheinen den Sinn so verstanden zu haben, wie es gedacht war.

"Es wäre für NV wesentlich teurer, die T&L aus dem MX200 zu entfernen (neues Chiplayout, eigene Fertigungsstrasse, Treiberanpassung) als sie einfach drin zu lassen."

Nach einer gewissen Anzahl an verkauften Chips rentiert sich das. Ausserdem könnten die so den Ausschuss wiederverwerten und z.B. MX-Chips mit kaputter T&L noch verkaufen, das spart bares Geld. Treiberanpassung, mein Gott, ist beim modular aufgebauten Deto doch kein Problem. Die T&L wird einfach als nicht vorhanden gekennzeichnet.

"Als Argument gegen T&L taugt dein Vergleich absolut garnichts."

Die MX-200 ist kein Argument gegen T&L, auch wenn du das so verstehen willst. Sie ist ein Argument, dass T&L nur dann etwas bringt, wenn die Karte auch ansonsten anständig dimensioniert ist.

> Man sollte für einen fast 3 Jahre alten Chip auch nicht die heutigen Masstäbe ansetzen, oder??

Um ihn für heute zu bewerten, sollte man das schon.

"Man muss den Chip in der Umgebung messen, die zu seinem Erscheinen aktuell war. Und da gibt es praktisch keine Performanceverlust zwischen 16 u. 32 Bit."

Ich erinnere mich so, dass der Einbruch schon damals zwischen 25 und 40% lag.

> "Beide Teile sollten harmonieren. Ist eine Einheit permanent überdimensioniert, kostet das den Endkunden nur Geld."
> Was kostet denn da Geld? Was ist denn das für ein Argument?

Ein Argument aus Sicht des Käufers. Die T&L ist überzüchtet. Sie hätte weniger leistungsfähig sein können, für den Anwender wäre es das gleiche. Eine weniger leistungsfähige T&L lässt sich billiger herstellen. Nur leider lassen sich dann auch nur weniger grosse Zahlen auf die Packung drucken.

> "Der Kyro kann seine Füllrate nachweislich ausspielen"
> Sehr guter Witz!!

Beim 3Dmark-Füllraten-Test kann er das, eine GTS kann es nicht. Ok, das ist kein "Real-World", im Gegenteil. Fest steht, dass eine GTS nicht mal in synthetischer Umgebung ihre Füllrate ausspielen kann. In der Praxis hat der Kyro wenigstens eine Chance, seine Füllrate auszuspielen, was der GTS verwehrt bleibt.

> Also bei einer angenommenen Auflösung von 1024x768 (rund 800.000 Pixel) rendert dein Kyro also in allen Games immer runde 200fps (175MPix/s geteilt durch 0.8Mpix). So ist das doch zu verstehen, oder nicht??

Es haben sich schon andere deiner tollen Berechnung angenommen. Das Grundwissen mit Multitexturung und transparentem Overdraw sollte man schon mitbringen, ehe man Füllratenrechnungen macht.

---

Stefan Payne"

"Und die Sache mit der T&L Spezi ist nicht von der Hand zu weise, daß NV unberechtigterweise das als ECKPUNKTE angibt!

Dreiecke wären korrekter gewesen."

Eher anders herum :)

"ow hat recht, der Artikel hat SEHR viele Fehler (technisch gesehen)."

Da ow das nicht zustande bringt, könntest du vielleicht wenigstens die grössten Fehler aufzählen? Falls sich etwas tatsächlich als falsch heraus stellt, würde ich das gerne im Nachtrag berücksichtigen.

[nggalai]

hi aths,

bitte entschuldige, wenn ich hauptsächlich auf argumentations-technische Punkte deiner Antwort eingehe und mich auch auf "unsere" Diskussion beschränke. Grundsätzlich sag' ich mal "danke" für dein posting, hat doch einiges klarer gemacht--und ich denke dass auch klar ist, dass wir beide eigentlich recht einer Meinung sind. :) Freu' mich schon auf deinen Anhang zum Artikel.

"[Warum MX-200?]"

semi-ACK. Alles, was Du mit dem Beispiel im Artikel zeigst, ist a) dass MAX PAYNE b) stärker Füllraten- als Geometrie-limitiert ist. a und b, Sonst nichts. So wie er im Moment da steht ist dein erster Absatz mi Artikel zu allgemein formuliert. Aber grundsätzlich, nach deiner Erklärung hier im Forum, stimme ich dir zu: TnL bringt ohne stabilen technischen background (e.g. Bandbreite) nicht viel.

"[Erst Bandbreite, dann T&L]"

Zu a): die Bandbreiten-Erfordernisse um anständig hardwired TnL fahren zu können sind schon seit über einem Jahr erfüllt. Die MX200 ist ein low-cost Ausreisser. DX7-style TnL verbrät nicht sooo viel an zusätzlicher Bandbreite, sonst würden auch die ganzen Tech-demos nicht sauber laufen. Und natürlich wäre TnL mit b) besser, deshalb haben wir jetzt ja endlich echte vertex shader in consumer Hardware. Einfach so aus Spass an der Sache implementiert kein Hersteller ein solches Feature in hardware.

Der Schluss, zu dem ich angesichts der GF1/2-Hardware [Bandbreitenbeschränkung] komme ist, dass T&L gar keinen signifikanten Qualitätsschub bringen KANN. Das ist imho wieder zu allgemein gesagt, sorry. Ein Gegenbeispiel reicht um deine Argumentation zu widerlegen, und da werfe ich mal einfach Sacrifice auf einer GF2 rein--die höhere Framerate mit TnL Unterstützung gilt wohl als signifikanter Qualitätsschub, wenn man die Sache so interpretiert:

Ohne TnL weniger Polygone flüssig dargestellt, mit TnL mehr Polygone flüssig dargestellt -> Qualitätssteigerung durch hardware TnL Support, selbst auf der bandbreitenlimitierten MX.

Gleiches lässt sich auch zu Max Payne, Black&White und Giants sagen. Und warscheinlich noch einige Titel mehr.

T&L hin oder her - damit allein kann uns nicht, wie aber versprochen, der grosse Schub in Dingen Detailreichtum gebracht werden.Damit alleine sicher nicht. ACK.

Für die Zukunft ist meine Aussage folgende: Bei Anhebung der Polygonzahl steigt die Ineffizienz und der Overdraw, erst recht, wenn neue Objekte eingefügt werden. Das ist kein Grund, mehr Polys zu verwenden, WENN DENN die Rendereinheit mit der zusätzlichen Last auch fertig wird. In Zukunft wird nicht nur die Polygonzahl, sondern auch die Mehrfachheit des Multitexturing zunehmen. Die Auflösung wird steigen, 32 Bit wird sich durchsetzen. Wenn es soweit ist, dass die GPU theoretisch "glänzen könnte", dann überfordert sie erstens hoffnungslos die Rendereinheit und zweitens wird sie wegen der festen Verdrahtung vermutlich sowieso weniger genutzt.Bis auf den letzten Satz absolut ACK. Allerdings sehe ich das nicht so schwarz für Karten vom GF2 GTS Kaliber aufwärts (die hätten genügend Reserven, bei TnL optimierter Software zu glänzen). Und wenn man sich so die Spiele Engines anschaut, die in den nächsten Monaten auftauchen, dann scheint hardwired TnL doch recht stark vertreten zu sein. Sogar Duke Nukem Forever wurde (sanft) auf hardware TnL Möglichkeiten erweitert, wie ich gestern feststellen musste. Aber eben, lassen wir das mitm Zukunftratespiel erstmal und schaun in einem Jahr nochmals nach. :)

Das will ich sehen -> 12 Millionen Dreiecke pro Sekunde bei einer GF256. Die müssen immerhin gerendert werden.Ja, ich will das auch sehen, deshalb hab' ich meine Quelle mal angemailt. :) Allerdings muss ich sagen, dass die 12 Millionen--wenn man von Benchmarks und Demos extrapoliert--sehr wohl im Rahmen des Möglichen liegen, wenn nur die Situation anspruchslos genug ist. Oder sind mit den 12Mio wohl wieder Eckpunkte gemeint? in dem Falle ginge die Zahl absolut in Ordnung.

Aus angeführten Gründen ist der theoretische Maxmial-Fall einer HW T&L nicht interessant. Es sei denn, man sitzt in der Marketing-Abteilung. ... oder man diskutiert wie wir das hier im Forum machen. Einfach der Diskussion halber. :)

> Ich habe bisher noch keine Spiele Engine gesehen, die nicht mit statischem TnL umgesetzt hätte werden können.

Würden sie davon auch erheblich profitieren, so dass der Kauf einer T&L-Karte für vollen Genuss unweigerlich wird?Für den vollen Genuss? Absolut. Schau dir doch nur mal gegenwärtige TnL-unterstützende Spiele an: Serious Sam z.B. ist bei voller Auslastung der Engine ohne hardware TnL kaum mehr spielbar, mit allen Geometrie-Details voll oben. Die Unreal2 Engine wünscht sich nach Aussagen sowohl der Programmierer als auch Spieledesigner ebenfalls einen Geometrie-Beschleuniger. Max Payne sowieso.

"[Kleinster gemeinsamer Nenner]"

Was hast Du denn immer mit Ultima Ascension? ;) Es ist wohl allgemein bekannt, dass Origin wie auch id gerne, hmm, ich kenn den deutschen Ausdruck nicht, hoffentlich versteht ihr mich so, "Origin and id both really like(d) to push the envelope." Ich sag' nur Strike Commander ... aber "normal" für Spieleentwickler ist das nicht. Manchmal geht's gut mitm, err, Couvert-drücken? :) aber halt auch nicht immer: U9 eines der schlechtest-verkauften EA Games aller Zeiten und hat Origin schlussendlich den Kopf gekostet (was sicher auch an den Bugs liegt, aber wenn man die Grösse der U-Fanbasis bedenkt, hatten wohl die Hardware-Anfordernisse mehr damit zu tun). Das Risiko, an der user base vorbeizuentwickeln, kann sich kaum ein Team leisten.

Wäre T&L der Bringer, gäbe es in den Optionen eine T&L-Option, der die Grafik in neuer Pracht erstrahlen liesse. Es sei denn, alle Spielehersteller hätten sich abgesprochen, dem Zocker den Segen durch T&L zu verwehren. *lacht* Nein, die warscheinlichste Erklärung ist da, aus Business-Sicht, eher so: ein vernünftiges LOD Modell für Level- und Charaktergeometrie zu erstellen ist ganz schön schwierig und kostet viel Zeit und daher auch Geld. Einfach mal kurz eine standalone "TnL Version mit 20x mehr Polygonen pro Modell" zu coden ist auch nicht so ohne weiteres machbar, und was passiert, wenn man einfach mehr Dreiecke dynamisch per Zufallsprinzip hinzufügt zeigen ja schön TruQuake und der UT patch für TruForm. Da muss angepasst werden, in jedem Fall, und das geht wieder ins Geld. Der Produzent(und nicht die Programmierfirma) muss erstmal ja sagen, bevor auch nur eine Zeile Code resp. eine Minute Zeit in die Richtung investiert wird.

Dass zur Zeit von WC5 Glide deutlich mehr aufm Kasten hatte als D3D ist bekannt. Und dass damals 3dFX Karten da noch immer die am weitesten verbreiteten 3D Beschleuniger waren, wohl auch. Da liegt es absolut drin, für Glide zu entwickeln. Entwicklung ist immer ein Ausbalancieren von "was können wir machen" und "wieweit müssen wir für low-end User Zugeständnisse machen". Schlussendlich soll Aufwand und Ertrag ins Gleichgewicht gebracht werden(resp. "kleiner Aufwand, grosser Ertrag" dabei rauskommen--der Tetris-Effekt. :) )
"Kleinster Gemeinsamer Nenner" ist so nicht richtig, muss ich mich selbst korrigieren auf, hmm, "weiteste sinnvolle Verbraucherbasis."

> "[1024x768x2xFSAA vs. 1600x1200]"
> Und "ist auch noch schneller" kann ich als Sometime-V5 user nicht bestätigen. (Bei 800x600 stimmt's wieder.)

Ich habs mit einer Voodoo4 getestet. Ausserdem kann man das nachrechnen.War ein Missverständins meinerseits--ich hatte im Kopf, dass Du von 1024x768x4x FSAA schneller als 1600x1200 sprachst. Mein Fehler.

"[Voodoo5 Rendereffizienz]"

Ah, ok. Du meinst das quasi-SLI Design der V5. OK. Ich sprach von den Grafikchips (i.e. VSA100 / NV15), nicht von der ganzen Karte. ACK.

Soweit ich informiert bin, hat die Radeon schon einen Vertex Shader 1.0. Also eine programmierbare T&L-Einheit, fortschrittlicher als eine GTS-T&L.Kannst Du eine Quelle dazu angeben? Soviel ich weiss, hat die Radeon PS1.0 Support, und keinen Hardware Vertex-Shader. Naja, beides wird von keiner API direkt unterstützt und liegt brach, also ist's eh nicht so wichtig. (Aber interessant.)

Wow. Sorry wegen der Länge meiner Postings. Blame my chronic insomnia. ;)

ta,
-Sascha.rb

[Xmas]

Bei der V5 muss man aber auch berücksichtigen, dass sie die doppelte Bandbreite für Texturen benötigt (und das ist einiges!) und auch sonst die SLI-Technik keine hundertprozentige Effizienz, sprich doppelte Leistung der V4 bringt (aus verschiedenen Gründen, die ich nicht alle kenne). Ob man hier wirklich davon sprechen kann, dass die V5 effizienter als eine GTS ist, weiß ich nicht. Auch auf Kostenseite - mehrere (billige) Chips und mehr (billigeres) RAM, ob sich das rechnet?

[Ceiser Söze]

Zum Thema RT-DAT (Sacrifice-Engine):
Das Ganze hört sich in der Theorie viel besser an, als es dann in der Praxis auch aussieht. Ich habe einmal einen Direktvergleich gemacht: GeForce2 vs. Voodoo5 auf gleicher CPU. Die Polygonenmenge auf der GeForce2 war zwar laut den Zahlen insgesamt etwas höher, aber auf dem Bild sah man überhaupt keinen Unterschied. Wenn man ganz gezielt danach suchte, konnte man vielleicht, wenn man Glück hatte und sich auch wirklich an einer optimalen Position befand :) , einen kleinen Unterschied erkennen. Im Spielverlauf war jedoch keine Verbesserung der optischen Qualität durch T&L zu erkennen.
Daher fällt auch die RT-DAT-Engine in die Kategorie "In der Theorie nett klingende, in der Praxis aber kaum überzeugende Dinge" ;)

Max Payne und Giants haben kein leistungsabhängiges LOD-System. Die Spiele sehen mit Software T&L genauso schön/hässlich aus wie mit Hardware T&L. Der einzige Unterschied ist die Framerate. Und ob es sich für 10% mehr Frames lohnt, ein Paar Millionen zusätzliche Transistoren auf ein Die zu setzen, wage ich zu bezweifeln. Die hätte man besser für eine Optimierung der Bandbreite oder andere Nette Dinge eingesetzt. Auf der GeForce2 wären z.B. ein HyperZ-Feature, ein Accumulation-Buffer à la T-Buffer und Enviromental BumpMapping viel besser am Platz gewesen, als festverdrahtetes Hardware-T&L (die GeForce3 ist ein anderes Paar Schuhe - ein Schritt in die richtige Richtung, aber immer noch suboptimal).

[StefanV]

@Aths

1. Die 'Spiele' TnL entspricht der 'Profi' TnL (z.B. der Delta kennt die gleichern Befehle wie eine GF)

2. Es gab früher mal einen Chip, den man FREI Programmiern konnte;), leider wurde er nur bis NV3 Niveau weiterentwickelt, erreichte mit halbe Transistor Zahl und Halber Core Frequenz die gleiche Leistung.

Mit einem neuen Treiber könnte man diesem Chip z.B. EMBM 'angewöhnen'.

3. Die Sache mit der MX-200:

Ein bis 2 weitere Sätze wären in diesem Fall sinnvoll gewesem;).

4. Im Artikel scheint es so, als warst du sehr 3DFX Lastig.

5. Zur V5:
Ich bin der Meinung, das ein getrenntes Speicher Interface (siehe V2) sinnvoller wäre.
Ich hätte da sozusagen einen Controller Chip und 2 Render Chips genommen.

6. Du schweifst oft vom Thema ab.


Zur Radeon:

Gibt es nicht 2 Arten von VS??

Einen 'großen' und einen 'kleinen'??

Die G550 z.B. hat einen 'kleinen'...

[nggalai]

Hi Ceiser Söze,

danke für die Infos; mir ist aber auch klar, dass die genannten Spiele keine vernünftige LOD Funktion besitzen. Es ist jedoch schon so, dass man bei den genannten Spielen mit einer TnL Karte mehr Goodies und höhere Geometrie-Details aktivieren kann, bis die Performance einbricht. Ausserdem muss ich fragen: hast Du mal Sacrifice mit Final Patch auf einer HW-TnL gegen eine nicht-TnL Karte verglichen? Da liegen Welten dazwischen, in Sachen Spielbarkeit bei max. Details.

Ich muss dir auch hier recht geben: für 10% mehr framerate eine TnL Unit zu verbauen macht wenig Sinn. Allerdings ist's so, dass der Unterschied zwischen Minimal-Framerate mit TnL und w/out TnL bei TnL-optimierten Spielen doch etwas grösser ist; bei Giants z.B. sprechen wir von 30fps statt 14fps, in Extremsituationen, bei Serious Sam 12 statt 22. Und Sacrifice kannst Du bei vollen Details im Multiplayer ohne TnL vergessen (und geht sogar auf einer GF2 GTS ein wenig in die Knie, so).

Die maximale Framerate interestiert echt nicht, sobald mal 60fps erreicht sind--wenn man aber auf einer TnL Karte mehr Geometrie-Details einschalten und trotzdem die Minimal-FPS im spielbaren Bereich halten kann, dann ist das für mich sehr wohl ein Qualitätsargument.

einen schönen Sonntag noch,

-rb

[Thowe]

Originally posted by nggalai


1. Ich muss dir auch hier recht geben: für 10% mehr framerate eine TnL Unit zu verbauen macht wenig Sinn. Allerdings ist's so, dass der Unterschied zwischen Minimal-Framerate mit TnL und w/out TnL bei TnL-optimierten Spielen doch etwas grösser ist; bei Giants z.B. sprechen wir von 30fps statt 14fps, in Extremsituationen, bei Serious Sam 12 statt 22. Und Sacrifice kannst Du bei vollen Details im Multiplayer ohne TnL vergessen (und geht sogar auf einer GF2 GTS ein wenig in die Knie, so).

2. Die maximale Framerate interestiert echt nicht, sobald mal 60fps erreicht sind--wenn man aber auf einer TnL Karte mehr Geometrie-Details einschalten und trotzdem die Minimal-FPS im spielbaren Bereich halten kann, dann ist das für mich sehr wohl ein Qualitätsargument.

3. einen schönen Sonntag noch,

-rb

zu 1. Stimme ich voll zu.

zu 2. Also Mehrnutzen der TnL-Unit durch mehr Details bei einer konstant guten Minimalframerate.

zu 3. War global gemeint? Also *winkt* auch dir einen schönen und "diskutionslastigen" Sonntag.

[aths]

> Freu' mich schon auf deinen Anhang zum Artikel.

Das ist nett, und den schreibe ich gerade zum dritten mal neu, um das Ding gegen Kritik (gemeint ist hier berechtigte Kritik!) weitestgehend immun zu machen.

> Alles, was Du mit dem Beispiel im Artikel zeigst, ist a) dass MAX PAYNE b) stärker Füllraten- als Geometrie-limitiert ist. a und b, Sonst nichts.

Trifft das nicht auf alle modernen Spiele zu?

> So wie er im Moment da steht ist dein erster Absatz mi Artikel zu allgemein formuliert.

Dort steht: "Dennoch bin ich bei Max Payne mit meiner Nicht-T&L-Karte besser bedient, weil sie deutlich mehr Speicherbandbreite hat." Das Beispiel bezog sich ausdrücklich auf das eine Spiel.


> "[Erst Bandbreite, dann T&L]"
> sonst würden auch die ganzen Tech-demos nicht sauber laufen.

Techdemos nutzen zum allergrössten Teil starre Geometrie. Für dynamische müsste man ständig neue (veränderte) Objekte an die Karte senden, was die Bandbreiten-Anforderung erhöht. Der nature-Part aus der 3dmark2001-Demo lief auch auf einer Ultra nicht gerade flüssig. Das hab ich auf der cebit gesehen, zum Einsatz kam ein 1200-er TB.

> Qualitätssteigerung durch hardware TnL Support, selbst auf der bandbreitenlimitierten MX.

Die Möglichkeit, dass T&L für die Framerate was bringen kann, wurde im Artikel mehrfach erwähnt. Auf zukünftigen CPUs wird dieser Vorteil sinken. Qualitätsschub bezog ich, vielleicht kam das nicht genügend durch, vorallem auf das Aussehen, da die Framerate auch durch eine kräftige CPU nach oben gezogen werden kann. Siehe die Feature-Aufzählung kurz vor dem Fazit, die bringen allesamt bessere (und nicht "nur" schnellere) Grafik.

> Aber eben, lassen wir das mitm Zukunftratespiel erstmal und schaun in einem Jahr nochmals nach.

Hehe, in einem Jahr werden die CPUs vermutlich so stark sein, dass du auf den besten Modellen auch Sacrifice ohne Nachteile spielen kannst.


Das mit den 12 Mio. Dreiecken, da warte ich ab, was sich bei dir ergibt.

> Die Unreal2 Engine wünscht sich nach Aussagen sowohl der Programmierer als auch Spieledesigner ebenfalls einen Geometrie-Beschleuniger. Max Payne sowieso.

Die Max-Payne-T&L-Optimierung sehe ich kritisch. Im 3dmark2000 konnte man noch 3dnow oder SSE-Handoptimierung auswählen, was jeweils mehr als die DX SW T&L brachte. Bei Max Payne kann man nur noch DX SW oder HW T&L auswählen. So wie es aussieht, stellen sie dem Käufer nicht mehr das schnellste mögliche (handprogrammierte) SW T&L zur Verfügung. Insofern ist es HW T&L "optimiert".


> "[Kleinster gemeinsamer Nenner]"
> [Origin]

Es gabt in der Vergangenheit Ausreisserfirmen, für die es offenbar schick war, die modernste HW zu fordern. Solche Firmen gab es in Bezug auf T&L bislang nicht. Warum ist das so?

> ein vernünftiges LOD Modell für Level- und Charaktergeometrie zu erstellen ist ganz schön schwierig und kostet viel Zeit und daher auch Geld.

Das ist sehr richtig. Allerdings liesse sich "TruForm" auch "offline" anwenden und dann könnte man die teilweise abgerundeteten Modelle für die T&L-Version speichern.

> "Kleinster Gemeinsamer Nenner" ist so nicht richtig, muss ich mich selbst korrigieren auf, hmm, "weiteste sinnvolle Verbraucherbasis."

Hier erreichen wir jetzt ein grossen Maß an Übereinstimmung. Vielleicht stimmst du mir auch zu, wenn ich weiterhin meine, würde T&L wirklich eine signifikanten Schub bringen, gäbe es hier auch entsprechende Titel. Siehe "Ausreisserfirmen" in der Vergangenheit. Es hat mich jedenfalls ernüchtert, dass selbst Max Payne mit T&L nur schneller ist, aber nicht besser aussieht.

> War ein Missverständins meinerseits--ich hatte im Kopf, dass Du von 1024x768x4x FSAA schneller als 1600x1200 sprachst. Mein Fehler.

Dank FSAA lassen sich hier drei Dinge gleichzeitig erreichen: Die Grafik sieht besser aus, läuft im ergonomischerem Modus, -> und ist bis zu 20% schneller. Dass Anti-Aliasing auch als Speed-Up genutzt werden kann (und zwar unabhängig von einer expliziten Unterstützung) nehmen viele strikt nicht zur Kenntnis.


> ["Radeon mit VS?"]
> Kannst Du eine Quelle dazu angeben?

"Auch auf Geometrieebene ist der RADEON im Prinzip besser bestückt. In der Tat verbaute ATI bereits damals eine erste Version einer TNL-Einheit, die in Ansätzen an einen Vertex Shader erinnert. Da der RADEON allerdings vor dem verspäteten DirectX 8 fertiggestellt wurde, erfüllt die Einheit nicht die DirectX8-Spezifikation 1.0 bzw. 1.1, sondern lediglich einige Teilfunktionen. Dazu zählen Pointsprites, 2- und 4-faches Matrix-Skinning sowie Keyframe-Interpolation."

Ok, also doch nicht 1.0, aber ansatzweise schon Funktionen. Zum PS fand ich aber auch was:

"Wenn Sie in der Registry im Verzeichnis HKEY_LOCAL_MACHINE \ SOFTWARE \ ATI_Technologies \ Driver \ 0000 \ atidxhal die String-Werte VertexShaderVersion = "10" sowie PixelShaderVersion = "10" eintragen, täuschen Sie DirectX 8 einen kompletten DX8-Beschleuniger vor. Manche DX8 SDK-Tech-Demos funktionieren, andere nicht. Speziell die an den GeForce3 angepasste Vertex Shader-Version von DX8 mögen sich nicht mit dem RADEON vertragen, hingegen die gegenüber den ursprünglichen Fassung stark abgespeckte Pixel Shader-Version schon eher."

(Beides von http://www.3dconcepts.de/reviews/radeonvsgeforce2gts/4.htm)

---

Xmas: Da du ja beide Karten hast, hehe, können wir ja mal selbst n Techdemo machen und das einfach austesten :)

---

Ceiser Söze: "Im Spielverlauf war jedoch keine Verbesserung der optischen Qualität durch T&L zu erkennen."

Deshalb auch "T&L - das nicht eingelöste Versprechen". Leide ich an Gedächnisproblemen oder wurde uns nicht bessere Grafik versprochen?

---

Stefan Payne:

> 1. Die 'Spiele' TnL entspricht der 'Profi' TnL (z.B. der Delta kennt die gleichern Befehle wie eine GF)

Für Dinge wie 3D-Modellierung, wo für die Echtzeit-Voransicht nur schattierte Farben zum Einsatz kommen, ist die T&L ein nicht zu unterschätzender Vorteil, und ein sinnvolles Feature. Aber welchen Gamer interessiert das?

> 2. Es gab früher mal einen Chip, den man FREI Programmiern konnte, leider wurde er nur bis NV3 Niveau weiterentwickelt, erreichte mit halbe Transistor Zahl und Halber Core Frequenz die gleiche Leistung.

Meinst du den Pyramid3D?

> Mit einem neuen Treiber könnte man diesem Chip z.B. EMBM 'angewöhnen'.

Zu Lasten der CPU, nehme ich an. Angeblich kann mein Napalm-Chip jetzt auch EMBM unter OpenGL, ist zumindest im Treiber aktivierbar...

> 3. Die Sache mit der MX-200:
> Ein bis 2 weitere Sätze wären in diesem Fall sinnvoll gewesem.

Du hast Recht. Beim Schreiben war mir klar, was ich sagen wollte, aber der Leser kann nur das lesen, was da steht. Im Nachtrag wird die Sache daher noch kurz erwähnt.

> 4. Im Artikel scheint es so, als warst du sehr 3DFX Lastig.

Ich kann nur über Dinge schreiben, die ich kenne. Zu den T&L Konkurrenz-Features seitens 3dfx waren daher Äusserungen möglich. Sie boten das einzige FSAA, was mich überzeugte. Dieses Feature wird von mir sehr hoch bewertet, wie im Artikel und hier in den Diskussionen ersichtlich. Auch deshalb der Fokus auf 3dfx.

> 5. Zur V5:
> Ich bin der Meinung, das ein getrenntes Speicher Interface (siehe V2) sinnvoller wäre.
> Ich hätte da sozusagen einen Controller Chip und 2 Render Chips genommen.

Dieser Meinung sind nicht viele, da getrennte Speicher bestimmte Effekte verunmöglichen.

> 6. Du schweifst oft vom Thema ab.

Im Artikel oder hier?

> Zur Radeon: Gibt es nicht 2 Arten von VS?? Einen 'großen' und einen 'kleinen'?? Die G550 z.B. hat einen 'kleinen'...

Man muss die Spezifikation 1.1 erfüllen, um hier DX8 compliant zu sein. Auf dem Gebiet bin ich kein Experte.

---

nggalai: "bei Serious Sam 12 statt 22." Schön, dass T&L die fps hier fast verdoppelt. Allerdings würde ich beides noch als unspielbar bezeichnen. (Ok, 22 fps ist ganz nicht unspielbar, aber entspricht nicht meiner persönlichen Forderung von 40 fps für solo-, 60 fps für multiplayer.) Senkt man das Geometrie-Level so, dass man mit T&L auf ca. 40 fps kommt (bzw. für Multiplayer auf 60) wird die SW-Einstellung vermutlich nicht mehr so stark zurück hängen.

---

Wieso zum Geier wird mein Avatar nicht angezeigt? Ich hab doch einen hochgeladen...

[Thowe]

Originally posted by aths



zu 1. nggalai: "bei Serious Sam 12 statt 22." Schön, dass T&L die fps hier fast verdoppelt. Allerdings würde ich beides noch als unspielbar bezeichnen. (Ok, 22 fps ist ganz nicht unspielbar, aber entspricht nicht meiner persönlichen Forderung von 40 fps für solo-, 60 fps für multiplayer.)

zu 2. Wieso zum Geier wird mein Avatar nicht angezeigt? Ich hab doch einen hochgeladen...

zu 1. Sicherlich nicht dadurch wesentlich besser spielbar, aber es soll auch vermutlich nur als Referenz zum Thema künftiges Potential dienen.

zu 2. Häckchen vergessen

[StefanV]

@aths

1. Eine FESTE einheit ist für Spiele wohl schlecht geeignet, da sie ja für andere berechnungen benötigt wird, als bei OGL Anwendungen

2. Nein, ich meinte nicht den Pyramid (die Typen von den Laberboys bekommen ja auch nix fertig)...
Ich meinte die Veriete Serie...
Hatten ja einen RISC Core...

3. geht mir leider auch oft so ;)

4. das stimmt, du kannst nur über das schreiben, was du kennst.
Wenn man den Artikel durch hat dann denkt man aber (leider), daß du etwas gegen Nvidia hast und für 3DFX bist.

5. ansichtssache/ ausfürungssache

6. Im Artikel schweifst du oft ab.

7. Wenn ich mich nicht irre, dann gibt es den vollen VS und die Klassische TnL mit Matrix Skinning.
Beide sind Vertex Shader, ich denke hier könnte dir Leo helfen.

PS: kannst du deine Postings nicht 'etwas' kürzer halten?;)

Also Pro Person ein Posting, ist übersichtlicher als ein Monster Posting;).

Aber beachte, diese Version des Forums hat einen Bug, du kannst nicht 2 mal nacheinander quoten...

[007]

also langsam kann ich das Wort T&L nimmer hören, na ja sind eigentlich mehrere Wörter, aba egal, wie gehts euch in Sachen T&L?

[Thowe]

Originally posted by 007
also langsam kann ich das Wort T&L nimmer hören, na ja sind eigentlich mehrere Wörter, aba egal, wie gehts euch in Sachen T&L?

Ach was, weiter so. Vielleicht findet sich ja mal ein Nenner wenn die Leutz langsam sich einigen können was die wichtigsten Punkte der Diskution sind. Helfen könnte auch nicht alles wortwörtlich zu nehmen, sondern Aussagen auch schon mal tiefer zu interpretieren.

[nggalai]

Hi nochmals :D ,

Techdemos nutzen zum allergrössten Teil starre Geometrie. Für dynamische müsste man ständig neue (veränderte) Objekte an die Karte senden, was die Bandbreiten-Anforderung erhöht. Der nature-Part aus der 3dmark2001-Demo lief auch auf einer Ultra nicht gerade flüssig. Das hab ich auf der cebit gesehen, zum Einsatz kam ein 1200-er TB. Der Nature-Part im 3DMark2k1-Demo benutzt eben nicht DX7 TnL sondern Vertex Shader--auf nicht-DX8 Karten läuft der Teil des Demos auschliesslich auf der CPU. :)

Und das DX7 Techdemos zum allergrössten Teil wohl auf statischer Geometrie beruhen versteht sich ja wohl von selbst; man will ja eben DX7 Features damit präsentieren, zu denen hardware-beschleunigte ("starre") Geometrie gehört.

ta,
.rb

[nggalai]

... und NOCHMALS hi, ;)

ich habe zwar von meiner Quelle selbst noch kein Feedback betreffend der 12Mio Dreiecke/s mit einer GF256 erhalten, aber ich hab' mich mal wieder im ORB rumgeschaut. Bitte haltet im Kopf dass ich persönlich nicht sehr viel davon halte, solche theoretischen Benchmarks resp. deren Ergebnisse auf die Praxis anwenden zu wollen. Dies hier ist also rein zur Information gedacht, und nicht als Argument "für" TnL.

OK, ORB, then:

Im 3DMark2k1 High Polygon Count Test (1 light) kommt eine GF256 auf rund 9-11Mio Dreiecke pro Sekunde (Durchschnitt liegt bei etwa 9.5Mio), und das ist mit einer HW Lichtquelle incl. shading--meine oben erwähnte 12Mio-Angabe gilt ohne echtes HW-Licht sondern nur mit Normalvektor, i.e. solid colour. Liegt also absolut im Rahmen.

Eine TnL-lose Karte mit 1.4er TB kommt beim gleichen 3DMark2k1 Test auf max. 5-6Mio Dreiecke pro Sekunde, in etwa soviel wie die Charisma Engine der Radeon DDR hinkriegt (welche dafür bei mehreren Lichtquellen nicht so stark einbricht wie z.B. eine GTS). Eine GF3 liefert übrigens rund 18Mio Dreiecke bei einer Lichtquelle.

Hope this helps,

ta,
.rb

[Kai]

Vielleicht nutzt es euch was, wenn ich noch einwerfe, das z.B. Sacrifice ein FPS-Limit hat ... mehr als 26 ist nicht drin! Ob man es in der .cfg ändern kann, hab ich noch nicht getestet.

[Ceiser Söze]

Ich habe ja grundsätzlich nichts gegen T&L. Früher oder später ist dieser Weg unausweichlich (genauso wie man irgendwann auch wieder zum Software-Rendering zurückkehren muss). Was mich an der ganzen Sache stört, ist die Tatsache, dass nVidia (und danach ATI - vermutlich als Reaktion auf nVidia) halbgare Lösungen implementierten und ausserdem mit T&L neue Probleme in die Welt setzte, ohne die alten zuerst anzugehen.
Was das "halbgar" betrifft: Mittlerweile ist ja klar, dass ein Entwickler auf einer festverdrahteten T&L-Unit seine "Visionen" nicht oder nur schlecht realisieren kann. Dafür sind die Möglichkeiten zu eingeschränkt und leistungsfähig ist das Ganze in der Praxis auch nicht. Besonders das Lighting und damit der Teil, der wirklich einen grossen visuellen Qualitätssprung hätte ermöglichen können, war lahm (Lighting wird von vielen unterschätzt, kann aber mit einfachen Mitteln unglaubliche Atmosphäre generieren - siehe auch das Wenige, das man von Doom3 gesehen hat: Hier ist primär erstklassiges Lighting am Werk, das die unheimliche Atmosphäre aufkommen lässt). Bleibt nur die Ersatzfunktion als Speed-Up Feature. Aber das ist ja eigentlich nicht der Zweck von Hardware-T&L - und lässt sich auch mit anderen Mitteln erreichen...
Was die Probleme betrifft: Der zusätzliche Datenverkehr über den AGP-Bus, die Bandbreitenbelastung durch den Rasterizer UND die T&L-Unit, die Zunahme des Aliasing bei mehr Polygonen pro Szenerie etc.
Man hätte besser daran getan, die Probleme des Rasterizers zuerst aus der Welt zu schaffen, um erst danach die halbe Geometriepipeline auf den Grafikchip auszulagern: Von einem guten und schnellen FSAA, einer ebenso schnellen Implementierung von anisotropischem Filtering, einem hochoptimierten Z-Buffer und anderen bandbreitensparenden Massnahmen und Enviromental BumpMapping schon zu GeForce256-Zeiten hätte IMHO der gewöhliche Zocker viel mehr gehabt, als von einer vom Entwickler ungeliebten T&L-Unit.
Dann hätte eine T&L-Unit auf dem Grafikchip Sinn gemacht - aber bitte gleich einen Vertex-Shader (auch wenn das möglicherweise nicht so einfach zu realisieren gewesen wäre).

[Grasso]

FSAA ist einfach so geil, da muß man nichtviel drüber reden sondern man freut sich einfach, daß man einen Kyro hat.

Übrigens: Die minimale Framerate muß auch stärkere Bedeutung erlangen. Da gibt es nicht nur offensichtliche Anfälligkeiten der Grafikkarte wie etwa hoher Overdraw in bestimmten Szenen, sondern auch ganz perfide Treiberproblemchen: 1.: Treiber ("kernel-space") dürfen das Multitasking vorübergehend ausschalten, Anwendungen ("user-space") nicht. 2.: Der PCI-Bus ist in der aktuellen Version 2.1 noch anfällig für Staus (2.2 nicht mehr), was sich bis zur CPU, die dann nicht ans RAM rankommt, auswirken kann. nVidia-Treiber scheinen für deadlocks (gegenseitige rückgekoppelte Blockaden), die sich aus der Kombination von 1.) und 2.) ergeben, anfällig zu sein. Siehe angetatschte Datei!

Es kann allerdings sein, daß diese Aussetzer nicht ins Benchmarkergebnis einfließen, wenn nämlich bestimmte Zähler des Spiels oder sogar die kernelseitigen Multimediatimer von Windows, auf die sich ein guter Benchmark beziehen muß, mit verzögert werden. Die Treiberprogrammierung unter Windows erlaubt es, sogut wie alle möglichen Prioritäten einzustellen, von der Interruptbehandlung, nicht-preemptivem Code und den Bussen, die sich sowieso nur indirekt von der CPU kontrollieren lassen, mal ganz abgesehen.

nVidia sind für Soundknackser, ruckeliges DVD etc pp bekannt. So, wie das in der großen Zeit von 2D (Win9x, ~1998) bei ATI, Matrox und anderen Größen des Grafikkartenmarkts war, damals waren die Treiber unglaublich rücksichtslos, bloß um im Buisness-2D-bench etwas bessere Werte zu erhalten. Die damaligen Detonatoren (für Riva128 und TNT) war dagegen harmlos, einfach weil nVidia nicht so viel rumgefummelt hat. Siehe auch etwas weiten unten auf schon genannter Seite unter der Rubrik Video!

nVidias vielgerühmte "Treiber-Optimierungen" brachten zweifellos eine bessere 3D-Gesamtperformance, schließlich wurden die meisten Spiele des Jahres 1998 erst durch die Detonatoren des Jahres 1999/2000 überhaupt vernünftig spielbar, aber diese Optimierungen liefen nur nach trial-and-error ab und orientierten sich ausschließlich an unsinnigen Benchmarks (unbewertete average frames ist immer unsinnig).

Daß Chipsätze für K6-2/3 kapitulieren war egal, solange Entwickler und testende Zeitschriftenredakteure Pentium2s auf Intel 440FX-BX benutzten. Letztlich hat es nVidia aber gedämmert, daß sie damit nicht mehr durchkommen, darum kommt auch ihr nForce-Chipsatz, der die Busprobleme auf der Grafikseite mit Brute-force (DDRAM mit Interleaving) und auf der Multitaskingseite (Sound, Netzwerk etc.) mit speziellen Features (reservierte Bandbreiten) lösen soll.

Als Referenz erwähne ich http://grassomusic.de/deutsch/video.htm, auf der Teile dieses Postings vielleicht auftauchen werden, schließlich will ein zwei-Stunden-Posting wie dieses recycled werden.

[Grasso]

Bilder attachen geht wohl nicht mit Ns4...

[nggalai]

Hi Grasso,

danke für die Info, aber das ist in diesem Thread doch eher OT. Könntest Du vielleicht einen neuen Thread eröffnen, damit man das sauber diskutieren kann?

Danke,

.rb

[Grasso]

Ich will diese Grafik nicht als Beweis verstanden wissen, schließlich könnte das mit dem "ganz tief runter und dann sofort ganz hoch" auch auf einen Fehler des Mittelungsalgorithmus zurückzuführen sein. Es soll bloß demonstrieren, daß des Sinn machen kann, fps / Zeit darzustellen.

[Grasso]

http://www.3dcenter.de/vbulletin/showthread.php?s=&threadid=3638

[Unregistered]

Originally posted by nggalai
Bitte nicht persönlich nehmen, ok?

Erf? Weshalb denn das? Etwa, weil bedeutend mehr Anwender MX400 oder MX Classic besitzen als MX200? Oder weil die 400er die doppelte Speicherbandbreite der 200er hat, und daher mit der V4 gleichzieht?

=> Nene, der Vergleich mit der MX200 stimmt in meine Augen auch.
Die MX200 hat auch T&L und diese Funktion ist leider nunmal ein Kaufgrund für Kunden.
Das die T&L hier komplett aufgrund der niedrigen Speicherbandbreite sinnlos ist, sehen die 08-15 Kunden nicht.
Leider gibt es von diesen Kunden, der liest in einer Zeitschrift das die MX "TopLeistung" bringt geht in einen nächsten Laden und kauft eine.
Der Hacken daran ist leider das die meisten dann die kleine Schrift MX200 übersehen..........
Auserdem wird diese Karte dann wieder in komplett Systemen verbaut, wo eine Kyro1 günstiger und um einiges Effektiver wäre.
Was die MX400- betrifft von der Speicherbandbreite könnte man es Vergeleichen aufgrund des TBR Verfahren hat die MX400 keine Chance auch hier zieht die T&L keine Nutzen.
Aber wie gesagt der Hauptgrund ist das TBR - Verfahren weshalb die MX stehen gelassen werden.
Trotz höheren Chip und Speichertakt.

Dein ganzer Artikel (mit dem ich, wie schonmal gesagt, im grossen-ganzen einverstanden bin) geht doch um Marketingversprechen über DX7-style TnL (also hardwired TnL), nicht?

=> DX7 T&L war oder ist einfach nicht so Leistungsfähig wie es man angepriessen hat.
Freilich ein Anfang muss mal sein, ansonsten könnten wir lange auf T&L warten.
In einer Zeitschrift (weiss nicht mehr genau müsste ich nachsehen) hat 3dfx bewusst nicht T&L eingesetzt weil die DX7 T&L leider noch zu unflexible war.
3dfx wollte gleich auf eine Externe T&L welche frei programmier war.
3dfx hat hier die Konkurrenz und die Kunden unterschätzt.
Sie wurden fest kritisiert für diesen Entschluss auch wenn man jetzt sieht das es eigentlich der Richtige Gedankenweg war.
Hätte 3dfx Überlebt und den Rampage gebracht.
Hätten NV und 3dfx beide Karte mit T&L und vernünftigen FSAA gehabt.
Also wäre es im Endeffekt auf das gleiche hinausgelaufen.
Kurz DX7 T&L hat bis jetzt eigentlich keiner wirklich gebraucht und bei neuen Games wie Doom und Aquanox wäre beide Karten mit DX8 T&L der Überflieger gewesen.
Aber die Radeon2 gibt es ja noch. *sfg*
Die Radeon2 sollte aber auch Probleme bekommen, da angeblich die Readeon2 die GeForce3 PixelShader Version per Treiber auf Radeon PixelShader Version 1.4 umkonvertieren muss.
Also wenn das stimmt dann sollte Massive dieses berücksichtigen und einen Patch bereitstellen ansonsten werden sich einige wieder ergötzen an 5fps mehr.
Was in diesen Fall zu Unrecht wäre.
Genauso wie die jetzigen benches mit Aquanox das dieses ja nur momentan auf GeForce getrimmt wird, die Endversion aber angeblich nicht.

Diese Einbrüche währen auch bei TBR normal. Bei der Kyro zieht das nicht, da sie intern eh mit 32bit rechnet, also in ows Perspektive nicht von einem schnelleren 16bit Modus profitiert. Und dass die Radeon nicht so stark einbricht liegt einfach daran, dass ihr Design auch schon bei 16bit limitiert i.e. es wird nichtmehr viel "schlimmer", mit 32bit. Das ist übrigens die Erklärung, die ich von einem ATi Techniker bekam und nicht auf meinen eigenen Mist gewachsen. Abgesehen davon, eine GF2 Pro oder gar GF3 bricht auch nichtmehr so krass ein.

=> Richtig, deshalb verliert die Kyro2 kaum Leistung weil eben intern mit 32 Bit gerechnet wird.
Naja mit den neuen Treiber wurde es schon besser jetzt ist auch schon ein ersichtlicher Abstand bei der Radeon zwischen 16 und 32 Bit.
Kurz 16 Bit wurde leicht schneller.
Was aber blunzen ist da ich immer über (je nach Auflösung) 60 fps habe.
B. Ich aus optischen Gründen sowieso nur in 32 Bit Spiele und da ist die meine RadeonSDR sowieso schneller als die MX-Karten.

Oh, schaut mal her--ein Zirkelschluss. :) Weshalb soll TnL nur dann sinnvoll sein--falls die Karte auf 32bit/hohe Auflösungen ausgelegt ist--wenn die Unit programmierbar ist? Reduzieren sich dann "die Bandbreiten-Erfordernisse?" Mit dieser Aussage beweist Du dein Argument mit den Schluss, zu dem Du kommen willst.

Also verstehe ich dich richtig, wenn ich die Aussage dieses Absatzes (und der korrespondierenden Teile deines Artikels) so paraphrasiere?

"DX7-style TnL kann nur deshalb von einer schnellen CPU gleichschnell wie von einer dedizierten GPU ausgeführt werden, weil die gegenwärtigen Spiele nicht genug Polygone aufweisen, als dass die GPU glänzen könnte--daher wird die DX7-style TnL Einheit auch in Zukunft nix bringen."

Falls ich dich so richtig verstanden habe, hat's da nämlich nochmals einen klassischen Fehlschluss drin.



Die TnL Unit hat auch pipelining und caches ... aber OK, in dem Fall hier ein Praxisbeispiel ausm Serious Sam Forum zum Thema hardwired TnL in OpenGL (von einem Programmierer, der meine eigene Argumentation gegen hardwired-TnL kommentierte):

"I wrote a little benchmarking program in OpenGL. It sets up a sphere with a single directional light, lots and lots of polygons on the screen. The only thing being done is drawing the sphere -- no AI, no sound processing, no physics engine with collision detection, etc. My CPU (Pentium III 550) can pull off about 1.6 million triangles per second running the benchmark.

My ex-girlfriend's GeForce 256 can pull off 12 million triangles per second.

There's quite a huge difference there, and if you account for the fact that in a game, the CPU has to perform all the other tasks mentioned above like physics and AI, it doesn't leave a lot of headroom. The point is, allowing the CPU to do less work is a good thing, and a well-written graphics engine can do exactly that if it makes good use of hardware T&L.

I just remembered one of your original points was about lighting not being done on the graphics card, and I had written another benchmark that only used constant colors without lighting. It maxed out at 2.6 Mtris/sec on my machine. That benchmark didn't use enough triangles to fully stress a T&L card, I think it acheived up to 7 Mtris on the GF256, which was rising proportionally with the number of triangles on screen.

Neither benchmark used VARs which would've gotten even higher performance on GeForce cards."

Ich denke, wir sind uns einig das im theoretischen Fall eine HW TnL Engine auch einem 2GHz Athlon überlegen wäre, aber dass das in der Praxis (noch?) nicht der Fall ist. Meiner Meinung nach ist der einzige Grund, weshalb wir nicht mehr Spiele mit sauberer TnL Unterstützung haben, das Fehlen von TnL Hardware auf der common user base, und nicht die Inflexibilität der Implementation. Ich habe bisher noch keine Spiele Engine gesehen, die nicht mit statischem TnL umgesetzt hätte werden können. Aber eben, Spieleprogrammierer wollen halt auch Geld machen und ihre Produkte aufm kleinsten gemeinsamen Nenner sauber laufen sehen, nicht nur auf hardware TnL Systemen.

=> Grossteils stimme ich Dir überein, aber man könnte schon anders Systeme berücksichtigen und dennoch T&L Unterstützten.
Ist aber ein wesentlich mehraufwand schätze ich mal.

Die Kyro kann ihre Füllrate auch nicht zu 100% ausspielen, in der Praxis. :)

=> Können aber die anderen auch nicht.

ACK zum besser Aussehen, aber aus anderen Gründen (i.e. ich bevorzuge FSAA eh :) ). Wenn dein Monitor Mühe hat, bei 1200 Zeilen nicht auch mit mindestens 85Hz zu fahren, dann solltest Du diese Auflösung eh vergessen. Und "ist auch noch schneller" kann ich als Sometime-V5 user nicht bestätigen. (Bei 800x600 stimmt's wieder.)

Ich hatte mit deinem Artikel eigentlich weniger mit den FSAA Ausführungen selbst als eher damit ein Problem, dass Du von einer wirklich gelungenen TnL-Marketinglüge-Analyse plötzlich zu FSAA rüberwechselst, nachm Motto "aber DAS bringt was, qualitätsmässig, und nVidia ist da nur aufgesprungen." Ist ja schön, dass das qualitätsmässig was bringt, hat aber in einem TnL Artikel nichts verloren.

=> Ich schätze aths hat dieses anders gemeint. *sfg*
Ich glaube er wollte nur aufzeigen das Qualität auch was anders wie T&L sein kann.
Wegen Qualität: Wird Zeit das ATI die Hufen bewegt und TruFrom salon fähig macht.
Und wenn sie selbst alte Games patchen müsten.
Für UT und Quake gibt es ja schon mal einen PAtch, aber nicht von ATI:-)

Wie schliesst Du das aus dieser Aussage? Nur weil ow nicht Textur/Pixelflimmern erwähnt hat?

Was verstehst Du unter "effektiverer Renderstruktur?"

=> *schluterzucken*

Das kann ich definitiv nicht bestätigen. Ich hab' extra nochmals meine V3 rausgekramt, und die 16bit Qualität hatte eine stark verwaschene Komponente. Mir gefällt das 16bit meiner Kyro immernoch am besten. :)

=> Hm, die Kyro rendert intern auch mit 32Bit, 3dfx 22 Bit Post Filter,sieht aber noch immer besser aus als bei NV und Radeon Karten.

Nö, ist praktisch identisch aufgebaut, und dazu noch langsamer als bei der GTS, was aber eher am Chiptakt hängt als an der Implementierung.

=> Nein eben nicht, die T&L der Radeon ist fortschrittlicher, übrigens kann Pixelshader auch bei der Radeon aktivieren nur diese kann leider nicht alle Funktionen wie bei einer GeForce3.
Dann kommt noch HyperZ u.s.w...

Weshalb haben wir hier schonwieder einen neuen Thread?

tata,
.rb

[Unregistered]

"Wenn Sie in der Registry im Verzeichnis HKEY_LOCAL_MACHINE \ SOFTWARE \ ATI_Technologies \ Driver \ 0000 \ atidxhal die String-Werte VertexShaderVersion = "10" sowie PixelShaderVersion = "10" eintragen, täuschen Sie DirectX 8 einen kompletten DX8-Beschleuniger vor. Manche DX8 SDK-Tech-Demos funktionieren, andere nicht. Speziell die an den GeForce3 angepasste Vertex Shader-Version von DX8 mögen sich nicht mit dem RADEON vertragen, hingegen die gegenüber den ursprünglichen Fassung stark abgespeckte Pixel Shader-Version schon eher."

=> Falsch.
Nicht die Zahl 10 eingeben sondern den Wert auf 11 ändern.
Dann ladet sogar der 3DMark2001 die PixelShader und das Nature Demo.
Allerdigns bevor der 3DMark das Demo dann bringt, bricht er mit der Fehlermeldung: "P_D3D::_DRV_allocateMap device not support normal bump map" ab.
Aber laden tut er es, das heisst den Pixelshader erkennt nur alle Funktionen werden leider nicht Unterstützt.

Vertex Shader kann ebenso aktiviert werden, allerdings ist diese Funktion sehr buggy.
3DMark stürzt hoffnungslos ab.

[Legolas]

VertexShader braucht man nicht im Grafikkartentreiber extra aktivieren, weil die bei Nichtvorhanden sein in der Grafikhardware von der CPU emuliert werden.

[Unregistered]

Also erstmal herzlichen Glückwusch zu Deinem Artikel. Eigentlich gibt es nur eines das mich stört. Man hätte hier nicht zuoft die Voodoo als Referenz angeben sollen, sondern die Kyro2, da eben diese z.Z. aktuell ist und nVIDIA paroli bieten kann. 3dfx ist zudem nicht an veralteter Technik gestorben, sondern lediglich, weil Sie ihre Chips nur noch an STB verkauft haben. DIES war der aller größte Fehler. Man hätte die Chips nachwievor an ALLE Hersteller verkaufen sollen. Ansonsten ein echt bemwerkenswerter Artikel.

[Ceiser Söze]

3dfx hat STB aufgekauft, nicht zum Exklusiv-Vertriebspartner ernannt. Leider ging die Fusion nicht wie erwartet über die Bühne. Schlechtes Management machte sie teurer als erwartet. Dazu kam die Voodoo5-Verspätung und die Entscheidung, den Rampage mehrmals zu überarbeiten, statt endlich mal ein markreifes Produkt aus ihm zu machen (Voodoo3 und Voodoo4/5 waren nur"Übergangslösungen, der Rampage hätte ursprünglich 1999 erscheinen sollen - aber dann wollte man plötzlich noch die T&L-Unit SAGE dazunehmen, und Feature X und Feature Y usw...). Ganz nebenbei hatte die Konkurrenz aufgeholt - in Punkto Technologie und auch in Punkto Marketing ;)
Als dann Ende 1999 der neue CEO die Führung übernahm, war das Schicksal von 3dfx eigentlich bereits besiegelt. Die verursachten Probleme waren viel zu ernsthaft, als dass man noch gross etwas hätte ändern können. Hätte man neue Investoren auftreiben können, wäre die Geschichte vielleicht anders ausgegangen - aber man konnte ja nicht :(

[ow]

.

[Unregistered]

Die Voodoo Chips hätte jeder Hersteller gerne mit Kusshand genommen wenn er Sie den bekommen hätte. Ich vertreibe exclusiv Garfikkarten eines Herstellers hier in Deutschland( Hersteller aus HongKong ) und wir hätten gerne Voodoo 3/4/5 verbaut.

[Xmas]

Originally posted by Unregistered
=> Falsch.
Nicht die Zahl 10 eingeben sondern den Wert auf 11 ändern.
Dann ladet sogar der 3DMark2001 die PixelShader und das Nature Demo.
Allerdigns bevor der 3DMark das Demo dann bringt, bricht er mit der Fehlermeldung: "P_D3D::_DRV_allocateMap device not support normal bump map" ab.
Aber laden tut er es, das heisst den Pixelshader erkennt nur alle Funktionen werden leider nicht Unterstützt.

Vertex Shader kann ebenso aktiviert werden, allerdings ist diese Funktion sehr buggy.
3DMark stürzt hoffnungslos ab.
Was soll das bringen? Das Programm "erkennt" den Pixel Shader 1.1 nicht, sondern bekommt von Treiber vorgegaukelt, dass PS 1.1-Support vorhanden wäre - was allerdings nicht stimmt, deshalb die Fehlermeldung. Dass der 3DMark die Szene lädt und abbricht ist in keinster Weise besser als die Szene zu überspringen. Die Vertex Shader Emulation ist ebenso sinnlos.

[Xmas]

Originally posted by Ceiser Söze
Besonders das Lighting und damit der Teil, der wirklich einen grossen visuellen Qualitätssprung hätte ermöglichen können, war lahm (Lighting wird von vielen unterschätzt, kann aber mit einfachen Mitteln unglaubliche Atmosphäre generieren - siehe auch das Wenige, das man von Doom3 gesehen hat: Hier ist primär erstklassiges Lighting am Werk, das die unheimliche Atmosphäre aufkommen lässt).
Man kann eigentlich den gesamten Renderprozess als "Lighting" bezeichnen, es dreht sich ja immer um Licht ;)
Vertex Lighting sieht einfach schlechter aus als andere Verfahren, vor allem bei den heutigen Polycounts. Deswegen wird das "L" nicht verwendet, nicht weil es "lahm" wäre.


Was die Probleme betrifft: Der zusätzliche Datenverkehr über den AGP-Bus, die Bandbreitenbelastung durch den Rasterizer UND die T&L-Unit, die Zunahme des Aliasing bei mehr Polygonen pro Szenerie etc.

Zusätzlicher Datenverkehr über den AGP-Bus? Bei einer Engine die T&L optimal nutzt sollte es weniger Datenverkehr als bei Software-T&L sein.
Zunahme des Aliasing stimmt nur indirekt. Mehr Objekte bedeuten mehr Aliasing (und auch Overdraw).

[Ceiser Söze]

Man kann eigentlich den gesamten Renderprozess als "Lighting" bezeichnen, es dreht sich ja immer um Licht ;)
Vertex Lighting sieht einfach schlechter aus als andere Verfahren, vor allem bei den heutigen Polycounts. Deswegen wird das "L" nicht verwendet, nicht weil es "lahm" wäre.

Doch. Das Problem bei aktuellen T&L-Units ist die Tatsache, dass der Dreiecksdurchsatz mit jeder zusätzlichen Lichquelle drastisch sinkt (sowohl bei GeForce-, als auch bei Radeon-Karten). Da aber für ein schönes Vertexi-Lighting sehr viele Lichtquellen und viele Polygone benötigt werden, lässt sich dies auf aktuellen GraKas gar nicht realisieren, da das eine ja das andere verunmöglicht. Vertex-Lighting ist jedenfalls in Zukunft klar den Lightmaps vorzuziehen. Oder besser gesagt: Lightmaps sind kein vollwertiger Ersatz, da die Stärken dieses Verfahrens anderswo liegen - ideal wäre daher eine Kombination (zusätzlich mit einigen neuen Verfahren wie Shadow Maps). Wer das nicht glaubt, sollte mal ein Paar Videos von Nintendo Gamecube-Spiele ansehen (das Zelda-Video ist ein gutes Beispiel). Hier kommt ausgezeichnetes Lighting zum Einsatz. Und es sind keine Lightmaps.
Ich setze da übrigens grosse Hoffnungen auf PowerVR. Deren T&L-Unit (Elan), die im NaomiII zum Einsatz kam, konnte mehrere Lichtquellen gleichzeitig berechnen, ohne dass die Dreiecksperformance in den Keller sackte. Es besteht kein Grund zu glauben, dass PowerVR das nicht auch für den PC realisieren könnte...

[Legolas]

Naja, NVidia hat jetzt mit dem Sage auch eine recht leistungsfähige dynamische T&L Unit in der Hinterhand :D:D ;)

[Unregistered]

Originally posted by Ceiser Söze
Da aber für ein schönes Vertexi-Lighting sehr viele Lichtquellen und viele Polygone benötigt werden, lässt sich dies auf aktuellen GraKas gar nicht realisieren, da das eine ja das andere verunmöglicht. Vertex-Lighting ist jedenfalls in Zukunft klar den Lightmaps vorzuziehen.
Wieso Vertex Lighting, wenn man Lichtberechnungen per Pixel machen kann? Vertex Lighting (=Gouraud Shading) hat den entscheidenden Nachteil dass man Highlights nur an den Eckpunkten haben kann und im inneren des Polygons nur eintönig linear interpoliert wird. Wenn man mehr "Licht-Details" haben will, muss man die Geometrieauflösung enorm erhöhen, sogar bei flachen Dreiecken. Und das ist ja wohl kaum Sinn der Sache. In Verbindung mit Displacement Mapping und der damit verbundenen hohen Geometrieauflösung ist Vertex Shading vielleicht durchaus sinnvoll. Ansonsten kann man mit Bump Mapping bzw. Pixel Shadern und Shadow Maps ein viel besseres Ergebnis mit geringerem Aufwand erzielen.
Vertex Shading gehört in Spielen hoffentlich eher der Vergangenheit an.

[Xmas]

Sorry, war nicht eingeloggt. Das da oben war von mir

[nggalai]

Ich schliesse mich XMas vollumfänglich an. Weshalb vertex lighting wenn man besser und einfacher mit shadowmaps und pixelshadern durchkommt?

ta,
.rb

[Ceiser Söze]

Vertex Lighting ist aus dem einfachen Grund schöner, weil im Gegensatz zu den Lightmap-Verfahren kombiniert mit dem üblichen (Software-)Ambient-Lighting auch die Entfernung der Fläche zur Lichtquelle berücksichtigt wird. Ausserdem kann man mit Vertex-Lighting auch speziellere "Lichtsorten" wie Diffuse-, Specular- und Spot-Lighting realisieren.
Aktuelles Lighting per Lightmapping ist einfach nicht realistisch, weil es keine Nuancen bietet: Ein Objekt ist entweder hell, dunkel, oder irgendetwas dazwischen - mehr nicht. Aber es reflektiert kein Licht, es hat keine Glanzpunkte etc. Es wirkt irgendwie langweilig.
Solche Dinge lassen sich nur mit einer guten Implementierung von Vertex-Lighting realisieren und sehen auch viel besser aus (schaut euch z.B. mal die Firetruck-Demo von nVidia an, denn da kommt Specular Lighting zum Einsatz). Natürlich braucht es mehr Polygone für schönes Vertex-Lighting, aber wenn das olle ambient Lighting nur schon durch ein Uniform Lighting ersetzen würde, sähe das Ganze schon viel besser aus...

Und: Bitte verwechselt Vertex Lighting(!) nicht mit Gouraud Shading(!). Shading und Lighting sind zwei ganz verschiedene Paar Schuhe ;)

[Grasso]

<cite><pre> Ich setze da übrigens grosse Hoffnungen auf PowerVR. Deren
T&L-Unit (Elan), die im NaomiII zum Einsatz kam, konnte
mehrere Lichtquellen gleichzeitig berechnen, ohne dass die
Dreiecksperformance in den Keller sackte. Es besteht kein Grund
zu glauben, dass PowerVR das nicht auch für den PC realisieren
könnte...
</pre></cite>

PowerVR wird mit T&L-Implementation der Kyro III wohl keine großen Probleme haben. Bei der Sega Dreamcast, die auch einen PowerVR-Renderer hatte, wurde T&L noch von der DSP/SIMD-Engine der SuperH-CPU erledigt, und bei einer so eng spezifizierten und optimierten Plattform wie einer Spielekonsole findet doch eine Menge Technologietransfer statt. PowerVR haben einfach die Connections und das Know-how, im
Gegensatz zu nVidias aufwendigem Try-and-error, das von den Usern und seit der Entwicklung der Xbox auch von M$ und den Spieleschmieden gesponsort werden muß, damit überhaupt etwas funktionsfähiges oder gar zukunftsfähiges (hu hu!) rauskommt.

[Grasso]

PowerVR sind auch deshalb so spät mit T&L für die PC-Plattform, weil sie lieber erst abwarten, bis sich eine brauchtbare Architektur herauskristallisiert hat, bis also nVidia, M$ und Co. DirectX8 unter sich ausgemacht haben. Alles andere würde die Kapazitäten von PowerVR´s Treiber- als auch PR-Abteilung übersteigen.

Der Vorgänger der Kyro, der Neon250, soll nicht gerade berauschende Treiber gehabt haben, aber zur Zeit sind PowerVR doch wesentlich orientierter als nVidia, das betrifft auch http://grassomusic.de/deutsch/contentframe.htm?video.htm&proof : das Multitasking

Wer noch auf nVidia setzt, hat entweder Aktien von denen, kein Hirn, oder lebt hinterm Mond.

[Thowe]

@Grasso

keine Angst, wir hören dir zu.

[Xmas]

Originally posted by Ceiser Söze
Vertex Lighting ist aus dem einfachen Grund schöner, weil im Gegensatz zu den Lightmap-Verfahren kombiniert mit dem üblichen (Software-)Ambient-Lighting auch die Entfernung der Fläche zur Lichtquelle berücksichtigt wird.
Erst mal vorweg: ich habe gar nicht von Lightmaps, sondern von Pixel Shading gesprochen...
Lightmaps werden üblicherweise vorberechnet, also wird durchaus die Entfernung zur Lichquelle berücksichtigt. Allerdings setzt das Vorberechnen natürlich statische Lichtquellen voraus. Dynamische Lightmaps sind dagegen ziemlich rechenintensiv, deshalb braucht man hier Näherungsfunktionen. 3D-Lightmaps sind ein Lösungsansatz, brauchen allerdings viel Speicherplatz (sind aber auch für viele Lichtquellen identisch).
Ausserdem kann man mit Vertex-Lighting auch speziellere "Lichtsorten" wie Diffuse-, Specular- und Spot-Lighting realisieren.

Hier vermischst du was. Es gibt einerseits die "Lichtsorten" Ambient, Diffuse und Specular, und andererseis die "Lichtquellensorten" Spot, Directional und Point. Specular Highlights erfordern aber enorm viele winzige Dreiecke, um gut auszusehen. Hast du schon mal versucht, eine Kugel aus 20000 Dreiecken mit Vertex Lighting darzustellen? Sieht recht gut aus (aber noch lange nicht perfekt!), allerdings könnte man das auch besser machen ;)
Auch mit Pixel Shader kann man Diffuse und Specular Lighting berechnen - und zwar pro Pixel, nicht pro Eckpunkt. Also sieht es logischerweise besser aus. Und wenn kein PS vorhanden ist, greift man eben auf Dot3 Bump Mapping (diffuse) und EMBM (specular, mit spezieller Textur) zurück, mit Einschränkungen. PS ermöglicht zudem viel interessantere Lichtmodelle.

Aktuelles Lighting per Lightmapping ist einfach nicht realistisch, weil es keine Nuancen bietet: Ein Objekt ist entweder hell, dunkel, oder irgendetwas dazwischen - mehr nicht. Aber es reflektiert kein Licht, es hat keine Glanzpunkte etc. Es wirkt irgendwie langweilig.
"Aktuelles" Vertex Lighting wirkt genauso langweilig, weil die geometrische Auflösung viel zu niedrig ist. Quake 3 sieht mit Lightmaps jedenfalls viel besser aus als mit Vertex Lighting. Zudem kann man mit Lightmaps gewissermaßen auch Schatten darstellen.

Solche Dinge lassen sich nur mit einer guten Implementierung von Vertex-Lighting realisieren und sehen auch viel besser aus (schaut euch z.B. mal die Firetruck-Demo von nVidia an, denn da kommt Specular Lighting zum Einsatz). Natürlich braucht es mehr Polygone für schönes Vertex-Lighting, aber wenn das olle ambient Lighting nur schon durch ein Uniform Lighting ersetzen würde, sähe das Ganze schon viel besser aus...
Nein, sowas lässt sich auch anders und besser implementieren. Wo wird denn nur ambient Lighting eingesetzt??? Wenn du schon mal die NVidia-Demos erwähnst, geh doch mal auf die NV-Developer-Seite und schau dir an was dort an Per-Pixel-Lighting Demos zum Download bereit steht ;)
[/B]Und: Bitte verwechselt Vertex Lighting(!) nicht mit Gouraud Shading(!). Shading und Lighting sind zwei ganz verschiedene Paar Schuhe ;) [/B]
Diese Gleichsetzung habe ich mit voller Absicht getan. Ich kenne den Unterschied zwischen Lighting und Shading. Aber: Vertex Lighting berechnet Lichtwerte pro Eckpunkt. Um ein Dreieck zu rendern, müssen diese Lichtwerte über das Dreieck interpoliert werden. Allgemein wird hier linear (bzw. perspektivisch korrigiert linear) interpoliert, und das ist Gouraud Shading. Man kann auch nichtlinear interpolieren, aber das wird in der Praxis nicht getan.
Beides zusammen hat den Nachteil, dass Highlights nur an den Eckpunkten vorkommen können.
Phong Shading erfordert Lichtberechnungen pro Pixel.

[Ceiser Söze]

Das Problem mit der zu niedrigen Geometriekomplexität lässt sich eigentlich schnell lösen und zwar durch eine automatische, TruForm-ähnliche Tesselation der eigentlichen Dreiecke in viele kleinere Versionen (TruForm ohne Krümmung der Flächen halt *g*) . Es werden in der nächsten 2 Jahren sowieso kaum Spiele erscheinen, die T&L-limitiert sein werden, hier wäre also Leistung zum Verbraten da (vorausgesetzt, die Lighting-Unit hat was drauf - was leider noch nicht der Fall ist :( ).

Was mich an Pixel Shading & Co. stört: Es kostet verdammt viel Füllrate und die steht nach der Bandbreite an zweiter Stelle in der Liste der "sparsam zu verwendenden Ressourcen" ;) Mit Vertex Lighting können hier Ressourcen gespart werden (nicht nur an Füllrate, sondern auch an Bandbreite, da weniger Texturen verwendet werden müssen).

Ich will Pixel Shading & Co. nicht schlecht machen, aber es ist zweifellos kein Ersatz für Vertex Lighting - genauso, wie Vertex Lighting kein Ersatz für Pixel Shading ist. Am besten ist natürlich, wenn wir beides haben...

[Xmas]

Originally posted by Ceiser Söze
Was mich an Pixel Shading & Co. stört: Es kostet verdammt viel Füllrate und die steht nach der Bandbreite an zweiter Stelle in der Liste der "sparsam zu verwendenden Ressourcen" ;) Mit Vertex Lighting können hier Ressourcen gespart werden (nicht nur an Füllrate, sondern auch an Bandbreite, da weniger Texturen verwendet werden müssen).

Das ist richtig, und wenn die Hardware schon die Möglichkeit bietet, einen interpolierten Farbwert "umsonst" in den Blending-Prozess einzubeziehen, dann sollte man das auch ausnutzen :D.
Allerdings kommt man bei der Füllrate an den Punkt an dem man sagt: Ich hab genug Füllrate und Bandbreite, um eine "normale" Szene in 1280x1024x32 und einer Tiefenkomplexität von 3 mit 60 fps darstellen zu können. Was nun?
Als erstes auf der Wunschliste stehen wohl MSAA und anisotropic Filtering. Und dann?
Höhere Auflösung? (Bei heutigen Monitoren ist bei 1600x1200 Schluss)
Mehr Objekte? (Bei TBR kaum aufwändiger)
Detailiertere Objekte? (Kostet wenig Render- aber viel Geometrieleistung)
Realistischere Oberflächen? (Pixel Shader, Bump Mapping)
"Echte" Schatten und Reflexionen? (Texturen rendern - das haut rein!)
Motion Blur?

Und Pixel Shader ist dabei sicherlich nicht die schlechteste Wahl ;)

[Unregistered]

seit ihr nur alle post süchtig? =)