War der R300 schon ein Quad-Design?

[Coda]

Weil R420 ist ja eins, und soviel soll sich ja nicht viel geändert haben. Gibt's da auch Infos bezüglich R300?

[mapel110]

Ehm, es wurde doch immer gesagt, er habe 2 Quads, oder war das nur aus der Luft gegriffen?! :confused:

[Coda]

Wo wurde das gesagt? Ich hab zumindest noch kein Schaubild gesehen wo R300 mit 2 Quads dargestellt wird.

[mapel110]

Najo, in Bezug auf Radeon 9500 non-Pro wurde das auch immer gesagt. ATI hätte dort ein Quad deaktiviert. Offizielle Quellen wüsste ich jetzt auch nicht.

[DrumDub]

Wo wurde das gesagt? Ich hab zumindest noch kein Schaubild gesehen wo R300 mit 2 Quads dargestellt wird.

ähmm.. die 9500/9800se sagt dir soch was? und was war das für nen chip? r3x0 bei dem ein quad deaktiviert war. ich denke, damit ist die frage gekärt.

edit: mapel war schneller...

[Coda]

Ich hab immer nur gelesen dass 4 Pipelines deaktiviert sind, aber wahrscheinlich hast du recht.

[Demirug]

Selbst der R200 war schon ein Quad design genau wie der NV20.

[StefanV]

Weil R420 ist ja eins, und soviel soll sich ja nicht viel geändert haben. Gibt's da auch Infos bezüglich R300?
Radeon 9500 und 9800SE

[MadManniMan]

Selbst der R200 war schon ein Quad design genau wie der NV20.

Da stellt sich für den Halblaien wie mich doch die Frage: ab wann ists ein Quad-Design, was zeichnet ein solches aus?

[Demirug]

Da stellt sich für den Halblaien wie mich doch die Frage: ab wann ists ein Quad-Design, was zeichnet ein solches aus?

Ein Quad Design ist es ab dem Moment wenn 4 Pixelpipeline zusammengefasst und sich dabei die Steuerlogik teilen. In der Regel werden dabei dann auch noch andere Dinge vereinfacht.

[Exxtreme]

Da stellt sich für den Halblaien wie mich doch die Frage: ab wann ists ein Quad-Design, was zeichnet ein solches aus?
Wie Demirug schrieb, hat ein Quad-Design eine vereinfachte Steuerlogik. Hat den Vorteil, daß man Transistoren spart. Der Nachteil ist, daß ein Quad-Design bei sehr vielen und kleinen Polygonen an Effizienz verliert da es nur den 2x2 Pixelblock pro Takt berechnen kann wenn diese Pixel zu einen Polygon gehören. Sind die Polygone klein dann ist die Wahrscheinlichkeit recht hoch, daß nicht alle Pixel in diesem 2x2 Pixelblock zu einem Polygon gehören. Und da muss der Chip mindestens eine Runde mehr einlegen. Gehören die Pixel des 2x2 Pixelblocks jeweils einen anderen Polygon dann muss der Chip 4 Runden machen, pro Pixel eine.

[robbitop]

spätestens seit NV10 und R100 waren es Quads. Das ist IIRC nötig um gewisse Dinge relativ schnell errechnen zu können, die b.s.w. für BM nötig sind.
Wichtig ist, dass die Quads (wenn man mehrere besitzt) in unterschiedlichem Dreiecken operieren können. Das ist nicht bei jedem Design so. Dazu mehr in einem später erscheinenden Artikel.

[xy]

spätestens seit NV10 und R100 waren es Quads.

Der R100 hat doch nur 2 Pipelines, also kann es kein Quad (=4) sein?

[xdcfg]

Der R100 hat doch nur 2 Pipelines, also kann es kein Quad (=4) sein?

so lange die steuerlogik für einen 2x2-pixelblock geteilt wird schon. in die gesamte pipeline kommen dan quasi die "zutaten" für den 2x2-pixelblock hinein, und (im idealfall) nach 2 takten der fertige 2x2-block wieder raus.

[robbitop]

so lange die steuerlogik für einen 2x2-pixelblock geteilt wird schon. in die gesamte pipeline kommen dan quasi die "zutaten" für den 2x2-pixelblock hinein, und (im idealfall) nach 2 takten der fertige 2x2-block wieder raus.

genau, danke :)

[aths]

Wie Demirug schrieb, hat ein Quad-Design eine vereinfachte Steuerlogik. Hat den Vorteil, daß man Transistoren spart.... und dass man für dependent reads (z. B. für EMBM) ein vernünftiges LOD berechnen kann.

[Coda]

Das must du mir jetzt genauer erklären. Jeder PixelShader Durchlauf kann theoretisch beim gleichen dependant read an einer völlig anderen Position samplen, wie soll man da das LOD pro Quad berechnen können?

[MadManniMan]

Meinen herzlichsten Dank, Demi! Und Exxtreme! Und robbi. Und xdcfg. Und äffs. Und Coda...

Ergo muß dennoch die Entwicklung vom NV31/34 komplizierter gewesen sein, als auf ATi-Seiten das "Herauslösen" eines Quads?

[Xmas]

Das must du mir jetzt genauer erklären. Jeder PixelShader Durchlauf kann theoretisch beim gleichen dependant read an einer völlig anderen Position samplen, wie soll man da das LOD pro Quad berechnen können?
Ganz einfach. LOD berechnet sich aus du/dx, dv/dx, du/dy und dv/dy. Also Differenz der Texturkoordinaten horizontal und vertikal.

Hat man nun ein Quad
a b
c d (jeweils 2D-Texturkoordinaten)
so kann man beispielsweise (b+d)-(a+c) rechnen, um du/dx und dv/dx zu ermitteln, und (c+d)-(a+b) um du/dy und dv/dy zu erhalten.

[robbitop]

Meinen herzlichsten Dank, Demi! Und Exxtreme! Und robbi. Und xdcfg. Und äffs. Und Coda...

Ergo muß dennoch die Entwicklung vom NV31/34 komplizierter gewesen sein, als auf ATi-Seiten das "Herauslösen" eines Quads?

Nun das nicht direkt. Die gesamte NV3x Serie hat die Steuerlogik für genau einen Quad. Das heißt aber auch, dass von NV30 zu NV31 bsw nicht mehr so viel Transistoren gespart werden können. Was allerdings die verschaltung der Rasterizer Operatoren angeht, war das sicher nicht einfach. (NV31 kann ja uU 4 Farbwerte/4 alphablending Operationen pro Takt schreiben trotz nur 2 pixelpipelines innerhalb der Quadpipeline)

[aths]

Meinen herzlichsten Dank, Demi! Und Exxtreme! Und robbi. Und xdcfg. Und äffs. Und Coda...

Ergo muß dennoch die Entwicklung vom NV31/34 komplizierter gewesen sein, als auf ATi-Seiten das "Herauslösen" eines Quads?Jain.

Eine GeForce3 MX hat es nicht gegeben, weil das GF-Design bis NV28 einfach nicht skalierbar war. Die GeForce2 MX wurde vom NV15 ausgehend entwickelt, aber der Aufwand hat sich nur gelohnt weil für die 2 MX ein riesiger Markt existierte. Die GeForce4 MX ist ja eine GF2 MX mit GF4 Ti-Backend. Hier wurde bekanntlich nicht von einem NV25 runterskaliert, sondern ausgehend vom NV11 hochgeschraubt.

Die NV30-Architektur ist offensichtlich schon etwas mehr skalierbar, wenn man sich ansieht, wie viele Chips in recht kurzer Zeit erschienen sind. ATI hat einfach einen Quad weggelassen, aber HyperZ funktionierte dann nicht mehr vollständig. Das R300-Design ist in diesem Punkt entweder verbuggt oder die Entwickler haben geschlampt. Beim R420 wurde das ja behoben.

Der NV40 scheint hochgradig skalierbar, die entkoppelte ROP-Logik gehört dazu. Allerdings sieht es mir so aus, dass sowohl der 12-er von NV als auch von ATI nur mit angezogener Handbremse fährt. Skalierbarkeit hin oder her, optimiert sind die Chips offenbar auf 2^n Quadpipes.

Das ist der Grund, warum ich noch immer skeptisch bezüglich eines 6-er Quadchips auf NV40-Basis bin. Entweder haben die noch was an der Effizienz gedreht, oder die Rohleistung steigt (pro Takt immerhin um 50%) derart, dass Effizienznachteile nicht so auffallen. Ich halte es sogar für möglich, dass bestimmte Befehle etwas länger brauchen, weil zugunsten der Anzahl der Pipes an der Flexibilität gespart werden könnte.

[Coda]

Skalierbarkeit hin oder her, optimiert sind die Chips offenbar auf 2^n Quadpipes.Wie kommst du darauf? Das sollte ziemlich linear skalieren.

[Banshee18]

Allerdings sieht es mir so aus, dass sowohl der 12-er von NV als auch von ATI nur mit angezogener Handbremse fährt.

Inwiefern? Das würde mich jetzt doch näher interessieren.

mfg

Banshee

Edit: Zu langsam... :(

[aths]

Wie kommst du darauf? Das sollte ziemlich linear skalieren.Ich erinnere mich an Benches in denen die X800 Pro schlechter abschnitt als die 16-er Version, als man erwarten würde. Die 6600 GT wiederum steht einer 6800 eigentlich kaum nach, trotz etwas weniger Füllrate und deutlich geringerer Speicherbandbreite.

[fghgft]

Ich erinnere mich an Benches in denen die X800 Pro schlechter abschnitt als die 16-er Version,

war das nicht ein treiberproblem in doom3, das man ziemlich schnell in den griff bekam?

[mapel110]

war das nicht ein treiberproblem in doom3, das man ziemlich schnell in den griff bekam?
http://www.digit-life.com/articles2/digest3d/0205/itogi-video-d3-wxp-1280-agp.html
46,4 fps zu 31,9 fps
Radeon X800 XT nonPE zu X800 Pro

War also kein Treiberproblem.

[klgk]

http://www.digit-life.com/articles2/digest3d/0205/itogi-video-d3-wxp-1280-agp.html
46,4 fps zu 31,9 fps
Radeon X800 XT nonPE zu X800 Pro

War also kein Treiberproblem.

16pipes@500MHz gegenüber 12pipes@475MHz macht ca. 40% mehr füllrate, bei rund 11% mehr speicherbandbreite.

46fps gegenüber 32fps sind ca. 45% mehr, also kaum mehr als der füllratenvorteil. die zusätzlichen 5% können durchaus von der speicherbandbreite kommen, oder anderen einflüssen, sind aber nicht gerade weltbewegend.

btw. interessant dass die 12-pipe 6800 mit 256mb deutlich besser ist als eine 16-pipe 6800GT mit nur 128MB und niedrigerem speichertakt.
btw. wie aktuell sind die verwendeten ati-treiber in diesem test, imo müsste mit aktuellen treibern die x800xt doch eine 6800 locker schlagen

[mapel110]

3.2. This month we used 71.81 drivers for NVIDIA cards summaries; 6.512 drivers(Cat5.2) for ATI cards summaries.

/edit
lol, nvidia ist jetzt in HL2 Vorne. Was so shaderreplacement doch alles bringt. :wink:

[Coda]

Shaderreplacement geht in HL² nicht, dafür gibt es viel zu viele verschiedene Kombinationen.

Wenn dann wurden spezielle Peephole Optimierungen für HL² in den Compiler eingebaut, die funktionieren dann bei anderen Spielen auch.

[Banshee18]

Was sind "Peephole Optimierungen"?

Ich weiß, ich stelle zu viele Fragen... :rolleyes:

mfg

Banshee

[Coda]

Lokale Optimierungen von Maschinencode.

Aber allgemein scheint der Shadercompiler von Forceware 7x.xx (speziell >75.00) viel mehr aus NV40 rausholen zu können.

Ist ja auch logisch, dass die Architektur erstmal ein paar Treiber braucht um voll auf Touren zu kommen, das war mir auch beim Kauf damals klar.