was KÖNNTE ati mit dem R400 schaffen...? [Archiv]

nagus

2003-01-11, 21:20:23

Originally posted by duckofdeath
also was könnte da auf uns zukommen?
also 0,13µ sollte ja sogut wie sicher sein oder? aber was schafft ati aus dem core herauszukitzeln? ich würde einmal sagen mehr als nvidia mit 0,13µ schafft(vergleiche r300 und nv25)
also ich würd mal so auf 600-700mhz tippseln auch wenn es hochspekulativ ist da ati's prozess nich sehr ausgereift sein könnte...
aber ich bin schon mal gespannt

IMHO auf jeden fall min. absolut vollständige DX9 unterstürtzung. core takt ist schwer zu sagen ohne die ungefähre anzahl der transistoren zu kennen. 700mhz scheinen mir aber mehr als unwahrscheinlich.

0,15 R200 275Mhz > 0,15 R300 325 Mhz > 0,13 R400 700Mhz ?!?! ...glaub ich kaum.

duckofdeath

2003-01-11, 21:29:34

ok 700 sind a bissi hoch aber 600 könnt ich mir schon vorstellen weil sie gegen den nv35 auch was entgegensetzen müssen! und der hat sicher noch ein bissi mehr mhz als die geforcefx ultra (und blockiert vielleicht 2 pci slots *eg* )

Pirx

2003-01-11, 21:34:41

Hat ATi zur Zeit eigentlich nen Kupfer oder Aluprozeß? Wenn Sie jetzt noch Al haben und auf Cu umstellen könnte doch der Takt noch etwas mehr steigen

Axel

2003-01-11, 21:38:42

In einer alten roadmap stand mal:

R300 -> mind. 300MHz Chiptakt
R400 -> mind. 400MHz Chiptakt

Für mich klingt das realistisch. Das ganze kann natürlich auch überholt sein.

duckofdeath

2003-01-11, 21:42:36

es hat ja angeblich schon der r350 400Mhz (find ich ziemlich sicher)

LovesuckZ

2003-01-11, 21:50:17

Originally posted by duckofdeath
also ich würd mal so auf 600-700mhz tippseln auch wenn es hochspekulativ ist da ati's prozess nich sehr ausgereift sein könnte...
aber ich bin schon mal gespannt

Meine 9500 schafft locker 391MHZ. Da duerfte ATI wohl fuer den r400 deutlich hoeher gehen koennen.

Pussycat

2003-01-11, 22:02:30

Originally posted by LovesuckZ

Meine 9500 schafft locker 391MHZ. Da duerfte ATI wohl fuer den r400 deutlich hoeher gehen koennen.

Übertaktet mit Powerstrip?

LovesuckZ

2003-01-11, 22:22:07

Originally posted by Pussycat

Übertaktet mit Powerstrip?

Powerstrip ging nur bis 367. Radeonator 2.0 geht ueber 400 hinaus. Leider schafft die Karte nur 393:(

nagus

2003-01-12, 00:00:28

Originally posted by LovesuckZ

Powerstrip ging nur bis 367. Radeonator 2.0 geht ueber 400 hinaus. Leider schafft die Karte nur 393:(

"NUR" 393Mhz ?!?!? und das mit einer 9500PRO? wenig ist das aber nicht unbedingt... eher ziehhmlich geil und viel :)

betasilie

2003-01-12, 00:18:55

Originally posted by LovesuckZ

Powerstrip ging nur bis 367. Radeonator 2.0 geht ueber 400 hinaus. Leider schafft die Karte nur 393:(
WaKü?

mapel110

2003-01-12, 01:29:50

es kommt ja auch auf die effiziens des chips an. vielleicht braucht ati nicht mehr so hoch takten.
aber 500 mhz seh ich auch als minimum bei dem chip. is j noch lange hin und bis dahin hat ati auch erfahrung in dem prozess bzw die fertigungsstätten haben das.
dann sollten auch wesentlich höhere taktraten drin sein. es fehlt schliesslich der chip, der die doom3 engine in zukünftigen games entsprechend mit füllrate versorgt. ;)

700 mhz würd ich nicht mal als viel zu hoch ansiedeln !

Ailuros

2003-01-12, 08:19:53

...es kommt ja auch auf die effiziens des chips an. vielleicht braucht ati nicht mehr so hoch takten.

Ein aeusserst weiser Satz :)

Effizienz einer Architektur ist wichtiger als alles andere.

robbitop

2003-01-12, 08:52:58

ich denke da so an 150-160Mio transistoren
16 Tri TMUs
500Mhz Chip und Speicher (GDDR3)
und natürlich PS und VS in Version 3
alles im 0,13µ Kupferprozess
(low k dielectrischer Prozess wäre nett, aber TSMC kommt noch nich klar mit diesem bei so grossen chips)

LovesuckZ

2003-01-12, 09:31:25

Originally posted by nagus
"NUR" 393Mhz ?!?!? und das mit einer 9500PRO? wenig ist das aber nicht unbedingt... eher ziehhmlich geil und viel :)

Nur die einfache 9500.

LovesuckZ

2003-01-12, 09:31:42

Originally posted by betareverse

WaKü?

normaler Luftkuehler der drauf war.

betasilie

2003-01-12, 09:41:57

Originally posted by LovesuckZ

normaler Luftkuehler der drauf war.
Wow :)

LovesuckZ

2003-01-12, 10:20:53

Originally posted by betareverse
Wow :)

Ich weiß:D
Dafuer luept aber der Speicher nicht so toll. Bei 393 Coretakt sind nur 303MHZ Speicher drin. Bei 270Coretakt sinds auch nur 317. Wobei ich sogar 3.3NS Ram drauf hab.

Aber was solls. Ich brauch bei meiner 9500 sowieso mehr Core- statt Speichertakt.

BlueI

2003-01-12, 11:14:00

Is sicherlich auch ne Frage, ob ATi NVidia mit der Kühlung folgt oder ob sie bei ner 'normalen' Kühlung bleiben. NVidia würden ihren FX-Takt mit nem Kühler wie ATi jetzt hat meiner Ansicht nach nicht schaffen. :jump3:

betasilie

2003-01-12, 11:17:00

Originally posted by LovesuckZ
Dafuer luept aber der Speicher nicht so toll. Bei 393 Coretakt sind nur 303MHZ Speicher drin. Bei 270Coretakt sinds auch nur 317. Wobei ich sogar 3.3NS Ram drauf hab.
Ich bin jetzt erst mal bei 345/315 stehen geblieben bei meiner Powercolor 9700 und habe gerade 1 Stündchen UT2003 ohne Probleme gezockt. Falls da nicht viel mehr geht wäre ich auch äußerst Zufrieden.

betasilie

2003-01-12, 11:17:34

Originally posted by betareverse

Ich bin jetzt erst mal bei 345/315 stehen geblieben bei meiner Powercolor 9700 und habe gerade 1 Stündchen UT2003 ohne Probleme gezockt. Falls da nicht viel mehr geht wäre ich auch äußerst Zufrieden.

Edited: Sorry, ist ja OT. :D

Quasar

2003-01-12, 11:19:52

Und bringt's viel?
War bei mir leider nicht der Fall....nur die pure Vertexleistung konnte linear mitskalieren...

robbitop

2003-01-12, 12:09:22

also beim Radeon 9700PRO soll es linear skallieren (Füllrate und Leistung ...ich glaube Anandtec hatte extrem oc geacht und 30% mehr fps rausgeholt in sehr hohen settings @UT2k3)

betasilie

2003-01-12, 12:28:59

Originally posted by Quasar
Und bringt's viel?
War bei mir leider nicht der Fall....nur die pure Vertexleistung konnte linear mitskalieren...
Bei UT-2003 z.B. bringst deutlich was, beim 3d-Murks skaliert es allerdings nicht sehr gut.

Ich muss allerdings sagen, dass meine CPU gerade mit Standarttakt läuft und ein XP-2000+ bremst schon ein bischen. ;)

Unregistered

2003-01-12, 13:46:42

mal eine Spekulation in eine komplett andere Richtung :

>8Pipelines sind bei vielen Polygonen/sec für die Katz.

Ein extrem hoch getaktetes System mit <= 4Pipelines sollte eine wesentlich höhere Effizienz aufweisen.

Also :

R400 @ 2GHz mit < 70 Mio Transistoren

4 Pipelines (AF for free) => 8GPixel/sec

1-2 Vertex-Shader => 500-1000 Mio Polygone/Vertex /sec

etc...

bei nur 70Mio Transitoren könnten 2GHz sogar drin sein. Allerdings wird die Kühlung mindestens so aufwendig wie bei einer CPU.

nagus

2003-01-12, 13:53:54

Originally posted by Unregistered
mal eine Spekulation in eine komplett andere Richtung :

>8Pipelines sind bei vielen Polygonen/sec für die Katz.

Ein extrem hoch getaktetes System mit <= 4Pipelines sollte eine wesentlich höhere Effizienz aufweisen.

Also :

R400 @ 2GHz mit < 70 Mio Transistoren

4 Pipelines (AF for free) => 8GPixel/sec

1-2 Vertex-Shader => 500-1000 Mio Polygone/Vertex /sec

etc...

bei nur 70Mio Transitoren könnten 2GHz sogar drin sein. Allerdings wird die Kühlung mindestens so aufwendig wie bei einer CPU.

wie bist du da drauf gekommen?

2003-01-12, 14:11:55

Originally posted by Unregistered
mal eine Spekulation in eine komplett andere Richtung :

>8Pipelines sind bei vielen Polygonen/sec für die Katz.

Ein extrem hoch getaktetes System mit <= 4Pipelines sollte eine wesentlich höhere Effizienz aufweisen.

??? sagt wer?
wer soll denn die Pixel zeichnen, die die Polygone bilden deiner Meinung nach??

Also :

R400 @ 2GHz mit < 70 Mio Transistoren

4 Pipelines (AF for free) => 8GPixel/sec

1-2 Vertex-Shader => 500-1000 Mio Polygone/Vertex /sec

etc...

bei nur 70Mio Transitoren könnten 2GHz sogar drin sein. Allerdings wird die Kühlung mindestens so aufwendig wie bei einer CPU.

Nö, das ist Unfug. 2GHz sind da nicht drin, vielleicht mal gerade 800MHz. Nicht umsonst wurde die Pipeanzahl immer weiter erhöht.

duckofdeath

2003-01-12, 15:25:25

also ich würd sagen 8x2 oder sogar vielleicht 8x4 (ich liebe es zu übertreiben :D)ist efektiver!

nagus

2003-01-12, 15:38:25

Originally posted by duckofdeath
also ich würd sagen 8x2 oder sogar vielleicht 8x4 (ich liebe es zu übertreiben :D)ist efektiver!

8x4 ist blödsinn, weil ineffizient. 16x1 wäre logisch

duckofdeath

2003-01-12, 15:48:09

ok! ich lasse mit mir reden! Aber 16x1 könnte auch sein weil ich könnte mir immer noch vorstellen, dass der r350 8x2 hat

mapel110

2003-01-12, 16:28:20

also ich denke, dass es erstmal bei 8x1 bleiben wird. das muss schliesslich auch erstmal ausgereizt werden.

:stareup:
hab doch glatt effiziens geschrieben. naja, war schon spät :)

Xmas

2003-01-12, 16:34:10

Originally posted by nagus
8x4 ist blödsinn, weil ineffizient. 16x1 wäre logisch
4*4*1 wäre effizienter. Oder komplett asynchrone Pipes, aber da könnte die Cache-Effizienz drunter leiden.

aths

2003-01-12, 16:44:42

Originally posted by Xmas
4*4*1 wäre effizienter. Oder komplett asynchrone Pipes, aber da könnte die Cache-Effizienz drunter leiden. Wie ist 4x4x1 zu verstehen? Ein Pipeline-"Array"? Oder 4x 4x1, weil einige Dreiecke keine 16 Pixel mehr breit sind?

mapel110

2003-01-12, 16:48:46

Originally posted by aths
Wie ist 4x4x1 zu verstehen? Ein Pipeline-"Array"?

ist die parhelia nicht so aufgebaut ???

aths

2003-01-12, 16:50:05

Originally posted by mapel110
ist die parhelia nicht so aufgebaut ??? Parhelia hat eine 4x4-Architektur.

Demirug

2003-01-12, 17:00:29

Originally posted by aths
Wie ist 4x4x1 zu verstehen? Ein Pipeline-"Array"? Oder 4x 4x1, weil einige Dreiecke keine 16 Pixel mehr breit sind?

was hat die Breite eines Dreiecks damit zu tun?

IMO kann es langfristig sowieso nur eine Lösung geben die dem Hyperthreading von Intel nicht unähnlich ist. Dabei würde ich sogar so weit gehen und die Trennung zwischen der Vertex und der Pixel Pipeline komplett aufheben.

duckofdeath

2003-01-12, 19:15:15

gibts es schon bei irgendwelchen firmen patente für technologien wie diese "arrays"??? weil eigentlich ist das ja eine gute idee! könnte ein gegenstück zur speicherbandbreitenschonung sein (--> füllratenschonung....)

Demirug

2003-01-12, 19:42:28

Mit Patenten ist das immer so eine Sache. Das Patentamt braucht in der Regel immer mehr als 2 Jahre bis die Patente bearbeitet und veröffentlicht werden. Aus diesem Grund kann man also nicht sagen ob schon jemand ein Patent darauf beantragt hat.

NVIDIA setzt aber beim FX wohl zumindestens schon im Vertexshader Bereich auf eine solche Technik.

duckofdeath

2003-01-12, 20:17:16

aber ob die nvidia lösung wirklich effektiv ist steht in den sternen...

Ailuros

2003-01-12, 20:28:42

Mit dem ganzem Shader Wirrwarr und der dazu gehoerigen Arithmetic, kann es sein dass sich IHV's von vortan mehr auf Effizienz (computational efficiency) als auf andere Faktoren konzentrieren wie z.B. Bandbreite, aber die braucht man dann auch wieder fuer Anisotropic filtering...

duckofthedeath,

http://www.metagence.com/Technology.asp

Xmas

2003-01-12, 20:56:24

Originally posted by Demirug
was hat die Breite eines Dreiecks damit zu tun?

IMO kann es langfristig sowieso nur eine Lösung geben die dem Hyperthreading von Intel nicht unähnlich ist. Dabei würde ich sogar so weit gehen und die Trennung zwischen der Vertex und der Pixel Pipeline komplett aufheben.
Ja, das wird wohl so kommen, obwohl es auch Vorteile hat, Pipes synchron zu betreiben.

Mit 4x4x1 meinte ich 4 "Blöcke" zu je 4 Pipelines, die am gleichen, aber auch an verschiedenen Dreiecken arbeiten können.

Demirug

2003-01-12, 21:04:18

Originally posted by Xmas

Ja, das wird wohl so kommen, obwohl es auch Vorteile hat, Pipes synchron zu betreiben.

Mit 4x4x1 meinte ich 4 "Blöcke" zu je 4 Pipelines, die am gleichen, aber auch an verschiedenen Dreiecken arbeiten können.

ja nur der vorteil der synchronität wird schwindet immer stärker. Spätestens wenn dynamisches Branching in dem Pixelshadern benutzt werden kann ist es sowieso vorbei mit der synchronität.

Ja das mit den verschiedenen Dreiecken mancht durchaus sinn. Aber mit einem ShaderArray könnte man dieses Problem auch lösen.

Spaßvogel

2003-01-12, 21:22:38

Originally posted by duckofdeath
aber ob die nvidia lösung wirklich effektiv ist steht in den sternen...

Guter Satz! Hinzufügen möchte ich:

Die MHz-Zahl der FX wie die zukünftiger Chips(R400/NV35) ist ziemlich zweitrangig. Wichtiger ist die effiziente konzeptionelle Umsetzung von Vertex-/Pixelshader Einheiten/Funktionen und deren möglichst effiziente Nutzung durch den Treiber. Und das natürlich nicht nur in Hinblick auf Benchmarks!

Sicher ist, daß 16 Piplines mehr Pixel auf den Schirm schleudern können als dies mit 8 Pipelines möglich wäre, kein Bandbreitenproblem vorausgesetzt. Letztlich haben wir damit die doppelte Anzahl von Pixel-Shader Einheiten oder einfach mehr Parallelverarbeitung.

Stichwort Parallelverarbeitung:
Bei den mehr oder weniger komplexen Shaderprogrammen in 2003/2004 wird Parallelverarbeitung und effizientere Implementierung der Shader-Einheiten die gebenchten Frames per second maßgeblich bestimmen. DX8 Shader schnell verarbeiten zu können, darauf zu optimieren, wäre sinnig für aktuelle Neuerscheinungen.

DX8-Shader auf dem R300/R350 im Vergleich mit DX8-Shadern auf der GFFX. Wird bestimmt interessant zu sehen, wer's besser gemacht hat :)

Konzentriert euch also nicht so sehr auf die MHz-Zahlen, sondern mehr auf das bessere Design für die nächsten zwei Jahre. Danach werden die Würfel neu gemischt.

Für mich persönlich zählt allerdings nur die beste Darstellungsqualität bei ca. 40-50 Frame/s.

Grüsseli,
Spaßvogel

duckofdeath

2003-01-12, 21:34:56

bin auch gespannt wie die shaderleistungen von r350 und nv30 werden

weil der r350 könnte zum r300 schon ein update auf nv30 niveau erhalten

Crazytype

2003-01-12, 22:06:41

stimmt die nv30 sollte auch erst mit low-k kommen aber TSMC hatte probleme dabei, vielleicht nehmen die ja SOI? ;)
Er verglich vielleicht r300 mit n25 ,weil beide in 150 nanometer gefertigt sind aber ATI trotz hoher transistorenzahl einen hohen takt ermöglichen konnte,quasi effezienter.

zeckensack

2003-01-12, 22:15:41

Originally posted by Demirug
ja nur der vorteil der synchronität wird schwindet immer stärker. Spätestens wenn dynamisches Branching in dem Pixelshadern benutzt werden kann ist es sowieso vorbei mit der synchronität.

Ja das mit den verschiedenen Dreiecken mancht durchaus sinn. Aber mit einem ShaderArray könnte man dieses Problem auch lösen. Eine ganz gute Übergangslösung wären Prädikate ala Itanium. Sowas soll der NV30 ja schon können.

Aber auf lange Sicht hast du Recht, da muß man sich was neues einfallen lassen.

Mal 'ne ganz blöde Frage, siehst du überhaupt Anwendungsfälle für Pixel Shader mit tausenden von Instruktionen???

edit: Bei Echtzeit-Anwendungen ;)

Demirug

2003-01-12, 22:35:47

Originally posted by zeckensack
Eine ganz gute Übergangslösung wären Prädikate ala Itanium. Sowas soll der NV30 ja schon können.

Aber auf lange Sicht hast du Recht, da muß man sich was neues einfallen lassen.

Mal 'ne ganz blöde Frage, siehst du überhaupt Anwendungsfälle für Pixel Shader mit tausenden von Instruktionen???

edit: Bei Echtzeit-Anwendungen ;)

Ja der NV 30 kann Prädikate im PixelShader. Leider steht dafür aber nur ein Bit zu verfügung. Besser als nichts ist es aber schon.

Tausende kann der NV30 ja nicht sondern nur knapp üner eintausend. Aber die Frage nach dem Sinn ist natürlich berechtigt wenn man bedenkt das DOOM III gerade mal Shader mit um die 20 Instructionen einsetzt und damit wohl auch mit einer NV30 Karte keine Wunder im Bezug auf die FPS zu erwarten sind. Ich kann mir durchaus vorstellen das in Zukunft Shader mit ein paar hundert Instruktionen auch im Online Rendering Sinnvoll eingesetzt werden können allerdings müsste man dafür noch etwas im Bereich der Programmierbarkeit verbessern. Die Hochsprachen sind zwar ein schritt in die richtige Richtung aber mir geht das noch nicht weit genug. Aber das Thema hatte wir ja schonmal.

zeckensack

2003-01-12, 22:43:28

Daß das auf 'nem NV30 fürchterlich lahm wird, das hatte ich eigentlich vorausgesetzt. Es geht ja hier mittlerweile um die fernere Zukunft :)

Ausreichende Geschwindigkeit vorausgesetzt, kann man so viel Flexibilität überhaupt noch einsetzen, oder sind Shader irgendwann ab 200~300 Instruktion 'lang genug für alles'? Darüber habe ich gerade nachgegrübelt :|

Demirug

2003-01-12, 23:12:47

Originally posted by zeckensack
Daß das auf 'nem NV30 fürchterlich lahm wird, das hatte ich eigentlich vorausgesetzt. Es geht ja hier mittlerweile um die fernere Zukunft :)

Ausreichende Geschwindigkeit vorausgesetzt, kann man so viel Flexibilität überhaupt noch einsetzen, oder sind Shader irgendwann ab 200~300 Instruktion 'lang genug für alles'? Darüber habe ich gerade nachgegrübelt :|

Wenn man von einem "all in one Pass" Verfahren ausgeht kann man schon sehr lange Shader benötigen. Genügend Lichtquellen vorrausgesetzt natürlich. Das Problem dabei ist wie gesagt nur das ein solches Shadersystem mit heutigen mitteln zwar für eine Demo programmierbar ist aber für ein komplettes Spiel ist so etwas derzeit fast unmöglich. Man müsste die Shader sozusagen in Echtzeit erzeugen in abhängigkeit der Lichtquellen und Lichtfilter. Und das können HLSL, CG oder OpenGL 2.0 nicht leisten.

Unregistered

2003-01-13, 09:28:45

Originally posted by Crazytype
stimmt die nv30 sollte auch erst mit low-k kommen aber TSMC hatte probleme dabei, vielleicht nehmen die ja SOI? ;)
Er verglich vielleicht r300 mit n25 ,weil beide in 150 nanometer gefertigt sind aber ATI trotz hoher transistorenzahl einen hohen takt ermöglichen konnte,quasi effezienter.

Also meines Wissens nach taktet der nv25 höher als der R8500, beide in 0.15. Also ist NV effizienter.

JTHawK

2003-01-13, 10:24:23

huiui werdet mal net OT jungs :d es is das hier ne nv-effitienz-besprechung geworden und keine was könnte der r400 ..

also ich gehe klar davon aus das:

der r400 nvidias zu der zeit schnelslte gpu in die schranken weißen wird (dazu gibt es keinen zweifel wenn man sich nv's roadmap anschaut)

da nv bis zu der zeit weiterhin mit 500 mhz arbeitet wird ati definitiv drüber liegen .. und hat mir gddr3 ja auch noch mehr reserven als nvidia mit ddr2 ... wie schon einige gesagt haben gehe ich hier auch von 600 bis 700 mhz aus .. eventuell is noch mehr drin .. das wird dann aber ein relaunch werden .. r450 oder so - falls nvidia kontert :D

man sollte sein hauptaugenmerk net nur auf pixel und vertex shaderoperformance bzw effizienz auslegen .. man benötigt auch genug rohpower für die aktuellen games und anwendungen die mit pixel- und vertexshadern garnix am hut haben ... wir wollen ja kein desaster ala p4-fpu haben (die fpu meines xp 1466mhz ist fast doppelt so schnell wie die eines p4 2,4 ghz - zumindest bei distrinet :D )

das der r400 directx 10 kann - davon halte ich garnix .. dx10 wird frühestens 2005 kommen .. aber dann gibts ja schon den r500 :D also dx9+

wenn man genau hinschaut bertrumpfen sich nv und ati immer in einigen abständen mit mehr features .. nich das die irgendwann an featuritis leiden und nix richtig können .. das führt dann dazu das der zeitraum zum nächsten productlaunch länger wird .. (das würde ich begrüßen - meien r8500 wird nach einem jahr immer noch net voll ausgenutzt - featureseitig .. stattdessen wirud auf immer mehr rohpower gesetzt - obwohl man alles effizienter und besser machen könnte - aber dazu sind die programmieren ja zu faul ... wenn man bedenkt das doom3 noch dx7 ist :D ) wers setzt schon gerne neue features ein die erstmal monatelang erbrobt werden müssen wenn das alte doch so gut läuft . nur halt mehr power benötigt ...

also wenn dx10 kommt .. wird dx8 state of the art sein .. mit einigen dx9 features .. reine dx9 spiele .. ohje .. das wird dauern .. von dx10 ganz zu schweigen (siehe wierder mal doom3)

Pitchfork

2003-01-13, 10:35:47

Originally posted by Demirug
Man müsste die Shader sozusagen in Echtzeit erzeugen in abhängigkeit der Lichtquellen und Lichtfilter. Und das können HLSL, CG oder OpenGL 2.0 nicht leisten.

Wo siehst du das Problem mit dem Echtzeiterzeugen von Shadern? Gerade mit HLSL und Co. sollte das doch kein großes Problem mehr sein: für jeden Shadingblock ne Funktion geschrieben (Material, Schatten, Lichtquellen, Nebel,...) und die von einer Mainfunktion zusammengesetzt, und einzig diese Mainfunktion wird dynamisch erzeugt. Oder noch weiter gehend: es gibt eine Megamainfunktion wo alles aufgerufen wird, aber Konstanten schalten die einzelnen Blöcke ein- und aus.
DX9 kann auch Fragment Linking, was die Sache noch effizienter machen soll, aber leider bei Pixel Shadern nicht mehr so viel bringt, weil die Regeln für die Befehlsanordnung aufwendiger sind als bei Vertexshadern.
Aber mit nem guten Shadercache kann man damit gut auskommen.

Das Hauptproblem wird weniger die Shaderverwaltung in Zukunft als einfach die Anzahl der Pixelshader Ops pro sichtbarem Pixel (also inkl. ausgeführtem Overdraw). Und hier sehe ich Probleme bei DX9 Mainstreamhardware.

Demirug

2003-01-13, 10:40:31

"man sollte sein hauptaugenmerk net nur auf pixel und vertex shaderoperformance bzw effizienz auslegen .. man benötigt auch genug rohpower für die aktuellen games und anwendungen die mit pixel- und vertexshadern garnix am hut haben ..."

Das ist schon richtig das die pixel und vertex shaderoperformance (effizienz) optimiert wird. Denn sowohl NVIDIA wie auch ATI benutzten zum auführen von DX7 Funktionalitäten die Shader. Also wenn die Shadereinheiten schneller werden profitieren davon auch Spiele die gar keine Shader benutzten.

Demirug

2003-01-13, 10:57:19

Originally posted by Pitchfork

Wo siehst du das Problem mit dem Echtzeiterzeugen von Shadern? Gerade mit HLSL und Co. sollte das doch kein großes Problem mehr sein: für jeden Shadingblock ne Funktion geschrieben (Material, Schatten, Lichtquellen, Nebel,...) und die von einer Mainfunktion zusammengesetzt, und einzig diese Mainfunktion wird dynamisch erzeugt. Oder noch weiter gehend: es gibt eine Megamainfunktion wo alles aufgerufen wird, aber Konstanten schalten die einzelnen Blöcke ein- und aus.
DX9 kann auch Fragment Linking, was die Sache noch effizienter machen soll, aber leider bei Pixel Shadern nicht mehr so viel bringt, weil die Regeln für die Befehlsanordnung aufwendiger sind als bei Vertexshadern.
Aber mit nem guten Shadercache kann man damit gut auskommen.

Das Hauptproblem wird weniger die Shaderverwaltung in Zukunft als einfach die Anzahl der Pixelshader Ops pro sichtbarem Pixel (also inkl. ausgeführtem Overdraw). Und hier sehe ich Probleme bei DX9 Mainstreamhardware.

Mit Echtzeit erzeugung meine ich wirklich Just in Time. Soll heissen das sobald eine neue Konstelation von Lichtquellen/Lichtfilter auf ein Object einwirkt automatisch ein entsprechende Shader erzeugt wird. Das mit dem Fragment Linking geht dabei schon in die richtige Richtung ich sehe nur nach wie vor darin ein Problem das man Vertex und Pixelshader getrennt betrachtet. Mir persönlich wäre es lieber wenn man Shader nicht aufgrund der lokalität (Vertex, Pixel) programmiert sondern aufgrund der Funktinalität (in der Art von Renderman eben). Dann einfach der Runtime sagen welche Geometrieverformung, Oberflächen und Lichtquellen zum Einsatz kommen. Für diese die Parameter angeben und der rest geht automatisch.

- Zusammenfügen der Teilkomponeten
- Aufbauen und Optimieren des Renderbaums
- Aufteilen des Renderbaums auf CPU, VS, PS und event. Framebufferoperationen (AlphaTest, StencilTest, Alphablending)
- Festlegen der übergabeschnittstellen zwischen den einzelnen Einheiten
- Im Zweifelsfall sogar automatisches Multipass splitten

Ich weiss das so etwas schon in die richtung heiliger Krahl des Online rendering geht aber so stelle ich mir nun mal ein gutes Shadersystem vor.

Unregistered

2003-01-13, 13:42:41

Originally posted by Xmas

4*4*1 wäre effizienter. Oder komplett asynchrone Pipes, aber da könnte die Cache-Effizienz drunter leiden.

das wäre natürlich eine gute Alternative. Wenn der Chip an 4Polygonen
gleichzeitig arbeitet, und für jedes Polygon eine 4x1 Pipeline zur Verfügung stellt. Aber wie willst Du die Probleme mit dem Overdraw lösen, wenn du an 4 Polygonen / Polygon-Strips or Fans gleichzeitig arbeitest? Die Early-Z Unit wird dann bestimmt sehr aufwendig. Vielleicht hilft hier etwas Pixelflow-Knowhow weiter?

Das ganze würde aber eine nette Möglichkeit bieten, Highend und Lowend - Chips schnell und effizient zu entwickeln. Der Highend - Chip hat 4 Einheiten mit aufwendigem Early-Z, und der Lowend-Chip nur 1 Einheit mit einfachem Early-Z.

Pitchfork

2003-01-13, 13:42:43

So funktioniert ja auch ein gutes DX9 Rendersystem *g*
Bloß ist es nicht die allgemeine Shadersprache, sondern halt das Rendersystem der Engine. Da werden dann nur noch Parameter eingestellt und die entsprechenden Shader zusammengestellt. Die Engine ist dabei so frei einige Einschränkungen aufzustellen und auszunutzen, und die ganze Sache passiert eher auf "semantischer" Ebene:

Material:
- Anisotropisch Bumpmapped

Beleuchtung:
- Skylight
- 2 Punktlichtquellen samt ihrer Shadowmaps

Globale Effekte:
- Globaler Fog
- Volumetrischer Fog
- Caustics

Und aus diesen Daten baut die Engine die Shader zusammen. Und auf dieser Ebene kann man auch wunderbar platformübergreifend agieren, da die Engine dann weiß, daß Anisotropisch Bumpmapped auf der PS2 nicht geht und stattdessen eine anisotropische Beleuchtung auf Vertexebene aktiviert.

Das ganze funktioniert schon heute so und wird in Zukunft für lange Zeit weiterhin so laufen. Es geht ja nicht nur um die Shader, sondern um die vielen Quellen für Shaderparameter, sei es Material (relativ einfach), Beleuchtung, Nebel,... die einfach von vielen verschiedenen Subsystemen der Engine kommen und alle mit dem Shader harmonieren müssen.

Xmas

2003-01-13, 14:15:49

Originally posted by Unregistered
das wäre natürlich eine gute Alternative. Wenn der Chip an 4Polygonen
gleichzeitig arbeitet, und für jedes Polygon eine 4x1 Pipeline zur Verfügung stellt. Aber wie willst Du die Probleme mit dem Overdraw lösen, wenn du an 4 Polygonen / Polygon-Strips or Fans gleichzeitig arbeitest? Die Early-Z Unit wird dann bestimmt sehr aufwendig. Vielleicht hilft hier etwas Pixelflow-Knowhow weiter?

Das ganze würde aber eine nette Möglichkeit bieten, Highend und Lowend - Chips schnell und effizient zu entwickeln. Der Highend - Chip hat 4 Einheiten mit aufwendigem Early-Z, und der Lowend-Chip nur 1 Einheit mit einfachem Early-Z.
Es müssten auch nicht zwangsläufig 4 Polygone gleichzeitig sein, 2 wären schon recht gut, eben so dass die Trennung in 4er-Schritten erfolgen kann. Dafür zu sorgen dass sich die Pipes nicht ins Gehege kommen wäre recht einfach. Schließlich müssen ja die Pixelkoordinaten für die Pipes bekannt sein, und wenn zwei Pipe-Blöcke die gleichen Pixel bearbeiten, wird der der das "spätere" Polygon bearbeitet kurzzeitig geblockt.

Demirug

2003-01-13, 14:17:59

Pitchfork, in der Theorie gebe ich dir dabei ja auch vollkommen recht. Nur ist es derzeit etwas problematisch diese ganzen Shader zur Laufzeit aus Hochsprachen fragmente zu erzeugen. Gerade die übergänge zwischen den einzelnen Einheiten CPU, VS, PS sind dabei etwas schwer zu handhaben. Derzeit befindet man sich mehr oder minder ja gerade auf dem Übergang von Hardcoded Effekten zu einem Effektframework. NVIDIA hat zwar mal durchblicken lassen das sie für Cg eine modulare Funktionsorientierte Runtime planen aber das dauert wohl noch etwas.

Man könnte natürlich wie du gesagt hast alle Effekte in einem grossen Vertex und Pixelshader hinterlegen und dann mit vielen verzweigungen und schleifen arbeiten. Nur bin ich mir da nicht so ganz sicher wie man dabei die verwendung der interpolants im Trisetup noch vernüpftig in den Griff bekommen soll. Zudem dürfte selbst bei den VS und PS 3.0 die Programmlänge etwas zu kurz sein um alles reingepackt zu bekommen und auch die Flexibilität müsste man noch etwas verbessern.

Ich vermute mal das wir bisher etwas aneinader vorbei geredet haben. Was ich meinte ist wohl besser als dynamischen erzeugen von Effekten aus Effekt fragmenten zu bezeichnen.

Soll heisen das man zum Beispiel 10 Lichtquellen Fragmente sowie 10 Oberflächen Fragmente hat und man daraus nur noch die aktiven auswählt und parametriert. Und so etwas kann derzeit AFAIK wohl noch kein Effektframework.

Pitchfork

2003-01-13, 15:50:14

Nein, das kann kein Framework. Wie gesagt, Aufgabe der Engine.
Allerdings dürfte es auch im allgemeinen Fall so gut wie unmöglich sein, die Fragmente allein mathematisch korrekt zu verknüpfen. Da sind solche Details wie zur Laufzeit korrekt zugewiesene Interpolatoren harmlos gegen.
Aber du hast recht, vor allen Dingen die korrekte (genauer gesagt: konsistente) Nutzung der Interpolatoren macht etwas Sorgen. Ich überlege gerade, ob da nicht die neuen Semantikdefs aushelfen können. Beim Übergang von der Engine zu den Vertexshadern erfüllen die ja bereits gute Dienste.
Es bleibt jedoch Aufgabe der Engine aus den vielen Fragmenten ein großes ganzes zu bauen, mit dem nötigen Wissen über die Konditionen. Generische Lösungen werden wohl noch 1-2 Jahre brauchen, ist ja weniger eine Frage der Hardware als eine der Optimizer, fällt ja alles mehr oder weniger unter Elimination von Loopinvariants, d.h. ein Shader wird für ein Fragment geschrieben und der Compiler zieht automatisch Infos raus, die entweder nur pro Vertex berechnet werden müssen und solche, die nur pro Mesh berechnet werden müssen. Aber ich frage mich schon, ob das dann wirklich so der Fortschritt ist oder ob das bisherige reicht.

duckofdeath

2003-01-13, 18:30:04

hören sich gut an eure ideen

Demirug

2003-01-13, 19:24:39

Pitchfork,

ich würde das ganze schon als grossen Fortschritt sehen. Weniger für die Programmier die das ganze ja entwickeln müssen sondern vor allem um die Designer. Wenn diese sich bei Schreiben von Effekten keine Gedanken mehr machen müssen welche Lichtquelle bei welchen Oberflächen zum Einsatz kommen könnten sie viel schneller arbeiten.

Die Semantikdefs sind schon eine schöne sache aber in meiner Idealvorstellung überflüssig. Da diese Dinge alle automatisch passieren sollen.

Als Beispiel:

public class Mat1 : Material
{
public override ColorRGBA GetColor ()
{
ColorRGBA Result = new ColorRGBA();

foreach (Light light in Lights)
Result += light.GetDiffuse () * Vector3.Dot (light.GetLightVector(), Normal);

return CurrentColor + Result * Color * MatTextur[Texcoordidate];
}

public Primitive.ColorRGBA Color;
public Vertex.Vector2 Texcoordidate;
public Fragment.RGBATexture MatTextur;
}

public class GlobalAmbientLight : Light
{
public Light1 ()
{
DeactivateCurrentColor ();
}

public override ColorRGBA GetDiffuse ()
{
return AmbientColor;
}
}

public class DirectLight : Light
{
public DirectLight ()
{
if (FrameBuffer.Stencil != 0)
FrameBuffer.ColorOutput = false;
}

public override ColorRGBA GetDiffuse ()
{
return Diffuse;
}

public override Vector3 GetLightVector ()
{
return -Lightdir;
}

public Shader.ColorRGBA Diffuse;
public Shader.Vector3 Lightdir;
}

public class PointLight : Light
{
public PointLight ()
{
if (FrameBuffer.Stencil != 0)
FrameBuffer.ColorOutput = false;
}

public override ColorRGBA GetDiffuse ()
{
float Length = (LightPos - new Vector3(Pos)).Length;

float Attenuation = 1 / (A0 + A1 * Length + A2 * Length * Length);

return Diffuse * Attenuation;
}

public override Vector3 GetLightVector ()
{
Vector3 LightVector = LightPos - new Vector3(Pos);
LightVector.Normalize ();

return LightVector;
}

public Shader.ColorRGBA Diffuse;
public Shader.Vector3 LightPos;
public Shader.Float A0;
public Shader.Float A1;
public Shader.Float A2;
}

public class Geo1 : Geometrie
{
public override void CalculatePos ()
{
Pos = ObjPos * World;

Matrix NormalWorld = World;
NormalWorld.Invert ();
NormalWorld.Transpose ();

Normal = ObjNormal * NormalWorld;
Normal.Normalize ();
}

public Vertex.Vector4 ObjPos;
public Vertex.Vector3 ObjNormal;
public Primitive.Matrix World;
}

Pitchfork

2003-01-13, 19:52:42

Schon klar, wie du das meinst. Aber im Ernst, welcher Designer hat denn Lust und Können sich mit nem kompletten Shader rumzuschlagen? Der will sich MAXIMAL mit dem Material an sich rumschlagen und das ist nur ein Bruchteil des kompletten Shaders. Schau doch mal auf so was wie gute Outdoorbeleuchtung, Hemisphere Lighting, Distributed Area Lighting und wie das alles heißt. Das ist alles völlig unabhängig vom Material und trotzdem Teil des Shaders. Es muß also ein gemeinsames Bindeglied zwischen dem Material und den anderen Shaderparts geschaffen werden. Das könnte man in einer Shaderhochsprache evtl. schaffen, aber sicher bin ich mir da nicht.
Es dürfte eher den gleichen Weg gehen wie beim Offlinerendering: es gibt den Job des Shaderprogrammierers, der sich nur darum kümmert, gute Shader zu erzeugen. Der hat den Überblick über alles, ist ein Mittelding zwischen Coder und Artist und stellt den Grafikern eine Liste mit Materialien zur Verfügung, die die nur noch parametrisieren. Und wenn man so nen Freggl hat, dann sind einige Details nicht mehr soo wichtig.

Demirug

2003-01-13, 20:04:47

Pitchfork, wer die Shader am ende schreibt ist ja egal. Ich will nur mehr flexibilität bei der Entwicklung der Shader. Also das man sich bei schreiben der Schaderanteile fürs Licht keine Gedanken um das Material mit dem das Licht benutzt wird machen muss und umgekehrt. In dem Moment kann man sich recht einfach eine Sammlung von Effekten aufbauen die sich gut wiederverwenden lassen. Im Moment geht das halt leider nur wenn man den genau gleichen Effekt (Material, Licht, usw) wieder braucht. Ansonsten muss wieder der Shaderprogrammierer ran.

Aber wie gesagt man muss abwarten wie sich die Sache weiterentwickelt. Die Spieleentwicklung hat ja auch schon einen langen weg hinter sich (Assembler, Hochsprachen , OOP).

-error-

2003-01-14, 14:17:28

duckofdeath

2003-01-14, 14:37:08

der direkte gegner des r400 ist aber eigentlich nicht die geforcefx sondern ihr nachfolger nv35 (der aber durch die selben verspätungen sehr viel zu spät kommen wird [IMHO]!!)

2003-01-14, 17:28:36

Originally posted by duckofdeath
der direkte gegner des r400 ist aber eigentlich nicht die geforcefx sondern ihr nachfolger nv35 (der aber durch die selben verspätungen sehr viel zu spät kommen wird [IMHO]!!)

wieso sollte den NV35 zu spät sein?

AFAIK gibt es auch noch gar keine genauen geplanten Launch-Termine. Genausowenig für den R400.

duckofdeath

2003-01-14, 18:42:28

weil dann der "normale" nv30 viel zu kurz am markt wäre!!!

2003-01-14, 20:36:05

Originally posted by duckofdeath
weil dann der "normale" nv30 viel zu kurz am markt wäre!!!

???
wer/was/wie/wo sagt denn, wie lange ein Chip am Markt sein muss?

Axel

2003-01-14, 20:39:13

Originally posted by duckofdeath
weil dann der "normale" nv30 viel zu kurz am markt wäre!!!

Eigentlich nicht. Der FX erscheint pünktlich 6 Monate später und wird 6 Monate auf dem Markt sein, ehe im 2.HJ der NV35 erscheint. Also genau die 6 Monate die NV immer vorgesehen hatte. Ich glaube auch nicht, daß sie wieder solche Schwierigkeiten haben werden, da sowohl Design und Prod.-prozess dann auf vorhandenem aufbauen.

duckofdeath

2003-01-14, 20:46:43

meines ist auch zu 50% wunschdenken

Crazytype

2003-01-25, 23:26:14

mann solte eher die radeon 8500 mit der gf3 500 vergleichen, eine gf 4 kam viel später. Und die r300 wird auch in 150 nanometer gefertigt trotz mehr transistoren einen netten takt. Die r400 soll dochschon in Sommer erscheinen oder früherbst.

Edit: Mann kann schon sagen das die nv35 konkurenz jetzt der r400 ist da sich die Geforce ja um 6 Monate verspätet hat.

Ailuros

2003-01-26, 02:10:12

Originally posted by duckofdeath
weil dann der "normale" nv30 viel zu kurz am markt wäre!!!

Obwohl es Sinn macht zu spekulieren dass aeltere roadmaps sich zurueckgesetzt haben seit letztem Jahr mit der NV30 Verspaetung, bezweifle ich dass NVIDIA als es klar wurde dass NV30 doch nicht so frueh wie erwartet auf den Markt sein wird, fuer frueher als Ende Sommer 2003 fuer NV35 geplant hat.

Ich schaetze dass das ganze schon Sommer 2002 ziemlich klar fuer die war.

nagus

2003-01-26, 11:17:42

0,13µm
16x1 TMUs
550Mhz Core
550 MHz DDRII 256bit bus
PS3.0 und VS3.0

+ HYperZ 4 etc...

robbitop

2003-01-26, 11:41:33

naklar 16x1 TMU bei VS/PS 3.0
das wären mehr als 200Mio Transistoren.
selbst @0,13µ mit Kupferverbindungen wird das nicht wirklich in Serienproduktion zu vernünftigen Taktraten machbar sein.
Denn jede Pipe braucht eine Tri TMU und eine Ps3.0 fähige ALU.
Ich glaube mit 8 Pipe und je einer PS 3.0 ALU wirds schon verdammt viel für hohe Taktraten. Denn die PS 3.0 ALUs sind recht komplex.

aber da wir im SpekuForum sind isses ok

Wie Demirug schonmal sagte, wäre ein vernpnftiger PS ALU Array wesendlich günstiger, weil man dann die TMU Anzahl recht transistor günstig nach oben schieben könnte und die ALUs nicht unterversorgt werden...

nagus

2003-01-26, 12:27:38

jedenfalls wird die R400 sicher ziehmlich geil. ati hat gesagt, dass sie wieder alle "rules" brechen werden... wie damals mit der r300.

wenn zwischen r300 und r400 wieder so viel unterschied wie zwichen r200 und r300 ist, dann.... ;D ;D ;D

LovesuckZ

2003-01-26, 12:31:32

Originally posted by nagus
wenn zwischen r300 und r400 wieder so viel unterschied wie zwichen r200 und r300 ist, dann.... ;D ;D ;D

Welches Team werkelt am r400?

Ailuros

2003-01-26, 12:36:35

16 pipes? Uhmmmm........

Lovesuck,

Die gleichen beiden teams die schon auf R300 arbeiteten. East und West, wobei eins der beiden das alte ArtX team ist.

OT: Da Thilo's FX Benchmarks schnell die Runde uebers Netz machten, hab ich irgendwie das dumme Gefuehl dass Dein Avatar fuer mehr Aufmerksamkeit gesorgt hat als die FX Zahlen *grins*.

duckofdeath

2003-01-27, 00:19:29

naklar 16x1 TMU bei VS/PS 3.0
das wären mehr als 200Mio Transistoren.
selbst @0,13µ mit Kupferverbindungen wird das nicht wirklich in Serienproduktion zu vernünftigen Taktraten machbar sein.
Denn jede Pipe braucht eine Tri TMU und eine Ps3.0 fähige ALU.
Ich glaube mit 8 Pipe und je einer PS 3.0 ALU wirds schon verdammt viel für hohe Taktraten. Denn die PS 3.0 ALUs sind recht komplex.

wieso sollte das nicht bei annehmbaren taktraten hinhauen?? wenn ati mit dem r350 400-425mhz anstrebt und ich den chip auf 120-125m transistoren schätze und das in 0,15µ sollten 200m+ schon drinnen sein!
und bei 16 pipes sollten eigentlich auch 400mhz reichen!

Salvee

2003-01-27, 01:08:02

Originally posted by LovesuckZ

Welches Team werkelt am r400?

Das Team, das den R200 designed hat (also nicht das Team um ArtX).

[ncp]EasyChiller

2003-01-27, 02:53:01

soooo abwegig wären 16 pipes garnicht - wenn sie den R400 danne schon in 0,09 fertigen heisst das doch nahezu sie halbe chipfläche wie bei 0.13 ... also sollten damit zumindest an die 200Mio. Transistoren möglich sein ;D

duckofdeath

2003-01-27, 19:58:23

wieso sollten die den r400 in 0,09µ fertigen wenn die nicht mal einen highend 0,13µ und geschweige einen genug hochentwickelten(haben ja derzeit nur mal tools für die zukunft erworben --> r500!!!) 0,09µ prozess haben! 200m sind sicher in 0,13µ möglich!

LovesuckZ

2003-01-27, 20:17:34

Originally posted by Salvee
Das Team, das den R200 designed hat (also nicht das Team um ArtX).

Das war doch die Truppe, die mit mehr Taktung nicht mal ne TI500 geschlagen haben? Jeder hat ne 2. Chance verdient:D

duckofdeath

2003-01-27, 21:47:07

ah den versauens scho net! der wird sicher der überdrüberhammer

nagus

2003-01-27, 23:17:06

rage3d forum...

http://www.rage3d.com/board/showthread.php?s=&threadid=33661204&pagenumber=6

"I think the AIW R400 will be digital cable ready and have 2 built in tuners so you no longer need to add a second tuner card. It will also have hardware MPEG2 encoder/decoder and hardware divx encoder/decoder.

With it being faster nVidia will go out of business and all the ex 3DFX employees will shout out in joy that nVidia is dead. ATi will buy nVidia and kill it and take what ever technoligy is usefull. They will hire back all the good 3Dfx programers and will use 3DFx, nVidia and ATi technoligies to make a new processesor. The r500.

It will support OpenGL 3 and directX10 and Glide. Sorry had to throw glide in there lol. It will be used in the GameCube2, Xbox2 and ATi will make so much money that they will buy Microsoft and Nintendo. They then will beat out the Playstation 2 and buy Sony.

The then will make 1 machine and will have all the games run on it. All games will run perfectly and the world will be a happier place. All because of the R400 taking down nVidia

Ok seriously I think it will probly have 256MB of ram and 16 pipelines. It will do 32 textures per pass and do a 2 billion triangles. Radeon girl will look really hot and Dawn (nVidia fairy person) will get mad and quit working for nvidia. She'll join ATi and get better looking and the 2 of them will get some a BFG and blow up nVidia.

They will then go home and play games on the Radeon r500 and Radeon girl will get mad and blow up Dawn. She will then smile and the world will slowly forget about nVidia.

ATi will be rich because they are the only card company left. The wold will truely be a better place.
"

ich hab mich fast tod gelacht :lol::lol::lol:

ernsthaft: ich traue ATI absolut zu, eine neue "Killer" -generation wie damals die R300 zu entwickeln. wenn die nv35 im herbst kommt, wird das teil keine sau mehr interessieren. falls ati keinen mist baut, wie nvidia jetzt.

Quasar

2003-01-27, 23:22:07

Hm,
dein Zitat ausm R2D-Forum ist echt niedlich :D

Aber dein Zutrauen zu ATi teile ich nicht so sehr. Grund: Der R300 wurde von einem zugekauften Team entwickelt, und große Teile der Technologie lagen schon in der Schublade.
Das hat ATi zwischen R200 und R300 zu so einem großen Sprung befähigt. Nun ist erstmal Evolution statt Revolution angesagt.

nVidia hat offenbar wirklich gepennt oder ATi total unterschätzt, als sie mit dem R300 rauskamen.

duckofdeath

2003-01-27, 23:30:00

die aussage ausm rage3dforum is göttlich!!

Salvee

2003-01-27, 23:44:36

Originally posted by LovesuckZ

Das war doch die Truppe, die mit mehr Taktung nicht mal ne TI500 geschlagen haben? Jeder hat ne 2. Chance verdient:D

Genau diese Truppe wars (laut diversen Forenaussagen).

Wenn diese allerdings im vorhergesehenen Zeitrahmen bleiben und dabei den gleichen Performancesprung R100->R200 schaffen,
muss man sich um R400 keine Sorgen machen :)

Laut Gerüchten wird am R400 seit fast zwei Jahren designed und das Tapeout wird für Ende Q1/2003 bzw. Q2/2003 erwartet.

Alles wird gut ;)

duckofdeath

2003-01-28, 00:17:34

ich glaub auch dass ati genau im zeitplan ist und sich das r350 team schon wieder an die arbeiten am r500 gemacht hat!
vielleicht sehen wir den dann als radeon nx (Nvidia+ 3dfX) :D

Salvee

2003-01-28, 06:45:53

Kleines Update von CMKRNL (ihr wisst schon ;) )

'My information indicates that R400 will be a very substantial step up from the current generation products both in performance and features.

R350 is functionally close to R300, but faster.
NV35 is functionally close to NV30, but faster.

R400 and NV40 on the other hand, both represent a big step forward in the technology they will introduce (as well as having much higher performance)'

Kurz gesagt: Also R400 (um den geht es ja hier ;) ), wird gewaltig rul0rn.

Labberlippe

2003-01-28, 09:50:32

Originally posted by LovesuckZ

Das war doch die Truppe, die mit mehr Taktung nicht mal ne TI500 geschlagen haben? Jeder hat ne 2. Chance verdient:D
Äh nicht ganz.
Der ursprünglich geplante Gegener war die normale GeForce3.
nVIDIA hat hier aber taktisch, dann eine TI 500 gebracht.
Übrigens hier hat ATi auch gewonnen, nur war FSAA noch SuperSampling und einfach zu langsam.
Nach kurzer Zeit mit den neuen Treiber war aber die R8500 leicht über TI500.

Gruss Labberlippe

Unregistered

2003-01-28, 13:41:22

Originally posted by Labberlippe

Nach kurzer Zeit mit den neuen Treiber war aber die R8500 leicht über TI500.

Gruss Labberlippe

Das ist die 8500 bis heute nicht. In der Mehrzahl der Anwendungen wird sie von einer GF3 geschlagen.

[ncp]EasyChiller

2003-01-28, 16:16:42

nope! ...

AlfredENeumann

2003-01-28, 17:15:18

Originally posted by Unregistered

Das ist die 8500 bis heute nicht. In der Mehrzahl der Anwendungen wird sie von einer GF3 geschlagen.

never.

Spake

2003-01-28, 18:07:27

naja nvidia hat eben schneller und bessere Treiber rausgebracht als Ati und hat deshalb gewonnen
aber du hast schon recht:
der gegner der R8500 war die Geforce ohne Ti

Borbarad

2003-01-28, 18:19:08

Originally posted by duckofdeath
ah den versauens scho net! der wird sicher der überdrüberhammer

Wie viele Leute haben das bis vor kurzem noch über nVIDIAs NV30 gedacht? Noch ist alles offen und es bleibt spannend ;).

Entscheident wird sicher, ob ATI nicht auch ihre Schwierigkeiten mit dem 0,13µ Fertigsprozeß haben werden und Lernprozesse müssen auch sie erst damit machen.
Somit geht Zeit ins Land, die dann wieder NV helfen wird aufzuschließen...

Gruß,
Borbarad

Spake

2003-01-28, 18:47:06

hmm aber Ati ist beim gleichen produktionspartner und kann so vielleicht aus den fehlern der x lernen und es besser machen und ihren zeitplan einhalten

was mich viel mehr interressiert ist die frage ob es überhaupt einen refresh der R400 aka R450 geben wird?!
hab bis jetzt noch nichts drüber gelesen

2003-01-28, 22:01:19

Könnte es nicht sein, dass ATI den 130nm Prozess überspringt und direkt zu 90nm übergeht?
Mehrere Firmen sind momentan dabei, ihre Fabriken auf 90nm umzustellen, im Herbst bzw. Ende 2003 soll es, glaube ich, sein, oder? Dann wäre es der Hammer!

Rampage 2

2003-01-28, 22:41:08

Originally posted by nagus

IMHO auf jeden fall min. absolut vollständige DX9 unterstürtzung. core takt ist schwer zu sagen ohne die ungefähre anzahl der transistoren zu kennen. 700mhz scheinen mir aber mehr als unwahrscheinlich.

0,15 R200 275Mhz > 0,15 R300 325 Mhz > 0,13 R400 700Mhz ?!?! ...glaub ich kaum.

Ich schätze die Features mal so ein:

500MHz Chiptakt
500MHz physikalischer Speichertakt (effektiv 1GHz DDR2)
daraus resultierend 32GB/sec. theoretische Speicherbandbreite
12 Pixelpipelines mit je einer Textureinheit (= 6 Gpixel/texel sec.)
4 VertexShader Einheiten (= 500 Mvertices/triangles sec.)
8xAA (RGMS) (wer weiß, vielleicht wird es angeboten)
32xAF (halte ich für wahrscheinlich)

Ich denke der R400 wird 3x so schnell wie R9700Pro und doppelt so
schnell wie eine GFFX

Richthofen

2003-01-29, 00:20:08

"
never.
"

Soll ich dir reihenweise Benchmarks raussuchen, in denen eindeutig zu sehen ist das die GF3Ti500 damals wie heute der Radeon8500 überlegen ist?

Solltest du dich nur auf die GF3 bezogen haben beachte mein Posting nicht.
Allerdings gehören GF3Ti500 und Radeon8500 in ein Zeitfenster und da hat Nvidia gewonnen.

AlfredENeumann

2003-01-29, 00:43:26

Originally posted by Richthofen
"
never.
"

Soll ich dir reihenweise Benchmarks raussuchen, in denen eindeutig zu sehen ist das die GF3Ti500 damals wie heute der Radeon8500 überlegen ist?

Solltest du dich nur auf die GF3 bezogen haben beachte mein Posting nicht.
Allerdings gehören GF3Ti500 und Radeon8500 in ein Zeitfenster und da hat Nvidia gewonnen.

Ich bezogs auf GF3. Dafür ist die R200 gedacht gewesen. Nie für die TI500.

duckofdeath

2003-01-29, 03:21:18

also r200 und nv20 waren gestern! ausserdem hat der r200 imho eindeutig die besseren shader! und gegen die normale gf3 gewinnt sie allemal!

zurück zum thema: der r400 wird es imo gegen den nv35 recht leicht haben da nvidia höchstens ein 256bit speicherinterface einbauen kann und nicht den chip grundliegend ändern kann und da die fx ja angeblich nicht bandbreitenlimitiert ist habens sies verdammt schwer! weil den chiptakt könnens ja nimma sehr weit nach oben schrauben da sie ja nicht eine doppelte flowfx einbauen oder gar ein peltier benutzen wollen!
Also sag ich nur als fairer Ati fan: Ich wünsche mehr glück mit der nv4x serie NVIDIA

Crushinator

2003-01-29, 04:38:55

Originally posted by Quasar
Aber dein Zutrauen zu ATi teile ich nicht so sehr. Grund: Der R300 wurde von einem zugekauften Team entwickelt, und große Teile der Technologie lagen schon in der Schublade.
Das hat ATi zwischen R200 und R300 zu so einem großen Sprung befähigt. Nun ist erstmal Evolution statt Revolution angesagt. Demirug erzählt aber, daß R300 im Prinzip nur eine erweiterte R200 darstellt und nun? Ich glaub' Du tust ATi diesbezüglich einwenig unrecht, denn gute Hardware konnten sie schon immer bauen.

Ailuros

2003-01-29, 05:12:51

Quasar,

Ich hab zwar den ganzen Thread nicht durchgelesen (und obwohl ich mit Deiner Denkensweise mehr oder weniger uebereinstimme), liegt noch so einiges Interessantes in der ArtX Schublade dass noch nicht ausgenutzt wurde. ;)

Demirug

2003-01-29, 07:46:06

Originally posted by Ailuros
Quasar,

Ich hab zwar den ganzen Thread nicht durchgelesen (und obwohl ich mit Deiner Denkensweise mehr oder weniger uebereinstimme), liegt noch so einiges Interessantes in der ArtX Schublade dass noch nicht ausgenutzt wurde. ;)

Da liegt sicherlich noch so einiges. Nur im Unterschied zu den Konsolenchips kann man im PC-Bereich ja inzwischen keine Alleingänge mehr machen. Jeder Versuch in diese Richtung ging mehr oder minder daneben.

Exxtreme

2003-01-29, 07:56:07

Originally posted by Demirug

Da liegt sicherlich noch so einiges. Nur im Unterschied zu den Konsolenchips kann man im PC-Bereich ja inzwischen keine Alleingänge mehr machen. Jeder Versuch in diese Richtung ging mehr oder minder daneben.
Aber spiele-unabhängige Sachen kann man aber doch einbauen. ArtX hat in den GC-Chip eine interessante Technik namens "virtual texturing" eingebaut. Also diese Technik kann schon Speicherplatz und Bandbreite sparen.

Demirug

2003-01-29, 08:10:05

Originally posted by Exxtreme

Aber spiele-unabhängige Sachen kann man aber doch einbauen. ArtX hat in den GC-Chip eine interessante Technik namens "virtual texturing" eingebaut. Also diese Technik kann schon Speicherplatz und Bandbreite sparen.

natürlich sachen die man nicht extra Programmieren muss um sie zu nutzen kann man immer einbauen (solange sie halt zum rest passen).

Im Bezug auf "Virtual Texturing" würde ich mal vermuten das Techniken dieser Art schon länger in den PC Chips verbaut sind. Vertex Compression finde ich da persönlich interesanter.

Ailuros

2003-01-29, 12:39:18

Originally posted by Demirug

Da liegt sicherlich noch so einiges. Nur im Unterschied zu den Konsolenchips kann man im PC-Bereich ja inzwischen keine Alleingänge mehr machen. Jeder Versuch in diese Richtung ging mehr oder minder daneben.

Obwohl fuer ATI nicht viel Notwendigkeit dafuer besteht momentan, haben ArtX nicht auch deferred rendering in ihrem Portofolio?

robbitop

2003-01-29, 15:05:51

afair haben sie nicht...aber man sieht ja an NV und GP dass das nix nützt (is ja auch ein ganz anders zu designender Chip so ein TBR/DR und damit vieleicht schwerer zu designen -> mehr Zeit)

Spake

2003-01-29, 17:15:28

tjoa oder nvidia will sich einfach nicht auf neuland wagen
wollten j auch kein 256 Bit DDR sondern stetzten auf 128 Bit wobei VS array eine ganz andere geschichte ist

aber so wie es aussah wollte der alte IMR hase 3dfx auf TBDR umsteigen und deshalb werden diesen schritt über kurz oder lang (5-10 jahre) auch andere hersteller wagen

Ailuros

2003-01-31, 02:59:01

Originally posted by robbitop
afair haben sie nicht...aber man sieht ja an NV und GP dass das nix nützt (is ja auch ein ganz anders zu designender Chip so ein TBR/DR und damit vieleicht schwerer zu designen -> mehr Zeit)

Laenger als die fuer NV30 verbraucht haben bestimmt nicht. ;)

Spake

2003-02-01, 16:57:02

hmm beim nv30 hat ja die konstruktion eher am wenigsten zeit verbraucht sondern eher o.13 etc.

Ailuros

2003-02-02, 03:03:06

Originally posted by Spake
hmm beim nv30 hat ja die konstruktion eher am wenigsten zeit verbraucht sondern eher o.13 etc.

NV30 Design begann im Jahr 2000. Projektion war fuer Q4 2001/Q1 2002. Was denen Dick auf den Buckel gegangen ist war die 13um/low k electric Kombination.

Auf jeden Fall verbrauchen IHV's vom Kreidetafel Design bis zur Veroeffentlichung von einer neuen Generation selten weniger als 18 Monate.

duckofdeath

2003-02-02, 04:07:05

oder sie haben das design ändern müssen! stellt euch mal vor wie schlecht der nv30 mit 6 pipes wäre!

Ailuros

2003-02-02, 05:06:21

Die Geschichte sah in etwa so aus:

http://www.beyond3d.com/forum/viewtopic.php?t=4072

Zwar nicht 100%, aber verdammt nahe dran. Uebrigens hat sich deren roadmap zwischen 2001 und 2003 zweimal geaendert.

duckofdeath

2003-02-02, 07:37:23

traurig, traurig.... egal was man sagt er ist sicher kein schlechter chip aber die wichtigste entwicklung sollte anders aussehen
also ich sag mal intel und nvidia haben eines gemeinsam: taktrate! aber ob es ihnen im endeffekt wirklich was bring steht in den sternen!

LovesuckZ

2003-02-02, 08:51:44

Originally posted by duckofdeath
also ich sag mal intel und nvidia haben eines gemeinsam: taktrate!

Bitte ATi nicht vergessen.

Ailuros

2003-02-02, 14:25:31

also ich sag mal intel und nvidia haben eines gemeinsam: taktrate! aber ob es ihnen im endeffekt wirklich was bring steht in den sternen!

Oder auch anders:

NV = erster Versuch = veraltete Algorithmen
Intel = erster Versuch = noFPU inside

;D

Ailuros

2003-02-02, 14:29:47

Originally posted by LovesuckZ

Bitte ATi nicht vergessen.

Ich kann mir vorstellen dass er die parallele NV/Intel anders meinte.

R300 ist clock for clock schneller als NV30, genauso wie AMD im Vergleich zu Intel.

Ich koennte soweit gehen und behaupten dass R300 ein GF-rating (so wie Pentium rating) von 500 hat, obwohl sie nur auf 325MHz getaktet ist. j/k ;)

LovesuckZ

2003-02-02, 15:00:06

Originally posted by Ailuros
R300 ist clock for clock schneller als NV30, genauso wie AMD im Vergleich zu Intel.

Da sagt aber diesesw Bild was vollkommen anderes aus:
http://www.hardware.fr/medias/photos_news/00/05/IMG0005783.gif

Afin d´en savoir plus, nous avons donc fait un test des différentes architectures GeForce 4 / Radeon 9700 et GeForce FX à fréquence égale (275/270). Afin d´avoir une bande passante mémoire identique, nous avons en fait utilisé un Radeon 9500 Pro, qui utilise comme le GeForce4 et le GeForce FX un bus mémoire 128 bits.

Quelle (http://www.hardware.fr/articles/453/page9.html)

Die FX ist also im reinen Speed her nicht langsamer als ne 9500pro.
Warum sie aber beim AA/AFso einbricht, ist mir schleicherhaft und wahrscheinlich noch auf die Beta Treiber zu schieben.

Spake

2003-02-02, 15:34:59

LovesuckZ, ich glaube eher dass der gedanke in die richtung ging dass die R300 auf 325 Core schneller ist als der nv30 auf 325 Core und dann zwar um einiges

Xmas

2003-02-02, 16:06:07

LovesuckZ

2003-02-02, 17:01:51

Originally posted by Spake
LovesuckZ, ich glaube eher dass der gedanke in die richtung ging dass die R300 auf 325 Core schneller ist als der nv30 auf 325 Core und dann zwar um einiges

Weil der Vergleich dann wegen der Bandbreite unfair ist. Entweder man vergleicht beide so wie man sie kaufen kann oder nimmt die 9500pro und guckt, wie gut die FX mit gleichen Takt wie eine r300 mit 128BIT Speicherinterface sich schlaegt.

DasToem

2003-02-02, 17:13:34

***Deleted***

Tom

Demirug

2003-02-02, 17:19:48

Originally posted by DasToem

Ich weiß nicht, wo du hieraus einen Vorteil für die GFFX erkennen kannst. Schauen wir uns dochmal das Verhältnis Frames-Takt an:
Q3 GFFX 1600er kAF/kAA 0.29frames/MHz
Q3 R9500 pro 1600er kAF/kAA 0.50frames/MHz

Q3 GFFX 1600er 8AF/4AA 0.10 frames/MHz
Q3 R9500 pro 1600er 8AF/4AA 0.25frames/MHz

1:0 für ATI

Tom

PS: Hab den Speichertakt nicht beachtet.

du hast aber schon gesehen das beide Karten mit dem gleichen Core(275) und Speichertakt (270) gemessen wurde?

duckofdeath

2003-02-02, 17:23:01

Bitte ATi nicht vergessen.

sorry aber ich will ati nicht im gleichen atemzug mit nvidia/intel nennen...

ich kann mir vorstellen dass er die parallele NV/Intel anders meinte.

R300 ist clock for clock schneller als NV30, genauso wie AMD im Vergleich zu Intel.

Stimmt genau!

DasToem

2003-02-02, 17:24:46

Originally posted by Demirug

du hast aber schon gesehen das beide Karten mit dem gleichen Core(275) und Speichertakt (270) gemessen wurde?

Huch sry! Mein frz is echt ziehmlich grottig :).

Tom

LovesuckZ

2003-02-02, 17:30:35

Originally posted by duckofdeath
Stimmt genau!

Ich seh es nicht, dass ATI die bessere Leistung pro MHZ erbringt.

duckofdeath

2003-02-02, 17:34:43

sorry mein auch die leistung generell! oda meinst du die fx hätte mit einem 256bit speicherinterface mehr chancen? :stareup:

LovesuckZ

2003-02-02, 17:49:55

Originally posted by duckofdeath
sorry mein auch die leistung generell! oda meinst du die fx hätte mit einem 256bit speicherinterface mehr chancen? :stareup:

Wenn ich mir die AA Werte bei einigen test angucke - auf jeden Fall.

AlfredENeumann

2003-02-02, 18:48:51

AlfredENeumann

2003-02-02, 18:50:37

Originally posted by Demirug

du hast aber schon gesehen das beide Karten mit dem gleichen Core(275) und Speichertakt (270) gemessen wurde?

Aber nicht mit gleichem Speicher !!!!!

Exxtreme

2003-02-02, 18:50:42

AlfredENeumann

2003-02-02, 18:51:46

Originally posted by Exxtreme

Warum das? :|

Wie hoch ist die Bandbreite beider karten ?

Exxtreme

2003-02-02, 18:53:08

Originally posted by AlfredENeumann

Wie hoch ist die Bandbreite beider karten ?
Genauso hoch...

Dir ist schon klar, daß DDRII-RAM bei gleichem Takt sogar langsamer ist als DDRI-RAM?

Demirug

2003-02-02, 18:54:39

Originally posted by AlfredENeumann

Der vergleich ist für mich ein Witz !!!

Ne Karte mit 128Bit DDR1 RAM zu vergleichen gegen eine mit 128Bit DDR2 RAM.
Mann hätte da eher zur 9700non Pro greifen müssen.

Warum Witz???

Beide Chips hatten den gleichen Coretakt und bekammen die gleiche Bandbreite zu Verfügung gestellt. Also durchaus ein fairer Vergleich. Wobei man natürlich einräumen muss das der NV30 möglicherweise einen kleinen Vorteil hat. 4*32 könnte dem 2*64 überlegen sein.

Warum du hier einen Vorteil durch DDR-II gegen DDR-I sehen kannst verstehe ich nicht ganz.

AlfredENeumann

2003-02-02, 18:58:47

Originally posted by Exxtreme

Genauso hoch...

Dir ist schon klar, daß DDRII-RAM bei gleichem Takt sogar langsamer ist als DDRI-RAM?

:bonk: Boahr bin ich doof. Sorry. Nehme alles zurück !!!

Bin noch nicht ganz wach.

AlfredENeumann

2003-02-02, 19:35:28

Es würde mich aber trotzdem noch interessieren inwieweit beide Chips bei ansteigendem Core-Takt mitskalieren.

aths

2003-02-02, 21:21:28

Originally posted by Demirug
Wobei man natürlich einräumen muss das der NV30 möglicherweise einen kleinen Vorteil hat. 4*32 könnte dem 2*64 überlegen sein.Ja, ein bisschen. Ich verstehe aber nicht, wieso darauf immer rumgeritten wird. Hauptsache überhaupt eine Teilung und ein vernünftiges Cache-System. Sachen wie Early Z sind (bei guter Cache-Struktur) imo wesentlicher als der Unterschied einer Speicheranbindungs-Unterteilung in 2 oder 4 Kanäle.

diedl

2003-02-02, 21:23:21

trotzdem bringt mich der Vergleich 9500pro mit der FX ein wenig
zu denken. Neben dem 2x64b bzw 4x32b Unterschied sehe ich noch
eine ganz andere Problematik. Die GPUs sind was die Speicheranbindung
angeht anders ausgelegt.
Kleiner Vergleich mal zur CPU Welt.
Einen K7 kann man ruhig mal die doppelte Speicherbandbreite
anbieten, blos provitieren kann er davon so gut wie garnicht
weil er Sie nicht nutzen kann.
Bei einen P4 sieht das schon anders aus.
(Beide von DDR Ram ausgehend)
Demnach währe ein Vergleich 9500 pro/FX unfair. (Für die Radeon)
Genauso ist aber der Vergleich 9700/FX unfair. (Für die FX)
-Obwohl, dass er nicht für 256 b ausgelegt ist, ist ja die
Schuld des Chips.-
Ob man das jetzt so einfach auf die GPUs übertragen kann
müssen die Spezialisten klären.

mfg diedl

Demirug

2003-02-02, 21:49:39

@diedl:

Der Vergleich zwischen CPU und GPU/VPU hinkt ein wenig. Bei der CPU kommt ja neben der Bandbreite zwischen dem Chipsatz und dem Speicher ja auch noch die mögliche Bandbreite zwischen den Chipsatz und der CPU als Flaschenhals hinzu. Bei einem Grafikchip ist der Speicher direkt angebunden daher kann auch jedes Bit/s mehr genutzt werden.

@aths:

Natürlich sind Cache-Systeme und dinge wie Early-Z wichtig. Sie können ja die Anzahl der benötigten Speicherzugriffe reduzieren. Aber früher oder später kommt es dazu und je feiner die Unterteilung des Speicherbusses ist desto besser ist das. Um den Speicher effektiv auszunutzen sollte immer mit Burst gefetch werden. Mit jedem Fetch wird nun also eine Speicherkachel geladen. Und das hat auswirkungen auf alles. Je breiter ein Kanal ist desto grösser werden die Kacheln. Dies führt dazu das in einem Cache gleicher grösse viel weniger Kacheln gespeichert werden können was die Cachehits reduziert. Je weniger Kontroller zur Verfügung stehen desto mehr von der Speicher ist blockiert wenn dieser Kontroller etwas erledingen muss. Dadurch müssen dann andere Speicherzugriffe warten.

Zwar nimmt der Gewinn bei steigener Anzahl von Kanälen ab aber er ist immer noch vorhanden.

diedl

2003-02-02, 22:00:26

@Demirug
Ist richtig was du schreibst.
Ich bin auf diese Idee gekommen da die FX, in einen Test, von
einer Erhöhung der Bandbreite von 10%, so gut wie garnicht
provitieren konnte.

mfg diedl

zeckensack

2003-02-02, 22:14:33

Originally posted by diedl
@Demirug
Ist richtig was du schreibst.
Ich bin auf diese Idee gekommen da die FX, in einen Test, von
einer Erhöhung der Bandbreite von 10%, so gut wie garnicht
provitieren konnte.

mfg diedl Das könnte darauf hindeuten, daß der Chip erstens intern alles über einen Cache regelt, und zweitens dieser Cache genausoviel Bandbreite hat, wie der externe Speicher.

Man könnte also auch sagen, daß die FX auf synchronen Chip/Speichertakt ausgelegt ist. Ansonsten hätte sie von der Übertaktung des Speichers profitieren müssen.

Auf der anderen Seite würde das auch bedeuten, daß der NV30 nicht ohne Redesign des Caches auf ein 256bittiges Speicherinterface aufgerüstet werden kann.

Demirug

2003-02-02, 22:18:14

Originally posted by zeckensack
Das könnte darauf hindeuten, daß der Chip erstens intern alles über einen Cache regelt, und zweitens dieser Cache genausoviel Bandbreite hat, wie der externe Speicher.

Man könnte also auch sagen, daß die FX auf synchronen Chip/Speichertakt ausgelegt ist. Ansonsten hätte sie von der Übertaktung des Speichers profitieren müssen.

Auf der anderen Seite würde das auch bedeuten, daß der NV30 nicht ohne Redesign des Caches auf ein 256bittiges Speicherinterface aufgerüstet werden kann.

Oder das bei diesem Test die Bandbreite nicht der Flaschenhals war. Ich sage ja immer wer bei sowas übertaktet muss auch untertakten sonst sind die Aussagen nur begrennzt verwertbar.

Unregistered

2003-02-02, 23:43:35

wurde das nicht sogar auch (400/400 400/500 500/400 und dann halt noch die OCs)

naja da 400/500 und 500/400 gleichschnell waren aber ein stück schneller als 400/400...was schliessen wir daraus?

robbitop

2003-02-02, 23:44:42

unreg war ich ..bloede cookies..

zeckensack

2003-02-03, 00:47:28

Originally posted by Unregistered
wurde das nicht sogar auch (400/400 400/500 500/400 und dann halt noch die OCs)

naja da 400/500 und 500/400 gleichschnell waren aber ein stück schneller als 400/400...was schliessen wir daraus? Obwohl das natürlich bei weitem nicht mit so wenig Information geschlußfolgert werden kann, denke ich daß das meine These stützt:
Der Chiptakt (=Cachetakt) begrenzt die nutzbare Speicherbandbreite.

Jedenfalls fällt mir im Moment keine bessere Erklärung ein. Wenn ihr eine habt, dann immer her damit :)

@Demirug:
Ein Spiel wie Q3A wäre IMO für solche Tests geradezu optimal. Aktuelle Prozessoren haben keine Probleme mit 200+ fps. Der Overdraw ist zum Großteil nicht-transparent, bei einer gut ausbalancierten Architektur läuft's also auf
1)Füllrate
2)Texturcache und Texturbandbreite
hinaus.

Die GFFX mit 256 Bit Farbe+Z vs 256 Bit möglichem Speichertraffic pro Takt läuft auch schon hart am Bandbreitenlimit.

Theoretische Tests wären natürlich auch nicht schlecht ;)

Ailuros

2003-02-03, 05:07:23

Originally posted by LovesuckZ

Da sagt aber diesesw Bild was vollkommen anderes aus:
http://www.hardware.fr/medias/photos_news/00/05/IMG0005783.gif

Afin d´en savoir plus, nous avons donc fait un test des différentes architectures GeForce 4 / Radeon 9700 et GeForce FX à fréquence égale (275/270). Afin d´avoir une bande passante mémoire identique, nous avons en fait utilisé un Radeon 9500 Pro, qui utilise comme le GeForce4 et le GeForce FX un bus mémoire 128 bits.

Quelle (http://www.hardware.fr/articles/453/page9.html)

Die FX ist also im reinen Speed her nicht langsamer als ne 9500pro.
Warum sie aber beim AA/AFso einbricht, ist mir schleicherhaft und wahrscheinlich noch auf die Beta Treiber zu schieben.

Ich wuerde schon denken dass wenn ich eine Taktrate von 325MHz erwaehne, dass jemand dahinter kommen koennte dass ich eine 9700PRO meinte.

Ob solche Vergleiche wie der eigentliche Witz von mir auch Sinn machen ist eine andere Geschichte.

Nichtdestotrotz wenn ich mir die Resultate oben anschaue sehe ich dass die 9500PRO mit 4xAA/Aniso um ganze 32% schneller ist als die FX in q3a und 27% in UT2003. Dabei brauch ich nicht lange raten dass die 9700PRO immer noch weiter vorne liegt; Bandbreite hin und her ist mir egal.

Von einer Perspektive die optimale Bildqualitaet miteinbegreift, ist die R9700 Takt fuer Takt schneller als die FX. Klingt der "Witz" jetzt besser? ;)

Demirug

2003-02-03, 07:31:57

Originally posted by zeckensack
Obwohl das natürlich bei weitem nicht mit so wenig Information geschlußfolgert werden kann, denke ich daß das meine These stützt:
Der Chiptakt (=Cachetakt) begrenzt die nutzbare Speicherbandbreite.

Jedenfalls fällt mir im Moment keine bessere Erklärung ein. Wenn ihr eine habt, dann immer her damit :)

@Demirug:
Ein Spiel wie Q3A wäre IMO für solche Tests geradezu optimal. Aktuelle Prozessoren haben keine Probleme mit 200+ fps. Der Overdraw ist zum Großteil nicht-transparent, bei einer gut ausbalancierten Architektur läuft's also auf
1)Füllrate
2)Texturcache und Texturbandbreite
hinaus.

Die GFFX mit 256 Bit Farbe+Z vs 256 Bit möglichem Speichertraffic pro Takt läuft auch schon hart am Bandbreitenlimit.

Theoretische Tests wären natürlich auch nicht schlecht ;)

Ja Q3A wäre sicher nicht schlecht dafür. Wobei der beste Test für sowas dürfte der 3dMark ST-Fillratetest sein.

Crushinator

2003-02-03, 09:27:53

Originally posted by Ailuros Nichtdestotrotz wenn ich mir die Resultate oben anschaue sehe ich dass die 9500PRO mit 4xAA/Aniso um ganze 32% schneller ist als die FX in q3a und 27% in UT2003. Dabei brauch ich nicht lange raten dass die 9700PRO immer noch weiter vorne liegt; Bandbreite hin und her ist mir egal. Jo! Bei den Werten muß man sich wirklich fragen, was man für ein Zeug geraucht haben muß, um einerseits immer darauf zu pochen, daß Leistung bei AA/AF sehr wichtig sind und andererseits die FX immer noch vor der R300 (mit 128-Bit Anbindung) zu sehen. ;)

LovesuckZ

2003-02-03, 10:18:30

Originally posted by Ailuros
Nichtdestotrotz wenn ich mir die Resultate oben anschaue sehe ich dass die 9500PRO mit 4xAA/Aniso um ganze 32% schneller ist als die FX in q3a und 27% in UT2003. Dabei brauch ich nicht lange raten dass die 9700PRO immer noch weiter vorne liegt; Bandbreite hin und her ist mir egal.

Was wiederrum auch an den Betatreiber liegen koennte.
Es ging um die Leistung pro MHZ und nicht um die Geschwindigkeit beim Einsatz von AA/AF.

Unregistered

2003-02-03, 11:16:44

Originally posted by LovesuckZ

Was wiederrum auch an den Betatreiber liegen koennte.
Ausserdem ging es nicht um die Geschwinsdigkeit bei AA/AF, sondern um die Leistung pro MHZ.

:bonk: was hat da das "sondern" verloren?!

LovesuckZ

2003-02-03, 11:20:27

Originally posted by Unregistered
:bonk: was hat da das "sondern" verloren?!

Hm, wie muesste der Satz hoeßen?

/edit: ich schreibs mal um:D

LovesuckZ

2003-02-03, 11:21:20

Crushinator

2003-02-03, 11:27:29

Originally posted by LovesuckZ Was wiederrum auch an den Betatreiber liegen koennte.
Es ging um die Leistung pro MHZ und nicht um die Geschwindigkeit beim Einsatz von AA/AF. Wenn Du schon die Vermutung mit den Betatreibern in den Raum stellst, könnte man genau so die Vermutung äußern, daß die Radeon-Treiber schlechter seien, wenn kein AA/AF im Spiel ist? :naughty:

LovesuckZ

2003-02-03, 11:31:49

Originally posted by crushinator
Wenn Du schon die Vermutung mit den Betatreibern in den Raum stellst, könnte man genau so die Vermutung äußern, daß die Radeon-Treiber schlechter seien, wenn kein AA/AF im Spiel ist? :naughty:

Die 9500pro war mit den ersten Treibern - auch bei AA/AF - langsamer als ne TI4600. Und ATI's hat es doch geschafft (naja bei meiner 9500 nicht;D ), mit einem neuen Treiber deutlich an Leistung zu zulegen.

Ailuros

2003-02-03, 14:09:18

Originally posted by LovesuckZ

Was wiederrum auch an den Betatreiber liegen koennte.
Es ging um die Leistung pro MHZ und nicht um die Geschwindigkeit beim Einsatz von AA/AF.

Ich hab keine Ahnung warum es ueberhaupt eine Debatte wert ist. Wo hab ich in meinem Scherz klar gesetzt was ich ueberhaupt meinte?

Ich spiele schon seit einem Jahr exclusiv nur mit eingesetztem AA/aniso; da finde ich es selbstverstaendlich dass jemand mit einer NV30 oder R300 zumindest die Mindestwerte was AA/aniso betrifft einsetzen wird.

Ich kann mir schlecht vorstellen dass heute jemand ueber 350 euros auf den Tisch legt um verzackte/verwaschene Szenen zu sehen.

Also letzter Versuch:

Radeon9700PRO@ 4xAA/8xAniso = GFFX-U 500 rating

Wobei die Bildqualitaet mit Multisampling einen eher grossen Vorrang bei ATI nimmt.

LovesuckZ

2003-02-03, 14:51:22

Originally posted by Ailuros
Ich hab keine Ahnung warum es ueberhaupt eine Debatte wert ist. Wo hab ich in meinem Scherz klar gesetzt was ich ueberhaupt meinte?

R300 ist clock for clock schneller als NV30, genauso wie AMD im Vergleich zu Intel.

Ailuros

2003-02-04, 00:32:09

Na und? Hab ich dabei nicht genauso die Unterschiede in Architektur zwischen P4 und XP uebersehen?

Und wenn schon nochmal nachgequotet wird hier der ganze Post:

Ich kann mir vorstellen dass er die parallele NV/Intel anders meinte.

R300 ist clock for clock schneller als NV30, genauso wie AMD im Vergleich zu Intel.

Ich koennte soweit gehen und behaupten dass R300 ein GF-rating (so wie Pentium rating) von 500 hat, obwohl sie nur auf 325MHz getaktet ist. j/k

Wobei j/k = just kidding.

Druckbuchstaben zeigen deutlich Taktrate, wobei es klar sein sollte dass mit 325MHz Taktrate auch eine 9700/PRO gemeint ist.

LovesuckZ

2003-02-04, 09:54:41

Originally posted by Ailuros
Druckbuchstaben zeigen deutlich Taktrate, wobei es klar sein sollte dass mit 325MHz Taktrate auch eine 9700/PRO gemeint ist.

Dann musst du auch den Speicher de 9700 runtertakten. Sonst waere der Vergleich nicht fair!

Ailuros

2003-02-04, 11:57:59

Originally posted by LovesuckZ

Dann musst du auch den Speicher de 9700 runtertakten. Sonst waere der Vergleich nicht fair!

Hast Du ueberhaupt verstanden was ich im Grunde meinte? Egal wie die Architektur im ganzen ausgelegt, ist bekommt man mit einem Athlon XP mit niedriger Taktrate gleiche Leistung wie bei einem hoeher getakteten P4. Um vergleichbare Leistung zwischen den beiden CPU's festsetzen zu koennen, kann man Pentium rating verwenden, wobei AMD das PR sogar etwas konservativ angesetzt hat fuer die letzen Prozessoren.

Abgesehen davon war der Witz/Parallele so gemeint dass man mit einer R300 und default Takt momentan genauso viel oder fast genauso viel Leistung bekommt wie mit einer FX Ultra@500/1000MHz. Daher auch das "GeForce Rating@500" fuer die R300.

Alles was in die "ja aber..." Kategorie faellt, ob nun die Differenzen in der Architektur eines P4 oder XP, oder die Busbreite in chip A oder B ist genauso irrelevant wie Bildqualitaet, da hier nur Leistung gemeint ist.

Und falls im "ja aber.."-Bereich Treiberunreife von Seiten der FX fallen sollte, kannst Du frei den Witz auf eine GeForce Rating von 400-450 benutzen, falls die FX auch einen Leistungsschub mit zukuenftigen Treibern "across the board" bekommen sollte.

Wenn Du willst koennen wir ja durch einen Qualitaets-Vergleich zwischen 4xOGMS bei der FX und 4xRGMS bei der R300 gehen; mal sehen was dann "fair" oder "unfair" und fuer welche Karte ist.