R520 schon Anfang 2005?

[Crushinator]

Wobei das wahrscheinlich zwei Seiten einer Medaille sind. (...)
Klar, die Order wird aber vermutlich gewesen sein: "plz double da scorez, keepin same da' size, havin more waferz tha' diez, ksrythx". Vielleicht gab es da ja ein Mißverständnis darüber, welche scrorez gemeint waren. :D

[reunion]

Da ist gar nichts hinein interpretiert, das ist exakt was da steht. Der Chip läuft mit voller Funktionalität, das hat nichts mit dem erreichten Speed zu tun. Man erinnere sich ab wann einige Devs schon R520s hatten oder damals beim NV30 gab es schon lange vor dem Launch auch voll funktionstüchtige Chips.

Ja, der Chip läuft mit vollen Funktionsumfang, dies bedeutet aber noch lange nicht, dass er zu langsam läuft. Nur weil es beim NV30 so war, muss es noch lange nicht beim R520 auch so sein. IMHO klingt die Theorie von AiL schlüssig, oder es liegt wirklich an den Yields. Der 90nm Prozess ist neu und alles andere als ausgereift, dass da die Ausbeute bei einem hochkomplexen Chip zu beginn zu wünschen übrig lässt, wäre nicht gerade überraschend.

[Hauwech]

Falls man für R520 etwas an Crossfire ändert, wäre dies durchaus möglich.

Nicht andersrum? Man ändert was an R520 für Crossfire?

[wuzetti]

wenn ich mir den xbitlabs artikel durchlese, der irgendwie seriös klingt sowie die info von Coda http://www.forum-3dcenter.de/vbulletin/showthread.php?p=3130259#post3130259
dazuaddiere dürfte es ein gröberes problem mit dem prozess bzw. den yields geben. alles imho natürlich!

[reunion]

Nicht andersrum? Man ändert was an R520 für Crossfire?

Natürlich. :hammer:

[Crushinator]

Falls man für R520 etwas an Crossfire ändert, wäre dies durchaus möglich.
Was soll sich am Chip denn so wesentliches dafür geändert haben? Eher würde ich von einem aufwendigeren PCB-Design ausgehen. Deren Chips sind doch schon seit Ewigkeiten Multichip/Multiboard tauglich, und größere Änderungen am Chip nur für Consumer-taugliches Kreuzfeuer würde die Roadmap ganz schön durcheinander bringen. Ich würde sowas schonmal gar nicht für einen Nischenmarkt riskieren.

[reunion]

Was soll sich am Chip denn so wesentliches dafür geändert haben? Eher würde ich von einem aufwendigeren PCB-Design ausgehen. Deren Chips sind doch schon seit Ewigkeiten Multichip/Multiboard tauglich, und größere Änderungen am Chip nur für Consumer-taugliches Kreuzfeuer würde die Roadmap ganz schön durcheinander bringen.


Um das beantworten zu können, müsste man wissen, ob bzw. was ATi an Crossfire geändert hat. An die gleiche Lösung wie bei R4XX glaube ich jedenfalls nicht.


Ich würde sowas schonmal gar nicht für einen Nischenmarkt riskieren.

Nachträglich kann man soetwas aber nichtmehr ändern, dann hättte man wieder so eine Krücke wie bei R4XX.
Crossfire wurde AFAIK recht kurzfristig eingeschoben, vielleicht zu kurzfristig für R520.

[Hauwech]

Ja, der Chip läuft mit vollen Funktionsumfang, dies bedeutet aber noch lange nicht, dass er zu langsam läuft. Nur weil es beim NV30 so war, muss es noch lange nicht beim R520 auch so sein. IMHO klingt die Theorie von AiL schlüssig, oder es liegt wirklich an den Yields. Der 90nm Prozess ist neu und alles andere als ausgereift, dass da die Ausbeute bei einem hochkomplexen Chip zu beginn zu wünschen übrig lässt, wäre nicht gerade überraschend.

Imho ist ATI aber trotzdem gezwungen so langsam zu handeln. Selbst wenn sie heute die Massenproduktion beginnen und diese 100 Tage von Tapeout bis Verkauf immer noch Gültigkeit haben sollten, würde es Ende September sein bis sie wirklich in Massen verfügbar wäre. MMn dürften sie zwar mittlerweile genügend Chips für den Anfang 'gesammelt' haben, mit dem Weihnachtsgeschäft, je nachdem wie lange sich das noch hinzieht, könnte es dann aber vielleicht wirklich knapp werden.

[seahawk]

Ja, der Chip läuft mit vollen Funktionsumfang, dies bedeutet aber noch lange nicht, dass er zu langsam läuft. Nur weil es beim NV30 so war, muss es noch lange nicht beim R520 auch so sein. IMHO klingt die Theorie von AiL schlüssig, oder es liegt wirklich an den Yields. Der 90nm Prozess ist neu und alles andere als ausgereift, dass da die Ausbeute bei einem hochkomplexen Chip zu beginn zu wünschen übrig lässt, wäre nicht gerade überraschend.

Es bedeutet, das der Chip mit vollem Funktionsumfang läuft. Es bedeutet weder, dass er zu langsam läuft, noch dass er nicht zu langsam läuft.

Mich stört nur der hinweis, dass der Chip "fully functional" ist. Das empfinde ich fast wie eine versteckte Einschränkung. Imho keine Formulierung die man nutzen würde, wenn alles in Ordnung wäre.

[seahawk]

Was soll sich am Chip denn so wesentliches dafür geändert haben? Eher würde ich von einem aufwendigeren PCB-Design ausgehen. Deren Chips sind doch schon seit Ewigkeiten Multichip/Multiboard tauglich, und größere Änderungen am Chip nur für Consumer-taugliches Kreuzfeuer würde die Roadmap ganz schön durcheinander bringen. Ich würde sowas schonmal gar nicht für einen Nischenmarkt riskieren.

Vor allem weil man ggf. Masterkarten später bringen kann. Und eigentlich nur diese Änderungen brauchen sollten.

[DrumDub]

Vor allem weil man ggf. Masterkarten später bringen kann. Und eigentlich nur diese Änderungen brauchen sollten. ich glaube, beim r520 wird es für crossfire keine master und slave kombination mehr geben.

[Xmas]

Wahrscheinlich geringere Bildwiederholfrequenz?
:confused:
Ich zocke immer mit 85 Hertz, egal welche Auflösung.
Oder was wolltest du mir damit sagen?
Das meinte ich. Nun ja, hätte ich einen CRT dann wären 100Hz Standard, und nur wenn der Monitor in höhreren Auflösungen nicht mehr mitmacht würde ich runtergehen.

[seahawk]

ich glaube, beim r520 wird es für crossfire keine master und slave kombination mehr geben.

Abwarten. Dann müßten sie ja die Composingengine aufgeben.

[aths]

Alos muss man davon ausgehen, das er momentan gar nichts weiss. Über NV scheint er ekine Infos zu bekommen und bei ATI hat er imho schon zu viel erzählt, wenn unter NDA wäre.Meine Gerüchteküche-Kontakte sind nicht die besten – wobei mich Gerüchte eh nicht interessieren. Was wichtig ist, erfährt man schon früh genug, spätestens beim offiziellen Produktlaunch. Ich halte es für unwesentlich als erster die Fakten zu präsentieren und für sinnvoll, bei den Fakten Spreu vom Weizen zu trennen. In Dingen ATI bin ich bemüht, eine Verbesserung der Zusammenarbeit zu erreichen. Das Problem dabei ist nicht Rene Fröleke, den ich als PR-Profi (im positiven Sinne) schätze, sondern ATIs derzeitige allgemeine Informationspolitik.

[Winter[Raven]]

@aths

Man kann schlecht eine gute Informationspolitik betreiben, wenn der Mitbewerber seit 2 Jahren eine aus der "Technologischer" Sicht bessere Architektur vorweisen kann als man selbst. Die einzige Möglichkeit für ATI, Ihre Karten an den Mann zu bringen war ja die Schw... ahhh... Balkenlänke in den Benchmarks.

[DrumDub]

Abwarten. Dann müßten sie ja die Composingengine aufgeben. nicht zwangsläufig. ;)

[3d]

32 piplines und 512bit speicherinterface muss her.
wird doch langsam zeit. wie lange soll 256bit noch halten?
wär eine 512bit anbindung wirklich sooo tuer?

[reunion]

Abwarten. Dann müßten sie ja die Composingengine aufgeben.


Und wo liegt das Problem?
Diese wurde doch AFAIK ohnehin nur von E&S "ausgeliehen".

[Demirug]

Und wo liegt das Problem?
Diese wurde doch AFAIK ohnehin nur von E&S "ausgeliehen".

Man müsste mal so eine E&S Karte in die Finger bekommen um zu schauen ob die auch einen FPGA hat.

Das Problem ist das ATI dann das ganze ja im R520 einbauen müsste und sie haben ja behauptet das es eine ganz schlchte Idee sei die Multichip Funktionalität mit in einen Chip zu bauen welcher zum größten Teil nur für Einzelchiplösungen verwendet wird.

[Quasar]

Zumindest sieht es nach zwei Xilinx-Chips aus.

[Coda]

32 piplines und 512bit speicherinterface muss her.
wird doch langsam zeit. wie lange soll 256bit noch halten?
wär eine 512bit anbindung wirklich sooo tuer?Meiner Meinung nach noch sehr lange ;)

[LairD]

32 piplines und 512bit speicherinterface muss her.
wird doch langsam zeit. wie lange soll 256bit noch halten?
wär eine 512bit anbindung wirklich sooo tuer?

Such mal im Speku-Thread zum G70(da war das glaube ich),da habe ich nach den Kosten gefragt und Exxtreme meinte,wenn ich mich recht erinnere,dass die Verdrahtung bei 512 bit 4mal so aufwendig ist,wie bei 256 bit.

[reunion]

ATi Widerspricht Gerüchten um Shader 3.0a: R520 bietet vollen SM3.0-Support

Richard Huddy, European Developer Relations Manager, ATI told X-bit labs. “I suppose it’s also conceivable that MS might want to designate the Xbox 360 pixel shaders as ‘PS3.0a’.”

http://www.xbitlabs.com/news/video/display/20050610090546.html

[mapel110]

ATi Widerspricht Gerüchten um Shader 3.0a: R520 biete vollen SM3.0-Support

http://www.xbitlabs.com/news/video/display/20050610090546.html
The R520 is projected to be available later this year and launched this Summer.

Duz hört sich nicht so dolle an. Eigenkreation von xbitlabs?!

[Demirug]

ATi Widerspricht Gerüchten um Shader 3.0a: R520 bietet vollen SM3.0-Support

http://www.xbitlabs.com/news/video/display/20050610090546.html

Ähm wurde das 3.0a nicht so gedeutet das es besser als 3.0 sei?

Ich habe da am Ende nicht mehr so aufgepasst weil ich es ja sowieso für Blödsinn gehalten habe.

[reunion]

Ähm wurde das 3.0a nicht so gedeutet das es besser als 3.0 sei?

Ich habe da am Ende nicht mehr so aufgepasst weil ich es ja sowieso für Blödsinn gehalten habe.

IMO konnte man darüber keine Einigung erziehlen, ist ja jetzt eigendlich auch egal.

[Crushinator]

The R520 is projected to be available later this year and launched this Summer.

Duz hört sich nicht so dolle an. Eigenkreation von xbitlabs?!
Sommer == Juni bis August
Im Sommer launchen -> im September/Oktober (später) hierzulande verfügbar. Was hört sich daran denn nicht so dolle an und soll Eigenkreation von xbitlabs sein?

[pF3NG]

Im wesentlich steht drinnen, dass ATi ein Re-spin des R520 machen musste, da die Ausbeute miserabel war und dadurch sich der R520 noch nicht in Massenproduktion befindet. Bei G70 soll es hingegen keinerlei Probleme geben und dieser soll auch in kürze Vorgestellt bzw. Verfügbar sein.

Außerdem soll es sich bei R520 um eine komplett neue Architektur handeln, welche den Chip extrem komplex macht. Über die Pipelineanzahl wisse man noch nicht bescheid, der Chip wird allerdings in 90nm gefertigt und SM3.0 unterstützten.
LOL diese Meldung steht im Wiederspruch zu so ziemlich allen Posts der letzten 50 Seiten... :D

[ShadowXX]

Man müsste mal so eine E&S Karte in die Finger bekommen um zu schauen ob die auch einen FPGA hat.

Das Problem ist das ATI dann das ganze ja im R520 einbauen müsste und sie haben ja behauptet das es eine ganz schlchte Idee sei die Multichip Funktionalität mit in einen Chip zu bauen welcher zum größten Teil nur für Einzelchiplösungen verwendet wird.

Man kennt doch das Marketing.....die Aussage galt dann nur für den r3x0 bzw. r4x0.

Da r520 aber sooooo was tolles neues ist gilt die Aussage dann nicht mehr......

Das ist doch das gleiche mit SM3.0. Solange es ATI nicht hat/hatte war es "bad", mit dem erscheinen des r520 wird es dann plötzlich "must have".

Die bei ATI erinnern mich ein bisserl an Steve Jobs....(wobei nV auch nicht wesentlich besser bei solchen Geschichten ist.)

Aber genau wie bei Apple gibt es genug die wie jedesmal an den Lippen des Marketing kleben werden....

[Demirug]

wobei nV auch nicht wesentlich besser bei solchen Geschichten ist.

Wenn du wüsstest wie recht du hast...

[ShadowXX]

LOL diese Meldung steht im Wiederspruch zu so ziemlich allen Posts der letzten 50 Seiten... :D

Die sagen jedesmal das es eine völlig neue Architektur ist.

Im Falle des r520 kann man sogar ansatzweise davon sprechen, da sie gegenüber dem r420 doch sehr viel ändern mußten.
Basieren tut das ganze aber immernoch auf r300 (oder sogar r200).

Vollständig neu wäre sowas wie der r500.

[pF3NG]

']@aths

Man kann schlecht eine gute Informationspolitik betreiben, wenn der Mitbewerber seit 2 Jahren eine aus der "Technologischer" Sicht bessere Architektur vorweisen kann als man selbst. Die einzige Möglichkeit für ATI, Ihre Karten an den Mann zu bringen war ja die Schw... ahhh... Balkenlänke in den Benchmarks.
IMO war R300 eindeutig bessere Architektur als NV30, bei R420 und NV40 siehts anders aus ;)

edit: auch aus Technologischer sicht...

[pF3NG]

Die sagen jedesmal das es eine völlig neue Architektur ist.

Im Falle des r520 kann man sogar ansatzweise davon sprechen, da sie gegenüber dem r420 doch sehr viel ändern mußten.
Basieren tut das ganze aber immernoch auf r300 (oder sogar r200).

Vollständig neu wäre sowas wie der r500.
Ja doch das ist der R520 so wie es aussieht nicht..

Man müsste mal so eine E&S Karte in die Finger bekommen um zu schauen ob die auch einen FPGA hat.
Wir können ja alle schon mal zusammenlegen ;D

[ShadowXX]

Wenn du wüsstest wie recht du hast...

Ich hab schon genug "Hämmer" von nV gelesen um mir sehr gut vorstellen zu können, was/wie du das meinst.

Obwohl ich mir vorstellen kann, das du da bestimmt noch "härteres" mitbekommen hast.

Sind beides keine Lämmchen. Eher ein rudel Haie was nach 20 tagen endlich mal wieder Futter bekommt.

Ich bin mehr als Gespannt auf die Anti-nV-Folien von ATI und die Anti-ATI-Folien von nV.
Und für die dazugehörenden Threads bin ich schon dabei mir Popcorn vorzubereiten....

[Crushinator]

Man müsste mal so eine E&S Karte in die Finger bekommen um zu schauen ob die auch einen FPGA hat. (...)

Internal Connector auf PCB...
http://tweak.pl/images/simfusion.jpg

und...

[ShadowXX]

IMO war R300 eindeutig bessere Architektur als NV30, bei R420 und NV40 siehts anders aus ;)

edit: auch aus Technologischer sicht...

Das kommt ganz auf die Sichtweise an.

Shadertechnisch war der nv3x dem r3x0 durchaus überlegen (von den möglichkeiten und features).
Auch hatte der nv3x das wesentlich bessere (wenn auch langsamere) AF.

Das Problemlag eher daran, das nV sich bei DX9 "verschätzt" hatte und daurch performancetechnisch bei PS2.0 kein Bein auf den Boden bekam.
Unter DX8 konnte er mit dem r300 ohne Probs mithalten....

[Diskutator]

Das kommt ganz auf die Sichtweise an.

Shadertechnisch war der nv3x dem r3x0 durchaus überlegen (von den möglichkeiten und features).
Auch hatte der nv3x das wesentlich bessere (wenn auch langsamere) AF.

Das Problemlag eher daran, das nV sich bei DX9 "verschätzt" hatte und daurch performancetechnisch bei PS2.0 kein Bein auf den Boden bekam.
Unter DX8 konnte er mit dem r300 ohne Probs mithalten....
Wer jetzt wo die bessere Technik katte, läßt sich doch heute wunderbar belegen! Das der R520 einen NEUEN Weg geht, dürfte jedem anhand R500 klar geworden sein! Ich freue mich schon auf das Treffen im Benchmarklabor ;D

[reunion]

Das kommt ganz auf die Sichtweise an.

Shadertechnisch war der nv3x dem r3x0 durchaus überlegen (von den möglichkeiten und features).
Auch hatte der nv3x das wesentlich bessere (wenn auch langsamere) AF.

Das Problemlag eher daran, das nV sich bei DX9 "verschätzt" hatte und daurch performancetechnisch bei PS2.0 kein Bein auf den Boden bekam.
Unter DX8 konnte er mit dem r300 ohne Probs mithalten....


Dies mag vielleicht auf NV35 zutreffen, NV30 war hingegen in vielerlei Hinsicht eine Fehlkonstruktion.

[Diskutator]

']@aths

Man kann schlecht eine gute Informationspolitik betreiben, wenn der Mitbewerber seit 2 Jahren eine aus der "Technologischer" Sicht bessere Architektur vorweisen kann als man selbst. Die einzige Möglichkeit für ATI, Ihre Karten an den Mann zu bringen war ja die Schw... ahhh... Balkenlänke in den Benchmarks.

ZENSUR!!!!!!!!!! :)

[Demirug]

Crushinator, danke die Bilder kannte ich schon leider kann man drauf nicht wirklich erkennen welcher Chip das zusammenführen der Signale übernimmt.

reunion, wenn es das "DX9 will FP" Desaster nicht passiert wäre hätte auch der NV30 einen schönen Chip abgegeben.

Diskutator, wenn der R520 ein R500 derivat wäre könnte ich nur sagen "Gute Nacht ATI". Ich hoffe doch das sie etwas mehr Leistung auf die Strasse bekommen.

[Diskutator]

Man kennt doch das Marketing.....die Aussage galt dann nur für den r3x0 bzw. r4x0.

Da r520 aber sooooo was tolles neues ist gilt die Aussage dann nicht mehr......

Das ist doch das gleiche mit SM3.0. Solange es ATI nicht hat/hatte war es "bad", mit dem erscheinen des r520 wird es dann plötzlich "must have".

Die bei ATI erinnern mich ein bisserl an Steve Jobs....(wobei nV auch nicht wesentlich besser bei solchen Geschichten ist.)

Aber genau wie bei Apple gibt es genug die wie jedesmal an den Lippen des Marketing kleben werden....

SM3.0 ist in diesem Jahr bei 1% der Spiele ein "must have", Wer hat damals zum RICHTIGEN Zeitpunkt DX9 im Channel etabliert? Wer hat die bessere SM 2.0 Performance ? :eek:

Warum wohl hat nv SM3.0 schon so frühzeitig etabliert? :eek:

SM3.0 ist erst 2006 ein "must have" !

[Diskutator]

Diskutator, wenn der R520 ein R500 derivat wäre könnte ich nur sagen "Gute Nacht ATI". Ich hoffe doch das sie etwas mehr Leistung auf die Strasse bekommen.

Da kannst du sicher sein!

[Diskutator]

600MHz auf dem Core und einiges mehr auf dem Speicher werden es wohl werden!

[Coda]

Wer jetzt wo die bessere Technik katte, läßt sich doch heute wunderbar belegen!FX12 Shader performen auf NV3x durchaus auf R300 Niveau, und das würde bis heute für fast alles reichen. Nur hat MS da einen Strich durch die Rechnung gemacht.

Das der R520 einen NEUEN Weg geht, dürfte jedem anhand R500 klar geworden sein! Ich freue mich schon auf das Treffen im Benchmarklabor ;DAch tut es das? Es ist schon lange bekannt dass R520 eher ein traditionelles Design ist, weil ATi aus den unified Shadern nicht genügend Performance rausbekommt.

Lol, wo hast du denn in den letzten 2 Jahren gelebt? Das stimmt in keinster Weise was du hier behauptest, nim mal deine Fanboy-Mütze ab und argumentiere sachlich und anhand von Wissen!Wer im Glashaus sitzt... :rolleyes:

[reunion]

reunion, wenn es das "DX9 will FP" Desaster nicht passiert wäre hätte auch der NV30 einen schönen Chip abgegeben.


Es ging mir dabei auch nicht nur um die DX9-Performance.


Diskutator, wenn der R520 ein R500 derivat wäre könnte ich nur sagen "Gute Nacht ATI". Ich hoffe doch das sie etwas mehr Leistung auf die Strasse bekommen.

Was ist eigendlich genau das Problem bei der R500-Architektur?
Die Shaderperformance soll ja anständig sein. Okay, die Füllrate ist etwas mager, aber diese könnte man ja für einen Desktopchip problemlos aufbohren.

[pF3NG]

Dies mag vielleicht auf NV35 zutreffen, NV30 war hingegen in vielerlei Hinsicht eine Fehlkonstruktion.
ich sag nur 128 bit Speicher anbindung^^

[reunion]

FX12 Shader performen auf NV3x durchaus auf R300 Niveau, und das würde bis heute für fast alles reichen. Nur hat MS da einen Strich durch die Rechnung gemacht.


Wobei man trozdem nicht gänzlich auf FP-Shader verzichten hätte können.

[Coda]

Jo. Nur hätte das den Braten nicht fett gemacht. Und komm nicht mit dem Argument "Entwickler sind zu dumm Präzision abschätzen zu können". Das muss man bei Prozessorcode auch.

[Diskutator]

FX12 Shader performen auf NV3x durchaus auf R300 Niveau, und das würde bis heute für fast alles reichen. Nur hat MS da einen Strich durch die Rechnung gemacht.

Ach tut es das? Es ist schon lange bekannt dass R520 eher ein traditionelles Design ist, weil ATi aus den unified Shadern nicht genügend Performance rausbekommt.

Wer im Glashaus sitzt... :rolleyes:

1. Hatte MS ganz klar im Pflichtenheft FP24Bit stehen und keine 32Bit, naklar hören sich 32Bit besser an, nur nutzen sich nichts wenn dann der Weg doppelt so lang ist! Eigentor NV!

2. Ich wäre mir mit dem traditionellen Design nicht so sicher, immerhin ist beim R520 nix bis auf Core und evtl. unified Shader rausgekommen, es ist noch nicht das Kern-Detail rausgekommen!

3. Wer im Glashaus sitzt..... :eek:

Hast du dir schonmal die Mühe gemacht und dir die Beiträge von Ihm durchgelesen! Fanboy-Müll pur! Tut mir leid, da bekomme ich .......... ! :-)
:cool:

[pF3NG]

Es ging mir dabei auch nicht nur um die DX9-Performance.



Was ist eigendlich genau das Problem bei der R500-Architektur?
Die Shaderperformance soll ja anständig sein. Okay, die Füllrate ist etwas mager, aber diese könnte man ja für einen Desktopchip problemlos aufbohren.

wieso sagen auf einmal alle, die R500 Architektur sei schlecht?? Ich kann mich noch gut erinnern, wie der R500 in anderen Threads und auch hier in höchsten tönen gelobt worden ist :| (sieht man mal von nur 10 mb eDRAM ab)

[Coda]

1. Hatte MS ganz klar im Pflichtenheft FP24Bit stehen und keine 32Bit, naklar hören sich 32Bit besser an, nur nutzen sich nichts wenn dann der Weg doppelt so lang ist! Eigentor NV!Darum ging es gerade aber gar nicht. NV30 kann neben FP16 und FP32 auch FX12 rechnen. Und das ziemlich fix im Gegensatz zu den FP Formaten.

Nur MS sieht keine Möglichkeit in DX9 vor abseits von PS1.4 FX12 zu nützen, was nVIDIA das Leben ziemlich versaut hat in der NV3x Zeit.

[Crushinator]

wieso sagen auf einmal alle, die R500 Architektur sei schlecht?? Ich kann mich noch gut erinnern, wie der R500 in anderen Threads und auch hier in höchsten tönen gelobt worden ist :| (sieht man mal von nur 10 mb eDRAM ab)
Nun, sie ist nicht von nVIDIA. Das ist vielleicht der Hauptgrund! :D

[Coda]

Nein ist es nicht. R500 ist zukunftsweißend, aber leider anscheinend nicht wirklich schnell.

[Diskutator]

Darum ging es gerade aber gar nicht. NV30 kann neben FP16 und FP32 auch FX12 rechnen. Und das ziemlich fix im Gegensatz zu den FP Formaten.

Nur MS sieht keine Möglichkeit in DX9 vor abseits von PS1.4 FX12 zu nützen, was nVIDIA das Leben ziemlich versaut hat in der NV3x Zeit.

Da hast du allerdings recht, aber ist es nicht verwunderlich, das genau zu dieser Zeit nv mit MS ziemlich verbandelt war, ich sage nur Xbox1!
Das war meiner Meinung nach ganz klar ein kalkuliertes Risiko, ist halt anders gekommen, who cares today ? :wink:

[Coda]

1. Hatte MS ganz klar im Pflichtenheft FP24Bit stehen und keine 32Bit, naklar hören sich 32Bit besser an, nur nutzen sich nichts wenn dann der Weg doppelt so lang ist! Eigentor NV!Das stimmt so übrigens auch nicht, da hat man nur ATi nachgegeben AFAIR.

[Diskutator]

Nein ist es nicht. R500 ist zukunftsweißend, aber leider anscheinend nicht wirklich schnell.
Für die Xbox-Games (Next Generation) reicht es aber völlig aus, das war ja auch nur das Ziel. Sicherlich ist der R500 zum R520 vergleichbar von der Performance wie z.B. X700 zu X850!

[reunion]

Nein ist es nicht. R500 ist zukunftsweißend, aber leider anscheinend nicht wirklich schnell.


Gibt es schon Benchmarks von R500, oder woher kommt diese Weisheit?

[Demirug]

Was ist eigendlich genau das Problem bei der R500-Architektur?
Die Shaderperformance soll ja anständig sein. Okay, die Füllrate ist etwas mager, aber diese könnte man ja für einen Desktopchip problemlos aufbohren.

Bei der Shaderperformance darf man nicht vergessen das davon auch noch das Vertexshading abgeht. Zudem sind die ALUs im Vergleich zum R420 einfacher da die Zusatzeinheiten fehlen. Die bringen zwar nur begrenzt etwas aber immerhin.

Wenn man das SIMD noch ordentlich breiter machen würde ginge es wohl schon aber IMHO ist der R500 schon verdamt nah am Limit was derzeit machbar.

[Diskutator]

Das stimmt so übrigens auch nicht, da hat man nur ATi nachgegeben AFAIR. Das habe ich etwas anders in Erinnerung, sicherlich hatte ATI zu dem Zeitpunkt eine bessere Verhandlungsposition! Das mag ja sein, ändert aber nicht den Umstand von nv, "Mut zur Lücke" damals gehabt zu haben! Es war alles vorher bekannt gewesen!

[Diskutator]

Bei der Shaderperformance darf man nicht vergessen das davon auch noch das Vertexshading abgeht. Zudem sind die ALUs im Vergleich zum R420 einfacher da die Zusatzeinheiten fehlen. Die bringen zwar nur begrenzt etwas aber immerhin.

Wenn man das SIMD noch ordentlich breiter machen würde ginge es wohl schon aber IMHO ist der R500 schon verdamt nah am Limit was derzeit machbar.

Dem schliesse ich mich bedingt an :)

[Demirug]

DX Specs wurden immer so geschrieben das alle Hersteller sie erfüllen können.

[Quasar]

SM3.0 ist in diesem Jahr bei 1% der Spiele ein "must have", Wer hat damals zum RICHTIGEN Zeitpunkt DX9 im Channel etabliert?
Hm, wenn ich mich recht erinnere, war's September 2002, als ich das erste Mal eine R9700 Pro bekam.
DX9 gab's damals nicht - höchstens im geschlossenen Beta-Test.
Auch in der ersten Hälfte 2003 waren der 3DMark03 und Tomb Raider Angel of Darkness die einzigen größeren Anwendungen, die die 9700p aufgrund der höheren 2.0-Shaderleistung vorn sahen und nicht aufgrund anderer Dinge.

Soviel erstmal dazu.

[reunion]

Bei der Shaderperformance darf man nicht vergessen das davon auch noch das Vertexshading abgeht. Zudem sind die ALUs im Vergleich zum R420 einfacher da die Zusatzeinheiten fehlen. Die bringen zwar nur begrenzt etwas aber immerhin.

Wenn man das SIMD noch ordentlich breiter machen würde ginge es wohl schon aber IMHO ist der R500 schon verdamt nah am Limit was derzeit machbar.

AFAIK kommt R500 ohne dem eDRAM-Chip auf 150Mio Transistoren, da sollte also schon noch eine Steigerung drin sein.

[Diskutator]

Hm, wenn ich mich recht erinnere, war's September 2002, als ich das erste Mal eine R9700 Pro bekam.
DX9 gab's damals nicht - höchstens im geschlossenen Beta-Test.
Auch in der ersten Hälfte 2003 waren der 3DMark03 und Tomb Raider Angel of Darkness die einzigen größeren Anwendungen, die die 9700p aufgrund der höheren 2.0-Shaderleistung vorn sahen und nicht aufgrund anderer Dinge.

Soviel erstmal dazu.

Sicherlich RICHTIG! War aber die 9700 aber nicht gerade deshalb Ref.-Board von so einigen G-Devs.!

[Quasar]

1. Hatte MS ganz klar im Pflichtenheft FP24Bit stehen [...]
Als Mindestanforderung für 2.0-Shader? Wenn ja, seit welchem Zeitpunkt?

[ShadowXX]

AFAIK kommt R500 ohne dem eDRAM-Chip auf 150Mio Transistoren, da sollte also schon noch eine Steigerung drin sein.

Wenn ATI der Meinung gewesen wäre, das Sie ein r500 für den Desktop hätten bauen können, dann hätten Sie es wohl gemacht.....und nicht den r520 nochmal extra entwickelt.

Wir werden sehen was der r520 imstande ist zu Leisten, wenn er denn man in hände ausserhalb ATIs fällt.

Ich erwarte momentan nicht sehr viel (allerdings erwarte ich auch keine Wundertaten vom G70), lasse mich aber immer gerne Positiv überraschen.

Welcher Name auf meinem nächsten Grafikchip steht, ist mir dabei ziemlich egal.

[ShadowXX]

AFAIK kommt R500 ohne dem eDRAM-Chip auf 150Mio Transistoren, da sollte also schon noch eine Steigerung drin sein.

Eher etwas über 200Mios nach dem was ich gehört habe....

[Quasar]

Sicherlich RICHTIG! War aber die 9700 aber nicht gerade deshalb Ref.-Board von so einigen G-Devs.!
Genau. Und aus welchem Grunde sollte das nun mit SM3-Games anders sein bzw. warum soll nV deiner Meinung nach ihren SM3-Part zu früh gebracht haben?
Seit einem Jahr und mehr können Devs auf SM3-HW entwickeln.

[Diskutator]

Als Mindestanforderung für 2.0-Shader? Wenn ja, seit welchem Zeitpunkt? Das hatte ich nicht behauptet! Ich bezog mich auf die 32bit precision !

[Diskutator]

Genau. Und aus welchem Grunde sollte das nun mit SM3-Games anders sein bzw. warum soll nV deiner Meinung nach ihren SM3-Part zu früh gebracht haben?
Seit einem Jahr und mehr können Devs auf SM3-HW entwickeln.
Das ist meine persönliche Meinung und die bezog sich auf reines Feature-Setting-Marketing! Siehe FX5200 mit DX9 etc.!

[Quasar]

Es war alles vorher bekannt gewesen!
Quelle? :)

[Quasar]

Das hatte ich nicht behauptet! Ich bezog mich auf die 32bit precision !
Das Posting liest sich aber 'etwas' anders. :)
Dann auch hier: Quelle? Seit wann war FP24 als min. Präzision für 2.0-Shader im Pflichtenheft?

[reunion]

Wenn ATI der Meinung gewesen wäre, das Sie ein r500 für den Desktop hätten bauen können, dann hätten Sie es wohl gemacht.....und nicht den r520 nochmal extra entwickelt.


Dies ist vermutlich die einzige logische Erklärung.


Eher etwas über 200Mios nach dem was ich gehört habe....


Vermutlich hast du recht, ich beziehe diese Infos von Heise, die ja auch nicht gerade der Weisheit letzter Schluss sind. :D

[Diskutator]

Das Posting liest sich aber 'etwas' anders. :)
War auch so gedacht! Letztendlich führt die Diskussion uns ja jetzt näher an die Wahrheit als es andere versuchen dazustellen! :cool:

[Quasar]

ich sag nur 128 bit Speicher anbindung^^
Die hatte deutlich weniger Einfluss, als man gemeinhin glaubt. Erst in 1280 und höher mit 4xAA gewann der nV35 dadurch etwas Vorsprung.

[Diskutator]

Quelle? :) Fudo ;) Nein! lol, es gab genügend Anhaltspunkte hierzu, das muss reichen ! :rolleyes:

[seahawk]

600MHz auf dem Core und einiges mehr auf dem Speicher werden es wohl werden!

Wenn man keine Ahnung hat - Du weißt bestimt wie der Spruch weiter geht

Informiere Dich bitte erstmal über Xenon.

[Quasar]

Fudo ;) Nein! lol, es gab genügend Anhaltspunkte hierzu, das muss reichen ! :rolleyes:
Nun, das habe ich von woanders allerdings etwas anders gehört - "das muss reichen" ;)

Mit so einer Art der Belegführung kommen wir hier nicht weiter - Quellen als "das stimmt halt so" anzugeben ist nicht viel mehr wert, als direkter Spam.

[Diskutator]

Wenn man keine Ahnung hat - Du weißt bestimt wie der Spruch weiter geht

Informiere Dich bitte erstmal über Xenon.

LoL! Guten Hunger! See ya

[Diskutator]

Nun, das habe ich von woanders allerdings etwas anders gehört - "das muss reichen" ;)

Mit so einer Art der Belegführung kommen wir hier nicht weiter - Quellen als "das stimmt halt so" anzugeben ist nicht viel mehr wert, als direkter Spam.

Das schlimme an Quellen ist, immer Ihren wahren Ursprungsort zu finden! ;)

[Coda]

LoL! Guten Hunger! See yaWieso müssen Hardwarediskussionen eigentlich immer so aggressiv geführt werden?

[seahawk]

LoL! Guten Hunger! See ya

Guck Dir Xenon dochmal an. Ohne eine Verbeiterung der Pipelinestruktur würde eine Takterhöhung immer noch vollkommen unzureichend sein.

[Quasar]

Guck Dir Xenon dochmal an. Ohne eine Verbeiterung der Pipelinestruktur würde eine Takterhöhung immer noch vollkommen unzureichend sein.
Ach, iwo!
Von 500 auf 600MHz sind glatte 20% mehr. Von vier GP/s ausgehend, die man wohl durch die ROPs bekommt, sind das dann immerhin schon fünf GP/s.

Also nur knapp unter den zweitstärksten Modellen von vor einem Jahr. X-D

[Xmas]

Wenn du wüsstest wie recht du hast...
Das hört sich irgendwie so aktuell an... ;)

[Demirug]

Das hört sich irgendwie so aktuell an... ;)

Und deswegen gehe ich auch nicht in die Details... ;)

[Gast]

ich sag nur 128 bit Speicher anbindung^^

die 6600GT beweist dass diese auch gereicht hätte, und wäre ohne SM3 wohl nur gering größer als der NV35

[Gast]

DX Specs wurden immer so geschrieben das alle Hersteller sie erfüllen können.

wie sie wohl ausgesehen hätten wenn NV gar kein FP geboten hätte ;)

[Ailuros]

1. Hatte MS ganz klar im Pflichtenheft FP24Bit stehen und keine 32Bit, naklar hören sich 32Bit besser an, nur nutzen sich nichts wenn dann der Weg doppelt so lang ist! Eigentor NV!

R520 ist ausschliesslich FP32 so wie es aussieht, ausser ich hab was falsch verstanden.

2. Ich wäre mir mit dem traditionellen Design nicht so sicher, immerhin ist beim R520 nix bis auf Core und evtl. unified Shader rausgekommen, es ist noch nicht das Kern-Detail rausgekommen!

Keine Ahnung was Du hier meinst. Verstehst Du es selber? :D

3. Wer im Glashaus sitzt..... :eek:

Hast du dir schonmal die Mühe gemacht und dir die Beiträge von Ihm durchgelesen! Fanboy-Müll pur! Tut mir leid, da bekomme ich .......... ! :-)
:cool:

No comment.

[Winter[Raven]]

Das kommt ganz auf die Sichtweise an.

Shadertechnisch war der nv3x dem r3x0 durchaus überlegen (von den möglichkeiten und features).
Auch hatte der nv3x das wesentlich bessere (wenn auch langsamere) AF.

Das Problemlag eher daran, das nV sich bei DX9 "verschätzt" hatte und daurch performancetechnisch bei PS2.0 kein Bein auf den Boden bekam.
Unter DX8 konnte er mit dem r300 ohne Probs mithalten....

Full Ack! :)

//EDIT:

Aus welchem Grund ich ein Fanboy sein soll ist mir echt schleierhaft... Hier Nvidia Fanboy, im NV Forum ein Salman-Silencer Fanboy ...

Ist wohl der neueste Modewort, wenn man nicht gleicher Meinung ist :(

Schade :frown:

[Andreas Tidl]

"ATI is still not close to production. It's still tuning the chip. Like we said, a 24 pipes part will have acceptable yields for high end product and if it comes to 32 pipes yields won't be that good but it will be a very fast card. Whatever happens with R520, R580 will have all 32 pipelines enabled."

Auch wenn das vielen wohl schon bekannt war bin ich positiv überrascht, dass man mitlerweile schon in Kürze bei 32 Pipes angelangt ist. Wenn ich mir ansehe wie lange man damals bei 4 Pipes bei GeForce I,II,III und auch IV "festhing", so ist das schon eine kleine Sensation. Dem technischen Fortschritt kann ich nur meinen größten Respekt aussprechen.

[Winter[Raven]]

Löl ... sorry auch der R580 wird keine 32 haben, so ein Unfug!

Wo hast du dat her?

[Andreas Tidl]

']Löl ... sorry auch der R580 wird keine 32 haben, so ein Unfug!

Wo hast du dat her?

Link auf 3Dcenter.de

[Quasar]

R520 ist ausschliesslich FP32 so wie es aussieht, ausser ich hab was falsch verstanden.
Ich hoffe mal, daß das nicht irgenwo Probleme aufwirft.

[Quasar]

Auch wenn das vielen wohl schon bekannt war bin ich positiv überrascht, dass man mitlerweile schon in Kürze bei 32 Pipes angelangt ist. Wenn ich mir ansehe wie lange man damals bei 4 Pipes bei GeForce I,II,III und auch IV "festhing", so ist das schon eine kleine Sensation. Dem technischen Fortschritt kann ich nur meinen größten Respekt aussprechen.

Bitte betrachte mal die Anzahl der Pipelines (unabhängig von G70/R520) mit einem bißchen Abstand. Erinnerst du dich damals an den P4? :)

Wie lange gurkte man bei der P3-Architektur um und bei 1 GHz herum - kaum war der P4 da, *schwupps* hatte man im ersten Anlauf die 1,7GHz geknackt.
So ähnlich wollte Intel es ja mit dem Prescott handhaben. Einfach mit der Taktik, daß einfach immer weniger mächtige Einheiten verbaut wurden, die immer weniger pro Takt erledigen konnten. Dafür bohrte man die tolle GHz-Zahl immer weiter auf.

Dasselbe könnte irgendwann im GPU-Bereich passieren (oder ist bereits passiert?).

[Sunrise]

Bitte betrachte mal die Anzahl der Pipelines (unabhängig von G70/R520) mit einem bißchen Abstand. Erinnerst du dich damals an den P4? :)

Wie lange gurkte man bei der P3-Architektur um und bei 1 GHz herum - kaum war der P4 da, *schwupps* hatte man im ersten Anlauf die 1,7GHz geknackt.
So ähnlich wollte Intel es ja mit dem Prescott handhaben. Einfach mit der Taktik, daß einfach immer weniger mächtige Einheiten verbaut wurden, die immer weniger pro Takt erledigen konnten. Dafür bohrte man die tolle GHz-Zahl immer weiter auf.

Dasselbe könnte irgendwann im GPU-Bereich passieren (oder ist bereits passiert?).
Das (Un-)Wort "Pipelines" mal außer Acht gelassen:

Er hat trotzdem in gewisser Weise Recht. Konkurrenz belebt das Geschäft und auch im CPU-Bereich wird Intel einen Gang höher schalten (müssen), bzw. sie haben es bereits getan, wenn man sich die Pläne anschaut. Der GPU-Sektor ist seit geraumer Zeit aktiv wie nie zuvor, und wird auch wohl in Zukunft weiterhin rasant voranschreiten.

Bsp. hat ATI seit R350 deutliche Probleme, NVs "Geschwindigkeit" in Planung, Umsetzung und Ausführung zu folgen. Dies wäre nicht der Fall, hätten sie mehr "Zeit" um ihre GPU-Entwicklung und die Fertigungsprozesse in Ruhe reifen zu lassen. R520 wäre längst erschienen, gebe es nicht die hohen Ziele (bedingt durch die Konkurrenz), welche sich jedes dieser GPU-Unternehmen im PC-High-End-Bereich aktuell selbst stellt. Das alles natürlich losgelöst von anderen Bereichen, in denen beide Unternehmen aktuell auch tätig sind (z.b. Konsolen).

[Quasar]

Das (Un-)Wort "Pipelines" mal außer Acht gelassen:

Er hat trotzdem in gewisser Weise Recht. Konkurrenz belebt das Geschäft und auch im CPU-Bereich wird Intel einen Gang höher schalten (müssen), bzw. sie haben es bereits getan, wenn man sich die Pläne anschaut. Der GPU-Sektor ist seit geraumer Zeit aktiv wie nie zuvor, und wird auch wohl in Zukunft weiterhin rasant voranschreiten.
Zustimmung. Aber darum ging es mir primär doch gar nicht, sondern darum, daß allein eine Erhöhung der Pipeline-Anzahl oder des Taktes überhaupt noch nichts aussagt (daher auch die Analogie zur Netburst-Architektur).

Was zählt ist, wieviel am Ende eine bestimmte Architektur zu leisten im Stande ist. Wieviele Pipelines oder wieviel Takt dazu nötig ist, ist doch eine sekundäre Frage.

[DrumDub]

Was zählt ist, wieviel am Ende eine bestimmte Architektur zu leisten im Stande ist. Wieviele Pipelines oder wieviel Takt dazu nötig ist, ist doch eine sekundäre Frage. so ist es. interessant ist dabei die tatsache, dass sich auf grund der immer flexibleren architekturen die diskrepanz zwischen der vermuteten und realen leistung verstärken wird, da eben auch die fähigkeiten zur lastverteilung (zukünftige unified shader architekturen) und sonstige kreative optimierungen (siehe nv43 mit nur 128bit interface) immer ihv-spezifischer sein werden.

[Sunrise]

Zustimmung. Aber darum ging es mir primär doch gar nicht, sondern darum, daß allein eine Erhöhung der Pipeline-Anzahl oder des Taktes überhaupt noch nichts aussagt (daher auch die Analogie zur Netburst-Architektur).

Natürlich tut es dies nicht. Jedoch ist der technische Fortschritt vorhanden, wenn wir uns mal von dem Wort "Pipelines" lösen, und das habe ich gemeint. ;)

[Demirug]

Man merkt ja irgendwo schon das ATI und auch nVidia weg von dem Pipeline Begriff wollen indem sie sich jetzt GFlops um die Ohren hauen. Das ersetzt aber irgendwie nur einen Sinnlosigkeit durch eine andere.

[Coda]

Das glaube ich erst wenn ich es sehe. 32 Pipeline bringen bei 800Mhz Speicher mal rein gar nichts.

[Quasar]

Natürlich tut es dies nicht. Jedoch ist der technische Fortschritt vorhanden, wenn wir uns mal von dem Wort "Pipelines" lösen, und das habe ich gemeint. ;)
Sicher, aber ihn (den techn. Fortschritt) an der Zahl der Pipelines sichtbar machen zu wollen, ist ein Schritt auf dem Weg in die intel'sche GHz-Hölle. :)

Das glaube ich erst wenn ich es sehe. 32 Pipeline bringen bei 800Mhz Speicher mal rein gar nichts.
Das kommt ganz drauf an, was diese Pipelines dann so können werden.

[Sunrise]

Sicher, aber ihn (den techn. Fortschritt) an der Zahl der Pipelines sichtbar machen zu wollen, ist ein Schritt auf dem Weg in die intel'sche GHz-Hölle. :)

Das wäre es wirklich, ebenso wie praktisch alles von Intel, unter dem Marketing- contra Logik-Aspekt kompletter Unsinn ist. Intel spielt hier eine Vorreiterrolle, Konsumenten in Massen mit "fangenden" Schlagwörtern an die eigenen Produkte zu binden. Ebenso wie manche heute noch, AMD mit den alten "Schwächen" bewerten, dabei sieht die Realität eben komplett anders aus.

[Coda]

Das kommt ganz drauf an, was diese Pipelines dann so können werden.Tut es das? Shaderleistung sollte auch bei 16 Pipelines mit mehr ALUs reichen und Füllrate von 32 Pipelines ist nicht wirklich nötig.

[Quasar]

Tut es das? Shaderleistung sollte auch bei 16 Pipelines mit mehr ALUs reichen und Füllrate von 32 Pipelines ist nicht wirklich nötig.
Ja, tut es. 8 Quads von der Art des nV30 wären vermutlich (außer in bilinearem Single-Texturing :eek:) noch ganz gut mit Bandbreite zu versorgen.
Außerdem ist ja nicht fix, daß alles, was in der next-Gen als Pipeline bezeichnet wird, auch eine eigene TMU hat. *g*

[pF3NG]

die 6600GT beweist dass diese auch gereicht hätte, und wäre ohne SM3 wohl nur gering größer als der NV35
6600GT ist auch "Mainstream"-Karte, FX5800U war als High End geplant... :redface:

[Coda]

Außerdem ist ja nicht fix, daß alles, was in der next-Gen als Pipeline bezeichnet wird, auch eine eigene TMU hat. *g*Wenn R520 auf R420 aufbaut (was recht wahrscheinlich ist) dann werden die TMUs kaum von den Pipelines getrennt sein.

[Quasar]

6600GT ist auch "Mainstream"-Karte, FX5800U war als High End geplant... :redface:
Ich sag's nochmal: Erst ab 1280 inkl. 4xAA machte das 128Bit-Interface sich bemerkbar. Vorher nicht.

[Quasar]

Wenn R520 auf R420 aufbaut (was recht wahrscheinlich ist) dann werden die TMUs kaum von den Pipelines getrennt sein.
Siehst du - klassisch aneinander vorbeigeredet.

Ich gehe erstmal gar nicht unbedingt davon aus, daß eine Pipeline eine Pipeline ist und insofern gestehe ich auch der 32-Zählweise erstmal genügend Bandbreite aus 800MHz 256Bit-DDR zu.

[seahawk]

Tut es das? Shaderleistung sollte auch bei 16 Pipelines mit mehr ALUs reichen und Füllrate von 32 Pipelines ist nicht wirklich nötig.

Wichtig ist nur was am Ende rauskommt und nicht wieviel Funktionseinheiten zur Erzeilung dieses Ergebnises genutzt werden, oder wie man diese bezeichnet. :smile:

[Coda]

Eben. Deshalb sollte man auch eher die ALUs der bestehenden Pipelines aufbohren und nicht auch noch die Füllrate erhöhen die eh verpufft.

[Gast]

6600GT ist auch "Mainstream"-Karte, FX5800U war als High End geplant... :redface:

aber eine mainstream-karte die die ihrem highend-vorgänger das fürchten lehrt.

wenn die 6600GT-pipelines im SM3 erleichtert würde man wahrscheinlich unter 120Mill. Transistoren kommen (den VP nicht zu vergessen), und hätte einen chip der schon zur damaligen zeit vernünftig produzieren könnte.

[aths]

Das glaube ich erst wenn ich es sehe. 32 Pipeline bringen bei 800Mhz Speicher mal rein gar nichts.Doch.

Eben. Deshalb sollte man auch eher die ALUs der bestehenden Pipelines aufbohren und nicht auch noch die Füllrate erhöhen die eh verpufft.Es ist für die GFLOP-Leistung unwesentlich, ob man 4 Quads á 2 SUs oder 8 Quads á 1 SU hat. Je kürzer die Pipe, desto kleinere Objekte* ohne große Ineffizienz.

* Mit Objekt meine ich hier einen Rendervorgang bis zum nächsten State Change.

Rechnung zur Texturbandbreite. Annahme: 500 MHz Core, pro Bi-Sample braucht man 1 frisches Texel, pro Quad-Pipe eine Quad-TMU (Bilinear pro Takt) und 8 Quadpipes. Das macht bei DXT1-Texturen pro Takt einen Bedarf von 32 Pixelpipes * 4 Bit = 128 Bit. Also nichts. Die 8 GB pro Sekunde liefert schon eine 6600 GT PCIe. Bei DXT3 oder DXT5 bräuchte man die doppelte Texturbandbreite. Bei 16-Bit-Texturen wirds natürlich knapp, bei 32 Bit erst recht, von FP16-Texturen mit 4 Kanälen ganz zu schweigen.

Berücksichtigt man das Verhältnis von Tex-Ops zu arithmetischen Ops, ist man mit 16 Pixepipes á 2 SUs gegenüber 32 Pixelpipes á 1 SU natürlich kaum im Nachteil, spart jedoch Transistoren. Das ist aus meiner Sicht das Argument gegen 32 Pipes, und nicht, dass die Speicherbandbreite nicht reichen würde.

Mir wäre es natürlich lieber, wenn die bei 16 Pipes bleiben und dafür Fast-Tri-TMUs mit optimierter trilinearer Filterqualität bauen würden.

[Ailuros]

Eben. Deshalb sollte man auch eher die ALUs der bestehenden Pipelines aufbohren und nicht auch noch die Füllrate erhöhen die eh verpufft.

Und genauso wird es auch kommen fuer beide IHVs (wo immer nicht jetzt dann eben mit dem refresh des refreshes...:D ).

[Quasar]

Mir wäre es natürlich lieber, wenn die bei 16 Pipes bleiben und dafür Fast-Tri-TMUs mit optimierter trilinearer Filterqualität bauen würden.
*schreiend wegrennt*

Bitte nicht! Wenn schon, dann "optimaler" trilinearer Filterqualität. Was "optimiert" bedeutet, haben wir doch in den letzten Jahren überall herumbanden sehen...

[Ailuros]

*schreiend wegrennt*

Bitte nicht! Wenn schon, dann "optimaler" trilinearer Filterqualität. Was "optimiert" bedeutet, haben wir doch in den letzten Jahren überall herumbanden sehen...

So weit wie es gekommen ist, wird es ohne Optimierungen gar nicht mehr gehen, selbst in diesem Fall.

[Gast]

ihr immer mit euren optimierungen. sieht doch alles spitze aus in HQ und ist wenigstens schnell.

[Iwan]

ihr immer mit euren optimierungen. sieht doch alles spitze aus in HQ und ist wenigstens schnell.

selten das ich mal einem gast zustimmen muss. ingame fallen so sachen garnet auf solange man nicht gezielt danach sucht. und ich spiel ein spiel um es zu spielen und nicht um mögliche optimierungen zu finden. :)

[Quasar]

Tjo, und ich kaufe mir eine neue Grafikkarte, um eine besser visuelle Qualität zu erhalten, als mit der alten und nicht, um niedrigere LOD-Bias', vermatschte Texturen usw. zu bekommen, die ich mir auch mit einer alten Karte antun kann.

Wenn es sowas nicht mehr gibt, dann wird eben auch nicht mehr gekauft - so einfach ist.

[Gast]

selten das ich mal einem gast zustimmen muss. ingame fallen so sachen garnet auf solange man nicht gezielt danach sucht. und ich spiel ein spiel um es zu spielen und nicht um mögliche optimierungen zu finden. :)
Beim AF-Flimmern bei der GF6 braucht man nich lange zu suchen. Das fällt mir extrem auf. Das ist auch der Grund warum ich Grakas von ATI und Nvidia habe.
Meistens zocke ich mit der ATI.
Wenn ich mir aber HDR ansehen will oder ältere Spiele zocke, wo SSAA performant möglich ist, ist die NV-Karte im Rechner :)
Wenns um AA geht, fällt es gerade ingame am meisten auf.

[robbitop]

Ja, tut es. 8 Quads von der Art des nV30 wären vermutlich (außer in bilinearem Single-Texturing :eek:) noch ganz gut mit Bandbreite zu versorgen.
Außerdem ist ja nicht fix, daß alles, was in der next-Gen als Pipeline bezeichnet wird, auch eine eigene TMU hat. *g*
Du weißt schon, dass aritmetik so gut wie keine Bandbreite beansprucht?
Textursampling und das Schreiben der Pixel in den Framebuffer kostet eher Bandbreite. Und da wären 8x 4x2 katastrophal unterversorgt.
8x NV40 oder R420 Quads wären von der aritmetik jedenfalls auch nicht unterversorgt.

[robbitop]

Beim AF-Flimmern bei der GF6 braucht man nich lange zu suchen. Das fällt mir extrem auf. Das ist auch der Grund warum ich Grakas von ATI und Nvidia habe.
Meistens zocke ich mit der ATI.
Wenn ich mir aber HDR ansehen will oder ältere Spiele zocke, wo SSAA performant möglich ist, ist die NV-Karte im Rechner :)
Wenns um AA geht, fällt es gerade ingame am meisten auf.
Hast du HQ beim AF einfestellt oder nur Q? Denn bei ersterem gibts AFAIK laut den Untersuchungen von Quasar und Raff kein Flimmern, wo's nicht auch mit anderen Karten flimmert (hochfrequente Texturen neigenen immer zum Flimmern).

[Gast]

Hast du HQ beim AF einfestellt oder nur Q? Denn bei ersterem gibts AFAIK laut den Untersuchungen von Quasar und Raff kein Flimmern, wo's nicht auch mit anderen Karten flimmert (hochfrequente Texturen neigenen immer zum Flimmern).
Ich hab schon alles richtig gemacht. Treiber auf Quality, Optimierungen ausschalten, dann auf HQ. Trotzdem flimmert es bei hochfrequenten Texturen. Da kann ich machen, was ich will. :(
Bei ATI ist es nur minimal, natürlich subjektiv.
Aber ist ja nicht schlimm für mich, gibt ja nicht nur Nvidia, zum Glück. :)

[pF3NG]

Auch wenn ich es nicht für wahrscheinlich oder sogar für unsinn halte, 32 Pipelines bei R520 könnten möglich sein, vielleicht setzt man bei ATi auf XDR-RAM... (Ist nur so eine Speku meinerseits also nicht gleich nach Quellen fragen)

[Quasar]

Du weißt schon, dass aritmetik so gut wie keine Bandbreite beansprucht?
Textursampling und das Schreiben der Pixel in den Framebuffer kostet eher Bandbreite. Und da wären 8x 4x2 katastrophal unterversorgt.
8x NV40 oder R420 Quads wären von der aritmetik jedenfalls auch nicht unterversorgt.
Ja, das weiß ich. Vielen Dank.
Ich meinte auch die Pixelprozessoren vom Arithmetik-Teil her gesehen - daß ich nicht über TMUs sprach, sollte aus meinen vorigen Postings zu entnehmen sein.

[Gast]

Tjo, und ich kaufe mir eine neue Grafikkarte, um eine besser visuelle Qualität zu erhalten, als mit der alten und nicht, um niedrigere LOD-Bias', vermatschte Texturen usw. zu bekommen, die ich mir auch mit einer alten Karte antun kann.

Wenn es sowas nicht mehr gibt, dann wird eben auch nicht mehr gekauft - so einfach ist.
Na dann viel Spaß bei der Suche nach einem neuem Hobby.

[Ailuros]

Auch wenn ich es nicht für wahrscheinlich oder sogar für unsinn halte, 32 Pipelines bei R520 könnten möglich sein, vielleicht setzt man bei ATi auf XDR-RAM... (Ist nur so eine Speku meinerseits also nicht gleich nach Quellen fragen)

Eher GDDR4 aber vor Ende des Jahres (wenn ueberhaupt noch dieses Jahr) sehe ich von dem Zeug nichts. Solcher Speicher soll nach Angaben fuer R580 und dergleichen gedacht sein; immer noch nicht mehr quads als bisher nach allen Indizien nur eben mehr ALU-Power.

[Coda]

Hast du HQ beim AF einfestellt oder nur Q? Denn bei ersterem gibts AFAIK laut den Untersuchungen von Quasar und Raff kein Flimmern, wo's nicht auch mit anderen Karten flimmert (hochfrequente Texturen neigenen immer zum Flimmern).Trotz allen Dementis ist das flimmern imho vorhanden. Ich muss aber wirklich mal mit ner aktuellen ATi Karte gegenchecken.

[Quasar]

Es flimmert auch, ja. IMO aber schwer zu sagen, ob mehr oder weniger, als auf entsprechenden ATis. Kommt ganz auf's Game an, denke ich.

[Ailuros]

Trotz allen Dementis ist das flimmern imho vorhanden. Ich muss aber wirklich mal mit ner aktuellen ATi Karte gegenchecken.

Gedankensporn fuer Experimente auf einer NV4x: high quality im Treiber und SS:SE (aber in D3D, denn OGL ist nicht davon befallen); faerb mal die MIPmaps ein und bewege Dich im Technologie-Test aussen vor und zurueck. Wo genau trifft das Flimmern auf und wie gross ist der befallene Bereich?

[Ailuros]

Es flimmert auch, ja. IMO aber schwer zu sagen, ob mehr oder weniger, als auf entsprechenden ATis. Kommt ganz auf's Game an, denke ich.

Natuerlich kommt es auf das Spiel an; ich hab schon Faelle gesehen wo die texturing stage Optimierung auf einer Radeon zum flimmern fuehrt und bei einer GF hingegen nicht oder eben genau umgekehrt.

[Gast]

Hast du HQ beim AF einfestellt oder nur Q? Denn bei ersterem gibts AFAIK laut den Untersuchungen von Quasar und Raff kein Flimmern, wo's nicht auch mit anderen Karten flimmert (hochfrequente Texturen neigenen immer zum Flimmern).
Ich habe beiden Karten hier und definitv ist das flimmern mit einer NV40 Karte nicht vollkommen zu unterdrücken. Mit den ATIs gibts kein flimmern oder erheblich weniger.

Konsolenfreund

[Ailuros]

Ich habe beiden Karten hier und definitv ist das flimmern mit einer NV40 Karte nicht vollkommen zu unterdrücken. Mit den ATIs gibts kein flimmern oder erheblich weniger.

Konsolenfreund

Mit "negative LOD bias= clamp" und/oder im extremsten Fall mit noch einem Schuss positiven LOD bias dazu?

[Gast]

Mit "negative LOD bias= clamp" und/oder im extremsten Fall mit noch einem Schuss positiven LOD bias dazu?
Klar kann man mit LOD Spielereien das flimmern beseitigen, aber wer will schon im schlimmsten Fall matschige Texturen? Sorry, aber wenn ich alles auf max. Q setze, dann will ich kein flimmern mehr sehen.

Konsolenfreund

[Ailuros]

Klar kann man mit LOD Spielereien das flimmern beseitigen, aber wer will schon im schlimmsten Fall matschige Texturen? Sorry, aber wenn ich alles auf max. Q setze, dann will ich kein flimmern mehr sehen.

Konsolenfreund

Das Flimmern ersteht aber weil jegliche Applikation nicht den default LOD "0" richtig erkennt sondern zu irgend einem negativerem Wert greift.

Die "Klammer" ist im Treiber Control Panel schon seit November 2004; falls nicht bitte einen neueren Treiber benutzen.

Nur so nebenbei liefen und laufen alle meine Radeons seit R3xx mit MIPmap LOD bias auf "quality" (= +0.5). Drei mal darfst Du raten warum.

[robbitop]

Ja, das weiß ich. Vielen Dank.
Ich meinte auch die Pixelprozessoren vom Arithmetik-Teil her gesehen - daß ich nicht über TMUs sprach, sollte aus meinen vorigen Postings zu entnehmen sein.
Das war mir nicht ganz klar, da IMO deine Aussage implizierte, dass 8x NV30 Quads nicht unterversorgt wären, aber 8xNV40/R420 Quads schon (es ging ja auch immer darum dass 8 Quads nichts bringen würden).

[DrumDub]

Nur so nebenbei liefen und laufen alle meine Radeons seit R3xx mit MIPmap LOD bias auf "quality" (= +0.5). Drei mal darfst Du raten warum. jupp, mach ich auch so... "high quality" ist deshalb auch flimmriger.

[Ailuros]

jupp, mach ich auch so... "high quality" ist deshalb auch flimmriger.

High quality = 0.0
quality = +0.5
performance = +1.0
high performance = +1.5

[reunion]

WE MANAGED to get some juicy technical details about the next generation Playstation 3 RSX graphic engine. We learned that Nvidia's RSX is going to have 300 millions of transistors which is supposed to be the highest number for a graphic processor till now. We know that ATI's R520 will have even more but we suspect that the Xbox 360, R500 will have less than that.

:naughty:

http://www.theinquirer.net/?article=23888

[Ailuros]

WE MANAGED to get some juicy technical details about the next generation Playstation 3 RSX graphic engine. We learned that Nvidia's RSX is going to have 300 millions of transistors which is supposed to be the highest number for a graphic processor till now. We know that ATI's R520 will have even more but we suspect that the Xbox 360, R500 will have less than that.

:naughty:

http://www.theinquirer.net/?article=23888

Erstmal ist RSX =! G70 mit hoechster Warscheinlichkeit was die Anzahl der Einheiten betrifft und zweitens ist R500 der fabelhafte 300M Prozessor wenn Du eDRAM noch mitrechnest.

R520 hat um einiges weniger Transistoren als ihr alle erwartet.

[robbitop]

Erstmal ist RSX =! G70 mit hoechster Warscheinlichkeit was die Anzahl der Einheiten betrifft und zweitens ist R500 der fabelhafte 300M Prozessor wenn Du eDRAM noch mitrechnest.

R520 hat um einiges weniger Transistoren als ihr alle erwartet.
RSX soll sich dem G70 sogar sehr ähneln in Punkto Anzahl an Ausführungseinheiten. RSX und G70 haben auch beide ~>300Mio Transistoren.

[Demirug]

NV45-P+X+C = RSX
NV45-P+X+P = G70

Ja, ich bin ein Schwein

[zeckensack]

Ich wusste garnicht dass NV45 schon ein P hat :|

[Gast]

Würde mich bei dem Minimalismus bei ATI nicht wundern wenn er sogar weniger als der NV40 bei immer noch 16 Pipes hätte...

[Demirug]

Ich wusste garnicht dass NV45 schon ein P hat :|

So wie ich das P definiert habe schon.

[Godmode]

So wie ich das P definiert habe schon.

Wo den?

[Winter[Raven]]

was ist P? und was ist C?

[zeckensack]

So wie ich das P definiert habe schon.Verstehe.

[Gaestle]

RSX soll sich dem G70 sogar sehr ähneln in Punkto Anzahl an Ausführungseinheiten. RSX und G70 haben auch beide ~>300Mio Transistoren.


Hartware.net behaupten 128Bit HDR für RSX:
http://www.hartware.de/report_411_2.html

Grüße

[ShadowXX]

Ihr seid echt fies.....wobei ich mir beim X vorstellen könnte wofür es steht.

[ShadowXX]

Hartware.net behaupten 128Bit HDR für RSX:
http://www.hartware.de/report_411_2.html

Grüße

Hmmm...4xFP32?

[Quasar]

Hmmm...4xFP32?
Nah, die werden vermutlich eher das angepriesene "128Bit-Rendering" in den falschen Hals bekommen haben.
FP32 konnte ja schon der Fön.

[BBSR]

Hartware.net behaupten 128Bit HDR für RSX:
http://www.hartware.de/report_411_2.html

Grüße

kommt wahrscheinlich von der gamestar, bzw von der gleichen Quelle.
Die reden auch von 128Bit HDR.

[ShadowXX]

---- nonsense ---

[deekey777]

NV45-P+X+C = RSX
NV45-P+X+P = G70

Ja, ich bin ein Schwein

Wenn du das so direkt sagst...
Die eine Wochen werden wir schon aushalten, dann weiß die ganze Welt, was du meinst.
Kann jemand die Gleichungen lösen? Denn beim Lösen von Gleichungen mit mehreren Unbekannten war ich immer schwach. :D

[Quasar]

Sorry, dich wollte ich auch gar nicht quoten ShadowXX ;(

[ShadowXX]

Sorry, dich wollte ich auch gar nicht quoten ShadowXX ;(

Meine überlegung war aber trotzdem nonsense, da man bei den Filtern nicht 4xFP32 rechnen könnte, ausser man ist extrem kreativ.

Du wirst schon recht haben, das da wieder jemand was falsch in den Hals bekommen hat.

Fing doch vor nicht allzulanger Zeit mal mit 128Bit Rendering an...jetzt hat jemand nur noch ein HDR hintergehängt, damit sichs "richtiger" anhört (und sehr wahrscheinlich immer noch nonsense ist)

[Gaestle]

Meine überlegung war aber trotzdem nonsense, da man bei den Filtern nicht 4xFP32 rechnen könnte, ausser man ist extrem kreativ.

Du wirst schon recht haben, das da wieder jemand was falsch in den Hals bekommen hat.

Fing doch vor nicht allzulanger Zeit mal mit 128Bit Rendering an...jetzt hat jemand nur noch ein HDR hintergehängt, damit sichs "richtiger" anhört (und sehr wahrscheinlich immer noch nonsense ist)


Ja, sicherlich. Allerdings hat doch AFAIR aths mal erwähnt, dass das wahre, echte mega-HDR schon 128Bit gebrauchen könnte. Wobei ich nicht wissen will, was das alles an internen Veränderungen zur Folge hätte. Trotzdem wird's wohl irgendwann kommen.

Die 4x32FP-Sache bleibt mir bis dato unschlüssig. Welche Einheiten rechnen mit FP32 und sind 4fach ausgelegt? Sind da ganze Quads gemeint? ???

Grüße

[reunion]

R520 hat um einiges weniger Transistoren als ihr alle erwartet.


Sollte eher zur allgemeinen Erheiterung dienen. :D

[Quasar]

Im Prinzip könnte man schon FP32-Texturfilterung machen - das müssten dann eben die Pixeleinheiten übernehmen.
In der PS3-Vorstellung fand jedenfalls nur 128 Bit Pixel Precision Erwähnung - kein 128Bit in Verbindung mit HDR, sowie Color Formats und Color Precision.

[Gast]

Sollte eher zur allgemeinen Erheiterung dienen. :D


Naja, ein SM3 Chip ATI like wird nur das nötigste aufweisen. Da kann man wahrscheinlich von den 222 Millionen Transistoren die Nvidia beim NV40 gebraucht hat, ein paar Millionen abziehen. ;)

Würde mich sehr wundern wenn ATI mehr Transistoren als Nvidia braucht.

[Coda]

NV40 enthält auch nur "das nötigste"; nur ist das bei SM 3.0 eben verdammt viel.

Es ist schon richtig, dass ATi bei Präzission knausert wo's nur geht, aber soviel reißt das auch nicht raus. Mal abwarten...

[Gast]

NV40 enthält auch nur "das nötigste"; nur ist das bei SM 3.0 eben verdammt viel.

Es ist schon richtig, dass ATi bei Präzission knausert wo's nur geht, aber soviel reißt das auch nicht raus. Mal abwarten...
aths hat schonmal aufgeführ wieviel Ballast der NV40 mit sich trägt. Das ist ne ganze Menge.

Konsolenfreund

[Diskutator]

Naja, ein SM3 Chip ATI like wird nur das nötigste aufweisen. Da kann man wahrscheinlich von den 222 Millionen Transistoren die Nvidia beim NV40 gebraucht hat, ein paar Millionen abziehen. ;)

Würde mich sehr wundern wenn ATI mehr Transistoren als Nvidia braucht.

Bash-Boys under us*g*, Natürlich hat ein in 90nm produzierter chip ein andere anzahl von radios....

Aber deine pauschale negative antwort zum SM3.0 Chip von ATI bezüglich nur das nötigste zeigt mir welchen IQ du hast, auch nur das nötigste! ;D

[Coda]

aths hat schonmal aufgeführ wieviel Ballast der NV40 mit sich trägt. Das ist ne ganze Menge.Z.B.? Mir fällt da spontan nichts ein. Für eine SM 3.0 Architektur ist das ganze eigentlich schon schlank genug.

Na gut, der Videoprozessor hat einiges an Transistoren gebraucht, aber das hat ja nichts mit SM 3.0 zu tun.

[robbitop]

Z.B.? Mir fällt da spontan nichts ein. Für eine SM 3.0 Architektur ist das ganze eigentlich schon schlank genug.

Na gut, der Videoprozessor hat einiges an Transistoren gebraucht, aber das hat ja nichts mit SM 3.0 zu tun.
Der Videoprozessor und das defekte Tonemapping IIRC.

[Gast]

Z.B.? Mir fällt da spontan nichts ein. Für eine SM 3.0 Architektur ist das ganze eigentlich schon schlank genug.

Na gut, der Videoprozessor hat einiges an Transistoren gebraucht, aber das hat ja nichts mit SM 3.0 zu tun.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3112983&postcount=3
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3113542&postcount=7

Konsolenfreund

[Demirug]

Der Videoprozessor und das defekte Tonemapping IIRC.

Würdest du einen Videoprozessor aus einer GPU wieder ausbauen?

[robbitop]

Würdest du einen Videoprozessor aus einer GPU wieder ausbauen?
Nein, eher fixen, wie auch das Tonemapping. Aber um's Ausbauen gings auch nicht AFAIR.

[Quasar]

Würdest du einen Videoprozessor aus einer GPU wieder ausbauen?
Ich würde einen Videoprozessor ausbauen, ja.

Zumindest hat ATi ja schon H.264-Unterstützung für den R520 angekündigt.

[seahawk]

NV45-P+X+C = RSX
NV45-P+X+P = G70

Ja, ich bin ein Schwein

Hey, die Gleichungen kann man lösen. :smile:

[Gast]

nö, kann man nicht, du hast 2 gleichungen und 3 unbekannte....

[ShadowXX]

Ja, sicherlich. Allerdings hat doch AFAIR aths mal erwähnt, dass das wahre, echte mega-HDR schon 128Bit gebrauchen könnte. Wobei ich nicht wissen will, was das alles an internen Veränderungen zur Folge hätte. Trotzdem wird's wohl irgendwann kommen.

Die 4x32FP-Sache bleibt mir bis dato unschlüssig. Welche Einheiten rechnen mit FP32 und sind 4fach ausgelegt? Sind da ganze Quads gemeint? ???

Grüße

RGBA....jeweils mit FP32 und schon hast du "128Bit" Rendering.

Marketing ist doch was schönes, oder?

[seahawk]

nö, kann man nicht, du hast 2 gleichungen und 3 unbekannte....

Nicht wenn für einen eine Unbekannte eine Konstante ist. :smile:

[Gaestle]

RGBA....jeweils mit FP32 und schon hast du "128Bit" Rendering.

Marketing ist doch was schönes, oder?


Oh ja, stimmt. Danke.

*sichdieaugenreibtwegensovielbanalität* ;)


Grüße

[mapel110]

Bash-Boys under us*g*, Natürlich hat ein in 90nm produzierter chip ein andere anzahl von radios....

Aber deine pauschale negative antwort zum SM3.0 Chip von ATI bezüglich nur das nötigste zeigt mir welchen IQ du hast, auch nur das nötigste! ;D
Solche Äußerungen wollen wir hier nicht sehen.

[reunion]

Eher etwas über 200Mios nach dem was ich gehört habe....


Der Vollständigkeit halber:

R500 kommt auf 232M Transistoren, der eDRAm-Chip auf 100M.
Du warst also näher dran. ;)

http://xbox360.ign.com/articles/617/617951p3.html

[Aeros405]

Zur Info: X-Architektur soll Chips beschleunigen (http://www.heise.de/newsticker/meldung/60614)

[Coda]

Der Heise Artikel ist komisch, da steht was von 110nm. Rückzieher seitens ATI?

[Godmode]

Zur Info: X-Architektur soll Chips beschleunigen (http://www.heise.de/newsticker/meldung/60614)

Die schreiben dass der R520 in 110nm kommt??? Ich dachte der kommt fix in 90nm?? völlig verwirrt

edit: Coda war schneller

[Sunrise]

Der Vollständigkeit halber:

R500 kommt auf 232M Transistoren, der eDRAm-Chip auf 100M.
Du warst also näher dran. ;)

http://xbox360.ign.com/articles/617/617951p3.html
Laut Dave B. sind es "geschätzte":

232M - shader core - parent die
+150M - eDRAM module - daughter die
(80M eDRAM + 70M logic)
=
~382M transistors

[DrumDub]

Der Heise Artikel ist komisch, da steht was von 110nm. Rückzieher seitens ATI? oder doch was ganz anderes... ;)

[RLZ]

NV45-P+X+C = RSX
NV45-P+X+P = G70

Ja, ich bin ein Schwein
Dann haben wir noch Bier+Cola+X = Mixery.
Könnte eine interessante Lösung ergeben :D

Hiess es nicht der RSX wäre eine Generation weiter als der der G70?
Da müssten das C/P schon wichtige Teile sein...

[Godmode]

Hiess es nicht der RSX wäre eine Generation weiter als der der G70?
Da müssten das C/P schon wichtige Teile sein...

Nein ich glaub das hieß es nie, bin mir aber nicht sicher. C könnte für Cellinterface und P für PCI-Express stehen.

zb:

NV45-Brigde+X+CellInterface = RSX
NV45-Bridge+X+PCIeInterface(native) = G70

und X ist ist die Unbekannte.

[seahawk]

Die schreiben dass der R520 in 110nm kommt??? Ich dachte der kommt fix in 90nm?? völlig verwirrt

edit: Coda war schneller

Die Verbindung zum R520 ist nur eine Vermutung von heise.

[Sunrise]

http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=164302501

"ANAHEIM, Calif. — ATI Technologies Inc. (Markham, Ontario) has used the foundry services of Taiwan Semiconductor Manufacturing Co. Ltd. (TSMC) and a 0.11-micron manufacturing process to produce a PCI-Express graphics processor based on the X Architecture manufacturing approach."

Ich tippe mal auf X550.

EDIT:

"A number of companies have experimented with the X Architecture and produced test chips over several years, but ATI's chip appears to be the first one intended to go to high volume."

"The new device is expected to enter volume production late in 2005."

Meinen Tipp von oben gleich wieder vergessen. ;)

[reunion]

Die schreiben dass der R520 in 110nm kommt??? Ich dachte der kommt fix in 90nm?? völlig verwirrt



R520 kommt definitiv in 90nm.

[Xmas]

Hier ist dann wohl wahrscheinlich RV515 gemeint.

[Sunrise]

Hier ist dann wohl wahrscheinlich RV515 gemeint.
Scheint so.

[Coda]

Die Mainstreamsparte wird doch normalerweiße schon in einem kleineren Prozess gefertigt und nicht in einem größeren

[reunion]

Die Mainstreamsparte wird doch normalerweiße schon in einem kleineren Prozess gefertigt und nicht in einem größeren


Sie wird in einem billigeren Fertigungsprozess gefertigt, welcher nicht zwangsläufig der Kleinere sein muss.

[robbitop]

Sie wird in einem billigerem Fertigungsprozess gefertigt, welcher nicht zwangsläufig der Kleinere sein muss.
Siehe NV34. 150nm war bei der Chipgröße damals billiger und besser verfügbar als 130nm.

[pF3NG]

Dumme Frage aber welche Karte war NV34 nochmal??

[Sunrise]

Die Mainstreamsparte wird doch normalerweiße schon in einem kleineren Prozess gefertigt und nicht in einem größeren

Jein. 5200 lief auch noch auf 150nm vom Band. 110nm ist hochvolumig, erprobt und sehr kosteneffizient.

[robbitop]

Dumme Frage aber welche Karte war NV34 nochmal??
Geforce 5200.

[pF3NG]

aha

[Sunrise]

Dumme Frage aber welche Karte war NV34 nochmal??
GeForce FX 5100, FX 5200, 5200 Ultra, PCX 5300

[pF3NG]

Zitat:

Dumme Frage aber welche Karte war NV34 nochmal??


GeForce FX 5100, FX 5200, 5200 Ultra, PCX 5300
Kenn ich gar nicht; inwiefern unterscheidet sie sich denn von FX 5200? :|

[Sunrise]

Kenn ich gar nicht; inwiefern unterscheidet sie sich denn von FX 5200? :|
Mobile (Go):

http://www.pc-erfahrung.de/Index.html?GeforceFX5100GO.html

[pF3NG]

Hab mir sowas schon gedacht, war mir jedoch nicht ganz schlüssig, weil ich dachte da gäbe es auch FX Go 5200 mit 64 Bit.

[Diskutator]

Hab mir sowas schon gedacht, war mir jedoch nicht ganz schlüssig, weil ich dachte da gäbe es auch FX Go 5200 mit 64 Bit.
Naklar, es gibt alle Einstiegskarten auch mit 64Bit, ob ATI oder NV, beide haben das im Programm.

[Ailuros]

RSX soll sich dem G70 sogar sehr ähneln in Punkto Anzahl an Ausführungseinheiten. RSX und G70 haben auch beide ~>300Mio Transistoren.

Ich wuerde an Deiner Stelle keine Wetten eingehen, zumindest was eine der Beiden betrifft.

[reunion]

Ich wuerde an Deiner Stelle keine Wetten eingehen, zumindest was eine der Beiden betrifft.


Wenn man die Die-Größen vergleicht, erscheint es sogar so, als ob G70 mehr (und nicht weniger) als 300mio Transistoren hat IMHO. Wobei soetwas natürlich schwer vergleichbar ist.

[Quasar]

Ist es denkbar, daß R520 auch ein Daughter-Die hat? Immerhin könnte man sich so die ROP-Logik vom Parent-Die fernhalten und das Design dafür stünde auch schon.
Evtl. wird ja weniger eDRAM benutzt, das dafür mehr und schneller zum VRAM schreiben kann, so daß 2xFSAA noch immer "kostenlos" sein könnte.

[Ailuros]

Ist es denkbar, daß R520 auch ein Daughter-Die hat? Immerhin könnte man sich so die ROP-Logik vom Parent-Die fernhalten und das Design dafür stünde auch schon.
Evtl. wird ja weniger eDRAM benutzt, das dafür mehr und schneller zum VRAM schreiben kann, so daß 2xFSAA noch immer "kostenlos" sein könnte.

http://www.beyond3d.com/articles/xenos/index.php?p=05

Erstens waere weniger eDRAM nur gut genug als eine cache, zweitens sind die 10MB eDRAM auf Xenos so zugeschnitten dass man unter Umstaenden gerade noch 4xAA in "wahre" 1280*760 quetschen kann und drittens kann Xenos nicht mehr als 4xAA, egal welche Aufloesung und modus.

Hier eine schnelle Formel fuer einen TBDR und Framebuffer-Verbrauch in 1280*760:

1280*760*4*(1+1)

Hier braucht man keine viewports fuer AA, da es auf dem tile-level ausgefuehrt wird; mit sehr vielen samples kommt es eben dann zu intesiverem schreiben zum externen Speicher und die Anzahl der berechneten Tiles waechst, aber sonst limitiert die Fuellrate eher bevor der Speicher ausgehen koennte.

eDRAM ist eine Loesung fuer Bandbreite, nur brauechte man auch gesunde Mengen dafuer. Nimm Wavey's Formel und rechne bitte zumindest 6xAA in 1600 und dann eventuell noch minus Optimierungen (viewports), was aber fuer den PC auf die Nase fallen koennte, da sich hier Entwickler nicht stets auf die HW anpassen wie bei Consolen.

****edit: Quantum3D benutzt uebrigens auch eine aehnliche "viewport" Methode im Clarity Algorithmus; man nennt es dort "performance tiling".

[DrumDub]

Wenn man die Die-Größen vergleicht, erscheint es sogar so, als ob G70 mehr (und nicht weniger) als 300mio Transistoren hat IMHO. Wobei soetwas natürlich schwer vergleichbar ist. also fuad hat wohl angeblich die finalen specs und da steht was von 302 millionen. siehe g70 thread bzw. http://www.theinq.com/?article=23951

ich hatte mit ca. 290 millionen gerechnet.

[Ailuros]

also fuad hat wohl angeblich die finalen specs und da steht was von 302 millionen. siehe g70 thread bzw. http://www.theinq.com/?article=23951

ich hatte mit ca. 290 millionen gerechnet.

Wie Xmas auf B3D schon sagte: er kommt zwar naeher aber bis zur Veroeffentlichung ist es fraglich ob er alles zurechtschieben kann ;)

[Quasar]

http://www.beyond3d.com/articles/xenos/index.php?p=05

Erstens waere weniger eDRAM nur gut genug als eine cache,[...]

Genau - Cache*.
Ich tile (*SCNR*) das finale Bild in, je nach Auflösung vier, sechzehn oder 64 Tiles und rendere die der Reihe nach inklusive MSAA und schreibe sie dann vom eDRAM in den Backbuffer im VRAM (ich weiß nicht, ob man den nicht auch noch auslagern könnte).


*um eben den Performance-Hit von MSAA möglichst auf Null anzunähern.

edit:
Aber vermutlich mache ich es mir mal wieder viel zu einfach.

[Ailuros]

Genau - Cache*.
Ich tile (*SCNR*) das finale Bild in, je nach Auflösung vier, sechzehn oder 64 Tiles und rendere die der Reihe nach inklusive MSAA und schreibe sie dann vom eDRAM in den Backbuffer im VRAM (ich weiß nicht, ob man den nicht auch noch auslagern könnte).


*um eben den Performance-Hit von MSAA möglichst auf Null anzunähern.

Cache ja, aber ohne MSAA.

Bei Xenos fuer 4xAA in 1280*720 ca. 30MB / 3 viewports = 10MB eDRAM. Spekulativ kannst Du Dir die Groesse dieser viewports schon ausrechnen, aber gehe dann erstmal auf 6xAA@1600 und dann erst die tiles abrechnen und dann kannst Du die benoetigte eDRAM Menge fuer einen PC-chip ausrechnen.

Um einiges mehr als 10MB muesste es auf jeden Fall sein um 6xAA in hoeheren Aufloesungen zu erreichen + Optimierungen. Jetzt wo wir wissen wieviel die 10MB eDRAM genau in Transistoren kosten, rechne mir mal aus wieviel 20 oder 30MB eDRAM bedeuten wuerden in HW-Aufwand.

Das 4xAA in 720p ist auch nur unter Bedingungen gueltig; es wird wohl an den Entwicklern liegen ob sie diesen optimalen Fall auch dann ausnuetzen.

[Quasar]

Genau.
Deswegen möchte ich das Bild auch teilen.
Diese Tiles müssen dann eben so bemessen sein, daß das verbaut eDRAM ausreicht und schnell genug an das restliche VRAM angebunden sein, damit nicht zuviel Verzögerung entsteht.

[Ailuros]

Genau.
Deswegen möchte ich das Bild auch teilen.
Diese Tiles müssen dann eben so bemessen sein, daß das verbaut eDRAM ausreicht und schnell genug an das restliche VRAM angebunden sein, damit nicht zuviel Verzögerung entsteht.

Rechenuebung: 5MB eDRAM und rechne mir die benoetigten Tile-Groesse und Anzahl aus fuer 6xAA in 1600. Und das Ganze muesste dann auch effizienter sein als heutige Loesungen im PC; klingt aber eher nach einem um einiges schlechteren Fall.

[Quasar]

Komme ich mit 16 Tiles aus, oder brauche ich für jeden MSAA-Buffer einen eigenen Z-Buffer?

[pF3NG]

...Evtl. wird ja weniger eDRAM benutzt, das dafür mehr und schneller zum VRAM schreiben kann, so daß 2xFSAA noch immer "kostenlos" sein könnte.
Ich dachte wir reden hier von R520; der hat doch gar kein eDRAM :|

[Quasar]

Deshalb ja meine Frage von weiter oben - ob es nicht beim R520 ebenfalls die Möglichkeit einer solchen Teilung gäbe.
Wir sind hier ja im Spekulationsforum und bisher hat AFAIK noch keiner hier eine R520 in Händen gehabt.

[mrt]

Wären da nicht große Änderungen im Design nötig damit das mit den Tiles funktioniert?
Und wäre das überhaupt sinnvoll? (zB: Verwaltungsaufwand)

[Ailuros]

Komme ich mit 16 Tiles aus, oder brauche ich für jeden MSAA-Buffer einen eigenen Z-Buffer?

Hast Du ueberhaupt eine Ahnung wie zum Henker Wavey auf die 28.1MB kam fuer 720p und eDRAM?

Er sagt man soll den front buffer nicht mitberechnen ergo:

Pixels * FSAA Depth * (Pixel Colour Depth + Z Buffer Depth)

1280*720*4* (4+4) = huh was hab ich jetzt wieder verpasst? Ich komme eigentlich auf 29.5MB, denn *(32+32) kann es nicht sein.

Dem nach:

1600*1200*6* (4+4) = ~92MB

Nach OpenGL guy ist Framebuffer-Verbrauch auf einer PC GPU mit 6xAA wie folgend:

1600*1200*4*(6 (AA back buffer) + 6 (AA Z buffer) + 1 (front buffer) + 1 (back buffer) + 1 (non-AA Z buffer, some apps need this)) = 1600*1200*4*15 = 115,200,000 bytes or ~110 MB. 1600x1200 without AA needs about 22 MBs alone so that's 88 MBs more for 6x AA.

Of course, this doesn't count any extra padding or alignment that might be required so that actual memory requirements may be even higher.

Egal angenommen der Framebuffer-Aufwand liegt tatsaechlich irgendwo bei ~90MB, sind es mehr als 16 "viewports". Fuer 5MB eDRAM dann eher =/>18, ergo 6x mal mehr als Xenos (wobei ich eher an 720p mit 2xMSAA im Durchschnitt glauben will; kommt noch float HDR dazu gute Nacht....).

Die Frage ist woanders: wieso soll diese Methode schneller und effizienter sein als auf heutigen high end Karten und dass sogar mit >75M Transistoren (eDRAM + logic) fuer ~5MB. Das Ganze erscheint mir verdammt uneffizient, sonst wuerde ATI auch nicht viel davon aufhalten mehr als 3 "viewports" und ergo mehr MSAA samples zu unterstuetzen.

***edit: haette ich fast vergessen....wie man sehen kann hatte ich nie ein besonderes Talent mit Mathe *hust*

[Ailuros]

Deshalb ja meine Frage von weiter oben - ob es nicht beim R520 ebenfalls die Möglichkeit einer solchen Teilung gäbe.
Wir sind hier ja im Spekulationsforum und bisher hat AFAIK noch keiner hier eine R520 in Händen gehabt.

Eine solche "Teilung" wird schon auf den neuen Independence Systemen ausgefuehrt und Quantum3D nennt es "performance tiling" (siehe patentierter Clarity Algorithmus), aber handelt es sich auch um multi-board Systeme und hier wird die Geometrie wohl kaum skalieren. Bis zu 64xRGSS.

Es handelt sich aber auch um professionelle Simulations-Systeme; erstens braucht man hier keine Uebermenge an Leistung und zweitens so ueberladet an Geometrie sind die flight sims meistens ja auch nicht.

[Godmode]

Weis man eigentlich ob der R520 mit Single- oder Dualslotkühlung kommt?

[Winter[Raven]]

Weis man eigentlich ob der R520 mit Single- oder Dualslotkühlung kommt?

Ich denke 1 Slot sollte ausreichen, so sparsam wie ATi mit den Transitoren ist @ 0,9µ sollte es passen.

[Godmode]

']Ich denke 1 Slot sollte ausreichen, so sparsam wie ATi mit den Transitoren ist @ 0,9µ sollte es passen.

Ok klingt plausiebel.

[Gast]

']Ich denke 1 Slot sollte ausreichen, so sparsam wie ATi mit den Transitoren ist @ 0,9µ sollte es passen.
ca. 300 Mio Transistoren finde ich nicht wirklich sparsam.
Wie viel hat der G70?

[deekey777]

ca. 300 Mio Transistoren finde ich nicht wirklich sparsam.
Wie viel hat der G70?

300.000.001 - also nicht sparsam...
(Laut TheInq 302 Mio, irgendwo sah ich 298...)

[seahawk]

']Ich denke 1 Slot sollte ausreichen, so sparsam wie ATi mit den Transitoren ist @ 0,9µ sollte es passen.

Darauf würde ich nicht wetten.

[Godmode]

Ich meinte nur weil eben die XT850PE eine Dualslotkühlung hatte, und wenn der R520 noch mehr Transen und Takt hat könnte das schon sein. Naja aber man müsste halt wissen wie heiß 90nm wird. Andererseits sieht man ja beim G70, dass es auch mit Singleslotkühlung möglich ist.

[reunion]

Ich meinte nur weil eben die XT850PE eine Dualslotkühlung hatte, und wenn der R520 noch mehr Transen und Takt hat könnte das schon sein. Naja aber man müsste halt wissen wie heiß 90nm wird. Andererseits sieht man ja beim G70, dass es auch mit Singleslotkühlung möglich ist.

Beim G70 ist es aber auch nur aufgrund des extrem langen PCBs - und dem damit verbundenen langen Kühler möglich IMO.
Und den Slot unter der Grafikkarte muss man ohnehin freilassen.

[wuzetti]

ich vermute, dass sie den takt bis zum anschlag raufdrehen werden (müssen), um einigermassen mit G70 mitzukommen. von da her rechne ich fix mit einer dualslot variante!

[Godmode]

Beim G70 ist es aber auch nur aufgrund des extrem langen PCBs - und dem damit verbundenen langen Kühler möglich IMO.
Und den Slot unter der Grafikkarte muss man ohnehin freilassen.

Auch ein interessanter Aspekt! Wobei ich mich frage warum man immer noch Aluminium für Grakakühler und keine Kupfer verwendet?

ich vermute, dass sie den takt bis zum anschlag raufdrehen werden (müssen), um einigermassen mit G70 mitzukommen. von da her rechne ich fix mit einer dualslot variante!

Also ich rechne noch mit gar nichts, außer mit den Sachen die wir vom G70 schon wissen und dass der R520 in 90nm kommt!

[Quasar]

Hast Du ueberhaupt eine Ahnung wie zum Henker Wavey auf die 28.1MB kam fuer 720p und eDRAM?

Er sagt man soll den front buffer nicht mitberechnen ergo:



1280*720*4* (4+4) = huh was hab ich jetzt wieder verpasst? Ich komme eigentlich auf 29.5MB, denn *(32+32) kann es nicht sein.

Dem nach:

1600*1200*6* (4+4) = ~92MB

Nach OpenGL guy ist Framebuffer-Verbrauch auf einer PC GPU mit 6xAA wie folgend:



Egal angenommen der Framebuffer-Aufwand liegt tatsaechlich irgendwo bei ~90MB, sind es mehr als 16 "viewports". Fuer 5MB eDRAM dann eher =/>18, ergo 6x mal mehr als Xenos (wobei ich eher an 720p mit 2xMSAA im Durchschnitt glauben will; kommt noch float HDR dazu gute Nacht....).

Die Frage ist woanders: wieso soll diese Methode schneller und effizienter sein als auf heutigen high end Karten und dass sogar mit >75M Transistoren (eDRAM + logic) fuer ~5MB. Das Ganze erscheint mir verdammt uneffizient, sonst wuerde ATI auch nicht viel davon aufhalten mehr als 3 "viewports" und ergo mehr MSAA samples zu unterstuetzen.

***edit: haette ich fast vergessen....wie man sehen kann hatte ich nie ein besonderes Talent mit Mathe *hust*
Tja, keine Ahnung ehrlich gesagt (guter Bezug, gelle?)

Also einerseits, zur Frage der Wirtschaftlichkeit - dazu müsste man halt wissen, wie 'teuer' in der Produktion so ein Daughter-Die mitsamt ROPs und eDRAM ist.
Zumindest die ROPs spart man ja 1:1 im Parent-Die wieder ein, welches dadurch wiederum wirtschaftlicher zu produzieren oder eben einfach höher zu takten wäre.

Auch in der Konfiguration wäre man so weitaus flexibler, da man defektabhängigkeiten besser auf Leistungsgruppen verteilen könnte - einem Chip mit nur 3 aktiven Pixelquads genügte eben auch ein zu 75%-ROP-aktiver Daughter-Die usw.

Was die Buffer-Größe angeht: was ist denn, wenn man für die Pixel, die an Kanten liegen, also mit MSAA 'behandelt' werden, einfach nur einen Überlaufbuffer einrichtet? Die Pixel, die innerhalb von Geometrie liegen, werden direkt durchgeschoben in den Backbuffer und die Pixel, die MSAA benötigen, laufen, evtl. gelooped, durch die ROPs.

Vermutlich wäre das ein Heidenaufwand, am Ende das Bild wieder zusammenzusetzen, oder?

Außerdem gehen die Jungs bei ihrer Berechnung davon aus, daß man immer die maximale Buffergröße allozieren muss. Für den Worst-Case von 1-Pixel-Dreiecken, der sich nicht komprimieren läßt, sicherlich richtig. Wenn ich aber einen halbwegs realistischen Worst-Case, bezogen auf Leistung und Lebensdauer des Chips annehme und daraus mir eine halbwegs realistische Kompression errechne (sagen wir 2:1), habe ich über 99,9% der Applikationen bis hinauf zu 1600x1200 einen guten Speedboost und für den Rest muß dann eben die lokale Speicherbandbreite herhalten - damit ist man dann immer noch so schnell im Worst-Case, wie man es ohne diesen Trick sonst immer wäre.

Bezogen auf deine Angaben von ~110 MByte für 6xAA in 1600x1200 könnte man bei einer angenommenen Kompression von 2:1 wohl mit 3,5 MByte bei 16 Tiles auskommen und hätte sich damit IMO enorme Freiräume beim Design des Parent-Die erkauft - sowohl was Leistungsaufnahme, als auch was Transistorcount und Taktfrequenz angeht.

[Quasar]

Beim G70 ist es aber auch nur aufgrund des extrem langen PCBs - und dem damit verbundenen langen Kühler möglich IMO.
Und den Slot unter der Grafikkarte muss man ohnehin freilassen.
Soll ich mal nach Postings von ca. Anfang bis Mitte 2003 suchen, bei denen das Thema Dual-Slot Cooling ebenfalls diskutiert wurde? :)

[reunion]

Soll ich mal nach Postings von ca. Anfang bis Mitte 2003 suchen, bei denen das Thema Dual-Slot Cooling ebenfalls diskutiert wurde? :)


:D

(Ich hoffe du erwartest darauf keine Antwort).

[Gast]

']Ich denke 1 Slot sollte ausreichen, so sparsam wie ATi mit den Transitoren ist @ 0,9µ sollte es passen.

0,09µm oder 90nm bitte, 0,9µ wäre schon verdammt groß ;)

[Ailuros]

Also einerseits, zur Frage der Wirtschaftlichkeit - dazu müsste man halt wissen, wie 'teuer' in der Produktion so ein Daughter-Die mitsamt ROPs und eDRAM ist.

ca. 150M fuer die 10MB und die Logik auf Xenos (~80+~70).

Bezogen auf deine Angaben von ~110 MByte für 6xAA in 1600x1200 könnte man bei einer angenommenen Kompression von 2:1 wohl mit 3,5 MByte bei 16 Tiles auskommen und hätte sich damit IMO enorme Freiräume beim Design des Parent-Die erkauft - sowohl was Leistungsaufnahme, als auch was Transistorcount und Taktfrequenz angeht.

Wenn dann bezweifle ich dass man fuer heutige Verhaeltnisse mit weniger als 30MB eDRAM wegkommen wuerde und dass dann auch mit "viewport" Aufteilung wobei die Anzahl der "viewports" IMO nicht unendlich gross sein kann. Zu kleine "viewports" und es geht dann jegliches "macro tiling" in den Eimer; da eben SuperTiling auf einem solchen Konzept quasi basiert, koennte es sein dass meine eine Reihe von Technologien nutzlos rendert.

Bei Xenos koennten die "viewports" z.B. 427*240 pixel gross sein.

[r3ptil3]

Wow 200 Seiten Gesprächsstoff über den kommenden High-End Chip von ATI und bis jetzt nichts offizielles! :rolleyes:

Habe ich gerade gefunden (ATI R600)->
http://www.xbitlabs.com/forum/viewtopic.php?t=7628

[Ailuros]

Wow 200 Seiten Gesprächsstoff über den kommenden High-End Chip von ATI und bis jetzt nichts offizielles! :rolleyes:

Habe ich gerade gefunden (ATI R600)->
http://www.xbitlabs.com/forum/viewtopic.php?t=7628

LOL jetzt schon mit R600? Erstmal wenn 65nm dann garantiert nicht mehr in 2006 und zweitens sollten sich manche doch besser Xenos unter die Lupe nehmen........

[Gäst]

Bild und Beschreibung des R500 in der xbox360

http://www.beyond3d.com/#news24076

[wuzetti]

Weis man eigentlich ob der R520 mit Single- oder Dualslotkühlung kommt?
ich vermute, dass sie den takt bis zum anschlag raufdrehen werden (müssen), um einigermassen mit G70 mitzukommen. von da her rechne ich fix mit einer dualslot variante!
Also ich rechne noch mit gar nichts, außer mit den Sachen die wir vom G70 schon wissen und dass der R520 in 90nm kommt!

wieso fragst du dann?

[Nicky]

Wenn du wüsstest wie recht du hast...
stand schon vor ein paar Seiten...meinst du etwa das?

Unified v separate on the PC, and Nvidia’s stance

Nvidia have previously stated in public that they do not believe that unified shader architectures are the way forward. Windows Graphics Foundation 2, the version of DirectX that will ship with Longhorn, will be designed around the idea that the graphics card will have unified vertex and pixel pipelines, but will not require that to be the case. Given that ATI is working with Microsoft now on unified parts on next-gen DirectX, whilst Nvidia is saying that it doesn’t think this is the best idea, does Richard think that Nvidia will suffer, in the long run, on the PC platform from not following Microsoft?

“I’d love to say yes… I’d love to say that Nvidia are going to be stuck when it comes to Longhorn. But actually I do think they will have a unified shader architecture by the time WGF2 comes around. This time around, they don’t have the architecture and we do, so they have to knock it and say it isn’t worthwhile. But in the future, they’ll market themselves out of this corner, claiming that they’ve cracked how to do it best. But RSX isn’t unified, and this is why I think PS3 will almost certainly be slower and less powerful.

“Talking to the guys at Microsoft, it’s impossible to escape the conclusion that the future is for unified pipelines, there’s no doubt.”

Of course, the great news for ATI is that they’ll be on the second revision of their unified architecture by then, just as Nvidia is getting started....

[Demirug]

stand schon vor ein paar Seiten...meinst du etwa das?

Darauf war das nicht bezogen.

[Quasar]

ca. 150M fuer die 10MB und die Logik auf Xenos (~80+~70).
Nein, ich meinte monetär - und bitte in Verbindung mit den eingesparten Kosten sowohl beim Design als auch bei der Ausbeute des Parent-Die.
Und wie gesagt, gehe ich eigentlich nicht von 10 MByte, sondern eher von der Gegend um 3,5 MByte aus.

Was meinst du konkret, würden 3,5 MByte eDRAM plus die nötigen ROPs für einen 16xSIMD-Chip für 6xMSAA kosten (und mit nicht-loopenden ROPs könnte man vermutlich auch wahnsinnig schnelle Z-First-Passes einlegen)?



Wenn dann bezweifle ich dass man fuer heutige Verhaeltnisse mit weniger als 30MB eDRAM wegkommen wuerde und dass dann auch mit "viewport" Aufteilung wobei die Anzahl der "viewports" IMO nicht unendlich gross sein kann. Zu kleine "viewports" und es geht dann jegliches "macro tiling" in den Eimer; da eben SuperTiling auf einem solchen Konzept quasi basiert, koennte es sein dass meine eine Reihe von Technologien nutzlos rendert.

Bei Xenos koennten die "viewports" z.B. 427*240 pixel gross sein.
Ja, da müsste mal einer der Gurus was sagen - Ich sehe das momentan so, daß das Tiling die Sache nicht großartig verlangsamt, denn ob ich direkt in den Backbuffer bei 38,4 GByte/s rendere, oder den komprimierten Datenstrom erst in den Daughter-Die schiebe, der dann seine fertigen Tiles ebenfalls mit 38,4 GByte/s in das VRAM schiebt, dürfte sich ja nicht viel nehmen, ausser, daß ich im letzteren Falle eben das AA 'umsonst' bekomme.
Und intern wird das Bild bei den R300-Derivaten doch sowieso schon in Kacheln gerendert, oder?

Darüberhinaus - Geometrieleistung sollte auch für etwas größeren Verschnitt bei Applikationen ausserhalb des 3DMurks eigentlich ausreichen.

[DrumDub]

ca. 150M fuer die 10MB und die Logik auf Xenos (~80+~70). hmm... ich dacht die rops wären zusammen mit dem edram on die. sieht auf jeden fall interessant aus der chip: http://www.beyond3d.com/news/images/image.php?img=http://www.beyond3d.com/articles/xenos/images/c1.jpg&comment=ATI%20Xenos

erinnert mich auch irgendwie an den nv45 mit der hsi im package, nur größer: http://www.gamepc.com/images/labs/rev-6800gtpcie-chipLG.jpg

[Ailuros]

Ja, da müsste mal einer der Gurus was sagen - Ich sehe das momentan so, daß das Tiling die Sache nicht großartig verlangsamt, denn ob ich direkt in den Backbuffer bei 38,4 GByte/s rendere, oder den komprimierten Datenstrom erst in den Daughter-Die schiebe, der dann seine fertigen Tiles ebenfalls mit 38,4 GByte/s in das VRAM schiebt, dürfte sich ja nicht viel nehmen, ausser, daß ich im letzteren Falle eben das AA 'umsonst' bekomme.

Du bekommst doch schon auf heutigen GPUs 2xMSAA fast "for free", wozu der extra Aufwand?

Und intern wird das Bild bei den R300-Derivaten doch sowieso schon in Kacheln gerendert, oder?

Ja und zwar in etwa so:

http://www.beyond3d.com/reviews/ati/radeon9700pro/index.php?page=page4.inc#hyper

Drei Stufen von hierarchical Z wobei es drei Groessen von tiles gibt gibt; SuperTiling ist dann so wie ich es verstanden habe eine weitere Erweiterung wo man zuerst in macro tiles (quasi "viewports" ergo sehr grosse tiles) aufbricht und dann nochmal in micro tiles.

Mein Gedanke ist hier dass wenn die "viewports" fuer eDRAM (also deine "16" oder mehr) zu klein sind, dass diese dann kleiner sind als vorerwaehnte macro tiles. SuperTiling ist nicht nur fuer das load balancing fuer multi-chip/-board configs verantwortlich, sondern kann auch fuer load balancing zwischen Einheiten auf einer GPU verwendet werden.

Ich bin mir sicher dass ich mal wieder einen Haufen Mist hier kompiliere und ja ein "Guru" Beitrag waere erwuenscht; falls knapp unter 4MB eDRAM ausreichen wuerden, waeren IHVs schoen bloed wenn sie es noch nicht benutzt haben. Irgendwas macht hier keinen Sinn.

[Gast]

hmm... ich dacht die rops wären zusammen mit dem """edarm""" on die.

Pfui, ein Elektronischer Darm im PC. Aber wichtig ist ja eh nur was hinten rauskommt... ;)

Freudsche Fehlleistung? :)

Spass!!

[Johnny Rico]

Gibt es schon Informationen, wann der CHip genau vorgestellt wird bzw. verfügbar ist?

[DrumDub]

Gibt es schon Informationen, wann der CHip genau vorgestellt wird bzw. verfügbar ist? vorstellung: wahrscheinlich am 26. juli. verfügbarkeit: keine ahnung.

[robbitop]

hmm... ich dacht die rops wären zusammen mit dem edram on die. sieht auf jeden fall interessant aus der chip: http://www.beyond3d.com/news/images/image.php?img=http://www.beyond3d.com/articles/xenos/images/c1.jpg&comment=ATI%20Xenos

erinnert mich auch irgendwie an den nv45 mit der hsi im package, nur größer: http://www.gamepc.com/images/labs/rev-6800gtpcie-chipLG.jpg

Also der Daughter DIE sieht relativ zum R500 aber nicht nach 150Mio Transistoren aus. 70 Mio allein für die ROPs kommt mir auch ein wenig viel vor.

[reunion]

Also der Daughter DIE sieht relativ zum R500 aber nicht nach 150Mio Transistoren aus.


Den eDRAM sollte man auch wesentlich enger packen können.

[robbitop]

Den eDRAM sollte man auch wesentlich enger packen können.
Das wäre möglich. Hast du ein paar Zahlen dazu?

[Xmas]

Was die Buffer-Größe angeht: was ist denn, wenn man für die Pixel, die an Kanten liegen, also mit MSAA 'behandelt' werden, einfach nur einen Überlaufbuffer einrichtet? Die Pixel, die innerhalb von Geometrie liegen, werden direkt durchgeschoben in den Backbuffer und die Pixel, die MSAA benötigen, laufen, evtl. gelooped, durch die ROPs.

Vermutlich wäre das ein Heidenaufwand, am Ende das Bild wieder zusammenzusetzen, oder?

Außerdem gehen die Jungs bei ihrer Berechnung davon aus, daß man immer die maximale Buffergröße allozieren muss. Für den Worst-Case von 1-Pixel-Dreiecken, der sich nicht komprimieren läßt, sicherlich richtig. Wenn ich aber einen halbwegs realistischen Worst-Case, bezogen auf Leistung und Lebensdauer des Chips annehme und daraus mir eine halbwegs realistische Kompression errechne (sagen wir 2:1), habe ich über 99,9% der Applikationen bis hinauf zu 1600x1200 einen guten Speedboost und für den Rest muß dann eben die lokale Speicherbandbreite herhalten - damit ist man dann immer noch so schnell im Worst-Case, wie man es ohne diesen Trick sonst immer wäre.
Ein solcher "Überlauf-Buffer" lohnt sich erst wenn der Speicherplatz knapp wird. Denn Bandbreite spart man dadurch eher nicht, dazu wird die Architektur komplizierter.
ATI hat ein Patent dazu, beim Xenos ist der Framebuffer recht beschränkt, und dennoch hat man sich gegen eine solche Kompression entschieden. Das gibt schon zu denken.

[Quasar]

Ein solcher "Überlauf-Buffer" lohnt sich erst wenn der Speicherplatz knapp wird. Denn Bandbreite spart man dadurch eher nicht, dazu wird die Architektur komplizierter.
Ok. =) a ist gegeben, b1 habe ich als bekannt angenommmen und b2 ist wohl unvermeidlich. Die Frage ist, wieviel komplizierter - und welcher der Dies ist davon betroffen.
ATI hat ein Patent dazu, beim Xenos ist der Framebuffer recht beschränkt, und dennoch hat man sich gegen eine solche Kompression entschieden. Das gibt schon zu denken.
Nu ja, hier trägt M$ ja die Kosten der Herstellung, da konnte man sich schon eher ein bißchen mehr Geklotze erlauben, als das übliche Kleckern, sobald es ans eigene Geld geht.

Ich vermute außerdem, daß ein typisches XBox 360-Spiel ein Mehrfaches der Polygone eines typischen PC-Spiels mind. der nächsten zwei Jahre haben wird, so daß hier ein eher geringerer, durchschnittlicher Kompressionsfaktor angenommen werden könnte. Dazu muß die XBox 360 auch mit deutlich weniger Hauptspeicherbandbreite auskommen, als ein PC-High-End Geschoß an VRAM-Bandbreite zur Verfügung hat, fällt also entsprechend stärker ab, sobald der lokale eDRAM-Buffer überfüllt ist. Und: Konsolenspiele dürfen nicht ruckeln - PC-Spiele schon. ;)

[Quasar]

Du bekommst doch schon auf heutigen GPUs 2xMSAA fast "for free", wozu der extra Aufwand?

Weil die Füllraten weit schneller steigen, als die verfügbaren Bandbreiten (es sei denn, G70 od. R520 kommen zur allg. Überraschung doch noch mit 512Bit-DDR).

Und gleichbleibende Scores in "normalen" Games lassen sich schlecht als "ub0r"-GPU verkaufen.


BTW, da fällt mir noch 'ne Spinnerei ein:
Das Parent-Die bleibt, wie es ist (also mit normalen 2-Sample-ROPs), aber für's High-End gibt's noch einen Daughter-Die mit eDRAM und nochmals derselben Anzahl ROPs.
Wäre fein zu Skalierungszwecken zwischen UHE, HE und Mid-Range.

[reunion]

Das wäre möglich. Hast du ein paar Zahlen dazu?

Nein, das hab ich AFAIK von dir auf-geschnappt. ;)