R500 vs R520 [Archiv] - 3DCenter Forum

SamLombardo

2005-04-25, 19:24:25

[dzp]Viper

2005-04-25, 19:25:10

hm ich schiebs mal in das Speku-Forum (gibt ja nix weiter ausser Spekulationen zu dem Thema ;) )

Gast

2005-04-25, 19:29:31

thema kannst du dir sparen weil man nicht die daten des 520 kennt

Gast

2005-04-25, 19:30:47

reunion

2005-04-25, 19:32:43

Hallo. Sicherlich wurde irgendwo in den Tiefen des R520 Threads schonmal dazu geschrieben, ich finde aber nix konkretes.
Der R500 (XBOX2) soll ja ein weiterentwickelter/besserer Chip sein als der R520. Wie könnte man die Unterschiede sehen? Ist der R500 deutlich schneller? Basiert er auch auf SM3.0 oder weiterentwickelte Shader? Ist es eine grundlegend andere Architektur? Oder sind R500 und R520 leistungsmäßig doch irgendwie vergleichbar?

Vielen Dank Sam

R520 soll auf dem R300/R420 aufbauen, SM3.0 unterstützten und noch ein paar andere Dinge von R500 "geerbt" haben.
R500 basiert auf dem nie erschienen R400, hat eine unified-Shader-Architektur(jede Pipeline kann sowohl Pixel- als auch Vertexshaderdaten ausführen) und dürfte technolgisch ein Stück weiter sein. Außerdem wird R500 10MB-EDRAM beinhalten. Diese Architektur wird in Form des höchstwarscheindlich WGF 2.0-kompatiblen R600 auf den Desktopmarkt kommen. Beide Chips werden in 90nm lowk bei TSMC gefertigt.

SamLombardo

2005-04-25, 20:03:32

Gast

2005-04-25, 21:34:29

robbitop

2005-04-26, 10:36:37

Ailuros

2005-04-26, 12:25:01

ich gehe davon aus, dass R520 nominell schneller ist als R500. Denn eine WGF2 konforme Architektur kostet wie auch 10MiB eDRAM viele Transistoren. Die kann man beim R520 in Ausführungseinheiten investieren. Auch ist Abwärme in einer Konsole kritischer als im PC.
R400-R500-R600 sind eine Linie so wie NV3x-NV4x-G70, zum R600 sollte also nicht mehr soo viel fehlen, spekuliere ich einfach mal :)

Ich konnte bis jetzt keinen Geometrie-Shader in den Xenon Diagrammen entdecken. Wie klein oder gross der Unterschied ist, sollte frei zur Interpretation liegen. IMO ist es aber quasi nochmal eine Shader-Einheit die mit den anderen Shadern zum jeweiligen Datenaustausch kommt.

Stimmt eigentlich alles schon; es waere ja verheerend fuer ATI wenn R520 nicht um einiges schneller als Xenon waere.

Ailuros

2005-04-26, 12:29:13

Also ist der R500 wohl eine ganze Generation vorraus. :eek: Vielleicht wäre es Ati ja dann möglich auf Grund dieser "Vorarbeit" den R600 schneller zu bringen...Das die Unterschiede derart gravierend sind hätte ich so nicht erwartet. Es liet also eine völlig neue Struktur vor.

Theoretisch nur vereinte Einheiten macht den R500 jetzt nicht unbedingt WGF2.0/DX10 kompliant; ein Schritt in die Richtung zwar schon, aber ich bezweifle dass alle Basis-DX10 Vorraussetzungen getroffen wurden. Kann sein dass es bei PS3 auch nicht anders ist, was die Komplianz betrifft.

Ailuros

2005-04-26, 12:36:19

Es gibt Gerüchte, wonach der R500 embedded RAM bietet, im Gegensatz zum R520.

Ich halte es für wahrscheinlich, dass der R500 auschließlich SM4.0* Shaderunits bietet, also völlig frei programmierbare Shadereinheiten. Der R520 soll ja angeblich noch die alten SM2.0 Einheiten haben und aditional noch ein paar dieser SM4.0* Shaderunits, womit man dann SM3.0 bieten kann.

*oder halt fast SM4.0. Jedenfalls SM3.0+.

Konsolenfreund

Dieses "fast" oder "+" Zeug verwirrt nur weiterhin. Entweder ist eine Architektur DX9.0 oder DX10 kompliant.

Den imaginaeren "hybriden" R520 wuerde ich ja liebend gerne mal sehen; nicht nur erscheint so ein Aufbau als kompletter Schwachsinn, sondern wird auch so manches Treiber-gewarkel mit sich fuehren, da fuer vereinte Shader-Einheiten momentan (und bis zu >Mitte 2006) die API Unterstuetzung fehlt.

Wie soll ich mir das vorstellen? Bei einer Applikation mit einem SM2.0 renderpath hockt X Anzahl von Einheiten nur dumm rum oder anders rum bei einer Applikation mit SM3.0 die restlichen Y Einheiten? :|

Gast

2005-04-26, 14:21:35

Dieses "fast" oder "+" Zeug verwirrt nur weiterhin. Entweder ist eine Architektur DX9.0 oder DX10 kompliant.

Den imaginaeren "hybriden" R520 wuerde ich ja liebend gerne mal sehen; nicht nur erscheint so ein Aufbau als kompletter Schwachsinn, sondern wird auch so manches Treiber-gewarkel mit sich fuehren, da fuer vereinte Shader-Einheiten momentan (und bis zu >Mitte 2006) die API Unterstuetzung fehlt.

Wie soll ich mir das vorstellen? Bei einer Applikation mit einem SM2.0 renderpath hockt X Anzahl von Einheiten nur dumm rum oder anders rum bei einer Applikation mit SM3.0 die restlichen Y Einheiten? :|
Ich weiß es auch nicht und komisch kommt mir das Gerücht auch vor, aber es erscheint mir wahrscheinlicher, als das ATI mit derm R520 nochmal ein völlig neues SM3.0 Design bringt, wenn der R600, der imo WGF2.0 kompliant wird, nur ~ 12 Monate später kommt.

ShadowXX

2005-04-26, 14:38:22

Ich weiß es auch nicht und komisch kommt mir das Gerücht auch vor, aber es erscheint mir wahrscheinlicher, als das ATI mit derm R520 nochmal ein völlig neues SM3.0 Design bringt, wenn der R600, der imo WGF2.0 kompliant wird, nur ~ 12 Monate später kommt.

Wir wissen ja immer noch nicht, wie ATI die SM3.0 realisiert hat...der r520 könnte ja immer noch ein extrem aufgebohrter (oder wie auch immer man das nennen will) r420 sein.

Ailuros

2005-04-26, 14:47:27

Ich weiß es auch nicht und komisch kommt mir das Gerücht auch vor, aber es erscheint mir wahrscheinlicher, als das ATI mit derm R520 nochmal ein völlig neues SM3.0 Design bringt, wenn der R600, der imo WGF2.0 kompliant wird, nur ~ 12 Monate später kommt.

SM3.0 wird auch bei ATI mit der Zeit bis in den budget-Bereich skalieren; somit wird die Entwicklung auch nicht umsonst sein und das jetzt nicht nur ueber ein Jahr. Wie oft kann man den ueberhaupt einem jeglichen SM2.0 Design ein neues Gesicht geben, ueberhaupt fuer low-end?

SM3.0 ist IMO die Vorschwelle von DX10/Shaders; NVIDIA behauptet schon mit dem NV40 "unbegrenzte" Shader.

WGF2.0 GPUs fuer Mitte 2006 wird noch fuer einige Zeit noch eine einfache Projektion verbleiben. Ich will annehmen dass Microsoft nicht nochmal verspaeten wird, aber es garantiert mir auch keiner dass vielleicht die IHVs doch dann bis zum offiziellem WGF2.0 veroeffentlichen koennten (da dieses ja spaeter als das OS ankommen soll).

Ailuros

2005-04-26, 14:50:30

Wir wissen ja immer noch nicht, wie ATI die SM3.0 realisiert hat...der r520 könnte ja immer noch ein extrem aufgebohrter (oder wie auch immer man das nennen will) r420 sein.

Demi zitierte mal (aus den Treibern) ueber 512 PS30 und 1024 VS30 instruction slots. Ob das tatsaechlich der Wahrheit entspricht keine Ahnung.

512 slots sind das minimum fuer PS/VS30.

NV40 hat im Vergleich 4096 PS30, 544 VS30.

robbitop

2005-04-26, 16:07:05

F-Buffer und ein paar andere Änderungen und fertig ist das Checklistfeature. Schön billig in der Entwicklung genau wie R420.

DrumDub

2005-04-26, 16:11:43

F-Buffer und ein paar andere Änderungen und fertig ist das Checklistfeature. Schön billig in der Entwicklung genau wie R420. haha... das glaubst du doch selber nicht? sm 3.0 muss auf dem r520 mindestens genauso performant sein, wie auf dem nv40. die blöße kann sich ati nicht geben über ein jahr nach veröffentlichung des nv40 beim sm 3.0 nicht mithalten zu können.

Gast

2005-04-26, 16:14:54

Den imaginaeren "hybriden" R520 wuerde ich ja liebend gerne mal sehen; nicht nur erscheint so ein Aufbau als kompletter Schwachsinn, sondern wird auch so manches Treiber-gewarkel mit sich fuehren, da fuer vereinte Shader-Einheiten momentan (und bis zu >Mitte 2006) die API Unterstuetzung fehlt.

vereinte shadercores brauchen keine api-unterstützung.
der treiber teilt dann einfach dynamisch nach auslastung zu welche einheiten gerade ps-operationen und welche vs-operationen ausführen.

Ich halte es für wahrscheinlich, dass der R500 auschließlich SM4.0* Shaderunits bietet, also völlig frei programmierbare Shadereinheiten. Der R520 soll ja angeblich noch die alten SM2.0 Einheiten haben und aditional noch ein paar dieser SM4.0* Shaderunits, womit man dann SM3.0 bieten kann.

*oder halt fast SM4.0. Jedenfalls SM3.0+.

3.0+ oder wie du es immer nennst ist absolut sinnlos, da es keine api-unterstützung gibt. DX9 ist nur bis 3.0 spezifiziert, das "+" würde also brachliegen, WGF2.0 erfordert mindestens SM4, also dürfte die hardware hier keine shader rechnen da nicht alles was erforderlich ist unterstützt wird.

Gast

2005-04-26, 16:16:48

vereinte shadercores brauchen keine api-unterstützung.
der treiber teilt dann einfach dynamisch nach auslastung zu welche einheiten gerade ps-operationen und welche vs-operationen ausführen.

3.0+ oder wie du es immer nennst ist absolut sinnlos, da es keine api-unterstützung gibt. DX9 ist nur bis 3.0 spezifiziert, das "+" würde also brachliegen, WGF2.0 erfordert mindestens SM4, also dürfte die hardware hier keine shader rechnen da nicht alles was erforderlich ist unterstützt wird.
Ack. Wenn SM3.0 in der Praxis nicht performant ist, hätte ATI es auch völlig weglassen können, denn so gewinnt man keine Kunden.

robbitop

2005-04-26, 16:48:48

haha... das glaubst du doch selber nicht? sm 3.0 muss auf dem r520 mindestens genauso performant sein, wie auf dem nv40. die blöße kann sich ati nicht geben über ein jahr nach veröffentlichung des nv40 beim sm 3.0 nicht mithalten zu können.
Naja an den ALU's und an den TMU's müsste man eh arbeiten (FP32).
Es gibt doch keine wirklichen Benches für SM3, oder etwa doch? Sollte sich so schnell nicht ändern. Und wirklich performant ist NV in SM3 doch auch nicht. Es macht keinen Sinn, jetzt eine SM3 Architektur zu entwerfen, wenn bald eine WGF2 Architektur kommt. Das hätte dann schon zu R420 sein müssen. Entweder oder.

P4RH3li4

2005-04-26, 17:11:09

3.0+ oder wie du es immer nennst ist absolut sinnlos, da es keine api-unterstützung gibt. DX9 ist nur bis 3.0 spezifiziert, das "+" würde also brachliegen, WGF2.0 erfordert mindestens SM4, also dürfte die hardware hier keine shader rechnen da nicht alles was erforderlich ist unterstützt wird.
Für den PC Sektor mag das gelten, bei einem Konsolendesign wie XBox2 und R500 ist das nicht relevant.
Oder weiss man sicher das die Box exakt auf DirectX9 bzw.WGF2.0 basiert?
Ist doch auch möglich das das XBox2 SDK zum Bleistift DirectX9 basierend ist mit R500 spezifischen Extensions.
R520 dagegen als PC-Grafikkartendesign wird dagegen nicht wirklich über DirectX9/SM3.0 hinausgehen. Da ATI bei den zunehmend aufkommenden Titeln mit "3.0er" Unterstützung sicher nicht die Performancekrone verlieren will halte ich eine reine Softwarelösung für äusserst unwahrscheinlich.

Coda

2005-04-26, 19:30:55

Ist doch auch möglich das das XBox2 SDK zum Bleistift DirectX9 basierend ist mit R500 spezifischen Extensions.Sowas ist sogar ziemlich wahrscheinlich. War bei der XBox schon nicht anders (d.h. man konnte mehr von dem nVidia Chip ausnützen als mit DX 8)

R520 dagegen als PC-Grafikkartendesign wird dagegen nicht wirklich über DirectX9/SM3.0 hinausgehenGanz sicher nicht ;)

LordDeath

2005-04-26, 19:33:38

also ich denke auch, dass der R500 dank unified shader und vielleicht einiges mehr technisch weiter wäre als ein R520. ob es jetzt DX9.0 übertrifft oder irgendein WGF erfüllt ist eigentlich egal für ne konsole. man wird einfach versuchen, das beste für die kleinsten preis zu machen und muss sich nicht an irgendwelchen vorgaben orientieren wie im pc bereich.
aber traditionell sollte ein R520 mehr rohleistung haben als ein R500. weil man hier mehr takt geben kann, ein großes pc gehäuse hat und vielleicht auch mehr pipelines...

Ailuros

2005-04-27, 06:42:59

vereinte shadercores brauchen keine api-unterstützung.
der treiber teilt dann einfach dynamisch nach auslastung zu welche einheiten gerade ps-operationen und welche vs-operationen ausführen.

3.0+ oder wie du es immer nennst ist absolut sinnlos, da es keine api-unterstützung gibt. DX9 ist nur bis 3.0 spezifiziert, das "+" würde also brachliegen, WGF2.0 erfordert mindestens SM4, also dürfte die hardware hier keine shader rechnen da nicht alles was erforderlich ist unterstützt wird.

Zum zweiten Teil stimmen wir ja zu; es geht dann lediglich nur noch um eine bessere Erklaerung warum sich die beiden obrigen Paragraphen teilweise wiedersprechen.

Ailuros

2005-04-27, 06:46:33

Für den PC Sektor mag das gelten, bei einem Konsolendesign wie XBox2 und R500 ist das nicht relevant.
Oder weiss man sicher das die Box exakt auf DirectX9 bzw.WGF2.0 basiert?
Ist doch auch möglich das das XBox2 SDK zum Bleistift DirectX9 basierend ist mit R500 spezifischen Extensions.
R520 dagegen als PC-Grafikkartendesign wird dagegen nicht wirklich über DirectX9/SM3.0 hinausgehen. Da ATI bei den zunehmend aufkommenden Titeln mit "3.0er" Unterstützung sicher nicht die Performancekrone verlieren will halte ich eine reine Softwarelösung für äusserst unwahrscheinlich.

Xenon liegt wohl mit allerhoechster Wahrscheinlichkeit zwischen DX9.0 und 10. Wenn man die hoehere Komplianz nicht treffen kann, dann bleibt es bei DX9.0 Komplianz.

Wie waere es einfach mit "SM3.0 ohne getrennte PS/VS Einheiten"?

Leonidas

2005-04-30, 12:25:00

Vielleicht wäre es Ati ja dann möglich auf Grund dieser "Vorarbeit" den R600 schneller zu bringen...

Möglicherweise. Bringt nur nichts, weil man kann den R600 erst dann in den Markt werfen, wenn Longhorn verfügbar ist. Vorher sind die WGF2-Fähigkeiten nicht nutzbar.

Ailuros

2005-04-30, 14:27:51

Möglicherweise. Bringt nur nichts, weil man kann den R600 erst dann in den Markt werfen, wenn Longhorn verfügbar ist. Vorher sind die WGF2-Fähigkeiten nicht nutzbar.

Aus dem Grund gerade frage ich mich gerade in letzter Zeit oefters ob die WGF2.0 GPUs mit der Vorstellung von LONGHORN oder der Vorstellung von WGF2.0 kommen koennten.

Wird jetzt LONGHORN tatsaechlich Mitte 2006 veroeffentlicht, erscheint mir die Spanne zwischen R580/G80 etwas zu klein. Irgendwas stimmt hier nicht, aber es wird sich mit der Zeit schon klaeren.

Gast

2005-04-30, 15:33:42

Aus dem Grund gerade frage ich mich gerade in letzter Zeit oefters ob die WGF2.0 GPUs mit der Vorstellung von LONGHORN oder der Vorstellung von WGF2.0 kommen koennten.

Wird jetzt LONGHORN tatsaechlich Mitte 2006 veroeffentlicht, erscheint mir die Spanne zwischen R580/G80 etwas zu klein. Irgendwas stimmt hier nicht, aber es wird sich mit der Zeit schon klaeren.
Siehste. Habe ich, der tolle Gast, schon ein paar mal angemerkt, dass hier was seltsam ist rein von der Roadmap her.

KF

Ailuros

2005-04-30, 15:59:34

Siehste. Habe ich, der tolle Gast, schon ein paar mal angemerkt, dass hier was seltsam ist rein von der Roadmap her.

KF

Man kann mit dem Zeug als Beobachter schwer mit den staendigen Aenderungen mithalten. Wenn ich wuesste was Microsoft genau vorhat fuer 2006, waere einiges schon klarer. Offiziell schweigt ja M$ konstant ueber Veroeffentlichungdaten.

Gast

2005-04-30, 16:02:24

Ist es eigentlich möglich WGF2.0 auch für XP zu bringen oder ist das zu sehr verschieden für die XP Architektur?

reunion

2005-04-30, 16:20:37

Man kann mit dem Zeug als Beobachter schwer mit den staendigen Aenderungen mithalten. Wenn ich wuesste was Microsoft genau vorhat fuer 2006, waere einiges schon klarer. Offiziell schweigt ja M$ konstant ueber Veroeffentlichungdaten.

http://pics.computerbase.de/news/10745/1.jpg

"Holiday 2006" :D

Ailuros

2005-04-30, 16:35:46

http://pics.computerbase.de/news/10745/1.jpg

"Holiday 2006" :D

Ahhh Danke. Uhmmm Moment "holiday 2006" duerfte eigentlich eine Projektion (wenn alles nach Plan laeuft blah blah blah) fuer Weihnachten 2006 sein oder? Komischerweise dachte ich Idiot immer noch an Mitte 2006...*seufz*

Coda

2005-04-30, 17:29:55

Ist es eigentlich möglich WGF2.0 auch für XP zu bringen oder ist das zu sehr verschieden für die XP Architektur?Eher unwahrscheinlich, weil sich das Treiberinterface radikal geändert hat.

SamLombardo

2005-05-01, 13:02:54

Was ist eigentlich der Vorteil der Unified Shader im Vergleich zu getrennten PS und VS Einheiten? Speed? mehr Grafikfeatures? einfachere Programmierbarkeit?

Sam

ShadowXX

2005-05-01, 13:28:47

Was ist eigentlich der Vorteil der Unified Shader im Vergleich zu getrennten PS und VS Einheiten? Speed? mehr Grafikfeatures? einfachere Programmierbarkeit?

Sam

Ist wohl etws einfacher zu Programmieren, aber was viel wichtiger (zumindest aus meiner sicht) ist: Lastverteilung.

Wenn du etwas Programmierst, was stark PS-Lastig ist, nutzt du bei den unified Shader einfach mehr der Einheiten für Pixelshading...wenn dein Programm mehr VS-Lastig ist, benutzt du die Einheiten eben hauptsächlich als VS....

Im Prinzip sollte sowas sogar der Treiber automatisch auch bei älteren Titeln hinbekommen....

Coda

2005-05-01, 13:37:10

Einfacher zu programmieren ist daran gar nix, die Hochsprache bleibt bei HLSL.
Der einzige Vorteil ist die Lastverteilung, darüber hat der Programmierer aber keine Kontrolle.

Im Prinzip sollte sowas sogar der Treiber automatisch auch bei älteren Titeln hinbekommen....Selbstverständlich kann er das. Anders geht's bei unified shadern ja gar nicht.

Eigentlich hat die ganze Sache nur was mit dem Grafikchip zu tun, der Anwender/Programmierer braucht sich darüber keine Gedanken machen. CPUs benützen ja auch die selbe FPU für SSE und x87, nach außen ändert sich da aber auch nix.

SamLombardo

2005-05-01, 15:44:17

Aha. Danke :)

Ailuros

2005-05-01, 17:48:48

Der einzige Vorteil ist die Lastverteilung, darüber hat der Programmierer aber keine Kontrolle.

Zwischen den verschiedenen shader calls (ps/vs) ja? Wie koennte es eigentlich bei so einer Architektur aussehen, was die Latenz fuer vertex texturing betrifft?

Demirug

2005-05-01, 17:56:48

Zwischen den verschiedenen shader calls (ps/vs) ja? Wie koennte es eigentlich bei so einer Architektur aussehen, was die Latenz fuer vertex texturing betrifft?

Wen man gemeinsame Shadercores hat spielt es keine Rolle mehr ob die Textur nun im Vertex oder Pixelbereich gebraucht wird.

Coda

2005-05-01, 18:19:40

Wahrscheinlich sind die TMUs sogar entkoppelt bei so einer Architektur ähnlich wie die Vertex-TMUs bei NV40.

Damit hat man da auch noch Load-Balancing, weil die meisten Texturzugriffe werden wohl noch lange im PS Bereich liegen.

Ailuros

2005-05-02, 03:26:26

Wen man gemeinsame Shadercores hat spielt es keine Rolle mehr ob die Textur nun im Vertex oder Pixelbereich gebraucht wird.

Klingt aber schon nach einem sehr wesentlichen Grund der fuer vereinte Architekturen spricht.

Damit hat man da auch noch Load-Balancing, weil die meisten Texturzugriffe werden wohl noch lange im PS Bereich liegen.

Wird es ueberhaupt irgend ein Spiel mit wenigstens etwas vertex texturing geben, vor dem Erscheinen von DX10?

Coda

2005-05-02, 15:10:09

Klingt aber schon nach einem sehr wesentlichen Grund der fuer vereinte Architekturen spricht.Man braucht halt wirklich fette Crossbars für so ein Vorhaben...

Wird es ueberhaupt irgend ein Spiel mit wenigstens etwas vertex texturing geben, vor dem Erscheinen von DX10?Es gibt doch schon diese eine Flugsimulation die damit Displacement Mapping macht.

Wirkliche Farbgebung durch Texturen an Vertices halte ich für eher uninteressant.