R580 schon Anfang 2006?

[-error-]

Auf gehts in die neue Runde.

24 Pipes oder gar 32 Pipelines, erreicht durch geringeren Takt?

512 BIT Interface?

Fragen über Fragen...

[deekey777]

Der R580 hat 16 Pipelines, wurde schon mehrere Male im R520 Thread erwähnt. Einfach gesagt, ist der R580 ein vierfacher RV530, nur die Anzahl der VS bleibt bei 8.
Interessant wären auch Spekulationen zu RV540 und RV560.

"Regular participants of our forums may well have been aware of some reasonably obscure numbering schemes for many months that were used to describe parts of the performance characteristics, such as 16-1-1-1 for R520, 4-1-3-2 for RV530 and 4-1-1-1 for RV515, but until now the exact meaning of these weren't known. With the specifications for each of the chips we can now derive that the first number equates to the number of ROP's, the second the number of texture units per ROP, the third the number of "shader pipes" per ROP, and finally the Z/Stencil multiplier per ROP - with these figures in mind, we'll let you consider the ramifications for parts in the R5xx series that are still to come..."
http://www.beyond3d.com/reviews/ati/r520/index.php?p=07
Die Zahlenspielerei zum R580 ist 16-1-3-1, nur bei der letzten Zahl wäre da Verhältnis RV530 zu R580 1:2.

[TheGood]

Schön ein neue Thread mit dem titel des alten. Bin gespannt ob der Thread Titel diesesmal passt :)

[Coda]

Der Threadtitel ist schonmal sehr geil :D

Hoffen wir mal für ATi das "Anfang" diesmal die richtige Bedeutung hat ;)

[Demirug]

Nach meiner neuen Definition ist es ein unsymetrischer (3:1) 16 4xPipe Chip was bei einer älteren Zählweise ein 48 Pipe Chip ergeben würde.

EDIT Ich bin zu blöd zum rechnen. Ich meinte natürlich 64 Pipes.

[Mr. Lolman]

:)
Mal ernsthaft. Was wird der R580 besser können?

/edit:

*edit*

[deekey777]

Nach meiner neuen Definition ist es ein unsymetrischer (3:1) 16 4xPipe Chip was bei einer älteren Zählweise ein 48 Pipe Chip ergeben würde.
Nach dieser Definition wäre RV530 ein 12 Piper?

:)

Mal ernsthaft. Was wird der R580 noch besser können?
:biggrin:

[seahawk]

Mehr ALU Power ist, wenn man so will, der Hauptpunkt.

Und ja, er sollte pünktlich sein, wenn man Anfang 2006 nicht zu eng auslegt.

[Coda]

Nach meiner neuen Definition ist es ein unsymetrischer (3:1) 16 4xPipe Chip was bei einer älteren Zählweise ein 48 Pipe Chip ergeben würde.Sicher, dass die ALUs getrennte Programme rechnen und nicht immer 3 an einem zusammen?

[Coda]

Mal ernsthaft. Was wird der R580 besser können?Meine Wunschliste:

- weniger Strom verbrauchen
- Vertex TMUs
- FP16-Texturfilterung
- Mehr ALU-Leistung

Aber ich glaube kaum, dass wir bis auf das Letzte etwas davon sehen werden.

[Demirug]

:)
Mal ernsthaft. Was wird der R580 besser können?

/edit:

@Demi:

Was für eine Leistungssteigerung vgl zum R520 ist da zu erwarten? Und warum darf man beim R580 48 Pipes zählen - darf man das beim R520 auch?

Schneller Rechnen. Der Rest hängt vom Takt des Cores und Speichers ab.

64 nicht 48 Pipes (s.o)

Den R520 darf man nach meiner neuen Definition als 32 Pipe Chip ansehen.

Allerdings gilt nun um so mehr Pipe != Pipe.

Die Zahl kommt dadurch zustanden das die Nebenläufigen Datenwege gezählt werden welche die Pixelprozessoren vollständig durchlaufen.

[deekey777]

Der Threadtitel ist schonmal sehr geil :D

Hoffen wir mal für ATi das "Anfang" diesmal die richtige Bedeutung hat ;)

Wenn man bedenkt, daß der R580 vor einigen Wochen sein Tapeout hatte und die Erfahrungen aus der Fertigung des R520 miteinfliessen, könnte der Termin Anfang 2006 eingehalten werden, wenn so einen Termin überhaupt gibt.

[Coda]

Ich denke auch dass sich diesmal nichts verzögert. Ach übrigens, das Problem bei R520 war anscheinend in externer IP, also nicht ATis Verschulden

[Mr. Lolman]

Mir persönlich wärs sehr recht wenns nur ein höher getakteter R520 wär. So entzkoppelte ALUs machen mir Angst. Angst dass in ein paar Monaten Ati HW mehr als 20-30% schneller sein kann, als das aktuelle Highend Modell. => Lebenszyklus der aktuellen Highend-HW würde sich enorm verkürzen ;(

[Coda]

Mir persönlich wärs sehr recht wenns nur ein höher getakteter R520 wär. R580 ist 4xRV530, das ist fast sicher.

[Demirug]

Sicher, dass die ALUs getrennte Programme rechnen und nicht immer 3 an einem zusammen?

Natürlich nicht zu 100% Ich vermute aber das ATI hier dem X1600 Design folgen wird. Nur so können sie vermeiden einen neuen Shadercompiler schreiben zu müssen.

[Coda]

Das meinte ich ja. Ist es im X1600 Design so, dass die ALUs wirklich getrennte "Pixelshader" sind? Also nicht G70-ähnlich Triple-Issue?

[Crushinator]

Meine Wunschliste ist recht kurz:

- Keine 580+ Seiten in diesem Thread

:D

[Onkeltom421]

Wird sie sich doch eh. Zumindest jetzt bei ATI.
Wenn des alles so läuft wie geplant haben die doch höchstens 4 monate spass an der x1k serie.
Joa und dann gehts halt wie üblich weiter, höher takten und wieder ewig warten auf eine neue Architektur :redface:

[Mr. Lolman]

Schneller Rechnen. Der Rest hängt vom Takt des Cores und Speichers ab.

64 nicht 48 Pipes (s.o)

Den R520 darf man nach meiner neuen Definition als 32 Pipe Chip ansehen.

Allerdings gilt nun um so mehr Pipe != Pipe.

Die Zahl kommt dadurch zustanden das die Nebenläufigen Datenwege gezählt werden welche die Pixelprozessoren vollständig durchlaufen.

Hast du meine dumme (!?) Frage doch noch vorm Edit entdeckt. :)

zur Antwort: Toll aber imo shit. Wer kauft sich ernsthaft einen R520 wenn der R580 eh wiederalles in Grund und Boden stampft und praktisch schon in den Startlöchern steht. Die müssten den min. ein halbes Jahr zurückhalten, und irgendwie glaub ich daran nicht ganz...

[Coda]

Eher nicht. Nach R5xx sollte recht schnell (Ende 2006, Anfang 2007) der erste WGF 2.0 Chip kommen im US-Design.

[Demirug]

Das meinte ich ja. Ist es im X1600 Design so, dass die ALUs wirklich getrennte "Pixelshader" sind? Also nicht G70-ähnlich Triple-Issue?

Soweit mir bekannt ja. Wobei man das ja nicht wirklich als "Pixelshader" bezeichnen kann. Das ganze (ALUs+TMUs+Dispatcher+Registerspeicher) ist der Pixelshader.

Da pro Takt sowieso nur ein Thread (beim X1600er) im Dispatcher bearbeitet werden muss ist das noch recht einfach zu machen. Ich vermute allerdings das es im X1800 mindestens zwei oder gar 4 Dispatcher sind. Das es komplett Global ist glaube ich einfach nicht. OK, ich habe einfach zuviel Gray Supercomputer Design Unterlagen gelesen was wohl dazu führt das ich nicht glauben kann das sich jemand auf diesen Wahnsinn einlassen würde.

[Coda]

Soweit mir bekannt ja. Wobei man das ja nicht wirklich als "Pixelshader" bezeichnen kann. Das ganze (ALUs+TMUs+Dispatcher+Registerspeicher) ist der Pixelshader.Deshalb ja in Anführungszeichen.

Du meinst Cray, nicht Gray, oder?

[Crushinator]

(...) Joa und dann gehts halt wie üblich weiter, höher takten und wieder ewig warten auf eine neue Architektur :redface:
Dies mal geht's "einwenig" schneller. ;)

[deekey777]

Eine weitere dumme Frage: Wie gut/schlecht ist die Performance der X1600XT in Relation zu ihrer Hardware?

[reunion]

Auf gehts in die neue Runde.

24 Pipes oder gar 32 Pipelines, erreicht durch geringeren Takt?

512 BIT Interface?

Fragen über Fragen...

16TMUs, 48ALUs, 16 ROPs, Takt knapp unter 700Mhz.
Sonst erwarte ich keine Änderungen gegenüber R520.

Kurz 4x RV530.

[Demirug]

Hast du meine dumme (!?) Frage doch noch vorm Edit entdeckt. :)

zur Antwort: Toll aber imo shit. Wer kauft sich ernsthaft einen R520 wenn der R580 eh wiederalles in Grund und Boden stampft und praktisch schon in den Startlöchern steht. Die müssten den min. ein halbes Jahr zurückhalten, und irgendwie glaub ich daran nicht ganz...

Für mehr TMUs (die das Grund Design auch vertragen könnte) fehlt einfach die Speicherbandbreite. Zudem belastet eine TMU Pipe das Thread Buget viel stärker als eine ALU Pipe. Und Threads sind aufgrund des benötigten Speicher nicht ganz billig.

[Demirug]

Deshalb ja in Anführungszeichen.

Du meinst Cray, nicht Gray, oder?

Ja, ist heute scheinbar nicht mein Tag.

[reunion]

Eine weitere dumme Frage: Wie gut/schlecht ist die Performance der X1600XT in Relation zu ihrer Hardware?


Sehr gut IMHO. Das Teil bringt trotz eine deutlich unterlegenen theoretischen Füllrate mehr dergleichen auf die Straße, als eine X700pro. Man erreicht fast das theoretische Maximum.

http://www.xbitlabs.com/images/video/radeon-x1000/x1600/Fillrate_x16.gif

Von der Shaderleistung mal ganz zu schweigen...
Allerdings sind die 4 TMUs trotz allem natürlich zu wenig.

[seahawk]

Eine weitere dumme Frage: Wie gut/schlecht ist die Performance der X1600XT in Relation zu ihrer Hardware?

Für eine 1 Quad Chip sehr gut, für einen 3 Quadchip mit dieser taktung eher naja. Kommt alos immer auf den Vergleich an.

R580 optimiert den R520 imho und wird das Portofolio wohl eher nach oben abrunden.

[Demirug]

Sehr gut IMHO. Das Teil bringt trotz eine deutlich unterlegenen theoretischen Füllrate mehr dergleichen auf die Straße, als eine X700pro. Man erreicht fast das theoretische Maximum.

IMHO ist die X700Pro am vermurksten Speicherkontroller/Cachemanagment kollabiert.

Das hat man bei den neuen Chips nun scheinbar viel besser im Griff. Allerdings ist das mit Vorsicht zu genissen. ATI gibt selbst zu das der neue Speicherkontroller durch Applikationsspezifische Profile sehr gut an eine Anwendung angepasst werden kann. Das war jedoch hauptsächlich auf die X1800 bezogen in wie weit das auch für die X1600 gilt ist nicht ganz klar.

[Demirug]

Für eine 1 Quad Chip sehr gut, für einen 3 Quadchip mit dieser taktung eher naja. Kommt alos immer auf den Vergleich an.

R580 optimiert den R520 imho und wird das Portofolio wohl eher nach oben abrunden.

Eigentlich kann man in ja nur als 1 Quad einordnen da man bisher immer die TMUs als Mass genommen hat.

[reunion]

R580 optimiert den R520 imho und wird das Portofolio wohl eher nach oben abrunden.


Durchaus möglich, R520 ist ja was die Die-Fläche betrifft eigentlich ein Winzling. Eventuell dekradiert man ihn nach der R580-Vorstellung einfach zum Midragechip.

[Die gelbe Eule]

Everest weiß wieder mehr:

- detection of ATI R520, R520 Pro, R520 SE video chips
- detection of ATI R520 XT, R520 XT Platinum video chips
- detection of ATI R520GL Pro, R520GL XT video chips
- detection of ATI RV530 LE, RV530 Pro, RV530 SE video chips
- detection of ATI RV530 VE, RV530 XT, RV530GL video chips

Das sieht sehr wild aus ...

Denke das der R580 erst dann kommt, wenn man sieht wo die X1800XT eingeschalgen ist und was NV bringt. Diesmal wird eher ATi abwarten.

[reunion]

IMHO ist die X700Pro am vermurksten Speicherkontroller/Cachemanagment kollabiert.

Das hat man bei den neuen Chips nun scheinbar viel besser im Griff.


Natürlich spielt das auch mit rein.
Doch auch im Vergleich zur GF6800, mit immerhin 12TMUs, steht die X1600XT verdammt gut da.



Allerdings ist das mit Vorsicht zu genissen. ATI gibt selbst zu das der neue Speicherkontroller durch Applikationsspezifische Profile sehr gut an eine Anwendung angepasst werden kann. Das war jedoch hauptsächlich auf die X1800 bezogen in wie weit das auch für die X1600 gilt ist nicht ganz klar.

Ob man wirklich auf so einen unbedeutenden Füllratenmesser optimiert?
Vorallem, da die R520-Leistung zurzeit je nach Spiel noch stark schwankt, wäre man gut beraten, sich auf echte Spiele zu konzentrieren.

[-error-]

R580 ist 4xRV530, das ist fast sicher.

Der R580 hat die vierfache Leistung einer RV530, oder wie meinst du das?

[seahawk]

Durchaus möglich, R520 ist ja was die Die-Fläche betrifft eigentlich ein Winzling. Eventuell dekradiert man ihn nach der R580-Vorstellung einfach zum Midragechip.

Macht ja auch Sinn. Dann bringt man die 12Pipe Versionen aus den Restbeständen und spart sich evtl. eine Neuentwicklung.

[seahawk]

Eigentlich kann man in ja nur als 1 Quad einordnen da man bisher immer die TMUs als Mass genommen hat.

Dann ist R580 auch nur ein 16 Piper. Imho ist die Pipebezeichnung sowieso am Ende und das Festmachen via TMU auch. Eigentlich kann man heute Chips imho nur noch über de nPreis sinnvoll vergleichen.

[seahawk]

Ob man wirklich auf so einen unbedeutenden Füllratenmesser optimiert?
Vorallem, da die R520-Leistung zurzeit je nach Spiel noch stark schwankt, wäre man gut beraten, sich auf echte Spiele zu konzentrieren.

Sagen wir so, wer eingefärbete Mipmaps detected, der könnte auch auf sowas hin optimieren. Wobei ich ausrücklich könnte meine. Ich traue beide nIHVs so etwas grundsätzlich zu.

[Ailuros]

Meine Wunschliste ist recht kurz:

- Keine 580+ Seiten in diesem Thread

:D

ROTFLMAO :biggrin:

[reunion]

Der R580 hat die vierfache Leistung einer RV530, oder wie meinst du das?

Theoretisch sogar mehr, da der Takt höher sein wird.

[deekey777]

Everest weiß wieder mehr:

- detection of ATI R520, R520 Pro, R520 SE video chips
- detection of ATI R520 XT, R520 XT Platinum video chips
- detection of ATI R520GL Pro, R520GL XT video chips
- detection of ATI RV530 LE, RV530 Pro, RV530 SE video chips
- detection of ATI RV530 VE, RV530 XT, RV530GL video chips

Das sieht sehr wild aus ...

Das wußte Everst schon vor 2 Monaten. X-D

Denke das der R580 erst dann kommt, wenn man sieht wo die X1800XT eingeschalgen ist und was NV bringt. Diesmal wird eher ATi abwarten.
Wie meinen?
Die R580er Grafikkarten kommen bestimmt nicht früher oder später, egal ob sich der R520 durchsetzt oder nicht. Er kommt dann, wenn er reif genug ist, aber er ist nicht fertig.

[Ailuros]

Theoretisch sogar mehr, da der Takt höher sein wird.

Βevor sich jetzt wieder jemand verwirrt, R580 wird genauso viel "2x oder mehr mal" schneller sein als R520, wie eben auch G70 vs. NV40.

Ich weiss dass Du im Vergleich zu RV530 meintest, aber es ist eben mal wieder viel zu leicht falsch zu verstehen.

Was ich hiermit meine sehen wir seit NV40 neuere GPUs und werden noch einen Schub nach G70/R520 sehen, die eigentlich um ein X Prozentual schneller sind als ihre Vorgaenger.

Das Bild wird sich IMHO erst nach DX10 radikal aendern, aber selbst hier ist die Sache relativ, denn die Konzentration wird ja auch hier auf hoehere Programmierbarkeit und arithmetische Effizienz sein, was wohl heisst dass solange wir keine "echten" DX9.0 Spiele fuer den PC haben, dass die Leistungssteigerung bis dahin eher "mixed bag" sein wird.

[MikBach]

Dann ist R580 auch nur ein 16 Piper. Imho ist die Pipebezeichnung sowieso am Ende und das Festmachen via TMU auch. Eigentlich kann man heute Chips imho nur noch über de nPreis sinnvoll vergleichen.
Mit dem Preis sehe ich ähnlich..
Du legst die Pipelineanzahl an den TMUs fest?
Ich denke dass ALUs für die Pipe wichtiger sind. Speziell bei den Shadern.

[robbitop]

Natürlich spielt das auch mit rein.
Doch auch im Vergleich zur GF6800, mit immerhin 12TMUs, steht die X1600XT verdammt gut da.
Aber deutlich weniger Coretakt ;)

[seahawk]

Mit dem Preis sehe ich ähnlich..
Du legst die Pipelineanzahl an den TMUs fest?
Ich denke dass ALUs für die Pipe wichtiger sind. Speziell bei den Shadern.

Zumindest was es mal früher so, dass man die TMUs zählte. Ich halte es heute für nicht mehr zeitgemäß. Aber wie gesagt, betrachte den RV530. 4 TMUs und 12 ALUs.

Es sieht stark aus im Vergleich zu Chips mit 4 TMUs und er sieht ziemlich schwach aus zu welchen mit 12ALUs. Und imho ist es dem Kunden egal wie eine bestimmte Leistung erzielt wird. Wichtig ist imho das Preis-Leistungsverhältnis und daher kann man heute sinnvoll imho nur über den Preis einordnen.

< 100 euro
100-150 Euro
150-200 Euro
200-300 Euro
> 300 Euro

[deekey777]

Aber deutlich weniger Coretakt ;)

Nur weil die 6600GT uns verwöhnt/gezeigt hat, daß die Mittelklasse unbedingt schneller sein muß als die Vorgänger-Oberklasse, muß die X1600XT nicht schneller sein als die X800 oder 6800.
Kann man den Sinn dieses Satzes erkennen?

[Ailuros]

Mit dem Preis sehe ich ähnlich..
Du legst die Pipelineanzahl an den TMUs fest?
Ich denke dass ALUs für die Pipe wichtiger sind. Speziell bei den Shadern.

Es sind und bleiben 4 quads auf R580.

Jein was die ALUs betrifft; es ist noch wichtiger was jede ALU eigentlich kann.

Milchmaedchen-rechnung:

16 * 4 MADDs = 64 MADDs/clock * 0.625GHz = 40 GMADDs/clock = 80 GFLOPs

24 * 8 MADDs = 192 MADDs/clock * 0.43GHz = 82.56 GMADDs/clk = 165 GFLOPs

Falls die ALUs auf R580 unveraendert bleiben, worueber ich momentan noch keine Ahnung habe, sieht es nicht unbedingt nach einem Vorteil zur naechsten Loesung der Konkurrenz aus.

[Demirug]

Ob man wirklich auf so einen unbedeutenden Füllratenmesser optimiert?
Vorallem, da die R520-Leistung zurzeit je nach Spiel noch stark schwankt, wäre man gut beraten, sich auf echte Spiele zu konzentrieren.

Das Teil wird gerne benutzt und gerade bei Tests die immer gleich ablaufen geht das Optimieren am schnellsten.

[MikBach]

Zumindest was es mal früher so, dass man die TMUs zählte. Ich halte es heute für nicht mehr zeitgemäß.
Das ist ja eben das Problem, dass die Bezeichnung Pipeline für die Performance nicht mehr wichtig ist. Man muss tiefer gehen und sich mit ALUs, TMUs und ROPs auseinandersetzen. Wird alles viel komplexer...

[Ailuros]

Nur weil die 6600GT uns verwöhnt/gezeigt hat, daß die Mittelklasse unbedingt schneller sein muß als die Vorgänger-Oberklasse, muß die X1600XT nicht schneller sein als die X800 oder 6800.
Kann man den Sinn dieses Satzes erkennen?

Technologie macht Fortschritte; IHVs koennen nicht fuer immer nutzlosen Balast mit sich schleppen wenn die Konzentration in den arithmetischen Bereich kommen soll.

Ich hab zwar keine Ahnung was diesem Bereich DX10 GPUs betrifft, aber ich frage mich momentan ernsthaft ob wir dort mehr als 16 TMUs wirklich brauchen.

[Demirug]

Dann ist R580 auch nur ein 16 Piper. Imho ist die Pipebezeichnung sowieso am Ende und das Festmachen via TMU auch. Eigentlich kann man heute Chips imho nur noch über de nPreis sinnvoll vergleichen.

Was die Pipes angeht: Meine reden ich wollte damit eigentlich aufzeigen das es so einfach nicht mehr funktioniert.

Der Preis ist nett aber ohne weitere kenngrößen Nutzloss oder sollen wir einfach sagen die Karte ist teuerer also muss sie besser sein?

[Demirug]

Ich hab zwar keine Ahnung was diesem Bereich DX10 GPUs betrifft, aber ich frage mich momentan ernsthaft ob wir dort mehr als 16 TMUs wirklich brauchen.

Wir brauchen so viele TMUs wie man sinnvoll mit Daten versorgen kann.

Allerdings erwarte ich das diese TMUs im Laufe der Zeit einfacher werden. Ich gehe sogar soweit das wir irgendwann TMUs haben werden die nur noch Bilinear Filtern können.

[Ronny145]

Wie wirkt sich denn die verbesserte Alu Power aus oder wieviel schneller wäre denn so eine Karte im Vergleich zur jetzigen X1800XT? Wenn man das schon beantworten kann...
Ich kann mir unter der Alu Power nichts vorstellen.

[Demirug]

Wie wirkt sich denn die verbesserte Alu Power aus oder wieviel schneller wäre denn so eine Karte im Vergleich zur jetzigen X1800XT? Wenn man das schon beantworten kann...
Ich kann mir unter der Alu Power nichts vorstellen.

Das wird sehr stark vom Spiel abhängen. Spiele die viel rechnen müssen um die Pixelfarbe zu bestimmen profitieren davon. Kommt die Farbe dagegen hauptsächlich nur aus den texturen bringt die zusätzliche ALU Power gar nichts.

[dargo]

R580 ist 4xRV530, das ist fast sicher.
Der RV530 ist doch die X1600XT oder ?

Würde das bedeuten, daß der R580 zb. ca. 45% schneller bei 1600x1200 4xAA in Battlefield 2 wäre ?

X1800XT = 82fps
X1600XT = 29,8fps

29,8fps x4 = 119,2fps was ~45% schneller gegenüber der X1800XT wäre.

Das wär ja goil. :cool:

[MikBach]

Der RV530 ist doch die X1600XT oder ?

Würde das bedeuten, daß der R580 zb. ca. 45% schneller bei 1600x1200 4xAA in Battlefield 2 wäre ?

X1800XT = 82fps
X1600XT = 29,8fps

29,8fps x4 = 119,2fps was ~45% schneller gegenüber der X1800XT wäre.

Das wär ja goil. :cool:
So einfach ist das nicht...
Da spielen zu viele Faktoren wie z.B. Speicherbandbreite mit ein, dass man es nicht so pauschal sagen kann.

[dargo]

So einfach ist das nicht...
Da spielen zu viele Faktoren wie z.B. Speicherbandbreite mit ein, dass man es nicht so pauschal sagen kann.
Welche Möglichkeiten hat eigendlich ATI die Speicherbandbreite weiter zu erhöhen ?

Ich möchte nämlich keinen GDDR3 mit 900-1000Mhz und 2,5V haben. X-D

Oder wird doch das Speicherinterface auf 384Bit erhöht ?
Ist eigendlich dieser Ringbus auf einem R580 möglich ?

[Crushinator]

Würde das bedeuten, daß der R580 zb. ca. 45% schneller bei 1600x1200 4xAA in Battlefield 2 wäre ?
Nicht ganz, weil nicht zu erwarten ist, daß die Speicherbandbreite (wichtig für AA) wesentlich steigt.
Welche Möglichkeiten hat eigendlich ATI die Speicherbandbreite weiter zu erhöhen ?
Mommentan hauptsächlich über den Takt.
Ich möchte nämlich keinen GDDR3 mit 900-1000Mhz und 2,5V haben. X-D

Oder wird doch das Speicherinterface auf 384Bit erhöht ?
Ist eigendlich dieser Ringbus auf einem R580 möglich ?
R580 ist nur ein Refresh. Viel mehr als gesteigerte ALU-Leistung würde ich da nicht erwarten.

[MikBach]

R580 ist nur ein Refresh. Viel mehr als gesteigerte ALU-Leistung würde ich da nicht erwarten.
Die aber für die Shaderleistung sehr wichtig ist.

[Crushinator]

Die aber für die Shaderleistung sehr wichtig ist.
Exakt. :)

[Winter[Raven]]

Schon interessant, also vor X1k Reihe meinten ja einige die Shaderperf seih unwichtig die ein G70 drauf hat, Spiele dafür würde es sowieso geben... Aufeinmal ist man begeistert ... Man legt alles wie es einem passt, gelle?

[-error-]

']Schon interessant, also vor X1k Reihe meinten ja einige die Shaderperf seih unwichtig die ein G70 drauf hat, Spiele dafür würde es sowieso geben... Aufeinmal ist man begeistert ... Man legt alles wie es einem passt, gelle?

Wäre mir neu, das Shaderperformance wichtig ist, hat man spätestens bei FarCry gesehen und zu diesem Zeitpunkt war die G70 wohl kaum auf den Markt ;)

[Crushinator]

']Schon interessant, also vor X1k Reihe meinten ja einige die Shaderperf seih unwichtig die ein G70 drauf hat, Spiele dafür würde es sowieso geben... Aufeinmal ist man begeistert ... Man legt alles wie es einem passt, gelle?
Sie ist ja auch in sofern unwichtig, weil man z.Z. noch hauptsächlich Spezialfälle konstruieren muß, damit sich die ALUs im G70 optimal entfalten können. Man sieht ja, wie der im theoretischen Vergleich teils deutlich unterlegene R520 trotzdem in aktuellen Titeln performt. ;)

[mboeller]

WOW;

das hat mich dann doch überrascht wie gut der X1600XT bei PS3.0 incl. Branching im Vergleich zu einer 6800er abschneidet :

http://www.xbitlabs.com/images/video/radeon-x1000/x1600/Xbitmark_x16.gif

Link: http://www.xbitlabs.com/images/video/radeon-x1000/x1600/Xbitmark_x16.gif

Hätte ich nicht erwartet.

Sagt das was über die PS3.0-Eigenschaften des Xenos aus?

[Demirug]

Sie ist ja auch in sofern unwichtig, weil man z.Z. noch hauptsächlich Spezialfälle konstruieren muß, damit sich die ALUs im G70 optimal entfalten können. Man sieht ja, wie der im theoretischen Vergleich teils deutlich unterlegene R520 trotzdem in aktuellen Titeln performt. ;)

Konstruieren muss man die Spezialfälle nicht. Es gibt durchaus Shader aus aktuellen Spielen in denen ein G70 Takt und Pixelprozessor normalisiert 4 mal so schnell ist.

Der R520 profitiert hierbei von der ATI typischen besseren Entkopplung von ALUs und TMUs. Deswegen müssen sie ja jetzt anfangen die Rechenleistung zu erhöhen weil sie befürchten müssen das auch nVidia diese Entkopplung verbessert.

Desweiteren hängen die Spiele bei den bevorzugten Einstellungen (viel AA/AF und hohe Auflösungen) immer noch stark an den TMUs und der Bandbreite. Mehr rechenpower zu haben bedeutet aber auch das man endlich Shader AF einbauen kann um das Shaderflimmern (gerade beim hochfrequenten Bumpmapping) weg zu bekommen.

[Demirug]

WOW;

das hat mich dann doch überrascht wie gut der X1600XT bei PS3.0 incl. Branching im Vergleich zu einer 6800er abschneidet :


Hätte ich nicht erwartet.

War aufgrund der unterschiedlichen Arbeitsweise zu erwarten. Allerdings bin ich jetzt nicht sicher welche Branchfrequenz dieser Test nutzt.

Sagt das was über die PS3.0-Eigenschaften des Xenos aus?

Nicht direkt. Der Test betrifft ja nur ein PS3 Feature und zudem sind ein R520 und ein Xenos ja nicht direkt vergleichbar. Da der Xenos aber eine ähnliche Threading Logik hat kann man beim dynamischen Branching ähnliche Ergebnisse erwarten.

[MikBach]

Konstruieren muss man die Spezialfälle nicht. Es gibt durchaus Shader aus aktuellen Spielen in denen ein G70 Takt und Pixelprozessor normalisiert 4 mal so schnell ist.
Es macht nur was aus, wenn dieser innerhalb der Szene abläuft.

Der R520 profitiert hierbei von der ATI typischen besseren Entkopplung von ALUs und TMUs. Deswegen müssen sie ja jetzt anfangen die Rechenleistung zu erhöhen weil sie befürchten müssen das auch nVidia diese Entkopplung verbessert.

Das ist ja eben die Frage..
haben sie es gemacht, um die Leistung herbeizuzaubern? :)

[Coda]

R580 ist nur ein Refresh. Viel mehr als gesteigerte ALU-Leistung würde ich da nicht erwarten.Doch doch, der hat 3x mehr ALUs als R520.

[deekey777]

http://www.techpowerup.com/reviews/ATI/R5XX
In der Präsentation wird bei der X1300 und der X1800 von Shader Units gesprochen, bei der X1600 aber von Shader Prozessoren. Warum? Marketing Blah-Blah oder unbeabsichtliches Herausplaudern, daß der RV530 doch anders ist als R520? In den anderen Präsentationen, die überall zu finden sind, wird dagegen nicht mehr unterschieden.

[Crushinator]

Doch doch, der hat 3x mehr ALUs als R520.
Und was ist jetzt der extakte Unterschied zu meiner Aussage? Sind 3 mal mehr ALUs keine gesteigerte ALU-Leistung?

[deekey777]

Und was ist jetzt der extakte Unterschied zu meiner Aussage? Sind 3 mal mehr ALUs keine gesteigerte ALU-Leistung?

Daß es doch kein Refresh ist? :)

[Demirug]

Es macht nur was aus, wenn dieser innerhalb der Szene abläuft.

Der Shader wird benutzt. Allerdings weiß ich jetzt nicht wie oft und für wie viele Pixel.


Das ist ja eben die Frage..
haben sie es gemacht, um die Leistung herbeizuzaubern? :)

Wer ATI? Die arbeiten schon immer mit entkoppelten TMUs bei den Pixelshadern. nVidia hat mit dem NV30 Teilweise und mit dem NV40 ganz damit aufgehört und ist auf die Rampage Lösung übergegangen. Wobei das nur für den Pixelshader gilt der Vertexshader ist wieder anders.

[Ailuros]

R580 ist nur ein Refresh. Viel mehr als gesteigerte ALU-Leistung würde ich da nicht erwarten.

Ja aber nicht der "traditionelle refresh" wie wir in bis jetzt von ATI gewoehnt sind. Bis jetzt hatten ATI's Refreshes meistens nur eine hoehere Taktrate und schnelleren (oder sogar mehr) Speicher.

[Ailuros]

Und was ist jetzt der extakte Unterschied zu meiner Aussage? Sind 3 mal mehr ALUs keine gesteigerte ALU-Leistung?

Es sollte zumindest 3x mal die ALU Leistung heissen; wenn man davon ausgeht dass sich nichts an den ALUs aendern wird. Ich bezweifle zwar dass sich irgendwas besonderes daran aendern wird, aber da wir nichts darueber wissen bin ich lieber noch etwas vorsichtig damit.

[Crushinator]

Daß es doch kein Refresh ist? :)
Es ist genau so ein Refresh wie G70 zu NV40 oder NV35 zu NV30. Es wird sich doch nichts gravierendens am Feature-Umfang ändern. :)

[Ailuros]

Wer ATI? Die arbeiten schon immer mit entkoppelten TMUs bei den Pixelshadern. nVidia hat mit dem NV30 Teilweise und mit dem NV40 ganz damit aufgehört und ist auf die Rampage Lösung übergegangen. Wobei das nur für den Pixelshader gilt der Vertexshader ist wieder anders.

Irgendwann in naechster Zeit will ich mal versuchen Killgariff diesbezueglich ans "Microfon" zu lozen. Fall er darauf eingehen sollte, koennte es sein dass ein paar sehr interessante Antworten ankommen.

[Coda]

Und was ist jetzt der extakte Unterschied zu meiner Aussage? Sind 3 mal mehr ALUs keine gesteigerte ALU-Leistung?Argh verlesen...

[Ailuros]

NVIDIA wird in Sachen ALU Leistung sicher nicht im Rueckstand stehen mit dem naechsten Schub. Bleiben die heutigen ALUs gleich rechne ich mit knapp unter 300GFLOPs.

[Johnny Rico]

Was ist eigentlich "branching"? Was bringt das in Spielen?

[Coda]

Man kann pro Pixel verschiedene Berechnungen je nach Bedingung ausführen, z.B. ab einer bestimmten Entfernung nur noch günstigeres Normal- statt Parallaxmapping.

Wenn du schonmal programmierst hast: "if" ist ein typischer branch.

[deekey777]

Ja aber nicht der "traditionelle refresh" wie wir in bis jetzt von ATI gewoehnt sind. Bis jetzt hatten ATIs Refreshes meistens nur eine hoehere Taktrate und schnelleren (oder sogar mehr) Speicher.

Der Meinung bin auch.

Man kann pro Pixel verschiedene Berechnungen je nach Bedingung ausführen, z.B. ab einer bestimmten Entfernung nur noch günstigeres Normal- statt Parallaxmapping.

Wenn du schonmal programmierst hast: "if" ist ein typischer branch.

Vor Äonen habe ich mal mit Basic einfache Programmchen gemacht, da kamen "if"+"then" fast immer vor: Ich hab' gebrancht! :biggrin:

[Coda]

Ja aber nicht der "traditionelle refresh" wie wir in bis jetzt von ATI gewoehnt sind. Bis jetzt hatten ATI's Refreshes meistens nur eine hoehere Taktrate und schnelleren (oder sogar mehr) Speicher.Irgendwie aber doch, weil mit dem RV530 ist die Technik ja schon da X-D

[Crushinator]

Was dynamisches Branchen für's Spielen bringt ist Geschwindigkeit, weil dadurch kein neuer Renderpass/kein Shaderswitch mehr notwendig ist um - wie Coda oben schon beschrieben hat - dynamisch angepaßte Effekte nach Bedarf zu rendern.
Irgendwie aber doch, weil mit dem RV530 ist die Technik ja schon da X-D
(y) X-D

[Coda]

Dynamische Sprünge helfen nicht nur der Performance, sondern ermöglichen auch neue Effekte.

[Demirug]

Dynamische Sprünge helfen nicht nur der Performance, sondern ermöglichen auch neue Effekte.

Da muss ich jetzt aber etwas wiedersprechen. Du kannst jeden SM3 HLSL Shader auch so kompileren lassen das er keine dynamische Sprüngen enthält und der Effekt trotzdem der gleiche bleibt. Es ist daher wirklich nur ein Performances Feature aber ein sehr nützliches.

[Ailuros]

Irgendwie aber doch, weil mit dem RV530 ist die Technik ja schon da X-D

Du weisst genau wie ich es meinte. Wieviele Aenderungen hatte der R350 z.B. im Vergleich zum NV35? R420 zu R480?

Natuerlich ist der RV530 der quasi "Vorreiter" von R580, aber etwa in gleichem Sinn gilt das gleiche fuer NV43 und G70. Nur waren bei NVIDIA die Refreshes eben stets mehr als nur hoeher getaktete GPUs; siehe auch NV20->NV25.

[Ailuros]

Da muss ich jetzt aber etwas wiedersprechen. Du kannst jeden SM3 HLSL Shader auch so kompileren lassen das er keine dynamische Sprüngen enthält und der Effekt trotzdem der gleiche bleibt. Es ist daher wirklich nur ein Performances Feature aber ein sehr nützliches.

Die Spiele die mit G70/R520 entwickelt werden machen mir jetzt schon Angst; klingt mir nach einem ausgezeichneten Wirrwarr fuer Entwickler. Erstmal eine Checkliste was auf dem einem und dem anderen nicht geht und dann was auf einem schnell und auf dem anderen langsam ist und dann erst anfangen sich den Kopf zu zerbrechen....tstststs

[Coda]

Da muss ich jetzt aber etwas wiedersprechen. Du kannst jeden SM3 HLSL Shader auch so kompileren lassen das er keine dynamische Sprüngen enthält und der Effekt trotzdem der gleiche bleibt. Es ist daher wirklich nur ein Performances Feature aber ein sehr nützliches.Wie will man einen Loop mit dynamischem Ende denn bitte ausrollen?

[Demirug]

Wie will man einen Loop mit dynamischem Ende denn bitte ausrollen?

Es gibt ím SM3 ja keine echten Loops mit dynamischem Ende. Bei Schleifen braucht man ja immer eine Integer Konstante die angibt wie oft sie durchlaufen werden soll. Das ghört dann in den Bereich das statischen Branchings. Man kann einen dynamischen Break einbauen aber dieser lässt sich auch wieder ohne dynamische Branchs nachbilden.

[Demirug]

Die Spiele die mit G70/R520 entwickelt werden machen mir jetzt schon Angst; klingt mir nach einem ausgezeichneten Wirrwarr fuer Entwickler. Erstmal eine Checkliste was auf dem einem und dem anderen nicht geht und dann was auf einem schnell und auf dem anderen langsam ist und dann erst anfangen sich den Kopf zu zerbrechen....tstststs

Das ist nichts neues. Auf dem PC ist man das gewohnt. Zu Zeiten von DX6/7 war das alles noch viel schlimmer.

[Coda]

Es gibt ím SM3 ja keine echten Loops mit dynamischem Ende. Bei Schleifen braucht man ja immer eine Integer Konstante die angibt wie oft sie durchlaufen werden soll. Das ghört dann in den Bereich das statischen Branchings. Man kann einen dynamischen Break einbauen aber dieser lässt sich auch wieder ohne dynamische Branchs nachbilden.Argh. Immer bekommst du mich dran. Wieder was übersehen...

Das ist nichts neues. Auf dem PC ist man das gewohnt. Zu Zeiten von DX6/7 war das alles noch viel schlimmer.Vor allem werden sich die Vor- und Nachteile bei einer breiten Shadermenge wohl ausgleichen. Also bei so Klickibunti-WYSIWYG-Designer-Shadern von der UE3 z.B.

[Die gelbe Eule]

Laut inquirer wird es mit dem R580 wohl noch etwa dauern, da:

ATI also implied that if it wanted to make extreme fast platinum edition clock that it would be able to push the chips even higher than 625MHz/1500MHz.

[Coda]

Das ist beim momentanen Verbrauch der X1800XT aber mehr als unwahrscheinlich.

[Ailuros]

Laut inquirer wird es mit dem R580 wohl noch etwa dauern, da:

Dazu braucht man den INQ eigentlich nicht. Etwas hoehere Taktraten sollte man so oder so erwarten fuer R580 und das nicht nur in letzter Zeit.

[Ailuros]

Das ist beim momentanen Verbrauch der X1800XT aber mehr als unwahrscheinlich.

Sagten viele auch fuer 6 quads auf G70 im Vergleich zu NV40.

[Die gelbe Eule]

Dazu braucht man den INQ eigentlich nicht. Etwas hoehere Taktraten sollte man so oder so erwarten fuer R580 und das nicht nur in letzter Zeit.

Hast mal gesehen was noch alles an R520 geplant ist? Es wird wieder auf 8-10 Versionen hinauslaufen ...

Ich korrigiere, wir haben ja jetzt schon 4.

[Coda]

Sagten viele auch fuer 6 quads auf G70 im Vergleich zu NV40.Ich meinte damit das R520 so wie er jetzt ist wohl nicht in höher getakteten Versionen erscheinen wird. R580 ist was anderes.

Von der Heizleistung ist die XT ja schon eine Preview Edition ;)

[deekey777]

Hast mal gesehen was noch alles an R520 geplant ist? Es wird wieder auf 8-10 Versionen hinauslaufen ...

Ich korrigiere, wir haben ja jetzt schon 4.

Zumindest die X1800Pro wurde verworfen zu sein, besser gesagt, die X1800XL ist die vermeintliche X1800Pro. :biggrin:

[Ailuros]

Hast mal gesehen was noch alles an R520 geplant ist? Es wird wieder auf 5-6 Versionen hinauslaufen ...

Nur eine einfache Frage im B3D Forum warum nirgends 256MB Versionen vor dem Launch erwaehnt wurde, und ich wurde fast von der ATI-Fraktion gelyncht dass man 512 unbedingt braucht, dass sie nicht 20 SKUs haben koennen und noch weiterer sinnloser Bloedsinn.

[Coda]

SKUs?

[deekey777]

SKUs?
Wiki spricht: (http://de.wikipedia.org/wiki/Stock_keeping_unit)
Eine Stock Keeping Unit (SKU) ist eine Identifikationsnummer in der Lagerverwaltung.

Jedes Produkt im Lager wird vom Händler mit einer SKU versehen (im Gegensatz zu einer EAN, welche der Hersteller vergibt). Diese SKU wird dann benutzt, um ein Produkt aus dem Lager zu bestellen, den Standort zu bestimmen und den Bestand zu verwalten. Jedes Produkt und jede Variante eines Produkts hat eine eigene SKU, etwa für verschiedene Farben oder Modelle.

Wenn diese SKU gemeint ist, dann verstehe ich den Zusammenhang mit den Versionen/Namen nicht.

[Die gelbe Eule]

Nur eine einfache Frage im B3D Forum warum nirgends 256MB Versionen vor dem Launch erwaehnt wurde, und ich wurde fast von der ATI-Fraktion gelyncht dass man 512 unbedingt braucht, dass sie nicht 20 SKUs haben koennen und noch weiterer sinnloser Bloedsinn.

Tja so sind se ;D ...

Also R520 SE, R520 Pro, ATI R520 XT, R520 XT PE, ATI R520GL Pro, R520GL XT + 2 CF Karten mindestens

Das sind schonmal 8.

Ja die Karten kommen, weil es gibt nunmal Programme die Vorabinfos bekommen, um sie richtig zu erkennen.

[Frank1974]

Oh man

Der R520 steht noch nicht mal in den Regalen der Händler und hier wird schon über den R580 Spekuliert,den Infos zu Folge ist dieser ja auch schon sehr weit in der Entwicklung,aber nur wegen der Verspätung des R520 :rolleyes:
Aber Egal,ich würde sagen:

20-30% schneller als R520
weniger Stromverbrauch zum R520(hoffe ich)...

Aber falls er wirklich Anfang 2006 kommen sollte,würde ich das als ganz schöne Frechheit,gegenüber den Leuten die eine 1800XT kaufen sehen,also ich würde mir im November keine 1800XT kaufen,um dann Anfang nächsten Jahres zu sehen wie ein neues Highendprodukt rauskommt und die 1800XT sofort einen herben Wertverlust hat und dann ins Mittelfeld abrutscht.

Ich will damit ganz bestimmt nicht sagen das Ati Mist gebaut hat,Fehler passieren nunmal,wenn man am Limit Arbeitet, in so einem harten Zweikampf mit NV,ich meine nur das sie dem R520 ein wenig mehr Zeit am Markt lassen sollten(er ist meiner Meinung ja schliesslich schnell genug),bevor sie den Nachfolger rausbringen.

MFG
Frank

[Ailuros]

Aber falls er wirklich Anfang 2006 kommen sollte,würde ich das als ganz schöne Frechheit,gegenüber den Leuten die eine 1800XT kaufen sehen,also ich würde mir im November keine 1800XT kaufen,um dann Anfang nächsten Jahres zu sehen wie ein neues Highendprodukt rauskommt und die 1800XT sofort einen herben Wertverlust hat und dann ins Mittelfeld abrutscht.

Soooo viele werden es sowieso nicht sein. Uebrigens Anfang 2006 koennte auch Fruehling sein, kommt ganz drauf an wie man es genau meint. Der R520 wird aber trotz allem fuer einige Zeit nicht vom R580 abgeloest werden; eher ein Zusatz zum ultra high end. Es wuerde mich nicht wundern wenn es dann zu der Zeit eine neue Revision von R5x0 geben wuerde, wo die Verfuegbarkeit der X1800XTs um einiges besser sein wird.

[StefanV]

@Ail

Ists bekannt, ob man diverse Teile der GPUs deaktivieren kann?
So beim R580 z.B. ein paar ALUs ;)

[reunion]

NVIDIA wird in Sachen ALU Leistung sicher nicht im Rueckstand stehen mit dem naechsten Schub. Bleiben die heutigen ALUs gleich rechne ich mit knapp unter 300GFLOPs.

Auf dem Papier, ja.
Doch auf dem Papier müsste ein G70 einen R520 versägen, wenn es um ALU-Leistung geht. In der Praxis ist es höchstens ein leichter Vorsprung für G70. nV sollte lieber an der Effizienz, statt an den GFLOPs arbeiten IMHO.

[Winter[Raven]]

Auf dem Papier, ja.
Doch auf dem Papier müsste ein G70 einen R520 versägen, wenn es um ALU-Leistung geht. In der Praxis ist es höchstens ein leichter Vorsprung für G70. nV sollte lieber an der Effizienz, statt an den GFLOPs arbeiten IMHO.

Heutige Shader != das was geben wird, und da du sichelrich auf den Shadermark anspielst, seih es gesagt das dieser bei bei beiden totoptimiert ist!

[Demirug]

Auf dem Papier, ja.
Doch auf dem Papier müsste ein G70 einen R520 versägen, wenn es um ALU-Leistung geht. In der Praxis ist es höchstens ein leichter Vorsprung für G70. nV sollte lieber an der Effizienz, statt an den GFLOPs arbeiten IMHO.

Wenn es um die reine ALU Leistung geht tut er das auch in der Praxis.

Das primäre Problem bei nVidia ist das mischen von Texture und Rechenoperationen. Von mir immer als das "Rampage Dilema" bezeichnet.

[reunion]

Das primäre Problem bei nVidia ist das mischen von Texture und Rechenoperationen. Von mir immer als das "Rampage Dilema" bezeichnet.

Kannst du darauf bitte mal genauer eingehen?
Warum hat nV Probleme bei mischen von Texture- und Rechenoperationen, und was hat das mit Rampage zu tun?
Auch die Anzahl der Register scheint im Vergleich zu R520 arg unterdimensioniert, könnte es daran nicht auch liegen?

[Avalox]

Oh man

Der R520 steht noch nicht mal in den Regalen der Händler und hier wird schon über den R580 Spekuliert,den Infos zu Folge ist dieser ja auch schon sehr weit in der Entwicklung,aber nur wegen der Verspätung des R520 :rolleyes:
Aber Egal,ich würde sagen:

20-30% schneller als R520
weniger Stromverbrauch zum R520(hoffe ich)...



So, wie ich ATI verstanden habe, hatte man ganz schönen Bammel vor dem breiten Einstieg in den 90nm Prozess. Es ist ja anscheinend auch zu technischen Schwierigkeiten gekommen, die nun allerdings behoben scheinen. Ich könnte mir nun gut vorstellen, dass man sich schnell an "grössere" Projekte wagt. Zumal auch das XBox360 Gedöns sich dem Ende zuneigt.

HDTV wird ein Slogan werden, welcher eine Menge antreiben wird.

[Demirug]

Warum hat nV Probleme bei mischen von Texture- und Rechenoperationen, und was hat das mit Rampage zu tun?

Weil sie eine lange Pipe für alles haben. Hat Vorteile aber hat auch den Nachteil das die TMUs die Pipeline blockieren können. Eine blockierte Pipe kann aber nicht rechnen.

Rampage weil dieser Chip den ersten Pixelprozessor hatte der nach diesem Model aufgebaut war.

Auch die Anzahl der Register scheint im Vergleich zu R520 arg unterdimensioniert, könnte es daran nicht auch liegen?

Eigentlich nicht. Laut den Aussagen von ATI haben sie sogar nur 2 FP32 Register pro Pixel und Thread. Wenn sie mehr brauchen müssen sie die Threadanzahl reduzieren. Ohne aber zu wissen wie lang die ALU und TMU PIpeline (Physikalische Stufe) wirklich sind kann man schlecht sagen ab wann nicht mehr genügend Threads zur Auslastung der Pipes vorhanden sind. Aus diesem Grund habe ich ja auch gesagt das die Anzahl der verfügbaren Threads eine völlig nutzlosse Zahl ist solange man nicht noch ein paar mehr hat.

[3d]

wird 3dcenter den R520 noch testen?

ist der große leistungsabfall in "age of ampires 3" oder "riddick" architekturbedingt oder nur ein treiberproblem?
teilweise ist die XL ja langsamer als x850xt. :confused:

[robbitop]

wird 3dcenter den R520 noch testen?

Natürlich. Leo ist bereits dabei, eine Karte zu organisieren.

[Die gelbe Eule]

Wird der Test dann etwas anders aussehen, da man ja jetzt Erkenntnisse hat, die diesen beeinflussen könnten?

[deekey777]

Wird der Test dann etwas anders aussehen, da man ja jetzt Erkenntnisse hat, die diesen beeinflussen könnten?

Da mußt du Leo fragen, doch man kann schon davon ausgehen, daß er es nicht schafft, jedem alles rechtzumachen. Auch wird er alles neubenchen müssen, da die vorherigen Tests mit Quality gemacht wurden.

[Die gelbe Eule]

Ich meine ja nur, man weiß was einen erwartet und kann so besser auf Dinge eingehen, die vielleicht ATI nachher wehtuen werden. Ich verweise nur auf den Artikel, wegen der Nichtbeachtung beim Paperlaunch.

[MikBach]

Ich meine ja nur, man weiß was einen erwartet und kann so besser auf Dinge eingehen, die vielleicht ATI nachher wehtuen werden.
Falls es dich freuen würde, das es ATI wehtun würde, wundere ich mich nicht mehr, dass du bei einigen auf Ignore stehst.
Ein wenig mehr Objektivität würde dir nicht schlecht tun. :)

[up¦²]

Mich würde z.B. Age of Empire III interessieren, bitte:
http://www.microsoft.com/games/pc/age3.aspx#screenshots

[Ailuros]

Auf dem Papier, ja.
Doch auf dem Papier müsste ein G70 einen R520 versägen, wenn es um ALU-Leistung geht. In der Praxis ist es höchstens ein leichter Vorsprung für G70. nV sollte lieber an der Effizienz, statt an den GFLOPs arbeiten IMHO.

Branching Leistung ist genauso auf Papier? Heisst dass das sie total nutzlos ist?

Eben weil ATI solche "Papierfranzen" ignoriert verdreifachen sie die ALUs in R580 und NVIDIA wird wohl so schnell wie moeglich in die Richtung der Entkoppelung von arithmetic und texture OPs arbeiten. Einfache Logik; man arbeitet zuerst an den Schwaechen eines chips fuer dessen Nachfolger.

[3d]

age of ampires würde mich auch sehr interessieren. und riddick.

könnt ihr vielleicht auf die beiden spiele etwas näher eingehen?
warum bricht der R520 so massiv ein bei diesen spielen?
treibersache oder fordern die spiele bestimmte sachen von der GPU, die der R520 nicht so gut kann?
shaderleistung?
ist doch das einzige, was dem R520 fehlt oder?

[MikBach]

age of ampires würde mich auch sehr interessieren. und riddick.

könnt ihr vielleicht auf die beiden spiele etwas näher eingehen?
warum bricht der R520 so massiv ein bei diesen spielen?
treibersache oder fordern die spiele bestimmte sachen von der GPU, die der R520 nicht so gut kann?
shaderleistung?
ist doch das einzige, was dem R520 fehlt oder?
Shaderleistung?
Wenn ich mir die Egebnisse von FEAR ansehe, dann wird es sicherlich nicht die Shaderleistung sein, sondern ATI´s Problem mit OGL.
Was bei Age of Empires los ist, würde ich auch gerne wissen, wobei ich auf ein Treiberprob tippe.

[Coda]

Wenn ich mir die Egebnisse von FEAR anseheDie allesamt durch die 256MiB der GTX limitiert sind...

[MikBach]

Die allesamt durch die 256MiB der GTX limitiert sind...
Auch in 1024?

[Coda]

Ich finde nur Benchmarks in 1600/4xAA

Zudem sieht man an der X1800XL schön, dass es am Speicher liegt. Die ist nämlich langsamer als die 7800GT. Sehr seltsam, nicht?

Ohne AA ist die GTX nämlich schonmal schneller bei X-bit labs, weil ihr der Speicher nicht ausgeht.

[MikBach]

Ich finde nur Benchmarks in 1600/4xAA

http://www.hexus.net/content/item.php?item=3603&page=9

[Coda]

Da ist sie ja selbst ohne AA/AF um Welten langsamer. Ich rieche da andere Probleme.
Dann müsste die XL ja schon eine GTX vernichten. Tut sie aber nicht.

http://www.xbitlabs.com/images/video/radeon-x1800/fear_candy.gif

Das Performanceverhältnis (X1800XL->7800GT->7800GTX->X1800XT) zeigt eindeutig, dass es eine Speicherlimitierung ist.

Man merkt das ja schon selber wenn man auf einer 256MiB Karte in Fear in 1600 4xAA aktiviert. Der Einbruch ist verdammt groß.

[MikBach]

Da ist sie ja selbst ohne AA/AF um Welten langsamer. Ich rieche da andere Probleme.

Dann teile sie uns bitte mit...
Treiberprobs? Shaderreplacement nötig?

[Ailuros]

Dann teile sie uns bitte mit...
Treiberprobs? Shaderreplacement nötig?

Ich bin selber gerade am fragen was mit FEAR und CoD2 genau los ist dass sie solchen Unmengen an Speicher-resources konsumieren, aber da muss sich auch ein Profi diese beiden naeher ansehen.

Es sind pre-release demos und obwohl ich hoffe dass die finalen Spiele sich doch etwas normaler verhalten werden, stirbt die Hoffnung stets als letzte. Ich will mal sobald ich Zeit finde das Verhalten der beiden mit Demi's vidmemorytester versuchen genauer anzusehen, aber weiter als das kann ich als Laie nicht gehen.

Auf jeden Fall ich hatte die gleichen Gedanken wie Coda oben was die Fear-Leistung betrifft bei B3D, egal ob im Graph oben nur 1024*768 benutzt wurde. Die X1800XL hat dort nur 256MB, genauso wie 7800GTX und GT, wobei nur die X1800XT 512MB hat.

Es wundert mich sowieso - wie einige andere auch - ob in FEAR und/oder CoD2 irgendwelche Textur-Kompression am Werk ist oder nicht; es stimmt hier tatsaechlich was nicht.

[Die gelbe Eule]

Falls es dich freuen würde, das es ATI wehtun würde, wundere ich mich nicht mehr, dass du bei einigen auf Ignore stehst.
Ein wenig mehr Objektivität würde dir nicht schlecht tun. :)

Mir ist es doch egal, ob es denen wehtut oder nicht. Ein neuer Artikel wird auch nicht 3DCenter die Weltherrschaft geben.
ATI wollte nicht das 3DCenter ein R520 Sample bekommt, weil sie Angst hatten, es wird nichts positives. Nun kann man viel besser auf Dinge eingehen, die wirklich auf den Fingern brennen.

[HajottV]

Ich meine ja nur, man weiß was einen erwartet und kann so besser auf Dinge eingehen, die vielleicht ATI nachher wehtuen werden. Ich verweise nur auf den Artikel, wegen der Nichtbeachtung beim Paperlaunch.

:nono: :down: :confused: :ucrazy: :ucrazy2: :ulol4: :uhammer: :uhammer2: :uclap: :uban:

Gruß Jörg

Jaja, ich weiß, Gebot 12 und so... ich schäme mich auch.

[MechWOLLIer]

Was bei Age of Empires los ist, würde ich auch gerne wissen, wobei ich auf ein Treiberprob tippe.
Nope, ein Treiberproblem ist es wohl nicht.
Deaktiviere mal komplett die Schatten und staune;)

[Quasar]

Daß du aber auch immer alles verraten musst... *gg*

Es könnte daher aber auch ein Shaderproblem sein.

[MikBach]

Nope, ein Treiberproblem ist es wohl nicht.
Deaktiviere mal komplett die Schatten und staune;)
Kann trotzdem ein Treiberproblem sein.

[reunion]

Eigentlich nicht. Laut den Aussagen von ATI haben sie sogar nur 2 FP32 Register pro Pixel und Thread. Wenn sie mehr brauchen müssen sie die Threadanzahl reduzieren. Ohne aber zu wissen wie lang die ALU und TMU PIpeline (Physikalische Stufe) wirklich sind kann man schlecht sagen ab wann nicht mehr genügend Threads zur Auslastung der Pipes vorhanden sind. Aus diesem Grund habe ich ja auch gesagt das die Anzahl der verfügbaren Threads eine völlig nutzlosse Zahl ist solange man nicht noch ein paar mehr hat.

Dann hab ich die ATi-Folien falsch verstanden.
Sry. ;(

[reunion]

Branching Leistung ist genauso auf Papier? Heisst dass das sie total nutzlos ist?


Nein, ist sie nicht. Die Tests von xbitlabs zeigen deutlich, dass R520 da wesentlich performanter ist. Wenn ich mir die Shaderteste ansehe, ist G70 trotz eine theoretischen Überlegenheit in der Praksis nicht wirklich schneller.


Eben weil ATI solche "Papierfranzen" ignoriert verdreifachen sie die ALUs in R580 und NVIDIA wird wohl so schnell wie moeglich in die Richtung der Entkoppelung von arithmetic und texture OPs arbeiten. Einfache Logik; man arbeitet zuerst an den Schwaechen eines chips fuer dessen Nachfolger.

Genau darauf wollte ich hinaus; nV sollte erstmal das Problem mit den texture OPs lösen, bevor man die GFLOPs weiter erhöht.

[Demirug]

Dann hab ich die ATi-Folien falsch verstanden.
Sry. ;(

Die Folien sind durchaus so gechrieben das man sie falsch verstehen kann. Marketing Unterlagen sollen das Produkt ja gut aussehen lassen.

[Demirug]

Genau darauf wollte ich hinaus; nV sollte erstmal das Problem mit den texture OPs lösen, bevor man die GFLOPs weiter erhöht.

Beides bringt sie ans Ziel. Kosten/Nutzen Relation. Wenn es weniger Transitoren braucht zusätzliche ALUs einzubauen als die ALUs und TMUs zu entflechten baut man ALUs ein.

[deekey777]

...
ATI wollte nicht das 3DCenter ein R520 Sample bekommt, weil sie Angst hatten, es wird nichts positives. Nun kann man viel besser auf Dinge eingehen, die wirklich auf den Fingern brennen.

ATi fing erst an, X1000er an Tester zu verschicken, auch 3D Center wird seine Grafikkarten bekommen.

[Ferengie]

Meint ihr nicht, wir hätten November 2005 den R580 gesehen, wenn der R520 im Frühjahr gekommen wär?

[deekey777]

Meint ihr nicht, wir hätten November 2005 den R580 gesehen, wenn der R520 im Frühjahr gekommen wär?

Nein, der R580 liegt im Plan. Woher dieser Gedankengang?

[Ferengie]

...im 6 Monat Rhythmus bei Graka Chips.

[Morpog]

...im 6 Monat Rhythmus bei Graka Chips.

den ATI und Nvidia schon lange nicht mehr einhalten...........

[seahawk]

Meint ihr nicht, wir hätten November 2005 den R580 gesehen, wenn der R520 im Frühjahr gekommen wär?

Möglich. Weniger Probleme beim R520 hätten sich evtl. auch auf den R580 ausgewirkt. Ich denke allerdings nicht, dass wir ihn noch im Novemebr 2005 gesehen hätten.

[deekey777]

Möglich. Weniger Probleme beim R520 hätten sich evtl. auch auf den R580 ausgewirkt. Ich denke allerdings nicht, dass wir ihn noch im Novemebr 2005 gesehen hätten.

Die Probleme bei der Fertigstellung des R520 und deren Lösungen werden in Fertigstellung des R580 miteinfliessen, was zufolge hätte, daß keine Verzögerungen zu erwarten sein sollten.

[Ailuros]

Nein, ist sie nicht. Die Tests von xbitlabs zeigen deutlich, dass R520 da wesentlich performanter ist. Wenn ich mir die Shaderteste ansehe, ist G70 trotz eine theoretischen Überlegenheit in der Praksis nicht wirklich schneller.

Dann konzentrierst Du Dich aber schoen NUR auf die branching Shader-Tests. Sie Dir mal alle genauen Shader-tests an und man kann in diesen sowohl den dynamischen branching als auch den ALU Leistung Vorteil fuer jede der beiden genau sehen. Beide Vorteile sind momentan immer noch theoretisch sind aber durch und durch nachvollziebar zumindest in synthetischen Tests.

Es ist ja nett dass Du nur dass sehen willst, was gerade am besten passt aber G70/R520 kommen eben auf Gleichstand weil sie beide Vor- und Nachteile haben.

G70 ALU Leistung zeigte sich schon in UE3.

Genau darauf wollte ich hinaus; nV sollte erstmal das Problem mit den texture OPs lösen, bevor man die GFLOPs weiter erhöht.

Genauso wie ATI mehr ALUs auf R580 nachladen wird. Entkoppelt oder nicht entkoppelt haben beide sowohl Vor- als auch Nachteile. Dass der NV40 texturing computer nicht nur Vorteile hat, hat Killgariff sogar in aller Oeffentlichkeit zugestanden.

[reunion]

Dann konzentrierst Du Dich aber schoen NUR auf die branching Shader-Tests. Sie Dir mal alle genauen Shader-tests an und man kann in diesen sowohl den dynamischen branching als auch den ALU Leistung Vorteil fuer jede der beiden genau sehen. Beide Vorteile sind momentan immer noch theoretisch sind aber durch und durch nachvollziebar zumindest in synthetischen Tests.



Ich konzentriere mich keineswegs nur auf die Branching-Tests.
Und ja, G70 ist geringfügig schneller, nur ist dieser Vorteil bei weitem nicht so hoch, wie man aufgrund der theoretischen Leistungsfähigkeit vermuten würde.

Mehr versuche ich die letzten drei Posts eigentlich nicht auszudrücken. :)

[Demirug]

Ich konzentriere mich keineswegs nur auf die Branching-Tests.
Und ja, G70 ist geringfügig schneller, nur ist dieser Vorteil bei weitem nicht so hoch, wie man aufgrund der theoretischen Leistungsfähigkeit vermuten würde.

Mehr versuche ich die letzten drei Posts eigentlich nicht auszudrücken. :)

Die Theoretischen Zahlen lassen sich durchaus praktisch nachweisen. Mit dem GPUBench sieht man die unterschiedliche Rechenleistung sehr gut.

[Ailuros]

Ich konzentriere mich keineswegs nur auf die Branching-Tests.
Und ja, G70 ist geringfügig schneller, nur ist dieser Vorteil bei weitem nicht so hoch, wie man aufgrund der theoretischen Leistungsfähigkeit vermuten würde.

Mehr versuche ich die letzten drei Posts eigentlich nicht auszudrücken. :)



http://www.xbitlabs.com/images/video/radeon-x1000/x1800/Xbitmark_x18.gif

http://www.xbitlabs.com/articles/video/display/radeon-x1000_21.html

Der Reihe nach so wie die Resultate im Graph erscheinen:

R520: -40%
R520: -49%
R520: -25%
R520: -18%
R520: -29%
R520: -29%
G70: -36%
R520: -4%
R520: -30%
G70: -33%
R520: -11%
R520: -6%
R520: -37%
G70: -5%
G70: -65%
G70: -71%
G70: -107%

Wenn Du Lust hast kannst Du Dir den Durschnitt selber ausrechnen.

Wieso man den Unterschied noch nicht sehen kann ausser in synthetischen Appliationen?

1. Spiele benutzen noch keine so komplizierte Arithmetik.
2. Es gibt auf der einen Seite einen sehr grosszuegigen PS throughput und auf der anderen Seite einen sehr grosszuegigen VS Vorteil (wie auch weitere synthetische Tests im xbit Artikel zeigen).
3. Es gibt ausser dynamischem auch constant branching, wobei das erst nur unter sehr gewissen Bedingungen eine absolute Notwendigkeit sein wird. Momentan genauso selten benutzt wie (1) wenn ueberhaupt.
4. Man muss ja leider ein noch nicht verfuegbares (und mit fraglicher zukuenftiger Verfuegbarkeit) gegen ein seit Monaten breit verfuegbares Produkt vergleichen.

[reunion]

http://www.xbitlabs.com/articles/video/display/radeon-x1000_21.html

Der Reihe nach so wie die Resultate im Graph erscheinen:

R520: -40%
R520: -49%
R520: -25%
R520: -18%
R520: -29%
R520: -29%
G70: -36%
R520: -4%
R520: -30%
G70: -33%
R520: -11%
R520: -6%
R520: -37%
G70: -5%
G70: -65%
G70: -71%
G70: -107%

Wenn Du Lust hast kannst Du Dir den Durschnitt selber ausrechnen.


Falls es dich intressiert:
Ohne den Branchingtests hat G70 im Schnitt einen Vorteil von 14.6%.
Mit Branchingtests liegt R520 um 2.3% vorne.

Ziemlich geringer Vorteil für G70, wenn man bedenkt, dass G70 doppelt so viele ALUs pro Pipeline hat, findest du nicht?
Genau darauf will ich hinaus: Der Vorteil ist bei weitem nicht so hoch, wie man aufgrund der theoretischen Leistungsfähigkeit vermuten würde.



Wieso man den Unterschied noch nicht sehen kann ausser in synthetischen Appliationen?

1. Spiele benutzen noch keine so komplizierte Arithmetik.
2. Es gibt auf der einen Seite einen sehr grosszuegigen PS throughput und auf der anderen Seite einen sehr grosszuegigen VS Vorteil (wie auch weitere synthetische Tests im xbit Artikel zeigen).
3. Es gibt ausser dynamischem auch constant branching, wobei das erst nur unter sehr gewissen Bedingungen eine absolute Notwendigkeit sein wird. Momentan genauso selten benutzt wie (1) wenn ueberhaupt.
4. Man muss ja leider ein noch nicht verfuegbares (und mit fraglicher zukuenftiger Verfuegbarkeit) gegen ein seit Monaten breit verfuegbares Produkt vergleichen.

Dessen bin ich mir durchaus bewusst.

//Edit:
Demirug, gibt es aktuell eine Möglichkeit, den "Video Memory Watcher" oder den "DirectX Tweaker" herunterzuladen?
www.nonatainment.de ist ja zurzeit nicht erreichbar.

[deekey777]

....
3. Es gibt ausser dynamischem auch constant branching, wobei das erst nur unter sehr gewissen Bedingungen eine absolute Notwendigkeit sein wird. Momentan genauso selten benutzt wie (1) wenn ueberhaupt.
....

Static oder? Als Gegenteil zu dynamisch. ;)

[Ailuros]

Falls es dich intressiert:
Ohne den Branchingtests hat G70 im Schnitt einen Vorteil von 14.6%.
Mit Branchingtests liegt R520 um 2.3% vorne.

Kreative Mathe nennt sich das, ohne die Branching-tests gewinnt der G70 in 11 Faellen gegen 2. Ich will gar nicht fragen wie Du gerechnet hast :rolleyes:

Ziemlich geringer Vorteil für G70, wenn man bedenkt, dass G70 doppelt so viele ALUs pro Pipeline hat, findest du nicht?

16:24 und Du kannst tatsaechlich nicht zaehlen. Um noch genauer zu sein 16@625MHz vs. 24@430MHz. Wo der Vorteil liegt selber nachlesen, es gibt genug Artikel darueber.

Genau darauf will ich hinaus: Der Vorteil ist bei weitem nicht so hoch, wie man aufgrund der theoretischen Leistungsfähigkeit vermuten würde.

*sigh* nochmal Demis Antwort weiter oben. Der Test zeigt sowieso nur einen Bruchteil der Geschichte, es gibt sehr wohl Tests die den theoretischen Vorteil nachweisen. Es ist aber nur mal wieder interessant wie stark eine rote Brille die Interpretation von Resultaten beinflussen kann.

[Relic]

Kreative Mathe nennt sich das, ohne die Branching-tests gewinnt der G70 in 11 Faellen gegen 2. Ich will gar nicht fragen wie Du gerechnet hast :rolleyes:


Ich denk mal er hat es nicht so oberflächlich (gewonnen oder verloren) wie du betrachtet, sondern die Geschwindigkeit in den einzelnen Tests berücksichtigt...

[seahawk]

Ich denk mal er hat es nicht so oberflächlich (gewonnen oder verloren) wie du betrachtet, sondern die Geschwindigkeit in den einzelnen Tests berücksichtigt...

Er hat den die porzentuale Differenzen addiert und dann den Mittelwert bestimmt ? Was natürlich nicht ganz korrekt ist.

[Ailuros]

Ich denk mal er hat es nicht so oberflächlich (gewonnen oder verloren) wie du betrachtet, sondern die Geschwindigkeit in den einzelnen Tests berücksichtigt...

Ihr beide wuerdet tolle Statistiker ausmachen. Stell Dir mal vor die obrigen Prozentuale waeren Ergebnisse von politischen Wahlen aus diversen Bezirken. Faellt der Groschen jetzt vielleicht? Denn wenn Du es wirklich ueberdenkst, bin ich mit Sicherheit nicht derjenige der es oberflaechlich betrachtet hat.

[reunion]

Kreative Mathe nennt sich das, ohne die Branching-tests gewinnt der G70 in 11 Faellen gegen 2. Ich will gar nicht fragen wie Du gerechnet hast :rolleyes:


Ich habe die prozentualen Differenzen addiert, und dann durch die Anzahl der Ergebnisse dividiert, ergo den Mittelwert bestimmt.


16:24 und Du kannst tatsaechlich nicht zaehlen. Um noch genauer zu sein 16@625MHz vs. 24@430MHz. Wo der Vorteil liegt selber nachlesen, es gibt genug Artikel darueber.


Nein, du kannst nicht lesen.
Ich habe geschrieben, dass G70 doppelt so viele ALUs pro Pipeline hat, das hat weder etwas mit dem Takt, noch mit der absoluten Pipelineanzahl zu tun. Der Taktvorteil des R520 gleicht sich ja durch die höhere Pipelineanzahl des ungefähr G70 aus, und umgekehrt. Nur in punkto ALU-Leitstung hat G70 auf dem Papier einen klaren Vorteil, der in der Praksis deutlich geringer ausfällt.


*sigh* nochmal Demis Antwort weiter oben. Der Test zeigt sowieso nur einen Bruchteil der Geschichte, es gibt sehr wohl Tests die den theoretischen Vorteil nachweisen. Es ist aber nur mal wieder interessant wie stark eine rote Brille die Interpretation von Resultaten beinflussen kann.

Ich finde es vielmehr bedauerlich, dass du hier aufgrund falscher Interpretationen meiner Aussagen irgendetwas ableiten willst.

[seahawk]

Ich habe die prozentualen Differenzen addiert, und dann durch die Anzahl der Ergebnisse dividiert, ergo den Mittelwert bestimmt.


Und das ist eben falsch. Du mußt den Mittelwert der Ergebnisse bestimmen und dann den Prozenutalen Unterschied. Vorher von mir aus noch die Ergenisse in Porzent umgewandelt.



1. Shader R520 : 41,3% G70 : 58,7%
2. Shader R520 : 40,1% G70 : 59,9%
3. Shader R520 : 44,4% G70 : 55,6%
4. Shader R520 : 45,9% G70 : 54,1%
5. Shader R520 : 43,6% G70 : 56,4%
6. Sahder R520 : 43,7% G70 : 56,3%
7. Shader R520 : 57,6% G70 : 42,4%
8. Sahder R520 : 49,0% G70 : 51,0%
9. Shader R520 : 43,5% G70 : 56,5%
10. Shader R520 : 57,1% G70 : 42,9%
11. Shader R520 : 47,5% G70 : 52,5%
12. Shader R520 : 48,5% G70 : 51,5%
13. Shader R520 : 42,2% G70 : 57,8%
14. Shader R520 : 51,2% G70 : 48,8%
15. Shader R520 : 63,3% G70 : 36,7%
15. Shader R520 : 63,1% G70 : 36,9%
16. Shader R520 : 67,4% G70 : 32,6%

Mittelwert R520 : 53,3% G : 70 46,7%

-> damit is bewiesen, dass der R520 14% schneller als der G70 ist ;D

[aths]

Genau darauf wollte ich hinaus; nV sollte erstmal das Problem mit den texture OPs lösen, bevor man die GFLOPs weiter erhöht.Ist nicht unbedingt nötig. Mehr verfügbare Temps würden auch zu einer Steigerung des Quad-Throughput führen, und so ein Weg sollte deutlich einfacher zu realisieren sein, als mal kurz eine komplett neue Architektur zu entwerfen.

Das "Problem" bei den Texturen das du siehst, ist einfach eine Folge der gewählten Methode, Latenzen zu verstecken. Mit zusätzlichen verfügbaren Temps kann man einerseits die ALUs besser auslasten, und andererseits machmal die Abstände zwischen den Tex-Ops vergrößern, was zu einer Reduzierung des Pipelinestall-Risikos führt.

Die verbesserte Shader-Unit im G70 (gegenüber dem NV40) steuert ihre Rechenkraft meist nur indirekt bei: Das Sheduling wird einfacher, wenn das MAD in beiden Units verfügbar ist. Man kann darauf verzichten, das MAD in den nächsten Slot zu schieben und es gleich ausführen lassen. Hier bringt erhöhte GFLOP-Leistung also was, ohne dass das Textursampling entkoppelt, oder die Zahl der verfügbaren Temps erhöht wurde.

[Demirug]

Ist nicht unbedingt nötig. Mehr verfügbare Temps würden auch zu einer Steigerung des Quad-Throughput führen, und so ein Weg sollte deutlich einfacher zu realisieren sein.

Das "Problem" bei den Texturen das du siehst, ist einfach eine Folge der gewählten Methode, Latenzen zu verstecken. Mit zusätzlichen verfügbaren Temps kann man erstens die ALUs besser auslasten, und zweitens machmal die Abstände zwischen den Tex-Ops vergrößern, was zu einer Reduzierung des Risikos des Pipelinestalls führt.

Den Stall wirst du so nicht los. Die Pixelpipeline hat keine nebenläufige TMUs wie die Vertexpipeline.

[aths]

Den Stall wirst du so nicht los. Die Pixelpipeline hat keine nebenläufige TMUs wie die Vertexpipeline.Wenn zwischen Tex-Op und tatsächlicher Nutzung des Samples zusätzliche unabhängige ALU-Ops sind, darf die TMU mehr Takte sampeln ohne dass die Pipeline anhalten muss. Oder?

[Demirug]

Wenn zwischen Tex-Op und tatsächlicher Nutzung des Samples zusätzliche unabhängige ALU-Ops sind, darf die TMU mehr Takte sampeln ohne dass die Pipeline anhalten muss. Oder?

Eben nicht. "Rampage Dilemma"

Die TMU gibt ihere Ergebnisse (Texturesample, FP16 Nrm, FP16 Interpolation) direkt an ALUs 2 weiter. Die TMU hat keinen direkten Zugriff auf den Registerspeicher.

Im NV30/NV35 ging das noch unter bestimmten Vorraussetzungen. Seit dem NV40 haben wir aber ein vollständiges "Rampage Model" (aka Single VLIW). Deswegen wurde ja oft fälschlicherweise angenommen das die TMUs die ALUs mitbenutzten würden.

[Coda]

D.h. die TMU blockiert die komplette Pipeline bis zu 32 Takte bei 16xTriAF?

[Demirug]

D.h. die TMU blockiert die komplette Pipeline bis zu 32 Takte bei 16xTriAF?

Ja, allerdings wirst du bei 16xTriAF nur dann bis zu 32 Takte brauchen wenn du keine Mipmaps hast.

[Coda]

Dann halt 16 - das ist ja schon schlimm genug. Und das ist wirklich bei jedem Sampling so?

[aths]

Eben nicht. "Rampage Dilemma"

Die TMU gibt ihere Ergebnisse (Texturesample, FP16 Nrm, FP16 Interpolation) direkt an ALUs 2 weiter. Die TMU hat keinen direkten Zugriff auf den Registerspeicher.Die TMU könnte Ergebnisse im Texturcache zwischenspeichern, und für das Ergebnis das Register wiederverwenden, welches die Texturkoordinaten enthielt.

Wenn jedes Sampling besser als bilinear immer zum Stall führt, sehe ich nur das Wort "Fehlkonstruktion".

Im NV30/NV35 ging das noch unter bestimmten Vorraussetzungen. Seit dem NV40 haben wir aber ein vollständiges "Rampage Model" (aka Single VLIW). Deswegen wurde ja oft fälschlicherweise angenommen das die TMUs die ALUs mitbenutzten würden.Die TMU nutzt denke ich die Datenpfade aus der ersten Shader Unit.

[Quasar]

Ja, was meinst du, wie Nvidia es schaffte, mit 18 Millionen Transistoren weniger FP16-Filterung in die TMUs zu integrieren, VTF zu ermöglichen und gleichzeitig noch schlappe 2 Pixelprozessoren mehr in den Die zu integrieren?

Das dürfte auch der Grund gewesen sein, warum ATi den R400 gecancelt hat und der R420 kein SM3 abbekam.

[Coda]

Wie kommst du auf die 18Mio. Transistoren?

[Crushinator]

Wie kommst du auf die 18Mio. Transistoren?
Mathe for Runaways: 321 - 302 == 19 X-D ;)

[robbitop]

Mathe for Runaways: 321 - 302 == 19 X-D ;)
Naja da fehlt aber noch einiges. 50% mehr Pixelprozessoren und 3x ALU Anzahl.
Bei ungefähr gleicher Anzahl an Recheneinheiten müßte man einen NV40 nehmen. Ergo 222Mio vs 321Mio. Der Takt fällt halt raus.

[Demirug]

Die TMU könnte Ergebnisse im Texturcache zwischenspeichern, und für das Ergebnis das Register wiederverwenden, welches die Texturkoordinaten enthielt.

Wer erzählt den sowas? Oder ist das jetzt eine Idee von dir?

Wenn jedes Sampling besser als bilinear immer zum Stall führt, sehe ich nur das Wort "Fehlkonstruktion".

Ich hatte das in einer Anfrage an den Devsupport (im interen NV-Forum) mal etwas freundlicher formuliert. Das war dann auch einer der Fälle in denen niemand antworten wollte. ;)

Die Pipeline wurde für ein bestimmtes ALU zu TEX Operationen Verhältniss ausgelegt. Weicht man davon ab wird sie ineffektiv. Der Vorteil ist der Einfache Aufbau. Die große Batchgröße resultiert aus einer ähnlichen Designentscheidung.

Die TMU nutzt denke ich die Datenpfade aus der ersten Shader Unit.

Über diesen kommt die Texturekoordinate. Für das Samplen selbst wird sie allerdings nicht gebraucht.

[Quasar]

Mathe for Runaways: 321 - 302 == 19 X-D ;)
*argh* X-D ok, 19M.

[aths]

Wer erzählt den sowas? Oder ist das jetzt eine Idee von dir? Das mit dem Cache soll Kirk mal gesagt haben.

Ich hatte das in einer Anfrage an den Devsupport (im interen NV-Forum) mal etwas freundlicher formuliert. Das war dann auch einer der Fälle in denen niemand antworten wollte. ;)

Die Pipeline wurde für ein bestimmtes ALU zu TEX Operationen Verhältniss ausgelegt. Weicht man davon ab wird sie ineffektiv. Der Vorteil ist der Einfache Aufbau. Die große Batchgröße resultiert aus einer ähnlichen Designentscheidung.Wie ist dieses Verhältnis? Also welche Samples können noch ohne Stall erzeugt werden?

Über diesen kommt die Texturekoordinate. Für das Samplen selbst wird sie allerdings nicht gebraucht.Im nächsten Takt sollte die SU1 dann wieder frei sein. Die TMU speist ihr Sample in SU2 ein, wenn es dort gebraucht wird – in der Zwischenzeit könnten SU1 und SU2 ja was anderes berechnen. So kann man nach meiner Vorstellung auch die Stalls verhindern, sofern einem die Temps nicht ausgehen.

[Quasar]

Naja da fehlt aber noch einiges. 50% mehr Pixelprozessoren und 3x ALU Anzahl.[…]
Zumindest die Pixelprozessoren habe ich doch erwähnt. Bei den ALUs - naja, wer weiß, was da wirklich mehr kostet.

[Coda]

Mathe for Runaways: 321 - 302 == 19 X-D ;)Ach jetzt. Ich wusste nicht woher der Wert überhaupt kommt, aber jetzt ist es mir klar.

[Demirug]

Das mit dem Cache soll Kirk mal gesagt haben.

Dann hätte er defintive Blödsinn erzählt. Es gibt keinen Rückkanal von den TMUs zum Cache.

Wie ist dieses Verhältnis? Also welche Samples können noch ohne Stall erzeugt werden?

Sobald du TRI Filterst hast du Stalls. Die Basis dieses Designs ist folgenden.

Wenn ein Shader jedem VLIW die TMU nutzt ist er perfekt ausgelichen. Jedes VLIW ohne TMU Anweisung führt bei der Nutzung bessere Filter zu Ineffektivitäten.

Im nächsten Takt sollte die SU1 dann wieder frei sein. Die TMU speist ihr Sample in SU2 ein, wenn es dort gebraucht wird – in der Zwischenzeit könnten SU1 und SU2 ja was anderes berechnen. So kann man nach meiner Vorstellung auch die Stalls verhindern, sofern einem die Temps nicht ausgehen.

"In Order" Design. Die Reihenfolge der Quads darf sich nicht ändern sonst ist die Programmlogik kaputt.

[robbitop]

Zumindest die Pixelprozessoren habe ich doch erwähnt. Bei den ALUs - naja, wer weiß, was da wirklich mehr kostet.
Wären dann delta 100Mio Transistoren. Wäre mal interessant den R520 auf NV40 Niveau zu takten und einen Vergleich zu machen.

[reunion]

Wenn jedes Sampling besser als bilinear immer zum Stall führt, sehe ich nur das Wort "Fehlkonstruktion".


Genau deshalb ist es IMHO extrem ineffizient, die ALU-Leistung weiter zu erhöhen, ohne die TMUs zu entkoppeln.

[Quasar]

Wären dann delta 100Mio Transistoren. Wäre mal interessant den R520 auf NV40 Niveau zu takten und einen Vergleich zu machen.
Hm? Ich verstehe deine Gedankensprünge gerade irgendwie nicht. Ich rede von G70 vs. R520.

[aths]

Dann hätte er defintive Blödsinn erzählt. Es gibt keinen Rückkanal von den TMUs zum Cache.



Sobald du TRI Filterst hast du Stalls.Tridam erzählt mir was anderes.

Die Basis dieses Designs ist folgenden.

Wenn ein Shader jedem VLIW die TMU nutzt ist er perfekt ausgelichen. Jedes VLIW ohne TMU Anweisung führt bei der Nutzung bessere Filter zu Ineffektivitäten.

"In Order" Design. Die Reihenfolge der Quads darf sich nicht ändern sonst ist die Programmlogik kaputt.Die Reihenfolge der Quads ändert sich nicht. Aber der Scheduler (die Software im Treiber) kann ja die Instruktionen umsortieren. Folgender Fall:

- Hole Interpolation
- Sample t0 (bilinar)
- Hole Interpolation
- Sample t1 (tri-AF)
- Verrechne t0
- Hole noch eine Interpolation
- Rechne noch mehr herum
- Nutze t1

Hier könnte doch die Latenz vom AF in t1 versteckt werden, je nach dem, wie lange das Sample nun wirklich braucht. Die Frage ist, wie viel Spielraum der Scheduler hat – bei 4 Temps bei optimaler Nutzung.

[aths]

Genau deshalb ist es IMHO extrem ineffizient, die ALU-Leistung weiter zu erhöhen, ohne die TMUs zu entkoppeln.Anbetrachts der Tatsache, dass man sowieso mehr rechnen als samplen wird, kann reine ALU-Leistung auch noch was bringen.

[Quasar]

Genau deshalb ist es IMHO extrem ineffizient, die ALU-Leistung weiter zu erhöhen, ohne die TMUs zu entkoppeln.
Dazu wird Nvidia aber die komplette Architektur umbauen müssen. Da werden wir IMO eher ein US-Modell sehen.

[Demirug]

Tridam erzählt mir was anderes.

Ich habe das mehrmals nachgemessen Es ist immer wieder das selbe heraus gekommen. Die zusätzlichen Takte fürs Filtern können nicht durch die ALUs genutzt werden.

Die Reihenfolge der Quads ändert sich nicht. Aber der Sheduler (die Software im Treiber) kann ja die Instruktionen umsortieren. Folgender Fall:

- Hole Interpolation
- Sample t0 (bilinar)
- Hole Interpolation
- Sample t1 (tri-AF)
- Verrechne t0
- Hole noch eine Interpolation
- Rechne noch mehr herum
- Nutze t1

Hier könnte doch die Latenz vom AF in t1 versteckt werden, je nach dem, wie lange das Sample nun wirklich braucht. Die Frage ist, wie viel Spielraum der Sheduler hat – bei 4 Temps bei optimaler Nutzung.

Das was du hier haben willst erfordert nebenläufige TMUs. Das ist aber nur im Vertexshader so gebaut.

[Coda]

Haben nebenläufige TMUs eigentlich abseits von höherem Transistorverbrauch noch andere Nachteile?

[aths]

Ich habe das mehrmals nachgemessen Es ist immer wieder das selbe heraus gekommen. Die zusätzlichen Takte fürs Filtern können nicht durch die ALUs genutzt werden.



Das was du hier haben willst erfordert nebenläufige TMUs. Das ist aber nur im Vertexshader so gebaut.Was da groß nebenläufig sein muss ist mir noch nicht ganz klar.

Wir haben die Tex-Unit in der Pipe, die TMU (meiner Vorstellung nach in der Nähe des Speichercontrollers) und die NRM-Einheit wieder in der Pipe, aber nach der TMU (weil mans das Teil da gut gebrauchen kann.) Die TMU muss ohnehin Ergebnisse für den ganzen Batch irgendwo speichern. Solche internen Speicher braucht sie für Zwischenergebnisse wenn man besser als bilinear filtert. Da kann doch auch dann das fertige Sample rein.

[robbitop]

Hm? Ich verstehe deine Gedankensprünge gerade irgendwie nicht. Ich rede von G70 vs. R520.
Es geht mir aber um die Architektur. Somit wäre ein Vergleich bei in etwa gleicher Rechenwerkanzahl passend. Zumal das von der Pro Takt Leistung auch in etwa hinkommt (4 NV Quads vs 4x ATI Quads).

[Demirug]

Was da groß nebenläufig sein muss ist mir noch nicht ganz klar.

Wir haben die Tex-Unit in der Pipe, die TMU (meiner Vorstellung nach in der Nähe des Speichercontrollers) und die NRM-Einheit wieder in der Pipe, aber nach der TMU (weil mans das Teil da gut gebrauchen kann.) Die TMU muss ohnehin Ergebnisse für den ganzen Batch irgendwo speichern. Solche internen Speicher braucht sie für Zwischenergebnisse wenn man besser als bilinear filtert. Da kann doch auch dann das fertige Sample rein.

Die NRM Einheit sitzt neben der TMU nicht nach ihr. Was anderes würde sowieso die Pipe nur unnötig länger machen. Aber das ist hier sowieso egal.

Wir sind uns einig das die TMU innerhalb der Pipeline in Reihe zu den beiden ALUs liegt, oder?

Die TMU muss eben nicht für den ganzen Batch Ergebnisse speichern sondern nur für die Quads welche sich im Filterkern befinden. Wenn dieser korrekt gebaut ist gibt es genau eine Summezelle für einen einzigen Quad.

[robbitop]

Warum baut NV nicht einfach TMUs mit einem größerem Filterkernel ein. Das Textursampling würde dann deutlich schneller vonstatten gehen und die stalls wären deutlich kürzer. Klar stünde dies nicht im Verhältnis zur Bandbreite aber es würde helfen ohne große Entwicklingskosten und -zeiten zu fordern.

[Demirug]

Warum baut NV nicht einfach TMUs mit einem größerem Filterkernel ein. Das Textursampling würde dann deutlich schneller vonstatten gehen und die stalls wären deutlich kürzer. Klar stünde dies nicht im Verhältnis zur Bandbreite aber es würde helfen ohne große Entwicklingskosten und -zeiten zu fordern.

Du schreibst es doch schon Bandbreite. Filterkerne müssen gefüttert werden. Dann brauchen die Filterkene auch noch eine Gewichtung was auch berechnet werden muss.

Mit den ganzen Transitoren kann man auch noch eine ALU reinbauen.

[aths]

Die NRM Einheit sitzt neben der TMU nicht nach ihr. Was anderes würde sowieso die Pipe nur unnötig länger machen. Aber das ist hier sowieso egal.

Wir sind uns einig das die TMU innerhalb der Pipeline in Reihe zu den beiden ALUs liegt, oder?

Die TMU muss eben nicht für den ganzen Batch Ergebnisse speichern sondern nur für die Quads welche sich im Filterkern befinden. Wenn dieser korrekt gebaut ist gibt es genau eine Summezelle für einen einzigen Quad.Doch nur, wenn man in tatsächlich in einem Takt das bilineare Sample hat, also direkt nach der Tex-Op das fertige Bi-Sample rauspurzelt. Die Pipeline ist doch unter anderem dazu da, die Latenz beim Samplen zu verstecken.

[Demirug]

Doch nur, wenn man in tatsächlich in einem Takt das bilineare Sample hat, also direkt nach der Tex-Op das fertige Bi-Sample rauspurzelt. Die Pipeline ist doch unter anderem dazu da, die Latenz beim Samplen zu verstecken.

Nein, der Filterkern kann schon ein paar Takte brauchen. Die einzelnen BI-Samples müssen nur direkt hintereinader in den Kern eingeschoben werden.

Die Speicherlatenz muss verdeckt werden. deswegen muss zwischen dem Addressrechner und dem Filterkern ein FIFO sein.

Wie geschrieben die Abhänigkeit bekommt man nur weg wenn man ALUs und TMUs vollkommen nebenläufig macht. Das heist das die TMU einen Readport am Anfang und einen Writeport auf das Registerfile am Ende braucht. Eben so wie es ATI macht.

Die TMUs in den Vertexshader sind zudem auch nicht vollkommen nebenläufig weil zumindestens der Writeport am Ende Fehlt. Das Sample muss wieder in die primäre Pipe zurück. Diese muss dann im Zweifel auf die TMU warten.

[robbitop]

Wie geschrieben die Abhänigkeit bekommt man nur weg wenn man ALUs und TMUs vollkommen nebenläufig macht. Das heist das die TMU einen Readport am Anfang und einen Writeport auf das Registerfile am Ende braucht. Eben so wie es ATI macht.

Und wo ist das Problem, soetwas einzurichten?

[Demirug]

Und wo ist das Problem, soetwas einzurichten?

Das gleiche Problem wie immer. Es kostet Transitoren.

[Quasar]

Und wo ist das Problem, soetwas einzurichten?
321 vs. 302. ;)

[aths]

Nein, der Filterkern kann schon ein paar Takte brauchen. Die einzelnen BI-Samples müssen nur direkt hintereinader in den Kern eingeschoben werden.

Die Speicherlatenz muss verdeckt werden. deswegen muss zwischen dem Addressrechner und dem Filterkern ein FIFO sein.

Wie geschrieben die Abhänigkeit bekommt man nur weg wenn man ALUs und TMUs vollkommen nebenläufig macht. Das heist das die TMU einen Readport am Anfang und einen Writeport auf das Registerfile am Ende braucht. Eben so wie es ATI macht.

Die TMUs in den Vertexshader sind zudem auch nicht vollkommen nebenläufig weil zumindestens der Writeport am Ende Fehlt. Das Sample muss wieder in die primäre Pipe zurück. Diese muss dann im Zweifel auf die TMU warten.Ich kann mir nicht vorstellen, dass NV hier an ein paar Registern gespart hat und so verhindert, dass man Sample-Latenz (bei Filterung die höherwertiger ist als bilinear) "wegshedulen" kann. Dass die TMU nicht mehrere Sample Ergebnisse pro Quad halten kann sehe ich noch ein (das wäre natürlich noch schöner) aber dass sie das Ergebnis sofort in die Pipe schreiben muss und nicht einen Batch zwischenpuffert halte ich wie schon gesagt für einen Konstruktionsfehler.

Wenn schon Batch, dann braucht man auch die Register (bzw. FIFOs) dafür.

[robbitop]

321 vs. 302. ;)
Oh c'mon. Das sind zwei wirklich zu differierende Architekturen für so einen platten Vergleich.
Und passender wäre IMO 321 vs 222 ;)

[robbitop]

Das gleiche Problem wie immer. Es kostet Transitoren.
Pro Pipe kostet G70 auch mehr Transistoren als NV40.

[aths]

Pro Pipe kostet G70 auch mehr Transistoren als NV40.Diese vier FP32-ADDs und die paar Extra-Kanäle (fürs DP) kosten nicht die Welt, aber bringen – wie man sieht – eine Menge.

[Xmas]

Ziemlich geringer Vorteil für G70, wenn man bedenkt, dass G70 doppelt so viele ALUs pro Pipeline hat, findest du nicht?
Er hat aber nicht doppelt so viele. ATI hat seit R300 MAD + ADD, NVidia im NV40 MAD + MUL und im G70 MAD + MAD.

[mindfaq]

Es geht mir aber um die Architektur. Somit wäre ein Vergleich bei in etwa gleicher Rechenwerkanzahl passend. Zumal das von der Pro Takt Leistung auch in etwa hinkommt (4 NV Quads vs 4x ATI Quads).Guck mal hier (http://www.driverheaven.net/articles/efficiency/index.htm).
Da wurde ein G70 mit zwei deaktivierten Quads und im Verhältnis zum ebenfalls getestetem R520 identischen Taktraten getestet.

[Ailuros]

Ich habe die prozentualen Differenzen addiert, und dann durch die Anzahl der Ergebnisse dividiert, ergo den Mittelwert bestimmt.

Gut dass Du kein Statistiker bist.

Nein, du kannst nicht lesen.
Ich habe geschrieben, dass G70 doppelt so viele ALUs pro Pipeline hat, das hat weder etwas mit dem Takt, noch mit der absoluten Pipelineanzahl zu tun. Der Taktvorteil des R520 gleicht sich ja durch die höhere Pipelineanzahl des ungefähr G70 aus, und umgekehrt. Nur in punkto ALU-Leitstung hat G70 auf dem Papier einen klaren Vorteil, der in der Praksis deutlich geringer ausfällt.

Es sind trotzdem 16 ALUs insgesamt auf R520 und 24 auf G70. Wie diese aufgeteilt sind und was daraus rausschiesst ist eine andere Geschichte.

Der Vorteil liegt nicht nur auf dem Papier, darauf kannst Du noch lange herumtrommeln die Wahrheit zeigt sich sowieso frueher oder spaeter.


Ich finde es vielmehr bedauerlich, dass du hier aufgrund falscher Interpretationen meiner Aussagen irgendetwas ableiten willst.

Deine diesbezueglichen Aussagen haben sowieso weder Haende noch Fuesse. Es reicht mir zu sehen wie Du den Durchschnitt ausrechnest.

[Demirug]

Ich kann mir nicht vorstellen, dass NV hier an ein paar Registern gespart hat und so verhindert, dass man Sample-Latenz (bei Filterung die höherwertiger ist als bilinear) "wegshedulen" kann. Dass die TMU nicht mehrere Sample Ergebnisse pro Quad halten kann sehe ich noch ein (das wäre natürlich noch schöner) aber dass sie das Ergebnis sofort in die Pipe schreiben muss und nicht einen Batch zwischenpuffert halte ich wie schon gesagt für einen Konstruktionsfehler.

Wenn schon Batch, dann braucht man auch die Register (bzw. FIFOs) dafür.

Registerspeicher ist teuer. Zudem hätte mehr Speicher aleine das Samplelatenz Problem nicht gelösst den dieses ist unabhängig von der Speichermenge.

Vorallem darf man auch nicht vergessen das nVidia das Pixelshaderprogramm über die TMUs lädt. Aus diesem Grund muss das ganze ebenfalls zwingend in Order bleiben.

[robbitop]

Er hat aber nicht doppelt so viele. ATI hat seit R300 MAD + ADD, NVidia im NV40 MAD + MUL und im G70 MAD + MAD.
Wie kann eine ALU 2x Vec4 Ops raushauen? Oder zählst du jetzt die ADD Mini ALU mit?

[robbitop]

Guck mal hier (http://www.driverheaven.net/articles/efficiency/index.htm).
Da wurde ein G70 mit zwei deaktivierten Quads und im Verhältnis zum ebenfalls getestetem R520 identischen Taktraten getestet.
Pro Pipe und Takt ist CineFX anscheinend schneller und dabei auch noch deutlich transistorgünstiger.

[robbitop]

Es sind trotzdem 16 ALUs insgesamt auf R520 und 24 auf G70.
R520 = 16 ALUs
G70 = 48 ALUs (2 Shaderunits/ALUs pro Pipeline).

R520 ist dank höherem Takt in etwa auf theoretisch der hälfte der aritmetischen Rechenkraft wie G70.
In der Praxis sieht das allerdings anders aus.
Deine Aussage stimmt erst wieder wenn das Wort Pipeline oder SIMD Channel fällt.

[Quasar]

Pro Pipe kostet G70 auch mehr Transistoren als NV40.
Eben, und mit noch mehr Registern (die auch wünschenswert wären) und solchen spaßigen, nebenläufigen TMUs, am besten noch mit 4x4-Filterkernel, frei programmierbar versteht sich, kosten sie eben noch mehr als noch mehr.

Oh c'mon. Das sind zwei wirklich zu differierende Architekturen für so einen platten Vergleich.
Und passender wäre IMO 321 vs 222 ;)
…daher auch mein "321 vs. 302" (Nvidia hat, auch wenn es im Vergleich zur R300 und R420 jeweils nicht so aussah, ziemlich an Transistoren gespart). Nvidia hat bereits über 300 Millionen Transistoren in einen 0,11µ-Prozess gequetscht, jede Million mehr verringert potentiell die Ausbeute noch weiter (und damit Nvs Marge) und senkt möglicherweise die breit erreichbare Taktrate.

Irgendwo ist halt ein kritischer Punkt erreicht, ab dem zusätzlicher Aufwand mehr schadet als nützt.

[reunion]

Gut dass Du kein Statistiker bist.


Du darfst mich gerne berichtigen.


Es sind trotzdem 16 ALUs insgesamt auf R520 und 24 auf G70. Wie diese aufgeteilt sind und was daraus rausschiesst ist eine andere Geschichte.

Der Vorteil liegt nicht nur auf dem Papier, darauf kannst Du noch lange herumtrommeln die Wahrheit zeigt sich sowieso frueher oder spaeter.

Deine diesbezueglichen Aussagen haben sowieso weder Haende noch Fuesse. Es reicht mir zu sehen wie Du den Durchschnitt ausrechnest.


Für mich unverständlich, wie man sich derart begriffsstutzig anstellen kann. Vielleicht helfen die nackten Zahlen:

R520: 16ALUs/625Mhz
G70: 48ALUs/430Mhz

Theoretisch ("auf dem Papier") G70 ~ 2 x R520
Praktisch ist es weitaus enger (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3559756&postcount=149).

Ich hoffe dir ist jetzt klar, auf was ich hinaus will/wollte.
Mehr versuche ich die letzten paar Seiten nicht zu sagen.

[seahawk]

Für mich unverständlich, wie man sich derart begriffsstutzig anstellen kann. Vielleicht helfen die nackten Zahlen:

R520: 16ALUs/625Mhz
G70: 48ALUs/430Mhz

Theoretisch ("auf dem Papier") G70 ~ 2 x R520
Praktisch ist es weitaus enger (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3559756&postcount=149).

Ich hoffe dir ist jetzt klar, auf was ich hinaus will/wollte.
Mehr versuche ich die letzten paar Seiten nicht zu sagen.

Wenn Du so zählst eher. 24ALUs@625 gegen 48 ALUs@430. Sonst unterschlägt man die Mini-ALUs des R520. Da sie aber nicht voll funktionieren habe ich sie mal nur als halbe ALU gerechnet. Was achlich natürlich falsch ist und eher als Betrachtung der möglichen maximalen Leistungsfähigkeit dient.

[Quasar]

R520 = 16 ALUs
G70 = 48 ALUs (2 Shaderunits/ALUs pro Pipeline).

(Ich glaube, ich erwähnte es schonmal) Was ist für dich eine ALU? Muss die Zwangsläufig ein MADD zustande bringen pro Takt? Mit welcher Präzision muss dieses MADD gerechnet werden und auf wieviele Kanäle?

[aths]

Ich denke, man kann sich auf folgendes einigen: Ohne nähere Bestimmung ist die ALU "alles", was da für arithmetische Rechnungen in Full Precision und voller Breite (RGBA) geboten wird.

Daraus kann man natürlich nicht direkt die Leistung ermitteln – sofern ein Modifier à la _bx2 genutzt wird, belegt das das ADD der Mini-ALU im R300/R520. Beim NV40/G70 gehe ich davon aus, dass jede der beiden Shader Units eine eigene Mini-ALU hat (die jedoch kein freies ADD bietet und nur Modifier kostenlos macht.)

[aths]

Registerspeicher ist teuer. Zudem hätte mehr Speicher aleine das Samplelatenz Problem nicht gelösst den dieses ist unabhängig von der Speichermenge.

Vorallem darf man auch nicht vergessen das nVidia das Pixelshaderprogramm über die TMUs lädt. Aus diesem Grund muss das ganze ebenfalls zwingend in Order bleiben.Was genau meinst du mit "in Order"? Ich möchte ja nicht den Shadercode out of order ausführen, sondern in genau der Reihenfolge, in der der Code vorliegt. Und während das Textursample erfiltert wird möchte ich arithmetische Rechnungen ausführen – welche das gleiche Quad betreffen. Diese Rechnungen müssen natürlich unabhängig vom Textursample sein (sonst kann man mit der Rechnung noch nicht anfangen) – und diese Instruktionen müssen vom Scheduler (vom Treiber) dorthin geschoben worden sein. Die Verarbeitung in der Pipe bliebe ein richtiger FIFO (manchmal frage ich mich, ob die Register tatsächlich Register mit freiem Zugriff sind, oder nicht auch nur ein FIFO.)

[3d]

ich würd auch gerne was verstehen.
gibts irgendwo ein faq, wo die ganzen begriffe und zusammenhänge einigermaßen verständlich erklärt werden?

[Demirug]

Die Quads innerhalb der Pipe müssen in Order bleiben.

Das ist schön das du das möchtest. nVidia möchte das sicherlich auch. Aber dafür braucht man dann noch mehr Logik. So ist es ja schon ein Problem das eine ALU vor und eine hinter der TMU liegt. Ganz schlecht in diesem Zusammenhang. Denn damit eine ALU weiterarbeiten kann müsste ein Loop um diese ALU gebaut sein. Ein anderes Problem ist der Code den die ALU ausführen soll. Wohl soll denn dieser bitte plötzlich aus dem nicht herkommen. Ich draf erinneren nVidia hat keinen echten Programmspeicher in den Pixelshader.

[Quasar]

Wenn das mit den Transistoren so weitergeht, könnten sie ja einen X300 von ATi lizenzieren und ihn als Hilfseinheit beschäftigen, sobald ein Stall auftritt. *SCNR*

[Coda]

Ich draf erinneren nVidia hat keinen echten Programmspeicher in den Pixelshader.Sondern?

[Crushinator]

Wenn das mit den Transistoren so weitergeht, könnten sie ja einen X300 von ATi lizenzieren und ihn als Hilfseinheit beschäftigen, sobald ein Stall auftritt. *SCNR*
Extrem gute Idee! Die Lizenz möge allerdings nur in Form einer Gegenlizensierung des OpenGL-Treibers oder in Form eines 6 monatigen Gastauftritts des OpenGL-Teams bei den Praktikanten in Toronto erteilt werden, und zwar mit Blackjack, Rest optional! X-D

[Demirug]

Sondern?

Die TMUs laden das Programm immer stückweise aus dem RAM und zwar immer für den Batch der dem Start Quad folgt. Ist recht interesant das System.

[robbitop]

Eben, und mit noch mehr Registern (die auch wünschenswert wären) und solchen spaßigen, nebenläufigen TMUs, am besten noch mit 4x4-Filterkernel, frei programmierbar versteht sich, kosten sie eben noch mehr als noch mehr.


…daher auch mein "321 vs. 302" (Nvidia hat, auch wenn es im Vergleich zur R300 und R420 jeweils nicht so aussah, ziemlich an Transistoren gespart). Nvidia hat bereits über 300 Millionen Transistoren in einen 0,11µ-Prozess gequetscht, jede Million mehr verringert potentiell die Ausbeute noch weiter (und damit Nvs Marge) und senkt möglicherweise die breit erreichbare Taktrate.

1.)Irgendwo ist halt ein kritischer Punkt erreicht, ab dem zusätzlicher Aufwand mehr schadet als nützt.
Naja @90nm sollte das ja kein Problem mehr sein. 2 zusätzliche PPs kosten auch wieder Transistoren. Verbesserungen kosten immer mehr. Aber für G70 war natürlich nicht mehr drin, da gebe ich dir voll und ganz Recht.

2.)achso..jetzt verstehe ich deinen Einwurf, ok :)

[Quasar]

2.)achso..jetzt verstehe ich deinen Einwurf, ok :)
*Juhu* =)

[Ailuros]

Für mich unverständlich, wie man sich derart begriffsstutzig anstellen kann. Vielleicht helfen die nackten Zahlen:

R520: 16ALUs/625Mhz
G70: 48ALUs/430Mhz

Seit wann hat G70 48 ALUs frage ich nur :rolleyes: 48 fragment Shader ja.

***edit: uebrigens die GFLOP Berechnungen sind dank R520 = 4 MADDs/ALU/clk vs. G70 = 8 MADDs/ALU/clk

16 * 4 = 64 MADDs/clk * 0.625GHz = 40 GMADDs/clk = 80GFLOPs

24 * 8 = 192 MADDs/clk * 0.43GHz = 82.56 GMADDs/clk = 165GFLOPs

Theoretisch ("auf dem Papier") G70 ~ 2 x R520
Praktisch ist es weitaus enger (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3559756&postcount=149).

Ich hoffe dir ist jetzt klar, auf was ich hinaus will/wollte.
Mehr versuche ich die letzten paar Seiten nicht zu sagen.

Praktisch beweisen kann ich Dir noch gar nichts; es gibt stets eine gigantische Luecke zwischen dem was ich sagen darf und den Kleinigkeiten ueber die ich meine Klappe halten muss.

Sonstige Gedankensporne:

http://www.beyond3d.com/forum/showpost.php?p=593913&postcount=51

[Sunrise]

Die Reihenfolge der Quads ändert sich nicht. Aber der Sheduler (die Software im Treiber) kann ja die Instruktionen umsortieren.
Ich kann mir nicht vorstellen, dass NV hier an ein paar Registern gespart hat und so verhindert, dass man Sample-Latenz (bei Filterung die höherwertiger ist als bilinear) "wegshedulen" kann.
Diese Rechnungen müssen natürlich unabhängig vom Textursample sein (sonst kann man mit der Rechnung noch nicht anfangen) – und diese Instruktionen müssen vom Sheduler (vom Treiber) dorthin geschoben worden sein.

aths, "scheduler" bitte in Zukunft mit c schreiben.

[Sunrise]

…daher auch mein "321 vs. 302" (Nvidia hat, auch wenn es im Vergleich zur R300 und R420 jeweils nicht so aussah, ziemlich an Transistoren gespart). Nvidia hat bereits über 300 Millionen Transistoren in einen 0,11µ-Prozess gequetscht, jede Million mehr verringert potentiell die Ausbeute noch weiter (und damit Nvs Marge) und senkt möglicherweise die breit erreichbare Taktrate.

Irgendwo ist halt ein kritischer Punkt erreicht, ab dem zusätzlicher Aufwand mehr schadet als nützt.

NV dürfte - ausgehend von G70 - einiges an Spielraum auf 90nm haben. Bei R580 erwarte ich nicht unter 380 Mio. Transistoren, auch wenn diese Zahlenspielereien eigentlich völliger Quatsch sind, denn man merkt am Die selbst, dass ATi entsprechend dicht packen konnte.

PS: Dave gibt den G70 mit 300 Mio. Transistoren an, Schreibfehler ?!

[Ailuros]

PS: Dave gibt den G70 mit 300 Mio. Transistoren an, Schreibfehler ?!

Es sind 302M laut NV's offiziellen (und nicht offiziellen) Dokumenten. Was sind schon 2 im Vergleich zu 300? :P

[Sunrise]

Es sind 302M laut NV's offiziellen (und nicht offiziellen) Dokumenten. Was sind schon 2 im Vergleich zu 300? :P

Angenommen ich würde dir 300 Euro leihen, verlange dann aber aufgrund deiner Argumentation 302 Euro von dir zurück, mit exakt dieser Begründung, wie würdest du dann reagieren ? :P

PS: Geht mir eher ums Prinzip, denn Dave gibt sonst auch immer alles exakt an.

[Ailuros]

Angenommen ich würde dir 300 Euro leihen, verlange dann aber aufgrund deiner Argumentation 302 Euro von dir zurück, mit exakt dieser Begründung, wie würdest du dann reagieren ? :P

Mieses Beispiel; ich wuerde sowieso Zinsen bezahlen wenn Du sie verlangen wuerdest. Mit dem Prozentual leihe ich mir dann gerne Geld von Dir aus :biggrin:

PS: Geht mir eher ums Prinzip, denn Dave gibt sonst auch immer alles exakt an.

Spass beiseite ich hab Dich schon verstanden, aber Tippfehler kann wohl auch Wavey nicht entgehen oder?

[Sunrise]

Mieses Beispiel; ich wuerde sowieso Zinsen bezahlen wenn Du sie verlangen wuerdest. Mit dem Prozentual leihe ich mir dann gerne Geld von Dir aus :biggrin:

Auch unter Freunden ? Selten jemanden erlebt, der so entgegenkommend reagiert, besonders beim Thema Geld. Aber da macht wohl jeder so seine Erfahrungen. :biggrin:

Spass beiseite ich hab Dich schon verstanden, aber Tippfehler kann wohl auch Wavey nicht entgehen oder?

Deshalb fragte ich ja, ob es ein Tippfehler ist, oder ob Dave hier wieder mehr weiß (was eher häufig als selten der Fall ist).

[robbitop]

Seit wann hat G70 48 ALUs frage ich nur :rolleyes: 48 fragment Shader ja.


Der G70 verfügt über 2 vollwertige Vec4 ALUs pro Pipeline. Du verwirrst der Begtriff fragment shader und ALU. R3xx - R5xx besitzt nur eine ALU pro Pipeline. Eine Vec4 ALU kann pro Takt eine Vec4 Op berechnen oder 2 Ops mittels splitting. Fragment Shader würde ich eher als Zusammenfassung des Shaderteils der Pipeline nutzen. Sprich SU0 + SU1 gehören dazu.

[Quasar]

Was ist eine ALU?

[seahawk]

Der G70 verfügt über 2 vollwertige Vec4 ALUs pro Pipeline. Du verwirrst der Begtriff fragment shader und ALU. R3xx - R5xx besitzt nur eine ALU pro Pipeline. Eine Vec4 ALU kann pro Takt eine Vec4 Op berechnen oder 2 Ops mittels splitting. Fragment Shader würde ich eher als Zusammenfassung des Shaderteils der Pipeline nutzen. Sprich SU0 + SU1 gehören dazu.

Dafür haben sie eben auch noch die Mini-ALUs. Du kannst doch nicht VEC4 voll zählen und Add ALUs vällig vernachlässigen.

[robbitop]

Was ist eine ALU?
Jedes Rechenwerk, was eine Vec4 Op pro Takt raushauen kann IMO.

[robbitop]

Dafür haben sie eben auch noch die Mini-ALUs. Du kannst doch nicht VEC4 voll zählen und Add ALUs vällig vernachlässigen.
MiniALUs hat der NV4x/G7x auch. Nur zählt NV die nicht extra mit. Da beide über solche MiniALUs verfügen, lasse ich sie schlicht weg, um niemanden zu verwirren.

[seahawk]

MiniALUs hat der NV4x/G7x auch. Nur zählt NV die nicht extra mit. Da beide über solche MiniALUs verfügen, lasse ich sie schlicht weg, um niemanden zu verwirren.

NV4X ja, G7X nein, ist die Mini-ALU nicht eben jetzt uur einer vollwertigen geowrden ?

[Demirug]

NV4X ja, G7X nein, ist die Mini-ALU nicht eben jetzt uur einer vollwertigen geowrden ?

Nein, schon beim NV40 haben die beiden ALUs jeweils noch zusätzlich eine Mini-ALU die nVidia aber nicht einzeichnet weil sie sagen das für sie diese Funktionen zu einer richtigen GPU ALU dazu gehöhren. Genau genommen sind es sogar 3 Mini ALUs weil die TMU auch noch eine hat.

[seahawk]

Ok, ich dachte NV4X hatte 1 MAD + 1 ADD, während G70 2 MAD hätte. ATI hingegen 1 MAD + 1 ADD

[Demirug]

Ok, ich dachte NV4X hatte 1 MAD + 1 ADD, während G70 2 MAD hätte. ATI hingegen 1 MAD + 1 ADD

Das sind die Kern ALUs. Wobei ich bezüglich des zweiten ADDs bei ATI immer noch so meine Zweifel habe. Das ist auf jeden Fall mal sehr launisch.

Die sogenannten Mini-ALU Funktionen gibt es bei ATI nur in dieser ADD ALU. Bei nVidia dagegen hat sie jede der ALUs und es scheinen auch mehr Funktionen ausführbar zu sein. Über die Details schweigen aber nVidia und ATI.

[seahawk]

Ok danke.

[aths]

Das sind die Kern ALUs. Wobei ich bezüglich des zweiten ADDs bei ATI immer noch so meine Zweifel habe. Das ist auf jeden Fall mal sehr launisch.

Die sogenannten Mini-ALU Funktionen gibt es bei ATI nur in dieser ADD ALU. Bei nVidia dagegen hat sie jede der ALUs und es scheinen auch mehr Funktionen ausführbar zu sein. Über die Details schweigen aber nVidia und ATI.Das sag ich dir. Die wenigen Leute, mit denen ich Kontakt habe, scheinen das aber nicht nur nicht sagen zu wollen, sondern auch gar nicht zu wissen. Ich wüsste schon gerne, was so eine Mini-ALU kann:

- Wirklich alle üblichen Modifikatoren oder nur die wichtigsten?
- Vielleicht aber noch etwas mehr, also nicht nur bis x8 sondern ggf. generell Zweierpotenzen?
- Ist nach der TMU eine "echte" Mini-ALU oder "nur" eine Skalierungs-Einheit? Oder kann auch _bx2 "kostenlos" ausgeführt werden, aber nach der TMU und nicht vor SU2.

[Xmas]

Die Quads innerhalb der Pipe müssen in Order bleiben.

Das ist schön das du das möchtest. nVidia möchte das sicherlich auch. Aber dafür braucht man dann noch mehr Logik. So ist es ja schon ein Problem das eine ALU vor und eine hinter der TMU liegt. Ganz schlecht in diesem Zusammenhang. Denn damit eine ALU weiterarbeiten kann müsste ein Loop um diese ALU gebaut sein. Ein anderes Problem ist der Code den die ALU ausführen soll. Wohl soll denn dieser bitte plötzlich aus dem nicht herkommen. Ich draf erinneren nVidia hat keinen echten Programmspeicher in den Pixelshader.
Ich sehe nicht ganz das Problem. Instruktionen müssen nur einmal pro Batch-Durchlauf geholt werden, also einmal alle 250 Takte oder so. Dafür gibts dann ja wohl auch ein "Steuer-Quad" das die Pipeline durchläuft.

[Demirug]

Ich sehe nicht ganz das Problem. Instruktionen müssen nur einmal pro Batch-Durchlauf geholt werden, also einmal alle 250 Takte oder so. Dafür gibts dann ja wohl auch ein "Steuer-Quad" das die Pipeline durchläuft.

Ja, und dieser Quad transportiert die Anweisungen für die ALUs und TMU. Ohne diesen Quad wüsste die ALU also nicht was sie rechnen soll. Um also an die nächste Anweisung zu kommen muss dieser Quad durch die TMU.

Ich bin aber offen für Vorschläge wie man ohne die TMU nebenläufig zu machen die verlorene ALU Leistung wiedergewinnen soll.

[Xmas]

Ich bin aber offen für Vorschläge wie man ohne die TMU nebenläufig zu machen die verlorene ALU Leistung wiedergewinnen soll.
Ich bin keineswegs überzeugt davon dass die TMU nicht nebenläufig ist.

[Demirug]

Ich bin keineswegs überzeugt davon dass die TMU nicht nebenläufig ist.

Dann haben wir in diesem Punkt keinen Konsens. Ich bin dann allerdings auf die Erklärung gespannt wieso ich dann die Filterlatenz für 8xAF nicht nutzen kann um einige MULs durchzuführen. Die MULs brauchen das Ergebniss des Texturesamples nicht und ich hatte auch nur 2 Temps benutzt.

[reunion]

Anandtech: R580 Details Emerge (http://www.anandtech.com/video/showdoc.aspx?i=2574)

[mapel110]

Anandtech: R580 Details Emerge (http://www.anandtech.com/video/showdoc.aspx?i=2574)
Vendors tell us R580 is some ways away, so don't expect anything between now and CeBit.

:uponder:

[sulak]

Angenommen man veröffentlich erst zur Cebit, hat man sein Tapeout ja so um die Jahreswende, kann also zum jetzigen Zeitpunkt immer noch Dinge einbaun bzw. entfernen oder?

[reunion]

Angenommen man veröffentlich erst zur Cebit, hat man sein Tapeout ja so um die Jahreswende, kann also zum jetzigen Zeitpunkt immer noch Dinge einbaun bzw. entfernen oder?

R580 hatte schon sein erstes Tapeout.

[Coda]

Ich denke auch nicht dass ATi große Probleme mit dem Chip hat.

[sulak]

Das meinte ich auch nicht, man kann sich ja auch aus anderen Gründen mit dem R580 Zeit lassen, um ggf bei Modular eingebauten Teilen auf den Markt reagieren zu können, weis nicht, vieleicht wie beim NV40-G70 mal eben 8 Pipes drantackern *g

[Coda]

Die R580 Specs stehen so gut wie fest. 48 PS-Alus und weiterhin 16 TMUs/16 ROPs.

[Ailuros]

Das meinte ich auch nicht, man kann sich ja auch aus anderen Gründen mit dem R580 Zeit lassen, um ggf bei Modular eingebauten Teilen auf den Markt reagieren zu können, weis nicht, vieleicht wie beim NV40-G70 mal eben 8 Pipes drantackern *g

R580 hat keine Verspaetungen in seiner Entwicklung gesehen bis jetzt und deshalb wird er auch mit hoechster Wahrscheinlichkeit in relativ kurzer Zeit nach R520 auf Regale kommen.

Das mit dem "mal 8 pipes drantackern" ist leichter gesagt als getan; zwischen NV40 und G70 lagen ~14 Monate.

[seahawk]

Ich denke es gibt 2 Gründe :

a) Wenn man jetzt offiziell schon über ein baldiges Erscheinen des R580 spricht, dann schädigt man den R520
b) muss der R520 sich erst noch lohnen
c) will man mit dem R580 wahrscheinlich auch eine ausreichende Verfügbarkeit zum Launch sicherstellen (in allen Versionen)

Sowohl NV als auch ATI isnd mit ihren nächsten Refreshes ziemlich weit, imho macht ein Launch zur Cebit für beide Sinn. R520 und G70 sind so gleich, dass keiner in Zugzwang ist und von März bis Vista ist ein guter Zeitraum.

[BodyLove]

R580 hat keine Verspaetungen in seiner Entwicklung gesehen bis jetzt und deshalb wird er auch mit hoechster Wahrscheinlichkeit in relativ kurzer Zeit nach R520 auf Regale kommen.

Das mit dem "mal 8 pipes drantackern" ist leichter gesagt als getan; zwischen NV40 und G70 lagen ~14 Monate.

Und wenn man sich diese Option bewussst freigehalten hat, bzw. mit gesenkter Priorität daran gearbeitet hat?

Ist volle Spekulation, aber in solch einem Forum sind wir ja.:)