PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : ATI Chips


JuNkEE
2003-11-28, 22:58:56
Hi,

wann gibts denn endlich mal wieder eine ganz neue GPU von ATI? Bisher sind ja eigentlich alle derzeitigen High-End Chips remakes vom R300.
Vor ein paar Monaten war man ja noch der Annahme, dass der kommende R420 ein völlig neues Interface hat, was aber inzwischen von ATi auch wieder verneint wurde.
Also... wann wird ATi wieder was ganz neues auf den Markt schmeissen?

Bye

robbitop
2003-11-28, 23:10:40
vermutlich erst mit dem R500....R420 wird zwar groß und stark aber nichts revolutionär neues, nachdem was man so hört...

nagus
2003-11-28, 23:11:32
ich schätze mal in 9 - 12 monaten ca. bis dahin wird die R420 noch so richtig "gemolken" ;)

Gast
2003-11-29, 00:08:41
Original geschrieben von nagus
ich schätze mal in 9 - 12 monaten ca. bis dahin wird die R420 noch so richtig "gemolken" ;)

Ich denk eher so ein Evolutionssprung wie von GF3 auf GF4. NV40 geht sicherlich in die selbe Richtung.

-error-
2003-11-29, 02:32:34
Ich denke mal der R420 wird wie der R350, jedoch auf 0.13µ basieren, womit Taktraten zwischen 500-600mhz erzielt werden können (s. 9600XT overlocked)

Und dann wirds kritischer für Nvidia, die nicht mehr so einfach Taktsteigerung durchführen könnten. Zudem wird DDR2 auch Einzug bei ATI halten.

SamLombardo
2003-11-29, 09:18:35
Original geschrieben von Powerd by ATI
Und dann wirds kritischer für Nvidia, die nicht mehr so einfach Taktsteigerung durchführen könnten. Zudem wird DDR2 auch Einzug bei ATI halten.

Nur wird NV bis dahin den NV40 auf dem Markt haben. Wie es dann aussieht steht auf einem ganz andeem Blatt (PS3.0 Problem bei Ati Architektur). Also von "kritisch für Nvidia" kann imo keine Rede sein, wohl eher das Gegenteil...

mfG Sam

robbitop
2003-11-29, 09:41:51
der NV40 wird das sein, was NV30 hätte angeblich werden sollen ;)
neues AA / PPP / 6x2(8x2)


zum R420 und NV40 gibt es aber bisher keine Aussagekräftigen Infos

The Heel
2003-11-29, 11:01:36
ich sehe dann auch nvidia im vorteil,...

Piffan
2003-11-29, 11:37:54
Original geschrieben von The Heel
ich sehe dann auch nvidia im vorteil,...

Solche Aussagen sind wie Kaffeesatzlesen......kann sein, kann aber auch nicht sein ;)

Ich hoffe jedenfalls mal, dass die zukünftigen GPUs nicht zu stark differieren, so was wäre schädlich für die Konkurrenz und würde die Gefahr beinhalten, dass die Spieleentwickler wieder recht einseitig einen der Großen bevorzugen.

HOT
2003-11-29, 20:13:12
Meine Meinung:
R420, NV40, PwerVR Serie5 ---> PS/VS3.0

ice cool69
2003-12-01, 13:21:11
achja die serie5 von powerVR. na wenn die noch erscheinen sollte bin ich der erste der auf den zug aufspringt.

ansonsten hört sich die r420 nicht schlecht an, das is rechenpower pur.
und ma ehrlich jungs, von ps/vs 3.0 halte ich momentan überhaupt nix, auch die kommende grafikchipgeneration wird auf die 2.0-versionen ausgerichtet sein (siehe news) und 3.0-effekte liegen dermaßen weit in der zukunft...das kann man knicken.

achja, inwiefern hat die r300-architektur probs mit vs/ps 3.0? quelle???

zeckensack
2003-12-01, 14:01:55
Original geschrieben von JuNkEE
Hi,

wann gibts denn endlich mal wieder eine ganz neue GPU von ATI?When it's done.

mapel110
2003-12-01, 14:11:02
Original geschrieben von zeckensack
When it's done.

1.4.2004 :naughty:

aths
2003-12-01, 14:55:34
Original geschrieben von ice cool69
und ma ehrlich jungs, von ps/vs 3.0 halte ich momentan überhaupt nix, auch die kommende grafikchipgeneration wird auf die 2.0-versionen ausgerichtet sein (siehe news) und 3.0-effekte liegen dermaßen weit in der zukunft...das kann man knicken.Immer langsam mit den jungen Pferden...

PS.3.0 erfordert z.B. einen Instructioncount von 512. Das heißt, auf lange Sicht sind keine Multipass-Shader erforderlich. Zudem müssen alle 2.0-Caps erfüllt werden. Das nenne ich doch mal Einheitlichkeit :) Die Pixelshader 2.0 à la R300 reichen für HL2 sicher aus, aber da ist ja noch lange nicht Schluss.

PS.2.0 haben die Tür aufgestoßen, dass Shader breit eingesetzt werden können. Ich erwarte eine viel schnellere Entwicklung, als z.B. von der Multitexturing-Pipe zum Pixelshader 1.1.

Exxtreme
2003-12-01, 14:59:32
Original geschrieben von Powerd by ATI
Ich denke mal der R420 wird wie der R350, jedoch auf 0.13µ basieren, womit Taktraten zwischen 500-600mhz erzielt werden können (s. 9600XT overlocked)

Aus einer sehr sicheren Quelle weiss ich, daß der R420 mehr Pipelines haben wird. Das Teil soll rund doppelt so schnell werden wie eine R9700Pro.

Exxtreme
2003-12-01, 15:03:13
Original geschrieben von aths
PS.3.0 erfordert z.B. einen Instructioncount von 512. Das heißt, auf lange Sicht sind keine Multipass-Shader erforderlich. Zudem müssen alle 2.0-Caps erfüllt werden. Das nenne ich doch mal Einheitlichkeit :) Die Pixelshader 2.0 à la R300 reichen für HL2 sicher aus, aber da ist ja noch lange nicht Schluss.
Für PS2.0 müssen auch alle PS2.0-Caps erfüllt werden. ;) Und ich glaube nicht, daß die Leistung ausreicht für 512 Shaderanweisungen. Ein R3x0 schafft im Idealfall AFAIK 24 Shaderanweisungen pro Takt. Das sind über 20 Takte pro Shader... im Idealfall versteht sich. Für Spiele dürfte das unbrauchbar werden.

aths
2003-12-01, 15:12:09
Original geschrieben von Exxtreme
Für PS2.0 müssen auch alle PS2.0-Caps erfüllt werden. ;) Und ich glaube nicht, daß die Leistung ausreicht für 512 Shaderanweisungen. Ein R3x0 schafft im Idealfall AFAIK 24 Shaderanweisungen pro Takt. Das sind über 20 Takte pro Shader... im Idealfall versteht sich. Für Spiele dürfte das unbrauchbar werden. Bitte nicht so pauschal :D

Einerseits, nur mal angenommen ein Shader besteht aus 97 Instruktionen. Das geht Singlepass nicht mehr auf dem R300. Man braucht 2 Passes, das ist langsamer, und man verliert afaik auch Genauigkeit.

Andererseits rede ich nicht davon, das ganze Spiel durchgehend mit superlangen Shadern zu gestalten. Demirug müsste mal konkret werden, aber einfachere Materialien brauchen wohl nur -zig Anweisungen, sagen wir mal etwa 50. Wenn man aber bestimmte Effekte schön beleuchten möchte, bietet der PS.3.0 imo große Vorteile: Die bedingten Sprünge (so dass ein Shader unterschiedliche Lichtquellen berücksichtigen kann) und eben den erweiterten Instruction-Count.

Ich erwarte im NV40 und im R4xx taktbereinigt etwa doppelte Shaderpower ggü. den Vorgängern (NV38, R350.)

Der Instruction-Count von 32+64 reicht sicherlich für die "Haupt-Lebenszeit" des R3xx aus. Neue Mid-Range-, aber neue neue Einsteiger-Produkte müssen wohl auf R4xx-Basis kommen.

Demirug
2003-12-01, 15:20:01
Original geschrieben von Exxtreme
Für PS2.0 müssen auch alle PS2.0-Caps erfüllt werden. ;) Und ich glaube nicht, daß die Leistung ausreicht für 512 Shaderanweisungen. Ein R3x0 schafft im Idealfall AFAIK 24 Shaderanweisungen pro Takt. Das sind über 20 Takte pro Shader... im Idealfall versteht sich. Für Spiele dürfte das unbrauchbar werden.

Ich vermute mal das aths die 2.X Caps meinte.

ATI gibt gernen noch eine grössere Zahl an sagt aber nicht wie sie diese errechnen.

Ihr denkt mir bei den 512 Anweisungen aber alle zu direkt. Ein 3.0 Shader der aus 512 Anweisungen besteht muss nicht unbedingt auch 512 Anweisungen pro Pixel ausführen.

Aber selbst wenn es jetzt nicht um das Instruktionslimit geht machen 3.0 Shader sinn.

So enthalten die beiden Primärshader von HL2 (weil wir ja gerade dabei waren) einmal 10 und einmal 11 if-abfragen auf binärwerte welche sich pro Objekt ändern können. Da man bei den PS 2.0 aber kein dynamisches Branching hat gibt es für jedes mögliche Kombination von Bits einen eignen Shader. So werden aus einem Shader 1024 und aus dem anderen 2048 Varianten erzeugt. Daher ist man dann fleisig am Shaderwechseln. Mit PS 3.0 bräuchte man jeweils nur einen und würde nur die Bits übertragen. Das gleiche gilt auch für die VS.

AlfredENeumann
2003-12-01, 15:31:26
Original geschrieben von Exxtreme
Aus einer sehr sicheren Quelle weiss ich, daß der R420 mehr Pipelines haben wird. Das Teil soll rund doppelt so schnell werden wie eine R9700Pro.


Mal schauen wie es zum release mit meinem Geldbeutel aussieht. Sitze ja jetzt an einer netten Quelle und kann so ne nette Karte ziemlich zuerst haben.

reunion
2003-12-01, 16:34:51
Original geschrieben von Exxtreme
Aus einer sehr sicheren Quelle weiss ich, daß der R420 mehr Pipelines haben wird. Das Teil soll rund doppelt so schnell werden wie eine R9700Pro.

Hm, das wären dann entweder 325 mhz mit 16x1 oder 12x1 mit ca. 440 mhz was sich wesentlich realistischer anhört und dazu noch ca. 600 mhz gddr III Ramtakt oder ?? :naughty:

aths
2003-12-01, 16:38:58
Bitte!!! "wären" ohne h!

Beim NV40 erwarte ich eigentlich 8x2, ATI wäre mit 12x1 im Nachteil.

Exxtreme
2003-12-01, 16:50:52
Original geschrieben von aths
Bitte!!! "wären" ohne h!

Beim NV40 erwarte ich eigentlich 8x2, ATI wäre mit 12x1 im Nachteil.
Nicht mit Tri-TMUs... vorausgesetzt natürlich, daß NV keine Tri-TMUs hat.

LovesuckZ
2003-12-01, 16:54:01
Original geschrieben von Exxtreme
Nicht mit Tri-TMUs... vorausgesetzt natürlich, daß NV keine Tri-TMUs hat.

Wieviel Transistoren mehr kosten denn Tri - TMUs statt bri?

reunion
2003-12-01, 17:02:35
Original geschrieben von aths
Bitte!!! "wären" ohne h!

Beim NV40 erwarte ich eigentlich 8x2, ATI wäre mit 12x1 im Nachteil.

Ups, gefixt...

aths
2003-12-01, 17:05:59
Original geschrieben von Exxtreme
Nicht mit Tri-TMUs... vorausgesetzt natürlich, daß NV keine Tri-TMUs hat. NV wird nach wie vor bi-TMUs verwenden. 16 trilineare TMUs machen bandbreitentechnisch imo keinen Sinn. Wenn ATI 12 Pipes haben wird, imo kaum mit trilinearen TMUs. Die Bandbreite wäre btw. auch hier ziemlich strapaziert.

Original geschrieben von LovesuckZ
Wieviel Transistoren mehr kosten denn Tri - TMUs statt bri? Du meist, als bi?

reunion
2003-12-01, 17:06:16
Original geschrieben von aths
Beim NV40 erwarte ich eigentlich 8x2, ATI wäre mit 12x1 im Nachteil.

Glaubst du wirklich an 8x2 ???
Eine verdopplung der Pipes plus PS3.0 Support würde wohl locker die 200Mio Transitorenmarke sprengen...

aths
2003-12-01, 17:07:37
Original geschrieben von reunion
Glaubst du wirklich an 8x2 ???
Eine verdopplung der Pipes plus PS3.0 Support würde wohl locker die 200Mio Transitorenmarke sprengen... Ich gehe von 170-180 Mio Transistoren aus. Wie man weiß, sind die jetzigen Pipes für 3.0 schon einigermaßen gerüstet, das Upgrade auf 3.0 schätze ich nicht so wahnsinnig transistor-intensiv ein.

reunion
2003-12-01, 17:13:52
Original geschrieben von aths
Ich gehe von 170-180 Mio Transistoren aus. Wie man weiß, sind die jetzigen Pipes für 3.0 schon einigermaßen gerüstet, das Upgrade auf 3.0 schätze ich nicht so wahnsinnig transistor-intensiv ein.

Naja ich weiß ja nicht aber eine verdopplung der Pipes dürfte die Transistorenanzahl um locker 50% in die höhe jagen, plus PS3.0 Support und den ein oder anderen Chipinternen verbesserungen wie besseren AA Modus höheren PS Speed...aber wir werden sehn ;)

PS.: Wie siehts eigendlich mit 6x2 aus???

LovesuckZ
2003-12-01, 17:14:24
Original geschrieben von aths
Du meist, als bi?

*hust* ja :)

reunion
2003-12-01, 17:15:08
Original geschrieben von LovesuckZ
Wieviel Transistoren mehr kosten denn Tri - TMUs statt bri?

Kostet wenn ich mich nicht irre kaum mehr Transistoren als bi TMUs...

aths
2003-12-01, 17:19:31
Original geschrieben von reunion
Kostet wenn ich mich nicht irre kaum mehr Transistoren als bi TMUs... Hängt davon ab, wie man's macht. Heutige TMUs sind etwas aufwändiger als frühere, aber aus einer bilinearen eine trilineare zu machen ist so aufwändig nicht, da keine komplette zweite benötigt wird, sondern quasi eine "alte" reicht. Mal sehr vereinfacht gesagt :)

reunion
2003-12-01, 17:23:01
Original geschrieben von aths
Hängt davon ab, wie man's macht. Heutige TMUs sind etwas aufwändiger als frühere, aber aus einer bilinearen eine trilineare zu machen ist so aufwändig nicht, da keine komplette zweite benötigt wird, sondern quasi eine "alte" reicht. Mal sehr vereinfacht gesagt :)

Soll das heißen das eine tri TMU nichts anderes ist als zwei "zusammengeflickte" bi TMUs ???

aths
2003-12-01, 17:24:49
Original geschrieben von reunion
Soll das heißen das eine tri TMU nichts anderes ist als zwei "zusammengeflickte" bi TMUs ??? Ja und nein. Zur TMU gehört soweit ich weiß auch etwas Koordinaten-Berechnungslogik, und diese kann bei der 2. TMU sehr einfach ausfallen (einfach die Koordinaten der 1. TMU jeweils halbieren.) So kann man aus 1 und einer gestutzten TMU eine trilineare machen. Natürlich muss die Anbindung an den Cache entsprechend breiter werden.

Man könnte auch eine TMU so gestalten, dass sie mit einem 4x4-Filter single clock aus _einer_ MIP trilinear filtert. Wäre natürlich etwas aufwändiger.

Demirug
2003-12-01, 17:26:45
Original geschrieben von reunion
Soll das heißen das eine tri TMU nichts anderes ist als zwei "zusammengeflickte" bi TMUs ???

Das ist die einfachste Lösung. Wobei man bestimmte Teile einsparen kann weil man ja nur noch eine Texture addressieren muss.

Eine andere Lösung wäre Tri aus nur einer MipMap. Das ist aber aufwediger aber auch besser.

Mich persönlich würde es nicht wundern wenn wir TMUs mit 4x4 Kernel Filter sehen würden. (damit geht auch Tri aus einer MipMap)

aths
2003-12-01, 17:28:07
Original geschrieben von reunion
PS.: Wie siehts eigendlich mit 6x2 aus??? NV hat bislang noch nie "krumme" Dinger gemacht. Wo ATI mit 6x AA, 3 TMUs und FP24 aufwartet, waren bei NV nur volle Zweierpotenzen zu sehen. Ich glaube nicht an 6x2. Wäre Quad-technisch auch bisschen doof, auch wenn das mit den Quads beim PS.3.0 sowieso anders gemacht werden muss. Und wie sollten die Mainstream-Chips aussehen? 3x2? Wohl kaum :) (Deshalb glaube ich auch nicht so recht an 12x1 bei ATI. Soll der Mainstream 6 Pipes haben? Oder nur 4? Oder gleich 8?)

reunion
2003-12-01, 17:32:05
Original geschrieben von aths
Ja und nein. Zur TMU gehört soweit ich weiß auch etwas Koordinaten-Berechnungslogik, und diese kann bei der 2. TMU sehr einfach ausfallen (einfach die Koordinaten der 1. TMU jeweils halbieren.) So kann man aus 1 und einer gestutzten TMU eine trilineare machen. Natürlich muss die Anbindung an den Cache entsprechend breiter werden.

Man könnte auch eine TMU so gestalten, dass sie mit einem 4x4-Filter single clock aus _einer_ MIP trilinear filtert. Wäre natürlich etwas aufwändiger.

Dann könnte ich aber nicht mehr zwei bi Texturen pro Durchgang abarbeiten, sondern auch nurmehr eine, oder???

Was dann bedeuten würde das man mit bi Texturfilterung keine Leistungssteigerung gegenüber tri filterung erhält???

aths
2003-12-01, 17:35:16
Original geschrieben von reunion
Was dann bedeuten würde das man mit bi Texturfilterung keine Leistungssteigerung gegenüber tri filterung erhält??? Genau.

reunion
2003-12-01, 17:37:01
Original geschrieben von aths
(Deshalb glaube ich auch nicht so recht an 12x1 bei ATI.

Sondern??? :naughty:
weiterhin 8x1 bi oder 8x1 tri oder 16x1 bi oder gleich 16x1 tri...

aths
2003-12-01, 17:41:29
Original geschrieben von reunion
Sondern??? :naughty:
weiterhin 8x1 bi oder 8x1 tri oder 16x1 bi oder gleich 16x1 tri... Für 16x1 tri ist die Bandbreite nicht da. Ich rechne mit 8x1 tri oder 16x1 bi, weil es ATI ist, ganz vielleicht auch 12x1 bi.

zeckensack
2003-12-01, 19:09:53
Original geschrieben von aths
NV hat bislang noch nie "krumme" Dinger gemacht. Wo ATI mit 6x AA, 3 TMUs und FP24 aufwartet, waren bei NV nur volle Zweierpotenzen zu sehen.Und was ist mit "FX12"? :naughty:
Original geschrieben von reunion
Was dann bedeuten würde das man mit bi Texturfilterung keine Leistungssteigerung gegenüber tri filterung erhält???Ja. Na und? Wenn trilinear "schnell genug" ist, und bilinear nicht schneller ist, dann bedeutet das doch logischerweise, daß bilinear auch "schnell genug" ist :)

mapel110
2003-12-01, 19:13:12
Original geschrieben von zeckensack
Wenn trilinear "schnell genug" ist, und bilinear nicht schneller ist, dann bedeutet das doch logischerweise, daß bilinear auch "schnell genug" ist :)

dann hat man aber nicht mehr die möglichkeit, durch ein paar "trilinearspielchen" leistung zu schinden :)

btw wozu hat nvidia diese möglichkeit der tribandjustierung in ihre chips eingebaut, wenn sie diese "technologie" gleich beim nächsten neuen chip wieder verwerfen wollen(tri-TMUs verwenden)?!

aths
2003-12-01, 20:42:00
Nvidia wird auf x2 bi setzen, das ist sogut wie sicher.

Ailuros
2003-12-02, 04:32:16
(Deshalb glaube ich auch nicht so recht an 12x1 bei ATI. Soll der Mainstream 6 Pipes haben? Oder nur 4? Oder gleich 8?)

Wenn es tatsaechlich 12*1 ist, dann machen nur 8*1 fuer mainstream Sinn.

High end: 3 blocks
Mainstream: 2 blocks
Value: 1 block

Alles von unten nach oben, von der RV360 und Basis-dx9.0 als Ausgangspunkt.

ShadowXX
2003-12-02, 11:24:23
Original geschrieben von Ailuros
Wenn es tatsaechlich 12*1 ist, dann machen nur 8*1 fuer mainstream Sinn.

High end: 3 blocks
Mainstream: 2 blocks
Value: 1 block

Alles von unten nach oben, von der RV360 und Basis-dx9.0 als Ausgangspunkt.

Das macht sinn und "passt" in das bisherige Konzept von ATI.

Aber um mit 12x1 doppelt so schnell seien zu wollen, müssten es dann tri-TMUs sein....(und ebenfalls um dann mit einer nv40 mit 8x2 mithalten zu können...)

Das der r420 "echten" PS30 support hat, glaube ich inzwischen auch nicht mehr....
Ich schätze das sie über den F-Buffer und pure Rechenleistung zumindest in die nähe der PS3.0 Performace von nv kommen wollen....

Deshalb (IMHO):
r420: 12x1 Tri, PS3.0 über f-Buffer, hoher Takt (ca. 600Mhz).

Trotzdem glaube ich, dass es diesmal ATI sein wird, der immer wieder mit Chip-Revisionen nachlegen muss, um mit dem nv40 mithalten zu können...beim r500 könnte es dann anders aussehen...

J.S.Shadow

Exxtreme
2003-12-02, 11:28:56
Original geschrieben von ShadowXX
Das der r420 "echten" PS30 support hat, glaube ich inzwischen auch nicht mehr....
"Echter" PS3.0-Support? Also entweder unterstützt ein Chip PS3.0 oder nicht. Und wenn er es tut, dann ist der Support immer echt. :)

DrumDub
2003-12-02, 11:41:58
Original geschrieben von Exxtreme
"Echter" PS3.0-Support? Also entweder unterstützt ein Chip PS3.0 oder nicht. Und wenn er es tut, dann ist der Support immer echt. :)

mit echt, meint shadow xx wohl, dass es sich um ein implementierung handelt, die auch echte performance liefert... ;)

da hat hat nv momentan wohl die besseren karten, da deren cinefx-architektur schon besser auf ps 3.0 vorbereitet ist.

Exxtreme
2003-12-02, 11:43:59
Original geschrieben von DrumDub
mit echt, meint shadow xx wohl, dass es sich um ein implementierung handelt, die auch echte performance liefert... ;)

da hat hat nv momentan wohl die besseren karten, da deren cinefx-architektur schon besser auf ps 3.0 vorbereitet ist.
Ob der vermeintliche PS3.0-Support des R420 "echte" Performance liefert oder nicht, das wird sich noch früh genug herausstellen.

P.S. Das gleiche gilt für den NV40.

Hauwech
2003-12-02, 12:23:37
Wie gross duerfte denn die Akzeptanz von PS 3.0 bei den Proggern ueberhaupt sein? Freuen oder Stoehnen?
PS 2.0 wurde ja einigermassen zuegig angenommen wie es aussieht.
Um die Performance von R420 und NV40 bezueglich PS 3.0 mache ich mir eigentlich eh keine Gedanken. Zu deren Lebzeiten wird es eher keine Rolle spielen wie gut/schlecht sie ist (bis auf 3DMark-Anbeter und Fanboys natuerlich :D).

Demirug
2003-12-02, 12:51:22
Original geschrieben von Hauwech
Wie gross duerfte denn die Akzeptanz von PS 3.0 bei den Proggern ueberhaupt sein? Freuen oder Stoehnen?
PS 2.0 wurde ja einigermassen zuegig angenommen wie es aussieht.

Freude. :) 3.0 Shader sind schon praktisch. Es bleibt allerdings abzuwarten wie das Leistungsverhalten ist.

Nachdem die meisten Engines ja mit der Umstellung auf DX8 schon Shadertauglich gemacht worden sind war die erweiterung auf PS 2.0 ein leichtes. Das gleiche wird auch bei 3.0 passieren.

Um die Performance von R420 und NV40 bezueglich PS 3.0 mache ich mir eigentlich eh keine Gedanken. Zu deren Lebzeiten wird es eher keine Rolle spielen wie gut/schlecht sie ist (bis auf 3DMark-Anbeter und Fanboys natuerlich :D).

Sehe ich nicht so. Den sonst könnte ich auch behaupten das die PS 2.0 Performances der Radeon 9700 keine Rolle spielt.

Hauwech
2003-12-02, 13:01:02
Ich meinte es in dem Sinne, daß sie vernuenftig eingesetzt werden koennen, nicht nur als schmueckendes Beiwerk fuer ein paar Eyecandies.

Demirug
2003-12-02, 13:50:20
Original geschrieben von Hauwech
Ich meinte es in dem Sinne, daß sie vernuenftig eingesetzt werden koennen, nicht nur als schmueckendes Beiwerk fuer ein paar Eyecandies.

Ja da hast du natürlich recht.

Das wäre wie DOOM III auf einer GF256. ;)

aths
2003-12-02, 14:28:11
Original geschrieben von zeckensack
Und was ist mit "FX12"? :naughty:Oder FP24 für Z-Storage? Gut, gut, für einige interne Datenformate hat NV auch "krumme" Dinger gedreht.

Original geschrieben von Hauwech
Wie gross duerfte denn die Akzeptanz von PS 3.0 bei den Proggern ueberhaupt sein? Freuen oder Stoehnen?
PS 2.0 wurde ja einigermassen zuegig angenommen wie es aussieht. Wohl eher Freude. Zumal, von 1.1/1.3 zu 1.4 war es ja ein ziemlicher Schnitt. Zu 2.0 ist es nur eine Erweiterung. 3.0 ist, auf der logischen Ebene, ebenfalls nur eine Erweiterung. Will sagen, wer mit 2.0 bisschen zu tun gehabt hat, wird problemlos die 3.0-er anwenden können.

aths
2003-12-02, 14:29:22
Original geschrieben von ShadowXX
Das macht sinn und "passt" in das bisherige Konzept von ATI.Das halte ich für nicht sooo sinnig. Begründung: Der 8x1-Chip sollte wegen des geringeren Transistor-Counts höher taktbar sein. Da wäre zur 12x1-Variante kaum noch Luft.
Original geschrieben von ShadowXX
Aber um mit 12x1 doppelt so schnell seien zu wollen, müssten es dann tri-TMUs sein....(und ebenfalls um dann mit einer nv40 mit 8x2 mithalten zu können...)Für 12 trilineare TMUs ist die Bandbreite nicht da.

AlfredENeumann
2003-12-02, 15:17:39
Original geschrieben von aths
Für 12 trilineare TMUs ist die Bandbreite nicht da.


Woher kennst du den die Bandbreite die bei ATI´s nächster Karte zur Verfügung gestellt wird.

was wäre den deiner meinung an Bandbreite erforderlich, und wie müßte diese Speichermäßig realisiert werden ?

Und wieso traut man NV sowas zu und ATI nicht?

aths
2003-12-02, 15:30:54
Original geschrieben von AlfredENeumann
Woher kennst du den die Bandbreite die bei ATI´s nächster Karte zur Verfügung gestellt wird.Ich kann rechnen. Und imo davon ausgehen, dass R420 ein 256-Bit-DDR-Interface haben wird. Mit 700- oder 800-MHz-DDRx rechne ich hingegen nicht. (Was im Marketing dann ja "1400" oder "1600" "MHz" entspricht.)
Original geschrieben von AlfredENeumann
was wäre den deiner meinung an Bandbreite erforderlich, und wie müßte diese Speichermäßig realisiert werden?IMRs sind, HyperZ hin, LMA her, mit 4x2 bei 128 Bit DDR völlig ausgelastet. Die 9500 Pro mit 8x1 bei 128 Bit DDR ist extrem bandbreiten-limitiert. Das 256-Bit-Interface verträgt demzufolge bis zu 8x2 bi. 12x1 tri braucht 50% mehr Bandbreite. Gut, wenn lange arithmetische Shader eingesetzt werden, wird deutlich weniger Bandbreite gebraucht. Aber auch deutlich weniger Füllrate. Es macht keinen Sinn, der Karte Füllrate zu verschaffen die mangels Bandbreite nicht ausgenutzt werden kann.

Original geschrieben von AlfredENeumann
Und wieso traut man NV sowas zu und ATI nicht? Ich traue NV 8x2 bi zu. Entspricht bandbreitentechnisch etwa 8x1 tri. Bei 12 Pipes, 32 Bit-Rendering mit Z-Buffer fallen, um die Daten in den Framebuffer zu schreiben, 384 Bit Daten Farbe/Alpha an. Z muss ebenfalls gelesen und geschrieben werden. Auch bei 4:1-Komprimierung, und trotz HyperZ (also teilweisem Wegfall von Z-Tests) kommen da Daten zustande, die über den Bus müssen. Texture Cache hin oder her, bei 12 Pipes, also dem Arbeiten an 12 Pixeln, braucht man auch eine passende Textur-Bandbreite. Textur-Füllrate ist aber schon heute eigentlich genug da, jedenfall in Relation zur arithmetischen Rechenkraft. Ich rechne mit taktbereinigter arithmetischer Rechenkraft-Verdopplung beim R420, doch besieht man sich gebräuchliche Shader, ist da immer noch ein Missverhältnis zugunsten der "überschüssigen" Textur-Füllrate.

Konkret: Imo wird R420 weiterhin 8 Pipes haben, aber pro Pipe 2 (in Ausnahmefällen 4) arithmetische Ops (mit FP24) berechnen können. Die "praktische" Textur-Füllrate könnte bequem über trilineare TMUs gesteigert werden. Fast alles wird mindestens trilinear isotrop gefiltert, da wäre das ein netter Speed-Up. Zumal eine trilineare TMU mit relativ wenig Aufwand ausgehend von einer kompletten bilinearen TMU zu machen ist.

Wie man sieht, setze ich bei ATI eine evolutionäre Entwicklung voraus. Bislang, das stimmt natürlich, waren die Sprünge eher revolutionär, vielleicht überraschen sie mit etwas ganz anderen und meine Kristallkugel hat sich fürchterlich blamiert.

ShadowXX
2003-12-02, 15:40:04
Original geschrieben von AlfredENeumann
Woher kennst du den die Bandbreite die bei ATI´s nächster Karte zur Verfügung gestellt wird.

was wäre den deiner meinung an Bandbreite erforderlich, und wie müßte diese Speichermäßig realisiert werden ?

Und wieso traut man NV sowas zu und ATI nicht?

Juppsss...genau das frage ich mich auch immer...

Von den momentanen Chips ausgehend wird die Bandbreite nicht reichen, dass ist schon klar.
Aber ob der r420 nicht genug Bandbreite für 12x1 Tri-TMUs hat, wissen wir doch jetzt noch gar nicht.


Davon abgesehen hat es schon öfters Konstuktionen gegeben, wo die Bandbreite der Pferdefuss war (GeFore256 mit SDRam oder auch die ersten GeForce2GTS).

@Exxtreme:
ich gebe zu, dass "Echte" PS3.0, eine schlechte Bezeichnung war.
Ich meinte damit, dass ich nicht glaube das ATI die PS3.0 dediziert in die HW giesst, sondern eben über den F-Buffer und Rawpower gehen wird....

Und für meinen Teil und von dem was ich so von Demi gelesen habe, kann ich mir nicht vorstellen (bei aller liebe zu ATI) das diese Lösung dann genauso schnell ist wie die nV Lösung.
Ich kann mich natürlich irren, und der Overhead des F-Buffers und was sonst noch so an der Pipe gedreht werden muss ist vernachlässigbar.

Aber egal...wenn deine Quelle recht hat und der r420 tatsächlich ca. doppelt so schnell sein soll, werden Sie dieses bestimmt nicht über den Takt machen.

Dann eher:
a.) 16x1 Bi mit fast identischen Takten (wäre PS3.0 wohl nicht so prikelnd, wenn per F-Buffer)

oder abgespeckt:
aa.) 12x1 Bi mit leicht erhöhten Takten (->der hätte aber wohl gegen einen nv40 mit 8x2 Bi keine Chance)

b.) 8x1 Tri mit sehr hohen Takten (besser für PS3.0 per F-Buffer)

oder eben gleich

c.) 12x1 Tri mit etwas geringeren Takten als bei b.)

Und wenn die Bandbreite nicht ausreicht...was solls...auf der Verpackung sehen die theoretischen Maxwerte immer gut aus...

J.S.Shadow

P.S.
mach du doch mal einen Vorschlag aths....

ShadowXX
2003-12-02, 15:47:20
Original geschrieben von aths
Ich kann rechnen. Und imo davon ausgehen, dass R420 ein 256-Bit-DDR-Interface haben wird. Mit 700- oder 800-MHz-DDRx rechne ich hingegen nicht. (Was im Marketing dann ja "1400" oder "1600" "MHz" entspricht.)
IMRs sind, HyperZ hin, LMA her, mit 4x2 bei 128 Bit DDR völlig ausgelastet. Die 9500 Pro mit 8x1 bei 128 Bit DDR ist extrem bandbreiten-limitiert. Das 256-Bit-Interface verträgt demzufolge bis zu 8x2 bi. 12x1 tri braucht 50% mehr Bandbreite. Gut, wenn lange arithmetische Shader eingesetzt werden, wird deutlich weniger Bandbreite gebraucht. Aber auch deutlich weniger Füllrate. Es macht keinen Sinn, der Karte Füllrate zu verschaffen die mangels Bandbreite nicht ausgenutzt werden kann.


Nur weil die Füllrate nicht ausgenutzt werden kann, heisst das noch lange nicht, dass man solch einen Chip nicht baut.
Und was spricht wirklich gegen 700-800Mhz Speicher??


Ich traue NV 8x2 bi zu. Entspricht bandbreitentechnisch etwa 8x1 tri. Bei 12 Pipes, 32 Bit-Rendering mit Z-Buffer fallen, um die Daten in den Framebuffer zu schreiben, 384 Bit Daten Farbe/Alpha an. Z muss ebenfalls gelesen und geschrieben werden. Auch bei 4:1-Komprimierung, und trotz HyperZ (also teilweisem Wegfall von Z-Tests) kommen da Daten zustande, die über den Bus müssen. Texture Cache hin oder her, bei 12 Pipes, also dem Arbeiten an 12 Pixeln, braucht man auch eine passende Textur-Bandbreite. Textur-Füllrate ist aber schon heute eigentlich genug da, jedenfall in Relation zur arithmetischen Rechenkraft. Ich rechne mit taktbereinigter arithmetischer Rechenkraft-Verdopplung beim R420, doch besieht man sich gebräuchliche Shader, ist da immer noch ein Missverhältnis zugunsten der "überschüssigen" Textur-Füllrate.

Und das ist, was ich nicht glaube...."nur" die arithmetischer Rechenleistung verdoppeln wird nicht reichen, um mit dem nv40 mithalten zu können.
Vielleicht machen ATI ja auch ein 8x2 Bi Design....;D

J.S.Shadow

aths
2003-12-02, 15:49:36
Original geschrieben von ShadowXX
Von den momentanen Chips ausgehend wird die Bandbreite nicht reichen, dass ist schon klar.
Aber ob der r420 nicht genug Bandbreite für 12x1 Tri-TMUs hat, wissen wir doch jetzt noch gar nicht.Sofern es keine Wunder in der Speichertechnik gibt, weiß man das. Ich denke nicht, dass die ATI-Ingenieure ein Wunder eingeplant haben.
Original geschrieben von ShadowXX
Davon abgesehen hat es schon öfters Konstuktionen gegeben, wo die Bandbreite der Pferdefuss war (GeFore256 mit SDRam oder auch die ersten GeForce2GTS).Damals war auch noch 16-Bit-Rendering aktuell, wo die Füllrate durchaus einigermaßen ausgespielt werden konnte. Damals war auch die Frage des Transistor-Counts noch nicht sooo kritisch. ATI wird kaum einerseits FP24 nehmen, und andererseits ein paar "unnütze" TMUs verbauen. Eine Steigerung der arithmetischen Power ließe sich auch anders erreichen, indem einfach 2 arithmetische Ops pro Pipes und Takt gerechnet werden können.
Original geschrieben von ShadowXX
Ich meinte damit, dass ich nicht glaube das ATI die PS3.0 dediziert in die HW giesst, sondern eben über den F-Buffer und Rawpower gehen wird....PS.3.0 kann bisschen mehr, als >32+64 Instructions. Dazu gehören auch bedingte Sprünge. Dazu muss man sich zumindest teilweise vom quad-basierten Rendering lösen. ATI wird sich vermutlich für PS.3.0 auch mal vom Phase-Konzept lösen.

Original geschrieben von ShadowXX
Dann eher:
a.) 16x1 Bi mit fast identischen Takten (wäre PS3.0 wohl nicht so prikelnd, wenn per F-Buffer)16x1? Wieviele ROPs brauch man dann für vernünftige AA-Füllrate? (4 ROPs pro Pipe? Macht dann 64 ROPs.) Mit 16x1 rechne ich nicht. Ehe 16 Pipes kommen, müssten erst mal einige Änderungen bezüglich der Architektur erfolgen, "echte" Color-Compression wäre auch wünschenswert. Ich weiß nicht, ob R420 wirklich so fortschrittlich sein wird.

aths
2003-12-02, 15:53:51
Original geschrieben von ShadowXX
Nur weil die Füllrate nicht ausgenutzt werden kann, heisst das noch lange nicht, dass man solch einen Chip nicht baut.
Und was spricht wirklich gegen 700-800Mhz Speicher??Welcher RAM ist heute marktreif? Afaik 450, 500 MHz. Ich erwarte da keine 50%-igen Steigerungen innerhalb der nächsten 6 Monate.

Wie gesagt, ein Chip der seine Füllrate nicht ausnutzen kann, trägt überflüssige Transistoren, die man auch hätte anderswo einsetzen können. ATI will sich sicherlich nicht mit 400 MHz GPU-Taktfrequenz begnügen.


Original geschrieben von ShadowXX
Und das ist, was ich nicht glaube...."nur" die arithmetischer Rechenleistung verdoppeln wird nicht reichen, um mit dem nv40 mithalten zu können.
Vielleicht machen ATI ja auch ein 8x2 Bi Design....;D Der NV40 wird ggü. dem NV35 wohl auch "nur" doppelte arithmetische Leistung haben.

reunion
2003-12-02, 15:54:03
Original geschrieben von aths
Die 9500 Pro mit 8x1 bei 128 Bit DDR ist extrem bandbreiten-limitiert.

Und genau die Karte beweißt das sowas sehrwohl sinnmacht, immerhin hat die Karten nichtmal 9gb Speicherbandbreite und erreicht trozdem eine recht höhere Leistung

ShadowXX
2003-12-02, 16:04:59
Original geschrieben von aths
PS.3.0 kann bisschen mehr, als >32+64 Instructions. Dazu gehören auch bedingte Sprünge. Dazu muss man sich zumindest teilweise vom quad-basierten Rendering lösen. ATI wird sich vermutlich für PS.3.0 auch mal vom Phase-Konzept lösen.


Vielleicht habe ich mich blöd ausgedrückt, aber genau das wollte ich eben damit sagen....
Die jetzige HW von ATI ist eigentlich nicht für PS3.0 ausgelegt (glauben wir zumindest).
Um jetzt "schnell" PS3.0 Support einbauen zu können, erwähnte IMHO Demi mal, das es "vielleicht" eine Möglichkeit gibt, dies über den F-Buffer zu realisieren, dieses dann aber langsam sei.
->Daraus resultiert meine Annahme, dass Sie "hohe" Taktraten brauchen werden.

Aber ich gehe mit deiner Meinung konform (und nachdem ich mal kurz mit dem Windows-Taschenrechner rumgespielt habe),
das 12x1 Tri wohl doch zu viel sind...

hmmm...12x1 Tri sind zu viel....12x1 Bi wohl zu wenig.
Bleibt eigentlich nur 8x1 Tri oder 8x2 Bi.
Da der r3xx 8x1 Varianten sind, wirds dann wohl auf 8x1 Tri rauslaufen + erhöter Takt + grössere interne Caches.

Also doch nur ein NFS-U getunter r3xx....schade...


Ich weiß nicht, ob R420 wirklich so fortschrittlich sein wird.

Wird er wohl leider nicht sein.....

J.S.Shadow

aths
2003-12-02, 16:10:55
Original geschrieben von reunion
Und genau die Karte beweißt das sowas sehrwohl sinnmacht, immerhin hat die Karten nichtmal 9gb Speicherbandbreite und erreicht trozdem eine recht höhere Leistung Ja. Aber nicht proportional für den Aufwand. Die 9500 Pro wurde von ATI ja recht bald wieder rausgenommen und mit der 9600-er ersetzt. Auch die Kanadier haben nichts zu verschenken.

aths
2003-12-02, 16:15:54
Original geschrieben von ShadowXX
Die jetzige HW von ATI ist eigentlich nicht für PS3.0 ausgelegt (glauben wir zumindest).Ist auch so.
Original geschrieben von ShadowXX
Um jetzt "schnell" PS3.0 Support einbauen zu können, erwähnte IMHO Demi mal, das es "vielleicht" eine Möglichkeit gibt, dies über den F-Buffer zu realisieren, dieses dann aber langsam sei.Man baut nicht mal "schnell" 3.0-Support ein. R420 wurde entweder gleich für 3.0 geplant und designt (wovon ich ausgehe), oder 3.0 bleibt draußen.
Original geschrieben von ShadowXX
->Daraus resultiert meine Annahme, dass Sie "hohe" Taktraten brauchen werden.Taktsteigerung wird so oder so eine Rolle spielen. Je breiter die Architektur, desto ineffizienter. Beliebig weit kann man das Spielchen nicht treiben, es sei denn, man entkoppelt da die Pipeline-Blöcke richtig, dann jedoch müssen viele HW-Einheiten mehrfach ausgeführt werden. (Quasi Multicore on a single Chip. Zwei komplett unabhängige Cores braucht es nicht, aber dennoch wird es schwierig. Der arme Speicher muss z. B. adressmäßig mehr hin- und herspringen, was die Performance wieder drückt.) Das ist mit ein Grund, warum ich beim R420 einfach mit einer Verdoppelung der arithmetischen PS-Stages rechne, anstatt einer Verdoppelung der gesamten Architektur-Breite.

ShadowXX
2003-12-02, 17:02:38
Original geschrieben von aths
Ist auch so.
Man baut nicht mal "schnell" 3.0-Support ein. R420 wurde entweder gleich für 3.0 geplant und designt (wovon ich ausgehe), oder 3.0 bleibt draußen.


Dein Wort in ATIs Ohr....aber ich habe so eine Vermutung das alles ganz anders kommen wird als wir glauben....

Aber auch dann bleibt die Frage:
Wie haben sie den PS3.0 Support in den r420 "reindesigned".

Um es mal mit Ailuros zu sagen:
Ist der r420 zu 2/3 der eigentlich geplante r400, oder ist der r420 zu 3/4 ein r350.


Taktsteigerung wird so oder so eine Rolle spielen. Je breiter die Architektur, desto ineffizienter. Beliebig weit kann man das Spielchen nicht treiben, es sei denn, man entkoppelt da die Pipeline-Blöcke richtig, dann jedoch müssen viele HW-Einheiten mehrfach ausgeführt werden. (Quasi Multicore on a single Chip. Zwei komplett unabhängige Cores braucht es nicht, aber dennoch wird es schwierig. Der arme Speicher muss z. B. adressmäßig mehr hin- und herspringen, was die Performance wieder drückt.) Das ist mit ein Grund, warum ich beim R420 einfach mit einer Verdoppelung der arithmetischen PS-Stages rechne, anstatt einer Verdoppelung der gesamten Architektur-Breite.

Klingt nach längerem Überlegen sehr logisch.....

Wenn man das ganze jetzt mal nicht nur auf ATI bezieht, bedeutet das wohl, dass weder der nv40 noch der r420 wirklich die "tollen" Neuerungen werden.
Der nv40 hat zumindest (zu 99%) PS3.0 Support, wogegen ich bei ATI mir da nicht mehr so sicher bin...

J.S.Shadow

aths
2003-12-02, 17:11:46
PS.3.0-HW kann man einerseits als (teilweise stark) aufgebohrte PS.2.X-HW verstehen, oder natürlich auch völlig neu designen. So mit Shader-Arrays, die passend geschaltet werden, dass der Pipeline-Begriff praktisch seine Bedeutung verliert... möglich sind solche radikalen Neudesigns sicherlich, nur halte ich es persönlich für fraglich, ob sich das ATI oder NV auch trauen. ATIs R100, R200 und R300 waren für jeweils andere Techlevel: DX7, DX8, DX9. R420 ist weiterhin DX9. Das senkt aus meiner Sicht die Wahrscheinlichkeit eines revolutionären Chips, ich gehe von einer evolutionären Entwicklung aus. Aber natürlich kann es gut sein, dass ich mich hier völlig irre.

Demirug
2003-12-02, 18:15:00
Nur um Missverständnisse zu vermeiden. Ich hatte mal ein Verfahren entwickelt mit dem man die F-Buffer Grundidee nutzen könnte um PS 3.0 ausführen zu können. (ohne Suchfunktion aber zu faul zum suchen). Einbauen muss man das aber immer noch in den Chip. Zudem ging ich davon aus das es sich um einen F-Buffer handelt wie er in dem entsprechneden Standford Papier beschrieben ist. Ich habe aber langsam Zweifel das ATIs F-Buffer wirklich so arbeitet.

Exxtreme
2003-12-02, 19:27:46
Original geschrieben von ShadowXX

@Exxtreme:
ich gebe zu, dass "Echte" PS3.0, eine schlechte Bezeichnung war.
Ich meinte damit, dass ich nicht glaube das ATI die PS3.0 dediziert in die HW giesst, sondern eben über den F-Buffer und Rawpower gehen wird....

Ähhm, sowas wie "dedizierte PS3.0-HW" wird es wohl nicht geben. Nochmal, die PS3.0-Spezifikation schreibt nicht vor, wie die HW auszusehen hat. Es ist egal ob mit F-Buffer oder ohne. Es kann zig Implementierungsmöglichkeiten geben. Oder glaubst du, daß die aktuellen CPUs "dedizierte x86-Hardware" sind?

zeckensack
2003-12-02, 22:06:59
Das NV3x-Design ist auch nicht zu dynamischen branches fähig. Womit wir bei Null wären.

Demirug
2003-12-02, 22:32:32
Original geschrieben von zeckensack
Das NV3x-Design ist auch nicht zu dynamischen branches fähig. Womit wir bei Null wären.

Richtig, das NV30 kann es nicht es sind allerdings schon vorbereitungen dafür enthalten. Die Pipeline ist schon dafür ausgelegt das Quad sie jederzeit verlassen können und die dadurch frei werdenen Slots sofort wieder belegt werden. Es fehlt also nur noch am Ende der Pipeline ein Modul welches abhängig von Registerwerten den IP des Quads ändert. So ein Modul hat man schon ewig im Vertexbereich. Das einzige Problem was man dann noch lösen muss ist wenn die Pixel eines Quads unterschiedliche Wege gehen sollen.

Mein Tip: Quads werden auf 2 Pixel reduziert und wenn dann beide Pixel einen unterschiedlichen Programmweg gehen sollen werden beide durchlaufen und jeweils ein Pixel ausmakiert.

Quasar
2003-12-03, 00:20:59
Original geschrieben von aths
Welcher RAM ist heute marktreif? Afaik 450, 500 MHz. Ich erwarte da keine 50%-igen Steigerungen innerhalb der nächsten 6 Monate.

Zwei Dinge:

Eins (http://www.hynix.com/datasheet/eng/dram/dram_sub.jsp?RK=15&MS=511&ME=512&RAM_NAME=DDR2%20SDRAM&SUB_RAM=512M) (DDR2-800 ist angerissen und für DDR2-667 stehen schon ziemlich genaue Specs fest, dazu sind 0,11µ für die Speicherproduktion im Anrollen). Und zweitens (zumindest trifft der Punkt für mich zu) wer hat schon ernsthaft ein halbes Jahr vor Ankündigung des nV30 mit 500MHZ GPU/RAM gerechnet?

Heute sind wir ja noch nichtmal wieder dort (Gut, ATi ist mit der 9600XT da, aber die ist ein bissel einfacher gestrickt.)

ShadowXX
2003-12-03, 09:50:54
Original geschrieben von Exxtreme
Ähhm, sowas wie "dedizierte PS3.0-HW" wird es wohl nicht geben. Nochmal, die PS3.0-Spezifikation schreibt nicht vor, wie die HW auszusehen hat. Es ist egal ob mit F-Buffer oder ohne. Es kann zig
Implementierungsmöglichkeiten geben. Oder glaubst du, daß die aktuellen CPUs "dedizierte x86-Hardware" sind?

Das ist mir schon alles klar...ich wollte doch nur die "vielleicht" vorhandenen Ansätze zur Realisierung von PS3.0 bei den beiden Kontrahenten irgendwie unterscheiden....

Wie Demi eben schon erwähnte, ist zumindest die HW von nv darauf vorbereitet.
(@Demi: es sollte mehr um die Theorie gehen, nicht den technischen Hintergrund...aber trotzdem Danke für die erweiterte Erleuterung.)

Bei der ATI HW gehen fast alle davon aus, dass zumindest die r3xx HW, nicht so gut darauf vorbereitet ist.

Ich suchte deshalb nach einer möglichen Lösung für die ATI-Ing's, um PS3.0 auch auf der Grundlage der r3xx HW zu realisieren. (Da die meisten davon Ausgehen, dass der r420 mehr r350 als der "original r400" sein wird.)
Da nahm ich Demis Überlegungen als Ansatz.

Daraus resultiere dann meine Schlussfolgerung.

Inzwischen habe ich ja auch etwa umgedacht (danke aths, wobei ich auch Quasars Meinung bin, das zumindest ca. 700MHz Speicher durchaus verfügbar sein könnte (GDDR3)).

Deshalb lautet meine eigentliche Frage jetzt:

Wem steht der r420 verwandschaftlich näher?
Dem "alten (originalen) r400 Design oder dem r350 Design.

Wenn letzteres zutrifft, frage ich mich wirklich, ob ATI PS3.0 Support integrieret hat und wenn wie?

Ich bin auf jedenfall sehr gespannt, wie die PS3.0 vergleiche zwischen ATI und nV ausfallen werden....es könnte zu Umkehr dessen werden was momentan bei den PS2.0 abläuft...
Und dann wäre ATI ihre hart eroberten Marktanteile schneller wieder los, als Ihnen recht ist.

Kann natürlich auch sein, das es zum IQ-Duell wird:

ATI ohne PS3.0, dafür aber mit 8xMSAA und geringsten Geschwindigkeitseinbussen bei (sagen wir mal) 4xAA.

gegen

nV mit PS3.0 und "verschnellerten" PS2.0, aber immer noch mit den alten AA-Leichen.

AF lasse ich jetzt mal weg, da ich davon ausgehe das dort beide nicht viel ändern werden...

J.S.Shadow

Gast
2003-12-03, 09:57:13
Original geschrieben von Demirug
Richtig, das NV30 kann es nicht es sind allerdings schon vorbereitungen dafür enthalten. Die Pipeline ist schon dafür ausgelegt das Quad sie jederzeit verlassen können und die dadurch frei werdenen Slots sofort wieder belegt werden. Es fehlt also nur noch am Ende der Pipeline ein Modul welches abhängig von Registerwerten den IP des Quads ändert. So ein Modul hat man schon ewig im Vertexbereich. Das einzige Problem was man dann noch lösen muss ist wenn die Pixel eines Quads unterschiedliche Wege gehen sollen.

Mein Tip: Quads werden auf 2 Pixel reduziert und wenn dann beide Pixel einen unterschiedlichen Programmweg gehen sollen werden beide durchlaufen und jeweils ein Pixel ausmakiert.

- Muss Quad rendering nicht bleiben wegen du/dv?
- Quad Umsortierung kann man wohl machen, kostet aber dann zumindest einen extrem fetten Router oder nicht?
- Sind units nicht eh "Multi-Threaded" (zur Kompensierung der Latenzen)? Setzt "Multi-Threaded" unbedingt einen IP (instruction pointer) voraus?

Demirug
2003-12-03, 10:00:53
Ich weiss nicht ob wir das schon hatten aber es macht gerade mal wieder ein altes Gerücht die Runde.

R420 = VS aus dem gestopten R400 + 3 leicht modifizierten RV350 Pixelprozessoren @ 500 MHz

ShadowXX
2003-12-03, 10:28:51
Original geschrieben von Demirug
Ich weiss nicht ob wir das schon hatten aber es macht gerade mal wieder ein altes Gerücht die Runde.

R420 = VS aus dem gestopten R400 + 3 leicht modifizierten RV350 Pixelprozessoren @ 500 MHz

Also r420 = VS3.0 / PS2.0+ (oder langsame PS3.0) / 12x1 Bi TMUs :???:

Na, so dolle hört sich das nicht an...speziel bei "nur" 500Mhz...vielleicht liesst's sich schlechter als es dann ist...

Warum eigentlich nur die rv350 Pixelprozessoren (weil schon in 0.13?) und nicht die r350'er :???:

Wenn das wirklich das ATI-Packet sein soll, dann schätze ich den nv40 stärker ein als den r420....

J.S.Shadow

Gast
2003-12-03, 10:30:22
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A1=ind0310b&L=directxdev&D=0&I=-3#5

From: Tom Forsyth <tomf@MUCKYFOOT.COM>
Subject: Re: F-Buffer exposure on the ATI Radeon 9800 using P S2.0?

OpenGL only. And it's basically a driver-side thing anyway, not a new hardware capability. You get the same functionality and speed by splitting your shader into bits and writing intermediate results out to floating-point MRTs.

It's not an actual feature, it's what is sometimes termed a "marketing feature". You're not actually missing any functionality.

Careful about the distinction between the F-buffer as presented in the SIGGRAPH paper and the implementation. From the archives:


Richard Huddy [rhuddy@ATI.COM]:
The F-buffer works like this...

You create a shader which uses 'many' instructions, we detect that the shader cannot be executed in a single pass because it won't fit into the hardware and we decompose that shader into multiple blocks, each of which does fit into a single pass.

We store intermediate values in a float buffer, and we bind the passes together so that, as a programmer, you don't see the separate blocks being executed.

At first glance this sounds like it's going to be horrendously slow - but in fact it turns out to be fast because with long shaders you are usually shader_op-limited rather than bandwidth limited. [In fact we showed a demo of this working at the Radeon 9800 launch where the 9800 ran the same shader as a Quadro FX and the Radeon ran at about 45fps while the Quadro FX ran at around 4fps.]

It is presently only available in our OpenGL drivers - but if there is sufficient demand from DirectX programmers then we'll implement it in DirectX 9 as well.

Demirug
2003-12-03, 10:30:34
Original geschrieben von Gast
- Muss Quad rendering nicht bleiben wegen du/dv?

Nicht direkt. Man muss nur auf die Werte der entsprechenden Pixel zugreifen können. Das mit den 2 Pixel Quads war auch etwas zu vereinfacht ausgedrückt. In den Prozessor werden weiterhin 2*2 Pixel Quads eingeschleust. Diese werden dann aber in 2 Pixel Blöcke zerlegt und versetzt bearbeitet. Also zum Beispiel erst die oberen und dann die unteren zwei Pixel. Braucht man nun du oder dv stellt das kein Problem da weil man ja die entsprechenden Werte der anderen Pixel des Quads ebenfalls im Registerfile hat.

- Quad Umsortierung kann man wohl machen, kostet aber dann zumindest einen extrem fetten Router oder nicht?

Umsortiert werden muss da nichts. Es kommt höchstens dazu das einzelne Pixel ein paar Runden mehr drehen als andere aber das ist bei PS 3.0 ja sowieso zu erwarten.

Wo allerdings schon länger umsortiert wird ist bei den TMUs. Diese sortieren so um das die Textureanfragen Speicherfreundlicher werden. Beim NV35 soll diese Einheit über 170 Anfragen bearbeiten können.

- Sind units nicht eh "Multi-Threaded" (zur Kompensierung der Latenzen)? Setzt "Multi-Threaded" unbedingt einen IP (instruction pointer) voraus?

Pixelprozessoren sind sogar massive "Multi-Threaded". Beim NV35 sind über 200 "Threads" (=Pixelquads) gleichzeitig aktiv. Einen Instruction Pointer gibt es da im Prinzip schon jetzt allerdings wird dieser jedesmal am Ende der Pipeline einfach um 1 erhöht und wenn das Programmende erreicht ist verlässt der Quad die Pipeline. Was fehlt ist eine Einheit die den IP bedingt verändern kann.

reunion
2003-12-03, 12:47:25
Original geschrieben von ShadowXX
Also r420 = VS3.0 / PS2.0+ (oder langsame PS3.0) / 12x1 Bi TMUs :???:


"Leicht modifiziert" könnte auch tri TMUs bedeuten...

Na, so dolle hört sich das nicht an...speziel bei "nur" 500Mhz...vielleicht liesst's sich schlechter als es dann ist...

Naja wenn Nv wirklich 8x2 bringt, dann wäre ATI mit 12x1 bi im Nachteil mit 12x1 tri allerdings im Vorteil...

Warum eigentlich nur die rv350 Pixelprozessoren (weil schon in 0.13?) und nicht die r350'er :???:

Weil 3x R350 ca. 350Mio Transistoren mit 24x1 (Pixel x Texel) doch etwas zu viel ist...

Wenn das wirklich das ATI-Packet sein soll, dann schätze ich den nv40 stärker ein als den r420....

J.S.Shadow

Wie schon gesagt, kommt drauf an ob tri oder bi TMUs, bei 12x1 bi bräuchte NV nur 6x2, bei 12x1 tri, allerdings eine 12x2 Architektur...(natürlich jeweils bei gleichem Takt)

Demirug
2003-12-03, 12:59:28
reunion, der R350 hat ja auch zwei Pixelprozessoren.

Die 500MHZ kommen wahrscheinlich noch von der Aussage doppelt so schnell wie R300. Aber der Takt ist ja sowieso immer der Punkt mit dem grössten Fragezeichen weil diese ja immer erst relative spät genau festgelegt werden.

reunion
2003-12-03, 13:13:15
Original geschrieben von Demirug
reunion, der R350 hat ja auch zwei Pixelprozessoren.


Ich weiß ;)
Aber 3x R350 wären dann praktisch 3x2x4x1 oder eben 6x4x1 oder 24x1 ... (hab mich vielleicht etwas blöd ausgedrückt)

Die 500MHZ kommen wahrscheinlich noch von der Aussage doppelt so schnell wie R300. Aber der Takt ist ja sowieso immer der Punkt mit dem grössten Fragezeichen weil diese ja immer erst relative spät genau festgelegt werden.

Mal ne andere Frage, warum hat ATI bei R350 eigendlich nur eine bi Textureinheit pro Pipe genommen? Man hat ja damit praktisch keine Vorteil gegenüber NVs 4x2(zumindest bei tri Texturfilterung) braucht aber doppelt soviele Pipes(was ja zwangsläufig mehr Transistoren bedeutet)???

Also würden tri TMUs die Füllrate theoretisch verdoppelt, wodurch ATI eigendlich Dumm wäre weiterhin bi TMUs zu benutzten oder???

Deshalb glaube ich eher an 8x1tri oder eben 12x1 tri...

Demirug
2003-12-03, 13:28:45
Original geschrieben von reunion
Mal ne andere Frage, warum hat ATI bei R350 eigendlich nur eine bi Textureinheit pro Pipe genommen? Man hat ja damit praktisch keine Vorteil gegenüber NVs 4x2(zumindest bei tri Texturfilterung) braucht aber doppelt soviele Pipes(was ja zwangsläufig mehr Transistoren bedeutet)???

Also würden tri TMUs die Füllrate theoretisch verdoppelt, wodurch ATI eigendlich Dumm wäre weiterhin bi TMUs zu benutzten oder???

Zum einen hatte man die bi-TMUs ja noch fertig vom R200 rumliegen. Der andere Punkt ist die Bandbreite. Man kalukuliert pro BI-Sample und Takt 4 Byte Bandbreiten. Für ein TRI-Sample sind es dann schon 8 Byte. Bei 8 Samples kommt man so auf 8*8 = 64 Byte = 512 Bit = 256 Bit DDR. Da ein DDR Speicherinterface keine 100% Auslastung der Bandbreite ereichen kann hätte also bei TRI-TMUs die Bandbreite wohl nicht gereicht.

ShadowXX
2003-12-03, 13:32:58
Original geschrieben von reunion
Ich weiß ;)
Aber 3x R350 wären dann praktisch 3x2x4x1 oder eben 6x4x1 oder 24x1 ... (hab mich vielleicht etwas blöd ausgedrückt)


Mal ne andere Frage, warum hat ATI bei R350 eigendlich nur eine bi Textureinheit pro Pipe genommen? Man hat ja damit praktisch keine Vorteil gegenüber NVs 4x2(zumindest bei tri Texturfilterung) braucht aber doppelt soviele Pipes(was ja zwangsläufig mehr Transistoren bedeutet)???

Also würden tri TMUs die Füllrate theoretisch verdoppelt, wodurch ATI eigendlich Dumm wäre weiterhin bi TMUs zu benutzten oder???

Deshalb glaube ich eher an 8x1tri oder eben 12x1 tri...

Ok ok...hab nicht daran gedacht das der rv350 nur 4 Pipelines hat, der r350 aber 8...
(dann ist jetzt auch das 3xrv350 klar...)

Zu den Tri TMUs...in die Richtung habe ich zuerst gedacht, aber dann müssten Sie wahrscheinlich auf PS3.0 verzichten....es sind ja nur geringe Modifizierungen und Tri+PS3.0 würde ich eher als eine grundlegende Änderung betrachten....

Dazu kommt das Bandbreitenproblem welches aths ansprach....ich glaube zwar das es durchaus sein kann, dass es bis zum Q1/04 667MHz (oder mehr) Speicher geben können wird, aber ATI ist bei den Speichertakten schon immer etwas zurückhaltender gewesen als nV.

Ich schätze langsam, dass der r420 nur zur Überbrückng bis zum r500 durchhalten soll und dabei durchaus in Kauf genommen wird, das der nV40 dann so ca. 10-15% schneller ist.
Mann wird wahrscheinlich sehr stark auf IQ setzen....

Wobei geringe Modifikationen auch Modifikationen am AF heissen kann...oder mehr AA-Sampler...

J.S.Shadow

Sunrise
2003-12-03, 13:32:59
Die 500MHZ kommen wahrscheinlich noch von der Aussage doppelt so schnell wie R300.

Die Aussage war auch wirklich sehr geschickt gewählt.
Bei den heutigen zunehmend stärker werdenden Anforderungen an VS/PS, und dem Sprung auf 3.0, wird sich sicher nicht absolut festmachen lassen, was denn nun genau doppelt so schnell ist.

Mit einer geschätzen Transistorenzahl von 140-160 Mill. auf 0.13µm, halte ich 500MHz für realistisch. Aber wie Du schon sagtest Demi, der endgültige Takt hängt natürlich von einer Reihe von Faktoren ab.

Ailuros
2003-12-03, 15:47:34
Sign off fuer R420 ist 450MHz.

Koennte ich mit absoluter Sicherheit aus den verschiedenen "off the record" hints herauslesen dass dieser tatsaechlich 200M Transistoren hat, dann macht das ganze auch Sinn wenn man alles dazurechnet (extra instruction slots, ein pipe-block mehr etc etc.).

Wo ich stolpere ist dass 200M wiederrum zu wenig erscheinen fuer R500, oder es wurden in der Zwischenzeit ein paar Sachen reduziert die mir nicht bewusst sind...

Jetzt koennt ihr heftig weiterraten :bäh:

Ailuros
2003-12-03, 15:50:25
Dazu kommt das Bandbreitenproblem welches aths ansprach....ich glaube zwar das es durchaus sein kann, dass es bis zum Q1/04 667MHz (oder mehr) Speicher geben können wird, aber ATI ist bei den Speichertakten schon immer etwas zurückhaltender gewesen als nV.

SAMSUNG hat schon eine Bestellung bekommen fuer N Anzahl von 800MHz DDR2. Ich erwaehne mit Absicht nicht, weder die Anzahl noch den IHV.

ShadowXX
2003-12-03, 16:00:36
Original geschrieben von Ailuros
SAMSUNG hat schon eine Bestellung bekommen fuer N Anzahl von 800MHz DDR2. Ich erwaehne mit Absicht nicht, weder die Anzahl noch den IHV.

Wären mit 800Mhz DDR2 12x1 Tri machbar??

Da du den Sign-Off Speed des Chips hast, hat er wohl (zumindest irgendein) Tape-Out hinter sich.
450MHz für ein ca. 200Mio Monster ist aber nicht schlecht...


Wo ich stolpere ist dass 200M wiederrum zu wenig erscheinen fuer R500, oder es wurden in der Zwischenzeit ein paar Sachen reduziert die mir nicht bewusst sind...

und ich stolpere über diese Aussage:
bezog sich deine (vielleicht) 200Mio Angabe jetzt auf den r420 oder den r500??

J.S.Shadow

ShadowXX
2003-12-03, 16:07:42
Dann rate ich nochmals (bezogen darauf, das der r420 so um die 200Mio Transitoren hat und das Speicher in der Geschwindigkeitsordnung von ca. 800MHz durchaus verfügbar wären):

Da lt. vielen Aussagen der r420 ein "Monster" sein soll, gehe ich doch direkt auf meine Ausgangsspecs zurück:

r420= 12x1 Tri / VS3.0 / PS3.0(oder PS2.0+) / AF Identisch
+ vielleicht einen AA-Sampler mehr (pro Pipe bzw. PP)

Wäre zumindest ein Monster.....bei dem sich nV warm anzeihem müsste...auch bei "nur" 400-500MHz Coretakt.

J.S.Shadow

reunion
2003-12-03, 17:42:13
Original geschrieben von ShadowXX
Wären mit 800Mhz DDR2 12x1 Tri machbar??


800mhz DDR II mit 256-bit anbindung wäre wohl geradezu ideal für einen Chip mit 12x1 tri und ca. 450mhz Chiptakt...

Allerdings erscheint mir 12x1 tri doch etwas zu viel, der Chip könnte dann dreimal soviele tri textureinheiten pro Takt berechnen wie der jetztige R350 und hätte noch dazu einen höheren Chiptakt wodurch sich die Füllrate (wieder bei tri texturen) fast vervierfachen(!) würde! (Und damit auch die Pixel Shader performace sowie AA und AF Speed)

Das Teil würde doch selbst mit F-Buffer emulation 3.0 Shader schneller rechenen als NV mit PS3.0 Support "in Hardware" :D

Demirug
2003-12-03, 18:16:53
Original geschrieben von reunion
(Und damit auch die Pixel Shader performace sowie AA und AF Speed)

AF: Ja wobei die Frage wäre ob nur Tri AF oder auch BI AF.
AA: Wie das?
PS: Aber nur wenn der Shader fillrate limitiert ist. Einem aufgrund von Rechenleistung limitierten Shader nutzen tri-TMUs nichts.

Das Teil würde doch selbst mit F-Buffer emulation 3.0 Shader schneller rechenen als NV mit PS3.0 Support "in Hardware" :D

Auch wenn es nicht ganz ernst gemeint ist.

Das Leistungverhalten von 3.0 Shader wird weniger von der Fillrate als von anderen Dingen abhängen. Wenn man es mit richtige 3.0 Shader zu tun hat.

Xmas
2003-12-03, 18:40:59
Geht man vom Taktverhältnis der R9800XT sowie 12x1 bei 450MHz, so kommt man auf ziemlich genau 600MHz RAM-Takt.

aths
2003-12-03, 21:28:53
Original geschrieben von Xmas
Geht man vom Taktverhältnis der R9800XT sowie 12x1 bei 450MHz, so kommt man auf ziemlich genau 600MHz RAM-Takt. 12x1 bi? Dann nach wie vor mit einer T-Op und einer A-Op-Stage pro Pipe? (Pro Takt 12 T und 12 A.)
Da wäre der NV40 mit 8x2 bit ziemlich überlegen, nicht? (Pro Takt 16 T und 8 A, oder 16 A.)

Demirug
2003-12-03, 21:36:15
Original geschrieben von aths
12x1 bi. Und dann nach wie vor mit einer T-Op und einer A-Op-Stage pro Pipe? (Pro Takt 12 T und 12 A.)
Da wäre der NV40 mit 8x2 bit ziemlich überlegen, nicht? (Pro Takt 16 T und 8 A, oder 16 A.)

Du hast vergessen das die R300 Serie die eine A-Op (Vector4) auch in zwei A-Ops splitten kann (Vector3 + Skalar)

aths
2003-12-03, 21:42:14
Original geschrieben von Demirug
Du hast vergessen das die R300 Serie die eine A-Op (Vector4) auch in zwei A-Ops splitten kann (Vector3 + Skalar) Ich denke, sowas ähnliches kann CineFX2 auch?

Demirug
2003-12-03, 21:53:59
Original geschrieben von aths
Ich denke, sowas ähnliches kann CineFX2 auch?

Nach Rückfrage bei nVidia ist das nur bei FX12 Berechnungen möglich. Bei den FP-Berechnungen ist das nicht vorgesehen. Das Hauptproblem scheint dabei der Schreibzugriff auf das Registerfile zu sein. Da sind wohl wieder einmal die Transitoren ausgegangen den im Prinzip ist der Shadercore gut für das Splitten vorbereitet. Neben 3-1 wäre auch 2-2 denkbar. Mit dem NV40 wird man hoffentlich ein bischen nachrüsten.

aths
2003-12-03, 22:01:43
Das lässt die Rohleistung natürlich ein wenig anders aussehen... wie wahrscheinlich schätzt du die Möglichkeit ein, eine Vektor3- und eine Skalar-Op gleichzeitig auszuführen?

Demirug
2003-12-03, 22:27:17
Original geschrieben von aths
Das lässt die Rohleistung natürlich ein wenig anders aussehen... wie wahrscheinlich schätzt du die Möglichkeit ein, eine Vektor3- und eine Skalar-Op gleichzeitig auszuführen?

Ein paar Möglichkeiten findet man immer allerdings gibt es für das getrennte ausführen noch ein paar zusätzliche Vorraussetzungen. Es wird immer dann kritisch wenn man den Alphawert im Vektorteil braucht oder einen Wert aus dem Vektorteil im Skalarteil nutzen möchte bzw beim schreiben die beiden Einheiten kreuzen muss. Das ist aber alles Sache des Treibers bzw des Compilers.

Je länger ein Shader dabei ist desto höher die Wahrscheinlichkeit. Interesant ist es aber sowieso nur wenn man einen rechenlastigen Shader hat. Bei Texturlastigen wird ja sowieso Rechenleistung verschenkt. Die Verwendung von hochwertigen Texturfiltern verstärkt diesen Effekt noch.

zeckensack
2003-12-03, 22:48:59
Original geschrieben von Demirug
Du hast vergessen das die R300 Serie die eine A-Op (Vector4) auch in zwei A-Ops splitten kann (Vector3 + Skalar) Und noch mehr. Laut diesem Thread (http://www.beyond3d.com/forum/viewtopic.php?t=8005) gibt's pro 'Pipe' zwei Vektor- und zwei Skalar-Einheiten.

Das hatte ich schonmal verlinkt, und 'damals' kamen Zweifel an der Glaubwürdigkeit auf. Nun, die ATI-Angestellten, die in dem Thread schreiben, bestätigen durch ihre Aussagen das R350-Diagramm. Von daher würde ich das schon als gültig ansehen.

Demirug
2003-12-03, 23:04:53
Original geschrieben von zeckensack
Und noch mehr. Laut diesem Thread (http://www.beyond3d.com/forum/viewtopic.php?t=8005) gibt's pro 'Pipe' zwei Vektor- und zwei Skalar-Einheiten.

Das hatte ich schonmal verlinkt, und 'damals' kamen Zweifel an der Glaubwürdigkeit auf. Nun, die ATI-Angestellten, die in dem Thread schreiben, bestätigen durch ihre Aussagen das R350-Diagramm. Von daher würde ich das schon als gültig ansehen.

Kenn ich doch. Es gibt aber auch die Aussage das die beiden zusätzlichen Einheiten bei PS 2.0 überhaupt nicht eingesetzt werden. Daher scheint es mir fast so als ob man diese Einheiten primär dafür braucht um die komplexen PS 1.X Operationen auszuführen. Ich meine damit die Register Modifiers die bei den 2.0 Shadern ja weitgehen zusammengestrichen wurden.

Demirug
2003-12-03, 23:39:41
@aths: Das mit dem verschenken von Rechenleistung bei hochwertigen Texture Filter war wie folgt gemeint.


R300

TMU : 1 1 1 1 2 2 2 2 3 3 3 3 4 4 4 4
Tex : X X X X O O O O O O O O O O O O
Vec3 : X X X X X X X X X X X X X X X X
Skalar: X X X X X X X X X X X X X X X X

16 Vec3 + 16 Skalar

NV35 (FP-Mode)

TMU1 : 1 1 1 1 3 3 3 3
TMU2 : 2 2 2 2 4 4 4 4
SC : TT TT V4 V4 V4 V4 V4 V4
RC : V4 V4 V4 V4 V4 V4 V4 V4

14 Vec4

NV35 (FX-Mode)

TMU1 : 1 1 1 1 3 3 3 3
TMU2 : 2 2 2 2 4 4 4 4
SC : TT TT V4 V4 V4 V4 V4 V4
RC V3 : X X X X X X X X
RC S : X X X X X X X X
RC V3 : X X x X X X X X
RC S : X X X X X X X X

16*V3(FX) + 16*S(FX) + 6*Vec4(FP)

Das sind Nutzungsdiagramme für einen Shader der 4 2xAF tri Sample braucht.

Der R300/R350 benötigt dafür 16 Takte. Der NV35 braucht nur 8 erzeugt aber auch nur die Hälfte der Pixel dabei.

Jeder Shader der nun weniger als die angebene Anzahl von Takten zum Rechnen braucht ist Fillrate dominiert und es wäre sinnloss zu versuchen Rechenanweisungen einzusparen.

Beim R300 sind also auf jeden Fall 16 Anweisungen möglich und abhängig davon wie gut das Splitten funktioniert bis zu 32.

Beim NV35 hängt es vom Operationsmodus ab. Für einen reinen FP Shader stehen 14 Vec4 Ops zur Verfügung. Bei einem Shader welcher auch FX benutzt ergibt sich ein ähnliches Bild wie beim R300 mit dem Unterschied das beim NV35 noch 6 zusätzliche FP Ops zur Verfügung stehen würden.

Ergo: Rechenoperationen und Filteroperationen sollten aufeinader abgestimmt werden.

Ailuros
2003-12-04, 04:04:41
Geht man vom Taktverhältnis der R9800XT sowie 12x1 bei 450MHz, so kommt man auf ziemlich genau 600MHz RAM-Takt.

Hehehe. Ich sagte ja dass ich NICHT den IHV bei der Ram-Bestellung definiert habe.

a) Eine Bestellung sagt nicht viel wenn der Lieferant momentan immer noch Lieferungsprobleme hat.

b) Bestellter Speicher mit finaler Taktung kann einen kleinen Unterschied haben.

c) (irrelevant zu (a) & (b)) Oben erwaehnte Taktrate ist sign-off nicht final.

Wäre zumindest ein Monster.....bei dem sich nV warm anzeihem müsste...auch bei "nur" 400-500MHz Coretakt.

*your love keeps lifting me higher and higher...* :D

Da du den Sign-Off Speed des Chips hast, hat er wohl (zumindest irgendein) Tape-Out hinter sich.

Also tape-outs bei naechster Generation chips sind wohl schon alte news, nur wurde diesmal nicht so stark darueber getrommelt. Ist auch besser so.

bezog sich deine (vielleicht) 200Mio Angabe jetzt auf den r420 oder den r500??

I wish I knew myself heh. For the record R5xx@11nm.

ShadowXX
2003-12-04, 09:01:33
Laut www.TweakPC.de (http://www.tweakpc.de/mehr_all.php?news_id=4797&s=0&s1=12), plant ATI entgegen dein meisten Meinungen doch auf 32Bit genauigkeit umzustellen.

Es wird allerdings nicht ganz klar, ob es schon im r420 oder erst der r500 realisiert wird.

Wievile Transis würde es kosten von 24- auf 32Bit aufzurüsten??

Wenn das schon im r420 realisiert wird, dann würde ich von 12x1 Tri doch auf 8x1 Tri zurückgehen.
Dazu dann 600MHz Speicher + VS3.0 / PS2.0+ (oder 3.0).

Langsam wirds ein Kopf an Kopf rennen mit dem nv40, da die beiden sich im theoretischen Output immer weniger unterscheiden...(Ich schätze mal, dass sich auch der Coretakt der beiden nicht viel nehmen wir...)

Ob nun 8x2 Bi (nv) oder 8x1 (Tri) wird sich wohl auch nicht viel nehmen...
Ati verbessert das AF leicht....nV das AA.....

Die beiden Chips wirken langsam wie von der gleichen "Mutter", aber mit verschiedenen "Vätern".

Kommt zum Schluss bestimmt wieder auf den Shaderspeed der beiden an....

J.S.Shadow

Crushinator
2003-12-04, 12:34:19
^^ Ich würde mir PS 3.0 und damit FP32 aus dem Kopf schlagen, das paßt nicht mehr in den R420 rein. 12x1 * könnte man dagegen schon fast als gesichert annehmen. Setz' Dir einfach ein Limit von etwas über 180 mil. Transis und rechne aus, was da auf ATi-Art rein paßt. =)

ShadowXX
2003-12-04, 12:45:24
Original geschrieben von crushinator
^^ Ich würde mir PS 3.0 und damit FP32 aus dem Kopf schlagen, das paßt nicht mehr in den R420 rein. 12x1 * könnte man dagegen schon fast als gesichert annehmen. Setz' Dir einfach ein Limit von etwas über 180 mil. Transis und rechne aus, was da auf ATi-Art rein paßt. =)

Die Aussage mit den 32-Bit ist nicht von mir, sondern vom ATI-Chef David Orton.


In einem Gespräch mit PC-Watch deutete ATI-Chef David Orton darauf hin, dass demnächst Pixel-Shader von ATI Grafikkarten intern mit 32-bit Genauigkeit rechnen werden.


J.S.Shadow

Crushinator
2003-12-04, 13:48:05
Original geschrieben von ShadowXX
Die Aussage mit den 32-Bit ist nicht von mir, sondern vom ATI-Chef David Orton. Ja nun, das deckt sich nur in sofern mit der Aussage von SirEric (http://www.rage3d.com/?node=getarticle&u=content/interviews/ATIHardwareChat/), daß sie's irgendwann tun werden: (Ach was :D)

<SirEric> We currently support 32b (and more) throughout the pipeline, where it is required. For example, textures and render surfaces can be 32b per component.

<SirEric> In the pixel ALU pipe, we currently support 24b, which is DX9 standard. We make our engineering decisions based on "bang for your buck" and industry standards. We feel very good about all our decisions.

<SirEric> In the future, as transistor costs go down, we will revisit all our designs and decisions, and again make balanced selections. IMHO ist der Zug für "decisions" bezüglich R420 schon abgefahren, und sie haben sich wieder mal für BruteForce durch Redundanz der Shadereinheiten entschieden. Die einzig interessante Frage ist eigentlich, wie sie AF implementiert haben. Es wäre jedenfalls eine Schande wenn bei der anzunehmenden Füllrate immer noch winkelabhängig bilinear oder viel weniger anisotrop gefiltert würde.

ShadowXX
2003-12-04, 14:00:56
Original geschrieben von crushinator
Ja nun, das deckt sich nur in sofern mit der Aussage von SirEric (http://www.rage3d.com/?node=getarticle&u=content/interviews/ATIHardwareChat/), daß sie's irgendwann tun werden: (Ach was :D)
IMHO ist der Zug für "decisions" bezüglich R420 schon abgefahren, und sie haben sich wieder mal für BruteForce durch Redundanz der Shadereinheiten entschieden. Die einzig interessante Frage ist eigentlich, wie sie AF implementiert haben. Es wäre jedenfalls eine Schande wenn bei der anzunehmenden Füllrate immer noch winkelabhängig bilinear oder viel weniger anisotrop gefiltert würde.

Ich hoffe mal das es wirklich ein 12x1 Tri (oder von mir aus 8x1 Tri) Design ist...dann fällt zumindest schonmal der Teil mit der teilweisen Bi-Filterung weg.

Aber das Sie die AF-Winkel nochmal aufbohren glaube ich nicht("Bang for the Buck")...vielleicht beim r500.

J.S.Shadow

Crushinator
2003-12-04, 14:09:23
Original geschrieben von ShadowXX
(...) Aber das Sie die AF-Winkel nochmal aufbohren glaube ich nicht("Bang for the Buck")...vielleicht beim r500. Sie könnten die Winkelabhängigkeit ja wenigstens auf dasselbe AF-Niveau der NV3X bringen.

Winter[Raven]
2003-12-04, 14:46:37
Original geschrieben von crushinator
Sie könnten die Winkelabhängigkeit ja wenigstens auf dasselbe AF-Niveau der NV3X bringen.

Ja, KÖNNTEN, ob sie es dann machen ist fraglich, die paar % wird Ati wichtiger sein *fg*. Den wares bis jetzt auch egal wieso sollte es sich ändern ?

ShadowXX
2003-12-04, 15:34:01
Original geschrieben von Winter[Raven]
Ja, KÖNNTEN, ob sie es dann machen ist fraglich, die paar % wird Ati wichtiger sein *fg*. Den wares bis jetzt auch egal wieso sollte es sich ändern ?

Da könnte man aber auch als Gegenargument bringen, das Sie das Adaptive AF bis jetzt bei jeder Generation verbessert haben...

Wir werden sehen...ich sehe beide Chips momentan im "relativen" Gleichstand.
Hängt viel davon ab, wie "gut"(=schnell) nV das PS3.0 hinbekommt und ob ATI es überhaupt einbaut....

Denn falls der r420 wirklich kein PS3.0 hat, werden die vergleiche zwischen den Karten noch schwerer als es jetzt schon ist.

J.S.Shadow

Ailuros
2003-12-04, 15:37:27
Original geschrieben von ShadowXX
Laut www.TweakPC.de (http://www.tweakpc.de/mehr_all.php?news_id=4797&s=0&s1=12), plant ATI entgegen dein meisten Meinungen doch auf 32Bit genauigkeit umzustellen.

Es wird allerdings nicht ganz klar, ob es schon im r420 oder erst der r500 realisiert wird.

Wievile Transis würde es kosten von 24- auf 32Bit aufzurüsten??

Wenn das schon im r420 realisiert wird, dann würde ich von 12x1 Tri doch auf 8x1 Tri zurückgehen.
Dazu dann 600MHz Speicher + VS3.0 / PS2.0+ (oder 3.0).

Langsam wirds ein Kopf an Kopf rennen mit dem nv40, da die beiden sich im theoretischen Output immer weniger unterscheiden...(Ich schätze mal, dass sich auch der Coretakt der beiden nicht viel nehmen wir...)

Ob nun 8x2 Bi (nv) oder 8x1 (Tri) wird sich wohl auch nicht viel nehmen...
Ati verbessert das AF leicht....nV das AA.....

Die beiden Chips wirken langsam wie von der gleichen "Mutter", aber mit verschiedenen "Vätern".

Kommt zum Schluss bestimmt wieder auf den Shaderspeed der beiden an....

J.S.Shadow

Es gibt auch andere Methoden auf single cycle trilinear zu kommen die umstaendlicher aber vielleicht sogar billiger sind in HW. ATI aeusserst sich nicht zum Thema und die andere Seite empfindet es wohl als HW-Verschwendung - go figure....

12*1 bi, FP32, PS/VS3.0 (ich meine nur die instruction slots fuer PS) passen mehr oder weniger in die 200M rein.

Mir waere um vieles wichtiger wieviele arithmetic ops pro Takt jeder chip ausfuehren kann als andere oede Zahlen, ueberhaupt pipelines...

Ailuros
2003-12-04, 15:42:13
Original geschrieben von ShadowXX
Da könnte man aber auch als Gegenargument bringen, das Sie das Adaptive AF bis jetzt bei jeder Generation verbessert haben...

Wir werden sehen...ich sehe beide Chips momentan im "relativen" Gleichstand.
Hängt viel davon ab, wie "gut"(=schnell) nV das PS3.0 hinbekommt und ob ATI es überhaupt einbaut....

Denn falls der r420 wirklich kein PS3.0 hat, werden die vergleiche zwischen den Karten noch schwerer als es jetzt schon ist.

J.S.Shadow

Die Winkel-Abhaengigkeit komplett loszuwerden, wuerde aber single cycle tri vorraussetzen, sonst gewinnt man mehr Fuellrate theoretisch (wenn man 3 blocks akzeptiert) und verliert diesen Gewinn gleich wieder wenn man auf keine Winkel-Abhaengigkeit setzt.

Ich hab wirklich keine Ahnung, ich frage mich sogar ob man bei der AF-"Rosette" sogar noch auf "seltenere" Winkel tunen kann. Das wuerde dann schon eher nach ATI klingen, wenn sowas ueberhaupt moeglich ist.

ShadowXX
2003-12-04, 15:46:17
Original geschrieben von Ailuros
Es gibt auch andere Methoden auf single cycle trilinear zu kommen die umstaendlicher aber vielleicht sogar billiger sind in HW. ATI aeusserst sich nicht zum Thema und die andere Seite empfindet es wohl als HW-Verschwendung - go figure....

12*1 bi, FP32, PS/VS3.0 (ich meine nur die instruction slots fuer PS) passen mehr oder weniger in die 200M rein.

Mir waere um vieles wichtiger wieviele arithmetic ops pro Takt jeder chip ausfuehren kann als andere oede Zahlen, ueberhaupt pipelines...

Aber meinst du, dass ATI mit diesen Daten gegen einen 8x2 Bi nv40 gegenhalten kann??

Aber natürlich hast du recht:
Die arithmetic ops pro Takt sollte man wirklich nicht ausser Acht lassen....

Wenn wird es denn die ersten "halbwegs genauen" Gerüchte so geben...Januar?

J.S.Shadow

Crushinator
2003-12-04, 15:51:51
Original geschrieben von Winter[Raven]
Ja, KÖNNTEN, ob sie es dann machen ist fraglich, die paar % wird Ati wichtiger sein *fg*. Den wares bis jetzt auch egal wieso sollte es sich ändern ? :kratz2: Das hört sich irgendwie an wie DirectX 3.0 war schon für den Hintern und es wird auch in Zukunft so bleiben, und was ich von solchen Aussagen halte, ist es nicht wert ausgesprochen zu werden.

ShadowXX
2003-12-04, 16:09:39
Original geschrieben von Ailuros
Die Winkel-Abhaengigkeit komplett loszuwerden, wuerde aber single cycle tri vorraussetzen, sonst gewinnt man mehr Fuellrate theoretisch (wenn man 3 blocks akzeptiert) und verliert diesen Gewinn gleich wieder wenn man auf keine Winkel-Abhaengigkeit setzt.

Ich hab wirklich keine Ahnung, ich frage mich sogar ob man bei der AF-"Rosette" sogar noch auf "seltenere" Winkel tunen kann. Das wuerde dann schon eher nach ATI klingen, wenn sowas ueberhaupt moeglich ist.

Vielleicht machen Sie es ja nach dem Motto:
Drei Stricken, einen Fallenlassen ;D ;D

Aber mal im ernst:
Da die ATI Ing's ja scheinbar auf "krumme" Dinger stehen, würde mich auch so etwas nicht mehr Wundern
("Was?...33,876 Grad ist nicht so toll...hmmm...wollen wir dann 41,543 nehmen?")

J.S.Shadow

Ailuros
2003-12-04, 16:26:09
Original geschrieben von ShadowXX
Aber meinst du, dass ATI mit diesen Daten gegen einen 8x2 Bi nv40 gegenhalten kann??

Aber natürlich hast du recht:
Die arithmetic ops pro Takt sollte man wirklich nicht ausser Acht lassen....

Wenn wird es denn die ersten "halbwegs genauen" Gerüchte so geben...Januar?

J.S.Shadow

Man sollte Silizium bei allen naechster Generation chips Anfang 2004 erwarten.

Ankuendigungen kommt dann etwa einen Monat vor Veroeffentlichung.

Wenn Mufu nichts genaueres herausbekommt dann hab ich wohl auch keine Chancen.

Ich halte mich zurueck vor jedem Vorurteil was alle drei betrifft, bevor ich unabhaengige Tests/Analysen lesen kann. Zahlen auf Papier sagen mir in alle drei Faellen voruebergehend gar nichts, deshalb ist auch diese unendliche Zahlen-raterei IMO eher nutzlos.

Teufel selbst ATI z.B. kann nur schaetzen was NVIDIA moeglicherweise auftischen koennte und auch andersrum. Man kann hier nur daraus ausgehen dass ATI wohl diesmal nicht so viel an Transistoren sparen wollte; nachdem die Sintflut.

Demirug
2003-12-04, 16:30:22
Original geschrieben von Ailuros
Teufel selbst ATI z.B. kann nur schaetzen was NVIDIA moeglicherweise auftischen koennte und auch andersrum. Man kann hier nur daraus ausgehen dass ATI wohl diesmal nicht so viel an Transistoren sparen wollte; nachdem die Sintflut.

Wobei es ATI und nVidia leichter haben dürften als wir da sie doch Vertreter von beide zum Teil in den gleichen Sitzungen aufhalten. Das Verhalten der Gegenseite lässt dann schon gewisse Rückschlüsse zu.

Ailuros
2003-12-04, 16:32:57
Original geschrieben von ShadowXX
Vielleicht machen Sie es ja nach dem Motto:
Drei Stricken, einen Fallenlassen ;D ;D

Aber mal im ernst:
Da die ATI Ing's ja scheinbar auf "krumme" Dinger stehen, würde mich auch so etwas nicht mehr Wundern
("Was?...33,876 Grad ist nicht so toll...hmmm...wollen wir dann 41,543 nehmen?")

J.S.Shadow

Ich dachte eher an 4 Winkel anstatt 2 bei R3xx.

Ich weiss dass es dumm klingt, aber nur Demi koennte uns sagen ob sowas ueberhaupt noch moeglich ist.

Bei R2xx wurde bei 45 Grad reduziert (1 Winkel)
R3xx wurde bei ~22 und ~67 Grad reduziert (2 Winkel)...

...

~11,~33, ~56, ~78 (4 Winkel)

Macht mir selber aber keinen Sinn...

Ailuros
2003-12-04, 16:34:55
Original geschrieben von Demirug
Wobei es ATI und nVidia leichter haben dürften als wir da sie doch Vertreter von beide zum Teil in den gleichen Sitzungen aufhalten. Das Verhalten der Gegenseite lässt dann schon gewisse Rückschlüsse zu.

Deshalb halten sie auch so hartnaeckig dicht. Das und natuerlich auch die verstaendliche Moeglichkeit einer Wiederholung von "disasters" der Vergangenheit....

Demirug
2003-12-04, 16:45:10
Original geschrieben von Ailuros
Ich dachte eher an 4 Winkel anstatt 2 bei R3xx.

Ich weiss dass es dumm klingt, aber nur Demi koennte uns sagen ob sowas ueberhaupt noch moeglich ist.

Bei R2xx wurde bei 45 Grad reduziert (1 Winkel)
R3xx wurde bei ~22 und ~67 Grad reduziert (2 Winkel)...

...

~11,~33, ~56, ~78 (4 Winkel)

Macht mir selber aber keinen Sinn...

Anders herum wird ein Schuh daraus. Du darfst nicht darauf achten wo reduziert wurde sondern musst die Winkel betrachten die voll gefiltert werden.

Für AF ist die Berechung von Vektorlängen erforderlich. Mathematisch braucht man dazu normalerweise eine Wurzelfunktion. Wurzelfunktionen sind aufwendig. Bei einer CPU lässt man sich deswegen auch mehrer Takte Zeit dafür. Eine GPU kann sich diesen Luxus nicht erlauben. Will man nun keine Wurzelfunktion einbauen braucht man eine Näherung. Die einfachste Form bringt nur bei 0, 90°, ... die richtige Länge und hat bei 45°, 135°, ... die grösste Abweichung. Eine verbesserte Näherung bringt nun bei 0, 45°, 90°, 135°, ... die richtige Länge und wiederum genau dazwischen die grösste Abweichung. Will man die Winkelabhänigkeit weiter reduzieren braucht man eine Näherung die noch genauer ist oder muss eben entgültig auf die Wurzelfunktion umsteigen.

aths
2003-12-04, 17:29:41
Original geschrieben von Ailuros
Ich dachte eher an 4 Winkel anstatt 2 bei R3xx.

Ich weiss dass es dumm klingt, aber nur Demi koennte uns sagen ob sowas ueberhaupt noch moeglich ist.

Bei R2xx wurde bei 45 Grad reduziert (1 Winkel)
R3xx wurde bei ~22 und ~67 Grad reduziert (2 Winkel)...

...

~11,~33, ~56, ~78 (4 Winkel)

Macht mir selber aber keinen Sinn... Eher erhoffe ich eine Verbesserung derart, dass die vernachlässigten Winkel bei 16° noch mindestens 4° statt 2° AF bekommen.

aths
2003-12-04, 17:35:20
Original geschrieben von ShadowXX
Da lt. vielen Aussagen der r420 ein "Monster" sein soll, gehe ich doch direkt auf meine Ausgangsspecs zurück:

r420= 12x1 Tri / VS3.0 / PS3.0(oder PS2.0+) / AF Identisch
+ vielleicht einen AA-Sampler mehr (pro Pipe bzw. PP)Für 12x1 tri ist die Bandbreite nicht da.

Crushinator
2003-12-04, 17:53:13
Original geschrieben von aths
Für 12x1 tri ist die Bandbreite nicht da. Wie jetzt? Reicht etwa auch 800 MHz DDR2 nicht aus? :???:

Hauwech
2003-12-04, 17:54:56
Gab/gibt es nicht jemanden der sich CMD_Kernel oder nennt? Wenn ich mich recht entsinne, hat dieser anscheinend einen recht guten Draht oder kennt die richtigen Leute was Tape-outs angeht? Jemand mal was von diesem Herren gehoert/gelesen?

Xmas
2003-12-04, 23:05:21
CMKRNL und es ist eine sie AFAIK.

Höhnangst
2003-12-05, 00:48:10
Original geschrieben von aths
Für 12x1 tri ist die Bandbreite nicht da.
Aber mal abgesehen von dem Gleichgewicht zwischen Bandbreite und Füllrate, müsste der Leistungsverlust bei (hohem) AF-Einsatz demnach nicht viel geringer sein, wenn man mit 12x1 tri arbeitet? Man hätte ja dann soz. einen "Füllratenüberschuss", aus dem man schöpfen könnte.

Und ich denke, das sollte die Situation besonders dann verbessern, wenn ATi die AF-Optimierung (im R420) noch weiter entschärft und mehr Winkel höher filtert.

Ailuros
2003-12-05, 04:01:29
Original geschrieben von crushinator
Wie jetzt? Reicht etwa auch 800 MHz DDR2 nicht aus? :???:

Die Bestellung ist fuer NV *seufz*...also nach mehr als zwei Versuchen muesste man wohl verstehen koennen dass damit nicht ATI gemeint war. Target ist je nach Erfolg 700-750MHz ergo bis zu ~48GB/sec Bandbreite.

Ailuros
2003-12-05, 04:09:20
Original geschrieben von aths
Für 12x1 tri ist die Bandbreite nicht da.

Ich hab keine Ahnung wieviel Bandbreite R420 haben wird und ich erwarte auch nicht dass sie bei 3-way hierarchical Z stecken bleiben.

Mal angenommen 12bi texture ops vs 16bi texture ops, wo braucht man theoretisch in dem Fall mehr Bandbreite? Egal welche Antwort ohne die wahre Effizienz und den ganzen Aufbau beider Architekturen zu wissen, sind solche Spekulationen sowieso sinnlos.

Gast
2003-12-05, 07:47:42
Original geschrieben von Xmas
CMKRNL und es ist eine sie AFAIK.

Was ist eigentlich aus ihr geworden?

Sie hat früher sehr häufig auf Beyond3D gepostet und die Informationen zu Tape-outs waren fast immer sehr genau.

Das selbe frage ich mich aber bei SA. Was wohl aus dem geworden ist?

ShadowXX
2003-12-05, 08:53:12
Original geschrieben von Ailuros
Die Bestellung ist fuer NV *seufz*...also nach mehr als zwei Versuchen muesste man wohl verstehen koennen dass damit nicht ATI gemeint war. Target ist je nach Erfolg 700-750MHz ergo bis zu ~48GB/sec Bandbreite.

Das hatte ich mir durchaus gedacht, da ATI bei Speicher-Taktraten ja immer etwas "vorsichtiger" war...und bin deshalb nicht weiter darauf eingegangen...

Da nV ganz gerne mit Speicherbandbreite um sich wirft, gehe ich mal davon aus, das zumindest 8x2 Bi mit ca. 700MHz machbar sind...und damit auch 8x1 Tri.

Wobei ich inzwischen glaube, das ATI lieber PS3.0 einbauen wird, als Tri TMUs...
Und beides zusammen währe wohl zuviel für ca. 180Mio Transtoren (zumindest bei 12x1 Tri).

Ausserdem sind 12x1 Tri mit weniger als 800Mhz Speicher wohl definitiv nicht drinne...damit hat aths wohl recht.

Gerade bei PS3.0...und ich gehe inzwischen davon aus das der r420 PS3.0 haben wird...kommt es stark auf die ops/sec an. Vielleicht werden Sie dort nochmals ansetzen.

Und als Endprodukt dann:
12x1 Bi, PS/VS3.0 (wie auch immer implementiert) ,450MHz/600MHz.
AF bleibt wie es ist und AA wahrscheinlich auch (vielleicht einen Loop mehr (x8) oder sogar einen weitern AA Sampler würde ich ihnen aber durchaus zutrauen).

Das liesst sich zwar auf den ersten Blick nicht sonderlich spektakulär, aber gegen die Paper-Specs des nv30 lass sich der r300 auch nicht gerade spektakulär.

Wahrscheinlich hat Ailuros recht und es wird sich über die ops/sec der PixelShader entscheiden...

Da ich nicht weiss, eine wie starke "Notlösung", der r420 in wirklichkeit ist, kann man auch nur abschätzen inwieweit ATI wirklich auf Teufel komm raus mit nV um jeden Frame mithalten will....

Man stelle sich folgende Situation vor:

Von der Rohpower (Fillrate/Bandbreite) ist der nv40 wieder überlegen....die Shader sind Architekturbedingt etwas Langsamer (PS2.0) bzw. etwas schneller (PS3.0).
Aber nV benutzt weiterhin das alte AA Schema..upgedatet durch 32xOGSSAA (;D).

Die ATi hat weniger Fillrate und Bandbreite, aber Sie haben pro "Pipe" einen weiteren AA-Sampler und dazu noch verbesserte AF (in welcher Form auch immer).

Dann könnte die Unterschiede zwischen, "wir benchen mit AA" und "wir Benchen ohne AA", ziemlich extrem werden.

Speziell wenn das AF bei beiden dann auch noch ziemlich gleichwertig und schnell ist.

Könnte spannend werden....

J.S.Shadow

seahawk
2003-12-05, 09:45:18
Beim AA wird NV was ändern ...

ShadowXX
2003-12-05, 11:37:56
Original geschrieben von seahawk
Beim AA wird NV was ändern ...

Hoffen wir mal, dass das nicht das einzige ist, worauf ATI baut...

J.S.Shadow

Crushinator
2003-12-05, 11:40:04
Original geschrieben von Ailuros
Die Bestellung ist fuer NV *seufz*...also nach mehr als zwei Versuchen muesste man wohl verstehen koennen dass damit nicht ATI gemeint war. Target ist je nach Erfolg 700-750MHz ergo bis zu ~48GB/sec Bandbreite. Verstehe ich es jetzt richtig, daß 8x2 bi schon 48 GB/s braucht?

ShadowXX
2003-12-05, 12:13:16
Original geschrieben von crushinator
Verstehe ich es jetzt richtig, daß 8x2 bi schon 48 GB/s braucht?

Sieht wohl so aus...hätte ich auch nicht gedacht.

Wobei nV ja meist einen kleinen Bandbreiten-Überhang hat....
Könnte also sein das auch etwas weniger Ausreichen würde....(40GB/s oder so)

Vielleicht hat aths oder so ja mal eine "Art" Formel dafür.

J.S.Shadow

Demirug
2003-12-05, 13:15:30
Die übliche Berechnungformel für die durch BI-TMUs verbrauchte Bandbreite ist:

Bandbreite(int Bit/s) = Anzahl der TMUs * Grösse eines Texturwerts(in Bit) * CoreTakt (in Hz).

Texturewerte haben im Moment überlicherweise 32 Bit RGBA.

Beispiel:

FX 5800U: 8*32Bit*500.000.000Hz = 128.000.000.000 Bit/s = 16.000.000.000 Byte/s ~ 16 GByte/s

Aber dabei nicht vergessen das die restlichen Teile des Chips auch noch etwas Bandbreite haben wollen. Ebenfalls wichtig ist noch das die Bandbreite die Angegeben wird die Bruto-Bandbreite ist. Wie viel davon Netto übrig bleibt hängt dann nicht unwesentlich vom Speicherkontroller ab.

ShadowXX
2003-12-05, 13:34:23
Original geschrieben von Demirug
Die übliche Berechnungformel für die durch BI-TMUs verbrauchte Bandbreite ist:

Bandbreite(int Bit/s) = Anzahl der TMUs * Grösse eines Texturwerts(in Bit) * CoreTakt (in Hz).

Texturewerte haben im Moment überlicherweise 32 Bit RGBA.

Beispiel:

FX 5800U: 8*32Bit*500.000.000Hz = 128.000.000.000 Bit/s = 16.000.000.000 Byte/s ~ 16 GByte/s

Aber dabei nicht vergessen das die restlichen Teile des Chips auch noch etwas Bandbreite haben wollen. Ebenfalls wichtig ist noch das die Bandbreite die Angegeben wird die Bruto-Bandbreite ist. Wie viel davon Netto übrig bleibt hängt dann nicht unwesentlich vom Speicherkontroller ab.

Damit kenne wir dann ja die ungefähre Taktratenanpeilung für den nv40:

16*32*500.000.000Hz = ca. 32GB/sec

Für 500MHz Coretakt sollten dann also die 800MHz Chips reichen ;D

Für ATI-Tri TMUs missbrauche ich die Formel jetzt einfach mal:

24*32*450.000.000Hz = ca. 44GB/sec

Ok ok ahts....da würde es selbst mit 800Mhz Ram seeeehhhrrr eng werden.

Bleibt also nur ein 12x1 Bi Übrig:

12*32*450.000.000Hz = ca. 22GB/sec

Das ist mit "normalen" ATI Speichtaktraten (wenn nV den 800'er nimmt, nimmt ATI wohl 600'er) wohl machbar.

Tja...dann wären wir also bei einer r420 mit 12x1 Bi, VS/PS3.0, und vielleicht etwas verbesserten AA/AF.

Wenn Sie dann nix grossartiges an den ops/sec gedreht haben, wird der nv40 wohl vorne liegen...speziell wenn nV an Ihrem AA gedreht haben sollte...

J.S.Shadow

Demirug
2003-12-05, 15:40:02
Für Tri-TMUs die aus einer Mip-Map samplen würde ich die folgenden Formel benutzten

Bandbreite(int Bit/s) = 1,5 * Anzahl der TMUs * Grösse eines Texturwerts(in Bit) * CoreTakt (in Hz).

1,5 weil die Hitrate etwas besser sein soll.

Crushinator
2003-12-05, 16:00:26
Original geschrieben von Demirug
Bandbreite(int Bit/s) = 1,5 * Anzahl der TMUs * Grösse eines Texturwerts(in Bit) * CoreTakt (in Hz).

:kratz2: 18*32*450.000.000Hz = 26GB/sec ?

Oder hab' ich wieder was völlig falsch verstanden?

Demirug
2003-12-05, 16:11:23
Original geschrieben von crushinator
:kratz2: 18*32*450.000.000Hz = 26GB/sec ?

Oder hab' ich wieder was völlig falsch verstanden?

Du hast vergessen durch 8 zu teilen und dich um eine Stelle verrechnet. Es sind etwa 250 GBit/s ~ 31 GByte/s

ShadowXX
2003-12-05, 16:14:33
Original geschrieben von Demirug
Für Tri-TMUs die aus einer Mip-Map samplen würde ich die folgenden Formel benutzten

Bandbreite(int Bit/s) = 1,5 * Anzahl der TMUs * Grösse eines Texturwerts(in Bit) * CoreTakt (in Hz).

1,5 weil die Hitrate etwas besser sein soll.

Uppss...dann sieht es ja etwas anders aus:

1,5*12*32*450.000.000= ca. 33GB/sec

bei 600MHz Speicher stehen ca. 38GB zur verfügung...

Das würde dann ja doch ganz gut passen.

Hmmm....dann vielleicht doch 12x1 Tri.

Zumindest Bandbreitentechnisch wäre es machbar.

Tja...wir werden wohl genaueres erst Ende Januar / Anfang Februar erfahren....

J.S.Shadow

Quasar
2003-12-05, 16:37:46
Original geschrieben von aths
Für 12x1 tri ist die Bandbreite nicht da.

Das weisst du aus welcher Kristallkugel nochmal?

Crushinator
2003-12-05, 16:41:42
Original geschrieben von Demirug
Du hast vergessen durch 8 zu teilen und dich um eine Stelle verrechnet. Es sind etwa 250 GBit/s ~ 31 GByte/s :ups: Ich hatte Bits nicht beachtet, Autsch. :no:

18 * 32 * 450.000.000 == 259,2 GBits / 8 == 32,4 GiB?

Bitte sag' mir nicht, daß das jetzt wieder falsch ist, dann wär' ich völlig deprimiert. :bawling:

Gast
2003-12-05, 16:45:45
Original geschrieben von Demirug
Für Tri-TMUs die aus einer Mip-Map samplen würde ich die folgenden Formel benutzten

Bandbreite(int Bit/s) = 1,5 * Anzahl der TMUs * Grösse eines Texturwerts(in Bit) * CoreTakt (in Hz).

1,5 weil die Hitrate etwas besser sein soll.

Warum 1.5? Ist mir zu hoch. Die Texel sollten fast alle im Cache sitzen. Und warum 32 bit Texturen (vorheriges Posting)? Ist Kompression aus der Mode gekommen?

Ailuros
2003-12-05, 16:48:48
Wurde der F-buffer jetzt nicht in V-buffer umbenannt, oder plapper ich schon wieder fruehzeitig Zeug aus? :D

Noch ne Kleinigkeit mit sign-off geht ihr von einem minimalem Takt aus der nach den Sicherheitsmassnahmen der Foundry festgesetzt wird. Die finale Taktung und/oder das Ziel kann ruhig um 50-100MHz hoeher sein wenn alle andere wichtige Faktoren es auch erlauben.

Aber zum Anfang zumindest waere das Risiko kleiner, wenn man nicht allzu hoch die Taktraten hochschraubt, mit so viel Transistoren/Komplexitaet.

Crushinator
2003-12-05, 16:55:53
Original geschrieben von Ailuros
(...) Aber zum Anfang zumindest waere das Risiko kleiner, wenn man nicht allzu hoch die Taktraten hochschraubt, mit so viel Transistoren/Komplexitaet. Also, einigen wir uns auf 500 MHz mit 36 GiB/s Bandbreitenbedarf bei 12x1 Tri gepaart mit 600 MHz DDR2? :D

Demirug
2003-12-05, 17:11:48
Original geschrieben von crushinator
:ups: Ich hatte Bits nicht beachtet, Autsch. :no:

18 * 32 * 450.000.000 == 259,2 GBits / 8 == 32,4 GiB?

Bitte sag' mir nicht, daß das jetzt wieder falsch ist, dann wär' ich völlig deprimiert. :bawling:

Ich habe mit 1024 gerechnet.

Demirug
2003-12-05, 17:29:07
Original geschrieben von Gast
Warum 1.5? Ist mir zu hoch. Die Texel sollten fast alle im Cache sitzen. Und warum 32 bit Texturen (vorheriges Posting)? Ist Kompression aus der Mode gekommen?

Bei der Bandbreiten Kalkulation geht man von unkomprimierten Texturen aus.

Die 1,5 sind ein Schätzwert von mir weil mir keine genauen Zahlen bekannt sind. Das fast alle Texel im Cache sein sollten stimmt, deswegen rechnet man bei BI-TMUs ja auch damit das man im Durchschnitt pro BI-Sample einen zusätzlichen Texturewert braucht. Da bei TRI aus einer Mip-Map der Filter Kernel wesentlich grösser ist gehe ich von einer etwas grösseren Durchschnittsmenge beim Nachladen aus.

Crushinator
2003-12-05, 17:52:56
Original geschrieben von Demirug
Ich habe mit 1024 gerechnet. http://home.t-online.de/home/bullitt667/smilies/data/uglyaua.gif Ich glaub' ich spring' gleich aus'm Fenster, irgendwie kann ich heute nix mehr mit dem 2^er System anfangen. Das erinnert mich wieder mal ganz stark an den berühmten Satz:
There are 10 types of people out there, one of them understands binary and the other one doesn't. ...und zum Schluß landen wir bei 32,4 GB/s alias 31,64 GiB/s.

Gast
2003-12-05, 18:08:45
Original geschrieben von Demirug
Bei der Bandbreiten Kalkulation geht man von unkomprimierten Texturen aus.

Die 1,5 sind ein Schätzwert von mir weil mir keine genauen Zahlen bekannt sind. Das fast alle Texel im Cache sein sollten stimmt, deswegen rechnet man bei BI-TMUs ja auch damit das man im Durchschnitt pro BI-Sample einen zusätzlichen Texturewert braucht. Da bei TRI aus einer Mip-Map der Filter Kernel wesentlich grösser ist gehe ich von einer etwas grösseren Durchschnittsmenge beim Nachladen aus.

Der Filter Kernel ist zwar grösser, aber mit wachsender Anzahl an Pipes verkleinert sich der Overhead. Ausserdem spielt der Overhead ohnehin keine relevante Rolle, da sich der Kernel auf der Texture verschiebt. Bi- und Tri-Filterung aus einer Mipmap brauchen in etwa dieselben Texel, bei Tri werden die Texel nur 1-X Takte vorher geladen. Nebenbei: Komprimierte Texturen sind 4x4 Texel, d.h es wird erst mal mehr geladen als man braucht.

Die Textur-Bandbreite sollte IMO niemals der begrenzende Faktor einer Architektur sein. Wer viele Spiele kennt, kann ja mal sagen, ob 32 bit Texturen oder Kompression heutzutage verwendet wird.

Ailuros
2003-12-05, 19:08:33
Darf ich mal mit der Formel spielen?

NV25:

8*32*300.000.000/8= 9.6GB/sec (soweit so gut...)

Vaporware K3:

4*32*250.000.000/8= 4.0GB/sec (bei 250MHz DDR = 8.0GB/sec)

Wo liegt jetzt der Fehler?

LovesuckZ
2003-12-05, 19:11:25
Original geschrieben von Ailuros
Vaporware K3:
4*32*250.000.000/8= 4.0GB/sec (bei 250MHz DDR = 8.0GB/sec)


Hm, 2x2 oder 4x1? (eventuell auch 1x4?)

Ailuros
2003-12-05, 19:13:42
Original geschrieben von LovesuckZ
Hm, 2x2 oder 4x1? (eventuell auch 1x4?)

Demi sagte TMUs da ist es wohl eher egal wie der setup aussieht oder? Aber wenn Du schon fragst 4*1.

***edit: der Genauigkeit zuliebe

http://users.otenet.gr/~ailuros/stg5000_archi.jpg

Xmas
2003-12-05, 19:21:42
Original geschrieben von Gast
Der Filter Kernel ist zwar grösser, aber mit wachsender Anzahl an Pipes verkleinert sich der Overhead. Ausserdem spielt der Overhead ohnehin keine relevante Rolle, da sich der Kernel auf der Texture verschiebt. Bi- und Tri-Filterung aus einer Mipmap brauchen in etwa dieselben Texel, bei Tri werden die Texel nur 1-X Takte vorher geladen. Nebenbei: Komprimierte Texturen sind 4x4 Texel, d.h es wird erst mal mehr geladen als man braucht.

Die Textur-Bandbreite sollte IMO niemals der begrenzende Faktor einer Architektur sein. Wer viele Spiele kennt, kann ja mal sagen, ob 32 bit Texturen oder Kompression heutzutage verwendet wird.
Wenn du Bilinear mit Trilinear vergleichst: Trilinear aus einer Mipmap liest in der Hälfte der Fälle die Texel aus einer höher aufgelösten Mipmap. Bei Bilinear werden praktisch alle Texel vierfach, bei Fast Trilinear die in der Mitte häufig nur ein einziges mal verwendet. Das wirkt sich auf die Cache-Effizienz aus.

Texturkompression ist ja bei dynamisch erzeugten Texturen nicht möglich. Dependent Reads sind ein Fluch für die Cache Hit Rate. Der Extremfall EMBM mit dynamischen Environment Maps haut also richtig auf die Texturbandbreite.

Außerdem noch ein interessantes Zitat aus dem B3D-Forum (http://www.beyond3d.com/forum/viewtopic.php?t=9255&postdays=0&postorder=asc&start=140):
Original geschrieben von Dio
Remember the guiding principle in texturing: 'assume you cache miss'. This is at the core of the design of all modern VPU's.
IIRC arbeitet Dio übrigens für ATI.

Demirug
2003-12-05, 19:50:59
Original geschrieben von Ailuros
Darf ich mal mit der Formel spielen?

NV25:

8*32*300.000.000/8= 9.6GB/sec (soweit so gut...)

Vaporware K3:

4*32*250.000.000/8= 4.0GB/sec (bei 250MHz DDR = 8.0GB/sec)

Wo liegt jetzt der Fehler?

Nirgends. Bei einem IMR rechnet man ja immer mit Verschnitt bei den TMUs. Quads am Polyrand. Takte in denen gar nicht gesamplet wird weil es gerade an einer andere Stelle harkt oder gerade massenhaft Pixel die TMUs gar nicht erreichen (wegen Early-Z).

PowerVR ging beim K3 aber nun wohl davon aus das die TMUs ständig mit maximaler Leistung laufen. Ergo musste man auch ausreichend Bandbreite vorhalten und zwar nicht nur für die TMUs sondern auch noch für den Rest.

Eine Rolle spielt dabei auch noch der Wirkungsgrad des Memorykontrollers.

Gast
2003-12-05, 20:39:04
Original geschrieben von Xmas
Wenn du Bilinear mit Trilinear vergleichst: Trilinear aus einer Mipmap liest in der Hälfte der Fälle die Texel aus einer höher aufgelösten Mipmap. Bei Bilinear werden praktisch alle Texel vierfach, bei Fast Trilinear die in der Mitte häufig nur ein einziges mal verwendet. Das wirkt sich auf die Cache-Effizienz aus.

Texturkompression ist ja bei dynamisch erzeugten Texturen nicht möglich. Dependent Reads sind ein Fluch für die Cache Hit Rate. Der Extremfall EMBM mit dynamischen Environment Maps haut also richtig auf die Texturbandbreite.

Außerdem noch ein interessantes Zitat aus dem B3D-Forum (http://www.beyond3d.com/forum/viewtopic.php?t=9255&postdays=0&postorder=asc&start=140):

IIRC arbeitet Dio übrigens für ATI.

Bin etwas verwirrt. Trilinear aus einer Mipmap ("fast trilinear") greift auf dieselbe Mipmap zu wie bilinear. Tri schliesst bi mit ein. "Wie oft" hat ausserdem nichts mit der Bandbreite zu tun, deshalb gibt's ja Caches.

Dem zweiten Absatz kann ich so zustimmen. (Fragen: 1. Wie viele dynamische Texture sind die Regel? 2. Wie oft wird tri EMBM benutzt?) Das reicht aber nicht, um hier mit dem Faktor 1.5 zu rechnen oder die alleinige Nutzung von 32 bit Texturen vorauszusetzen. "Worst cases" mit geringem Realitätsbezug (Spiele) bringen nichts IMO. Ausserdem: Längere shader sind 'eh die Zukunft, d.h. die Texture-Bandbreite spielt eine zunehmend geringere Rolle.

Wenn du mir sagst, was Dio mit den 2 Sätzen gemeint hat (oder gemeint haben könnte), dann kann ich darüber nachdenken und darauf vielleicht antworten. Insbesondere verstehe ich nicht, was das mit Tri/Bi zu tun hat (Thread noch nicht gelesen). NV sagt: 80% texture hit rate ist uns gut genug.

Ailuros
2003-12-05, 21:02:23
Wenn du mir sagst, was Dio mit den 2 Sätzen gemeint hat (oder gemeint haben könnte), dann kann ich darüber nachdenken und darauf vielleicht antworten.

Es geht im besagten Thread um ein Argument ob (laut Sweeney) CPUs in absehbarer Zeit GPUs ueberfluessig machen werden.

Dio hat sich aus verstaendlichen Gruenden auf texturing unter anderen konzentriert:

For the same amount of logic, there's no way any other architecture can possibly outperform dedicated hardware.

Antwort:

Hmmm, what if the former(other) has far better memory, and b/w...

Dio's Antwort darauf:

The dedicated hardware is likely to make more efficient use of its bandwidth. Remember the guiding principle in texturing: 'assume you cache miss'. This is at the core of the design of all modern VPU's.

Expanding available bandwidth when you can't make use of it is a waste of money.

Of course, having all-SRAM, or other low/zero latency memory would greatly reduce miss latencies. But bandwidth isn't the key there; latency is. PC2100 DDR CAS2 can be faster than PC2700 CAS3, and that's on a CPU bus where the hit rate is targetted at 95%+, not 0%.

War zwar nur ein einziger klick entfernt, aber ich hoffe es hilft...

Gast
2003-12-05, 21:20:08
Ailuros,
bin gerade dabei den Thread zu lesen. Auf den ersten Blick verstehe ich immer noch nicht, was er damit meint (ausser vagen Vermutungen). Es fehlt mir ebenso der Bezug zu meinem Posting. Interpretationen sind willkommen.

Gast
2003-12-05, 21:55:18
Ich vermute nun, was er damit meint. GPUs treiben massivem Aufwand, um gegenüber Latenzen unempfindlich zu sein. NV hat z.B. ein 160 Takte FIFO fürs Texturieren, um ein cache miss wegzustecken. Mehr Bandbreite ohne dieses FIFO ist Unsinn, da Latenzen das Problem sind. Egal welche hit rate, das FIFO steckt cache misses problemlos weg. Was nicht heisst, dass 80% cache hit rate nicht wichtig ist, um Bandbreite zu sparen.

Gast
2003-12-05, 22:12:28
Original geschrieben von Ailuros
Wurde der F-buffer jetzt nicht in V-buffer umbenannt, oder plapper ich schon wieder fruehzeitig Zeug aus? :D

Noch ne Kleinigkeit mit sign-off geht ihr von einem minimalem Takt aus der nach den Sicherheitsmassnahmen der Foundry festgesetzt wird. Die finale Taktung und/oder das Ziel kann ruhig um 50-100MHz hoeher sein wenn alle andere wichtige Faktoren es auch erlauben.

Aber zum Anfang zumindest waere das Risiko kleiner, wenn man nicht allzu hoch die Taktraten hochschraubt, mit so viel Transistoren/Komplexitaet.

Lag der Sign-off - Speed des R300 nicht so bei 250MHz?

zeckensack
2003-12-05, 23:39:30
Original geschrieben von Gast
Bin etwas verwirrt. Trilinear aus einer Mipmap ("fast trilinear") greift auf dieselbe Mipmap zu wie bilinear.Bilinear filtert tendenziell aus kleineren Mip-Levels.

Mal beispielsweise bei einer lod fraction von 0,5 ... nimmt trilinear:
0,5*Bi-Sample aus Mip-Level n
+
0,5*Bi-Sample aus Mip-Level n+1

Ein reiner bilinearer Filter muß zu Mip-Level n+1 greifen, um Aliasing zu vermeiden (Onkel Nyquist ahoi!).

Dabei spielt es auch keine Rolle, ob man tri aus einer Mipmap, oder klassisch aus zwei bilinearen Samples berechnet.

aths
2003-12-06, 00:49:51
Original geschrieben von Quasar
Das weisst du aus welcher Kristallkugel nochmal? Das kann man ausrechnen. Man braucht 3-fache Texturbandbreite. Kann man auch mit Caches den Speichercontroller entlasten, die Anbindung der TMUs an den Cache muss entsprechend verbreitert werden. Damit verballert man Transistoren, die man kaum braucht, wenn nicht gleichzeitig die arithmetische Leistung extrem ansteigt. Um Faktor 3, damit die R300-Balance gehalten würde. Dazu bräuchte man also pro Quad noch mal zwei "Shadercores" extra. Da haben wir also 12 tri-TMUs, und 9 Shader-Cores, die vermutlich PS.3.0 können. Wie viele Transistoren wird das wohl kosten? Selbst wenn man nur 2 Shader-Cores pro Quad hätte, also 6 insgesamt, das halte ich für unwahrscheinlich.

Weiteres Argument: Die trilineare Füllrate würde taktbereinigt um Faktor 3 steigen. Daran glaube ich irgendwie nicht so recht.

Xmas
2003-12-06, 03:37:02
Original geschrieben von Gast
Bin etwas verwirrt. Trilinear aus einer Mipmap ("fast trilinear") greift auf dieselbe Mipmap zu wie bilinear. Tri schliesst bi mit ein. "Wie oft" hat ausserdem nichts mit der Bandbreite zu tun, deshalb gibt's ja Caches.

Dem zweiten Absatz kann ich so zustimmen. (Fragen: 1. Wie viele dynamische Texture sind die Regel? 2. Wie oft wird tri EMBM benutzt?) Das reicht aber nicht, um hier mit dem Faktor 1.5 zu rechnen oder die alleinige Nutzung von 32 bit Texturen vorauszusetzen. "Worst cases" mit geringem Realitätsbezug (Spiele) bringen nichts IMO. Ausserdem: Längere shader sind 'eh die Zukunft, d.h. die Texture-Bandbreite spielt eine zunehmend geringere Rolle.

Wenn du mir sagst, was Dio mit den 2 Sätzen gemeint hat (oder gemeint haben könnte), dann kann ich darüber nachdenken und darauf vielleicht antworten. Insbesondere verstehe ich nicht, was das mit Tri/Bi zu tun hat (Thread noch nicht gelesen). NV sagt: 80% texture hit rate ist uns gut genug.
Das erste hat zecki ja schon teilweise erklärt. "Wie oft" hat sogar sehr viel damit zu tun, denn ein Texel das nur einmal verwendet wird nimmt nur Platz im Cache weg.
Das zweite war nicht auf Bi/Tri bezogen, sondern auf die Aussage dass Texturbandbreite niemals der begrenzende Faktor ist (bei einer 1x8 Architektur wäre sie es wohl ständig ;). Und der Kommentar von Dio war zwar hauptsächlich auf die Latenz gemünzt, lässt aber auch die Bandbreite nicht ganz außen vor.

Ailuros
2003-12-06, 05:10:12
Original geschrieben von Gast
Lag der Sign-off - Speed des R300 nicht so bei 250MHz?

Ja aber ich moechte erinnern dass es sich um 107M@150nm handelte. Dazu noch DDR1.

Ailuros
2003-12-06, 05:37:48
Ich schiesse mal los was ein ganz anderes Thema betrifft:

http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=106181

Es gibt staendig Spekulationen ueber eine Einheit namens:

http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=79771

...wo man theoretisch topology+tesselation leicht unterbringen koennte. Voraussetzung ist natuerlich dass diese Einheit auch wirklich programmierbar sein wird. Ich bezweifle schon seit langem dass der NV40 einen PPP hat, und so wie es mit jeder Revision von DX-Next aussieht, ist es zweifelhaft ob die erwuenschte oder notwendige Programmierbarkeit fuer jenige Einheit(-en) auch wirklich eine Vorraussetzung sein wird fuer das zukuenftige API. Als freiwillige Option es ins API einzuschliessen sagt wohl gar nichts, denn es ist wohl dann verstaendlich dass IHVs entweder davon abweichen werden oder nur begrenzte Funktionalitaeten ergo Programmierbarkeit implementieren werden.

Warum soll das jetzt so wichtig sein? Mehr Pipelines? Warum nicht... Mehr Shader Anweisungen + dynamic loops/branching? Sehr willkommen...VS3.0 Displacement Mapping? Um einiges besser als Matrox's unsupported DM oder unattraktives pre-sampled DM bei R3xx/NV3x, aber fuer robuste HOS Unterstuetzung braucht der Entwickler IMHO um einiges mehr. Adaptive Tesselation ist wohl anscheinend schon lange "versteckt" in dx9.0, dabei ist die Brauchbarkeit im API wohl zwischen gering zu Null, und diese nur um einiges im naechsten API zu erhoehen sagt mir persoenlich auch nichts.

Ja einen grossen Teil der Verantwortung tragen hier die IHVs selber und was sie fuer Prioritaeten setzen. Ich frage mich allen Ernstes wie manche "unlimited resources" ansehen. Eine Einheit die Geometrie frei generieren und/oder loeschen kann ist IMO einen guten Schritt naeher zum obrigen Ziel. Viel mehr Bandbreite und starke CPU Entlastung.

Tut mir leid wenn ich jetzt versuche den X pipes bi/tri MHz Brei ein bisschen zu verpatzen, aber ich hab eine ganz andere Vorstellung von Graphiks der Zukunft....

Gast
2003-12-06, 14:02:27
Original geschrieben von zeckensack
Bilinear filtert tendenziell aus kleineren Mip-Levels.

Mal beispielsweise bei einer lod fraction von 0,5 ... nimmt trilinear:
0,5*Bi-Sample aus Mip-Level n
+
0,5*Bi-Sample aus Mip-Level n+1

Ein reiner bilinearer Filter muß zu Mip-Level n+1 greifen, um Aliasing zu vermeiden (Onkel Nyquist ahoi!).

Dabei spielt es auch keine Rolle, ob man tri aus einer Mipmap, oder klassisch aus zwei bilinearen Samples berechnet.

Wird sicher stimmen, auch weil XMAS dasselbe sagt. Etwas seltsam nachgefragt: Zu einer Zeit, als es anisotrophe Filterung noch nicht gab (lang, lang ist's her), habe ich mir mal Tri und Bi Bilder angeschaut. Wenn ich mich mal auf mein Gedächtnis verlasse, dann kam mir Tri immer unschärfer vor als Bi. Täuschung oder hat sich das eventuell geändert (verfeinerte Spezifikation)?

Noch naiver: Für Tri fliessen ggf. 50% Aliasing (Mip-Level n) in die Rechnung ein. Wäre es nicht notwendig für Bi Mip-Level n+1 zu nehmen und Tri nimmt n+1 und n+2, also genau umgekehrt? Würde auch die Unschärfe erklären.

zeckensack
2003-12-06, 16:54:11
Original geschrieben von Gast
Wird sicher stimmen, auch weil XMAS dasselbe sagt. Etwas seltsam nachgefragt: Zu einer Zeit, als es anisotrophe Filterung noch nicht gab (lang, lang ist's her), habe ich mir mal Tri und Bi Bilder angeschaut. Wenn ich mich mal auf mein Gedächtnis verlasse, dann kam mir Tri immer unschärfer vor als Bi. Täuschung oder hat sich das eventuell geändert (verfeinerte Spezifikation)?

Noch naiver: Für Tri fliessen ggf. 50% Aliasing (Mip-Level n) in die Rechnung ein. Wäre es nicht notwendig für Bi Mip-Level n+1 zu nehmen und Tri nimmt n+1 und n+2, also genau umgekehrt? Würde auch die Unschärfe erklären. Sieh selbst:
(da wo bilinear auf Mip n+1 geht, ist in trilinear ca 50/50 n und n+1 enthalten; und nein, da flimmert nichts)

Xmas
2003-12-06, 17:01:18
Original geschrieben von Ailuros
Adaptive Tesselation ist wohl anscheinend schon lange "versteckt" in dx9.0, dabei ist die Brauchbarkeit im API wohl zwischen gering zu Null, und diese nur um einiges im naechsten API zu erhoehen sagt mir persoenlich auch nichts.
Ich verstehe die Aussage nicht ganz. Adaptive Tessellation ist in DX9 ganz einfach nutzbar - aber nur ein einziger Chip unterstützt das bisher theoretisch.

Ailuros
2003-12-07, 04:09:22
Original geschrieben von Xmas
Ich verstehe die Aussage nicht ganz. Adaptive Tessellation ist in DX9 ganz einfach nutzbar - aber nur ein einziger Chip unterstützt das bisher theoretisch.

Das Ganze war wohl ein bisschen komisch ausgedrueckt. Natuerlich war es in Relation mit existierender HW gemeint, wobei es moeglich ist dass IHVs in der vorsehbaren Zukunft auch nicht unbedingt zu einer fixed function unit greifen werden; um das geht es hier.