R600-Architektur-Diskussion [Archiv]

Godmode

2007-05-14, 16:17:36

Da die Ergebnisse des R600 doch etwas unerwartet sind, möchte ich hier eine kleine Diskussion über die R600 Architektur starten.

http://www.computerbase.de/artikel/hardware/grafikkarten/2007/test_ati_radeon_hd_2900_xt/2/#abschnitt_technische_daten

In dieser Tabelle werden die Technischen Daten der verschiedenen Karten gegenübergestellt. Betrachtet man die Texturleistung des R600 und vergleicht diese mit dem G80, wird sich wohl jeder diese Frage stellen: warum hat der R600 nur ein Drittel der Texturfüllrate einer 8800 GTX? Diese wurde um gerade mal 1.472 MTex/s gegenüber des R580 erhöht, was mir doch recht wenig vorkommt.

Texturfüllrate ist doch nach wie vor eines der wichtigsten Kriterien für die Leistungsfähigkeit einer Grafikkarte. Anhand der X1600 hat man gesehen, dass eine hohe Shaderleistung alleine nichts bringt. Warum hat man nicht nochmal 16 TMUs draufgepackt? Dafür bekommt man einen programmierbaren Tesselator, der dazu auch noch ziemlich teuer sein soll, was das Transitorbudget betrifft und erst ab D3D11 offiziel in DX auftaucht. Hat ATI das Design an ner alten Spec. festgelegt?

Auf der anderen Seite haben wir ein 512 bit SI, welches wahnwitzige 106 GB/s an Speicherbandbreite liefert. Irgendwie etwas unausgeglichen IMHO.

Die theoretische Shaderleistung liegt laut CB auch bei der Geforce höher, da sie das MUL voll zählen. Die sehr gute Auslastung der ALUs durch die interessante Abarbeitung der Befehle spricht nocheinmal für die Geforce. Im Shadermark zeigt sich, dass die Geforce auch hier punktet. Ich weis leider nicht ob der Shadermark auch sehr stark an der Tex-Leistung hängt, klärt mich bitte auf.

Alle diese Dingen spiegeln sich dann auch in der Leistung wieder, die momentan nicht konkurenzfähig ist, was wohl teilweise an den Alpha Treibern liegt. Warum haben sie nicht noch einen oder zwei Monate gewartet, wenn doch die kleinen R6xx Modelle auch noch nicht verfügbar sind? In dieser Zeit hätte man sicherlich noch eines am Treiber verbessern können.

Von gewissen Seiten hört man, dass der R600 erst mit DX10 seine Muskeln spielen lässt. Erste Benchmarks wiederlegen aber auch das. Der Geometryshader des G80 soll nicht toll sein laut einem Posting im B3D Forum. Der G80 ist ein ziemlich abgerundetes Produkt, warum sollte gerade hier wieder gespart worden sein? Wenn dies aber wirklich zutrifft, dann gehört nVidia richtig geschlagen. Das wäre der praktische Tot des GS. Ich hoffe das dem doch nicht so ist und das Treiberteam für den GS noch nicht viel Zeit hatte.

Ich hoffe wir können hier nett diskutieren und es artet nicht wieder in einen Flame-War aus. IQ Diskussionen sind hier eher unerwünscht, das wird schon im (P)Reviewthread diskutiert.

Coda

2007-05-14, 17:37:29

Imho sind ihnen für mehr TMUs/ROPs einfach die Transistoren ausgegangen. nVIDIA hat da durch die Shader-Clock-Domäne und damit viel weniger Shader sehr viel Die-Space sparen könnnen.

Aber das hab (http://forum-3dcenter.org/vbulletin/showpost.php?p=5246030&postcount=165) ich ja schon früh (http://forum-3dcenter.org/vbulletin/showpost.php?p=5246104&postcount=169) geahnt.

Pirx

2007-05-14, 17:45:31

Aber das wissen die Entwickler doch alles, wenn das ein wirklicher Flaschenhals wäre, hätte man das doch nicht so gemacht.:confused:

Coda

2007-05-14, 17:50:37

Man kann nicht immer alles was man will, vor allem wenn man nicht genügend R&D betreibt im Gegensatz zum Konkurenten.

san.salvador

2007-05-14, 17:50:55

Dann dürfte es aber auch keine Hardware geben, die einen Flaschenhals hat.

Davon gibts aber doch massig... ;)

micki

2007-05-14, 18:42:12

In dieser Tabelle werden die Technischen Daten der verschiedenen Karten gegenübergestellt. Betrachtet man die Texturleistung des R600 und vergleicht diese mit dem G80, wird sich wohl jeder diese Frage stellen: warum hat der R600 nur ein Drittel der Texturfüllrate einer 8800 GTX? Diese wurde um gerade mal 1.472 MTex/s gegenüber des R580 erhöht, was mir doch recht wenig vorkommt.

Texturfüllrate ist doch nach wie vor eines der wichtigsten Kriterien für die Leistungsfähigkeit einer Grafikkarte. Anhand der X1600 hat man gesehen, dass eine hohe Shaderleistung alleine nichts bringt. Warum hat man nicht nochmal 16 TMUs draufgepackt? Dafür bekommt man einen programmierbaren Tesselator, der dazu auch noch ziemlich teuer sein soll, was das Transitorbudget betrifft und erst ab D3D11 offiziel in DX auftaucht. Hat ATI das Design an ner alten Spec. festgelegt?

Auf der anderen Seite haben wir ein 512 bit SI, welches wahnwitzige 106 GB/s an Speicherbandbreite liefert. Irgendwie etwas unausgeglichen IMHO.
ist eventuell sehr auf nextgen ausgelegt und bringt entsprechen nicht soviel zZ.
wenn du 11872 MTexel bei 128Bit+verschleiss (weil die caches entsprechen wenig effizient bei 128bit sind passen weniger texel rein) rechnest, kannst du eventuell 106GB/s verstehen.

Gast

2007-05-14, 18:49:26

Imho sind ihnen für mehr TMUs/ROPs einfach die Transistoren ausgegangen. nVIDIA hat da durch die Shader-Clock-Domäne und damit viel weniger Shader sehr viel Die-Space sparen könnnen.
Aber dann man ne Tesselation Unit ein?
Ich glaube jeder würde das Ding gerne gegen 2 Rops tauschen.

Coda

2007-05-14, 19:36:31

Fragt sich ja, was das Ding wirklich kann. Mal sehen was da an OpenGL-APIs kommt.

Demirug

2007-05-14, 20:08:25

Fragt sich ja, was das Ding wirklich kann. Mal sehen was da an OpenGL-APIs kommt.

Der Tesselator ist IMHO sowieso erst mal nur für XBox ports interesant. DX9 unterstützt ja noch patches und adaptive tesselation.

Die sollen sich aber bei OpenGL erst mal um EXT und ARB kümmern bevor sie auf AMD/ATI machen. Sonst steige ich doch noch auf NV_GPU_Program4 um.

BAGZZlash

2007-05-14, 20:28:11

Inwieweit funktioniert Tesselation eigentlich "von selbst"? Reicht es, der GraKa zu sagen "Tesselier' das mal!", und schon ist der Torbogen rund? Meine Frage zielt in die Richtung, wie einfach/schwer es ist, Tesselation-Patches für existierende Spiele zu basteln. Falls das breitflächig kommt, wird demnächst das Erstellen von Benchmarks noch schwerer, da die Bildqualität noch unvergleichbarer wird. Ist es denn in Direct3D10 überhaupt schon ohne Weiteres möglich, das Ding anzusprechen?

reunion

2007-05-14, 20:35:10

Ich denke bei einer Architekturdiskussion sollte man den B3D-Artikel zumindest mal kurz erwähnen:
http://www.beyond3d.com/content/reviews/16

So ausführlich wird wohl sonst nirgends darauf eingegangen.

deekey777

2007-05-14, 22:14:35

Thema: Architektur-Diskussion.
Jede Abweichung führt zur Erschießung.

Coda

2007-05-14, 22:34:57

Der Tesselator ist IMHO sowieso erst mal nur für XBox ports interesant. DX9 unterstützt ja noch patches und adaptive tesselation.
Gibt's den Tesselator also tatsächlich in der Xbox 360?
Komisch, wieso hat man dann nie davon gehört? Das wäre doch Marketingtechnisch keine schlechte Sache gewesen :|

Ist es denn in Direct3D10 überhaupt schon ohne Weiteres möglich, das Ding anzusprechen?
D3D10 bietet nur die "normale" Geometry-Shader-Funktionalität an.

Thema: Architektur-Diskussion.
Jeder Abweichung führt zur Erschießung.
Wie bist du denn drauf heute :D

micki

2007-05-14, 22:40:23

Gibt's den Tesselator also tatsächlich in der Xbox 360?in einigen reviews wird glaube ich behauptet dass es die tesselierungseinheit aus der box sogar waere und somit genau so funnktioniert.

Komisch, wieso hat man dann nie davon gehört? Das wäre doch Marketingtechnisch keine schlechte Sache gewesen :|das waere deren prozedurale synthese auch und trotzdem hoert man so gut wie nie davon.

Coda

2007-05-14, 22:43:21

in einigen reviews wird glaube ich behauptet dass es die tesselierungseinheit aus der box sogar waere und somit genau so funnktioniert.
Ja in den R600-Artikeln. Aber in Xbox-360-Artikeln wurde davon nirgends ein Sterbenswörtchen erwähnt.

Wechselbalg

2007-05-14, 23:05:39

Jetzt dann mal eine etwas abwegigere Frage. Ist die Tesselator Einheit auch noch zu den damaligen TruForm Umsetzungen, die auf R200 liefen dann noch (abwärts)kompatibel?

Also könnte man sich z.B. die N-Patches Funktionen von UT2003 oder Morrowind nutzen? Eventuell könnte man dann ja mit hohen Tesselationsfaktoren mal ein bisschen rumexperimentieren. (Entschuldigt wenn die Frage total blöd ist ^^)

Coda

2007-05-14, 23:06:58

Jetzt dann mal eine etwas abwegigere Frage. Ist die Tesselator Einheit auch noch zu den damaligen TruForm Umsetzungen, die auf R200 liefen dann noch (abwärts)kompatibel?
Ja, das kann jede Karte mit GS.

Also könnte man sich z.B. die N-Patches Funktionen von UT2003 oder Morrowind nutzen? Eventuell könnte man dann ja mit hohen Tesselationsfaktoren mal ein bisschen rumexperimentieren. (Entschuldigt wenn die Frage total blöd ist ^^)
Ich glaube das war doch eh immer in den ATI-Treibern als Softwareemulation noch drin, oder nicht?

Wenn nicht, wird's das jetzt vielleicht schon mal wieder geben, wenn das Treiberteam dafür Zeit findet ;) ;)

Wechselbalg

2007-05-14, 23:12:17

Danke für die Info :)

Das wurde aus den Treibern zwischenzeitlich einmal leider rausgenommen. Die Softwaremulation war aber auch einfach viel zu langsam, als das es sinnig gewesen wäre und Software beschränkte sich ja ohnehin auf sehr wenige unterstützte Titel.

Um mit dem R200 rumzuspielen war es aber schon ganz nett und mit hohen Einstellungen wenn ich es recht in Erinnerung habe auch durchaus fordernd, wenn auch für heutige Hardware vermutlich nicht mehr. ^^

StefanV

2007-05-14, 23:15:27

Ich glaube das war doch eh immer in den ATI-Treibern als Softwareemulation noch drin, oder nicht?

Wenn nicht, wird's das jetzt vielleicht schon mal wieder geben, wenn das Treiberteam dafür Zeit findet ;) ;)
Nein, hat man beim R300 irgendwann entsorgt, ist also nicht mehr im Treiber drin.

Schrotti

2007-05-14, 23:39:40

Die Matrox Parhelia hatte auch ein 512bit SI und war trotzdem ein Performance Flop.

Soviel zum großen SI.

StefanV

2007-05-14, 23:44:49

Die Matrox Parhelia hatte auch ein 512bit SI und war trotzdem ein Performance Flop.

Soviel zum großen SI.
512bit effektiv :ugly:

In Realität warens 256bit, wie bei R300.

Aquaschaf

2007-05-14, 23:46:56

Die Matrox Parhelia hatte auch ein 512bit SI und war trotzdem ein Performance Flop.

Parhelia hat ein 256bit SI.

Coda

2007-05-14, 23:56:51

Die Matrox Parhelia hatte auch ein 512bit SI und war trotzdem ein Performance Flop.
Es waren 256-Bit. Und es war ja auch ne 4x4-Architektur ;D

deekey777

2007-05-14, 23:57:35

Von gewissen Seiten hört man, dass der R600 erst mit DX10 seine Muskeln spielen lässt. Erste Benchmarks wiederlegen aber auch das. Der Geometryshader des G80 soll nicht toll sein laut einem Posting im B3D Forum. Der G80 ist ein ziemlich abgerundetes Produkt, warum sollte gerade hier wieder gespart worden sein? Wenn dies aber wirklich zutrifft, dann gehört nVidia richtig geschlagen. Das wäre der praktische Tot des GS. Ich hoffe das dem doch nicht so ist und das Treiberteam für den GS noch nicht viel Zeit hatte.
Ich weiß nicht, auf welches Posting du dich gerade beziehst, aber es gibt einen Blogeintrag eines FSX-Entwicklers, wonach die GS-Fähigkeit es des R600 "more powerfull" ist als die des G80. Wenn 1 = GS-Leistung des G80, dann ist 1.1 = GS-Leistung des R600 "more powerfull". Natürlich lässt sich so eine Aussage melken, um die Leistung des R600 als überlegend darzustellen.
Egal.
Was ich nicht so ganz verstehe, warum im R600-Shaderblock die 16 SP (=superskalare Prozessoren :biggrin: ) zu einem Block zusammengefasst wurden und nicht zu vier mit je viel SPs?

http://www.ixbt.com/video3/r600-part2.shtml#p5
(Unglücklicherweise ist das Review auf Digit-Life (noch) auf die Spiele beschränkt.) G80 = 8800GTS 640.
Man schenke Achtung dem "New PS 3.0"-Test: Der R600 hat anahnd diesen Tests mehr als genug an arithmetischer Leistung, aber die hat auch der R580, die Folgen kennen wir.
http://www.3dnews.ru/video/radeon_hd2900xt/index4.htm
(Schonwieder in Russisch, vielleicht gibt's was später bei Digital-Daily.)
Es wird ein von AMD-Mitarbeitern entwickelter D3D10-Test verwendet.
Test 1: absoluter Worst-Case mit voneinander abhängigen Instruktionen (ahoi Coda). Die Leistung ist nicht ein Fünftel, sondern 2/5 des Maximums, denn die "fette" ALU soll von den vier "dünnen" ALUs unabhängig sein.
Test 2: Hier zeigt der R600 seine Muskeln, wenn er ein Vec4 in einzelne unabhängige Vec1-Instruktionen zerteilt und diese parallel abarbeitet. In einem Takt.
Test 3: Die "fette" ALU kommt zum Einsatz. Pro Takt eine SF, der G80 braucht dafür vier Takte.
Test 4: Es werden einzelne skalare unabhängige Instruktionen zu einer superskalaren zusammengefasst. Vorteil R600.

Aber: Der Vorteil des R600 ist gleichzeitig sein größter Nachteil, den der Compiler muss schwitzen ohne Ende, damit die volle Leistungsfähigkeit entfaltet werden kann.

Coda

2007-05-15, 00:05:26

Irgendwas stimmt auch mit den G80-Vertexshadern nicht. Ich denke da hintet der Treiber zu viel in Richtung "nicht so wichtig".

Das ist vermutlich auch das Problem bei den Einbrüchen mit dem GS. Vermutlich sitzt das Treiberteam da noch an einer geeigneten Methode um die Auslastung abschätzen zu können.

up¦²

2007-05-15, 00:09:02

Was haltet ihr von Daves Erklärung
http://forum.beyond3d.com/showthread.php?t=41241&page=7 ff.

Coda

2007-05-15, 00:12:24

Das vertikale Scheduling funktioniert bei R600 nur wenn keine Abhängigkeiten vorhanden sind.

deekey777

2007-05-15, 00:17:42

Was haltet ihr von Daves Erklärung
http://forum.beyond3d.com/showthread.php?t=41241&page=7 ff.
In P178 erklärt er mit dem Buchstabensalat das, was robbi hier gezeigt hat: http://www.3dcenter.org/artikel/radeon_hd_2900_xt/index2.php
Die "dünnen" ALUs arbeiten horizontal, die "fetten" ALUs vertikal.

Coda

2007-05-15, 00:19:06

Muss die fette ja sogar, weil sie ja allein ist und trotzdem manchmal 4-Komponenten-Werte berechnen muss.

deekey777

2007-05-15, 00:50:00

Welchen Vorteil oder Nachteil haben die unabhängigen TU (Texture-Units) der R600? Wie sieht's mit VTF-Performance aus? Diese dürfte besser sein als beim G80.

Edit: Die Einzelnen TUs können gleichzeitig und unabhängig von den Shader-Blöcken Vertex- und Pixel-Thread abarbeiten, die TMUs des G80 können aber nur den Thread bearbeiten, den der Scheduler ihnen zuweist.

Coda

2007-05-15, 00:57:50

Ich hab dir glaub schonmal erklärt, dass D3D10-Shader völlig orthogonale Fähigkeiten besitzen und die gleichen TMUs ansteuern.

Es gibt also keinen Unterschied in der Filterleistung ob Vertex- oder Pixelshader. Wenn dann sind bestimmte Formate auf R600 schneller (was ich bezweifle).

up¦²

2007-05-15, 02:10:34

Falls deplaziert, dann weg damit, aber vielleicht bietet es auch einen Ansatz:
Stop the press! The HD 2900XT is top dog at all resolutions in Rainbow Six: Vegas which was a very pleasant surprise. Again, I remind you dear reader that Vegas is based off of the Unreal 3 engine so it's very possible that we will see similar performance difference when the Unreal series gets updated later this year.
http://www.legitreviews.com/article/503/8/
So: und jetzt erklärt mal, warum? Was ist an der Engine anders, daß sie funzt?

Schrotti

2007-05-15, 03:11:43

Sorry, wusste es nicht mehr genau mit der Parhelia.

Spasstiger

2007-05-15, 08:11:35

Sorry, wusste es nicht mehr genau mit der Parhelia.
Die Parhelia ist jetzt 5 Jahre alt, du glaubst doch wohl selber nicht, dass man damals schon ein 512-Bit-SI für Consumerkarten realisieren konnte. ;)

Die Textureinheiten des R600 heben sich übrigens schon etwas mehr vom R580 ab als es hier im Ausgangsposting dargestellt wird. Zum einen wird jetzt bilineares Filtern von fp16-Texturen in einem Takt unterstützt, zum anderen werden stehen noch zusätzliche Pointsampling-TMUs zur Verfügung, die zusätzliche Pixel- und Vertexfetches quasi kostenlos machen im Gegensatz zum G80.

aths

2007-05-15, 08:16:10

Edit: Die Einzelnen TUs können gleichzeitig und abhängig von den Shader-Blöcken Vertex- und Pixel-Thread abarbeiten, die TMUs des G80 können aber nur den Thread bearbeiten, den der Scheduler ihnen zuweist.Das habe ich jetzt nicht verstanden.

Was ich nicht so ganz verstehe, warum im R600-Shaderblock die 16 SP (=superskalare Prozessoren :biggrin: ) zu einem Block zusammengefasst wurden und nicht zu vier mit je viel SPs?Auch das verstehe ich nicht.

Gast

2007-05-15, 08:41:21

Falls deplaziert, dann weg damit, aber vielleicht bietet es auch einen Ansatz:
http://www.legitreviews.com/article/503/8/
So: und jetzt erklärt mal, warum? Was ist an der Engine anders, daß sie funzt?

Die 2900XT hat eine sehr hohe Rechenleistung, die ohne die SF Units auf dem Niveau der 8800 Ultra liegt. Xbox360 Portierungen sollten der Karte sehr gut liegen, da sie a) ein Abkömmling von Xenos ist und b) eben ihre Rechenleistung 1:1 auszuspielen kann.

deekey777

2007-05-15, 08:44:41

Es war spät, und jetzt ist es viel zu früh.
Das habe ich jetzt nicht verstanden.
http://www.ixbt.com/video3/r600-part1.shtml
Entweder schreibt iXBT malwieder quatsch oder ich verstehe sie falsch: Die TUs haben ihre eigenen Arbiter/Sequencer, die unabhängig von denen der einzelnen Shader-Blöcken sind, "sie müssen nicht auf die Shader-Blöcke warten, bis diese Daten anfordern, sondern können mit der Arbeit gleich beginnen". Auch kann jede einzelne TU einen Pixel-Thread und einen Vertex-Thread bearbeiten.

Auch das verstehe ich nicht.
Es ging mir um die grobe Granularität innerhalb der einzelnen "SIMD" (SIMD nach ATI/AMD ist ein einzelner Shader-Block).

Wie groß ist eigentlich ein Vertex-Thread beim R600?
Die 2900XT hat eine sehr hohe Rechenleistung, die ohne die SF Units auf dem Niveau der 8800 Ultra liegt. Xbox360 Portierungen sollten der Karte sehr gut liegen, da sie a) ein Abkömmling von Xenos ist und b) eben ihre Rechenleistung 1:1 auszuspielen kann.
R6V ist keine Xbox360-Portierung.

aths

2007-05-15, 09:32:00

Es war spät, und jetzt ist es viel zu früh.

http://www.ixbt.com/video3/r600-part1.shtml
Entweder schreibt iXBT malwieder quatsch oder ich verstehe sie falsch: Die TUs haben ihre eigenen Arbiter/Sequencer, die unabhängig von denen der einzelnen Shader-Blöcken sind, "sie müssen nicht auf die Shader-Blöcke warten, bis diese Daten anfordern, sondern können mit der Arbeit gleich beginnen". Auch kann jede einzelne TU einen Pixel-Thread und einen Vertex-Thread bearbeiten. Wenn die Shaderblöcke keine Daten anfordern, was genau sollen die TMUs dann filtern?

Es ging mir um die grobe Granularität innerhalb der einzelnen "SIMD" (SIMD nach ATI/AMD ist ein einzelner Shader-Block).

Wie groß ist eigentlich ein Vertex-Thread beim R600?Das weiß ich nicht, aber so grob finde ich Granularität beim R600 gar nicht.

LovesuckZ

2007-05-15, 09:33:05

Kann der Grund, warum AMD die HD 2900XT so billig verramscht, daranliegen, dass der Chip in der jetzigen Form stark verbuggt ist? Diese MSAA - Shader Sache scheint doch sehr wahrscheinlich zu sein. Auch erkläre dies den fehlenden Mehrgewinn bei einer höhreren Speicherbandbreite (XTX).

AMD confirmed to the french press that they use shaders to do MSAA resolve so IMHO it's clear that R600 ROPs are buggy. No need to discuss 107years about R600 lack of performance, buggy ROPs AA (done par shader) and low texturing power. I hope R650 will fix these issues...
http://forum.beyond3d.com/showpost.php?p=1005182&postcount=258

In a wild bout of pure speculation on our part, we would have to guess about one other problem that popped up during R600's creation. It seems to us that AMD was unable to get their MSAA hardware to work properly and was forced to use shader hardware to handle MSAA rather than go back for yet another silicon revision. Please know that this is not a confirmed fact, but just an educated guess.
http://forum.beyond3d.com/showpost.php?p=1005209&postcount=270

Godmode

2007-05-15, 09:40:27

PCGH_Carsten

2007-05-15, 09:51:38

in einigen reviews wird glaube ich behauptet dass es die tesselierungseinheit aus der box sogar waere und somit genau so funnktioniert.

Das ist exakt das, was AMD in Tunis vor >100 Journalisten behauptete. So direkt lügen werden sie sicherlich nicht.

aths

2007-05-15, 09:52:19

Kann der Grund, warum AMD die HD 2900XT so billig verramscht, daranliegen, dass der Chip in der jetzigen Form stark verbuggt ist?Hä? Billig verramscht? AMD zwingt Nvidia in einen Preiskampf, der uns Kunden hoffentlich nützt. Nvidias Ultra zu 700 € – wer braucht das?

Dass der Chip stark verbuggt sei, wäre mir neu. Beim einigen NV-Chips, z. B. NV40, sind mir hingegen einige Bugs bekannt. Auch bei GF3 und GF4 MX schien nicht alles so gelaufen zu sein wie gedacht, von der GF4 Ti ganz zu schweigen. Die FX-Serie brauche ich hoffentlich auch nicht noch mal zu erwähnen – insbesondere NV31. Dass der fertige Chip einige nicht geplante Probleme in HW hat, hat NV in der Vergangenheit öfter erleben müssen. Davon dass der Chip "stark verbuggt" sei, hast du aber nie gesprochen.

Diese MSAA - Shader Sache scheint doch sehr wahrscheinlich zu sein. Auch erkläre dies den fehlenden Mehrgewinn bei einer höhreren Speicherbandbreite (XTX).Vergleicht man Produkte bei gleichen Preisen (und rechnet noch eine kleine Preissenkung der neuen Radeons in der nächsten Zeit ein) steht AMD doch ziemlich gut da.

aths

2007-05-15, 09:53:10

Das ist exakt das, was AMD in Tunis vor >100 Journalisten behauptete. So direkt lügen werden sie sicherlich nicht.Wurde in Tunis auch behauptet, dass CFAA mit Edge Detection das Texture Shimmering senken würde?

TheRealTentacle

2007-05-15, 09:54:19

Ich hab mal eine Frage ...

Wie hoch ist die Point Sampling Füllrate der in dem 3D Center Artikel angesprochenden 16 Point Sampling Einheiten, und in wie fern lassen sich diese nutzen?

Für viele Effekte reicht doch Point Sampling aus, und die ließen sich doch dann auf diese Einheiten auslagern, oder nicht?

aths

2007-05-15, 09:56:42

Ich hab mal eine Frage ...

Wie hoch ist die Point Sampling füllrate der in dem 3D Center Artikel angesprochenden 16 Point Sampling einheiten, und in wie fern lassen sich diese Nutzen?

Für viele Effekte reicht doch Point Sampling aus, und die ließen sich doch dann auf diese Einheiten auslagern, oder nicht?Das meiste was im Pixelshader genutzt wird, sollte gefiltert werden.

LovesuckZ

2007-05-15, 09:59:22

Vergleicht man Produkte bei gleichen Preisen (und rechnet noch eine kleine Preissenkung der neuen Radeons in der nächsten Zeit ein) steht AMD doch ziemlich gut da.

Ja, bis auf ein angebliches AA- bzw. RBE-Problem.
Ich bezweifel, dass AMD die Karte für sowenig Geld anbieten möchte, da andere Eigenschaften deutlich auf einem GTX Killer hinweisen, dem man wohl eher für 500€ statt 350€ verkaufen wollte.

PCGH_Carsten

2007-05-15, 10:03:31

Wurde in Tunis auch behauptet, dass CFAA mit Edge Detection das Texture Shimmering senken würde?

Nicht, dass ich mich erinnern könnte.

DaEmpty

2007-05-15, 10:07:33

LovesuckZ

2007-05-15, 10:19:29

Dass der fertige Chip einige nicht geplante Probleme in HW hat, hat NV in der Vergangenheit öfter erleben müssen. Davon dass der Chip "stark verbuggt" sei, hast du aber nie gesprochen.

Abgesehen davon, dass das mehr als ein Tag zurückliegt, weiß ich nicht, ob eine bewusste Designentscheidung mit verbuggten Einheiten gleichzusetzen ist. Beide liefern zwar ein ähnliches Ergebnis - unterirdische Leistung, sind wohl von der Herangehensweise doch zu unterscheiden.
Oder macht es Sinn, die Recheneinheiten für AA zu verwenden und so die Last von der Bandbreite auf jene umzulagern?

Spasstiger

2007-05-15, 10:22:57

Vielleicht bekommen sie bei 65-nm-Fertigung auch 24 oder gar 32 Texturfilter-Einheiten unter, was den Chip mehr als konkurrenzfähig machen sollte.
Das Gute am R600 ist auf jeden Fall: AMD/ATI kann auf ein 512-Speicherinterface zurückgreifen, Bandbreitenprobleme sind deshalb in nächster Zeit nicht zu erwarten.
Und dass Nivida in den nächsten Monaten auch ein 512-Bit-SI aus dem Boden stampft, glaube ich nicht.
Sollte man mit einem Refresh den Rest in den Griff bekommen, d.h. die Treiberprobleme, die schwache AA-Performance und die schwache TMU-Leistung, dann hat der R6XX das Potential, den G80 in jetziger Form deutlich zu schlagen, v.a. wenn fp16-HDR-Rendering zusammen mit fp16-Texturen eingesetzt wird.

DrumDub

2007-05-15, 10:48:59

das komische beim r600 sind in erster linie die unterirdischen ergebnisse mit msaa. da bricht der r600 viel zu stark ein. wenn die rops wirklich kaputt sind, dann wird man da wohl nicht mehr viel machen können, außer für jedes spiel dass shader-aa von hand zu optimieren...

sieht man schön bei den benches hier zu oblivion: http://www.techreport.com/reviews/2007q2/radeon-hd-2900xt/index.x?pg=13

ohne aa liegt die hd2900xt zwischen der 8800gts und der gtx. mit 4xmsaa fällt sie dann hinter die 8800gts zurück...
mit dem neuen alpha-treiber und optimierten shader-aa (?) liegt hd2900xt dann wieder vor der 8800gts...

Godmode

2007-05-15, 11:01:33

,vv

Warum meinst du auch das die Rops kaputt sind, oder wars ein Fehler weil du das Posting wieder gelöscht hast?

DrumDub

2007-05-15, 11:04:53

Warum meinst du auch das die Rops kaputt sind, oder wars ein Fehler weil du das Posting wieder gelöscht hast? habs noch mal editiert... jetzt sollte die begründung besser passen.

die theoretischen werte beim r600 bei 2x/4xmsaa sind übrings auch weit hinter denen des g80 und können sich nur leicht vom r580 absetzen: http://www.hardware.fr/medias/photos_news/00/19/IMG0019966.gif

Odal

2007-05-15, 11:16:15

hm nur soll doch dieser ominöse "alphatreiber" aus dem CB treibervergleich lediglich das adaptive AA durch EATM ersetzt haben....

das heisst doch nicht das das normale multisampling aa anders läuft....

das irgendetwas sehr im argen ist wenn AA in benutzung kommt ist offensichtlich...

hat das ding überhaupt ROPs? Ich mein nicht das von vornherein angedacht war AA ausschliesslich mittels shadern zu realisieren um da sehr flexibel zu sein. Wir hatten hier ja schonmal die diskussion über flimmereien durch shaderaliasing und die möglichkeit das per aa im pixelshader zu beheben und die möglichkeit bei z.b. dem G70/71 das fehlende AA bei HDRR benutzung über aa mittels shadern (sehr langsam) umzusetzen...

daher meine fragen...

1. hat der R600 überhaupt echte ROPS
2. könnten die wirklich defekt sein?
3. könnte der starke einbruch durch AA darauf hindeuten das das AA komplett mittels shadern realisiert wird?
4. kann man das irgendwie testen?

DrumDub

2007-05-15, 11:42:01

hm nur soll doch dieser ominöse "alphatreiber" aus dem CB treibervergleich lediglich das adaptive AA durch EATM ersetzt haben....
bei techreport nutzen sie afaik kein aaa/trssaa.

hat das ding überhaupt ROPs? ja, denn rops brauchste ja nicht nur fürs msaa: http://www.beyond3d.com/content/reviews/16/10

PCGH_Carsten

2007-05-15, 11:46:46

1. hat der R600 überhaupt echte ROPS
2. könnten die wirklich defekt sein?
3. könnte der starke einbruch durch AA darauf hindeuten das das AA komplett mittels shadern realisiert wird?
4. kann man das irgendwie testen?

1. Ja, heißen bei AMD aber Render-Backends
2. Klar "könnten" die, gesichert ist das nicht
3. Könnte, ist aber unwahrscheinlich. CFAA wird unter Zuhilfenahme der Shader gemacht.
4. Ja, ist aber aufwendig - es sei denn, man kann selbst programmieren.

Coda

2007-05-15, 11:58:24

Kann der Grund, warum AMD die HD 2900XT so billig verramscht, daranliegen, dass der Chip in der jetzigen Form stark verbuggt ist? Diese MSAA - Shader Sache scheint doch sehr wahrscheinlich zu sein. Auch erkläre dies den fehlenden Mehrgewinn bei einer höhreren Speicherbandbreite (XTX).

http://forum.beyond3d.com/showpost.php?p=1005182&postcount=258

http://forum.beyond3d.com/showpost.php?p=1005209&postcount=270
Das ergibt aber keinen Sinn.

Das MSAA-Resolving wird nicht durch die ROPs durchgeführt, sondern maximal On-Scanout durch den RAMDAC. Ich glaub der hat da was falsch verstanden. Das CFAA-Resolving wird durch die Shader ausgeführt, das normale wohl wie früher.

Wenn die ROPs defekt wären für MSAA würden die Samples erst gar nicht richtig im VRAM landen und damit wäre gar kein AA möglich. Ist es aber.

das waere deren prozedurale synthese auch und trotzdem hoert man so gut wie nie davon.
Was für eine "prozedurale Synthese"? Prozedurale Shader oder wie? Das kann auch ein R300.

Das ist exakt das, was AMD in Tunis vor >100 Journalisten behauptete. So direkt lügen werden sie sicherlich nicht.
Anscheinend? Ich hab auf keinem Diagram zu C1 oder irgendwelchem anderen Xbox-Material irgendwas in diese Richtung gesehen. Das ist schon sehr mysteriös.

Gast

2007-05-15, 12:07:25

3. Könnte, ist aber unwahrscheinlich. CFAA wird unter Zuhilfenahme der Shader gemacht.
Die Implementation ihres Edge-Detection-Filters lässt schon vermuten, dass die ROPs/RBEs zumindest keinerlei Resolve können. Außerhalb von Poligonkanten Boxfilter, sonst ein ziemlich breites Zelt... Wieso eigentlich überhaupt dann außerhalb von Poligonkanten filtern, wenn man auch ein beliebiges Sample aus den betreffenden Pixeln nehmen kann? Macht eh keinen Unterschied mit reinem MSAA bzw. außerhalb von Alphatest/-blend-beinhaltenden Pixeln mit EATM/AAA. Würde mich nicht wundern, wenn bald auch Edge-Detection-Filter mit schmaleren Filterkernels nachgeschoben werden, um die Shader zu entlasten.

DrumDub

2007-05-15, 12:07:41

Das MSAA-Resolving wird nicht durch die ROPs durchgeführt, sondern maximal On-Scanout durch den RAMDAC. Ich glaub der hat da was falsch verstanden. hmm.... also rys bei b3d ist sich relativ sicher, dass da das problem liegt:Hardware resolve is actually done in the ROP on R600, but only for fully compressed tiles. I write that in the article. So I don't need to state that it was the plan to use the ROP for downsampling, because that's actually what's happening (unless you argue that reading just one value doesn't count, because there was no math involved to weight other samples) for one case.

And I also say that I lean towards the case that the hardware is broken because they have to downsample on the shader core for non fully compressed tiles, even if they can pass the decompressed samples back with a fast path. http://forum.beyond3d.com/showpost.php?p=1005255&postcount=289

edit: hier seine weiteren vermutungen zu dem problem: http://forum.beyond3d.com/showpost.php?p=1005269&postcount=294

Coda

2007-05-15, 12:16:15

Ach das Downsampling machen doch die ROPs normal? Okay, war mir neu. Kann schon sein.

Ronny145

2007-05-15, 12:17:33

Würde das also bedeuten, dass es nicht am Treiber liegt? Dieses Shader AA müsste für jedes Spiel extra angepasst werden?

Coda

2007-05-15, 12:20:53

Nein. Das Resolving ist ja immer gleich.

Aber wo du's grad ansprichst: Jetzt weiß ich auch woher die Gerüchte um ein angebliches "Shader-AA" kamen :D

up¦²

2007-05-15, 12:27:28

Coda

2007-05-15, 12:29:21

Warum sollte es? :|

aths

2007-05-15, 12:33:55

Nicht, dass ich mich erinnern könnte.Es steht jedenfalls in offiziellen Presse-Materalien und iirc auch in einem CB-Artikel.

Ronny145

2007-05-15, 12:41:22

Nein. Das Resolving ist ja immer gleich.

Also mit nem Treiber ist da nichts mehr zu machen?

aths

2007-05-15, 12:46:55

Abgesehen davon, dass das mehr als ein Tag zurückliegt, weiß ich nicht, ob eine bewusste Designentscheidung mit verbuggten Einheiten gleichzusetzen ist. Beide liefern zwar ein ähnliches Ergebnis - unterirdische Leistung, sind wohl von der Herangehensweise doch zu unterscheiden. Bei NV25 und NV31 gibt es richtige Bugs. Beim NV20 gabs anfangs auch Bugs, die erst in späteren Revisionen behoben wurden. Beim NV40 gab es Bugs.

Oder macht es Sinn, die Recheneinheiten für AA zu verwenden und so die Last von der Bandbreite auf jene umzulagern?Die Redewendung "Sinn machen" ergibt im Deutschen keinen Sinn.

Der Trend geht nun mal dazu, immer mehr von dem, was früher mit FF (fixed function) gelöst wurde, im programmierbaren Teil auszuführen.

Ja, bis auf ein angebliches AA- bzw. RBE-Problem.
Ich bezweifel, dass AMD die Karte für sowenig Geld anbieten möchte, da andere Eigenschaften deutlich auf einem GTX Killer hinweisen, dem man wohl eher für 500€ statt 350€ verkaufen wollte.Hrm? Nur weil der R600 dem G80 an einigen Stellen was voraus hat, leitest du daraus ab dass er als GTX-Killer geplant war? R600 wurde, wenn man die Architektur betrachtet, unabhängig von Nvidias Plänen als arithmetikstarke D3D10-Karte mit besonderer HDR-Rendering-Tauglichkeit entwickelt.

Gast

2007-05-15, 12:52:46

Also mit nem Treiber ist da nichts mehr zu machen?Schwer zu sagen. Falls die HW das kann wäre es vielleicht möglich, mit den Resolveshadern ansonsten leerlaufende ALUs zu füttern. Wie viel das bringen könnte falls es geht ist auch fraglich, denn auch wenn die R600-ALUs etwas weniger "skalar" sind als die von G8x, sollten sie dennoch mit guten Treibern oft so weit auszulasten sein, dass die ALUs kaum leerlaufen.

aths

2007-05-15, 12:59:18

Schwer zu sagen. Falls die HW das kann wäre es vielleicht möglich, mit den Resolveshadern ansonsten leerlaufende ALUs zu füttern. Wie viel das bringen könnte falls es geht ist auch fraglich, denn auch wenn die R600-ALUs etwas weniger "skalar" sind als die von G8x, sollten sie dennoch mit guten Treibern oft so weit auszulasten sein, dass die ALUs kaum leerlaufen.Obwohl mir die R600-ALUs im Detail noch nicht verständlich sind, nehme ich auch stark an, dass bei ausgereiften Schedulern die ALU-Leerlaufzeit minimal ist.

Gaestle

2007-05-15, 12:59:22

Bei NV25 und NV31 gibt es richtige Bugs. Beim NV20 gabs anfangs auch Bugs, die erst in späteren Revisionen behoben wurden. Beim NV40 gab es Bugs.

Die Redewendung "Sinn machen" ergibt im Deutschen keinen Sinn.

Hrm? Nur weil der R600 dem G80 an einigen Stellen was voraus hat, leitest du daraus ab dass er als GTX-Killer geplant war?

Ich persönlich finde, DIESE Diskussionen haben mit dem Thema des Threads (R600 Architektur) nichts zu tun und tragen eher dazu bei, dass wirkliche Informationen durch Spam und Flame verdeckt werden.

aths

2007-05-15, 13:04:24

Ich persönlich finde, DIESE Diskussionen haben mit dem Thema des Threads (R600 Architektur) nichts zu tun und tragen eher dazu bei, dass wirkliche Informationen durch Spam und Flame verdeckt werden.Ich kann es nicht ab wenn bei ATI/AMD groß von Bugs geredet wird und bei NV nicht. Fehler machen beide IHVs.

Insgesamt halte ich die G80-Architektur für ausgewogener und skalierbarer, transistoreffizienter und stromsparender. Das ist kein Grund, an der R600-Architektur herumzumäkeln – vor allem, da ich viele Details noch gar nicht verstanden habe. Spekulation: AMD legt nach, und am Ende könnte es so aussehen wie 1950 vs 7900: AMD hat die Nase vorn.

PCGH_Carsten

2007-05-15, 13:15:37

Anscheinend? Ich hab auf keinem Diagram zu C1 oder irgendwelchem anderen Xbox-Material irgendwas in diese Richtung gesehen. Das ist schon sehr mysteriös.

Hier ist "irgendwas in der Richtung" - zwei Minuten Google und drei Minuten um das Bild klein genug zu bekommen, damit es in den Anhang passt.
Stammt von hier: http://www.doggetts.org/michael/x05-xenos-doggett.pdf

Es steht jedenfalls in offiziellen Presse-Materalien und iirc auch in einem CB-Artikel.

Ich verstehe nicht, was du mir damit sagen willst?

Gmax

2007-05-15, 13:25:14

deekey777

2007-05-15, 13:29:16

Weils ein X360 Port ist?
Îst es nicht.
R6V (Xbox360) = UE 2.5
R6V (PC) = UE 3.0

Und wie ich schon in einem anderen Thread gelästert habe:
Wenn Halo 2 (PC) auf der Geforce schneller ist als auf der Radeon, ist es nur darauf zurückzuführen, weil in der Xbox der NV2A steckt?

Coda

2007-05-15, 13:53:26

Hier ist "irgendwas in der Richtung" - zwei Minuten Google und drei Minuten um das Bild klein genug zu bekommen, damit es in den Anhang passt.
Okay, vielen Dank.

Gast

2007-05-15, 13:57:46

Würde das nicht erklären, warum der R600 so gut funktioniert bei Rainbow Six: Vegas (Unreal 3 engine !)
http://www.legitreviews.com/images/reviews/503/vegas_3.gif
http://www.legitreviews.com/article/503/8/

ich tippe mal auf ein treiberproblem bei NV, die G80-treiber sind ja auch noch nicht so ganz das wahre.

jedenfalls ist die radeon in R6 zwar überall gut, allerdings nicht dermaßen überlegen.

http://www.techreport.com/reviews/2007q2/radeon-hd-2900xt/index.x?pg=13

LovesuckZ

2007-05-15, 15:33:12

Îst es nicht.
R6V (Xbox360) = UE 2.5
R6V (PC) = UE 3.0

Schreibe mir doch bitte per PN, welche Unterschiede zwischen den Versionen bestehen. Danke.

Und wie ich schon in einem anderen Thread gelästert habe:
Wenn Halo 2 (PC) auf der Geforce schneller ist als auf der Radeon, ist es nur darauf zurückzuführen, weil in der Xbox der NV2A steckt?

Willst du behaupten, dass zwischen dem NV2A und dem G80 genauso viele Gemeinsamkeiten bestehen wie zwischen Xenos und r600? Es ist doch unübersehbar, dass Xenos als sehr deutliche Grundlage für den r600 verwendet und erweitert wurde. In allen Xbox360 Portierungen, bis auf Carbon wegen eines Bugs, läuft die Karte auf dem Niveau der 8800Ultra. Das ist auch nicht verwundelich, da beide die ungefähr gleiche MADD-Leistung erreichen. Schaut man sich Spiele an, die keine Xbox360 Herkunft haben, sieht es dagegen schon schlechter aus. Zufall?
Ich denke nicht. Hier zeigt es sich, dass Xbox360 Entwicklung sehr stark die Rechenleistung beanspruchen und sogut wie möglich versuchen Xenos optimal auszulasten. Und davon soll die 2900XT nicht profitieren?

reunion

2007-05-15, 15:58:36

Anscheinend? Ich hab auf keinem Diagram zu C1 oder irgendwelchem anderen Xbox-Material irgendwas in diese Richtung gesehen. Das ist schon sehr mysteriös.

Es gab auch kaum Material zu Xenos. Bei einem der weniger Technikartikel auf B3D wird allerdings sehrwohl darauf hingewiesen.

Godmode

2007-05-15, 16:01:43

Ich denke nicht. Hier zeigt es sich, dass Xbox360 Entwicklung sehr stark die Rechenleistung beanspruchen und sogut wie möglich versuchen Xenos optimal auszulasten. Und davon soll die 2900XT nicht profitieren?

Ich kenn die Texelleistung der XBOX nicht, aber vermutlich wird diese auch ziemlich gering sein und dadurch muss man sie gut verstecken. Es wird dann einfach mehr gerechnet als texturiert und die Berechnungen dürften dem R600 sicherlich gut schmecken, da der Xenos doch einen ähnlichen Aufbau hat. Eventuell könnte nVidia hier mit einem neuen Treiber nachhelfen.

LovesuckZ

2007-05-15, 16:05:56

Ich kenn die Texelleistung der XBOX nicht, aber vermutlich wird diese auch ziemlich gering sein und dadurch muss man sie gut verstecken. Es wird dann einfach mehr gerechnet als texturiert und die Berechnungen dürften dem R600 sicherlich gut schmecken, da der Xenos doch einen ähnlichen Aufbau hat.

Xenos hat 8 ROPs (4c/8z - Samples) und 16 INT8 TMUs, die einen Takt von 500MHz besitzen. Das Verhältnis zwischen Textur- und Rechenleistung wurde bei der 2900XT fast beibehalten.

Gast

2007-05-15, 16:11:37

Ich denke, man sollte mal noch einige Wochen wartem, bevor man endgültige Aussagen über die Architektur treffen kann. Im Moment ist da noch zu vieles im unklaren.

Gast

2007-05-15, 17:12:44

Ich denke, man sollte mal noch einige Wochen wartem, bevor man endgültige Aussagen über die Architektur treffen kann. Im Moment ist da noch zu vieles im unklaren.

stimmt, wobei ich kaum denke dass ATI da noch wahnsinnig viel rausholen kann, bei der verspätung sollte das treiberteam eigentlich genug zeit haben.

micki

2007-05-15, 17:15:24

stimmt, wobei ich kaum denke dass ATI da noch wahnsinnig viel rausholen kann, bei der verspätung sollte das treiberteam eigentlich genug zeit haben.
woher willst du wissen das nicht genau der treiber das grosse problem war? :)

naja, nv hat ja auch noch einiges an leistung rausgekratzt, kann man von ati auch hoffen. ansonsten einfach gegen die ersten nv treiber benchen, damit man sehen kann worauf zu hoffen ist.

Gast

2007-05-15, 18:53:38

stimmt, wobei ich kaum denke dass ATI da noch wahnsinnig viel rausholen kann, bei der verspätung sollte das treiberteam eigentlich genug zeit haben.

Man darf dabei nicht vergessen, daß im Grunde nicht ein sondern 3 Treiber zu programmieren sind. DX9 für Win2k/XP, DX9L für Vista und DX10 für Vista.
Und OpenGL natürlich.

up¦²

2007-05-15, 21:37:30

Gast

2007-05-15, 21:44:36

weiß jemand wie der chip mit erhötem pcie-takt skaliert? eventuell mit link... ich find nix passendes

Coda

2007-05-15, 21:47:31

Könnte es nicht auch an der CPU-GPU Synchronization liegen?
Darüber wurde vonm Programmierern doch beim Xenos schon geklagt...
Was in der Richtung?
http://arstechnica.com/articles/culture/mattlee.ars/3
Das ist bei jeder GPU der Fall.

weiß jemand wie der chip mit erhötem pcie-takt skaliert? eventuell mit link... ich find nix passendes
Sehr wahrscheinlich gar nicht.

up¦²

2007-05-15, 21:54:03

Hier noch ein interessanter Ansatz:
http://media.arstechnica.com/news.media/AMD-ACSS.gif
The CAL and HAL portions of ACSS are complex yet integral parts of the driver for the R600 family, and I'd bet money that together they're one of the bottlenecks that's holding back the system from achieving its full potential on gaming benchmarks. It appears that on all of the benchmarks run so far, both DX9 and DX10, all of the graphics calls are going to the CAL via the DirectX and OpenGL CAL bindings, where they're dynamically farmed out to the available stream computing resources on the GPU. If the CAL/HAL stack, which is a brand new piece of software that probably has quite a bit of optimization overhead left in it, doesn't do its job optimally, then the graphics code that's running on it won't be able to get peak performance out of the hardware.
http://arstechnica.com/news.ars/post/20070514-amd-launches-the-hd-2000-series.html

BTW: Xenos
http://arstechnica.com/articles/paedia/cpu/xbox360-1.ars

deekey777

2007-05-15, 22:16:57

Wäre es möglich, das Thread-Thema zu achten?

Exxtreme

2007-05-15, 23:04:51

Coda

2007-05-15, 23:08:53

Wenn man das AA über die Shader macht, müsste es doch möglich sein pro Polygonkante eine individuelle Subpixelmaske wählen zu können oder?
Nur das Resolving wird über die Shader gemacht. Die ROPs geben das Subpixelmuster vor.

robbitop

2007-05-16, 15:10:55

Willst du behaupten, dass zwischen dem NV2A und dem G80 genauso viele Gemeinsamkeiten bestehen wie zwischen Xenos und r600?
Immerhin die NV typische MUL-lastigkeit.

Coda

2007-05-16, 15:30:17

Bei NV2A gab's schon ne MUL-Lastigkeit?

robbitop

2007-05-16, 15:36:40

Bei NV2A gab's schon ne MUL-Lastigkeit?
Die NV Combiner hatten schon (fast) immer doppelt so viele MULs wie ADDs. Klar lassen sich jetzt auch ein paar Gegenbeispiele nennen.

Gast

2007-05-16, 15:37:14

Mal was anderes, schon in den anderen Threads angesprochen - wenn es es hardwareseitiges Problem ist, warum kann sich die HD 2900XT dann in OGL mit GTX/Ultra messen...?

Godmode

2007-05-16, 15:56:25

Mal was anderes, schon in den anderen Threads angesprochen - wenn es es hardwareseitiges Problem ist, warum kann sich die HD 2900XT dann in OGL mit GTX/Ultra messen...?

hier noch die Links dazu:
http://www.computerbase.de/artikel/hardware/grafikkarten/2007/test_ati_radeon_hd_2900_xt/18/#abschnitt_doom_3
http://www.computerbase.de/artikel/hardware/grafikkarten/2007/test_ati_radeon_hd_2900_xt/25/#abschnitt_the_chronicles_of_riddick

Die Karte ist da wirklich nicht schlecht.

Gast

2007-05-16, 21:42:03

Mal was anderes, schon in den anderen Threads angesprochen - wenn es es hardwareseitiges Problem ist, warum kann sich die HD 2900XT dann in OGL mit GTX/Ultra messen...?

Da es in OGL kaum Engines gibt, wird AMD wohl weiterhin auf ihre Shadereplacement setzen. Ich wette, wenn man A.I ausstellt, wird die Karte wieder auf ein "normales" D3D Maß einbrechen.

Tigerchen

2007-05-17, 07:49:41

Die Parhelia ist jetzt 5 Jahre alt, du glaubst doch wohl selber nicht, dass man damals schon ein 512-Bit-SI für Consumerkarten realisieren konnte. ;)

Damals wurde das behauptet und von keinem in Frage gestellt. Ich erinner mich noch gut an die Hype bis die ersten ernüchternden Benches kamen.

Odal

2007-05-17, 07:59:18

Da es in OGL kaum Engines gibt, wird AMD wohl weiterhin auf ihre Shadereplacement setzen. Ich wette, wenn man A.I ausstellt, wird die Karte wieder auf ein "normales" D3D Maß einbrechen.
das ist doch quatsch dann wäre der R600 ohne AA&AF deutlich schneller als der G80 und würde unter verwendung von AA&AF genauso einbrechen wie unter DX nur das aufgrund der hohen leistung er mit AA&AF gleich auf mit dem G80 wäre...dem ist aber nicht so....

wenn was "optimiert" wurde dann höchstens das AF...und das gilt es eben noch herauszufinden

Spasstiger

2007-05-17, 11:22:38

Damals wurde das behauptet und von keinem in Frage gestellt. Ich erinner mich noch gut an die Hype bis die ersten ernüchternden Benches kamen.

Der Karte hätte vermutlich nichtmal ein 128-Bit-SI geschadet. ;)
Sieht man ja auch an der GeForce FX 5800, trotz 128 Bit SI konnte die Karte in Nicht-Shader-Games eine Radeon 9700 Pro übertrumpfen. Ok, mit 4xAA war die 9700 Pro dann doch etwas vorne, nur war damals AntiAliasing den Spielern noch nicht so wichtig wie heute.

CompuJoe

2007-05-17, 11:28:57

Das wird wohl so ähnlich ablaufen wie bei nv.

Wartet mal noch 1 bis 2 Treiber ab und die Karten sind mind. gleich auf.

Coda

2007-05-17, 11:39:29

Damals wurde das behauptet und von keinem in Frage gestellt. Ich erinner mich noch gut an die Hype bis die ersten ernüchternden Benches kamen.

Es wurde gar nichts behauptet. Die Karte hatte aber nur ein 256-Bit-Interface (damals waren noch 128 Bit üblich).

Gast

2007-05-17, 11:54:42

Wartet mal noch 1 bis 2 Treiber ab und die Karten sind mind. gleich auf.
Gut vorstellbar - aber das wird noch eine schwere Geburt IMO. Grund: VLIW-Optimierungen laufen eher auf pro-Game-Basis und aktuell hat das arme Treiberteam von AMD und die 100 Beta-Tester schon mehr als genug Baustellen:

- XP
- Vista x32
- Vista x64
- Crossfire (oh-ho - jetzt doch mit Profilen...)
- OpenGL (unter XP fehlt noch etwas, das wie SM4 ist

robbitop

2007-05-17, 12:14:24

Das AF vom NV30 trug auch ihrem Teil dazu bei. Teuer aber auch besser. Aber auch das hat damals keinen interessiert.

Simon Moon

2007-05-17, 13:04:05

Damals wurde das behauptet und von keinem in Frage gestellt. Ich erinner mich noch gut an die Hype bis die ersten ernüchternden Benches kamen.

Effektiv sind es auch 512Bit. War zu dieser Zeit nicht unüblich, das DDR Verfahren einfach als Verdoppelung des SI zu bezeichnen.

So gesehen hätte der R600 heute eben ein 1024Bit SI...

Aber offenbar erinnerst du dich doch nicht so gut an den Hype damals...

Gast

2007-05-17, 14:11:25

Wartet mal noch 1 bis 2 Treiber ab und die Karten sind mind. gleich auf.

kaum, die karte hat einfach zu wenig füllrate, da tut AF verdammt weh.

aber zumindest vor der 8800GTS sollte sich ein halbwegs ordentlicher abstand ausgehen, gegen GTX/Ultra wird sie aber im großen und ganzen nicht mithalten können, vor allem wenn AF ins spiel kommt, wobei es natürlich auch wieder ein paar ausnahmen geben wird.

aths

2007-05-17, 14:37:39

Gut vorstellbar - aber das wird noch eine schwere Geburt IMO. Grund: VLIW-Optimierungen laufen eher auf pro-Game-Basis und aktuell hat das arme Treiberteam von AMD und die 100 Beta-Tester schon mehr als genug Baustellen:

- XP
- Vista x32
- Vista x64
- Crossfire (oh-ho - jetzt doch mit Profilen...)
- OpenGL (unter XP fehlt noch etwas, das wie SM4 istIch würde das nicht am VLIW festmachen. VLIW oder nicht VLIW ist per se weder gut noch schlecht. ATIs Arithmetikunits sind etwas schwieriger optimal auszulasten, dafür ist die Maximalleistung höher.

Gast

2007-05-17, 14:41:29

Ich würde das nicht am VLIW festmachen. VLIW oder nicht VLIW ist per se weder gut noch schlecht. ATIs Arithmetikunits sind etwas schwieriger optimal auszulasten, dafür ist die Maximalleistung höher.
Das war rein darauf bezogen, dass die Optimierungen mit VLIW eher auf spezielle Games angepasst werden müssen, da generelle Optimierungen damit eher schwierig sind.

aths

2007-05-17, 14:48:54

Mal eine Frage am Rande:

Wenn man das AA über die Shader macht, müsste es doch möglich sein pro Polygonkante eine individuelle Subpixelmaske wählen zu können oder? Oder gar gleich selbst eine zum Winkel passende Maske errechnen können. Dann könnte man es gleich analytisch machen. Man weiß doch vorher nicht, was später für noch Daten (neue Dreiecke, neue Kanten) kommen. Was machst danN?

Bei NV2A gab's schon ne MUL-Lastigkeit?Schon bei NV10, wenn nicht schon bei NV4.

Das war rein darauf bezogen, dass die Optimierungen mit VLIW eher auf spezielle Games angepasst werden müssen, da generelle Optimierungen damit eher schwierig sind.Generelle Optimierungen sind ganz gut möglich. Der Shader muss ja "nur" so sortiert werden, dass man möglichst keine "Leerblasen" in den Instruktionen inkauf nehmen muss.

Gast

2007-05-17, 18:24:25

AMD explains Radeon HD 2900XT's poor AA performance

We asked Richard Huddy, Worldwide Developer Relations Manager of AMD's Graphics Products Group, to go into more detail about why the Radeon HD 2000-series architecture has been optimised for shader-based AA rather than traditional multi-sample AA. He told us that 'with the most recent generations of games we've seen an emphasis on shader complexity (mostly more maths) with less of the overall processing time spent on the final part of the rendering process which is "the AA resolve". The resolve still needs to happen, but it's becoming a smaller and smaller part of the overall load. Add to that the fact that HDR rendering requires a non-linear AA resolve and you can see that the old fashioned linear AA resolve hardware is becoming less and less significant.' Huddy also explained that traditional AA 'doesn't work correctly [in games with] HDR because pixel brightness is non-linear in HDR rendering.'

While many reviews of the HD 2900XT have made unflattering comparisons between it and Nvidia's GeForce 8800-series, Huddy was upbeat about AMD's new chip. 'Even at high resolutions, geometry aliasing is a growing problem that can only really be addressed by shader-based anti-aliasing. You'll see that there is a trend of reducing importance for the standard linear AA resolve operation, and growing importance for custom resolves and shader-based AA. For all these reasons we've focused our hardware efforts on shader horsepower rather than the older fixed-function operations. That's why we have so much more pure floating point horsepower in the HD 2900XT GPU than NVIDIA has in its 8800 cards... There's more value in a future-proof design such as ours because it focuses on problems of increasing importance, rather than on problems of diminishing importance."

http://www.custompc.co.uk/custompc/news/112773/amd-explains-poor-radeon-hd-2900xt-aa-performance.html

Schlechtes Zeichen, dass er nicht sagt, dass es in zukünftigen Treibern Besserungen geben wird?

d2kx

2007-05-17, 18:47:23

Ohne Experte zu sein, dürfte die X2900 zumindest nach ihm ja dann zukünftig immer besser abschneiden (immer besser bezogen auf "holt die GF 8800 immer mehr ein").

Coda

2007-05-17, 18:53:47

to go into more detail about why the Radeon HD 2000-series architecture has been optimised for shader-based AA rather than traditional multi-sample AA.
Muahahaha. "Optimized". Der is geil ;D

The resolve still needs to happen, but it's becoming a smaller and smaller part of the overall load. Add to that the fact that HDR rendering requires a non-linear AA resolve and you can see that the old fashioned linear AA resolve hardware is becoming less and less significant.'
Und? Er ist trotzdem schwein-lahm momentan auf der R600. Bei der Bandbreite sollte es eigentlich fast nichts kosten.

Huddy also explained that traditional AA 'doesn't work correctly [in games with] HDR because pixel brightness is non-linear in HDR rendering.'
Soso. Tut es auf G80 und R580 wunderbar in den heutigen Spielen. Und das downfiltering ist bereits nicht-linear.

Auf gut Deutsch: Er redet sich ziemlich beschissen raus. Naja gut, was hätte er auch sonst antworten können, man kann den armen Mann ja verstehen ;)

Gast

2007-05-17, 18:57:45

Wie sieht es eigentlich bei Xenos aus? Gibt es dort ebenfalls diese AA Probleme?

Coda

2007-05-17, 18:59:59

Nein, C1 kann AA komplett umsonst, weil die ROPs ins eDRAM eingebaut sind. Kann man aber nicht mit R600 vergleichen.

Gast

2007-05-17, 19:12:38

da Frage ich mich nur warum AMD derart andere Wege einschlägt:
Von "aa fast Umsonst" zu "aa und ab hier geht nichts mehr"?

Coda

2007-05-17, 19:25:24

Gast

2007-05-17, 19:30:52

Nein, C1 kann AA komplett umsonst, weil die ROPs ins eDRAM eingebaut sind. Kann man aber nicht mit R600 vergleichen.

*Hust* das bezweifle ich mal das C1/Xenos, also der Grafik Chip der Xbox360 das umsonst kann. Es wird quasi nie angewendet da Spieleentwickler 60FPS erzielen wollen. 2xAA is das höchste der Gefühle und 4xAA nur in nichtssagenden Replays. Gibt ja nichtmal gescheites AF, in keinem einzigen Spiel bisher.

Coda

2007-05-17, 19:33:08

*Hust* das bezweifle ich mal das C1/Xenos, also der Grafik Chip der Xbox360 das umsonst kann.
Dann bezweifel mal weiter, es ändert nichts an den Tatsachen. Es geht nur recht schnell der eDRAM aus. In 720p reicht es nur noch für 2xAA.

Falls höhere AA Modi in den hohen Auflösungen gefahren werden sollen muss das Bild in zwei oder mehr Teile unterteilt werden, wodurch natürlich indirekt die Performance wieder sinkt. Aber C1 kann in der Tat in 640x480 4xAA exakt gleich schnell fahren als wenn kein AA angewendet würde.

Gast

2007-05-17, 19:41:45

Raff

2007-05-17, 19:44:37

Von den reinen theoretischen Leistungsdaten sollte R600 das schnellste AA haben das eine Desktopkarte jemals hatte, weil die Bandbreite unglaublich hoch ist.

Irgendwas ist schief gegangen, entweder Treiber oder Hardware.

So unglaublich ist die gar nicht. Die 8800 Ultra hat 103,7 GB/s, die 2900 XT 105,6 GB/s.

MfG,
Raff

Gast

2007-05-17, 19:50:13

Aber das soll per Treiber gefixt werden

Das AF "Problem" kann genauso wenig gefixt werden wie das "Problem" beim AAA mit Supersampling-Anteil. Die 8800GTX hat 64 INT8 Filtereinheiten, die GTS immerhin noch 48. Die 2900XT hat ganze 16 FP16 Einheiten, die jedoch auch nur in einem Takt INT8 (bilinear) filtert können. Beim Einsatz des tilinearen Filters bleibt die MTexel/s Zahl gleich, da eben nicht die Hälfte an TFU brachliegen - im Gegensatz zur 2900XT.

DerKleineCrisu

2007-05-17, 19:53:24

Soso. Tut es auf G80 und R580 wunderbar in den heutigen Spielen. Und das downfiltering ist bereits nicht-linear.

Auf gut Deutsch: Er redet sich ziemlich beschissen raus. Naja gut, was hätte er auch sonst antworten können, man kann den armen Mann ja verstehen ;)

naja HDR+AA war nicht bei dx9 Vorgesehen bzw nicht so wie es ATI umgesetzt hatte .
Bei dx10 wurde diese Lücke geschlossen ;D .
Ich glaube da liegt der Hund begraben .
Deswegen diese Aussage das HDR&AA nicht funktioniert ;). Ich liebe Wendehälse.

Coda

2007-05-17, 20:05:58

So unglaublich ist die gar nicht. Die 8800 Ultra hat 103,7 GB/s, die 2900 XT 105,6 GB/s.

MfG,
Raff
Ach tatsächlich? Dann ist das 512-Bit-SI ja wirklich nur Verschwendung bei dem Chip.

naja HDR+AA war nicht bei dx9 Vorgesehen bzw nicht so wie es ATI umgesetzt hatte .
Ist es wohl. Du kannst ohne Probleme MSAA bei einem FP16-Rendertarget aktivieren, wenn es der Chip unterstützt.

Gast

2007-05-17, 20:18:41

Zurück zum R600, neben AA ist ja auch das AF nicht ganz so kostenlos wie man es vieleicht erwartet hat. Aber das soll per Treiber gefixt werden...

das "problem" der AF-performance kann nicht über den treiber gelöst werden, der R600 hat einfach viel zu wenig füllrate, wenn AF zum einsatz kommt gerade mal 1/4 der G80-füllrate/takt. die einzige möglichkeit das per treiber zu beseitigen wären wieder ein paar mehr der sogenannten "filteroptimierungen" einzuführen. (wo wir gerade dabei sind, wieviel verliert der R600 eigentlich ohne AI, kann mich nicht erinnern das gesehen zu haben?)

die schwache AA-performance gibt allerdings ziemliche rätsel auf, bandbreite ist genügend vorhanden und selbst wenn das resolve über den shader gemacht wird, hat die karte doch recht viel arithmetikleistung, theoretisch sogar etwas mehr als die 8800GTX. das inoffizielle gamma-korrigierte FSAA auf dem NV40 ist doch bestimmt auch über den shader gelaufen und hat nicht annhäernd soviel performance gekostet.

vor allem frage ich mich was ATI das letzte halbe jahr gemacht hat, einen derartigen fehler nicht zu bemerken, sei es nun ein hardwaredefekt oder ein treiberproblem. sowas muss bei den zig respins doch aufgefallen sein, und bei der verspätung wäre ein monat mehr auch nicht mehr so schlimm um ein derart gravierendes problem zu beseitigen.

Gast

2007-05-17, 20:30:08

Riecht nach einem Design Fehler, wenn man eine HDTV Konsole bewirbt und vor der Einführung noch Vollmundig versprach 4xAA wird Standard.
Naja gut in der Theorie kann er also 4xAA gratis, in der Praxis werden wir es nie sehen weil nicht genug RAM da ist, sauber gemacht...Naja, wenn die Konsole als HD-Konsole konstruiert worden ist, bin ich Chewbacca...
Bin trotzdem recht zufrieden mit dem Gerät, in SD-Auflösung bekommt man sogar manchmal SSAA :D

[wilder Spekulatius]Aber mal zurück zu den ROPs/RBEs von R600. Sind die Dinger selbst vielleicht gar nicht kaputt, sondern einfach größtenteils von Xenos übernommen, aber anderswo im Design (chipinterne Speicher/Anbindung ans Speicherinterface/das Speicherinterface höchstselbst) hakts, so dass sie ohne eDRAM nicht so funzen, wie sie sollen? Außerdem muss irgendwas in OpenGL ja anders laufen als unter D3D, dass die Ergebnisse dort nicht ähnlich katastrophal ausfallen.[/wilder Spekulatius]

zum AF-Tempo:
Mit einiger Arbeit am Treiber sollte es wohl hinzubekommen sein, dass R600 sich hier eher wie ein Chip mit 20 TMUs verhält, mit kräftigem zu-Tode-"optimieren" auch wie einer mit deren 32. Insbesondere wegen der zusätzlichen Pointsampling-TMUs muss der kritische Teil der Presse hier aufpassen wie die Schießhunde. Das Thema könnte noch sehr interessant werden...

Gast

2007-05-17, 20:35:10

Auch mit zum "Tode-optimierten-AF" kann die Karte sich nicht wie eine mit 20,25 oder 32 Filtereinheitenkarte verhalten - wie auch?
Man kann den Verlust durch die Filterung nur verringern. Mit 2xbiAF verliert die 2900XT die hälfte an Texturleistung. Wieweit willst du da noch optimieren?

Gast

2007-05-17, 20:42:21

Liesse sich AF eigentlich im Shader "nachbilden" ?

Gast

2007-05-17, 21:01:03

Liesse sich AF eigentlich im Shader "nachbilden" ?Genau das meinte ich, die PS-TMUs zusätzlich mit Shaderhilfe nutzen. 4 PS-TMUs=1 normale TMU, also insgesamt in diesem Fall 20 TMUs. Beim AF könnte man die Dinger dann wohl etwas effizienter einsetzen, was einen höheren Tempozuwachs bedeuten könnte - aber auch gleichzeitig die Frage aufwirft, ob man sich dann verkneifen wird, zugunsten des Tempos die Qualität über den Jordan zu werfen.
Ob das tatsächlich ginge... Keine Ahnung. Aber:
Only the :upara: survive!

Gast

2007-05-17, 21:01:43

Ja, aber nur sehr langsam, sonst würde man das ja tun und bräuchte keine TMUs mehr.

Coda

2007-05-17, 21:24:03

AF über den Shader ist unpraktikabel, das kann ich euch versichern.

Gast

2007-05-17, 21:34:00

AF über den Shader ist unpraktikabel, das kann ich euch versichern.Wie unpraktikabel denn? Ich meine, wenn ein Spiel fast nur an der TMU-Leistung hängt könnte es doch was bringen, oder?

=Floi=

2007-05-17, 21:36:34

ich verstehe den sinn nicht zuerst die USD architektur einzubauen welche ja im grunde auch die shaderleistung beschleunigen soll und man dann aber die shaderleistung für AA nützt
das leuchtet mir nicht ganz ein

Coda

2007-05-17, 21:38:32

Wie unpraktikabel denn? Ich meine, wenn ein Spiel fast nur an der TMU-Leistung hängt könnte es doch was bringen, oder?
Wenn du AF über die Shader machst, dann hängt es nicht mehr an der TMU-Leistung, sondern brutal an den ALUs und am dyn. branching ;)

Gast

2007-05-17, 21:43:19

Wenn du AF über die Shader machst, dann hängt es nicht mehr an der TMU-Leistung, sondern brutal an den ALUs und am dyn. branching ;)

Wäre es langfristig eine Alternative?

Gast

2007-05-17, 21:58:22

Wenn du AF über die Shader machst, dann hängt es nicht mehr an der TMU-Leistung, sondern brutal an den ALUs und am dyn. branching ;)Würde die Shaderleistung von R600 denn reichen, um die PS-TMUs per Emulation vollwertiger TMUs auszulasten und noch ein paar Flops für andere Operationen überzuhaben?

Gast

2007-05-17, 22:08:45

Gast

2007-05-17, 22:20:55

Ich glaube da sind wir noch meilenweit davon entfernt, bis Shadereinheiten komplett alles übernehmen. Dedizierte Einheiten kosten aktuell weniger Transistoren als eine Horde ALUs die sich um alles kümmern muss.Darum gehts doch gar nicht, sondern um die Frage, ob sich ein Flaschenhals der R600-Architektur zumindest in manchen Anwendungen aufweiten ließe.

Botcruscher

2007-05-17, 22:29:33

Gibts eigentlich Pläne für einen Artikel? Irgendwie Sieht imo zZ. kaum jemand durch was ATI(AMD) da getrieben hat.

Gast

2007-05-17, 22:44:15

Würde die Shaderleistung von R600 denn reichen, um die PS-TMUs per Emulation vollwertiger TMUs auszulasten und noch ein paar Flops für andere Operationen überzuhaben?

niemals, rechne dir aus wieviele FLOPs alleine ein bilineares sample kostet und du wirst sehen dass selbst dafür die ALU-leistung nicht wirklich ausreichend ist um das ganze großflächig einzusetzen. mit AF wird das ganze noch sehr viel schlimmer.

Coda

2007-05-17, 22:53:46

Wäre es langfristig eine Alternative?
Nein.

Gast

2007-05-17, 22:59:20

niemals, rechne dir aus wieviele FLOPs alleine ein bilineares sample kostet und du wirst sehen dass selbst dafür die ALU-leistung nicht wirklich ausreichend ist um das ganze großflächig einzusetzen. mit AF wird das ganze noch sehr viel schlimmer.Kann ich leider nicht, du anscheinend schon. Wärst du wohl so freundlich mal vorzurechnen, wie viele Shadereinheiten R600 bräuchte, um seine 16 PS-TMUs für bilineare/trilineare/anisotrope Filterung voll auszulasten?

Gast

2007-05-17, 23:07:14

Nein.

Hm, ok. Hätte ja auch ein möglicher Ansatz für die Zukunft sein können, danke.

Ailuros

2007-05-17, 23:41:43

Ich kann es nicht ab wenn bei ATI/AMD groß von Bugs geredet wird und bei NV nicht. Fehler machen beide IHVs.

Insgesamt halte ich die G80-Architektur für ausgewogener und skalierbarer, transistoreffizienter und stromsparender. Das ist kein Grund, an der R600-Architektur herumzumäkeln – vor allem, da ich viele Details noch gar nicht verstanden habe. Spekulation: AMD legt nach, und am Ende könnte es so aussehen wie 1950 vs 7900: AMD hat die Nase vorn.

Damit es so aussieht wie bei R5x0 vs. G7x muesste aber G8x eine gesunde Anzahl von G7x-Schwaechen geerbt haben, was aber nicht der Fall ist.

Ganz grob zusammengefasst hatte R520 im Vergleich zu G70 den Nachteil der kleineren theoretischen GFLOP Leistung; man schob drei mal so viele ALUs rein weil es billig war und voila setzte sich der R580 vom G71 mit gutem Abstand ab.

Beim R600 sieht es aber um einiges anders aus.

ROP-Schwaechen
Resolve-Probleme
VLIW
Niedrige Pixel-/Texel-Fuellraten

usw.

Jetzt bleibt die Frage wieviele Aenderungen man innerhalb einer Generation durchfuehren kann und wie viele Resourcen AMD (und nicht ATI!) opfern will fuer ein solches Projekt.

Da mich gerade vorher jemand ueber das Thema gefragt hat *hust*:

http://forum.beyond3d.com/showpost.php?p=1005954&postcount=24

Ja R600 hat grosse Vorteile insgesamt (und stets rein theoretisch) was Geometrie bzw. Tesselation betrifft und ja die Tesselations-Einheit braucht keine Aenderungen fuer "D3D11" denn der Anteil Tesselation im zukuenftigen API ist afaik so gut wie festgemauert. IMG wird wohl auch keine Aenderungen fuer ihren relevanten Kleinkram Schnickschnack brauchen, bleibt eben nur noch NV die aber IMO auch keinen besonderen Aufwand braucht das Zeug in G100 zu implementieren.

Vielleicht hilft diese Kleinigkeit ein bisschen: R600's Grossvater (wie die meisten wissen) war der Ur-R400 und nein das Ding wurde nicht storniert wie ATI behauptete wegen vorzeitiger API-Komplianz oder aehnlichem Bloedsinn, sondern einfach nur weil das Ding zu lahm war.

R400 = 4 * Vec4 (4D)
Xenos = 3 * Vec16 (5D)
R600 = 4 * Vec16 (5D)

Alle drei haben die Tesselations-Einheit, aber da man nie den ersten Design komplett einstampfte und es teurer gewesen waere die Tesselations-Einheit zu entfernen lies man sie einfach so wie sie original geplant war (und ja fuer die die ein gutes Gedaechtnis haben, bis zum R600 glaubte ich stets dass es sich um eine fixed-function Tesselations-Einheit handelt und nicht um eine programmierbare und das war mein eigener Fehler). Einige Schwaechen wurden aber vom R400 weitergeschleppt.

Wenn Du jemand von AMD ueber R600 fragen wuerdest deutet man schnell den Finger auf den Herstellungsprozess, aber der um einiges reduzierte Stromverbrauch seit dem vorigen Jahr ist eine uebles Ueberbleibsel von ein paar bugs die sich tatsaechlich in den Design geschlichen haben. Natuerlich ist kein chip je zu 100% bugfrei, das waere uebertrieben und gelogen. Der Unterschied hier ist die Anzahl der Bugs die beim R600 um einiges hoeher war als bei G80 durch das letzte Jahr seiner Entwicklungs-phase.

Fuer NV schaetzte ich momentan folgenden Verlauf ein (was aber auch verdammt ungenau sein kann und ziemlich gewagt von mir):

D3D10:

G80 = D3D10
G9x/GX2@65nm = D3D10
G9x single chip (spaeter als ^) = D3D10.1 (projected H1 2008)
G2x0 = D3D10.2 (?)

D3D11:

G100 = D3D11 (~2009?)

Wie es da bei AMD verlaufen wird und wo sich R700 genau plazieren wuerde im Vergleich zum obrigen, kann sich jederman selber ausraten. Auf jeden Fall sollte AMD (da sie den Zug fuer dieses Jahr mit D3D10 high end GPUs sowieso schon verpasst haben) IMHO den Quatsch mit jeglichem Refresh gleich total vergessen und sich mit voller Pulle auf eine rechtzeitige Veroeffentlichung des R700 fuer Anfang 2008 konzentrieren.

reunion

2007-05-18, 00:04:40

R400 = 4 * Vec4 (4D)

Sorry, aber das ergibt angesichts der Spezifikationen eines R300 keine Sinn.

Ailuros

2007-05-18, 00:12:55

Sorry, aber das ergibt angesichts der Spezifikationen eines R300 keine Sinn.

Wenn Du nicht an quads sondern an cluster denken wuerdest, macht es schon Sinn.

aths

2007-05-18, 14:09:49

Würde die Shaderleistung von R600 denn reichen, um die PS-TMUs per Emulation vollwertiger TMUs auszulasten und noch ein paar Flops für andere Operationen überzuhaben?Darauf sind die ALUs gar nicht ausgelegt. Kurz: Das kannst du vergessen. Über kurz oder lang könnte es sein, dass die TMU mehr und mehr in programmierbare Bestandteile aufgelöst wird, aber bisher sind TMUs parametrisierbare Fixed-Function-Units die nur das können wofür sie gedacht sind – dies aber sehr schnell.

Daredevil

2007-05-18, 14:18:38

Hat sich erledigt.

Gast

2007-05-19, 01:35:55

Darauf sind die ALUs gar nicht ausgelegt. Kurz: Das kannst du vergessen. Über kurz oder lang könnte es sein, dass die TMU mehr und mehr in programmierbare Bestandteile aufgelöst wird, aber bisher sind TMUs parametrisierbare Fixed-Function-Units die nur das können wofür sie gedacht sind - dies aber sehr schnell.Das ist ja alles schön und gut, aber immer noch keine Antwort auf die Frage. Völlig unabhängig davon, wie beknackt es einem erscheinen mag:
Wir haben 16 PS-TMUs und 64 Vec5-ALUs (bzw. Vec6, wenn wir die Brancheinheit dazunehmen). Reichen die, um aus den 16 PS-TMUs in Software 4 vollwertige TMUs (bzw. eine vollwertige Quad-TMU) zu machen oder nicht?

Coda

2007-05-19, 02:53:54

Nein tun sie nicht.

paul.muad.dib

2007-05-19, 22:11:42

Gibt es irgendwo einen Vergleich, was TMUs von R580, R600, G70 und G80 pro Takt können, bzw. wie viele Takte sie wofür brauchen? Falls nicht, kann das hier jemand zusammenfassen?

Gast

2007-05-19, 22:49:42

Gibt es irgendwo einen Vergleich, was TMUs von R580, R600, G70 und G80 pro Takt können, bzw. wie viele Takte sie wofür brauchen? Falls nicht, kann das hier jemand zusammenfassen?

G7x: 1bi-sample/takt, für tri, FP16, jeden AF-durchlauf wird geloopt und es fällt jeweils ein weiterer takt an.

R5xx: 1 bi-sample/takt, für alles weitere wird geloopt, wobei im gegensatz zu G7x FP-filterung garnicht unterstützt wird.

R6xx: 1 bi-sample/takt sowohl für INT8, als auch für FP16. für INT16 bzw. FP32 sind 2 takte notwendig, Tri und AF wird geloopt und es fällt für jeden durchlauf ein weiter takt (bzw. 2 bei FP32/INT16) an

G80: wahlweise 1xFP16-bilinear, 1xINT8-trilinear, 1xINT16-bilinear oder 1xINT8-2x-bilineares-AF pro takt (1x INT8-bilinear natürlich auch), sind weitere durchläufe notwendig wird wieder geloopt (z.b. für FP32, höhere AF-stufen)

deekey777

2008-05-12, 17:09:19

http://ati.amd.com/developer/cgo/2008/Rubin-CGO2008.pdf
Seite 34: 5 way VLIW Packing Rate

Irgendwie stehe ich auf dem Schlauch: Was bedeuten die Average-Zahlen genau?

mrt

2008-05-13, 15:14:34

Da ist doch die Auslastung der ALUs gemeint. Optimum wären 5, weil 5 Komponenten ;)

Coda

2008-05-13, 20:38:02

Ja in den meisten Fällen ist es offenbar knapp unter 4. Das ist schon relativ gut.

deekey777

2008-09-17, 23:07:04

In der aktuellen c't gibt es einen Test der aktuellen Grafikkarten (Schwerpunkt HD4800) und neben bei wird auf die Architektur der aktuellen Grafikchips eingegangen. Da gibt es zwar einen kleinen Fehler, was den G80 bzw. G200 angeht, aber die eine Aussage fand ich interresant:
AMD-GPUs fühlen sich am wohlsten, wenn ein Spiel möglichst lange Shader-Programme aus 200 und mehr Instruktionen verwendet. Dann ist die Wahrscheinlichkeit hoch, in einem Shader-Programm fünf voneinander unabhängige Operationen für die superskalaren Recheneinheiten zu finden. AMD setzt also darauf, dass zukünftige Spiele längere Shader-Programme verwenden, was nicht nur die Spielegrafik interessanter macht, sondern auch die Gesamtzahl der benötigten Shader verringern kann. Der Shooter Crysis benötigt für seine gelungene Dschungel-Grafik beispielsweise noch rund 85 000 Shader-Programme, die sich mit großem Aufwand pflegen lassen. Längere und komplexere Shader-Programme könnte man dagegen universell für eine ganze Material-Gruppe und für verschiedene Beleuchtungssituationen einsetzen und den Entwicklungsprozess damit vereinfachen. Vielleicht könnten die Radeon-Chips bei zukünftigen Spielen ihr Potenzial noch etwas besser auspielen.
(c't 20/08, Seite 130)
Wie ist diese Aussage als Ganzes zu bewerten? Meine vorige Frage bezog sich auch auf "Crysis: 284 ps": Was heißt das? (Ich finde die Antwort nicht).

Im F@H-Thread habe ich auf eine Aussage von Mike Houston hingewiesen, der sich wiederum genau zu der Packing-Rate aus der Präsentation äußerte:
http://foldingforum.org/viewtopic.php?f=51&t=4879&p=50760&hilit=vliw#p50763
Quite a bit better than small game shaders. The shaders (kernels) for Folding@Home are massive compared to game shaders so the compiler has much more opportunity to schedule. There are also much fewer memory loads/stores and straight line math. Basically, >4 for the heavy kernels and we have some that are >4.5.

Also längere Shader = bessere VLIW-Auslastung wahrscheinlich. In den aktuellen Spielen sind die Shader nicht lang genug.