Diskussion zu: Inside ATIs R420

[Leonidas]

Link

[Lustiger Troll]

ähhhm braucht es dafür 2 Threads?

/Edit sorry der andere sind ja die Benches .

[ow]

.

[Leonidas]

War online ... auf der ORG. Der DE ist der neue Server, dort ist es erst grad hin transferiert worden :-))). Und die Startseite war noch nicht angepasst ... ok, nun alles verlinkt.

[Salvee]

Erstmal überfliegen

Kleine Fehlerchen:

Seite 1:

'welches wegen dem Supersampling-Verfahren langsam ist und zudem aufgrund eines Bigs in der Smoothvision-Hardware'

'Ehrlich gesagt bezweifeln wir, dass das eine gute Idee ist'

'4x mit einer alternierenden Maske könnte theoretisch zwar die gleiche Qualität wie 8x "sparsed" liefern.' (ist irgendwie kein vollständiger Satz)

Seite 2:

'Man verwechlse bitte'

'wird als Version 2.x behandelt, sonfern die Hardware nicht schon'

'Die Performance vom R360 (Radeon 9600) wäre etwa 10% besser' ->RV360

'Denkbare zukünftige Chips die auf den Einstiegs- oder Mainstream-Markt abziehlen'

'was die Leistung verglichen mit dem R360 erhöht.' ->RV360

'Dabei handelt es sich eigentlich um den gelcihen Chip.'

'oder ebene eine einzelne defekte Quad-Pipe haben darf'

' 6x AA bietet eine sehr gute Glättung von Polyginkanten'

[Simon Moon]

War nicht die Parhelia vor der R9700 mit einer 256Bit Speicheranbindung auf dem Markt?

[Salvee]

Seite 3 ganz unten:

'(wobei inkauf genommen wird, dass vielleicht X einige Units ausgelastet werden können)' ->ich vermute, hier (X) fehlt ein 'nur'

Seite 4:

'genau wie für die morgigen (beispielsweise Halflife 2) ist der R420 ein natürlich trotzdem ein interessantes Produkt.' ->ein 'ein' zuviel

[aths]

Zitat:

Original geschrieben von El-Diablo
War nicht die Parhelia vor der R9700 mit einer 256Bit Speicheranbindung auf dem Markt?

Das stimmt :bonk:

Edit: Bis hierhin sind alle Fehler Leo gemeldet. Bitte nur neue Fehler vermerken (Leo kann die Korrekturen jetzt nicht sofort einpflegen.)

[BodyLove]

im Fazit:

Zitat:

...so bin ich persönlich nicht davon überzeigt...

sonst, wie immer aths sehr guter und kritischer Artikel deinerseits.

[aths]

Zitat:

Original geschrieben von BodyLove
sonst, wie immer aths sehr guter und kritischer Artikel deinerseits.

Kritisch?

[Kritischer aths]

Der R420 bietet an Features Bugfixing beim HyperZ und F-Buffer, einen erhöhten Instruction Count und zusätzliche Temp-Register im Pixelshader, und als einziges neues Feature 3Dc. Dieses ist aber eigentlich nur ein 2-Kanal-DXT5 und seine Nutzung belastet den Pixelshader zusätzlich, so dass das einzige wirklich neue Feature nicht wirklich ein wirklich neues Feature ist.

ATI bringt nach reichlich 1 1/2 Jahren an Neuem: genau, nichts. Nichts außer mehr Leistung. Die gleiche, teilweise problematische Bildqualität wird jetzt als "High Definition" vermarktet. Und daraus soll man nun einen Artikel stricken.

[/kritischer aths]

[BodyLove]

Zitat:

Original geschrieben von aths
Kritisch?

[Kritischer aths]

Der R420 bietet an Features Bugfixing beim HyperZ und F-Buffer, einen erhöhten Instruction Count und zusätzliche Temp-Register im Pixelshader, und als einziges neues Feature 3Dc. Dieses ist aber eigentlich nur ein 2-Kanal-DXT5 und seine Nutzung belastet den Pixelshader zusätzlich, so dass das einzige wirklich neue Feature nicht wirklich ein wirklich neues Feature ist.

ATI bringt nach reichlich 1 1/2 Jahren an Neuem: genau, nichts. Nichts außer mehr Leistung. Die gleiche, teilweise problematische Bildqualität wird jetzt als "High Definition" vermarktet. Und daraus soll man nun einen Artikel stricken.

[/kritischer aths]

Das ist nicht kritisch, sondern viel eher sarkastisch. Aber gut zu lesen, dass es jemand im Netz gibt, die es stark anzweifeln, dass an der BQ vom R420 nichts verändert wurde.

[aths]

Zitat:

Original geschrieben von BodyLove
Das ist nicht kritisch, sondern viel eher sarkastisch. Aber gut zu lesen, dass es jemand im Netz gibt, die es stark anzweifeln, dass an der BQ vom R420 nichts verändert wurde.

Die Aussage (keine Verbesserungen bzgl. AA und AF) stammt von ATI selbst.

[BubbleBoy]

.

[aths]

Zitat:

Original geschrieben von BubbleBoy
Warum wird das Kind nicht beim Namen genannt? Anstatt in jedem dritten Absatz (auch in anderen Artikeln) umständliche Formulierungen zu benutzen sagt einfacht ATI/Nvidia/R420/GFX6800/... . Ich persönlich empfinde es nur als Wichtigtuerei wenn solche Phrasen ständig auftauchen.

Sprachlich gesehen ist der Artikel Horror. Ich hätte zwei Tage mehr Zeit gebraucht. Umständliche Formulierungen bitte ich deshalb zu entschuldigen.

[BubbleBoy]

.

[Frank]

Zitat:

Original geschrieben von El-Diablo
War nicht die Parhelia vor der R9700 mit einer 256Bit Speicheranbindung auf dem Markt?

Der erste 3D Chip mit 256Bit Speicherinterface war wohl eher der Neomagic MagicMedia 256XL+ (oder der Number Nine Ticket to Ride bei 32MB WRAM).

Ansonsten:
Danke aths für den sehr guten Artikel.

[Demirug]

Ich fang dann mal an.

3dc:

-Der Z-Wert ist sogar äussert genau (für einen Normal vektor) weil er ja berechnet wurde. Normalerweise haben die aus einer Normalmap ausgelesenen Texturen ja meist nicht die Länge 1. Die Frage ist daher eher wie genau X und Y sind? Das wiederum dürfte davon abhängen wie unregelmässig die Normalmap.

- Schade fand ich das du nicht die von ATI angegeben 4:1 Kompression kritisiert hast.

- PS: Der 2 Komponeten Trick lässt sich auf einem NV40 übrigens dafür einsetzten einen hochwertige FP16 normalmap zum gleichen Speicher und Bandbreitenverbrauch wie eine normale XYZW Normalmap mit 8 Bit Festpunkt Werten zu erhalten.

Verbesserte Pixelshader:

- Die 1536 Anweisungen ergeben sich anders. 512 Texturanweisungen, 512 Vektor3 Anweisungen und 512 Skalar Ops. Im Prinzip wurde auch schon beim R3XX so aufgeteilt 32+64+64. Das interne Anweisungsformat besteht wohl darauf das jede der 3 Einheiten (Textur, Vektor3 und Skalar) ein eigenen Programm hat.

- 32 Temps. Mit Verlaub aber die Begründung das man dadurch längere Anweisungsblöcke zwischen die Textursamples pressen kann ist Blödsinn. Man kann auch mit wenigen Temps lange Codesequenzen schreiben. ATI braucht die vielen Temps aus einem ganz anderen Grund. Da man immer noch ein Dependent Read Limit hat muss man immer so viele Textursamples wie möglich am Stück holen. Da man jedes Sample in eine Tempvariable speichern muss braucht man eben einige davon. Die 32 reichen genau aus um 512 Textursamples mit jeweils einem Skalar auszuführen.

Was geblieben ist:

- "Centroid sampling" hat natürlich was mit den Pixelshader rechnungen zu tun. Es wird ja beim festlegen der Eingangsregister benutzt und gibt an wie der Pixelshader die entsprechenden Register interpolieren soll. Deswegen kann es auch nur im Pixelshadercode gesetzt werden. Für Prozedurale Texturen braucht man ja auch Koordinaten die nicht über den Polyrand hinausgehen auch wenn diese niemals zum auslesen einer Textur benutzt werden.

Die Pipeline:

Mit der Effizienz Betrachtung habe ich ein grosses Problem, So wie es hier aufgeführt wird hätte ein Chip mit nur einer Einheit die alles kann (Texturops, Vektorops, Spezialfunktionen) aber eben nur immer eine Sache davon pro Takt eine maximale Effizienz von 100%. zum Beispiel gibt nVidia für den NV30 wenn es keine Tempprobleme gibt für den Shadercore eine Auslastung von 100% an weil er ja in jedem Takt etwas tut. Das wäre nach dem hier benutzten Model dann auch eine Effizienz von 100%.

Aber selbst wenn wir dabei bleiben müssen wir Äpfel mit Äpfel vergleichen. ATI gibt 5 Anweisungsslots pro Takt an. 1 Textur, 2 Vektor3 und 2 Skalar. Von den Vektor3 und Skalar kann jeweils ein Slot nur für eine einfache Operation genutzt werden (das hat ATI allerdings vergessen dazu zu schreiben. Wenn es dumm läuft kann man von diesen 5 Slots nur einen nutzen was dann 20% Effizienz wäre. Bei nVidia sind es nun 4 Slots (jeweils 2 in SU0 und SU1) und im schlimmsten Fall kann man ebenfalls nur einen nutzen also 25% Effizienz. Folgt man also den Beschreibungen der IHVs hat ATI ein grösseres Problem ihere 5 Slots voll zu bekommen. Da man aber mit dem IHV Beschreibungen Äpfel mit Birnen vergleicht muss man IMHO das ganze auf einer viel tieferen Eebene Untersuchen. Als dort wo die Skalaren MULs, ADDs und SFUs sind.

So jetzt habe ich aber erst mal genug kritisiert.

[KingZer0]

Was haltet ihr von der unterschiedlichen Implementierung von z resp. stencil operationen im nv40 und r420.

Bekanntermaßen sind die pipelines des nv40 in einem z/stencil only pass in der lage pro pipe 2 stencil/z werte zu berechnen während hingegen beim r420 die pipelines einen z/stencil wert berechnen können und die multisamplingansialiasing einheit des r420 ebenfalls.

In der summe sind also beide dazu inder lage 32Z/stencil werte zu berechnen aber unter völlig anderen umständen.

Beim R420 ist die Irnonie an der Sache das offensichtlich durch Hinzuschalten von AntiAliasing die Z/Stencil Power zunimmt.

[Rellik327]

Obwohl es sicherlich noch ein paar Wochen dauert, bis man ein endgültiges und vollständiges Bild der neuen Karten hat, schockiert mich die schlichte ungenauigkeit bzw Falschaussagen des Artikels. Die 3D Center Test waren eigentlich immer sehr gut und besonders genau. Aber die nicht nachvollziehbaren Kritiken der Anisotropen Qualität(in Bezug auf die GF3/4 R200/300/350/420 NV38/40 chips) machen einen stuzig.

Auch die Tatsache, das es einfach nicht stimmt das ATI in den Treibern nicht eine ähnliche Option wie NVidia anbietet, wenn es um die Aktivierung des Trilinearen Filters bei Anisotropen Filtern geht.

Ich zitiere:

"SMOOTHVISION HD anisotropic filtering supports 2, 4, 8, or 16 texture samples per pixel. Each setting can be used in a performance mode that uses bilinear samples, or a quality mode that uses trilinear samples There is also a new capability to support intermediate modes, to help strike the ideal balance between performance and quality."

Und dann noch das Thema 24bit rendering:

All operations are processed with a full 24 bits of precision for each component. The RADEON X800 driver software ensures optimal utilization of these ALUs by analyzing and reordering incoming pixel shader instructions wherever possible, without affecting the output.”

Es wird also NICHT auf 32bit umgeschaltet. Die GF Serie muß also entweder Qualität niedriger ansetzten (16bit) oder mit 32bit Leistung verschenken, da momentan DX9 mit 24 bit rendert. Das MS gerade dabei ist, IHRE EIGENE SPEC auf 32bit zu ändern (wohl ab DX9.0c) ist erst für ATI ein Problem, wenn ein Spiel dies nutzt, bzw voraussetzt.

Desweitern sind die Videofähigkeiten der X800 ebenso wie die der NV40 einen schritt weiter als die Vorgänger. Und programmierbar ist die Engine auch

VIDEOSHADER HD is a key feature of the video processing engine that allows it to tap into the power of the programmable pixel shader units of the RADEON X800 3D core. This allows shaders to be used to accelerate many different video processing tasks, including noise removal (VIDEOSOAP), de-blocking (FULLSTREAM), adaptive de-interlacing, frame rate conversion, color space conversion, and much more. VIDEOSHADER HD also provides the flexibility required to support all of the latest video formats, including MPEG1/2/4, Real, DivX, and WMV9.



Wer das adaptive deinterlacing der R350 Kerne kennt, weiß was das für DVD-Ausgabe bedeutet.

Was das Testsystem angeht, so finde ich das es absolut ok ist, mal ein System zu sehen, was eher dem Durchschnitt entspricht. Allerdings sind die neuen Karten von NVidia und ATi wohl eindeutig mit solchen Systemen nicht optimal genutzt. In Anbetracht der Tatsache, das auch Tests auf FX-53 Systemen noch CPU limitiert waren, bin ich gespannt wie weit die Karten noch skalieren werden.

Soviel erstmal von mir, mal sehen was die anderen Reviews so rauskriegen.
Infos von: http://www.ati.com/companyinfo/gloss...#smartshaderHD

EDIT:

Was 3Dc angeht, so verweise ich auf den legendären S3TC mod
bei UT, mit dem man die High Res Texturen der 3ten CD einsetzten konnte. Dadurch war eine deutliche Texturverbesserung zu erreichen die sogar schneller war als die normalen Texturen (jedenfalls auf meinem damaligen Radeon/PIII-700 System)

Ich denke, ähnliche Optionen stehen nun Entwicklern offen.

[Demirug]

Zitat:

Original geschrieben von KingZer0
Was haltet ihr von der unterschiedlichen Implementierung von z resp. stencil operationen im nv40 und r420.

Bekanntermaßen sind die pipelines des nv40 in einem z/stencil only pass in der lage pro pipe 2 stencil/z werte zu berechnen während hingegen beim r420 die pipelines einen z/stencil wert berechnen können und die multisamplingansialiasing einheit des r420 ebenfalls.

In der summe sind also beide dazu inder lage 32Z/stencil werte zu berechnen aber unter völlig anderen umständen.

Beim R420 ist die Irnonie an der Sache das offensichtlich durch Hinzuschalten von AntiAliasing die Z/Stencil Power zunimmt.

Ich fürchte da hast du was falsch verstanden.

Beide können zwar bis zu 32 Z/Stencil Ops pro Takt aber nur der NV40 kann das auch ohne AA ausnutzen. Der R420 kann ohne AA nur 16 Ops/Takt. Mit 2xAA bringen es dann beide auf 16 Pixel mit jeweils 2 Ops pro Takt.