interessanter T&L-Review
Thomas Markert
hab ich grad auf www.3dcenter gefunden...sehr interessant muss ich
sagen, und vor allem objektiv finde ich
http://www.3dcenter.de/artikel/t_und_l/
cu Thomas
Sascha Erni, .rb
hey, cool. Danke für den Link. Ich habe mich selten so über einen
Theorie-Bericht amüsiert. Ist doch sehr Voodoo-bezogen geschrieben,
und dass er TnL mit FSAA vergleicht will mir echt nicht in den Kopf.
Grundsätzlich hat der Autor ja recht mit seinen Aussagen betreffend
Sinnfreiheit von DX7-style TnL für Neuanschaffungen, hat aber einige
ganz grobe Patzer eingebaut. Den hier fand' ich besonders gut:
"20 oder 31 fps sind das Ergebnis zweier unterschiedlicher Karten (GTS
vs. V5) im Rollenspiel U9. (Gemessen wurde in 1024x768x32 unter DX7).
T&L kam dabei nicht zum Einsatz. Die Karte ohne T&L-Support zieht hier
dank anderer Schmankerl (wie effektivere Bandbreitennutzung) souverän
an der Karte mit T&L-Support vorbei."
Ja, sicher. Und das U9 für Glide entwickelt und erst deutlich später
(mangelhaft) auf D3D gehoben wurde ist ja egal ... :)
Aber trotzdem: danke nochmals.
ta,
.rb
Thomas Markert
<ngg...@hotmail.com> wrote:
>"20 oder 31 fps sind das Ergebnis zweier unterschiedlicher Karten (GTS
>vs. V5) im Rollenspiel U9. (Gemessen wurde in 1024x768x32 unter DX7).
>T&L kam dabei nicht zum Einsatz. Die Karte ohne T&L-Support zieht hier
>dank anderer Schmankerl (wie effektivere Bandbreitennutzung) souverän
>an der Karte mit T&L-Support vorbei."
>
>Ja, sicher. Und das U9 für Glide entwickelt und erst deutlich später
>(mangelhaft) auf D3D gehoben wurde ist ja egal ... :)
hehe, der iss mir auch aufgefallen, da werden Äpfel mit Birnen
verglichen, aber sonst fand ich das was über T&L gesagt wurde sehr
passend...das mit den Voodoos, naja, er war wahrscheinlich ein Freund
der guten alten Voodoo-Karten ;-)
cu Thomas
Marcus Heuser
"Sascha Erni, .rb" <ngg...@hotmail.com> schrieb:
>
> Grundsätzlich hat der Autor ja recht mit seinen Aussagen betreffend
> Sinnfreiheit von DX7-style TnL für Neuanschaffungen, hat aber einige
> ganz grobe Patzer eingebaut. Den hier fand' ich besonders gut:
>
> "20 oder 31 fps sind das Ergebnis zweier unterschiedlicher Karten (GTS
> vs. V5) im Rollenspiel U9. (Gemessen wurde in 1024x768x32 unter DX7).
> T&L kam dabei nicht zum Einsatz. Die Karte ohne T&L-Support zieht hier
> dank anderer Schmankerl (wie effektivere Bandbreitennutzung) souverän
> an der Karte mit T&L-Support vorbei."
Zumal dann zur GF256 folgendes steht:
"Damit gibt es Füllrate satt, nämlich (bei den 120 MHz Chiptakt) 480
Megapixel. Der RAM lief mit 166 MHz SDRAM, die DDR-Versionen gar
mit 150 MHz DDR-RAM, so dass für damalige Zeiten anständige Speicher-
bandbreiten von 2,5 GB/s bzw. 4,5 GB/s verwirklicht wurden. Die Karte war
aufgrund ihrer Rohpower so schnell."
bye
Marcus
Daniel Lichtenberger
wrote:
Entweder hat der Urlaub meine Wahrnehmung nachhaltig verändert, oder
der Artikel ist tatsächlich so verbohrt und wärmt unnötig alte Zeiten
wieder auf. ;-)
Das wurde eigentlich alles schon x-mal durchgekaut, und eine (pardon)
Minimal-Innovation wie S3TC mit einer T&L-Pipeline zu vergleichen, ist
schon etwas gewagt; manche Punkte wie der MX-Dreiecksdurchsatz werden
auch nicht gerade einwandfrei widerlegt (mit triangle strips kann man
sehr wohl mit rund einem Eckpunkt pro Dreieck auskommen), davon
abgesehen erreicht sowieso keine Karte die Peak-Werte in der Realität.
Über den Sinn und Unsinn von DX7-T&L läßt sich wunderbar streiten,
nachdem entsprechende Chips mittlerweile aber überall verramscht
werden, sehe ich nicht viel Sinn darin, sich darüber noch den Kopf zu
zerbrechen. Viel interessanter fände ich da die Vertex-Shader-Leistung
der GF3, die gemessen an GHz-Athlonen (vom Preis her) und dem
getriebenen HW-Aufwand anscheinend recht schlecht ausfällt.
bye
-Daniel
--
HP: http://danielshome.cjb.net / UIN: 30333508
ToG: http://www.topofgames.de - Reviews, Previews, Specials
Thomas Eßer
> Theorie-Bericht amüsiert. Ist doch sehr Voodoo-bezogen geschrieben,
Wenn es um Historie geht, dürfte es eher schwer sein an 3dfx
vorbei zu kommen. Das im weiteren Verlauf einiges von dem Marketing-
geblubber ins Normaldeutsch übersetzt wird ist ebensowenig daneben
wie die Tatsache, das TnL nach DX7 deutlich überbewertet wird.
> "20 oder 31 fps sind das Ergebnis zweier unterschiedlicher Karten (GTS
> vs. V5) im Rollenspiel U9. (Gemessen wurde in 1024x768x32 unter DX7).
> T&L kam dabei nicht zum Einsatz. Die Karte ohne T&L-Support zieht hier
> dank anderer Schmankerl (wie effektivere Bandbreitennutzung) souverän
> an der Karte mit T&L-Support vorbei."
>
> Ja, sicher. Und das U9 für Glide entwickelt und erst deutlich später
> (mangelhaft) auf D3D gehoben wurde ist ja egal ... :)
Die V5 wird afaik ebenfalls unter _D3d_ gemessen und ist wegen der
etwas effizienterern Anbindung und sicherlich der für diesen Fall
besser optimierten 3dfx Treiber deutlich schneller. Auch UT z.b.
sieht selbst mit dem anerkannten eher mäßigen D3D Support auf einem
VSA-100 besser aus und ist schneller als ein vergleichbarer GF1/2.
Mit Glide hat das ganze nichts zu tun, da wäre die V5 sicherlich
noch weiter im Vorteil. Ich kann da nichts falsches oder komisches dran
entdecken, im Gegenteil - in diesem Artikel steht einiges an Wahrheiten ...
Thomas Eßer
> hehe, der iss mir auch aufgefallen, da werden Äpfel mit Birnen
V5 und GF, beide mit D3D - wo sind da die Äpfel, wo sind die
Birnen?
Sascha Erni, .rb
"Thomas Eßer" <sa...@gmx.net> schrieb ...
> Wenn es um Historie geht, dürfte es eher schwer sein an 3dfx
> vorbei zu kommen. Das im weiteren Verlauf einiges von dem Marketing-
> geblubber ins Normaldeutsch übersetzt wird ist ebensowenig daneben
> wie die Tatsache, das TnL nach DX7 deutlich überbewertet wird.
Sagt ja auch niemand was anderes. :) Grundsätzlich steh ich hinter
dem Artikel. War interessant, amüsant, und hatte nicht allzuviele
Fehlschlüsse drin. Sowas findet man seit 3DConcepts ableben heute eher
selten.
> > Ja, sicher. Und das U9 für Glide entwickelt und erst deutlich
später
> > (mangelhaft) auf D3D gehoben wurde ist ja egal ... :)
>
> Die V5 wird afaik ebenfalls unter _D3d_ gemessen und ist wegen der
> etwas effizienterern Anbindung und sicherlich der für diesen Fall
> besser optimierten 3dfx Treiber deutlich schneller. Auch UT z.b.
> sieht selbst mit dem anerkannten eher mäßigen D3D Support auf einem
> VSA-100 besser aus und ist schneller als ein vergleichbarer GF1/2.
> Mit Glide hat das ganze nichts zu tun, da wäre die V5 sicherlich
> noch weiter im Vorteil. Ich kann da nichts falsches oder komisches
dran
> entdecken, im Gegenteil - in diesem Artikel steht einiges an
Wahrheiten ...
Das "Falsche daran," wenn ich deine Wortwahl weiterverwende, ist, dass
einerseits der Artikel rummotzt, dass man nur Benchmarks verwendet,
die auf nVidia / TnL optimiert wurden, andererseits dann eine der
schlechtesten D3D Engines aller Zeiten verwendet, die dazu noch vom
Code her auf Glide fusst und wohl einige Voodoo-Eigenheiten (Register
Combinations, Textur Management, etc.) "geerbt" hat. Und die
Schlussfolgerung, dass die V5 in Ultima9 wegen besserer
Bandbreite/-ausnutzung schneller als eine GTS sei ist einfach nur
falsch. Dann wäre die GeForce3 massiv schneller als eine GTS (was sie
nicht ist, bei U9). Die GTS, MX, und GF3 sind mit U9 praktisch
gleichschnell. Ich habe mich also darüber amüsiert wie a) der gleiche
Fehler wie von der TnL Konkurrenz gemacht wird, beim Benchen, und b)
die Erklärung für den Performance-Unterschied extremst an den Haaren
herbeigezogen wurde.
Wie schon gesagt, grundsätzlich bin ich mitm Autoren einer Meinung.
Hab' ja auch nicht ohne Grund meine MX durch eine Kyro-II
ausgetauscht. Es kam noch einiges gutes Feed-back zum Artikel
zusammen, leider auch wieder haltloses Gefasel einiger nVidia- und
3dFX Jünger, kann man hier bei Bedarf nachlesen:
http://www.3dcenter.de/vbulletin/showthread.php?s=&threadid=3369
http://www.3dcenter.de/vbulletin/showthread.php?s=&threadid=3372
http://www.3dcenter.de/vbulletin/showthread.php?s=&threadid=3394
(Wie üblich können sich Forums-Benutzer nicht auf einen Thread
einigen.)
ta,
.rb
Thomas Eßer
> Entweder hat der Urlaub meine Wahrnehmung nachhaltig verändert, oder
> der Artikel ist tatsächlich so verbohrt und wärmt unnötig alte Zeiten
> wieder auf. ;-)
Man liest aber ziemlich selten - neben den allwärtigen Beweihräucher-
aktionen - etwas derartiges im Web. Das das hier nichts neues ist,
dürfte dem geneigtem Leser schon klar sein :). Ich behaupte auch
heute noch, das 3dfx weniger an der angeblich 'schwachen' Technologie
kaputt gegangen ist, sondern an einer unfähigen Marketingabteilung.
> Das wurde eigentlich alles schon x-mal durchgekaut, und eine (pardon)
> Minimal-Innovation wie S3TC mit einer T&L-Pipeline zu vergleichen, ist
Gemessen an dem was es bringt liegt es auch nicht weit davon weg, T&L
ist schließlich auch nichts neues ;). Innovation im Sinne von 'bringt
was' würde ich auch eher bei FSAA sehen - im wahrsten Sinne des Wortes.
> schon etwas gewagt; manche Punkte wie der MX-Dreiecksdurchsatz werden
> auch nicht gerade einwandfrei widerlegt (mit triangle strips kann man
> sehr wohl mit rund einem Eckpunkt pro Dreieck auskommen), davon
Sicher kann man - nur ist das bezogen auf tatsächliche Spiele nicht
realistisch. Fans und Stripes gab es schließlich auch schon früher,
allerdings liegt das Limit ja
> abgesehen erreicht sowieso keine Karte die Peak-Werte in der Realität.
ganz woanders ;). Niemand kauft einen Wagen mit 300 PS der ab 100 km/h
abregelt. Bei Grafikkarten ist dies ja wie bekannt völlig anders :).
> Über den Sinn und Unsinn von DX7-T&L läßt sich wunderbar streiten,
> nachdem entsprechende Chips mittlerweile aber überall verramscht
> werden, sehe ich nicht viel Sinn darin, sich darüber noch den Kopf zu
Außer in der Theorie bringt es nichts ;).
> zerbrechen. Viel interessanter fände ich da die Vertex-Shader-Leistung
> der GF3, die gemessen an GHz-Athlonen (vom Preis her) und dem
> getriebenen HW-Aufwand anscheinend recht schlecht ausfällt.
NACK. Da es - außer in sinnfreien und beweisarmen Techdemos - immer noch
an DX8+ Software mangelt (Wo sind doch gleich die ganzen GF3 optimierten
Spiele;) läßt sich das jetzt noch nicht klären. Aber für eine Emulation
von Pixel- und Vertexshadern dürfte eine derzeitige CPU nicht ausreichen,
zumindest dann nicht, wenn die Qualität erhalten bleiben soll. Allerdings
glaube ich auch, das es trotz der kommenden Konkurenz (ATI, ...) noch
reichlich lange dauern wird, bevor sich da überhaupt etwas tut. Analog
halt zum DX7 T&L - Karten für unter weit 200.- Emmchen erzeugen halt immer
noch keine Software ...
Gruß,
Thomas
Thomas Eßer
> schlechtesten D3D Engines aller Zeiten verwendet, die dazu noch vom
> Code her auf Glide fusst und wohl einige Voodoo-Eigenheiten (Register
Was - außer der extreme Speicherverbrauch in Sachen Texturing - ist
an der Engine schlecht? Die Optik ist klasse und die vermeintliche
Glidelastigkeit erklärt ebenfalls nicht, warum auch andere nicht 3dfx
Grafikkarten bei U9 im Verhältnis zu anderen Spielen besser als NVidias
Chips aussehen.
> Combinations, Textur Management, etc.) "geerbt" hat. Und die
> Schlussfolgerung, dass die V5 in Ultima9 wegen besserer
> Bandbreite/-ausnutzung schneller als eine GTS sei ist einfach nur
> falsch. Dann wäre die GeForce3 massiv schneller als eine GTS (was sie
Wäre sie - wenn bessere Treiber zur Verfügung stehen würden. NVidia
ignoriert bis heute diverse Texturmodi, in manchen Treibern werden
diese aufwendig emuliert, in manchen sind diese schlicht abgeschaltet.
> nicht ist, bei U9). Die GTS, MX, und GF3 sind mit U9 praktisch
> gleichschnell. Ich habe mich also darüber amüsiert wie a) der gleiche
Was zeigt, daß das Limit nicht in der Hardware zu suchen ist, sondern
eher in miesen Treibern und/oder fehlenden Hardwarefeatures. FF7 ist
auch so ein Beispiel ;).
> Fehler wie von der TnL Konkurrenz gemacht wird, beim Benchen, und b)
> die Erklärung für den Performance-Unterschied extremst an den Haaren
> herbeigezogen wurde.
Für so extrem halte ich das nicht.
Daniel Lichtenberger
>Man liest aber ziemlich selten - neben den allwärtigen Beweihräucher-
>aktionen - etwas derartiges im Web.
Stimmt. Die Beweihräucher-Aktionen nehme ich wohl mittlerweile gar
nicht mehr wahr ;-).
>Das das hier nichts neues ist,
>dürfte dem geneigtem Leser schon klar sein :). Ich behaupte auch
>heute noch, das 3dfx weniger an der angeblich 'schwachen' Technologie
>kaputt gegangen ist, sondern an einer unfähigen Marketingabteilung.
Ack.
>> Das wurde eigentlich alles schon x-mal durchgekaut, und eine (pardon)
>> Minimal-Innovation wie S3TC mit einer T&L-Pipeline zu vergleichen, ist
>
>Gemessen an dem was es bringt liegt es auch nicht weit davon weg, T&L
>ist schließlich auch nichts neues ;).
Stimmt, aber ohne mich jetzt zu weit aus dem Fenster lehnen zu wollen,
ist der Entwicklungsaufwand für eine T&L-Einheit vermutlich um
Größenordnungen höher als für eine relativ einfache Erweiterung wie
S3TC.
>Innovation im Sinne von 'bringt
>was' würde ich auch eher bei FSAA sehen - im wahrsten Sinne des Wortes.
Solange man nVidia'sches Software-Supersampling nicht dazuzählt,
schon. ;) Wirklich schade, daß das RGSS von 3dfx in der Versenkung
verschwunden ist...
>Sicher kann man - nur ist das bezogen auf tatsächliche Spiele nicht
>realistisch.
Hat ja auch keiner behauptet. ;)
>ganz woanders ;). Niemand kauft einen Wagen mit 300 PS der ab 100 km/h
>abregelt. Bei Grafikkarten
...und dem PC-Markt im allgemeinen...
>ist dies ja wie bekannt völlig anders :).
Ist schon klar, daß es die T&L-Fähigkeiten eines Chips ad absurdum
führt, wenn man ihm ein 64-Bit-Speicherinterface spendiert, aber
anscheinend überlebt man im Grafikmarkt sonst nicht - siehe 3dfx...
>NACK. Da es - außer in sinnfreien und beweisarmen Techdemos - immer noch
>an DX8+ Software mangelt (Wo sind doch gleich die ganzen GF3 optimierten
>Spiele;) läßt sich das jetzt noch nicht klären.
Deswegen wäre es ja so interessant ;). Müßte halt jemand ein bißchen
was programmieren ... am besten mit Kommandozeilen-Interface, damit es
in keinen Web-Reviews für Grakas verwendet wird. ;)
>Aber für eine Emulation
>von Pixel- und Vertexshadern dürfte eine derzeitige CPU nicht ausreichen,
>zumindest dann nicht, wenn die Qualität erhalten bleiben soll.
Für Pixelshader natürlich nicht (dann wäre man ja wieder bei
Software-Rendering angelangt), aber Vertex-Shader sollen dem Vernehmen
nach von Intel und AMD hübsch optimiert worden sein.
>Allerdings
>glaube ich auch, das es trotz der kommenden Konkurenz (ATI, ...) noch
>reichlich lange dauern wird, bevor sich da überhaupt etwas tut. Analog
>halt zum DX7 T&L - Karten für unter weit 200.- Emmchen erzeugen halt immer
>noch keine Software ...
Ich glaube auch nicht, daß es in den nächsten 12 Monaten eine
signifikante Anzahl an echten DX8-Spielen geben wird... es wird auch
interessant sein, wieviele von den ersten xBox-Titeln von den
Vertex/Pixelshadern wirklich Gebrauch machen.
Daniel Lichtenberger
<ngg...@hotmail.com> wrote:
>Das "Falsche daran," wenn ich deine Wortwahl weiterverwende, ist, dass
>einerseits der Artikel rummotzt, dass man nur Benchmarks verwendet,
>die auf nVidia / TnL optimiert wurden, andererseits dann eine der
>schlechtesten D3D Engines aller Zeiten verwendet, die dazu noch vom
>Code her auf Glide fusst und wohl einige Voodoo-Eigenheiten (Register
>Combinations, Textur Management, etc.) "geerbt" hat.
Umgekehrt kann man die Quake3-Engine aber auch als "nVidia-optimiert"
bezeichnen, aus den bekannten Gründen. Ich glaube auch nicht, daß die
UT-Engine in ihrer D3D-Version irgendwelche Voodoo-Eigenheiten geerbt
hat, außer daß manche Sachen auf nVidia-Karten eben nicht oder nicht
ordentlich funktionieren (8-Bit-Texturen gibt's imho immer noch
nicht). Der von Thomas angesprochene Speicherverbrauch von Texturen
ist allerdings wirklich problematisch (vor allem bei Sachen wie
Tactical Ops 2, wenn man "nur" 32 MB hat).
>Und die
>Schlussfolgerung, dass die V5 in Ultima9 wegen besserer
>Bandbreite/-ausnutzung schneller als eine GTS sei ist einfach nur
>falsch.
Jep...
>ta,
>.rb
Sascha Erni, .rb
"Daniel Lichtenberger" <daniel.lic...@gmx.net> schrieb ...
> Umgekehrt kann man die Quake3-Engine aber auch als
"nVidia-optimiert"
> bezeichnen, aus den bekannten Gründen.
*nickt* ja. Allerdings gibt's beutend mehr Spiele, die mit der Q3
Engine laufen als mit der U9 Engine. (Q3, U9 ... LOL.) Andererseits
ist Ultima 9 ein guter Textur-Performance Benchmark, auch wenn's in
dem Zusammenhang bessere Spiele für gibt, mit besseren
Benchmark-Funktionen und moderneren Engines. Serious Sam zum Beispiel.
Grundsätzlich bin ich aber eg gegen vergleichende Spiele-Benchmarks in
der Form, wie sie die ganze Zeit durchgeführt werden--ihr wisst schon,
"Karte X ist 25fps schneller als Karte Y" mit 3 Spielen und dem
3DMark. Wenn's nach mir ginge, würden--falls überhaupt--mindestens 12
verschiedene, aktuelle Spiele getestet werden, und zwar nicht auf das
Frame genau, sondern nachm Motto "Q3 läuft bei 1024x768x32 flüssig auf
unseren Systemen, mit anisotropischem Filtern bricht die Performance
nicht nennenswert ein, FSAA geht auch in Ordnung." Aber das wird jetzt
doch zu OT. :)
ta,
.rb
Daniel Lichtenberger
On Mon, 20 Aug 2001 21:51:21 +0200, "Sascha Erni, .rb"
<ngg...@hotmail.com> wrote:
>*nickt* ja. Allerdings gibt's beutend mehr Spiele, die mit der Q3
>Engine laufen als mit der U9 Engine.
...was mich nicht grundsätzlich stört. ;-)
>Grundsätzlich bin ich aber eg gegen vergleichende Spiele-Benchmarks in
>der Form, wie sie die ganze Zeit durchgeführt werden--ihr wisst schon,
>"Karte X ist 25fps schneller als Karte Y" mit 3 Spielen und dem
>3DMark. Wenn's nach mir ginge, würden--falls überhaupt--mindestens 12
>verschiedene, aktuelle Spiele getestet werden, und zwar nicht auf das
>Frame genau, sondern nachm Motto "Q3 läuft bei 1024x768x32 flüssig auf
>unseren Systemen, mit anisotropischem Filtern bricht die Performance
>nicht nennenswert ein, FSAA geht auch in Ordnung." Aber das wird jetzt
>doch zu OT. :)
Ack, ack. :)
Raphael Pilarczyk
Bet: "Re: interessanter T&L-Review"
> Man liest aber ziemlich selten - neben den allwärtigen Beweihräucher-
> aktionen - etwas derartiges im Web. Das das hier nichts neues ist,
> dürfte dem geneigtem Leser schon klar sein :). Ich behaupte auch
> heute noch, das 3dfx weniger an der angeblich 'schwachen' Technologie
> kaputt gegangen ist, sondern an einer unfähigen Marketingabteilung.
Die technologie war nicht so schwach, aber sie kam zu spaet
und war im Preis/Leistung vergleichsweise SEHR teuer.
Abgesehen davon haben Sachen wie Rush und Banshee dem Image
geschadet. Richtig.
--
PIK
Thomas Markert
hi
>> hehe, der iss mir auch aufgefallen, da werden Äpfel mit Birnen
>
>V5 und GF, beide mit D3D - wo sind da die Äpfel, wo sind die
>Birnen?
na die Voodoo wird Glide nutzen und die die GF wird D3D nutzen, da
aber D3D erst im nachhinein integriert wurde läuft es nicht so
optimal...
und man daher keine Rückschlüsse auf die Graka Geschwindigkeit ziehen,
eiegntlich nur wenn beide Karten die gleiche Api nutzen...
cu Thomas
Thorsten Lange
> hab ich grad auf www.3dcenter gefunden...sehr interessant muss ich
> sagen, und vor allem objektiv finde ich
Weder objektiv noch sachlich richtig. Da hat einfach nur jemand seinen
Advocacy-Trieb ausgelebt.
Bye,
Thorsten
Martin Kuras
> >V5 und GF, beide mit D3D - wo sind da die Äpfel, wo sind die
> >Birnen?
>
> na die Voodoo wird Glide nutzen und die die GF wird D3D nutzen, da
> aber D3D erst im nachhinein integriert wurde läuft es nicht so
> optimal...
>
> und man daher keine Rückschlüsse auf die Graka Geschwindigkeit ziehen,
> eiegntlich nur wenn beide Karten die gleiche Api nutzen...
Wer lesen kann ist klar im Vorteil.
Gruß Martin
--
Alle Verallgemeinerungen sind falsch!
Thomas Eßer
> Weder objektiv noch sachlich richtig. Da hat einfach nur jemand seinen
> Advocacy-Trieb ausgelebt.
Was ist angeblich /nicht/ objektiv und sachlich falsch?
Ohne entsprechende Hinweise fällt es eher schwer, solche
Sprüche nicht als Schwätzerei abzutun ...
Thomas Eßer
> Stimmt. Die Beweihräucher-Aktionen nehme ich wohl mittlerweile gar
> nicht mehr wahr ;-).
Hah - Abstumpfung :).
[T&L vs. S3TC]
> Stimmt, aber ohne mich jetzt zu weit aus dem Fenster lehnen zu wollen,
> ist der Entwicklungsaufwand für eine T&L-Einheit vermutlich um
> Größenordnungen höher als für eine relativ einfache Erweiterung wie
> S3TC.
Weiß ich nicht. Das bißchen festverdrahtete Logik wird so oder so nicht
allzu aufwendig sein, zumal es sich ja in beiden Fällem immer wieder
recyceln läßt. Allerdings hat es NV selbst beim GF3 nicht geschafft,
die Dekompression fehlfrei hinzubekommen :). So trivial scheint das
also auch nicht zu sein. Von der Anzahl der Transistoren würde ich
eine T&L Einheit aber auch vorne sehen, insbesondere wegen des nie
benötigten 'L'.
>> Innovation im Sinne von 'bringt
>> was' würde ich auch eher bei FSAA sehen - im wahrsten Sinne des Wortes.
>
> Solange man nVidia'sches Software-Supersampling nicht dazuzählt,
> schon. ;) Wirklich schade, daß das RGSS von 3dfx in der Versenkung
> verschwunden ist...
Kommt ja vielleicht unter neuem Namen wieder, wenn NV den 3dfx
Patentfundus auswertet. Vielleicht schon im X-Box Chip, da würde
es ob der geringen Konsolenauflösung sogar Sinn machen. Obwohl,
PAL oder NTSC Fernseher haben ja FSAA on Board ;).
[Pixel & Vertex vs. CPU]
> Für Pixelshader natürlich nicht (dann wäre man ja wieder bei
> Software-Rendering angelangt), aber Vertex-Shader sollen dem Vernehmen
> nach von Intel und AMD hübsch optimiert worden sein.
Da ließe ich via SSE,3d Now ect. sicher viel machen. Allerdings
müssen dann die Texturen im Rechner RAM bearbeitet werden und erst
wenn alles durchgerechnet ist zur Grafikkarte transferriert werden.
Sobald die Grafikkarte an den Texturen rumbasteln muß, dürfte
es ziemlich eng werden. Komprimierte Texturen gibt es dann
ebenfalls nicht mehr. Macht imo keinen richtigen Sinn.
> Ich glaube auch nicht, daß es in den nächsten 12 Monaten eine
> signifikante Anzahl an echten DX8-Spielen geben wird... es wird auch
> interessant sein, wieviele von den ersten xBox-Titeln von den
> Vertex/Pixelshadern wirklich Gebrauch machen.
Ack. Same procedure as last year ;). Einige Knaller sicher,
vielleicht sogar ziemlich viele - nur was davon dann wie auf
den PC portiert werden wird dürfte spannend werden. Konsole
und PC sind spieletechnisch halt 2 paar Schuhe und wenn man
sich so einige Umsetzungen ansieht .. grusel ...
Gruß,
Thomas
Thomas Eßer
>> V5 und GF, beide mit D3D - wo sind da die Äpfel, wo sind die
>> Birnen?
>
> na die Voodoo wird Glide nutzen und die die GF wird D3D nutzen, da
Zum dritten Mal - _beide_ Karten laufen unter D3D, trotzdem ist die
V5 trotz besserer Papierform unter U9 deutlich schneller. Das kann
a.) an der Hardware liegen und b.) an den immer noch nicht so tollen
NVidia Treibern, speziell bei Spielen abseits des Mainstream. Ich tippe
auf eine Mischform von a und b.
> und man daher keine Rückschlüsse auf die Graka Geschwindigkeit ziehen,
> eiegntlich nur wenn beide Karten die gleiche Api nutzen...
Eben. Und genau das wird da gemacht ...
Gruß,
Thomas
Thorsten Lange
> > Weder objektiv noch sachlich richtig. Da hat einfach nur jemand seinen
> > Advocacy-Trieb ausgelebt.
>
> Was ist angeblich /nicht/ objektiv und sachlich falsch?
Dieser Artikel erscheint in meinen Augen wenig objektiv, weil
Formulierungen wie "nVidia-Propaganda" doch etwas - sagen wir mal -
vorbelastet sind, und dem Artikel eine eindeutige Färbung verleihen.
Solche und ähnliche Ausdrücke haben in einem neutralen Artikel nichts
zu suchen.
Ausserdem finde ich es schon recht bezeichnend, dass der Autor sich
mit dem MX200 ausgerechnet einen 3D-Chip herausgesucht hat, der
absichtlich beschnitten wurde, damit er in das Low-Cost Marktsegment
passt. Zu einer aussagekräftigen Betrachtung hätte wenigstens der
MX400 oder ein vanilla GeForce2 gehört. Übrigens verwendet der Autor
im weiteren Verlauf nVidias Marketing-Angaben zum leistungsfähigeren
GeForce2 MX, nicht etwa die zum MX200.
Und sachlich richtig? Nunja, mir fehlt ein wenig die Zeit, um den
Artikel komplett auseinanderzunehmen (was auch wenig sinnvoll wäre),
daher nur ein paar Beispiele, die ich für richtiggehende Klöpse halte.
Nehmen wir einmal die Berechnung der auf dem AGP benötigen Bandbreite.
Der Autor behauptet, alleine die Übertragung der Geometrie-
Informationen für die zwanzig Millionen Eckpunkte, die der MX200
maximal transformieren kann, beanspruchten 1,6 GB/s. Was soll da alles
übertragen werden? 1,6 GB/s geteilt durch 20 Millionen Eckpunkte/s
ergibt 80 Byte pro Eckpunkt! Eine 3D-Koordinate besteht aus drei
Gleitkommazahlen, die bei Verwendung von 32-Bit-Floats (mehr benötigt
man üblicherweise nicht) gerade einmal 12 Byte in Anspruch nehmen.
Möchte man nicht nur den Transform-, sondern auch den Lighting-Teil in
Anspruch nehmen, kommen noch einmal drei Floats für den
Normalen-Vektor hinzu (Smooth-Shading angenommen) - damit bin ich erst
bei 24 Bytes. Wir können auch noch Texturkoordinaten hinzuzählen (2
Floats) und landen bei 32 Bytes. Ein wenig kann man diese Zahl noch
aufblähen, wenn man Multitexturing verwendet und bei jeder einzelnen
Textur auf eigene Texurkoordinaten zurückgreift. Man könnte noch
Farbinformationen für jeden Eckpunkt hinzunehmen, aber dazu besteht
eigentlich kein Grund, denn Hardware-Lighting und Texturing machen das
meist überflüssig. Aber selbst dann erreicht man nicht annähernd 80
Bytes/Eckpunkt - und damit auch keine 1,6 GB/s.
Ausserdem kennen moderne Grafik-APIs sogenannte "compiled vertex
arrays". Diese eignen sich zwar nur für weitgehend statische Objekte
(die als Szenerie aber in jedem Spiel vorhanden sind), aber dafür
liegen sie im Speicher der Grafikkarte und können extrem schnell
angesprochen werden - über den AGP müssen dann zur Polygon-Bildung nur
noch die Indizes in das Array übertragen werden.
Desweiteren verneint der Autor an dieser Stelle seines Artikels die
Bedeutung von Triangle-Strips, was man eigentlich nur tun kann, wenn
man selbst nie 3D-Karten programmiert hat oder diese Versuche in
dieser Richtung nur nicht ernstzunehmende Spielerei waren. Mein
Vertrauen in die Sachkomptenz des Autors wird dadurch zutiefst
erschüttert; im weiteren Verlauf finden sich ähnliche Punkte.
Dein Kritikpunkt "mangelnde Belege für eine Behauptung" trifft
übrigens auch auf den Artikel selbst zu; dort wird einfach behauptet,
ein 1,2-GHz-Athlon könne T&L schneller ausführen als die Grafikkarte.
Belege dafür fehlen aber; es gibt keine nähere Beschreibung
betreffender 3D-Engines, keine vergleichenden Benches. Ich wäre auch
schon mit einer einfachen Modellrechnung zur theoretischen
Leistungsfähigkeit des Prozessors zufrieden gewesen, aber stattdessen
findet man nur den Satz "es ist einsichtig, dass..." und ein Vergleich
von Taktfrequenzen. Bei mir entsteht an dieser Stelle der Eindruck,
dass der Autor - wenn überhaupt - nur rudimentäre Kenntnisse über die
Architektur von CPUs und Grafik-Beschleunigern besitzt.
Habe ich Dir damit die Gründe, die zu meiner Meinungsbildung führten,
ausführlich genug erläutert?
Bye,
Thorsten
Martin Horst
Hi,
>Thomas Markert schrieb:
>
>>> V5 und GF, beide mit D3D - wo sind da die Äpfel, wo sind die
>>> Birnen?
>>
>> na die Voodoo wird Glide nutzen und die die GF wird D3D nutzen, da
>
>Zum dritten Mal - _beide_ Karten laufen unter D3D, trotzdem ist die
>V5 trotz besserer Papierform unter U9 deutlich schneller. Das kann
>a.) an der Hardware liegen und b.) an den immer noch nicht so tollen
>NVidia Treibern, speziell bei Spielen abseits des Mainstream. Ich tippe
>auf eine Mischform von a und b.
>...
wenn ich das noch richtig im Kopf habe, liegt es daran, daß daß die U9
Engine für weit entfernte Objekte von texturierten Polygonen auf einfarbige
Polygone umschaltet (was man nach der DX Hilfe aber auch nicht tun
sollte. Steht ein fetter Warnhinweis drin.). Die NVidia Chips führen einen
Reset bei der Umschaltung durch und lehren ihre Caches. Daran ist
auch nichts verwerfliches, denn sowas sollte man eben als Spieleentwickler
auch nicht tun. Aber wenn ich mir den Rest vom Spiel anschaue, dann haben
da wohl richtige Profis dran gearbeitet :-)
Gruß
Martin
Raphael Pilarczyk
Bet: "Re: interessanter T&L-Review"
> > hab ich grad auf www.3dcenter gefunden...sehr interessant muss ich
> > sagen, und vor allem objektiv finde ich
>
> Weder objektiv noch sachlich richtig. Da hat einfach nur jemand seinen
> Advocacy-Trieb ausgelebt.
So wie du grade?
--
PIK
Thorsten Lange
> > Weder objektiv noch sachlich richtig. Da hat einfach nur jemand seinen
> > Advocacy-Trieb ausgelebt.
>
> So wie du grade?
Aus welchem dieser beiden Sätze liest Du ein leidenschaftliches
Plädoyer für oder gegen eine bestimmte Hardware heraus?
Wenn Du auf die fehlende Begründung anspielst (die ich auf Anfrage von
Thomas Eßer wenigstens teilweise geliefert habe - das Posting sollte
inzwischen bei Dir angekommen sein oder das in Kürze tun): Mein
Statement war primär als persönliche Meinungsäußerung gedacht (wessen
Meinung sollte ich auch sonst äußern?), die ich als Kontrast zu Thomas'
"vor allem objektiv finde ich" abgesetzt habe.
Klar, es bleibt mein Angriff, der Artikel sei sachlich falsch, der
zunächst einmal unbegründet ist, aber dass dieser nicht unbedingt von
neutraler Position aus geschrieben wurde, kann IMHO (um das mal
ausdrücklich zu schreiben) von jedem auch ohne tiefergehendes Wissen
um die 3D-Karten erkannt werden, sofern er auf die verwendeten
stilistischen Mittel achtet. Sätze wie "Dank der nVidia-Propaganda und
ihren Erfüllungsgehilfen in Gestalt von unfähigen Redakteuren, die
einfach alles nachkrähen[...]" lassen nicht gerade auf Objektivität
schließen. Ob nun "nachgekräht" wird oder nicht, sei dahingestellt,
aber die Redakteure der vom Autor niedergemachten Fachmagazine haben
diesem eines voraus: Sie veröffentlichen ihre Artikel unter ihrem
eigenen Namen, und den bleibt "aths" ebenso schuldig wie
Quellenangaben...
Bye,
Thorsten
Daniel Lichtenberger
wrote:
>Ob nun "nachgekräht" wird oder nicht, sei dahingestellt,
>aber die Redakteure der vom Autor niedergemachten Fachmagazine haben
>diesem eines voraus: Sie veröffentlichen ihre Artikel unter ihrem
>eigenen Namen, und den bleibt "aths" ebenso schuldig
Der steht glaub ich am Ende des Artikels oder auf der Homepage, die
dort angegeben ist ...
>wie
>Quellenangaben...
...gibt wohl keine ;). Der 64-Bit-Artikel
(http://www.3dcenter.de/artikel/2001/07-26a.php3) vom selben Autor
steht imo auch auf mehr als wackligen Beinen.
Sascha Erni, .rb
das ist einer der Punkte, die an der U9 engine eher faul sind, als D3D
Ding. Dann zeigt die Engine selbst in der letzten Inkarnation noch
Speicherlecks unter Win98, die auch mal den Rechner runterreissen können;
auf das idiotische View-Distance Modell will ich gar nicht erst eingehen.
Und wie ich schon weiter oben sagte, auch wenn die Engine auf D3D
gewechselt hat: es lieg nahe, dass der Code der Engine immernoch auf
Voodoo-Spezifikationen optimiert ist, was Textur-Management, register
combiners, Speicher-Verwaltung, filtering etc. anbelangt. Selbst Origin
hat sich für die D3D Engine entschuldigt.
Weshalb dann sind sowohl Radeon als auch Kyro-II soviel schneller als eine
GF3? Naja, ist's zumindest bei mir nicht. Meine GF3 ist satte 5fps
schneller, in Britain, als meine K2. Ein Beispiel macht noch keinen Sommer
(oder so ähnlich), aber offenbar kommt's recht stark auf die verwendeten
Treiber an (in meinem Fall 12.41).
ta,
.rb
Raphael Pilarczyk
Bet: "Re: interessanter T&L-Review"
> Solche und ähnliche Ausdrücke haben in einem neutralen Artikel nichts
> zu suchen.
Eine s.g. Neutralitaet gibt es nicht, da zB. auch Artikel
von Menschen geschrieben werden. Wenn du neutrale Menschen suchst,
geh' auf den Friedhof.
--
PIK
Thomas Markert
Ahoi
>>> V5 und GF, beide mit D3D - wo sind da die Äpfel, wo sind die
>>> Birnen?
>>
>> na die Voodoo wird Glide nutzen und die die GF wird D3D nutzen, da
>
>Zum dritten Mal - _beide_ Karten laufen unter D3D, trotzdem ist die
>V5 trotz besserer Papierform unter U9 deutlich schneller. Das kann
>a.) an der Hardware liegen und b.) an den immer noch nicht so tollen
>NVidia Treibern, speziell bei Spielen abseits des Mainstream. Ich tippe
>auf eine Mischform von a und b.
sorry, aber ich hatte mein Post geschrieben bevor ich die anderen
antowrten weiter unten gelesen hatte, sollte man halt nich machen...
>> und man daher keine Rückschlüsse auf die Graka Geschwindigkeit ziehen,
>> eiegntlich nur wenn beide Karten die gleiche Api nutzen...
>
>Eben. Und genau das wird da gemacht ...
ok, ok ich hab geschnackelt
cu Thomas
Thomas Markert
buhahahahahaha
darf ich das als Sig haben?
cu Thomas
Martin Horst
Hi,
ebenso *nick*
Mit etwas Anpassung in der INI lief es auf meine GF1 halbwegs flot. Man mußte
vor allem die Textur und Vertex Caches etwas anpassen.
Aber das ganze Spiel ist ein haufen Bugs. Was sich Origin damit geleistet hat
übertrifft so ziemlich alles was ich bis dahin gesehen habe.
Ich habe mal ein Statement von einem U9 Entwickler bzgl. der D3D Portierung
gelesen und welche Probleme sie dabei gehabt haben. Da stand zum Teil nur
Mißt drin. Und wenn man sich anschaut wie lange das Teil in der Entwicklung war
und die ganzen Verzögerungen, dann frage ich mich, ob der Projektmanager
sich nicht vielleicht auch einen anderen Job hätte suchen sollte (falls es jemals einen
gegeben hat) :-)
Gruß
Martin
Thorsten Lange
> Eine s.g. Neutralitaet gibt es nicht, da zB. auch Artikel
> von Menschen geschrieben werden. Wenn du neutrale Menschen suchst,
> geh' auf den Friedhof.
Vorurteilsfreiheit ist nicht das Fehlen einer eigenen Meinung.
Jeder Beitrag hat eine bestimmte Intention, und der besagte Artikel
ist da keine Ausnahme. Ich behaupte lediglich, dass in diesem Fall die
Intention nicht darin lag, eine Betrachtung zur Nützlichkeit von T&L
abzuliefern und dessen Vor- und Nachteile aufzuzeigen - mithin also
einen Bericht abzuliefern, anhand dessen sich der Leser eine eigene
Meinung bilden kann. (Das wäre eine mögliche Definition von
Objektivität.) Kannst Du dem zustimmen?
Bye,
Thorsten
Thomas Eßer
> http://www.3dcenter.de/artikel/2001/07-26a.php3
Wieso? Im großen und ganzen werden doch nur die Aussagen von
Carmack aufgewärmt und eine größere, zumindest interne Farbtiefe
liegt für DX9 tatsächlich in der Luft. Bei massivem Texturing
würde das ja auch Sinn machen ;).
Ob der Framebuffer wirklich 64 Bittig bedient werden muß halte ich
allerdings auch für ein Gerücht, ebenso wie das völlige Ignorieren
von alternativen Methoden - für einen Tiler sieht das ganze ja
schon völlig anders aus, wird aber nur leicht gestreift ...
Vieles ist halt - nicht zuletzt wegen fehlender Hard- und
software - spekulativ. Ich allerdings erwarte von einem Artikel
über ungelegte Eier auch nichts anderes ;).
Gruß,
Thomas
Thomas Eßer
> Intention nicht darin lag, eine Betrachtung zur Nützlichkeit von T&L
> abzuliefern und dessen Vor- und Nachteile aufzuzeigen - mithin also
Übertitelt ist das ganze mit
'T&L - das nicht eingelöste Versprechen'
Es wird primär mit den Werbeversprechen abgerechnet und
einfach ein Realitätscheck gemacht, was von den Werbeaussagen
übrigbleibt. Daher auch meine Vermutung, das Du die Intention
des Artikel nicht verstanden hast.
Erkläre doch mal, inwiefern sich die Werbeaussagen von damals
mit der heutigen tatsächlichen Situation decken. Für eine
tiefgreifende Analyse die Du scheinbar erwartet hast, würde ich
eher den angesprochenen Artikel von 3dConcept ranziehen.
Thomas Eßer
> das ist einer der Punkte, die an der U9 engine eher faul sind, als D3D
> Ding. Dann zeigt die Engine selbst in der letzten Inkarnation noch
> Speicherlecks unter Win98, die auch mal den Rechner runterreissen
Sicher ist die Engine verwanzt ohne Ende, EA hat halt den Geldhahn
zugedreht bevor etwas halbwegs entgültiges dabei rumkommen konnte.
Nur ändert das nicht an der prinzipiellen Leistungsfähigkeit der
Grafikengine.
> Weshalb dann sind sowohl Radeon als auch Kyro-II soviel schneller als
> eine GF3? Naja, ist's zumindest bei mir nicht. Meine GF3 ist satte 5fps
> schneller, in Britain, als meine K2. Ein Beispiel macht noch keinen
Zum einen wäre es /etwas/ enttäuschend wenn eine angebliche High End
Karte zum 3/4 fachen Preis nicht wenigstens einen kleinen Vorteil ver-
buchen könnte, zum anderen läßt sich durch Tweaking auf einer Kyro
einges rausholen. Allerdings sieht es auf einer K-2 weit besser aus
als auf meiner GF1 ;). Noch davon abgesehen ist U9 ohnehin einer
Speicher- und CPU-limitiert :).
Gruß,
Thomas
Thomas Eßer
> nicht tun sollte. Steht ein fetter Warnhinweis drin.). Die NVidia Chips
> führen einen Reset bei der Umschaltung durch und lehren ihre Caches.
Wo kann man entsprechendes nachlesen? Die Treiber der Konkurenten haben
es scheinbar nicht nötig, wobei ich nicht glaube, das der
Performancenachteil ausschließlich an Cachetrashing on Chip liegen
soll.
Gruß,
Thomas
Thomas Eßer
> Dieser Artikel erscheint in meinen Augen wenig objektiv, weil
> Formulierungen wie "nVidia-Propaganda" doch etwas - sagen wir mal -
Sind Werbeaussagen - egal von welchem Hersteller - etwas anderes
als Propaganda? Das Werbeaussagen gerade im Computerbereich schon
sehr spitz interpretiert werden müssen, um wenigstens den Hauch
von Wahrheit zu enthalten, darüber müssen wir doch sicher nicht
diskutieren?
> vorbelastet sind, und dem Artikel eine eindeutige Färbung verleihen.
> Solche und ähnliche Ausdrücke haben in einem neutralen Artikel nichts
> zu suchen.
Es geht in dem Artikel primär um die Werbetechnische- und die
tatsächliche Folge von Hardware T&L, insbesondere um die damals
gemachten vollmundigen Versprechungen, die teils wortwörtlich
wiederholt werden. Sicher ist das heute _peinlich_ für die Her-
steller ;).
> Ausserdem finde ich es schon recht bezeichnend, dass der Autor sich
> mit dem MX200 ausgerechnet einen 3D-Chip herausgesucht hat, der
> absichtlich beschnitten wurde, damit er in das Low-Cost Marktsegment
> passt. Zu einer aussagekräftigen Betrachtung hätte wenigstens der
Der Chip wird gegen eine V5-4500 gestellt, die ebenfalls Lowcost
darstellt(e). Wo ist das Problem? Hört sich für nicht gerade nach
kritikwürdigem an ...
> MX400 oder ein vanilla GeForce2 gehört. Übrigens verwendet der Autor
> im weiteren Verlauf nVidias Marketing-Angaben zum leistungsfähigeren
> GeForce2 MX, nicht etwa die zum MX200.
Der Core ist der gleiche wie bei einer MX oder einer MX-400, die
Speicheranbindung hat erstmal nicht mit der theoretischen Leistungs-
fähigkeit zu tun. Im übrigen wird afaik immer darauf hingewiesen,
was spezifisch gemeint ist - So what?
> Nehmen wir einmal die Berechnung der auf dem AGP benötigen Bandbreite.
Die ist völlig korrekt. Lies bitte dazu
http://www.3dconcept.ch/artikel/T&L/10.htm
Sowohl AGP, Speicher und CPU Bus machen ohnehin schon weit
früher dicht. Selbst /wenn/ man mit deutlich weniger Bytes
pro Dreickeck auskommen würde, läßt sich die theoretische
Leistung nichtmal annähernd erreichen. Abgesehen davon das
dabei keine reale Anwendung, sondern nur ein weiteres
überflüssiges Techdemo rauskommt.
> Der Autor behauptet, alleine die Übertragung der Geometrie-
> Informationen für die zwanzig Millionen Eckpunkte, die der MX200
Abgesehen davon benötigt man noch Bandbreite für Texturen,
Statusinformationen, etc.
> Desweiteren verneint der Autor an dieser Stelle seines Artikels die
> Bedeutung von Triangle-Strips, was man eigentlich nur tun kann, wenn
Es läßt sich aber längst nicht alles in Stripes verpacken.
Geometriekompression gibt es derzeit nicht kaufbar für Normal-
sterbliche und für fast ausschließlich statische Geometrie
sind heute die Onboard Grafikspeicher schon zu klein.
> Dein Kritikpunkt "mangelnde Belege für eine Behauptung" trifft
> übrigens auch auf den Artikel selbst zu; dort wird einfach behauptet,
> ein 1,2-GHz-Athlon könne T&L schneller ausführen als die Grafikkarte.
Real existierende Spiele beweisen, das es - mit entsprechend schneller
CPU - keine Leistungsverluste gibt. Man kann sicher trefflich darüber
spekulieren, woran das genau liegt - Fakt ist aber, das es so ist.
Sicher lassen sich Szenarios konstruieren, wo diese _reale_ Situation
völlig umdrehen läßt - Techdemos zum Beispiel, aber die interessieren
beim Thema des Artikels absolut nicht.
> Habe ich Dir damit die Gründe, die zu meiner Meinungsbildung führten,
> ausführlich genug erläutert?
Nein, nicht wirklich. Ich glaube zum einen, das Du den Sinn des Artikels
nicht verstanden hast und zum anderen, das Du mit dem Ergebnis ein Problem
hast ;).
Daniel Lichtenberger
>> http://www.3dcenter.de/artikel/2001/07-26a.php3
>
>Wieso? Im großen und ganzen werden doch nur die Aussagen von
>Carmack aufgewärmt und eine größere, zumindest interne Farbtiefe
>liegt für DX9 tatsächlich in der Luft.
Ja, die Betonung liegt aber auf _intern_. Und die liegt seit jeher
höher als die Framebuffer-Tiefe (schon Voodoo1 rechnete iirc mit 32
oder 40 Bit, und keinen hat's interessiert). Mit Loopback und Tiler
wird der Sinn eines 64-Bit-Framebuffers noch unverständlicher. Und
dieser (entscheidende) Unterschied zwischen interner und
Framebuffer-Farbtiefe geht im Artikel ziemlich unter (obwohl es
erwähnt wird).
>Ob der Framebuffer wirklich 64 Bittig bedient werden muß halte ich
>allerdings auch für ein Gerücht, ebenso wie das völlige Ignorieren
>von alternativen Methoden - für einen Tiler sieht das ganze ja
>schon völlig anders aus, wird aber nur leicht gestreift ...
Exakt ... mich stören auch die pseudowissenschaftlichen Rundungsfehler
(ich kann mir z.B. nicht vorstellen, daß 11 Passes bei 32 Bit nur 2%
Rundungsfehler verursachen, und wenn es so wäre, würde man es
garantiert _nicht_ bemerken) und daß der Rampage schon wieder aus dem
Grab gezerrt wird. ;)
>Vieles ist halt - nicht zuletzt wegen fehlender Hard- und
>software - spekulativ. Ich allerdings erwarte von einem Artikel
>über ungelegte Eier auch nichts anderes ;).
Erwartet habe ich es auch, ich denke der Artikel spielte nur damit,
daß sich 64 Bit schon wieder nach einem kommenden Glaubenskrieg anhört
(--> bringt Hits ;) SCNR).
Thorsten Lange
> Thorsten Lange schrieb:
>
> > Dieser Artikel erscheint in meinen Augen wenig objektiv, weil
> > Formulierungen wie "nVidia-Propaganda" doch etwas - sagen wir mal -
>
> Sind Werbeaussagen - egal von welchem Hersteller - etwas anderes
> als Propaganda?
Ja. Bitte informiere Dich über die Bedeutung der einzelnen Wörter.
Unter "Propaganda" versteht man (zumeist politische) Werbung ohne
Rücksicht auf den Wahrheitsgehalt.
> Das Werbeaussagen gerade im Computerbereich schon
> sehr spitz interpretiert werden müssen, um wenigstens den Hauch
> von Wahrheit zu enthalten, darüber müssen wir doch sicher nicht
> diskutieren?
Natürlich. Die Angaben zur Peak-Performance ist immer die Performance,
von der selbst der Hersteller zugibt, dass sie in der Praxis nicht
erreicht wird. Das ist bereits seit Jahrzehnten so, und jeder
Hersteller beteiligt sich an diesem Spiel.
> > Ausserdem finde ich es schon recht bezeichnend, dass der Autor sich
> > mit dem MX200 ausgerechnet einen 3D-Chip herausgesucht hat, der
> > absichtlich beschnitten wurde, damit er in das Low-Cost Marktsegment
> > passt. Zu einer aussagekräftigen Betrachtung hätte wenigstens der
>
> Der Chip wird gegen eine V5-4500 gestellt, die ebenfalls Lowcost
> darstellt(e). Wo ist das Problem? Hört sich für nicht gerade nach
> kritikwürdigem an ...
Das Problem besteht darin, dass in der Gegenüberstellung ein Chip
verwendet wird, der - je nach betrachteter Zahl - deutlich schlechter
aussieht als die V5-4500 (ich denke da z.B. an die hervorgehobene
Speicherbandbreite), für das spätere Bashing (ja, das nenne ich so)
werden jedoch die deutlich höheren Leistungsangaben eines besseren
Chips herangezogen.
> Der Core ist der gleiche wie bei einer MX oder einer MX-400, die
> Speicheranbindung hat erstmal nicht mit der theoretischen Leistungs-
> fähigkeit zu tun.
Jedoch gibt nVidia beim MX200 deutlich geringere Leistungsdaten an,
als bei den anderen Chips.
> > Nehmen wir einmal die Berechnung der auf dem AGP benötigen Bandbreite.
>
> Die ist völlig korrekt. Lies bitte dazu
> http://www.3dconcept.ch/artikel/T&L/10.htm
Ah, da ist ja der Artikel, von dem der Autor abgeschrieben hat. Falsch
abgeschriebene Zahlen bleiben aber trotzdem falsch. Die dort genannten
80 Byte sind ausschließlich eine Spekulation des Autors. Bitte führe
eine korrekte Rechnung anhand einer konkreten Grafik-Engine vor, dann
können wir weiter diskutieren. Meine Vergleichszahlen habe ich ja
schon genannt. Ich kann auch gerne auf diesen Artikel näher eingehen,
wenn Dir das lieber ist.
> > Der Autor behauptet, alleine die Übertragung der Geometrie-
> > Informationen für die zwanzig Millionen Eckpunkte, die der MX200
>
> Abgesehen davon benötigt man noch Bandbreite für Texturen,
> Statusinformationen, etc.
Die aber immer anfallen, nicht nur wenn T&L verwendet wird. Die zur
Verfügung stehende Bandbreite muss man aufteilen, klar - aber so gross
ist das Problem auch wieder nicht; Texturuploads sind nicht so häufig
nötig (oder sollten es nicht sein). Gut, unter dem Strich wird kein
Durchsatz von 20 Millionen Polygonen/s erreicht - aber beschimpfst Du
den Hersteller Deines Autos, weil er es gewagt hat, die
Höchstgeschwindigkeit im Prospekt mit 200 km/h anzugeben, Du aber
trotzdem nicht in einer halben Stunde von Dortmund nach Köln gelangst?
Der maximale Dreiecksdurchsatz ist übrigens nur eine Größe, die die
Gesamtleistung bestimmt - aber das kennen wir ja in ähnlicher Form
schon vom Gesamtsystem "PC". Hier führt eine Verdoppelung des
CPU-Taktes ja auch nicht zu einer Verdoppelung der Gesamtleistung.
> > Desweiteren verneint der Autor an dieser Stelle seines Artikels die
> > Bedeutung von Triangle-Strips, was man eigentlich nur tun kann, wenn
>
> Es läßt sich aber längst nicht alles in Stripes verpacken.
Aber sehr, sehr viel. Auf der von Dir genannten 3dconcept-Seite findet
man übrigens den Hinweis, bei Quake seien Triangle-Strips auf eine
Länge von maximal 10 Dreiecken beschränkt. Der Source-Code der
Quake-Engine scheint dies jedoch nicht zu belegen - die bei der
Erzeugung der Strips verwendeten Datenstrukturen lassen jedenfalls
Raum für Strips mit einer Länge von 128 Vertizes, also für 126
Dreiecke...
> Nein, nicht wirklich. Ich glaube zum einen, das Du den Sinn des Artikels
> nicht verstanden hast und zum anderen, das Du mit dem Ergebnis ein Problem
> hast ;).
Dann sag mir bitte, welchen Sinn der Artikel hat. nVidia wird unter
Zuhilfenahme von nicht zutreffenden Informationen auf nVidia falscher
Werbeaussagen beschuldigt. So weit, so gut - aber woran liegt es denn,
dass aktuelle Spiele nicht in dem Maße von T&L profitieren wie sie es
könnten?
Sieht man sich die derzeitigen Spiele an, dann wird deutlich, dass von
T&L eigentlich nur der "T"-Teil der Karte verwendet wird. Die
vielfältige Lichtstimmung in den Spielen lässt sich mit den 8
Lichtquellen, die der GeForce hardwareseitig unterstützt, einfach
nicht erreichen (die derzeit üblichen Polygon-Zahlen erschweren das
noch zusätzlich), also verzichtet man auf das Lighting und gestaltet
die Beleuchtung praktisch statisch (üblicherweise unter Zuhilfenahme
von Lightmaps). Ist es ein Fehler des Chips, dass seine
Lighting-Funktionen nicht verwendet werden? Ich denke nein, denn es
gibt durchaus Anwendungen, die auf funktionierendes dynamisches
Lighting angewiesen sind, denn bewegliche Objekte und
Mesh-Deformationen passen nicht mit statischer Beleuchtung zusammen,
wenn man auf schnelle und korrekte Beleuchtung angewiesen ist (dazu
gehört z.B. das System, an dem ich gerade entwickele ;-) ) Der
Transform-Teil ist aber in jedem Falle nützlich, es sei denn, der
Software-Entwickler besteht darauf, das Objekt selbst von Welt- in
Bildschirmkoordinaten zu transformieren - sofern er OpenGL benutzt,
ist das übrigens nur mit ein paar Tricks möglich, denn hier sind
Vertex-Koordinaten immer Weltkoordinaten; daher benutzt jede
OpenGL-Applikation normalerweise auch automatisch die "T"-Hardware,
sofern diese vorhanden ist.
Die Kritik an nVidia erstreckt sich weiter darauf, dass aktuelle
Spiele nicht so viele Polygone benutzen, wie es nach den Werbeaussagen
von nVidia möglich sein soll. Woran liegt das? Eine Erklärung wäre,
dass die Programmierer nicht befähigt sind, die nVidia-Hardware
auszureizen, woran ich aber nicht glauben kann. Vermutlich ist dieses
Verhalten vielmehr erwünscht, denn wenn ein Spiel nur noch auf
GeForce-Karten lauffähig wäre, blieben die Besitzer anderer Hardware
aussen vor und das Spiel ließe sich schlechter verkaufen. Natürlich
könnte man jetzt argumentieren, die Hersteller könnten ihre Modelle
doch in verschiedenen Detaillierungsstufen erstellen und zur Laufzeit
das Modell verwenden, dass zur jeweiligen Hardware passt. Dummerweise
würde dies einigen Aufwand und somit Produktionskosten verursachen,
also wird diese mögliche Lösung nicht umgsetzt. Die einschlägigen
Benchmarkergebnisse zeigen auf jeden Fall, dass noch eine Menge Luft
ist - wenn man sich mit 80 fps mit 40 fps begnügen würde, wären auch
detailliertere Szenerien denkbar.
Fazit ist also: Die zur Verfügung stehende Hardware wird von den
derzeitigen Spielen nicht vollends ausgenutzt - ist das die Schuld des
Hardwareherstellers? Wenn Du der Meinung bist, dann musst Du
allerdings anfangen, jeden anderen Hardwarehersteller auch zu
beschimpfen. Ein einfaches Beispiel: Das unter Win vermutlich am
häufigsten eingesetzte Entwicklungssystem dürfte Visual C++ von
Microsoft sein. Der dort enthaltene C-Compiler kennt gerade einmal den
PentiumPro. Den Pentium-II/III und -IV kennt er nicht, also führt er
auch keine Optimierungen für diese Prozessoren aus. Demzufolge kann es
keine mit Visual C++ erzeugten Applikationen geben, die die vorhandene
Hardware vollständig ausreizen. Ist das Intels Schuld?
Bye,
Thorsten
Martin Horst
Hi,
>Martin Horst schrieb:
sorry, aber daß weiß ich nicht mehr. Es hat aber auch nichts mit den
Treiber zu tun sondern eben mit der Hardware. Normalerweise
schaltet ja auch keiner die Modi im Betrieb um sondern bei der
Initialisierung. Und wie gesagt, darauf wird in der D3D Doku hingewiesen.
Auf der anderen Seite könnte man dann ja auch anführen, warum der
Kyro1/2 Chip so Probleme mit Render To Texture hat. Jeder 3D Chip
hat da und dort eine Schwachstelle. Man muß deswegen dann aber
auch nicht volles Rohr daraufhinprogrammieren :-)
Aber IMHO haben die das wohl eh mit dem letzten Patch geändert und
nach einigen Änderungen in der INI lief es bei mit auch "sehr" flott.
Und zwar richtig mit rumlaufen und nicht die Stußtest wo der Avatar nur
gerade aus läuft.
Auf der anderen Seite: Auf meine damaligen ATI Rage 128 lief es
überhaupt nicht. Super lahm und es fing nach 15min. an nur noch zu Ruckeln.
Also auch nicht viel besser.
Für mich waren die Entwickler absolut unfähig. Vor allem kühmten die in einem
Schreiben (habe ich auch nicht mehr) über entliche Probleme, welche sich
dann aber wohl schnell beheben ließen. Wofür z.B. haben NVidia und andere
Entwicklersupport!?
Das Spiel ist vom technischen Aspekt her gesehen, absoluter Schrott.
Deswegen läßt sich da bzgl. Performance von Grafikkarten eigentlich
überhaupt nichts drüber sagen.
Gruß
Martin
Christian Lindner
>Real existierende Spiele beweisen, das es - mit entsprechend schneller
>CPU - keine Leistungsverluste gibt. Man kann sicher trefflich darüber
>spekulieren, woran das genau liegt - Fakt ist aber, das es so ist.
Nein, das ist nur ein hartnäckiges Gerücht. Real existierende Spiele wie
Max Payne (vor allem in Aussenszenen) profitieren durchaus von einer
Grafikkarte mit T&L, sogar wenn man eine sehr schnelle CPU hat.
Martin Kuras
Beweis durch Behauptung?
Gruß Martin
--
Welches Naturgesetz sagt denn das unbelebte Dinge keine Rechte haben?
[Tobias Wrede in de.rec.sf.startrek.voyager]
Daniel Lichtenberger
wrote:
>Für mich waren die Entwickler absolut unfähig. Vor allem kühmten die in einem
>Schreiben (habe ich auch nicht mehr) über entliche Probleme, welche sich
>dann aber wohl schnell beheben ließen. Wofür z.B. haben NVidia und andere
>Entwicklersupport!?
Ich glaube weniger daß die Entwickler unfähig waren, eher daß die
Engine über die vielen Jahre hinweg so oft verändert wurde (U9 sollte
ja anfangs eine isometrische Perspektive haben), daß das Ding am Ende
wohl absolut "unwartbar" wurde und keiner sich mehr richtig auskannte
(und Geld gab's von EA wohl auch nicht mehr). Jeder, der mal unter
richtigem Zeitdruck programmiert hat, kann nachvollziehen, zu welchen
haarsträubenden Konstrukten man sich in solchen Situationen hinreißen
lassen kann. ;-)
>Das Spiel ist vom technischen Aspekt her gesehen, absoluter Schrott.
Ack ;)
Thomas Eßer
>> Sind Werbeaussagen - egal von welchem Hersteller - etwas anderes als
>> Propaganda?
>
> Ja. Bitte informiere Dich über die Bedeutung der einzelnen Wörter.
> Unter "Propaganda" versteht man (zumeist politische) Werbung ohne
> Rücksicht auf den Wahrheitsgehalt.
Spar Dir die Wortklauberei. Du bist schließlich derjenige, der
den Artikel erstmal in zwei Worten abkanzelt und dann offenbar
Mühe hat, dafür auf Nachfrage Begründungen zu liefern die nicht
an den gleichen Problemen leiden, welche 'kritisiert' werden.
>> Das Werbeaussagen gerade im Computerbereich schon
>> sehr spitz interpretiert werden müssen, um wenigstens den Hauch
>> von Wahrheit zu enthalten, darüber müssen wir doch sicher nicht
>> diskutieren?
>
> Natürlich. Die Angaben zur Peak-Performance ist immer die Performance,
> von der selbst der Hersteller zugibt, dass sie in der Praxis nicht
> erreicht wird. Das ist bereits seit Jahrzehnten so, und jeder
> Hersteller beteiligt sich an diesem Spiel.
Und die Erde ist eine Scheibe.
> Das Problem besteht darin, dass in der Gegenüberstellung ein Chip
> verwendet wird, der - je nach betrachteter Zahl - deutlich schlechter
> aussieht als die V5-4500 (ich denke da z.B. an die hervorgehobene
> Speicherbandbreite), für das spätere Bashing (ja, das nenne ich so)
> werden jedoch die deutlich höheren Leistungsangaben eines besseren
> Chips herangezogen.
Schon gemerkt, das die Bandbreite das Problem ist? Was wieder direkt
zur Propaganda führt.
>> Der Core ist der gleiche wie bei einer MX oder einer MX-400, die
>> Speicheranbindung hat erstmal nicht mit der theoretischen Leistungs-
>> fähigkeit zu tun.
>
> Jedoch gibt nVidia beim MX200 deutlich geringere Leistungsdaten an,
> als bei den anderen Chips.
Für den Core? Beweis duch Behauptung?
> Ah, da ist ja der Artikel, von dem der Autor abgeschrieben hat. Falsch
> abgeschriebene Zahlen bleiben aber trotzdem falsch. Die dort genannten
> 80 Byte sind ausschließlich eine Spekulation des Autors. Bitte führe
> eine korrekte Rechnung anhand einer konkreten Grafik-Engine vor, dann
> können wir weiter diskutieren. Meine Vergleichszahlen habe ich ja
> schon genannt. Ich kann auch gerne auf diesen Artikel näher eingehen,
> wenn Dir das lieber ist.
Bitte mach das. Ich behaupte schließlich nicht, das dies alles Mist sei.
Leider kommst Du auf diese Tour auch nicht an der Tatsache vorbei, das
der AGP einer der Flaschenhälse ist, die Hardware T&L ausbremsen. Und
das ist letztlich der Punkt.
Da Du ja offenbar eine der großen Engines so gut intern kennst, das Du
exakte Angaben liefern kannst ... Ich bin gespannt ;).
> nötig (oder sollten es nicht sein). Gut, unter dem Strich wird kein
> Durchsatz von 20 Millionen Polygonen/s erreicht - aber beschimpfst Du
Schön das Du das zur Kenntnis nimmst ;).
> den Hersteller Deines Autos, weil er es gewagt hat, die
> Höchstgeschwindigkeit im Prospekt mit 200 km/h anzugeben, Du aber
> trotzdem nicht in einer halben Stunde von Dortmund nach Köln gelangst?
Vergleich die nicht hinken sind keine - oder wirbt einer der
Massenhersteller im KFZ Bereich damit, das mit mit Auto A
welches 200 km/h maximal bringt in der Lage ist, diese
immer und überall zu leisten, bei Nebel, 80 Grad Minus und im
Rückwärtsgang? NVidia - und natürlich andere - machen das fort-
während. Aber selbst da gibt es deutliche qualitative Unterschiede.
> Quake-Engine scheint dies jedoch nicht zu belegen - die bei der
Was? GLQuake, Quake2, Quake3 - und was wird tatsächlich verwendet?
>> Nein, nicht wirklich. Ich glaube zum einen, das Du den Sinn des
>> Artikels nicht verstanden hast und zum anderen, das Du mit dem
>> Ergebnis ein Problem hast ;).
>
> Dann sag mir bitte, welchen Sinn der Artikel hat. nVidia wird unter
Werbeaussagen vs. Realität.
> Zuhilfenahme von nicht zutreffenden Informationen auf nVidia falscher
> Werbeaussagen beschuldigt. So weit, so gut - aber woran liegt es denn,
Nochmal, welche der speziell NVidia zugedachten Äußerungen sind denn
/nicht/ korrekt? Ich erinnere in diesem Zusammenhang an das spaßige
Kyro II Pamphlet ...
> dass aktuelle Spiele nicht in dem Maße von T&L profitieren wie sie es
> könnten?
Wenn sie es denn überhaupt unterstützen, nicht zu vergessen. Es gibt
immer noch keine Schwemme von derartigen Titeln.
Fehlende Bandbreite, mangelnde Flexiblität von festverdrahtetem
Transforming, letzlich zu schnelle Hardwareentwicklung im Gegensatz
zur langsamen Softwareentwicklung, ...
[...]
> von Lightmaps). Ist es ein Fehler des Chips, dass seine
> Lighting-Funktionen nicht verwendet werden? Ich denke nein, denn es
Falsche Fragestellung. Warum wird ein letztlich unbrauchbares, weil zu
langsames und zu unflexibles Feature derart gehypt? Werbung vs. Realität.
Das es kein Schwein nutzt und stattdessen Features welche wirklich Sinn
machen würden stiefmütterlich behandelt werden fällt den Stimmungsmachern
oder besser den abhängigen Hardwarehanseln - egal ob Online oder im
Printbereich - jetzt ganz langsam auf - was natürlich auch daran liegt, das
sich Besserung am Horizont abzeichnet - DX8+ Hardware. Was letztlich
nur wieder handfeste wirtschaftliche Interessen widerspiegelt.
[viel richtiges]
> Fazit ist also: Die zur Verfügung stehende Hardware wird von den
> derzeitigen Spielen nicht vollends ausgenutzt - ist das die Schuld des
Alles richtig - nur was hat das mit der Intention des Artikels zu tun?
Ich bin mehr denn je der Ansicht, das Du den Artikel in den völig
falschen Hals bekommen hast.
Thomas Eßer
> Das Spiel ist vom technischen Aspekt her gesehen, absoluter Schrott.
ACK.
> Deswegen läßt sich da bzgl. Performance von Grafikkarten eigentlich
> überhaupt nichts drüber sagen.
NACK. Unter gebührender Berücksichtigung der Fakten sicher doch.
Der Quake3/3dMark Einheitsbrei ist das eigentliche Problem ;).
Gruß,
Thomas
Thomas Eßer
Flüssiger als flüssig ist aber immer noch überflüssig. Wenn die
theoretische Mehrleistung für mehr Details genutzt würde, könnte
ich zustimmen - wird sie aber nicht. Bei MP angeblich wegen
mangelnder Entwicklungszeit und Platz auf der CD, beides ist
ein (schlechter) Witz, angesichts der angeblich zugrundeliegenden
Demoengine und 4 Jahren Bastelei.
Davon abgesehen ist es schlicht unmöglich zu vergleichen, dadurch
das für Hardware T&L lose zwangsweise eine andere Grafikkarte ge-
nommen werden muß, würde ich nicht darauf spekulieren, das die
daraus resultierenden anderen Bedingungen vergleichbar sind.
Und das Software T&L welchers einstellbar ist, verrät nichts
darüber, ob exakt das gleiche in Sotware ablaufen würde ;).
Letztlich alles müßig - MP ist auf einer Non T&L Karte trefflich
spielbar.
Marcus Heuser
>
> Ich glaube weniger daß die Entwickler unfähig waren, eher daß die
> Engine über die vielen Jahre hinweg so oft verändert wurde (U9 sollte
> ja anfangs eine isometrische Perspektive haben), daß das Ding am Ende
> wohl absolut "unwartbar" wurde und keiner sich mehr richtig auskannte
> (und Geld gab's von EA wohl auch nicht mehr).
Nicht nur das - es wurden IMO sehr viele Designfehler begangen und dann
wirklich stur "auf Teufel komm raus" durchgezogen.
Wen hätte es wirklich gestört, wenn man die Welt in einzelne Abschnitte
unterteilt hätte, jedes Dungeon oder deren Etagen separat aufgebaut hätte?
Nur damit das alte 2D-Spielgefühl in eine 3D-Welt übertragen werden kann,
damit von der Ober- in die Unterwelt ohne Ladepausen gelangen kann?
IMO ein falscher Ansatz, wenn die technischen Möglichkeiten nicht gegeben
sind - und diese waren damals nicht gegeben, wenn man sich mal vorstellt,
welche CPU-Leistung man braucht, um U9 auf höchster Detailstufe laufen
zu lassen. Solche CPUs waren die meiste Zeit während der Entwicklung gar
nicht erhältlich - von dem Voodoo-Desaster mal abgesehen. Die Epic-Leute
haben wenigstens solange Patches nachgeliefert, bis auch D3D einigermaßen
lief.
U9 aber hätte man schön in einzelne Kapitel (passend zur Story) unterteilen
können - die epische Breite dieses Spieles wäre auch so rübergekommen -
dann entweder ein Engine lizensieren oder eine spezialisierte, wie z.B. die
DarkEngine von Looking Glas, selber schreiben - aber bitte nicht dieses
Marketing-BlaBla von wegen "mit unserer Engine kann man den ganzen
Planeten darstellen, wenn man nur weit genug zurückzoomt"...
bye
Marcus
Marc 'HE' Brockschmidt
>
> Thomas Eßer schrieb:
>
>> Real existierende Spiele beweisen, das es - mit entsprechend schneller
>> CPU - keine Leistungsverluste gibt. Man kann sicher trefflich darüber
>> spekulieren, woran das genau liegt - Fakt ist aber, das es so ist.
>
> Nein, das ist nur ein hartnäckiges Gerücht.
Ja?
> Real existierende Spiele wie Max Payne (vor allem in Aussenszenen)
> profitieren durchaus von einer Grafikkarte mit T&L, sogar wenn man eine
> sehr schnelle CPU hat.
Dann gib uns doch mal einen benchmark.
cu
HE
--
Der Diskettenvorrat geht immer am Samstag nach Ladenschluß zur Neige.
(Murphy's Gesetz)
Sascha Erni, .rb
"Marc 'HE' Brockschmidt" <nospam.Marc_...@gmx.de> schrieb ...
> > Real existierende Spiele wie Max Payne (vor allem in Aussenszenen)
> > profitieren durchaus von einer Grafikkarte mit T&L, sogar wenn man
eine
> > sehr schnelle CPU hat.
>
> Dann gib uns doch mal einen benchmark.
z.B. hier:
http://www.3dcenter.de/vbulletin/showthread.php?s=&threadid=3407
Hat noch mehr in den 3dcenter.de Foren, und ohne Ausnahme war HW TnL auf
GF immer schneller als in Software. Allerdings konnte ich noch keine
Suchfunktion finden, so dass ich nur das hier bieten kann. :(
ta,
.rb
Raphael Pilarczyk
Bet: "Re: interessanter T&L-Review"
> Spar Dir die Wortklauberei. Du bist schließlich derjenige, der
> den Artikel erstmal in zwei Worten abkanzelt und dann offenbar
> Mühe hat, dafür auf Nachfrage Begründungen zu liefern die nicht
> an den gleichen Problemen leiden, welche 'kritisiert' werden.
Versenkt!
--
PIK
Raphael Pilarczyk
Bet: "Re: interessanter T&L-Review"
a) WIE profitieren sie denn? Keine nachvollziehbaren "Testtips"
fuer Leute mit >800MHz CPUs (1024x768/32)?
b) Und wenn: Soll man HW-T&L im Jahre 2001 jetzt wegen einem
einzigen Spiel preisen??
--
PIK
Christian Lindner
>>> Real existierende Spiele wie Max Payne (vor allem in Aussenszenen)
>>> profitieren durchaus von einer Grafikkarte mit T&L, sogar wenn man
>>> eine sehr schnelle CPU hat.
>>
>> Dann gib uns doch mal einen benchmark.
>
>z.B. hier:
>http://www.3dcenter.de/vbulletin/showthread.php?s=&threadid=3407
>
>Hat noch mehr in den 3dcenter.de Foren, und ohne Ausnahme war HW TnL auf
>GF immer schneller als in Software.
Noch mehr Beispiele, dass Hardware T&L schneller ist als in Software,
gibt es unter anderem hier:
In Aussenszenen manchmal doppelt so schnell mit Hardware-T&L trotz
T-Bird 1.4 GHz:
http://www.nvnews.net/cgi-bin/search_news.cgi?category=1&keyword=payne&page=2
Auf einem Athlon 1.1 GHz: 28 fps mit Software-T&L, 41 fps mit
Hardware-T&L:
Martin Horst
Hi,
> ...
>Fazit ist also: Die zur Verfügung stehende Hardware wird von den
>derzeitigen Spielen nicht vollends ausgenutzt - ist das die Schuld des
>Hardwareherstellers? Wenn Du der Meinung bist, dann musst Du
>allerdings anfangen, jeden anderen Hardwarehersteller auch zu
>beschimpfen. Ein einfaches Beispiel: Das unter Win vermutlich am
>häufigsten eingesetzte Entwicklungssystem dürfte Visual C++ von
>Microsoft sein. Der dort enthaltene C-Compiler kennt gerade einmal den
>PentiumPro. Den Pentium-II/III und -IV kennt er nicht, also führt er
>auch keine Optimierungen für diese Prozessoren aus. Demzufolge kann es
>keine mit Visual C++ erzeugten Applikationen geben, die die vorhandene
>Hardware vollständig ausreizen. Ist das Intels Schuld?
IMHO haben der Pentium Pro, II, III die gleichen Pipelines. Beim P4 bin
ich mir nicht sicher. Deswegen gibt es bei der Optimierung auch nur
den Punkt Pentium Pro, da dieser die gleichen Ergebnisse auch auf
den P2s und P3s erreicht.
Gruß
Martin
Martin Horst
Moin,
ebenso NACK :-)
Der Kyro zabelt z.B. bei Giants gut ab. Ist der Chip deswegen schlecht.
Klar sind die Einheits Benchmarks auch sinnlos. Doch auf meiner GF1
lief bis auf U9 eben alles absolut flüssig. Da schiebe ich die Schuld dann
doch eher auf die U9 Engine anstatt auf die Treiber oder die Hardware
von NVidia.
Gruß
Martin
Daniel Lichtenberger
wrote:
>IMHO haben der Pentium Pro, II, III die gleichen Pipelines. Beim P4 bin
>ich mir nicht sicher.
Jep, der Pentium Pro-Kern wird im Wesentlichen auch im P2/P3
verwendet. Der P4 ist allerdings etwas ganz neues ...
>Deswegen gibt es bei der Optimierung auch nur
>den Punkt Pentium Pro, da dieser die gleichen Ergebnisse auch auf
>den P2s und P3s erreicht.
Eben, und MMX/SSE (was der PPro beides nicht hatte) wird ja vom
Compiler nicht benutzt ...
Thomas Markert
wrote:
hi,
>sorry, aber daß weiß ich nicht mehr. Es hat aber auch nichts mit den
>Treiber zu tun sondern eben mit der Hardware. Normalerweise
>schaltet ja auch keiner die Modi im Betrieb um sondern bei der
>Initialisierung. Und wie gesagt, darauf wird in der D3D Doku hingewiesen.
>Auf der anderen Seite könnte man dann ja auch anführen, warum der
>Kyro1/2 Chip so Probleme mit Render To Texture hat.
also soweit ich weiss liegt das weder an der Kyro-Hardware noch an den
Treibern sondern an einem Bug in DirectX 8, der mit DX8.1 behoben
werden soll...bleibt nur die Frage wann der released wird...
cu Thomas
Thorsten Lange
> Spar Dir die Wortklauberei. Du bist schließlich derjenige, der
> den Artikel erstmal in zwei Worten abkanzelt und dann offenbar
> Mühe hat, dafür auf Nachfrage Begründungen zu liefern die nicht
> an den gleichen Problemen leiden, welche 'kritisiert' werden.
Was versuchst Du hier eigentlich zu betreiben? Meine Aussage war
zunächst, der Artikel war weder sachlich noch objektiv. Wenn ich
begründe, warum bei mir dieser Eindruck entstanden ist, kommst Du
plötzlich mit der Behauptung an, ich habe Mühe, eine Begründung zu
beliefern (um Dich zu zitieren: "Beweis durch Behauptung?") und
unterstellst mir Wortklauberei. Bitte versuche im weiteren Verlauf
dieses Threads eine Diskussion zu führen, keine Meta-Diskussion, in
der Du versuchst, auf Nebenschauplätze auszuweichen. Wenn Dir
natürlich die Argumente fehlen, ist das verständlich, dass Du das
versuchst...
> > Natürlich. Die Angaben zur Peak-Performance ist immer die Performance,
> > von der selbst der Hersteller zugibt, dass sie in der Praxis nicht
> > erreicht wird. Das ist bereits seit Jahrzehnten so, und jeder
> > Hersteller beteiligt sich an diesem Spiel.
>
> Und die Erde ist eine Scheibe.
Was ist denn jetzt? Ist meine Aussage falsch? Wird die
Peak-Performance jetzt doch in der Praxis erreicht?
> Für den Core? Beweis duch Behauptung?
Merkst Du was? Dich stört das gleiche, was mich an besagtem Artikel
stört - fehlende Quellenangaben. :-)
> Bitte mach das. Ich behaupte schließlich nicht, das dies alles Mist sei.
> Leider kommst Du auf diese Tour auch nicht an der Tatsache vorbei, das
> der AGP einer der Flaschenhälse ist, die Hardware T&L ausbremsen. Und
> das ist letztlich der Punkt.
Der AGP als Nadelöhr bremst nicht nur T&L aus, er beschränkt den
Durchsatz auf jeden Fall, egal ob nun transformierte Dreiecke
übertragen werden oder nicht-transformierte. T&L hat einfach den
Vorteil, die CPU zu entlasten (bitte wiederhole jetzt nicht wieder den
Satz "dann kauft man eben einfach eine schnellere CPU"), und es
eröffnet überhaupt erst die Möglichkeit Geometriedaten für den
schnelleren Zugriff im Speicher der Grafikkarte abzulegen. Die
Speicherbandbreiten hier liegen deutlich höher (ausser natürlich bei
der MX200). Natürlich kann man hier nicht die gesamte Szene ablegen,
aber man kann wenigstens die Möglichkeit, dies für häufig benötigte
Objekte zu tun - und dank des T-Parts von T&L hat man die Möglichkeit
diese an verschiedenen Positionen in der Szene auftauchen zu lassen.
Aber gut, nehmen wir uns noch einmal die Artikel vor. Die Autoren
behaupten ja, im Durchschnitt müssten 80 Byte pro Dreieck über den AGP
übertragen werden, was ich als überzogen bezeichnet hatte. Meine
eigene Modellrechnung hast Du ja bisher ignoriert, also stelle ich sie
anhand der Zahlen auf den Webseiten erneut auf.
Zunächst stehen dort 12 Byte für 3D-Koordinaten und 12 Byte für den
Normalenvektor. Unter der (vernünftigen) Annahme, dass Smooth-Shading
durchgeführt wird und für jeden Eckpunkt ein Normalenvektor übertragen
werden muss, stimmt das so weit. Die folgenden 4 Bytes für die Farbe
des Dreieecks werden bei Verwendung von T&L (insbesondere "L") jedoch
nicht normalerweise nicht benötigt. Ohne Lighting verwendet man die
Farbinformation üblicherweise dazu, die vorberechnete statische
Beleuchtung in die Darstellung einfließen zu lassen: Die Farbe des
Polygons gibt die Helligkeit vor, die mit der Textur verrechnet wird.
Bei Verwendung von dynamischen Lighting stellt man jedoch nur einmal
die Materialeigenschaften ein, die ein Objekt hat und kann den Rest
der Hardware überlassen.
Dann gehen in die Rechnung noch die Texturkoordinaten ein, in diesem
Fall 16 Byte. Diese Zahl gilt für den Fall, dass Multitexturing mit
zwei Texturen durchgeführt wird. Auf das Zusammenspiel von
Multitexturing und T&L werde ich später noch einmal eingehen; an
dieser Stelle übernehmen wir die Zahl einfach.
Halten wir also 40 Byte pro Eckpunkt fest.
Anschließend wird die Rechnung auf Dreiecke erweitert. Hier beginnen
wir nicht mit 132 Byte, sondern mit den korrigierten 120 Byte aus
unserer Rechnung. Hierauf möchte der Autor dieser Seite 8 Byte für
Texturinformationen aufaddieren, was an dieser Stelle ebenfalls
überflüssig ist, denn die verwendeten Texturen werden nicht pro
Dreieck, sondern pro Objekt eingestellt. Texturwechsel kosten Zeit und
senken die Effizienz etwaiger Caches des Grafikchips; also versucht
man ihre Anzahl so gering wie möglich zu halten und zeichnet nicht
jedes Dreieck mit einer anderen Textur.
Die Angabe eines weiteren Bytes für Steuerparameter ist ebenfalls
überflüssig, denn auch die anderen Kontextwechsel (Blending-Modi,
etc.) werden nicht pro Dreieck durchgeführt. Der Normalenvektor wird
in der Rechnung "Durchschnitt" glücklicherweise weggelassen, denn
sonst müsste ich erneut etwas streichen. ;-) Für Lighting-Zwecke
benötigt man entweder den Normalenvektor der Fläche (Flat-Shading)
oder die Normalenvektoren der Eckpunkte (Smooth-Shading), aber nicht
beide zusammen. Da in der bisherigen Rechnung bereits von
Smooth-Shading ausgegangen wurde, ist der Normalenvektor der Fläche
überflüssig.
Somit bleibt es also bei 120 Bytes pro Dreieck für den Fall, dass
wirklich einzelne Dreiecke gerendert werden.
Kommen wir also zur nächsten Frage: Wie viele Eckpunkte müssen bei der
Verwendung von Triangle-Strips durchschnittlich übermittelt werden.
Im folgenden werde ich einzelne Passagen der Webseite zitieren und
näher darauf eingehen:
| Der Spieleentwickler muss die Daten selbst zu Strips-
| und Fans zusammenfassen, was einen *Mehraufwand*
| bedeutet.
(Hervorhebung durch Sternchen von mir; auf der Webseite fett gedruckt)
Natürlich ist dazu Rechenaufwand nötig - aber nicht während das Spiel
läuft, sondern während der Modellierungsphase; zur Laufzeit des
Programms ändert sich die Topologie eines Objektes normalerweise
nicht. Angesichts der übrigen Vorberechnungen (Lighting, evtl.
BSP-Bäume) wohl ein zu vernachlässigender Schritt.
| Im Idealfall (grosse Flächen von Aussenszenarien)
| kann es sein, dass zur Beschreibung eines Dreiecks
| nur 1 Punkt benötigt wird
Soweit richtig - auch wenn es weniger um große Flächen als um
regelmäßig aufgebaute Objekte geht, in denen sich die einzelnen
Dreiecke eben besser zu Strips zusammenfassen lassen.
| (bei Meshes' sogar noch weniger),
Wie jetzt? Weniger als ein Eckpunkt pro Dreieck in einem Triangle
Strip? Vermutlich hat der Verfasser Quad-Meshes im Sinn gehabt, mithin
sind wir jetzt also bei Quad-Strips.
| während bei hochdetailierten Levels mit
| dynamischer Geometrie
Dynamische Geometrie hat zunächst einmal nichts mit der Topologie
eines Objekts zu tun. Auf Anhieb fällt mir keine Animationsmethode
ein, bei der es nötig wäre, die Topologie eines Dreiecksnetzes zu
verändern und somit eine vorhandene Stripification zu zerstören, wobei
ich mich selbst schwerpunktmäßig mit Character-Animation befasse. Für
einen Quellennachweis für Animation mit Topologieänderung wäre ich
dankbar.
| 2.5 bis 2.9 Eckpunkte/Dreieck benötigt werden.
| Generell kann man sagen, dass die Anzahl benötigter Eckpunkte /
| Dreieck sinkt, je mehr Dreiecke bei einfachen
| Objekten genutzt werden. Dynamische und
| hochkomplexe Geometrie bewirkt das Gegenteil.
Um Dich zu zitieren: Beweis durch Behauptung? Nach meiner Erfahrung
ist eher das Gegenteil der Fall: Je höher aufgelöst ein Objekt ist,
umso besser kann man Triangle-Strips finden.
Im weiteren greift der Autor eine die spekulative Zahl von 1,7
Eckpunkten/Dreieck aus der Luft und gelangt so zu einem
Durchschnittswert von 80 Byte pro Dreieck. Benutzt man die 120 Bytes
aus meiner Rechnung wären es übrigens nur 68 Bytes.
Wie glaubhaft ist diese Zahl von 1,7 unter der Voraussetzung, dass
hochaufgelöste Modelle verwendet werden? Nun, nicht nur
Spieleentwickler befassen sich mit der Erzeugung von Triangle-Strips;
das Thema ist auch ein Forschungs-Gegenstand, wodurch wir
glücklicherweise auf wissenschaftliche Veröffentlichungen
zurückgreifen können. Der Vorteil: Wissenschaftliche Aussagen sind
überprüfbar (im Gegensatz zur Werbung ;-)) und werden in der Regel von
der wissenschaftlichen Gemeinde auch überprüft.
Ich möchte an dieser Stelle zwei Veröffentlichungen herausgreifen
(diese sind auch im WWW verfügbar). Die erste ist
Francine Evans, Steven Skiena, Amitabh Varshney
Efficiently Generating Triangle Strips for Fast Rendering
(Verfügbar auf der Strip-Homepage <http://www.cs.sunysb.edu/~stripe/>)
Bei dem zweiten handelt es sich um
Xinyu Xiang, Martin Held, Josph S. B. Mitchell
Fast and Effective Stripification of Polygonal Surface Models
im Web: <http://www.cosy.sbg.ac.at/~held/projects/strips/strips.html>
In beiden Veröffentlichungen werden die vorgestellten Verfahren
natürlich auch auf Ihre Effizienz untersucht; beide erzielen deutlich
bessere Raten als 1,7 - die Ergebnisse liegen teilweise sogar unter
1,2 Eckpunkte/Dreieck und nie über 1,3.
Die Untersuchungen wurden dabei an hochdetaillierten Modellen
durchgeführt (z.T. über 20.000 Dreiecke); die obige Aussage, in diesem
Fall sinke die Effizienz der Stripification, scheint damit deutlich
widerlegt.
Geht man von den 120 Byte/Dreieck und einem Verhältnis von 1,3 aus,
landen wir bei durchschnittlich 52 Bytes pro Dreieck. 20 Millionen
Dreiecke/s erforderten also eine Bandbreite von ca. 1 GB/s. Immer noch
sehr viel - aber deutlich weniger als die genannten 1,6 GB/s, oder?
Verzichtet man auf das Lighting (wie es in derzeitgen Spielen ja der
Fall ist), kann man sich die Übertragung der Normalenvektoren sparen,
muss dann jedoch wieder Farbinformationen übermitteln. Die Rechnung
läge dann bei 32 Bytes/Eckpunkt, 42 Bytes/Dreieck und ca. 840 MB/s...
Kommen wir nun noch einmal, wie versprochen, auf das Thema
Multitexturing zurück. Die derzeit wichtigste Anwendung dafür ist
sicherlich das zusätzliche Aufbringen einer Lightmap. Lighting in
Hardware könnte diese Lightmap überflüssig machen, mithin also die zur
Übermittlung der Dreiecksdaten erforderliche Bandbreite reduzieren
(weniger Texturkoordinaten) und so die Performance steigern. Wenn
durch die fehlende Lightmap auch noch auf einen zusätzlichen
Renderpass verzichtet werden kann, würde die Performance sogar
recht drastisch steigen. Eine andere Möglichkeit wäre es, die so
"freigewordene" Textur für andere gestalterische Zwecke einzusetzen
und so den visuellen Eindruck bei gleichbleibender Performance zu
verbessern.
Bye,
Thorsten (in der Hoffnung, dass die weitere Diskussion nicht mehr über
die Form, sondern über die Sache geführt wird)
Thorsten Lange
[Compiler-Optimierung füer Prozessoren]
> IMHO haben der Pentium Pro, II, III die gleichen Pipelines.
Sie basieren auf dem gleichen Kern, richtig.
> Beim P4 bin ich mir nicht sicher.
Völlig zu Recht. ;-) Der P4 ist eine komplette Neuentwicklung.
> Deswegen gibt es bei der Optimierung auch nur
> den Punkt Pentium Pro, da dieser die gleichen Ergebnisse auch auf
> den P2s und P3s erreicht.
Beim Scheduling gibt es dennoch Unterschiede zwischen den Prozessoren
(näheres in den Optimization Guidelines von Intel); es macht nicht
viel aus, aber mir ging es eher darum, Tendenzen aufzuzeigen. Ein
wesentlicher Unterschied zwischen PPro und P-III besteht ja auch in
der hinzugekommenen SSE-Einheit, die vom Visual-C++ völlig ignoriert
wird. Hiermit könnte man durchaus Verbesserungen erzielen. Als
Beispiel sei der deutlich bessere optimierende Intel-Compiler
genannt, der IIRC auch auf SSE-Befehle zurückgreift.
Bye,
Thorsten
Thomas Eßer
> Was versuchst Du hier eigentlich zu betreiben? Meine Aussage war
Stell mir keine Fragen, die Du erstmal für Dich beantworten
solltest. Halten wir einfach mal fest:
- Du kanzelst völlig unbegründet einen Artikel deftig ab.
- Auf Nachfrage kommen dann imo eher müde Begründungen, die
zumindest mich nicht überzeugen.
- Stattdessen wird sich weit von Tenor des Artikels entfernt.
> zunächst, der Artikel war weder sachlich noch objektiv. Wenn ich
> begründe, warum bei mir dieser Eindruck entstanden ist, kommst Du
Eben diese Begründung geht aber vollkommen am Tenor des von Dir
so beanstandeten Artikels vorbei, das habe ich mehrfach erwähnt,
findet aber keine Berücksichtigung, stattdessen versuchst Du
auffallend häufig das ganze auf eine persönliche Ebene zu
ziehen. Abgesehen davon sparst Du auch, aber nicht nur dabei nicht
mit ziemlich bissigen Kommentaren. Wenn Du das brauchst bitte, aber
dann nicht über das Echo wundern.
>> Und die Erde ist eine Scheibe.
>
> Was ist denn jetzt? Ist meine Aussage falsch? Wird die
> Peak-Performance jetzt doch in der Praxis erreicht?
Ja, sie ist falsch. Genau darum geht es doch - Werbung vs. Realität am
Beispiel Hardware T&L. Kein Hersteller wird jemals zugeben, das die
Werbungstraumwerte mit der Realität nichts zu tun haben.
>> Für den Core? Beweis duch Behauptung?
>
> Merkst Du was? Dich stört das gleiche, was mich an besagtem Artikel
> stört - fehlende Quellenangaben. :-)
Ich hatte vorausgesetzt, das Dir der Zusammenhang zwischen MX, MX-200
und MX-400 Dir bekannt sind. Ein Irrtum, wie es scheint ;). Außer den
marketingtechnischen unterschieden in der Taktfrequenz gibt es keine
Änderungen am Core, welche an der Peakperformance etwas ändern
würden. Die NVidia Homepage findet Du sicher selbst ;).
> Der AGP als Nadelöhr bremst nicht nur T&L aus, er beschränkt den
> Durchsatz auf jeden Fall, egal ob nun transformierte Dreiecke
Bingo. Wäre es also verkehrt zu sagen, das Hardware T&L den AGP
noch mehr belastet als wenn man alles die CPU erledigen läßt:)?
Sicher gibt es einen theoretischen Vorteil, das bestreitet niemand
ersthaft, aber in der Praxis und da erst recht im Vergleich zu den
getätigten Werbeaussagen bleibt davon halt nichts übrig.
> Aber gut, nehmen wir uns noch einmal die Artikel vor. Die Autoren
Welchen Artikel? 3dcenter oder 3dconcept? Letztere, den Du ja sezieren
wollten, gehen übrigens von 26 bis 68 Bytes pro Eckpunkt aus, bei einem
Schnitt von 44 Bytes. Selbst mit dem gedachten Faktor 1.7 sind das
'nur' noch ~75 Bytes, wenn man von 1.2 ausgeht 53 Bytes.
[...]
> In beiden Veröffentlichungen werden die vorgestellten Verfahren
> natürlich auch auf Ihre Effizienz untersucht; beide erzielen deutlich
> bessere Raten als 1,7 - die Ergebnisse liegen teilweise sogar unter
> 1,2 Eckpunkte/Dreieck und nie über 1,3.
Was immer noch kein Hinweis darauf ist, wie es in real existierenden
Spielen aussieht, ich gehe doch davon aus, das es sich /nicht/ um
Untersuchungen an grafischem Mainstreak, aka Spielen handelt?
> Die Untersuchungen wurden dabei an hochdetaillierten Modellen
> durchgeführt (z.T. über 20.000 Dreiecke); die obige Aussage, in diesem
> Fall sinke die Effizienz der Stripification, scheint damit deutlich
> widerlegt.
Das behauptet ja auch niemand. Allerdings lassen sich derart hohe
Polygonzahlen (noch) nicht in Spielen wiederfinden. Beide Artikel
gehen aber von Spielen aus.
> Geht man von den 120 Byte/Dreieck und einem Verhältnis von 1,3 aus,
> landen wir bei durchschnittlich 52 Bytes pro Dreieck. 20 Millionen
Dann kann der Artikel auf 3dConcept ja so verkehrt nicht sein, 52 zu 53
sehe ich nicht als Problem ;).
> Dreiecke/s erforderten also eine Bandbreite von ca. 1 GB/s. Immer noch
> sehr viel - aber deutlich weniger als die genannten 1,6 GB/s, oder?
Richtig - nur ist dieses 'nur' 1 GB/Sek. für derzeitige Systeme immer
noch deutlich zu viel. Overhead, Fillbytes ect. fehlen ja immer noch,
weder CPU, Chipset noch RAM können das liefern. Womit wir wieder beim
Ausgangspunkt wären.
[Multitexturing]
> durch die fehlende Lightmap auch noch auf einen zusätzlichen
> Renderpass verzichtet werden kann, würde die Performance sogar
> recht drastisch steigen. Eine andere Möglichkeit wäre es, die so
Solange für jeden der Lichtquellen ein Extra Pass eingefügt
werden muß wohl kaum ;). Deswegen ist ja DX-7 L faktisch in den
derzeitigen Implementierungen unbrauchbar. Das es prima wäre
'wenn' bestreitet ja niemand ... dürfte aber mit einer Verbreitung
von DX8+ Hardware ohnehin obsolent sein.
Thomas Eßer
>> Der Quake3/3dMark Einheitsbrei ist das eigentliche Problem ;).
>
> ebenso NACK :-)
? - Meinst Du ersthaft zur Beurteilung eines Grafikchip würde
ein Spiel und ein Demo ausreichen?
> Der Kyro zabelt z.B. bei Giants gut ab. Ist der Chip deswegen schlecht.
Nein, weil es wohl an einem Bug in DX liegt.
> Klar sind die Einheits Benchmarks auch sinnlos. Doch auf meiner GF1
> lief bis auf U9 eben alles absolut flüssig. Da schiebe ich die Schuld
> dann doch eher auf die U9 Engine anstatt auf die Treiber oder die
> Hardware von NVidia.
Dann stellt sich aber wieder die Frage, warum andere Chips erheblich
weniger Probleme haben als alles was auf NVidia Einheitstreibern auf-
setzt. Hohe Versionsnummer und viele 'geleakte' Betas sprechen eher
dafür, das es auch da reichlich Bedarf für Fixes gibt.
Ich erinnere nur an Diablo II oder an das in Grafikkartenzyklen gemessen
endlose S3TC Drama ;).
Gruß,
Thomas
Thomas Eßer
> Noch mehr Beispiele, dass Hardware T&L schneller ist als in Software,
> gibt es unter anderem hier:
Gegenbespiele gibt es hier:
http://www.3dconcepts.de/reviews/3dprophet4500/11.htm
besondern witzig ist der, immerhin ein T&L Demo von NVidia
http://www.3dconcepts.de/reviews/3dprophet4500/31.htm
Gegenbeispiele von weit besser fürs Benchmarking geeigneten
Spielen lassen sich massenweise finden. Und nu?
Thomas Eßer
> wird. Hiermit könnte man durchaus Verbesserungen erzielen. Als
> Beispiel sei der deutlich bessere optimierende Intel-Compiler
> genannt, der IIRC auch auf SSE-Befehle zurückgreift.
Macht er, läßt sich auch prima in der Visual IDE verwenden. Wen
es interessiert:
http://developer.intel.com/software/products/compilers/c50/
bzw.:
http://developer.intel.com/software/products/compilers/c50/vtune_cpp.htm
Hth,
Thomas
Thomas Eßer
> Nicht nur das - es wurden IMO sehr viele Designfehler begangen und dann
> wirklich stur "auf Teufel komm raus" durchgezogen.
In diesem Zusammenhang bin ich auf Dungeon Siege gespannt, soll ja
ebenfalls ohne merkbares nachladen auskommen - ist allerdings gerade
erst verschoben worden ;).
> rübergekommen - dann entweder ein Engine lizensieren oder eine
> spezialisierte, wie z.B. die DarkEngine von Looking Glas, selber
Naja, diese Engine ist ja auch nicht der Knaller. Im EA Sammelsurium
hätte sich bestimmt besseres finden lassen. Allerdings glaube ich
auch, das U9 unter der _zu_ langen Entwicklungszeit und dem hinter-
herlaufen hinter Hardwaretrends gelitten hat.
> schreiben - aber bitte nicht dieses Marketing-BlaBla von wegen "mit
> unserer Engine kann man den ganzen Planeten darstellen, wenn man nur
> weit genug zurückzoomt"...
Das verbreitet sich ja immer mehr ;).
Gruß,
Thomas
Thomas Eßer
>>> Real existierende Spiele wie Max Payne (vor allem in Aussenszenen)
>>> profitieren durchaus von einer Grafikkarte mit T&L, sogar wenn man
>>> eine sehr schnelle CPU hat.
>>
>> Dann gib uns doch mal einen benchmark.
>
> z.B. hier:
> http://www.3dcenter.de/vbulletin/showthread.php?s=&threadid=3407
>
> Hat noch mehr in den 3dcenter.de Foren, und ohne Ausnahme war HW TnL auf
> GF immer schneller als in Software. Allerdings konnte ich noch keine
> Suchfunktion finden, so dass ich nur das hier bieten kann. :(
Hmm, das ist der erste 'Artikel' unter dieser ID:
!Hi, wollte hiermal ein paar Benchmarkergebnisse in Bezug auf T&L in
!MaxPayne posten (1. Szene):
!
!Hardware T&L: 24.05 FPS
!Software T&L: 23.80 FPS
!
!Alle Details auf Maximum, 1280x768, "3x" FSAA, Anisotropic Filtering on.
!System: TB1000@140x10, 256MB DDR@CL2, GF3@215/515
Später gibt es dann weit größere Unterschiede, alle allerdings auf so
tiefem Niveau, welches eine üble CPU Limitierung annehmen läßt. Wobei
sich immer noch die Frage stellt, was die unterschiedlichen Einstellungen
bei MP überhaupt ausmachen. MP als Benchmark würde ich derzeit nur ganz
vorsichtig genießen.
Gruß,
Thomas
Daniel Lichtenberger
>!Hardware T&L: 24.05 FPS
>!Software T&L: 23.80 FPS
>!
>!Alle Details auf Maximum, 1280x768, "3x" FSAA, Anisotropic Filtering on.
>!System: TB1000@140x10, 256MB DDR@CL2, GF3@215/515
>
>Später gibt es dann weit größere Unterschiede, alle allerdings auf so
>tiefem Niveau, welches eine üble CPU Limitierung annehmen läßt.
Naja, eine GF3 ist bei den obigen Einstellungen aber ziemlich sicher
Fillrate-limitiert, bei "normalen" Auflösungen (weiter unten im
Thread) kommen ja durchaus ansehliche Vorteile durch T&L heraus.
Martin Kuras
> > Noch mehr Beispiele, dass Hardware T&L schneller ist als in Software,
> > gibt es unter anderem hier:
>
> Gegenbespiele gibt es hier:
>
> http://www.3dconcepts.de/reviews/3dprophet4500/11.htm
Zumal hier (bei Alice) die Texturkopmression im Spiel noch
ausgeschaltet war, denn sonst hat selbst die GF2u keine Chance
gegen den KyroII.
Martin Kuras
> Naja, eine GF3 ist bei den obigen Einstellungen aber ziemlich sicher
> Fillrate-limitiert, bei "normalen" Auflösungen (weiter unten im
> Thread) kommen ja durchaus ansehliche Vorteile durch T&L heraus.
Wie war das doch gleich mit dem damals heiß diskutiertem im Vergleich
zum HW-T&L schnelleren SW-T&L mit den optimierten 3DNow!-dll´s für
3DMark auf schnellen CPU´s, die heute noch bedeutend schneller
geworden sind? Vielleicht möchte das jemand mal ausgraben?
Thorsten Lange
> > Was ist denn jetzt? Ist meine Aussage falsch? Wird die
> > Peak-Performance jetzt doch in der Praxis erreicht?
>
> Ja, sie ist falsch. Genau darum geht es doch - Werbung vs. Realität am
> Beispiel Hardware T&L. Kein Hersteller wird jemals zugeben, das die
> Werbungstraumwerte mit der Realität nichts zu tun haben.
Hast Du Dich jemals mit einem Hardwarehersteller unterhalten, um das
so sicher behaupten zu können? Auf Nachfrage erfährt man durchaus, wie
es um die praktisch erreichbare Performance bestellt ist. Das ein
Hersteller diese Angaben nicht ebenso groß auf seine Webseiten stellt,
wie die Peak-Angaben, ist irgendwo verständlich.
> Ich hatte vorausgesetzt, das Dir der Zusammenhang zwischen MX, MX-200
> und MX-400 Dir bekannt sind. Ein Irrtum, wie es scheint ;). Außer den
> marketingtechnischen unterschieden in der Taktfrequenz gibt es keine
> Änderungen am Core, welche an der Peakperformance etwas ändern
> würden. Die NVidia Homepage findet Du sicher selbst ;).
Diesen Kommentar kann ich ungebremst zurückgeben. Da die Taktfrequnz
nun einmal einen Einfluss auf die Peakperformance hat und die
MX-Familie mit unterschiedlichen Taktfrequenzen arbeitet, haben die
einzelnen Chips auch unterschiedliche Spitzenleistungen. Oder gibt
nVidia bei allen drei Chips die gleiche Peak-Performance an?
> > Der AGP als Nadelöhr bremst nicht nur T&L aus, er beschränkt den
> > Durchsatz auf jeden Fall, egal ob nun transformierte Dreiecke
>
> Bingo. Wäre es also verkehrt zu sagen, das Hardware T&L den AGP
> noch mehr belastet als wenn man alles die CPU erledigen läßt:)?
Den AGP: ja. Jetzt wärest Du einmal am Zug zu beweisen, dass der AGP
in derzeitigen Spielen tatsächlich das Nadelöhr darstellt. ;-)
Es gilt allerdings, dass die Verwendung der Transform-Funktion der
Hardware keine zusätzliche Last auf dem AGP erzeugt. Für einen fairen
Vergleich sollte man sich dann schon die Situation bei Verwendung von
dynamischen Lighting ansehen. Hier wird tatsächlich etwas mehr Last
auf dem AGP erzeugt, aber dafür erfährt die CPU eine deutliche
Entlastung.
Zahlenbeispiel: Angenommen, wir wollen 2 Millionen Dreiecke/s von 8
Lichtquellen beleuchtete Dreiecke pro Sekunde rendern (nehmen wir wie
zuvor Triangle-Strips mit Faktor 1,3 an und gehen vom Idealfall aus,
dass an keinem Punkt die Berechnung wiederholt werden muss), dann
müssen wir das Beleuchtungsmodell 20,6 Millionen mal pro Sekunde
auswerten, wozu auf einer 1,2-GHz-CPU gerade einmal 57 Taktzyklen
blieben. Ziemlich knapp, wenn Du mich fragst, zumal wir die dazu
benötigten Normalenvektoren noch auf Einheitslänge bringen müssen (was
in Hardware "umsonst" wäre). Nach meinem Eindruck ist das nicht zu
machen; und selbst wenn man das mit geschickter Programmierung doch
noch hinbekommt: Der CPU bliebe keine Zeit mehr, sich um etwas anderes
zu kümmern.
> Welchen Artikel? 3dcenter oder 3dconcept? Letztere,
Letzterer.
> den Du ja sezieren
> wollten, gehen übrigens von 26 bis 68 Bytes pro Eckpunkt aus, bei einem
> Schnitt von 44 Bytes. Selbst mit dem gedachten Faktor 1.7 sind das
> 'nur' noch ~75 Bytes, wenn man von 1.2 ausgeht 53 Bytes.
Wobei die 80 Bytes nicht von mir kommen, sondern von der Seite selbst
(ein gutes Stück nach dieser ersten Tabelle).
Vielleicht hat der Verfasser den von ihm errechneten Gesamtaufwand für
ein Dreieck wieder durch 3 geteilt und diesen Wert dann mit 1,7
multipliziert - ergibt ungerundet 79,9 Bytes.
[Objekte > 20.000 Dreiecke]
> Das behauptet ja auch niemand. Allerdings lassen sich derart hohe
> Polygonzahlen (noch) nicht in Spielen wiederfinden. Beide Artikel
> gehen aber von Spielen aus.
Sie ziehen die derzeitigen Spiele-Engines heran, um anhand deren Werte
zu schlußfolgern, dass detailliertere Spiele durch T&L nicht machbar
sind. Diese Schlußfolgerung möchte ich widerlegen, indem ich aufzeige,
dass bei steigendem Detaillierungsgrad die Effizienz der
Triangle-Strips wächst und nicht etwa - wie dort angenommen - konstant
bleibt oder gar steigt.
> > Geht man von den 120 Byte/Dreieck und einem Verhältnis von 1,3 aus,
> > landen wir bei durchschnittlich 52 Bytes pro Dreieck. 20 Millionen
>
> Dann kann der Artikel auf 3dConcept ja so verkehrt nicht sein, 52 zu 53
> sehe ich nicht als Problem ;).
Die 53 Bytes kommen allerdings von Dir, nicht von der 3dConcept-Seite.
Der dort errechnete Wert liegt bei 80 Bytes. Kann ich daher davon
ausgehen, dass Du mir darin zustimmst, dass diese 80 Byte deutlich zu
hoch gegriffen sind?
> Richtig - nur ist dieses 'nur' 1 GB/Sek. für derzeitige Systeme immer
> noch deutlich zu viel. Overhead, Fillbytes ect. fehlen ja immer noch,
> weder CPU, Chipset noch RAM können das liefern. Womit wir wieder beim
> Ausgangspunkt wären.
In praktischen Anwendungen kommt auch noch die Zeit hinzu, die z.B.
benötigt wird, Bildschirm und Z-Puffer zu löschen, Texturen
hochzuladen, den Seitenwechsel durchzuführen, etc. Während dieser Zeit
liegt der Dreiecksdurchsatz bei exakt 0 Polygonen/s.
Leicht einzusehen, dass deswegen der durchschnittlich erreichte
Dreiecksdurchsatz unter der Peak-Performance liegt. Hierauf wollte ich
mit dem Begriff der Höchstgeschwindigkeit hinaus - es ist durchaus
legitim, mit dieser zu werben. Auch bei Speicherbausteinen
findet man ja immer wieder die Angaben zur "maximalen Bandbreite", die
deutlich über dem erzielbaren Speicherdurchsatz liegen.
Festplattenhersteller werben mit den 100 MB/s des IDE-Bus, nicht etwa
mit der Dauerübertragungsrate, die aussagekräftiger wäre, aber
deutlich geringer ausfällt.
Diese Werbeaussagen dürfen gemacht werden, denn der Speicher erzielt
diese Bandbreite, wenn auch nur während der drei Takte, die auf den
Lead-Off-Cycle eines Burst folgen und die Festplatte überträgt die
Daten auf dem IDE-Bus mit 100 MB/s, wenn sie erst einmal von der
Plattenoberfläche geholt wurden - also nutzen die Hersteller diese
günstige Gelegenheit und schreiben möglichst große Zahlen in ihre
bunten Flyer. Warum sollte man das Grafikchip-Herstellern nicht ebenso
zugestehen? ATI bewirbt den Radeon 8500 übrigens mit 75 Millionen
Polygonen/s...
> [Multitexturing]
>
> > durch die fehlende Lightmap auch noch auf einen zusätzlichen
> > Renderpass verzichtet werden kann, würde die Performance sogar
> > recht drastisch steigen. Eine andere Möglichkeit wäre es, die so
>
> Solange für jeden der Lichtquellen ein Extra Pass eingefügt
> werden muß wohl kaum ;).
Oh, nicht für jede. Die GeForce-Chips enthalten einen Vertex-Cache
(FIFO-Strategie) für die letzten 10 Eckpunkte, die durch T&L gegangen
sind. Werden diese Eckpunkte erneut benutzt, entfällt die für das
Lighting benötigte Rechenzeit. Ein weiterer Grund, Triangle-Strips zu
benutzen. :-)
> Deswegen ist ja DX-7 L faktisch in den derzeitigen Implementierungen
> unbrauchbar.
Dazu möchte ich keine Aussage machen, da ich mit diesem API keine
ausreichende praktische Erfahrung habe - bin halt OpenGL-Entwickler,
und dort ist T&L problemlos nutzbar.
> Das es prima wäre
> 'wenn' bestreitet ja niemand ... dürfte aber mit einer Verbreitung
> von DX8+ Hardware ohnehin obsolent sein.
Sofern deren zusätzliche Features auch tatsächlich benutzt werden;
sonst heisst es in einem Jahr wieder "Marketing-Lüge!" ;-))
bye,
Thorsten
Martin Horst
Hi,
>Martin Horst schrieb:
>
>>> Der Quake3/3dMark Einheitsbrei ist das eigentliche Problem ;).
>>
>> ebenso NACK :-)
>
>? - Meinst Du ersthaft zur Beurteilung eines Grafikchip würde
>ein Spiel und ein Demo ausreichen?
Nein, daß meinte ich damit nicht.
>> Der Kyro zabelt z.B. bei Giants gut ab. Ist der Chip deswegen schlecht.
>Nein, weil es wohl an einem Bug in DX liegt.
Schwer vorzustellen. Es liegt wohl am Render To Textur. Und bei anderen
Chips läuft es ja auch. Würde mich also wundern.
>> Klar sind die Einheits Benchmarks auch sinnlos. Doch auf meiner GF1
>> lief bis auf U9 eben alles absolut flüssig. Da schiebe ich die Schuld
>> dann doch eher auf die U9 Engine anstatt auf die Treiber oder die
>> Hardware von NVidia.
>
>Dann stellt sich aber wieder die Frage, warum andere Chips erheblich
>weniger Probleme haben als alles was auf NVidia Einheitstreibern auf-
Gute frage. Wie gesagt, auf meiner ATI lief es auch nicht besser. Und wo da
die paar FPS herkommen weiß ich auch nicht. Wer weiß was für ein
Texturmanagment die da verwendet haben. Ob es ein eigenes (wahrscheinlich
wegen Glide), oder ob es das von DX ist. Das kann tausend Gründe habe.
Und der Benchmark ist IMHO eh mißt. Der Avatar läuft ja nur gerade durch
Britania durch. Es wird doch erst lustig beim drehen.
Aber wie auch bereits erwähnt. Andere Chips haben mit anderen Spielen
auch Probleme. Kryo und ATI haben sich bei Max Payne auch nicht mit
Ruhm bekleckert. Woran liegt das!?
>setzt. Hohe Versionsnummer und viele 'geleakte' Betas sprechen eher
>dafür, das es auch da reichlich Bedarf für Fixes gibt.
Das mit den geleakten Treibern ist aber was anderes. Die sind von
NVidia nicht freigegeben und sollten eigentlich nicht ins Netz gelangen
sondern sind für Hardware Hersteller gedacht. Wenn jemand meint, er
müsse alle 5 Sekunden einen neuen Treiber installieren, dann ist das
sein Problem.
>Ich erinnere nur an Diablo II oder an das in Grafikkartenzyklen gemessen
>endlose S3TC Drama ;).
Was meinst du damit!? Also Diablo2 lief bei mir ohne Probleme. Na ja,
einmal durchgespielt und in die Ecke geschmissen. Für Single Player
doch eher uninteressant.
Gruß
Martin
Sascha Erni, .rb
"Thomas Eßer" <sa...@gmx.net> schrieb ...
> MP als Benchmark würde ich derzeit nur ganz
> vorsichtig genießen.
Absolut und total ACK.
ta,
.rb
Sascha Erni, .rb
> Gegenbespiele gibt es hier:
>
> http://www.3dconcepts.de/reviews/3dprophet4500/11.htm
>
> besondern witzig ist der, immerhin ein T&L Demo von NVidia
>
> http://www.3dconcepts.de/reviews/3dprophet4500/31.htm
>
> Gegenbeispiele von weit besser fürs Benchmarking geeigneten
> Spielen lassen sich massenweise finden. Und nu?
Sorry Thomas, aber der Poster hat explizit nach Max Payne Benchmarks
gefragt, i.e. wollte belegt haben, dass in der einen Applikation hardware
TnL was bringt. Niemand hat behauptet, dass Max Payne dadurch zum
repräsentativen Benchmark für alle TnL Spiele würde.
Eher noch, die Ursprungsbehauptung (die ich übrigens nicht voll teile) ist
ja gerade, dass MP eines der *ersten* Spiele ist, bei dem TnL was bringt.
Das mit einer 2jährigen Engine zu kontern ... ich weiss ja nicht.
:)
ta,
.rb
Martin Horst
Hi,
>Martin Horst <MHo...@unprotect.de> writes:
>
>[Compiler-Optimierung füer Prozessoren]
>> IMHO haben der Pentium Pro, II, III die gleichen Pipelines.
>
>Sie basieren auf dem gleichen Kern, richtig.
>
>> Beim P4 bin ich mir nicht sicher.
>
>Völlig zu Recht. ;-) Der P4 ist eine komplette Neuentwicklung.
Hatte ich also doch richtig im Kopf :-)
>> Deswegen gibt es bei der Optimierung auch nur
>> den Punkt Pentium Pro, da dieser die gleichen Ergebnisse auch auf
>> den P2s und P3s erreicht.
>
>Beim Scheduling gibt es dennoch Unterschiede zwischen den Prozessoren
>(näheres in den Optimization Guidelines von Intel); es macht nicht
>viel aus, aber mir ging es eher darum, Tendenzen aufzuzeigen. Ein
>wesentlicher Unterschied zwischen PPro und P-III besteht ja auch in
>der hinzugekommenen SSE-Einheit, die vom Visual-C++ völlig ignoriert
>wird. Hiermit könnte man durchaus Verbesserungen erzielen. Als
>Beispiel sei der deutlich bessere optimierende Intel-Compiler
>genannt, der IIRC auch auf SSE-Befehle zurückgreift.
Mit den SSE Befehlen ist das so eine Sache. So richtig viele verwendet
der Intel Compiler ja auch nicht. Und bei Vektor Befehlen (die ja für die
Vektorrechnung recht interessant sind) ist eh Assembler angesagt
(und den kann man ja nachträglich einbinden). Denn Vektorisierung durch
den C Compiler ist schon so eine Sache (ich weiß wovon ich rede, ich
mache es gerade :-) ).
Und der Intel Compiler optimiert ja wiederum nur für Intel Prozessoren.
Und dann haben die Leute mit AMD Prozessoren keinen richtigen
Spaß mehr daran.
BTW: Der VC7 soll ja noch 'ne ganze Ecke besser werden.
Sprich: Auch wie der Intel Compiler ein global optimierende
profilierender Compiler sein.
Gruß
Martin
Daniel Lichtenberger
wrote:
>Wie war das doch gleich mit dem damals heiß diskutiertem im Vergleich
>zum HW-T&L schnelleren SW-T&L mit den optimierten 3DNow!-dll´s für
>3DMark auf schnellen CPU´s, die heute noch bedeutend schneller
>geworden sind?
Ich vermute MadOnion hat das "Problem" im 3DMark 2001 "behoben". ;-)
IIRC waren aber auch nicht die Spieleszenen in Software-T&L schneller
(eher umgekehrt), sondern die synthetischen High-Poly-Tests, weil das
Hardware-Lighting bei 4 und 8 Lichtern sehr stark eingebrochen ist.
Lustig war's aber trotzdem ;)
>Vielleicht möchte das jemand mal ausgraben?
Bloß nicht ;-)
Martin Kuras
> >Wie war das doch gleich mit dem damals heiß diskutiertem im Vergleich
> >zum HW-T&L schnelleren SW-T&L mit den optimierten 3DNow!-dll´s für
> >3DMark auf schnellen CPU´s, die heute noch bedeutend schneller
> >geworden sind?
>
> Ich vermute MadOnion hat das "Problem" im 3DMark 2001 "behoben". ;-)
> IIRC waren aber auch nicht die Spieleszenen in Software-T&L schneller
> (eher umgekehrt), sondern die synthetischen High-Poly-Tests, weil das
> Hardware-Lighting bei 4 und 8 Lichtern sehr stark eingebrochen ist.
Ja genau!
> Lustig war's aber trotzdem ;)
Oh ja......
> >Vielleicht möchte das jemand mal ausgraben?
>
> Bloß nicht ;-)
Nun, war nicht wirklich ernst gemeint und sollte eher den Charakter
einer Drohung haben. ;)
Thomas Eßer
> hardware TnL was bringt. Niemand hat behauptet, dass Max Payne dadurch
> zum repräsentativen Benchmark für alle TnL Spiele würde.
Genau so las es sich aber. Wobei auf die ganzen zweifelhaften Details
der MP Verliebten wieder mal keiner eingeht. Mir war halt diese
kritiklose Beweihräuchrung zu sehr in der Nähe von 3d Mark, obwohl das
ja nun wirklich paßt ;).
Gruß,
Thomas
Thomas Eßer
>> Ja, sie ist falsch. Genau darum geht es doch - Werbung vs. Realität am
>> Beispiel Hardware T&L. Kein Hersteller wird jemals zugeben, das die
>> Werbungstraumwerte mit der Realität nichts zu tun haben.
>
> Hast Du Dich jemals mit einem Hardwarehersteller unterhalten, um das
> so sicher behaupten zu können? Auf Nachfrage erfährt man durchaus, wie
Was intern da so abgesondert wird, sieht man an der Kyro II 'Argumentationshilfe' aus
NVidia Internen Beständen ;). Davon abgesehen wird der durchschnittliche Kunde genau
danach /nicht/ fragen, wobei ich es zusätzlich noch für sehr zweifelhaft halte,
das er wenn eine halbwegs ehrliche Antwort erhalten würde.
Das eigentliche Problem liegt aber im gewöhnlich völlig kritiklosen
Übernehmen dieser 'Informationen' seitens der Medien.
> Diesen Kommentar kann ich ungebremst zurückgeben. Da die Taktfrequnz
> nun einmal einen Einfluss auf die Peakperformance hat und die
Der Core ist der gleiche. Dazu gibt es durchaus verschieden getaktete
MX aller Varianten. Studier die Specs der Kartenfabrikanten.
>> Bingo. Wäre es also verkehrt zu sagen, das Hardware T&L den AGP noch
>> mehr belastet als wenn man alles die CPU erledigen läßt:)?
>
> Den AGP: ja. Jetzt wärest Du einmal am Zug zu beweisen, dass der AGP
> in derzeitigen Spielen tatsächlich das Nadelöhr darstellt. ;-)
Ich schrieb bereits, das der AGP _einen_ der Engpässe darstellt. PC
ist halt ein Sstem voller Engpässe.
>> Welchen Artikel? 3dcenter oder 3dconcept? Letztere,
>
> Letzterer.
Dann kannst Du kaum auf 80 Bytes rumreiten - die stammen afaik aus
ersterem. Was aber alles nichts daran ändert, das auch Deine Zahlen
eindrucksvoll beweisen, das die theoretische Leistung sich nichtmal
annähernd in der Praxis nutzen läßt ;).
> Die 53 Bytes kommen allerdings von Dir, nicht von der 3dConcept-Seite.
> Der dort errechnete Wert liegt bei 80 Bytes. Kann ich daher davon
> ausgehen, dass Du mir darin zustimmst, dass diese 80 Byte deutlich zu
> hoch gegriffen sind?
Kann sein, kann nicht sein. Solange sich Raphael auf der Maur sich dazu
nicht äußert, kann ich dazu nichts sagen. Wie stehst Du allerdings zu
der dort zu findenen Aussage, das laut id Software pro Eckpunkt im
Schnitt 40 Bytes angibt - beim alten Quake2?
>> Richtig - nur ist dieses 'nur' 1 GB/Sek. für derzeitige Systeme immer
>> noch deutlich zu viel. Overhead, Fillbytes ect. fehlen ja immer noch,
>> weder CPU, Chipset noch RAM können das liefern. Womit wir wieder beim
>> Ausgangspunkt wären.
[...]
> Leicht einzusehen, dass deswegen der durchschnittlich erreichte
> Dreiecksdurchsatz unter der Peak-Performance liegt. Hierauf wollte ich
> mit dem Begriff der Höchstgeschwindigkeit hinaus - es ist durchaus
> legitim, mit dieser zu werben. Auch bei Speicherbausteinen
Sicher ist das legitim. Genau da liegt offebar auch das Problem.
Tu Dir den Gefallen und zieh Dir mal die konkreten Werbeaussagen
zum Thema T&L rein, stöber mal auf den damaligen euphorischen
'Artikeln' zum Thema und guck Dir den 3d Mark an ;).
> Dazu möchte ich keine Aussage machen, da ich mit diesem API keine
> ausreichende praktische Erfahrung habe - bin halt OpenGL-Entwickler,
> und dort ist T&L problemlos nutzbar.
Siehst Du - hier wird es eher aus der Sicht der Anwender gesehen ;) und
wie bereits erwähnt liegt vermutlich genau da unser Problem.
> Sofern deren zusätzliche Features auch tatsächlich benutzt werden;
> sonst heisst es in einem Jahr wieder "Marketing-Lüge!" ;-))
Ich schätze, trotz X-Box - das es mindestens 2-3 Jahre dauern wird bis das
dieser Kram nennenswert unterstützt wird.
Thomas Eßer
>>>> Der Quake3/3dMark Einheitsbrei ist das eigentliche Problem ;).
>>>
>>> ebenso NACK :-)
>>
>> ? - Meinst Du ersthaft zur Beurteilung eines Grafikchip würde ein
>> Spiel und ein Demo ausreichen?
> Nein, daß meinte ich damit nicht.
Dann hab ich offenbar ein ernsthaftes Verständigungsproblem mit
Deinem 'NACK'.
>> Der Kyro zabelt z.B. bei Giants gut ab. Ist der Chip deswegen
>>> schlecht. Nein, weil es wohl an einem Bug in DX liegt.
> Schwer vorzustellen. Es liegt wohl am Render To Textur. Und bei anderen
> Chips läuft es ja auch. Würde mich also wundern.
Eben, und da liegt wohl das Problem bei DX8.0 - zumindest wenn man
der Kyro FAQ trauen darf.
http://www.paraknowya.com/specials/faq/index.shtml#sdf
> Spielen auch Probleme. Kryo und ATI haben sich bei Max Payne auch nicht
> mit Ruhm bekleckert. Woran liegt das!?
Wahrscheinlich weil NVidia und Remedy, bzw. Madonion es wohl ziemlich
gut miteinander können. Umgekehrt gibt es auch jede Menge Spiele,
welche auf anderen Karten schneller und/oder optsich reizvoller
laufen.
>> setzt. Hohe Versionsnummer und viele 'geleakte' Betas sprechen eher
>> dafür, das es auch da reichlich Bedarf für Fixes gibt.
> Das mit den geleakten Treibern ist aber was anderes. Die sind von
> NVidia nicht freigegeben und sollten eigentlich nicht ins Netz gelangen
So ist die offizielle Leseart. Wenn NVdidia /wollte/, würde es
diese massenhafte Verbreitung nicht geben. Oder all die anderen
Hersteller sind viel Schlauer, was ich nun wriklich nicht glaube.
Zum einen fixt man auf diese Tour wunderbar die Leute an, zum
anderen ist das ein gigantischer und vor allem kostenloser Beta-
test. PR mal anders.
> sondern sind für Hardware Hersteller gedacht. Wenn jemand meint, er
> müsse alle 5 Sekunden einen neuen Treiber installieren, dann ist das
> sein Problem.
Sicher aind das diese Knalltüten selbst schuld - und das Result können
wir hier laufend besichtigen. Danke auch ;). Allerdings wird der deutliche
Hinweis auf Betastatus regelmäßig 'vergessen' - für mich ein Indiz dafür,
das geleakt letztlich mit Absicht gleichzusetzen ist. 'Hilfe, ich habe ein
Problem mit Detonator schlagmichtot' Threads finde ich mittlerweile genauso
dämlich, wie 'Mein 3dMark ist länger als Deiner'. Alles letztlich Synonyme
für sich rapide ausbreitende Erweichung der Brainware ;).
>> Ich erinnere nur an Diablo II oder an das in Grafikkartenzyklen
>> gemessen endlose S3TC Drama ;).
> Was meinst du damit!? Also Diablo2 lief bei mir ohne Probleme. Na ja,
> einmal durchgespielt und in die Ecke geschmissen. Für Single Player
> doch eher uninteressant.
Mit den damals beim Release offiziell verfügbaren 'Detonatoren' zickte
Diablo 2 grausam rum. Abhilfe schafften erst geleakte Betatreiber ...
Schau mal bei Google oder einem Newsserver mit hoher Haltezeit.
Gruß,
Thomas
Thomas Eßer
> Und der Intel Compiler optimiert ja wiederum nur für Intel Prozessoren.
Allerdings laufen die Kompilate oftmals auf einem K7+ auch richtig
gut ;). Segen und Fluch der doch recht engen X86 Geschichte.
> Und dann haben die Leute mit AMD Prozessoren keinen richtigen
> Spaß mehr daran.
Och doch, meistens schon.
Gruß,
Thomas
Thomas Eßer
> Nun, war nicht wirklich ernst gemeint und sollte eher den Charakter
> einer Drohung haben. ;)
Gelungen, absolut gelungen ;).
Thorsten Lange
[...]
> Davon abgesehen wird der durchschnittliche Kunde genau
> danach /nicht/ fragen, wobei ich es zusätzlich noch für sehr zweifelhaft halte,
> das er wenn eine halbwegs ehrliche Antwort erhalten würde.
Das Problem besteht darin, dass der Kunde normalerweise nicht beim
Hersteller nachfragt. Über solche "Details" unterhält sich
normalerweise der Entwickler mit dem Hersteller...
Was der Kunde beim Discounter oder Kistenschieber als Antwort erhält,
ist dagegen völlig offen. Manchmal wäre ich froh, wenn ich an diesen
Orten wenigstens die Werbeaussagen der Hersteller zu hören bekäme. ;-)
> Das eigentliche Problem liegt aber im gewöhnlich völlig kritiklosen
> Übernehmen dieser 'Informationen' seitens der Medien.
Oh ja - Kompetenz der Computerzeitschriften. Ein völlig anderes Thema;
hier gibt es aber noch einen völlig anderen Punkt: Der
Durchschnitts-User will überhaupt nichts von den komplexen
Zusammenhängen in einem PC wissen. (Deshalb kann man ihn ja so gut mit
Zahlen ködern. ;-))
> Dann kannst Du kaum auf 80 Bytes rumreiten - die stammen afaik aus
> ersterem.
Die 80 Bytes sind das "Endergebnis" im 3dConcept-Artikel. Zu finden unter
<http://www.3dconcept.ch/artikel/T&L/11.htm>, letzter Satz.
> Was aber alles nichts daran ändert, das auch Deine Zahlen
> eindrucksvoll beweisen, das die theoretische Leistung sich nichtmal
> annähernd in der Praxis nutzen läßt ;).
Diese 80 Bytes werden im 3dcenter-Artikel allerdings dazu
herangezogen, um zu beweisen, dass sich 20 Millionen Dreiecke/s nicht
einmal theoretisch erreichen lassen (weil das die sogar die
theoretische Bandbreite des AGP übersteigen würde), und diese Aussage
lässt sich mit meiner Rechnung problemlos widerlegen. Mehr wollte ich
nicht.
> Wie stehst Du allerdings zu
> der dort zu findenen Aussage, das laut id Software pro Eckpunkt im
> Schnitt 40 Bytes angibt - beim alten Quake2?
Da ich keinen Zugang zum Source-Code der Quake2-Engine habe, kann ich
nur spekulieren. Die Größenordnung kommt auf jeden Fall hin;
allerdings ist die Formulierung "Speicherbedarf" ein wenig unklar. Die
Engine kann ja durchaus noch Informationen zur Verwaltung benötigen,
die aber nicht an die Grafikkarte übermittelt werden müssen.
> Sicher ist das legitim. Genau da liegt offebar auch das Problem.
> Tu Dir den Gefallen und zieh Dir mal die konkreten Werbeaussagen
> zum Thema T&L rein, stöber mal auf den damaligen euphorischen
> 'Artikeln' zum Thema und guck Dir den 3d Mark an ;).
Da liegt der Unterschied zwischen dem, was sich alle von T&L erhofft
hatten und dem, was tatsächlich umgesetzt wurde. Tatsache ist nun
einmal, dass das Lighting-Feature von Spielen praktisch ignoriert
wird. Eigentlich schade, denn hier geht sicher einiges verloren. Woran
liegt es? IMHO daran, dass Spiele auf jeder Hardware laufen sollen.
Ein Spiel, das T&L voraussetzt wird sich ganz einfach schlechter
verkaufen als eines, das ohne auskommt - und diese Überlegung gilt für
jedes spezielle Feature und zeigt den Nachteil der gängigen
Entwicklungspraxis bei 3D-Chips auf: Jeder Hersteller versucht, sich
von der Konkurrenz abzusetzen und implementiert tolle neue Features.
Dummerweise hat er damit etwas geschaffen, was sich
betriebswirtschaftlich ganz toll anhört, nämlich ein
Alleinstellungsmerkmal. In der Praxis bedeutet das aber, dass der
Markt dieses Feature nur schleppend annimmt; erst wenn andere
Hersteller nachgezogen haben und das neue Feature praktisch zur
Standardausstattung gehört, findet es breite Unterstützung.
Die gestalterischen Einschränkungen, die einem durch T&L auferlegt
werden (erzeugen einer bestimmten Lichtstimmung) sind da weniger die
Ursache. Selbst Mischformen von bisher üblicher Programmierung und T&L
sind denkbar: Man kann durchaus die Beleuchtung für den statischen
Teil der Szene wie gehabt vorberechnen, dann jedoch T&L zur Laufzeit
benutzen um z.B. einen Character, der unter einer Laterne
hindurchgeht, korrekt zu beleuchten (für solche Effekte behilft man
sich zur Zeit einfach damit, dass die gesamte Figur erhellt wird und
darauf hofft, dass niemand den Unterschied bemerkt). Ein anderes
Beispiel: Warum findet man in First-Person-Shootern so häufig
Nachtsichtgeräte? Nicht nur, weil sie cool sind, sondern weil
Taschenlampen so schwer zu implementieren sind. Eine ordentliche
Taschenlampe wirft nun einmal einen eng begrenzten Lichtkegel. Mit T&L
wäre der relativ leicht zu implementieren (damit das wirklich gut
aussieht, benötigt man allerdings recht fein aufgelöste 3D-Modelle
oder echtes Phong-Shading, was aber auch durch
Dot-Product-Bump-Mapping erreicht werden kann). Wäre schon nett, wenn
man sich damit durch ein dunkles Gebäude tasten könnte...
Man könnte also auch, ohne gleich alles mit T&L erschlagen zu wollen,
ein paar nette zusätzliche Effekte implementieren, für die man noch
nicht einmal besonders viele Hardware-Lichtquellen benötigt.
Bye,
Thorsten
Martin Horst
Moin,
>Martin Horst schrieb:
>
>>>>> Der Quake3/3dMark Einheitsbrei ist das eigentliche Problem ;).
>>>>
>>>> ebenso NACK :-)
>>>
>>> ? - Meinst Du ersthaft zur Beurteilung eines Grafikchip würde ein
>>> Spiel und ein Demo ausreichen?
>> Nein, daß meinte ich damit nicht.
>
>Dann hab ich offenbar ein ernsthaftes Verständigungsproblem mit
>Deinem 'NACK'.
War wohl ein bischen undeutlich :-)
>>> Der Kyro zabelt z.B. bei Giants gut ab. Ist der Chip deswegen
>>>> schlecht. Nein, weil es wohl an einem Bug in DX liegt.
>> Schwer vorzustellen. Es liegt wohl am Render To Textur. Und bei anderen
>> Chips läuft es ja auch. Würde mich also wundern.
>
>Eben, und da liegt wohl das Problem bei DX8.0 - zumindest wenn man
>der Kyro FAQ trauen darf.
>
>http://www.paraknowya.com/specials/faq/index.shtml#sdf
Na ich weiß nicht. Erstmal, ich wüßte nicht warum DX da was in die
Info Strukturen der Treiber schreiben / ändern sollte. Und zum anderen
meine ich daß es in Giants ja auch benutzt wird, aber eben nur langsam
läuft.
>> Spielen auch Probleme. Kryo und ATI haben sich bei Max Payne auch nicht
>> mit Ruhm bekleckert. Woran liegt das!?
>
>Wahrscheinlich weil NVidia und Remedy, bzw. Madonion es wohl ziemlich
>gut miteinander können. Umgekehrt gibt es auch jede Menge Spiele,
>welche auf anderen Karten schneller und/oder optsich reizvoller
>laufen.
Ob das der Grund ist :-) Glaube ich eher weniger, da sie auch mit anderen
Firmen Kontakte haben.
>>> setzt. Hohe Versionsnummer und viele 'geleakte' Betas sprechen eher
>>> dafür, das es auch da reichlich Bedarf für Fixes gibt.
>> Das mit den geleakten Treibern ist aber was anderes. Die sind von
>> NVidia nicht freigegeben und sollten eigentlich nicht ins Netz gelangen
>
>So ist die offizielle Leseart. Wenn NVdidia /wollte/, würde es
>diese massenhafte Verbreitung nicht geben. Oder all die anderen
>Hersteller sind viel Schlauer, was ich nun wriklich nicht glaube.
>Zum einen fixt man auf diese Tour wunderbar die Leute an, zum
>anderen ist das ein gigantischer und vor allem kostenloser Beta-
>test. PR mal anders.
Ich wüßte nicht wie NVidia das verhindern sollte. Die Treiber werden ja wie
gesagt an Spielefirmen und Hardwarehersteller ausgeliefert, damit diese
die Möglichkeit haben, die neuen Treiber mit iherer Software bzw. Hardware
zu testen. Da muß ja nur ein Männiken sitzen, welches diese Treiber dann
ins Netz ballert (obwohl das IMHO verboten ist). Was sollen die denn dagegen
tun!?
>> sondern sind für Hardware Hersteller gedacht. Wenn jemand meint, er
>> müsse alle 5 Sekunden einen neuen Treiber installieren, dann ist das
>> sein Problem.
>
>Sicher aind das diese Knalltüten selbst schuld - und das Result können
>wir hier laufend besichtigen. Danke auch ;). Allerdings wird der deutliche
>Hinweis auf Betastatus regelmäßig 'vergessen' - für mich ein Indiz dafür,
>das geleakt letztlich mit Absicht gleichzusetzen ist. 'Hilfe, ich habe ein
>Problem mit Detonator schlagmichtot' Threads finde ich mittlerweile genauso
>dämlich, wie 'Mein 3dMark ist länger als Deiner'. Alles letztlich Synonyme
>für sich rapide ausbreitende Erweichung der Brainware ;).
Sehe ich genauso. In meiner Zeit als GF1 Besitzer (über 1 1/2 Jahre) habe ich
gerade mal 4 verschiedene Treiber installiert. Wofür auch, läuft ja auch alles.
>
>>> Ich erinnere nur an Diablo II oder an das in Grafikkartenzyklen
>>> gemessen endlose S3TC Drama ;).
>> Was meinst du damit!? Also Diablo2 lief bei mir ohne Probleme. Na ja,
>> einmal durchgespielt und in die Ecke geschmissen. Für Single Player
>> doch eher uninteressant.
>
>Mit den damals beim Release offiziell verfügbaren 'Detonatoren' zickte
>Diablo 2 grausam rum. Abhilfe schafften erst geleakte Betatreiber ...
>Schau mal bei Google oder einem Newsserver mit hoher Haltezeit.
Keine Probleme. Mit den Treibern und der ersten D2 Version. Liegt wohl
aber auch daran, daß ich noch ein gutes altes BX Board habe. Damit
lief bis jetzt alles ohne Probleme.
Gruß
Martin
Martin Horst
Moin,
>Martin Horst schrieb:
in der CT hatten die mal eine Version des Intel C Compilers getestet. Und
in manchen Benchmarks ist der AMD dort voll eingebrochen. Ein Schelm
wer böses denkt :-)
Vielleicht hat Intel das Problem wieder beseitigt.
Martin
Thomas Eßer
> meine ich daß es in Giants ja auch benutzt wird, aber eben nur langsam
> läuft.
Giants wird es emulieren, deshalb der Performanceeinbruch. Auch wird
sich zeigen, inwieweit die Release von DX8.1 und die DX8 Kyro Treiber
etwas ändern werden.
[geleakte Treiber]
> Ich wüßte nicht wie NVidia das verhindern sollte. Die Treiber werden ja
> wie gesagt an Spielefirmen und Hardwarehersteller ausgeliefert, damit
> diese die Möglichkeit haben, die neuen Treiber mit iherer Software bzw.
> Hardware zu testen. Da muß ja nur ein Männiken sitzen, welches diese
> Treiber dann ins Netz ballert (obwohl das IMHO verboten ist). Was
> sollen die denn dagegen tun!?
Unter NDA stehen die Sachen sicher, wenn man wirklich will, wird das
auch eingehalten, weil es ansonsten ganz schön teuer wird. Bei anderen
Herstellern klappt das ausgezeichnet. Der Detonatorwahn zeigt allerdings
deutlich, das diese PR Strategie funktioniert - schonmal aufgefallen,
das /wirklichg/ Verbesserungen sehr überraschend kommen und sich nicht
allmählich durch kleine Verbesserungen ankündigen? Beispiel - Detonator
3 als Reaktion auf ATIs Radeon Release. Ähnliches scheint NVidia mit
Det. 4 und Radeon 2 vorzuhaben.
> Keine Probleme. Mit den Treibern und der ersten D2 Version. Liegt wohl
> aber auch daran, daß ich noch ein gutes altes BX Board habe. Damit
> lief bis jetzt alles ohne Probleme.
Es lag einwandfrei an den damals offiziell verfügbaren Treibern. Hier
hatten viele die geforderten Betas schon installiert, trotzdem gab es
genügend Leute auch hier mit Problemen. Nicht vergessen das sie über-
wiegende Mehrheit einmal die Treiber CD zur Hand nimmt und danach
ziemlich selten etwas ändert.
Gruß,
Thomas
Martin Horst
Hi,
>Martin Horst schrieb:
>
>> meine ich daß es in Giants ja auch benutzt wird, aber eben nur langsam
>> läuft.
>
>Giants wird es emulieren, deshalb der Performanceeinbruch. Auch wird
also das glaube ich eher weniger. Das würde dann grottenlahm werden.
>sich zeigen, inwieweit die Release von DX8.1 und die DX8 Kyro Treiber
>etwas ändern werden.
Benutzt Giants nicht eigentlich DX7!? Oder wurde das bei einem Update
verändert!? Ist schon lange her, wo ich das gezockt habe.
>[geleakte Treiber]
>
>> Ich wüßte nicht wie NVidia das verhindern sollte. Die Treiber werden ja
>> wie gesagt an Spielefirmen und Hardwarehersteller ausgeliefert, damit
>> diese die Möglichkeit haben, die neuen Treiber mit iherer Software bzw.
>> Hardware zu testen. Da muß ja nur ein Männiken sitzen, welches diese
>> Treiber dann ins Netz ballert (obwohl das IMHO verboten ist). Was
>> sollen die denn dagegen tun!?
>
>Unter NDA stehen die Sachen sicher, wenn man wirklich will, wird das
>auch eingehalten, weil es ansonsten ganz schön teuer wird. Bei anderen
>Herstellern klappt das ausgezeichnet. Der Detonatorwahn zeigt allerdings
>deutlich, das diese PR Strategie funktioniert - schonmal aufgefallen,
NDA Funktioniert aber auch nur, solange sich jeder dran hält. Da nimmt
ein Mitarbeiter einen geleakten Treiber mit, gibt den einen Freund und
der ballert das Teil ins Netz. Sowas findet doch keiner mehr heraus.
>das /wirklichg/ Verbesserungen sehr überraschend kommen und sich nicht
>allmählich durch kleine Verbesserungen ankündigen? Beispiel - Detonator
>3 als Reaktion auf ATIs Radeon Release. Ähnliches scheint NVidia mit
>Det. 4 und Radeon 2 vorzuhaben.
Klar, warum sollten die das auch nicht tun. Solange Treiber für meine
Karte rauskommen, habe ich keine Probleme damit :-)
Aber wenn ich an die Treiber meiner damaligen ATI Rage128 denke,
wird mir heute noch schlecht. Mit den NVidia Treibern bin ich absolut
zufrieden.
>> Keine Probleme. Mit den Treibern und der ersten D2 Version. Liegt wohl
>> aber auch daran, daß ich noch ein gutes altes BX Board habe. Damit
>> lief bis jetzt alles ohne Probleme.
>
>Es lag einwandfrei an den damals offiziell verfügbaren Treibern. Hier
>hatten viele die geforderten Betas schon installiert, trotzdem gab es
>genügend Leute auch hier mit Problemen. Nicht vergessen das sie über-
>wiegende Mehrheit einmal die Treiber CD zur Hand nimmt und danach
>ziemlich selten etwas ändert.
Mag sein. Aber es gibt immer Leute die mit irgendwas Probleme haben.
Und NVidia Karten sind eben weit verbreitet. Ich hatte jedenfalls keine
Probleme damit. Leider gibt es im moment keinen guten BX Ersatz.
Bin mal auf die NVidia Chipsätze gespannt was die so bringen (vor allem
an Stabilität). Die VIA Teile haben sich ja leider nicht so mit Ruhm
bekleckert :-)
Gruß
Martin
Sascha Erni, .rb
"Martin Horst" <MHo...@unprotect.de> schrieb ...
> On Sat, 25 Aug 2001 17:55:18 +0200, Thomas Eßer <sa...@gmx.net> wrote:
>
> Hi,
>
> >Martin Horst schrieb:
> >
> >> meine ich daß es in Giants ja auch benutzt wird, aber eben nur
langsam
> >> läuft.
> >
> >Giants wird es emulieren, deshalb der Performanceeinbruch. Auch wird
> also das glaube ich eher weniger. Das würde dann grottenlahm werden.
Das Problem mit Giants (und 3DMark2k1, btw) und Kyro-II ist folgendes:
Unter DX <8.1 wird für TBR (nicht nur Kyro) generell einfach mal der
Hardware-Support für render to texture deaktiviert, was solche Funktionen
auf der Kyro wirklich grottenlangsam (und buggy) macht. Ist ein
offizieller DX bug, und wurde in der 620er Beta von DX/D3D behoben. Jetzt
muss PowerVR noch "echte" DX8 Treiber liefern, dann sollte's das
eigentlich gewesen sein.
ta,
.rb
Thomas Eßer
> offizieller DX bug, und wurde in der 620er Beta von DX/D3D behoben. Jetzt
> muss PowerVR noch "echte" DX8 Treiber liefern, dann sollte's das
> eigentlich gewesen sein.
In geleakter Form gibt es wohl mittlerweile zumindest Betas von Kyro DX8
Treiber - habe ich aber noch nicht ausprobiert, mangels Giants auch nicht
so sonderlich interessant und 3DM werde ich nicht installieren, muß doch
an mein Image denken ;).
Intressanter könnten imo die weiteren Bugfixes in den Treibern sein,
ich bin allerdings sicher, das in Kürze etwas offizielles erscheinen
wird.
Gruß,
Thomas
Thomas Eßer
> NDA Funktioniert aber auch nur, solange sich jeder dran hält. Da nimmt
> ein Mitarbeiter einen geleakten Treiber mit, gibt den einen Freund und
> der ballert das Teil ins Netz. Sowas findet doch keiner mehr heraus.
Nochmal - wenn SIE es wollten, gäbe es dieses Problem nicht. Warum
klappt es denn bei der Konkurenz? Da gibt es Betas mit entsprechenden
Hinweisen offiziell, hat niemand ein Problem mit.
> Klar, warum sollten die das auch nicht tun. Solange Treiber für meine
> Karte rauskommen, habe ich keine Probleme damit :-)
Laut Anand existieren diese Treiber schon länger - nur weil NV Marketing
betreiben wil, sollen wir also auf Leistunng verzichten? Sehe ich nicht
ein ;) - Abgesehen davon - _wo_ bleiben denn davon die geleakten Betas?
[D2]
> Und NVidia Karten sind eben weit verbreitet. Ich hatte jedenfalls keine
Das war ja das peinliche ;). Abgesehen davon dürften absolut gesehen
die NVidia Karten immer noch deutlich in der Minderheit sein. Die paar
tausend Leser des deutschen Usenet zählen in der Masse nicht.
> Bin mal auf die NVidia Chipsätze gespannt was die so bringen (vor allem
> an Stabilität). Die VIA Teile haben sich ja leider nicht so mit Ruhm
> bekleckert :-)
Ich auch, ich bin da allerdings eher pessimistisch. Allerdings ist das
völlig OT.
Gruß,
Thomas
Thomas Eßer
> theoretische Bandbreite des AGP übersteigen würde), und diese Aussage
> lässt sich mit meiner Rechnung problemlos widerlegen. Mehr wollte ich
> nicht.
Und ich wollte nicht mehr, als aufzeigen das die puren Zahlen gar
keine Rolle spielen, weil es so oder so nicht funktioniert in realen
Situationen ;).
> Da liegt der Unterschied zwischen dem, was sich alle von T&L erhofft
> hatten und dem, was tatsächlich umgesetzt wurde. Tatsache ist nun
Erhofft - Wodurch? Um mal wieder die Kurve zum Thema zu kriegen. Der
Hype entsteht doch erst durch vollmundigste Ankündigung der Hersteller
und das völlig vernagelte Verhalten der Medien. Anschließend folgt
natürlich unweigerlich das total vernagelte Verhalten der Käufer,
zumindest wenn 1. und 2. halbwegs funktionieren.
> Hersteller nachgezogen haben und das neue Feature praktisch zur
> Standardausstattung gehört, findet es breite Unterstützung.
Richtig - aber wo sind Jahre später denn die ganzen Spiele? Könnte
das nicht auch daran liegen, das die Hersteller relativ schnell er-
kannt haben, das es neben dem 'nicht lohnen' auch ein 'zu langsam'
und ein 'zu limiert' gibt? Einige wenige Beispiele für das Lightning
gibt es, ein richtiger Knüller war da allerdings nicht bei, trotz
wirklich renommierter Produzenten.
> Man könnte also auch, ohne gleich alles mit T&L erschlagen zu wollen,
> ein paar nette zusätzliche Effekte implementieren, für die man noch
> nicht einmal besonders viele Hardware-Lichtquellen benötigt.
Siehe Max Payne Readme's ;). Obwohl zig tausend Programmiererstunden in
eine nette Demo mit neusten Grafikfeatures investiert wurden, gibt es
im tatsächlichen Spiel nichts davon. Angeblich zu teuer und zu gering
verbreitete Zielhardware - und das trotz fertiger Engine. Oder vielleicht
haben sie auch bemerkt, das zu einem Spiel ein bißchen mehr gehört als
Optik - und das häßlicherweise auch Speicher und CPU Zeit kostet :).
Gruß,
Thomas