R600: alles rund um die neue Generation, Teil 10

[deekey777]

Warum heißt dass dann FP16-HDR? :)
Weil auch die Postfilter-Effekte Alpha-Texturen sind, die gefiltert werden wollen? Aber nich immer.
;5465366']Was soll daran falsch sein? Was zählt ist wie effizient der Chip arbeitet, da kann hinten 3TFLOPs stehen was aber in der Praxis nichts bringt.

Dann lies doch mal, was er geschrieben hat: Der R600 wird mehr arithmetische Leistung haben. Und die hat er, was man schon Anfang März demonstriert hat.

[Coda]

Warum heißt dass dann FP16-HDR? :)
Weil's um den Framebuffer geht und nicht um die Texturen.

Wenn ein Spiel Lightmaps benützt muss man diese natürlich auch in HDR speichern (Source-Engine), für normale Texturen ist das völlig sinnfrei. Lightmaps sind btw. am aussterben, weil statisch.

Weil auch die Postfilter-Effekte Alpha-Texturen sind, die gefiltert werden wollen? Aber nich immer.
He?

[robbitop]

Warum heißt dass dann FP16-HDR? :)
Weil der Framebuffer mit FP16 pro Komponente geschrieben wird. Da ist dann eine deutlich hoehere Farbdynamik drin (Lichterspiele ahoi :D). So gibt es besonders bei Dunkel und bei Hell sehr viele Abstufungen.

[deekey777]

He?
Ich bin im falschen Film.

[reunion]

Achso, danke euch zwei. Ich ging bisher immer davon aus, dass dann auch die Texturen im FP16-Format vorliegen, da HDR doch einiges an Leistung verschlingt. Dann ist diese Eigenschaft von R600 aktuell wohl ziemlich nutzlos. Also kostet das wenn man auf Lightmaps verzichtet eigentlich nur zusätzliche Bandbreite und keine Texelfüllrate?

[AnarchX]

Es ist weder logisch noch unlogisch. Geht mal ins finstere Mittelalter des Jahres 2004, als die 6800Ultra vorgestellt wurde. Die Aussage war, dass UT3 mit allem drum und dran auf einer Grafikkarte spielbar sein wird, die 500 GFLOP/s an arithmetischer Leistung liefert.
Meine Vermutung: [...]


Ja und dazu sollte die Wunschkarte von Epic auch noch 2GB VRAM haben. ;D

Naja, fragt sich ob Epic bei dieser 500GFLOPs Aussage auch schon an solche ALU wie beim G80 gedacht hatte.

Wenn nun UT3 und andere UE3-Games wirklich sehr füllratenlastig sind, könnte das einiges an Arbeit für das ATi-Treiberteam bedeuten.
(Immerhin hat ja selbst der RSX eine höhere theoretische Texelleistung als die HD 2900XT X-D)

[Gmax]

Waren die UT Leute nicht immer sehr pro Nvidia?

[Gast]

Waren die UT Leute nicht immer sehr pro Nvidia?

Ich glaube die Aussage ist veraltet, wer heute einen Millionenseller hinlegen will muss beide GPU Hersteller superb unterstützten. Deswegen ist auch die UT Engine sehr beliebt und skaliert auf allen Karten gut.
Nur weil man sagt diese GPU wird unser Hauptenwicklungsinstrument ist man noch lange nicht biased.

[Gast]

Um den G80 auszureizen, muss man den Code so optmieren, dass auch von der MUL-Einheit gebrauchgemacht wird. Der R600 hat vollwertige MADD-Einheiten, er braucht so eine Optimierung nicht unbedingt. Ähnliches machen wohl die beiden Grünen bei Crytek.


Noe, der G80 braucht keine "Optimierungen" um die volle Rechenleistung abzufragen. Die Recheneinheiten laufenn immer auf vollen Touren, das ist architekturbedingt.
Dagegen benötigt der r600 angepasste Shader, um sicher zugehen, dass die einzelnen Recheneinheiten nicht brachliegen.

[horn 12]

Also ich habe bei meinem Netzteil
Delta DPS 450-AA nun nur einen einzigen 6-Pin Anschluss für die Graka, welchen ich derzeit ber der MSI 1950 PRO montiert habe.
Wird es einen Adapter von A/A geben, wo dieser 6 pin Anschluss auf 2x3 Pin geteilt wird? Bei der HD 2900XT muss man wohl beide Pin Pole besetzen, einer allein scheint nicht zu funktiuonieren...
Falls mein Netzteil reicht, werde ich die Karte wohl nicht übertakten können,- oder nur minimal da für hohes OCing wohl 1x4 und 2x3 Pins notwendig sein werden.
Oder sehe ich das komplett falsch?

[deekey777]

Noe, der G80 braucht keine "Optimierungen" um die volle Rechenleistung abzufragen. Die Recheneinheiten laufenn immer auf vollen Touren, das ist architekturbedingt.
Dagegen benötigt der r600 angepasste Shader, um sicher zugehen, dass die einzelnen Recheneinheiten nicht brachliegen.

Abgesehen davon, dass ich die skalaren Einheiten des G80 mit keinem Wort erwähnt habe: Welche sind die häufigsten Instruktionen in Spielen? Vec3+1?

[Gast]

Abgesehen davon, dass ich die skalaren Einheiten des G80 mit keinem Wort erwähnt habe: Welche sind die häufigsten Instruktionen in Spielen? Vec3+1?

Es ist egal, welche die häufigsten Instruktionen sind. Es liegt an der Art der Bearbeitung, dass die Recheneinheiten immer auf vollen Touren laufen.
Und die Mul läuft ebenfalls, indem sie den recheneinheiten Arbeit abnimmt. Ob das bissl zusätzlich Leistung auch nur annährend den Aufwand widerspiegelt, bezweifel ich.

[deekey777]

Es ist egal, welche die häufigsten Instruktionen sind. Es liegt an der Art der Bearbeitung, dass die Recheneinheiten immer auf vollen Touren laufen.
Und die Mul läuft ebenfalls, indem sie den recheneinheiten Arbeit abnimmt. Ob das bissl zusätzlich Leistung auch nur annährend den Aufwand widerspiegelt, bezweifel ich.
Es ist nicht egal. Besser gesagt: Dem G80 ist es egal, da er alle Instruktionen > Vec1 in einzelne Vec1-Instruktionen splittet.
Der R600 dreht natürlich Däumchen, wenn die Instruktionen < Vec4+1 sind, das sieht auch jeder Blinde. Aber dein Einwand war, dass man den Code für den R600 optimieren muss, was aber nicht unbedingt nötig ist, wenn die meisten PS Vec3+1 sind. Und VS profitieren schon immer von 4+1-Einheiten (der G70 hat sie, der R520 hat sie, alle haben sie), oder?

Wäre es nicht denkbar, dass der R600 bzw. der Compiler den Code ähnlich dem G80 in Vec1-Instruktionen aufspaltet?

[Nakai]

Wäre es nicht denkbar, dass der R600 bzw. der Compiler den Code ähnlich dem G80 in Vec1-Instruktionen aufspaltet?

Hat der R600 nun 4+1-Shader oder 1+1+1+1+1-Dinger. Aus der Präsentation wird das nicht klar...?

mfg Nakai

[Gast]

Aber dein Einwand war, dass man den Code für den R600 optimieren muss, was aber nicht unbedingt nötig ist, wenn die meisten PS Vec3+1 sind.


Sie sind heute so, weil die vorigen Architekturen mit dieser Konstellation am besten zu recht kamen.
Das stärkt doch nur meine These, da es den G80 egal ist, wie die "PS Vec" Anweisungen aussehen. Seine volle Rechenleistung schafft er bei einer Vec1 Instruktion sowie Vec3+1. Der r600 dagegen nicht
Welche Architektur benötigt nun eine Optimierung? Die, die immer die volle Leistung abruft, oder die, welche spezielle Instruktion benötigt, um nicht Leistung brachliegen zu lassen?

[Gast]

Hat der R600 nun 4+1-Shader oder 1+1+1+1+1-Dinger. Aus der Präsentation wird das nicht klar...?
mfg Nakai

Vec4+1 - wie Xenos.
AMD erwähnt Xenos nicht in ihrem Vergleich der Recheneinheiten. Jedoch wollen sie den r600 als die "second superscalar unified architecture" verkaufen.

[deekey777]

Vec4+1 - wie Xenos.
AMD erwähnt Xenos nicht in ihrem Vergleich der Recheneinheiten. Jedoch wollen sie den r600 als die "second superscalar unified architecture" verkaufen.
Was AMD aber erwähnt, dass die 5D-ALUS bis zu fünf Instruktionen verarbeiten kann, bei den anderen steht eindeutig bis zu zwei.

[Gast]

Was AMD aber erwähnt, dass die 5D-ALUS bis zu fünf Instruktionen verarbeiten kann, bei den anderen steht eindeutig bis zu zwei.

Und welche war ihre "first supercalar unified architecture"? ;)

[deekey777]

Und welche war ihre "first supercalar unified architecture"? ;)
Xenos.
Nochmal: Erste superskalare Architektur war der R300. Erste superskalare und unified Architektur war der Xenos.
Warum hängst du dich an diesem Begriff "superskalar" auf?

[DaEmpty]

Wäre es nicht denkbar, dass der R600 bzw. der Compiler den Code ähnlich dem G80 in Vec1-Instruktionen aufspaltet?
Es wäre ziemlich bescheuert, wenn er es nicht tun würde. Mathematische Abhängigkeiten können beim R600 trotzdem zu Blasen führen.

[(+44)]

Odal nicht Odol

1. zeigte auch ein G70/71 zum release keine grösseren Schwächen
2. bietet der R600 deutlich mehr Aritmetikpower
3. bietet der R600 deutlich mehr Bandbreite

Conclusion aus 2. und 3. Spiele werden eher Aritmethiklastiger und Bandbreitenlastiger (besonders wenn HDRR zum einsatz kommt) woraus folgt:

wenn eine 2900XT jetzt schon zwischen 8800GTS und 8800GTX (liegt näher an der GTX als an der GTS) positioniert ist laut spielebenchmarks aktueller und älterer Spiele, wird sie in zukünftigen Spielen von ihren Vorteilen eher profitieren als das die nachteile (Textureinheiten, ROPs) zu tragen kommen

Bei den Vergleichen wird immer vergessen, dass die nV-Karten keine NV40-Derrivate sind. Es ist ein NV50 - eine Neuentwicklung die so nicht mit dem klassischen PS/VS-Einheiten vergleichbar ist.

Klar war der G71 nur ein höher getakteter NV40, aber wieso der G80 in "neueren" Spielen jetzt wieder so verlieren soll, versteh ich nicht. Vielleicht wird der G91 das ja, weil ATi dann ein Architekturupdate bringt, aber ATM zieht dieses Argument nicht wirklich.

[deekey777]

Es wäre ziemlich bescheuert, wenn er es nicht tun würde. Mathematische Abhängigkeiten können beim R600 trotzdem zu Blasen führen.
Wußte ich's doch. :biggrin:

PS: nachträgliches herzlich Willkommen. :smile:

[Gast]

Xenos.
Nochmal: Erste superskalare Architektur war der R300. Erste superskalare und unified Architektur war der Xenos.

Schau ihre Marketing - Folien an. Xenos kann nach ihnen auch nur 2 Instruktionen pro Takt. Der r600 soll 5 Instruktionen können. Xenos kann seine Recheneinheiten jedoch nur in Vec4 + 1 skalar splitten.
Daher die Frage: Welche Architektur von ATi war denn ihre erste "superscalare unfied", die ebenfalls nach ihrer Zählweise x Instruktions pro Takt schafft?

* abhängig von den skalaren einer Recheneinheit.

[Gast]

"Superskalar" ist doch nur ein Marketing-Buzzword. G80 ist skalar, also muss R600 superskalar sein. Wirklich aussagekräftig ist dieses "superskalar" nämlich nicht.

[DaEmpty]

Daher die Frage: Welche Architektur von ATi war denn ihre erste "superscalare unfied", die ebenfalls nach ihrer Zählweise x Instruktions pro Takt schafft?
Xenos.
Er verteilt (wie auch schon der R300) 2 Operationen auf 2 parallele Recheneinheiten (einer Vec3/4 und einer Skalareinheit). R600 verteilt 5 Operationen auf 5 parallele Skalareinheiten. Beides passt auf die Definition von Superskalarität.
Wo ist dein Problem damit?

PS: nachträgliches herzlich Willkommen.
Danke.
Ich hoffe mal zu einigen Diskussionen was sinnvolles beitragen zu können. :)

[deekey777]

"Superskalar" ist doch nur ein Marketing-Buzzword. G80 ist skalar, also muss R600 superskalar sein. Wirklich aussagekräftig ist dieses "superskalar" nämlich nicht.
Genau. Ist wie Man <-> Superman.

Wie war das Sprichwort: Papier ist geduldig? Oder "Traue keiner Studie, die du nicht selbst gefälscht hast"?

[Coda]

Wäre es nicht denkbar, dass der R600 bzw. der Compiler den Code ähnlich dem G80 in Vec1-Instruktionen aufspaltet?
Nicht im gleichen Sinne. Natürlich wird der Compiler versuchen die Vec5-Einheiten optimal auszulasten, aber das kann ihm bei Abhängigkeiten eben nicht immer gelingen.

G80 kann seine Einheiten mit Sicherheit besser auslasten. Auf das Mul direkt zu optimieren wird sicher keiner machen, weil es verdammt selten verwendet werden kann und dann auch nicht viel bringt.

[Gast]

Wo ist dein Problem damit?


AMD's Aussage zum r600:

http://img251.imageshack.us/img251/6121/superscalar1tg0.jpg

Wo würdest du hier Xenos einordnen?
Ich denke mal - nach ihrem Maßstab - nicht in den "Superscalar" Bereich.

[Winter[Raven]]

was man schon Anfang März demonstriert hat.

Du meinst bestimmt diese PR-Folie mit 2x R600 @ 1Tflop?

arithmetische Leistung

Ok, mag sein, aber trotzdem will ich erst sehen was diese "mehr Flops" sich in der Praxis ausmachen.

[reunion]

Nicht im gleichen Sinne. Natürlich wird der Compiler versuchen die Vec5-Einheiten optimal auszulasten, aber das kann ihm bei Abhängigkeiten eben nicht immer gelingen.

G80 kann seine Einheiten mit Sicherheit besser auslasten. Auf das Mul direkt zu optimieren wird sicher keiner machen, weil es verdammt selten verwendet werden kann und dann auch nicht viel bringt.

Nur ohne MUL hat eine GTX eben "nur" eine peak Leistung von 345.6GFLOPs, während die XT mit 750Mhz auf 480GFLOPs kommt, was immerhin fast genau 40% mehr sind. Inwieweit man das durch die bessere Auslastung der Einheiten des G80 wird ausgleichen können, dürfte wohl im wesentlichen davon abhängen, wie gut der Compiler bei ATi arbeitet. Ich kann mir jedenfalls kaum vorstellen, dass bei R600 so viele Einheiten im Schnitt Däumchen drehen.

[Nakai]

Also lassen sich die R600 5D-ALUs zu 1+1+1+1+1 splitten? Ich traue den Folien nicht.

mfg Nakai

[reunion]

Also lassen sich die R600 5D-ALUs zu 1+1+1+1+1 splitten? Ich traue den Folien nicht.

mfg Nakai

Wenn die Folien nicht völlig frei erfunden sind, lässt die Erläuterung dort keinen anderen Schluss zu.

[Gast]

Ich kann mir jedenfalls kaum vorstellen, dass bei R600 so viele Einheiten im Schnitt Däumchen drehen.

Es müssen nicht "soviele Einheiten" seien. Wenn nur eine nicht benutzt wird, hat der r600 nur noch einen Vorteil von 11%.
Und da der G80 bei einem nur ca. 35% Vorteil der MADD - Leistung gegenüber der X1950XTX im Schnitt 80% vorne liegt, zeigt, wie effizient die Architektur ist.
Die Rechenleistung beider Karten wird auf dem gleichen Niveau liegen.

[Coda]

Nur ohne MUL hat eine GTX eben "nur" eine peak Leistung von 345.6GFLOPs, während die XT mit 750Mhz auf 480GFLOPs kommt, was immerhin fast genau 40% mehr sind.
GFlops vergleichen war und wird immer Schwachsinn sein. Wann kapiert ihr das endlich?

Ich kann mir jedenfalls kaum vorstellen, dass bei R600 so viele Einheiten im Schnitt Däumchen drehen.
Es wird aber so sein, sobald du entsprechende Dependencies drin hast. Im Extremfall wird jeden Takt genau ein Skalar fertig.

float a = 2;
float b = a + 2;
float c = b + 2;
usw.

Das kann G80 mit 100% Durchsatz ausführen, R600 nur mit 20%.

[Gast]

Also lassen sich die R600 5D-ALUs zu 1+1+1+1+1 splitten? Ich traue den Folien nicht.
mfg Nakai

Zur Zeit sage ich klar: Nein.
Das gleiche wie mit der "Mul-Einheit" beim G80. Das Marketing missbraucht diese, um über die wichtige 500GFlop Marke zu kommen.
Aus dem gleichen Grund bezeichnet AMD den r600 als "superscalar": Man will zeigen, dass ihre Architektur besser wäre als die von nVidia. Einerseits hätte man "superscalare" Recheneinheiten und man kann dann jede einzelne als Zahl benutzen - 320 Scalare.

[reunion]

GFlops vergleichen war und wird immer Schwachsinn sein. Wann kapiert ihr das endlich?

Das diente doch nur zur Erläuterung der weiteren Textes. Wenn das alles wäre, was ich geschrieben hätte, würde ich deinen Einwand verstehen, so nicht.

[Coda]

Das andere hab ich dir gerade erörtert. Splitting ist nicht die Lösung für diese Probleme.

[reunion]

Und da der G80 bei einem nur ca. 35% Vorteil der MADD - Leistung gegenüber der X1950XTX im Schnitt 80% vorne liegt, zeigt, wie effizient die Architektur ist.


Nur hat ATi die Effektivität der ALUs in Vergleich zu R580 auch erheblich gesteigert. Aber warten wir ab, so führt das ohnehin zu nichts.

[Coda]

Nur hat ATi die Effektivität der ALUs in Vergleich zu R580 auch erheblich gesteigert.
"Erheblich" gesteigert durch 1:1:1:1:1-Splitting? Ich glaube du überschätzt das etwas.

Die meiste Zeit rechnet man auf Vec3+Skalaren rum. Da war 3:1 nicht viel schlechter.

[deekey777]

;5465688']Du meinst bestimmt diese PR-Folie mit 2x R600 @ 1Tflop?
Es war keine PR-Folie. :mad:

http://www.hardocp.com/news.html?news=MjQ0MTcsLCxobmV3cywsLDE=
Siehst du irgendeine Folie?
http://forum.beyond3d.com/showpost.php?p=941211&postcount=326
Their test was written using Brook and the DX9 backend. CTM isn't magic, just like CUDA isn't magic. However, a simple MAD test with only a few registers being used, no texture lookups, and lots of iterations and pixels should run just about any board at full tilt. Where things get more complicated is a mix of instructions which pushes how the compiler and hardware do instruction scheduling.

Und: http://forum.beyond3d.com/showthread.php?p=940012#post940012
At least through CUDA and DX9/GL fragment programs, we've seen ~340GFlops for MAD on G80. We've never found the magic extra MUL, and the CUDA documentation and the CUDA forums says it isn't there, at least not for general use. R580 is ~240GFlops if just using MADs, and 360GFlops for ADD+MAD (you can do this with pain via DX/GL, but you can do it easily in CTM since you can write actual ASM). Of course, all of these shaders are contrived and your experience will vary with real code. ;-)
Theoretische MADD-Leistung des R580 = 48*8*0.65.
Und jetzt kannst du dir aus Fingern aussagen, was der R600 mit ~750 MHz und 128 FLOPs pro Takt an MADD-Leistung erreicht.
Die Ultra darf man aber nicht vergessen: 256 * 1,512

[Odal]

"]
beziehst du dich dabei @ arithmetische Leistung oder auf die Arth. Zahl auf dem Papier?

Anhand der "Arth. Zahl auf dem Papier" kann man die Arithmetikleistung abschätzen. Und dort sieht der R600 jedenfalls potenter aus als der G80. Ich denke mal schon das der R600 seine Recheneinheiten in den meisten Fällen recht gut auslasten kann.

[reunion]

Zur Zeit sage ich klar: Nein.
Das gleiche wie mit der "Mul-Einheit" beim G80. Das Marketing missbraucht diese, um über die wichtige 500GFlop Marke zu kommen.
Aus dem gleichen Grund bezeichnet AMD den r600 als "superscalar": Man will zeigen, dass ihre Architektur besser wäre als die von nVidia. Einerseits hätte man "superscalare" Recheneinheiten und man kann dann jede einzelne als Zahl benutzen - 320 Scalare.

Also eindeutiger als auf den Folien gehts nicht mehr. Auf solchen Folien werden natürlich nur die Sonnenseiten aufgezeigt, aber eine bewusste Lügen wird man wohl nicht präsentieren.

Es wird aber so sein, sobald du entsprechende Dependencies drin hast. Im Extremfall wird jeden Takt genau ein Skalar fertig.

float a = 2;
float b = a + 2;
float c = b + 2;
usw.

Das kann G80 mit 100% Durchsatz ausführen, R600 nur mit 20%.

Ja, das ist der eine Extremfall, den G80 dann theoretisch um 3.5 mal scheller ausführen könnte als R600. Nur interessant wäre die Durchschnittliche Auslastung der Einheiten. Schafft es R600 im Schnitt mehr als ~3.6 Instructionen pro 5D ALUs auszuführen, wäre er schneller als G80, bei weniger langsamer.

[Odal]

GFlops vergleichen war und wird immer Schwachsinn sein. Wann kapiert ihr das endlich?


Es wird aber so sein, sobald du entsprechende Dependencies drin hast. Im Extremfall wird jeden Takt genau ein Skalar fertig.

float a = 2;
float b = a + 2;
float c = b + 2;
usw.

Das kann G80 mit 100% Durchsatz ausführen, R600 nur mit 20%.

ähm in welchem Anwendungsfall wird bitteschön genau diese "sinnlose" instruktionsabfolge verwendet? Ausserdem gibts da noch die Möglichkeit der Optimierung und der Umsortierung so das zwischendrin andere Arithmetik Operationen durchgejagt werden welche davon unabhängig sind.

[Gast]

Schafft es R600 im Schnitt mehr als ~3.6 Instructionen pro 5D ALUs auszuführen, wäre er schneller als G80, bei weniger langsamer.Die pervers überlegene Füllrate des G80 nicht vergessen.

[reunion]

Die pervers überlegene Füllrate des G80 nicht vergessen.

Ich denke es war offensichtlich, dass sich das auf die ALU-Leistung bezog. Dass das nur ein Aspekt unter vielen ist, der für die Endleistung verantwortlich ist, sollte jedem klar sein.

[reunion]

ähm in welchem Anwendungsfall wird bitteschön genau diese "sinnlose" instruktionsabfolge verwendet? Ausserdem gibts da noch die Möglichkeit der Optimierung und der Umsortierung so das zwischendrin andere Arithmetik Operationen durchgejagt werden welche davon unabhängig sind.

Das sind doch nur Extrembeispiele, sowas sollte man nicht ernst nehmen. Genausogut könnte man jetzt mit dem kommen:

Test instruction set (length 384, no texture fetch and 100 iterations)
MAD R0.xyz, R0, R0, R1;
MUL R2.x, R2, R3;
MAD R1.x, R1, R1, R3;
MAD R0.xyz, R1, R1, R0;
ADD R2.x, R1, R2;
MUL R3.x, R3, R1;


R600XT (co-issue 3 instructions) - 93,9277 GInstr/sec

8800 GTX - 39,1998 GInstr/sec

http://forum.beyond3d.com/showpost.php?p=979177&postcount=3849

[Gast]

Man sollte immer schön alles mitzitieren:


Why is the 8800GTX so slow in this? I see 10 scalar instructions among the 6 total instructions, so theoretically shouldn't it be 1.35*128*6/10 = 104 GInstr/sec?
It's almost as if the GTX is treating that set as 6 4D instructions and masking the rest. There must be significant compiler issues. On the other hand, the R600XT rate doesn't reach the naive theoretical peak either (unless it's clocked at 500MHz), so who knows what's going on.

http://forum.beyond3d.com/showpost.php?p=979399&postcount=3912

[DaEmpty]

Ich sehe ja nicht, dass man in Zukunft noch größtenteils mit Vec3+1 im PS rechnet...

Aber nehmen wir mal ein praktisches leistungsfressendes Beispiel. :biggrin:

Interessant ist vorallem die while-Schleife in der Funktion RenderScenePS, da sie das Raycasting durchführt und damit den größten Teil der Leistung frisst.
Nun könnt ihr ja mal Compiler spiele und das in Blöcken von 5 Sklaren verteilen.

//--------------------------------------------------------------------------------------
// File: ParallaxOcclusionMapping.fx
//
// Parallax occlusion mapping implementation
//
// Implementation of the algorithm as described in "Dynamic Parallax Occlusion
// Mapping with Approximate Soft Shadows" paper, by N. Tatarchuk, ATI Research,
// to appear in the proceedings of ACM Symposium on Interactive 3D Graphics and Games, 2006.
//
// For examples of use in a real-time scene, see ATI X1K demo "ToyShop":
// http://www.ati.com/developer/demos/rx1800.html
//
// Copyright (c) ATI Research, Inc. All rights reserved.
//--------------------------------------------------------------------------------------

//--------------------------------------------------------------------------------------
// Global variables
//--------------------------------------------------------------------------------------

texture g_baseTexture; // Base color texture
texture g_nmhTexture; // Normal map and height map texture pair

float4 g_materialAmbientColor; // Material's ambient color
float4 g_materialDiffuseColor; // Material's diffuse color
float4 g_materialSpecularColor; // Material's specular color

float g_fSpecularExponent; // Material's specular exponent
bool g_bAddSpecular; // Toggles rendering with specular or without

// Light parameters:
float3 g_LightDir; // Light's direction in world space
float4 g_LightDiffuse; // Light's diffuse color
float4 g_LightAmbient; // Light's ambient color

float4 g_vEye; // Camera's location
float g_fBaseTextureRepeat; // The tiling factor for base and normal map textures
float g_fHeightMapScale; // Describes the useful range of values for the height field

// Matrices:
float4x4 g_mWorld; // World matrix for object
float4x4 g_mWorldViewProjection; // World * View * Projection matrix
float4x4 g_mView; // View matrix

bool g_bVisualizeLOD; // Toggles visualization of level of detail colors
bool g_bVisualizeMipLevel; // Toggles visualization of mip level
bool g_bDisplayShadows; // Toggles display of self-occlusion based shadows

float2 g_vTextureDims; // Specifies texture dimensions for computation of mip level at
// render time (width, height)

int g_nLODThreshold; // The mip level id for transitioning between the full computation
// for parallax occlusion mapping and the bump mapping computation

float g_fShadowSoftening; // Blurring factor for the soft shadows computation

int g_nMinSamples; // The minimum number of samples for sampling the height field profile
int g_nMaxSamples; // The maximum number of samples for sampling the height field profile



//--------------------------------------------------------------------------------------
// Texture samplers
//--------------------------------------------------------------------------------------
sampler tBase =
sampler_state
{
Texture = < g_baseTexture >;
MipFilter = LINEAR;
MinFilter = LINEAR;
MagFilter = LINEAR;
};
sampler tNormalHeightMap =
sampler_state
{
Texture = < g_nmhTexture >;
MipFilter = LINEAR;
MinFilter = LINEAR;
MagFilter = LINEAR;
};


//--------------------------------------------------------------------------------------
// Vertex shader output structure
//--------------------------------------------------------------------------------------
struct VS_OUTPUT
{
float4 position : POSITION;
float2 texCoord : TEXCOORD0;
float3 vLightTS : TEXCOORD1; // light vector in tangent space, denormalized
float3 vViewTS : TEXCOORD2; // view vector in tangent space, denormalized
float2 vParallaxOffsetTS : TEXCOORD3; // Parallax offset vector in tangent space
float3 vNormalWS : TEXCOORD4; // Normal vector in world space
float3 vViewWS : TEXCOORD5; // View vector in world space

};


//--------------------------------------------------------------------------------------
// This shader computes standard transform and lighting
//--------------------------------------------------------------------------------------
VS_OUTPUT RenderSceneVS( float4 inPositionOS : POSITION,
float2 inTexCoord : TEXCOORD0,
float3 vInNormalOS : NORMAL,
float3 vInBinormalOS : BINORMAL,
float3 vInTangentOS : TANGENT )
{
VS_OUTPUT Out;

// Transform and output input position
Out.position = mul( inPositionOS, g_mWorldViewProjection );

// Propagate texture coordinate through:
Out.texCoord = inTexCoord * g_fBaseTextureRepeat;

// Transform the normal, tangent and binormal vectors from object space to homogeneous projection space:
float3 vNormalWS = mul( vInNormalOS, (float3x3) g_mWorld );
float3 vTangentWS = mul( vInTangentOS, (float3x3) g_mWorld );
float3 vBinormalWS = mul( vInBinormalOS, (float3x3) g_mWorld );

// Propagate the world space vertex normal through:
Out.vNormalWS = vNormalWS;

vNormalWS = normalize( vNormalWS );
vTangentWS = normalize( vTangentWS );
vBinormalWS = normalize( vBinormalWS );

// Compute position in world space:
float4 vPositionWS = mul( inPositionOS, g_mWorld );

// Compute and output the world view vector (unnormalized):
float3 vViewWS = g_vEye - vPositionWS;
Out.vViewWS = vViewWS;

// Compute denormalized light vector in world space:
float3 vLightWS = g_LightDir;

// Normalize the light and view vectors and transform it to the tangent space:
float3x3 mWorldToTangent = float3x3( vTangentWS, vBinormalWS, vNormalWS );

// Propagate the view and the light vectors (in tangent space):
Out.vLightTS = mul( vLightWS, mWorldToTangent );
Out.vViewTS = mul( mWorldToTangent, vViewWS );

// Compute the ray direction for intersecting the height field profile with
// current view ray. See the above paper for derivation of this computation.

// Compute initial parallax displacement direction:
float2 vParallaxDirection = normalize( Out.vViewTS.xy );

// The length of this vector determines the furthest amount of displacement:
float fLength = length( Out.vViewTS );
float fParallaxLength = sqrt( fLength * fLength - Out.vViewTS.z * Out.vViewTS.z ) / Out.vViewTS.z;

// Compute the actual reverse parallax displacement vector:
Out.vParallaxOffsetTS = vParallaxDirection * fParallaxLength;

// Need to scale the amount of displacement to account for different height ranges
// in height maps. This is controlled by an artist-editable parameter:
Out.vParallaxOffsetTS *= g_fHeightMapScale;

return Out;
}


//--------------------------------------------------------------------------------------
// Pixel shader output structure
//--------------------------------------------------------------------------------------
struct PS_OUTPUT
{
float4 RGBColor : COLOR0; // Pixel color
};

struct PS_INPUT
{
float2 texCoord : TEXCOORD0;
float3 vLightTS : TEXCOORD1; // light vector in tangent space, denormalized
float3 vViewTS : TEXCOORD2; // view vector in tangent space, denormalized
float2 vParallaxOffsetTS : TEXCOORD3; // Parallax offset vector in tangent space
float3 vNormalWS : TEXCOORD4; // Normal vector in world space
float3 vViewWS : TEXCOORD5; // View vector in world space
};


//--------------------------------------------------------------------------------------
// Function: ComputeIllumination
//
// Description: Computes phong illumination for the given pixel using its attribute
// textures and a light vector.
//--------------------------------------------------------------------------------------
float4 ComputeIllumination( float2 texCoord, float3 vLightTS, float3 vViewTS, float fOcclusionShadow )
{
// Sample the normal from the normal map for the given texture sample:
float3 vNormalTS = normalize( tex2D( tNormalHeightMap, texCoord ) * 2 - 1 );

// Sample base map:
float4 cBaseColor = tex2D( tBase, texCoord );

// Compute diffuse color component:
float3 vLightTSAdj = float3( vLightTS.x, -vLightTS.y, vLightTS.z );

float4 cDiffuse = saturate( dot( vNormalTS, vLightTSAdj )) * g_materialDiffuseColor;

// Compute the specular component if desired:
float4 cSpecular = 0;
if ( g_bAddSpecular )
{
float3 vReflectionTS = normalize( 2 * dot( vViewTS, vNormalTS ) * vNormalTS - vViewTS );

float fRdotL = saturate( dot( vReflectionTS, vLightTSAdj ));
cSpecular = saturate( pow( fRdotL, g_fSpecularExponent )) * g_materialSpecularColor;
}

// Composite the final color:
float4 cFinalColor = (( g_materialAmbientColor + cDiffuse ) * cBaseColor + cSpecular ) * fOcclusionShadow;

return cFinalColor;
}


//--------------------------------------------------------------------------------------
// Parallax occlusion mapping pixel shader
//
// Note: this shader contains several educational modes that would not be in the final
// game or other complicated scene rendering. The blocks of code in various "if"
// statements for turning off visual qualities (such as visual level of detail
// or specular or shadows, etc), can be handled differently, and more optimally.
// It is implemented here purely for educational purposes.
//--------------------------------------------------------------------------------------
float4 RenderScenePS( PS_INPUT i ) : COLOR0
{

// Normalize the interpolated vectors:
float3 vViewTS = normalize( i.vViewTS );
float3 vViewWS = normalize( i.vViewWS );
float3 vLightTS = normalize( i.vLightTS );
float3 vNormalWS = normalize( i.vNormalWS );

float4 cResultColor = float4( 0, 0, 0, 1 );

// Adaptive in-shader level-of-detail system implementation. Compute the
// current mip level explicitly in the pixel shader and use this information
// to transition between different levels of detail from the full effect to
// simple bump mapping. See the above paper for more discussion of the approach
// and its benefits.

// Compute the current gradients:
float2 fTexCoordsPerSize = i.texCoord * g_vTextureDims;

// Compute all 4 derivatives in x and y in a single instruction to optimize:
float2 dxSize, dySize;
float2 dx, dy;

float4( dxSize, dx ) = ddx( float4( fTexCoordsPerSize, i.texCoord ) );
float4( dySize, dy ) = ddy( float4( fTexCoordsPerSize, i.texCoord ) );

float fMipLevel;
float fMipLevelInt; // mip level integer portion
float fMipLevelFrac; // mip level fractional amount for blending in between levels

float fMinTexCoordDelta;
float2 dTexCoords;

// Find min of change in u and v across quad: compute du and dv magnitude across quad
dTexCoords = dxSize * dxSize + dySize * dySize;

// Standard mipmapping uses max here
fMinTexCoordDelta = max( dTexCoords.x, dTexCoords.y );

// Compute the current mip level (* 0.5 is effectively computing a square root before )
fMipLevel = max( 0.5 * log2( fMinTexCoordDelta ), 0 );

// Start the current sample located at the input texture coordinate, which would correspond
// to computing a bump mapping result:
float2 texSample = i.texCoord;

// Multiplier for visualizing the level of detail (see notes for 'nLODThreshold' variable
// for how that is done visually)
float4 cLODColoring = float4( 1, 1, 3, 1 );

float fOcclusionShadow = 1.0;

if ( fMipLevel <= (float) g_nLODThreshold )
{
//===============================================//
// Parallax occlusion mapping offset computation //
//===============================================//

// Utilize dynamic flow control to change the number of samples per ray
// depending on the viewing angle for the surface. Oblique angles require
// smaller step sizes to achieve more accurate precision for computing displacement.
// We express the sampling rate as a linear function of the angle between
// the geometric normal and the view direction ray:
int nNumSteps = (int) lerp( g_nMaxSamples, g_nMinSamples, dot( vViewWS, vNormalWS ) );

// Intersect the view ray with the height field profile along the direction of
// the parallax offset ray (computed in the vertex shader. Note that the code is
// designed specifically to take advantage of the dynamic flow control constructs
// in HLSL and is very sensitive to specific syntax. When converting to other examples,
// if still want to use dynamic flow control in the resulting assembly shader,
// care must be applied.
//
// In the below steps we approximate the height field profile as piecewise linear
// curve. We find the pair of endpoints between which the intersection between the
// height field profile and the view ray is found and then compute line segment
// intersection for the view ray and the line segment formed by the two endpoints.
// This intersection is the displacement offset from the original texture coordinate.
// See the above paper for more details about the process and derivation.
//

float fCurrHeight = 0.0;
float fStepSize = 1.0 / (float) nNumSteps;
float fPrevHeight = 1.0;
float fNextHeight = 0.0;

int nStepIndex = 0;
bool bCondition = true;

float2 vTexOffsetPerStep = fStepSize * i.vParallaxOffsetTS;
float2 vTexCurrentOffset = i.texCoord;
float fCurrentBound = 1.0;
float fParallaxAmount = 0.0;

float2 pt1 = 0;
float2 pt2 = 0;

float2 texOffset2 = 0;

while ( nStepIndex < nNumSteps )
{
vTexCurrentOffset -= vTexOffsetPerStep;

// Sample height map which in this case is stored in the alpha channel of the normal map:
fCurrHeight = tex2Dgrad( tNormalHeightMap, vTexCurrentOffset, dx, dy ).a;

fCurrentBound -= fStepSize;

if ( fCurrHeight > fCurrentBound )
{
pt1 = float2( fCurrentBound, fCurrHeight );
pt2 = float2( fCurrentBound + fStepSize, fPrevHeight );

texOffset2 = vTexCurrentOffset - vTexOffsetPerStep;

nStepIndex = nNumSteps + 1;
fPrevHeight = fCurrHeight;
}
else
{
nStepIndex++;
fPrevHeight = fCurrHeight;
}
}

float fDelta2 = pt2.x - pt2.y;
float fDelta1 = pt1.x - pt1.y;

float fDenominator = fDelta2 - fDelta1;

// SM 3.0 requires a check for divide by zero, since that operation will generate
// an 'Inf' number instead of 0, as previous models (conveniently) did:
if ( fDenominator == 0.0f )
{
fParallaxAmount = 0.0f;
}
else
{
fParallaxAmount = (pt1.x * fDelta2 - pt2.x * fDelta1 ) / fDenominator;
}

float2 vParallaxOffset = i.vParallaxOffsetTS * (1 - fParallaxAmount );

// The computed texture offset for the displaced point on the pseudo-extruded surface:
float2 texSampleBase = i.texCoord - vParallaxOffset;
texSample = texSampleBase;

// Lerp to bump mapping only if we are in between, transition section:

cLODColoring = float4( 1, 1, 1, 1 );

if ( fMipLevel > (float)(g_nLODThreshold - 1) )
{
// Lerp based on the fractional part:
fMipLevelFrac = modf( fMipLevel, fMipLevelInt );

if ( g_bVisualizeLOD )
{
// For visualizing: lerping from regular POM-resulted color through blue color for transition layer:
cLODColoring = float4( 1, 1, max( 1, 2 * fMipLevelFrac ), 1 );
}

// Lerp the texture coordinate from parallax occlusion mapped coordinate to bump mapping
// smoothly based on the current mip level:
texSample = lerp( texSampleBase, i.texCoord, fMipLevelFrac );

}

if ( g_bDisplayShadows == true )
{
float2 vLightRayTS = vLightTS.xy * g_fHeightMapScale;

// Compute the soft blurry shadows taking into account self-occlusion for
// features of the height field:

float sh0 = tex2Dgrad( tNormalHeightMap, texSampleBase, dx, dy ).a;
float shA = (tex2Dgrad( tNormalHeightMap, texSampleBase + vLightRayTS * 0.88, dx, dy ).a - sh0 - 0.88 ) * 1 * g_fShadowSoftening;
float sh9 = (tex2Dgrad( tNormalHeightMap, texSampleBase + vLightRayTS * 0.77, dx, dy ).a - sh0 - 0.77 ) * 2 * g_fShadowSoftening;
float sh8 = (tex2Dgrad( tNormalHeightMap, texSampleBase + vLightRayTS * 0.66, dx, dy ).a - sh0 - 0.66 ) * 4 * g_fShadowSoftening;
float sh7 = (tex2Dgrad( tNormalHeightMap, texSampleBase + vLightRayTS * 0.55, dx, dy ).a - sh0 - 0.55 ) * 6 * g_fShadowSoftening;
float sh6 = (tex2Dgrad( tNormalHeightMap, texSampleBase + vLightRayTS * 0.44, dx, dy ).a - sh0 - 0.44 ) * 8 * g_fShadowSoftening;
float sh5 = (tex2Dgrad( tNormalHeightMap, texSampleBase + vLightRayTS * 0.33, dx, dy ).a - sh0 - 0.33 ) * 10 * g_fShadowSoftening;
float sh4 = (tex2Dgrad( tNormalHeightMap, texSampleBase + vLightRayTS * 0.22, dx, dy ).a - sh0 - 0.22 ) * 12 * g_fShadowSoftening;

// Compute the actual shadow strength:
fOcclusionShadow = 1 - max( max( max( max( max( max( shA, sh9 ), sh8 ), sh7 ), sh6 ), sh5 ), sh4 );

// The previous computation overbrightens the image, let's adjust for that:
fOcclusionShadow = fOcclusionShadow * 0.6 + 0.4;
}
}

// Compute resulting color for the pixel:
cResultColor = ComputeIllumination( texSample, vLightTS, vViewTS, fOcclusionShadow );

if ( g_bVisualizeLOD )
{
cResultColor *= cLODColoring;
}

// Visualize currently computed mip level, tinting the color blue if we are in
// the region outside of the threshold level:
if ( g_bVisualizeMipLevel )
{
cResultColor = fMipLevel.xxxx;
}

// If using HDR rendering, make sure to tonemap the resuld color prior to outputting it.
// But since this example isn't doing that, we just output the computed result color here:
return cResultColor;
}


//--------------------------------------------------------------------------------------
// Bump mapping shader
//--------------------------------------------------------------------------------------
float4 RenderSceneBumpMapPS( PS_INPUT i ) : COLOR0
{
// Normalize the interpolated vectors:
float3 vViewTS = normalize( i.vViewTS );
float3 vLightTS = normalize( i.vLightTS );

float4 cResultColor = float4( 0, 0, 0, 1 );

// Start the current sample located at the input texture coordinate, which would correspond
// to computing a bump mapping result:
float2 texSample = i.texCoord;

// Compute resulting color for the pixel:
cResultColor = ComputeIllumination( texSample, vLightTS, vViewTS, 1.0f );

// If using HDR rendering, make sure to tonemap the resuld color prior to outputting it.
// But since this example isn't doing that, we just output the computed result color here:
return cResultColor;
}


//--------------------------------------------------------------------------------------
// Apply parallax mapping with offset limiting technique to the current pixel
//--------------------------------------------------------------------------------------
float4 RenderSceneParallaxMappingPS( PS_INPUT i ) : COLOR0
{
const float sfHeightBias = 0.01;

// Normalize the interpolated vectors:
float3 vViewTS = normalize( i.vViewTS );
float3 vLightTS = normalize( i.vLightTS );

// Sample the height map at the current texture coordinate:
float fCurrentHeight = tex2D( tNormalHeightMap, i.texCoord ).a;

// Scale and bias this height map value:
float fHeight = fCurrentHeight * g_fHeightMapScale + sfHeightBias;

// Perform offset limiting if desired:
fHeight /= vViewTS.z;

// Compute the offset vector for approximating parallax:
float2 texSample = i.texCoord + vViewTS.xy * fHeight;

float4 cResultColor = float4( 0, 0, 0, 1 );

// Compute resulting color for the pixel:
cResultColor = ComputeIllumination( texSample, vLightTS, vViewTS, 1.0f );

// If using HDR rendering, make sure to tonemap the resuld color prior to outputting it.
// But since this example isn't doing that, we just output the computed result color here:
return cResultColor;
}

[Coda]

Schafft es R600 im Schnitt mehr als ~3.6 Instructionen pro 5D ALUs auszuführen, wäre er schneller als G80, bei weniger langsamer.
3.6 klingt für mich als Durchschnitt schon ziemlich gut. Wo ist also die so überlegende Arithmetikleistung die du für R600 vorschlägst?

Ausserdem gibts da noch die Möglichkeit der Optimierung und der Umsortierung so das zwischendrin andere Arithmetik Operationen durchgejagt werden welche davon unabhängig sind.
Man kann eben nicht immer umsortieren. Vor allem ist da D3D10 auch strenger geworden.

[Gast]

Schon witzig, bei Release des G80 wurde gemekert das die Arithmetikleistung im Vergleich zur R580 viel zuwenig nach vorne gegangen ist, dann kam man endlich auf den trichter das es die Effizienz ist die die Architektur stark macht und nun isses wieder zu wenig und jeder hängt sich an MUL auf...
R600 im Vergleich zum R580 ist momentan ein teurer Sprung nach vorne, denn von einer X1950XTX kann sich die HD2900XT nich voll absetzen (und die R580 hatte ja auch schon "überlegene ArithmetikLeistung")

[reunion]

Man sollte immer schön alles mitzitieren:



http://forum.beyond3d.com/showpost.php?p=979399&postcount=3912

Oh, das war keine Absicht. Ich hatte das damals gepostet, als es diesen quote noch nicht gab, und dann nicht mehr den Thread weiterverfolgt.

3.6 klingt für mich als Durchschnitt schon ziemlich gut. Wo ist also die so überlegende Arithmetikleistung die du für R600 vorschlägst?


Wo schlage ich das vor? Ich erwähnte jetzt glaube ich zum hundertsten male, dass es darauf ankommt, wie gut bei R600 die Einheiten ausgelastet werden können. Wir werden ja dann zum Launch durch viele Shadertests sehen, wie es in der Praxis aussieht.


Nun könnt ihr ja mal Compiler spiele und das in Blöcken von 5 Sklaren verteilen.


Könntest du da bitte für etwas weniger betuchte ein wenig nachhelfen? :)

[Gast]

welcher benchmark klingt im moment am vernüftigsten ?

[Winter[Raven]]

Es war keine PR-Folie. :mad:

http://www.hardocp.com/news.html?news=MjQ0MTcsLCxobmV3cywsLDE=
Siehst du irgendeine Folie?
http://forum.beyond3d.com/showpost.php?p=941211&postcount=326


Und: http://forum.beyond3d.com/showthread.php?p=940012#post940012

Theoretische MADD-Leistung des R580 = 48*8*0.65.
Und jetzt kannst du dir aus Fingern aussagen, was der R600 mit ~750 MHz und 128 FLOPs pro Takt an MADD-Leistung erreicht.
Die Ultra darf man aber nicht vergessen: 256 * 1,512

Ahso, sorry, ich kenne nur die eine PR-Folie von AMD mit Barcelona und 2x R600.

[DaEmpty]

Könntest du da bitte für etwas weniger betuchte ein wenig nachhelfen? :)
Zusammenfassend würd ich mal sagen, dass es manchmal knapp werden kann genügend Skalare zusammenzubringen. Es hängt viel vom Compiler ab, wie er Branches und Abhängigkeiten auflöst. Manchmal kann man ja auch die Formel umformen, was zwar mehr Rechenarbeit bedeutet aber im Endeffekt die Effizienz steigern würde.

Deine durchschnittlich 3.6 Skalare sind aber viel interessanter.
Praktisch heisst es nämlich, dass man es schaffen muss durchschnittlich mehr als 7 skalare Operationen ohne Abhängigkeit im Shader zu finden.

7/2 = 3.5
niedrigster Fall danach:
11/3 = 3.66

Unter 8 skalaren Operationen liegen nur noch 4 und 5 über dem erforderlichen Durchschnitt.

[deekey777]

Man sollte immer schön alles mitzitieren:



http://forum.beyond3d.com/showpost.php?p=979399&postcount=3912
Und den Rest auch:
http://forum.beyond3d.com/showthread.php?p=979437#post979437
http://forum.beyond3d.com/showthread.php?p=979633#post979633
That's exactly what I was saying. Multiply those rates by 6 instructions per iteration and you get 156.3 GInstr/s for R600XT and 105.6 GInst/s for G80. Tertsi's numbers were ~100 GInstr/s for R600XT and ~40 GInstr/s for G80.

Either something's not right in the measurement or the compilers aren't doing their job. Can't see any other reason for the disparity.

[Slipknot79]

welcher benchmark klingt im moment am vernüftigsten ?



Ich würde mal jene Benches meinen, die die XT zwischen der GTS und der GTX einordnen lassen.

[Nakai]

Kann mit mal jemand Jaweds Diagramm erklären?

Also es werden 2 Vec3-Mad-Ops und dann noch 2 skalare MULs, ein skalares ADD und 2 skalare MULs, oda?

Das Diagramm stellt jeweils eine ALU jeder GPU da. Beim R600 ist es eine der 5D-ALUs und beim G80 eine der Vec8-ALUs. Der R600 benötigt 16 Takte wo der G80 nur 10 Takte benötigt.
Der R600 hat aber 64 dieser Shader der G80 nur noch 16 dieser Art.
Da dies 8 Mal durchgeführt wird, braucht der R600 16 Takte und der G80 nur 10.

Bin ich damit richtig?

mfg Nakai

[reunion]

AMD is Throwing a Party!

On the evening of May 10th, AMD is throwing a party in San Francisco for you! There will be demos of the soon-to-market Barcelona and Radeon 2900 XT as well as the chance the play Prey DM on some of the newest AMD hardware. AMD staff will be there to answer your questions. Our own HardForum members will get priority and are encouraged to take pictures and post about the event. Please email Kyle@HardOCP.com with an invitation request for you and a guest. I will be there as well as other Web journalists to partake in the fun. You must be 21 and IDs will be checked at the door. See you there, Kyle!

http://www.hardocp.com/

[robbitop]

Hat der R600 nun 4+1-Shader oder 1+1+1+1+1-Dinger. Aus der Präsentation wird das nicht klar...?

mfg Nakai
Du musst umdenken. Die ALUs des R600 bearbeiten immer ein Pixel. Die G80 ALUs immer 16. Wenn pro Pixel und Takt weniger als 5 Instruktionen anfallen (was nicht unhaeufig ist), entstehen natuerlich Blasen beim R600, die der G80 nicht erleiden muss.

[seahawk]

Exakt, das Diagram verschleiert halt, dass R600 mehr horizontal an die Sache rangeht. Also man praktisch nur Instruktionene für eine Pixel spliten kann.

[Nakai]

Du musst umdenken. Die ALUs des R600 bearbeiten immer ein Pixel. Die G80 ALUs immer 16. Wenn pro Pixel und Takt weniger als 5 Instruktionen anfallen (was nicht unhaeufig ist), entstehen natuerlich Blasen beim R600, die der G80 nicht erleiden muss.

Also kann der R600 "nur" an 64 Pixeln arbeiten, wo der G80 an 128 arbeitet(der G80 braucht mehr Takte als der R600).
Also kann der R600 nur wenige Pixel berechnen, aber dafür sehr komplexe.

mfg Nakai

[Gast]

Jap, der G80 hat deswegen auch hochgetaktete Skalareinheiten :)

[robbitop]

Ein R600 braucht fuer 5 Instruktionen pro Pixel halt nur einen Takt.
Wenn aber weniger als 5 anfallen, drehen Teile der ALU Daeumchen. Und das ist generell nicht gerade ein unwesentlicher Teil.

Der G80 kann das umschiffen, da seine Einheiten gaenzlich anders angebunden sind, so dass sie Kanal fuer Kanal berechnen.

[w0mbat]

"Unbekannte" Karte erzielt sehr hohe 3DMark Werte. Hm, OC HD2900 XT?
http://www.nordichardware.com/forum/viewtopic.php?topic=8428&forum=45

[Gast]

Anhand der "Arth. Zahl auf dem Papier" kann man die Arithmetikleistung abschätzen. Und dort sieht der R600 jedenfalls potenter aus als der G80.
Auf dem Papier sahen X1950XTX und 7900 GTX auch "identisch" aus bei 249,6 GFLOPs. Eine G80-GTS verfügt nur über 230,4 MAD-GFLOPs und macht bei ziemlich nass.


Q

[Gast]

Wenn aber weniger als 5 anfallen, drehen Teile der ALU Daeumchen. Und das ist generell nicht gerade ein unwesentlicher Teil.
Irgendwie bin ich damit nicht so ganz glücklich.
Wenn die Auslastung durchschnittlich wirklich so schlecht ist, hätte man auch einfach 4fach ALUs nehmen können.
Wenn man die ALU Leistung effektiv zwischen GTX und GTX ansiedelt, dürfte durchschnittlich ziemlich genau eine bzw zwei (ergibt gleiche Auslastung) Vec3 Operation pro Takt anfallen. Wenn nur jeden zweite Takt noch ein einzige Skalar anfällt, würde man schon auf GTX Niveau liegen.

Ich hab mir jetzt einige Shader angesehen, aber ich sehs nicht wo dies überwiegend der Fall sein sollte.
Die effektive Rechenleistung, sollte mit 1:1:1:1:1 Splittung nicht unter der GTX in der Praxis liegen. Eine vollständige Auslastung war wohl auch garnicht das Ziel des Designs.

[Gast]

Ein R600 braucht fuer 5 Instruktionen pro Pixel halt nur einen Takt.
Dass es sich wohl um SIMD-Einheiten handelt, verschärft die Sache etwas. Ansonsten wären fünf Instruktionen pro Pixel sicherlich kein Problem; ich glaube nicht, dass häufig ein Pixel mit einer Komplettrechnung von RGBA zufrieden ist.


Q

[Gast]

Irgendwie bin ich damit nicht so ganz glücklich.
Wenn die Auslastung durchschnittlich wirklich so schlecht ist, hätte man auch einfach 4fach ALUs nehmen können.
Wenn man die ALU Leistung effektiv zwischen GTX und GTX ansiedelt, dürfte durchschnittlich ziemlich genau eine bzw zwei (ergibt gleiche Auslastung) Vec3 Operation pro Takt anfallen. Wenn nur jeden zweite Takt noch ein einzige Skalar anfällt, würde man schon auf GTX Niveau liegen.

Bei einigen PRT für Global Illumination hat man wohl Vec3+2 recht häufig.


Q

[Nakai]

Naja so schlecht ist das gar nicht, wobei das einfach nur 64 Vec5-Einheiten sind.

Naja erst ab Vec4-Ops liegt der R600 vorne, ansonsten ist der R600 schwächer in der Arithmetischen Leistung.

mfg Nakai

[robbitop]

Irgendwie bin ich damit nicht so ganz glücklich.
Wenn die Auslastung durchschnittlich wirklich so schlecht ist, hätte man auch einfach 4fach ALUs nehmen können.
Vertexshader kann man oftmals durch ein skalares SFU beschleunigen. Das wollte man sich wohl nicht nehmen lassen.

Ich persoenlich wuerde gefuehlsmaessig auf einen ungefaehren Gleichstand tippen.

[Gast]

Apropos FSU: Bei aller MADD-Begeisterung - was ist denn mit den SFUs?


Q

[robbitop]

Welche meinst du speziell (gibt ja so viele verschiedene)? Und was soll mit denen sein?

[DaEmpty]

Vertexshader kann man oftmals durch ein skalares SFU beschleunigen. Das wollte man sich wohl nicht nehmen lassen.
Bei welchen Operationen kann man die Beschleunigung denn nutzen?
Inwiefern macht das noch Sinn, wenn man bei dem Vec5 nicht mehr auf Vektorgrenzen angewiesen ist und man Skalare frei verteilen kann?

[AnarchX]

Apropos FSU: Bei aller MADD-Begeisterung - was ist denn mit den SFUs?

http://directupload.com/files/myjzmivzgmyw5iwzdgxi.jpg

Sieht wohl so aus, als müsste man die von den 475GFLOPs noch abziehen.
(Mit den SFUs kommt man beim G80GTX doch auf 691GFLOPs?)

[reunion]

Auf dem Papier sahen X1950XTX und 7900 GTX auch "identisch" aus bei 249,6 GFLOPs. Eine G80-GTS verfügt nur über 230,4 MAD-GFLOPs und macht beide ziemlich nass.


Q

Shaderleistung ist nicht alles. Eine GTS hat immerhin nicht gerade unerhebliche Vorteile was TMU- und ROP-Leistung, etc. betrifft. Bei einem R580 dürfte die Shaderleistung wohl so ziemlich das letzte sein, was limitiert.

[Coda]

G80 macht sie auch Nass, wenn man reine Shader ohne Filtering laufen lässt.

[Nakai]

Nur eine kleine theoretische Annahme:

Skalare Berechnungen:
Der R600 kann 64 solcher Ops in einem Takt durchführen. Der G80 128, ist noch höher getaktet.

---> 64 : 172,8

Vec2-Berechnungen:
Hier wieder 64 solcher Ops. Da der G80 zwei Takte benötigt, schafft er theoretisch nur 64(er würde 128 aufeinmal nach 2 Takten ausspucken!).

---> 64 : 86,4

Vec3-Berechnungen:

---> 64 : 57

Vec4-Berechnungen:

---> 64 : 48

Der R600 wäre hier schneller als der G80, wenn man nur die MAD-Performance betrachtet.

Vec5-Berechnungen:
5 Takte, der R600 schafft hier 320 Ops für 5 Takte, der G80 auch wieder nur 128.

---> 256 : 172,8 (64 : 34,56)

Bei Geomtrieberechnungen kann der R600 ungefähr 40% schneller sein als der G80. Ansonsten unterliegt der R600 dem G80. Der R600 muss mindestens mit 850 Mhz getaktet sein um der Geforce 8800GTX ebenbürtig zu sein, wenn man das nun betrachtet, da aber die ganzen Shaderops gemischt sind, kann der R600 hier und da vll noch etwas gewinnen. Der G80 hat mit größeren Shadern Probleme, hier kann der R600 deutlich punkten.
Nochmal zur Anmerkung, da der G80 horizontal die Pixel berechnet und nicht waagrecht wie der R600, kann man die Werte nicht wirklich vergleichen.
Theoretisch spuckt der G80 immer 128 Werte aufeinmal aus, aber erst nach einer bestimmten Anzahl an Takten, die je nach Komplexität der Berechnungen zunimmt.

Nun ein Frage, da der G80 immer für 8 Pixel immer die gleiche Berechnung gleichzeitig durchführt, kann es da auch nichtmal zu blasen kommen?
Oder kommen die verschiedenen Ops immer so gleichmäßig vor, oder verteilt der Scheduler die zu bearebitenden Pixel immer sehr gut?


mfg Nakai

(Mit den SFUs kommt man beim G80GTX doch auf 691GFLOPs?)

In jedem Cluster sind 4 SFUs drin, die alle 4 Takte ein Flop liefern.

---> 10,8 GFlops

[reunion]

G80 macht sie auch Nass, wenn man reine Shader ohne Filtering laufen lässt.

Das bezweifle ich auch gar nicht. Nur wird der Unterschied vermutlich geringer sein als bei Spielen.

[DaEmpty]

Nur eine kleine theoretische Annahme:

Skalare Berechnungen:
Der R600 kann 64 solcher Ops in einem Takt durchführen. Der G80 128, ist noch höher getaktet.

---> 64 : 172,8
Das stimmt nur unter der Annahme, dass alle Skalare Berechnungen voneinander abhängig sind. Ein seltener Fall.
Falls 5 skalare Operationen voneinander unabhängig sind, kann der R600 sie auch in einem Takt berechnen. Ein Vorteil der 1:1:1:1:1 Splittings.

Nun ein Frage, da der G80 immer für 8 Pixel immer die gleiche Berechnung gleichzeitig durchführt, kann es da auch nichtmal zu blasen kommen?
Oder kommen die verschiedenen Ops immer so gleichmäßig vor, oder verteilt der Scheduler die zu bearebitenden Pixel immer sehr gut?
Am Ende eines Batches sollten fast immer ein paar Blasen durch fehlende Pixel auftreten. Ansonsten müsste ein FIFO innerhalb eines Batches schon alles abfangen können, was nicht durch DB verursacht wird.
Hatte wir Ende Teil 9 schonmal. ;)

[Gast]

Shaderleistung ist nicht alles. Eine GTS hat immerhin nicht gerade unerhebliche Vorteile was TMU- und ROP-Leistung, etc. betrifft. Bei einem R580 dürfte die Shaderleistung wohl so ziemlich das letzte sein, was limitiert.

Ja aber genau das sagst du doch, die Arithmetikleistung des R600 soll Bäume ausreißen können, und nun ist es nicht alles... Füllrate, ROPs da wird der R600 dran zu beißen haben, denn viel Bandbreite hat eine GTS gegenüber der XT nicht und geht trotzdem wie geschnitten Brot (Bis zur Standart Auflösung der 24" WideTFT)

[reunion]

Ja aber genau das sagst du doch, die Arithmetikleistung des R600 soll Bäume ausreißen können, und nun ist es nicht alles...

Lege mir nicht irgendwelche Sätze in den Mund, die ich nicht gesagt habe.

[Nakai]

Falls 5 skalare Operationen voneinander unabhängig sind, kann der R600 sie auch in einem Takt berechnen. Ein Vorteil der 1:1:1:1:1 Splittings.

Danke für die Aufklärung.

mfg Nakai

[seahawk]

Danke für die Aufklärung.

mfg Nakai

Aber nur, wenn sie für ein Pixel benötigt werden. :biggrin:

[robbitop]

Bei welchen Operationen kann man die Beschleunigung denn nutzen?
Inwiefern macht das noch Sinn, wenn man bei dem Vec5 nicht mehr auf Vektorgrenzen angewiesen ist und man Skalare frei verteilen kann?
Soweit ich das verstanden habe, sind die Kanaele der ALUs fix. Also wird das mit Verteilen nichts. (oder missverstehe ich dich gerade?)

[deekey777]

http://directupload.com/files/j2rwj2tyjxmcamngnimz.jpeg
In der Annahme, dass diese Schemata die Wahrheit wiedergeben: Kann es sein, dass die kleinste ALU-Gruppe einer SIMD-Einheit des RV610 entspricht und die TUs von dem Shaderblock wirklich entkoppelt sind?:confused:

[robbitop]

Die Anzahl und die Groesse an SIMDs variiert. anhand der Zeichnung ist die kleinste SIMD wohl eine Quad ALU.

[Gast]

Der G80 hat mit größeren Shadern Probleme, hier kann der R600 deutlich punkten.

Probleme?
Es wurde doch schon geklärt, dass der G80 keine Probleme mit "komplexen" Shadern hat. Er kann immer seine Recheneinheiten auslasten!

[Gast]

Das war, glaub ich, eher so gemeint, dass der G80 bei komplexen Berechnungen nicht mit dem R600 mithalten könnte. Der Flaschenhals liegt beim R600 bei "Unterbelastung" und beim G80 bei der "Überbelastung", wenn der R600 seine Rohleistung besser ausspielen kann.

[deekey777]

Hier fehlt doch eine Folie: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=359698
Es gibt keine adäquate Folie des R600 zu der Folie, die in meinem vorherigen Posting zu sehen ist. :| Das wäre die Folie Nr. 5. Warum fehlt ausgerechnet sie?
Und warum gibt's die Seite 12 zweimal?
Die Anzahl und die Groesse an SIMDs variiert. anhand der Zeichnung ist die kleinste SIMD wohl eine Quad ALU.
Es wäre denkbar, dass sie wie beim G80 nach und nach zusammengefasst werden, was ich irgendwie nicht so recht glauben will: 16 5D-ALUs führen immer die gleichen Instruktionen? Das ist doch doof.

[Gmax]

Fudzi (http://www.fudzilla.com/index.php?option=com_content&task=view&id=838&Itemid=1) meint, der R65o soll schon im September kommen.

Ist da eurer Meinung was dran? Ich kanns mir nach den vielen Verspätungen dieses Jahr echt nicht vorstellen.

[robbitop]

Es wäre denkbar, dass sie wie beim G80 nach und nach zusammengefasst werden, was ich irgendwie nicht so recht glauben will: 16 5D-ALUs führen immer die gleichen Instruktionen? Das ist doch doof.
Ist im 3D Rendering nicht so arg.

[Gast]

Fudzi (http://www.fudzilla.com/index.php?option=com_content&task=view&id=838&Itemid=1) meint, der R65o soll schon im September kommen.

Ist da eurer Meinung was dran? Ich kanns mir nach den vielen Verspätungen dieses Jahr echt nicht vorstellen.

Naja, war doch beim R520 und R580 genauso. ATI scheint sich beim meistern eines Chips schwer zu tun, aber wenn er einmal läuft, dann läuft er auch.

Sind über den R650 schon eventuelle Spezifikationen bekannt bzw. was dort aufgebohrt wird? (also lediglich Takt, oder mehr Einheiten, wenn ja welche, etc.)

[Gmax]

Naja, war doch beim R520 und R580 genauso. ATI scheint sich beim meistern eines Chips schwer zu tun, aber wenn er einmal läuft, dann läuft er auch.

Sind über den R650 schon eventuelle Spezifikationen bekannt bzw. was dort aufgebohrt wird? (also lediglich Takt, oder mehr Einheiten, wenn ja welche, etc.)

Soweit ich weiß nur ein höherer Takt.

[Hvoralek]

Hier fehlt doch eine Folie: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=359698
Es gibt keine adäquate Folie des R600 zu der Folie, die in meinem vorherigen Posting zu sehen ist. :| Das wäre die Folie Nr. 5. Warum fehlt ausgerechnet sie?Was ist mit der hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5446543#post5446543)? Die ist doch auch in Deinem Sammelthread enthalten :confused:

Fudzi (http://www.fudzilla.com/index.php?option=com_content&task=view&id=838&Itemid=1) meint, der R65o soll schon im September kommen.

Ist da eurer Meinung was dran? Ich kanns mir nach den vielen Verspätungen dieses Jahr echt nicht vorstellen.Aus der Verspätung des R600 kann man nicht automatisch schließen, dass auch R650 sich so krass verspäten muss. Denke etwa an R520 und R580. Apropos R520: Inzwischen gibt es hier mehr Beiträge zum R600 (9*1000 + 1337 (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=4975480#post4975480) + 344) als zu R520 (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=145961&highlight=R520) (10462). Und auch die Verspätung gegenüber den ersten "Schätzungen" ist inzwischen minimal größer (Q1 2005 --> Okt. 2005 ./. Q3 2006 --> Mai 2007).

[deekey777]

Was ist mit der hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5446543#post5446543)? Die ist doch auch in dem Sammelthread enthalten :confused:


Das ist nur eine Vergrößerung des R600 aus der Folie mit der Nr. 3.
Ich meine wirklich eine Folie, wo steht so etwas wie:
ATI RADEON HD2900XT
320 Stream Processing Units
4/8/16 SIMDs
4 Texture Units
4 RBEs
Vielleicht ist die Folie mit der HD2600 bzw. HD2400 nur aus dem Grund im Internet aufgetaucht, damit der Eindruck entsteht, dass diese der Konkurrenz mächtig überlegen sind.

[Gast]

Das war, glaub ich, eher so gemeint, dass der G80 bei komplexen Berechnungen nicht mit dem R600 mithalten könnte. Der Flaschenhals liegt beim R600 bei "Unterbelastung" und beim G80 bei der "Überbelastung", wenn der R600 seine Rohleistung besser ausspielen kann.

Deswegen sind die Einheiten beim G80 doch so hochgetaktet, wenn mehr durchläufe fällig sind muss man halt die Einheiten höher takten oder mehr Dinge parallel bearbeiten. Effizienz ^^

[Gast]

Shaderleistung ist nicht alles.
Ja genau. Darum habe ich diesen Vergleich gepostet. Bitte auch den Kontext (s. das von mir zitierte) sehen.

Eine GTS hat immerhin nicht gerade unerhebliche Vorteile was TMU- und ROP-Leistung, etc. betrifft.
Trifft dann wohl auch ggü. R600 zu.

Bei einem R580 dürfte die Shaderleistung wohl so ziemlich das letzte sein, was limitiert.
Sollte man meinen, stimmt aber nicht immer. Trifft vermutlich dann wohl auch auf R600 zu.


Q

[Gast]

Welche meinst du speziell (gibt ja so viele verschiedene)? Und was soll mit denen sein?
Wurde ja gerade durch die Folie schon beantwortet. Die Frage war: Macros oder weniger Einheiten.


Q

[seahawk]

Fudzi (http://www.fudzilla.com/index.php?option=com_content&task=view&id=838&Itemid=1) meint, der R65o soll schon im September kommen.

Ist da eurer Meinung was dran? Ich kanns mir nach den vielen Verspätungen dieses Jahr echt nicht vorstellen.

Da man nichts über große Verspätungen des R650 hörte, ist das nicht völlig ausgeschlossen.

[Simon Moon]

Irgendwie scheint mir der R600 komisch.

Da ist zum einen ein 512Bit GDDR3 800Mhz Interface, welches 80% mehr Bandbreite hat, als der G80. Auf der Gegenseite sind jedoch "nur" 16TMUs, welche nur 30% der Füllrate der G80 bringen. Nun, ich als Laie dachte bisher immer, v.a. die Texturen bräuchten Bandbreite und die Shaderinstruktionen im Vergleich wesentlich weniger. Wieso hat dann der R600 soviel Bandbreite nötig?

[[MK2]Mythos]

Irgendwie scheint mir der R600 komisch.

Da ist zum einen ein 512Bit GDDR3 800Mhz Interface, welches 80% mehr Bandbreite hat, als der G80. Auf der Gegenseite sind jedoch "nur" 16TMUs, welche nur 30% der Füllrate der G80 bringen. Nun, ich als Laie dachte bisher immer, v.a. die Texturen bräuchten Bandbreite und die Shaderinstruktionen im Vergleich wesentlich weniger. Wieso hat dann der R600 soviel Bandbreite nötig?

Weil ATi wohl zu früh auf D3D10 und den Anstieg von Geometrie und Shaderberechnungen gesetzt hat.

[Gast]

Mythos;5467634']Weil ATi wohl zu früh auf D3D10 und den Anstieg von Geometrie und Shaderberechnungen gesetzt hat.

Das ist ja nun der genaue Gegensatz von dem, was Simon Moon ausgeführt hat... ???

[Gast]

Der Flaschenhals liegt beim R600 bei "Unterbelastung" und beim G80 bei der "Überbelastung", wenn der R600 seine Rohleistung besser ausspielen kann.

Hoe?
Der G80 hat bei den Recheneinheiten keinen "Flashenhals". Die Einheiten werden immer ausgelastet, daher genügen weniger Einheiten, die man höher takten kann. AMD benötigt für die gleiche Effizienz 2,5 - fache Menge an Einheiten!
Nur der r600 hat einen Flaschenhals, wenn seine Einheiten nicht zu mindesten 4/5 ausgelastet werden können. Dem g80 ist es egal, seine Einheiten sind immer voll dabei.

[Coda]

Ist im 3D Rendering nicht so arg.
Sobald dyn. branching ins Spiel kommt schon ;)

[Gast]

Hoe?
Der G80 hat bei den Recheneinheiten keinen "Flashenhals". Die Einheiten werden immer ausgelastet, daher genügen weniger Einheiten, die man höher takten kann. AMD benötigt für die gleiche Effizienz 2,5 - fache Menge an Einheiten!
Nur der r600 hat einen Flaschenhals, wenn seine Einheiten nicht zu mindesten 4/5 ausgelastet werden können. Dem g80 ist es egal, seine Einheiten sind immer voll dabei.

Das Wort "Flaschenhals" ist hier natürlich irreführend, da der G80, wie du schon sagtest, eigentlich keine Flaschenhälse hat. Was ich sagen wollte, war, dass der R600 eine höhere Rohleistung hat als der G80 (was die Shader betrifft!). Allerdings lastet der R600 seine Rohpower selten aus, vor allem bei vielen kleinen (abhängigen) Berechnungen dürfte der G80 locker vorbeiziehen. Bei komplexen Berechnungen, wo die Shader des R600 (fast) voll ausgelastet sind, wird der R600 den Vorteil haben. Das wurde aber glaube ich schon sehr oft hier gesagt.

[robbitop]

Sobald dyn. branching ins Spiel kommt schon ;)
Ich bin mal gespannt, wann das kommt ^^
Wobei eine 16er Granularitaet schon so schlecht nicht ist. Wenn man das noch weiter aufdroeseln wuerde, wuerden vermutlich die Kosten fuer Kontrolllogik den Nutzung an Mehrleistung mehr als auffressen. Ab diesem Punkt koennte man dann einfach Cluster duplizieren.

[deekey777]

Was schätzt ihr, wie groß die Threads/Batches beim R600 sein werden?

[robbitop]

Ich tippe auf 4 Quads, welche je ein SIMD bildet. Beim RV630 und RV610 weniger.

[Coda]

Ich bin mal gespannt, wann das kommt ^^
Wann was kommt? D3D10-Apps werden davon regen Gebrauch machen.

[IVN]

Ich tippe auf 4 Quads, welche je ein SIMD bildet. Beim RV630 und RV610 weniger.
D.h. der R600 muss bei einer falschen Vorhersage 80 Oprationen wegwerfen, während G80 das nur für 16 tun muss?

[Coda]

Bei G80 ist die Branch-Granularität 32 Pixel.

[deekey777]

D.h. der R600 muss bei einer falschen Vorhersage 80 Operationen wegwerfen, während G80 das nur für 16 tun muss?
Eigentlich 16 wie beim G80.
Rein folienmäßig sind es keine 80 Instructions, sondern 5*16.:|

[IVN]

Bei G80 ist die Branch-Granularität 32 Pixel.
Also, für dyn. Bran. werden zwei ALUs als eine angesehn?

[robbitop]

Naja die MAD ALU und die MUL ALU wohl. (sind ja jeweils 2x Vec8).

[deekey777]

Ergibt das irgendeinen Sinn?
http://img249.imageshack.us/img249/5012/sinntg1.jpg
http://img145.imageshack.us/img145/4201/sinn2xo8.jpg

[Gast]

Ergibt das irgendeinen Sinn?

Nein, Bilder ohne Text ergeben selten Sinn. Vielleicht schreibst du einen Satz dazu?

[Coda]

Naja die MAD ALU und die MUL ALU wohl. (sind ja jeweils 2x Vec8).
Die MAD/MUL-Einheiten werden ja durch das selbe VLIW angesprochen, warum sollte das die Branch-Granularität aufblasen?

[Nakai]

Stromverbrauch R600:

ATI Radeon HD 2900 XT 1024MB DDR4 TDP:
GPU: 180 Watt
Board: 225 Watt

ATI Radeon HD 2900 XT 512MB DDR3 TDP:
GPU: 160 Watt
Board: 225 Watt

ATI Radeon HD 2900XL 512MB DDR3 TDP:
GPU: 130 Watt
Board: 205 Watt

mfg Nakai

[Super Grobi]

Was bedeutet "Board"? Ist das dann der Stromverbrauch der Karte OHNE das "Restsystem"?

Gruss
SG

[dargo]

Was soll das mit dem Board? :)

[Nakai]

Wahrscheinlich die angegebene TDP, GPU könnte dann der eigentliche Verbrauch sein.

mfg Nakai

[boxleitnerb]

Ich schätze mal, damit meint er die ganze Karte inkl. Speicher, Spannungswandlern und dem PCB :)

[Gast]

Naja, das sollte doch dann -sollte es die gleiche Testplattform sein- im selbe Rahmens ein.
Dort ists aber einmal 35, 65 und 75 Watt Unterschied.
Von daher könnte das schon die TDP sein, macht in dem Fall mehr Sinn.

[Gast]

Ich schätze mal, damit meint er die ganze Karte inkl. Speicher, Spannungswandlern und dem PCB :)

Unlogisch. Warum sollte der "Rest" der XT 512 mehr verbrauchen als die der XT 1024? Das müsste doch genau anders herum sein. Außerdem sind 65 Watt (bei der XL sind das etwa 33%) für Speicher+Spannungswandler etwas hoch gegriffen.

[Gast]

Edit: Sorry, wenn die 1024MB-Version GDDR4-RAM hat, könnte das natürlich was ausmachen. Trotzdem wäre der Restverbrauch immer noch viel zu hoch gegriffen. TDP vs. realer Verbrauch macht da wirklich mehr Sinn.

[w0mbat]

Stromverbrauch R600:

ATI Radeon HD 2900 XT 1024MB DDR4 TDP:
GPU: 180 Watt
Board: 225 Watt

ATI Radeon HD 2900 XT 512MB DDR3 TDP:
GPU: 160 Watt
Board: 225 Watt

ATI Radeon HD 2900XL 512MB DDR3 TDP:
GPU: 130 Watt
Board: 205 Watt

mfg Nakai

These values can vary with different clock speeds :tongue:

[Nakai]

lol...;D

mfg Nakai

€: Sry das ich es benutzen musste, mir geht aber das rumgerate mit dem Stromverbrauch auf die Nerven...^^

[w0mbat]

Solange du das Bild nicht selber postest ist es mir ziemlich egal.

[Gast]

Warum gibst du nicht die Quelle an?
http://forum.beyond3d.com/showpost.php?p=982180&postcount=4547

Auch sollte man da vorsichtig sein, da kaotik es mit " this should be" einleitet.
Rein ins blaue: 160 Watt alleine für die GPU wäre ein ziemlich großer Batzen - nur unwesentlich mehr verbraucht eine GTX Karte nach nVidia TDP Vorgaben...

[w0mbat]

Warum gibst du nicht die Quelle an?
http://forum.beyond3d.com/showpost.php?p=982180&postcount=4547

Auch sollte man da vorsichtig sein, da kaotik es mit " this should be" einleitet.
Rein ins blaue: 160 Watt alleine für die GPU wäre ein ziemlich großer Batzen - nur unwesentlich mehr verbraucht eine GTX Karte nach nVidia TDP Vorgaben...

Lol, das ist nicht die Quelle. Die Quelle aus der Nakai zitiert ist über 1 Woche alt.

[Nakai]

Nur das meine Quelle authentischer ist...

mfg Nakai

[Gast]

Aus meiner Sicht ist dein zweites Ich nicht authentischer als das Bild - Hallo Wombat... :wink:
Dann sage doch, wer deine Quelle war. Oder hast du wieder das Forum mit dem LuxxForum verwechselt?

[deekey777]

Aus meiner Sicht ist dein zweites Ich nicht authentischer als das Bild - Hallo Wombat... :wink:
Dann sage doch, wer deine Quelle war. Oder hast du wieder das Forum mit dem LuxxForum verwechselt?
Ist es nicht egal, was die Quelle ist, so lange die Daten echt sind?

[w0mbat]

Ist es nicht egal, was die Quelle ist, so lange die Daten echt sind?

QFT

Und jetzt B2T!

[robbitop]

Die MAD/MUL-Einheiten werden ja durch das selbe VLIW angesprochen, warum sollte das die Branch-Granularität aufblasen?
sry brainart

[Gast]

Welches NT (Wattangabe) mit welchen Ampere Werten muss man besutzen um eine HD 2900 XT stabil zum Laufen zu bringen (vorausgesetzt die Werte stimmen)
Das mit dem 500 Watt NT habe ich schon gehört, kann es aber auch ein 400-er richten?

[Gast]

Ist es nicht egal, was die Quelle ist, so lange die Daten echt sind?

Ohne Quellenangaben sind die Daten nicht echt.
Im beyond3d.com Forum ist ein Bild mit den selben Werten aufgetaucht. Nakai dagegen gibt seine Quelle nicht an - die wahrscheinlich auf das gleiche Bild geschiehlt hat.

[kruemelmonster]

Das kommt ganz darauf an ob man NoName Schrott wie LC Power (oder schlimmeres) drin hat oder was vernünftiges wie Enermax etc. Mit meinem be quiet Dark Power Pro 430 sehe ich der Graka-Zukunft jedenfalls entspannt entgegen.

Btw,
AMD-based system was configured like follows:

* Two Athlon 64 FX-74 3.0GHz CPUs
* Two Foxconn GeForce 8800GTX graphics cards in SLI mode
* ASUS L1N64-SLI WS mainboard (Dual Socket 1207, NVIDIA nForce 680a SLI)
* 2GB DDR2-800 SDRAM (Mushkin XP2-6400PRO, 4 x 512MB)
* Two Western Digital WD1500AHFD hard disk drives in a RAID0
* Various trifles like a DVD-ROM, fans, etc

Intel-based system:

* Quad-core Core 2 Extreme QX6700 CPU (Kentsfield) overclocked to 3.5GHz
* Two Foxconn GeForce 8800GTX graphics cards in SLI mode
* ASUS Striker Extreme mainboard (LGA775, NVIDIA nForce 680i SLI)
* 2GB DDR2-800 SDRAM (Mushkin XP2-6400PRO, 4 x 512MB)
* Two Western Digital WD1500AHFD hard disk drives in a RAID0
* Various trifles like a DVD-ROM, fans, etc

http://www.xbitlabs.com/images/other/1000w-psu-roundup/p1.png


Quelle (http://www.xbitlabs.com/articles/other/display/1000w-psu-roundup.html)

[dargo]

Welches NT (Wattangabe) mit welchen Ampere Werten muss man besutzen um eine HD 2900 XT stabil zum Laufen zu bringen (vorausgesetzt die Werte stimmen)
Das mit dem 500 Watt NT habe ich schon gehört, kann es aber auch ein 400-er richten?
Im Prinzip ist es ganz einfach - vergiss die Wattangaben! Was zählt ist die combined 12V Power. Da die HD2900XT irgendwo zwischen 13 und 17A liegen wird kannst du dir selbst ausmalen welches NT du brauchen wirst. Mit einem C2D um die 3Ghz würde ich schon bei 29A combined 12V anfangen.

[Gast]

Welches NT (Wattangabe) mit welchen Ampere Werten muss man besutzen um eine HD 2900 XT stabil zum Laufen zu bringen (vorausgesetzt die Werte stimmen)
Das mit dem 500 Watt NT habe ich schon gehört, kann es aber auch ein 400-er richten?
Kommt auch auf den Hersteller und dein Gesamtsystem an. Mein Enermax Liberty mit 400 W betreibt eine 8800GTX, einen C2D mit 2600 Mhz, 4 Festplatten und zwei optische Laufwerke. Allerdings wird's dabei schon gut warm. Guter Belastungstest wäre Prime bei gleichzeitigem Laufen des ATi Tools evtl. noch etwas die Platten dabei stressen. Dann bist du bei Games auf jeden Fall auf der sicheren Seite.

[Nakai]

Ohne Quellenangaben sind die Daten nicht echt.
Im beyond3d.com Forum ist ein Bild mit den selben Werten aufgetaucht. Nakai dagegen gibt seine Quelle nicht an - die wahrscheinlich auf das gleiche Bild geschiehlt hat.

Niemals, ich würde immer Quellenangaben angeben, solange ich die Quelle nennen darf.
(wenn ich die Erlaubnis bekommen würde!)

Solange du das Bild nicht selber postest ist es mir ziemlich egal.

Wunderbar.

Vll trag ich noch was nach...;)

mfg Nakai

[Gast]

Niemals, ich würde immer Quellenangaben angeben, solange ich die Quelle nennen darf.
(wenn ich die Erlaubnis bekommen würde!)


Aha - die Erlaubnis zur Weitergabe von Informationen hast du, aber die Quelle zu nennen sei dir untersagt? Wie soll AMD den Weg zurückverfolgen?
Sind wir doch ehrlich: Deine Quelle hat in den Beyond3d.com Thread geschaut und dir die Werte gesagt.
Ach, poste doch bitte das Bild. Sollte ja kein Problem sein - oder hat deine Quelle lauter Wasserzeichen reingemalt?

[sulak]

Die Werte sagen doch rein gar nichts aus, außer das was schon bekannt ist an TDP angaben. Und die sind ja nichtssagend wie man auch am G80 erkennt. 177Watt TDP aber unter Last haste vieleicht maximal 140Watt gemessen.

Abwarten bis echte Zahlen raus sind, am besten Crossfire System vs. Single Card System. Dann hat mans auf ~10Watt genau was eine Karte "brauch".

[Nakai]

Aha - die Erlaubnis zur Weitergabe von Informationen hast du, aber die Quelle zu nennen sei dir untersagt? Wie soll AMD den Weg zurückverfolgen?
Sind wir doch ehrlich: Deine Quelle hat in den Beyond3d.com Thread geschaut und dir die Werte gesagt.
Ach, poste doch bitte das Bild. Sollte ja kein Problem sein - oder hat deine Quelle lauter Wasserzeichen reingemalt?

Nein, wenn dann andersrum. Der Typ von B3D hat von diesen Infos eine eigene Meldung fabriziert.


Hat er auch das?

ATI Radeon HD2000-series:

ATI Radeon HD2900XT 512MB DDR3, R600, 80Nm
ATI Radeon HD2900XL 512MB DDR3, R600, 80Nm
ATI Radeon HD2900PRO 512MB DDR3, RV670, 65Nm

ATI Radeon HD2600XT 512MB DDR4, RV630, 65Nm
ATI Radeon HD2600XT 512MB DDR3, RV630, 65Nm
ATI Radeon HD2600XT 256MB DDR3, RV630, 65Nm
ATI Radeon HD2600PRO 256MB DDR3, RV630, 65Nm

ATI Radeon HD2400XT 256MB DDR2, RV610, 65Nm
ATI Radeon HD2400PRO 256MB DDR2, Rv610, 65Nm
ATI Radeon HD2400PRO 128MB DDR2, RV610, 65Nm

NDA for complete ATI Radeon HD2000 Series product list ends May 14th, 2007 15:00h CET, excluded ATI Radeon HD2900PRO.

[andererGast]

Was ist daran neu? Das ist doch schon seit Wochen, wenn nicht Monaten bekannt.

[Gast]

Wir werden sehen, ob wir am Montag eine 2900XL sehen werden.
Komisch nur, dass du die einzige Quelle kennst, die von einer XL spricht. Scheint wohl als einziger eine Karte bekommen zu haben...

[Nakai]

Naja ich glaube es sehr...

mfg Nakai

[Gast]

Warum gibst du nicht die Quelle an?
http://forum.beyond3d.com/showpost.php?p=982180&postcount=4547

Entweder alt oder falsch.

[deekey777]

Aha - die Erlaubnis zur Weitergabe von Informationen hast du, aber die Quelle zu nennen sei dir untersagt? Wie soll AMD den Weg zurückverfolgen?
Sind wir doch ehrlich: Deine Quelle hat in den Beyond3d.com Thread geschaut und dir die Werte gesagt.
Ach, poste doch bitte das Bild. Sollte ja kein Problem sein - oder hat deine Quelle lauter Wasserzeichen reingemalt?
Fühlst du dich dann irgendwie besser?

[AnarchX]

Hat er auch das?

ATI Radeon HD2000-series:

ATI Radeon HD2900XT 512MB DDR3, R600, 80Nm
ATI Radeon HD2900XL 512MB DDR3, R600, 80Nm
ATI Radeon HD2900PRO 512MB DDR3, RV670, 65Nm

ATI Radeon HD2600XT 512MB DDR4, RV630, 65Nm
ATI Radeon HD2600XT 512MB DDR3, RV630, 65Nm
ATI Radeon HD2600XT 256MB DDR3, RV630, 65Nm
ATI Radeon HD2600PRO 256MB DDR3, RV630, 65Nm

ATI Radeon HD2400XT 256MB DDR2, RV610, 65Nm
ATI Radeon HD2400PRO 256MB DDR2, Rv610, 65Nm
ATI Radeon HD2400PRO 128MB DDR2, RV610, 65Nm

NDA for complete ATI Radeon HD2000 Series product list ends May 14th, 2007 15:00h CET, excluded ATI Radeon HD2900PRO.

Und wo ist die HD 2600XT 256MB GDDR4? ;)

Zudem ist es auch fraglich, warum man Karten am 14. vorstellen sollte, die optimistisch vielleicht erst einen Monat später erhältlich sind.

btw.
Unknown VGA @ 885/1000MHz Stock-Kühler
http://img440.imageshack.us/img440/2783/06b3daa9rv4.jpg
http://we.pcinlife.com/thread-760129-3-1.html

[Gast]

Was hat eine 8800 gtx @stock mit der gleichen CPU? Wo gibt's denn dieses 3D Mark 06 "Rechner"?

[AnarchX]

Was hat eine 8800 gtx @stock mit der gleichen CPU?
Imo sollte die GTX bei SM2.0 gleich oder besser(edit: scheint wohl doch minimal langsamer zu sein) sein und bei SM3/HDR etwas langsamer.


Wo gibt's denn dieses 3D Mark 06 "Rechner"?
http://www.xtremesystems.org/forums/showthread.php?t=102058

[dildo4u]

Was hat eine 8800 gtx @stock mit der gleichen CPU? Wo gibt's denn dieses 3D Mark 06 "Rechner"?
Warum sollte man eine OC 2900XT denn mit einer 8800GTX@ Stock vergleichen?

[deekey777]

Was soll das mit dem Board? :)
Keine Ahnung, aber es ist nicht nur der Chip, der gekühlt werden will, sondern jedes kritische Bauteil (sprich Kühlkörper auf Speicher, Rückseite oder ähnlich). Diese 225 W TDP ist wohl die gesamte maximale Wärmeabgabe, die irgendwie abgefangen werden muss.
Viel interessanter finde ich den Unterschied zwischen den Chips der GDDR3- und der GDDR4-Versionen.

[Gast]

dildo4u: es interessiert mich halt

[dargo]

Viel interessanter finde ich den Unterschied zwischen den Chips der GDDR3- und der GDDR4-Versionen.
Was ist denn daran interessant :confused:

[dildo4u]

dildo4u: es interessiert mich halt
Ich hab eine Weile gesucht gibt halt nich so viele die einen Quad Core@ 3.8GHz betreiben deshalb hier ein QuadCore@3.5GHZ und einer 8800GTX@Stock.

http://service.futuremark.com/compare?3dm06=1233285

[deekey777]

Was ist denn daran interessant :confused:
160 W gegen 180 W?

[dargo]

160 W gegen 180 W?
Vierschiedene Revisionen?

Edit:
Oder einfach :
HD2900XT 512MB = ~750Mhz Core-Clock
HD2900XT 1GB = ~800Mhz Core-Clock

oder so ähnlich ...

[AnarchX]

Ich hab eine Weile gesucht gibt halt nich so viele die einen Quad Core@ 3.8GHz betreiben deshalb hier ein QuadCore@3.5GHZ und einer 8800GTX@Stock.

http://service.futuremark.com/compare?3dm06=1233285

Stock?
Da beide Grafik-Scores über 6000 sind zweifel ich mal daran.

Vierschiedene Revisionen?

Darauf würde ich auch tippen, immerhin wurde ja berichtet, dass dieses OEM-GDDR4-Monster eine ältere Revision verwendet.

[dildo4u]

Stock?
Da beide Grafik-Scores über 6000 sind zweifel ich mal daran.


Wegen der Bemerkung in der Beschreibung.

"Description:When oh when will 8800 oc come along in Vista!"

[Gast]

Ich hab eine Weile gesucht gibt halt nich so viele die einen Quad Core@ 3.8GHz betreiben deshalb hier ein QuadCore@3.5GHZ und einer 8800GTX@Stock.

http://service.futuremark.com/compare?3dm06=1233285
Darum wollte Er sicher den Rechner haben ;)

Mit nem 3,8 GHz würde der aus deinem Link auf 15199 gehen

[Gast]

Neuer Treiber für die HD2900 XT welche sie ca. 5 bis etwas mehr % schneller macht und die GTX wird bei 2 Games bereits getoppt. Bei anderen sollte sie knapp darunter zu liegen kommen. Zu einem Launchpreis von 350-360 Euro durchaus akzeptabel. Der Preis wird aber bald die 350 Euro Marke unterschreiten, so meine Annahme. Und für Crysis reicht die Karte locker.

Link:
8.374 is the new R600 driver
The power of R600

http://www.fudzilla.com/index.php?op...844&Item id=1

Horn12

[Gast]

ATI Radeon HD2000-series:

:::
ATI Radeon HD2900PRO 512MB DDR3, RV670, 65Nm

:::
NDA for complete ATI Radeon HD2000 Series product list ends May 14th, 2007 15:00h CET, excluded ATI Radeon HD2900PRO.

Na sowas. RV670. Wann soll den der Chip kommen?

[Nakai]

Ein kleiner Zusatz, den hab ich nicht dazugeschrieben:

Upcoming ATI products

new ATI Radeon HD2950 series (R650, 65Nm) in Q3 2007

ATI Radeon HD2950XTX, 1024MB DDR4, R650, 65Nm
ATI Radeon HD2950XT, 512MB DDR4, R650, 65Nm

NDA extensions for complete ATI Radeon HD2950 series at Computex

D.h. der Rv670 kommt entweder vor oder ebenfalls bei der Computex.

mfg Nakai

[dildo4u]

Da steht aber was von Q3 2007 zu den High-End 65NM Produckten da kann der RV670 gar nicht zur Computex(Juni) kommen.

[StefanV]

Was soll das mit dem Board? :)
Board = PCB/Karte

Ist doch nicht soo schwer, eigentlich.

[laser114]

Da steht aber was von Q3 zu den High-End 65NM Produckten da kann der RV670 gar nicht zur Computex(Juni) kommen.

Sobald man die High-End-Sparte in 65 nm produzieren kann, sollte man es auch mit dem RV670 können.

Aber ich verstehe Nakais Gedankengang: Sonst würde AMD den RV670 sicher HD 2950 Pro nennen, wenn er erst mit dem R650 kommen würde.

[Nakai]

Ich distanziere mich zu diesen Infos, ich hab es nur abgeschrieben, bzw. teilweise abgeschrieben, also nicht alles.
Wenn es nicht so kommt wie es dort angegeben ist, werde ich keine Verantwortung übernehmen. Diese Infos sind etwa 10 Tage alt.

mfg Nakai

[w0mbat]

Leute, setzt nicht zu viel auf die Bezeichnungen bei Präsentationen von AMD/ATI, vor allem wenn sie nicht für die Öffentlichkeit bestimmt sind. Es gibt Slides, gar nicht mal so alt, auf denen X2000 series steht. Es gibt auch welche mit HD X2900 XT usw.

[AnarchX]

Infos? Naja, das sind eher Spekulationen die man ohne großes Wissen schnell mal zusammenstellen kann.

btw.

HD2950 MAXX 2048MB DDR4, 2xRV670, 65Nm

NDA will expire in October 2007. ;D

[Nakai]

Naja ich sagte selber, ich distanziere mich davon...;)

mfg Nakai

[Gast]

http://www.fudzilla.com/index.php?op...844&Item id=1


Splinter Cell und Carbon sind direkte Xbox360 Spiele, die auf Xenos optimiert sind. Wäre wirklich erbärmlich, wenn man in diesen Spielen nicht schneller wäre.
Dagegen wird man wohl in Spielen wie Oblivion und Gothic 3 kaum eine Chance haben, da hier nicht die reine Rechenleistung im Vordergrund steht.

Warum distanzierst du dich, nakai?
Wohin war deine "Quelle authentischer" als das Bild und jetzt?

[Nakai]

Ganz einfach weil es abgeschrieben ist. Ich kann nur sagen, dass diese "Infos" authentisch sind, jedoch älter. In der Zwischenzeit kann sich ja was geändert haben.

mfg Nakai

[deekey777]

Splinter Cell und Carbon sind direkte Xbox360 Spiele, die auf Xenos optimiert sind. Wäre wirklich erbärmlich, wenn man in diesen Spielen nicht schneller wäre.

Direkte Xbox360-Spiele? Und welchen Einfluss hat das auf die Performance des R600?

Und regle deine Probleme mit Nakai per PM/Rauchzeichen oder sonst wie, aber nicht in diesem Thread.

[Gast]

Direkte Xbox360-Spiele? Und welchen Einfluss hat das auf die Performance des R600?


Lass mich überlegen:
Eine Engine bzw. ein Spiel, das für eine Konsole entwickelt und 1:1 auf den PC umgesetzt wurde, wird natürlich nicht auf dem PC - Grafikchipabkömmling, der exakt den gleichen Recheneinheitenaufbau hat wie der Konsolen - Grafikchip, besser laufen als auf dem Konkurrenzprodukt, dessen Verhältnis zwischen Textur- und Rechenleistung nicht so unbalanciert ist.

[Coda]

Es ist aber bei weitem nicht der gleiche Recheneinheitenaufbau.

[Gast]

Es ist aber bei weitem nicht der gleiche Recheneinheitenaufbau.

Was unterscheidet den die Recheneinheiten der beiden "Architekturen"?
Zur Zeit scheint es so, dass das Xenos Design mit einigen, aus meiner Sicht kleinen, Änderungen übernommen und von den Einheiten erweitert wurde (8 zusätzliche ROPs, Tessalationseinheit, eine weitere "Vec16" Einheit, nen bissl mehr Cache). Dazu höhrere Taktraten und fertig ist die "second *hust* superscalar unified architekture".

[deekey777]

Lass mich überlegen:
Eine Engine bzw. ein Spiel, das für eine Konsole entwickelt und 1:1 auf den PC umgesetzt wurde, wird natürlich nicht auf dem PC - Grafikchipabkömmling, der exakt den gleichen Recheneinheitenaufbau hat wie der Konsolen - Grafikchip, besser laufen als auf dem Konkurrenzprodukt, dessen Verhältnis zwischen Textur- und Rechenleistung nicht so unbalanciert ist.

Aber natürlich...
Warum liegt die X1900 vor der 7950GT oder auch 7900GTX?
http://www.3dcenter.org/artikel/2006/12-31_a.php
Dass der R580 kein Abkömling des Xenos ist, kann man auch nicht annehmen, dass dieser von den "Opmierungen" des Xbox360-Version profitiert, insbesondere weil die Xbox360 kein Windows XP, keine Treiber, kein DX9, keinen Treiberoverhead usw kennt.

[Coda]

Was unterscheidet den die Recheneinheiten der beiden "Architekturen"?
Ziemlich viel. Xenos hatte 4:1 ALUs, bei R600 ist sogar ein 5-fach-Split möglich.

Das einzige was evtl. gleich ist, ist dass Xenos wirklich auch viel mehr Rechenleistung hat als Texturleistung. Aber G8x ist nun wirklich auch kein Kind von so unglaublich geringer Arithmetikleistung.

[reunion]

[...] dessen Verhältnis zwischen Textur- und Rechenleistung nicht so unbalanciert ist.

"Unbalanciert" - woran machst du das fest? Welches ALU:TEX-Verhältnis ist denn "ausgewogen"? ATi schafft es offensichtlich auch mit diesen "unbalancierten" Chip die Leistung im Vergleich zu R580 annähernd zu verdoppeln, und ein R580 schaffte dies auch im Vergleich zu einem R480, der ebenfalls 16bi Samples pro Takt filtern konnte genau wie R520/R580 und R600. Vielleicht haben sich einfach die Anforderungen der Spiele geändert, oder vielleicht oder besser gesagt höchstwahrscheinlich hat sich auch die Effektivität der Einheiten während dieser drei Generationen stark verbessert.

[dargo]

Board = PCB/Karte

Ist doch nicht soo schwer, eigentlich.
Nö, eigendlich nicht. Mich irritiert nur die enorme Verlustleistung der reinen GPUs. :eek:

[[MK2]Mythos]

Nö, eigendlich nicht. Mich irritiert nur die enorme Verlustleistung der reinen GPUs. :eek:

Du kannst es auch nicht lassen, oder? ;)

[reunion]

btw.
Unknown VGA @ 885/1000MHz Stock-Kühler
http://img440.imageshack.us/img440/2783/06b3daa9rv4.jpg
http://we.pcinlife.com/thread-760129-3-1.html

885Mhz mit Standardkühler zeigen jedenfalls schonmal, wohin der Hase läuft.

[Gast]

885Mhz mit Standardkühler zeigen jedenfalls schonmal, wohin der Hase läuft.
Schlechter vergleich Hasen schlagen oft haken da gibts immer aussreiser nach oben und unten;)

[deekey777]

Wenn sich ein bestimmter User weiterhin den Unwissenden spielt, werden seine Postings als Gast als Gastpostings behandelt und gelöscht.

[Gast]

885Mhz mit Standardkühler zeigen jedenfalls schonmal, wohin der Hase läuft.


Richtung 300W Stromverbrauch?

[Gast2]

Was soll das denn heißen? Unnötiger Kommentar, wie ich finde.

Immerhin hat der Gast recht. Die Karten die vor Release im Umlauf sind, sind meist gut selektierte Modelle... ich kann mich nicht daran erinnern, das diese Ergebnisse jemals zutrafen. 90 % aller Käufer werden sicher weit weniger Glück haben, egal ob CPU, RAM; GraKa.

[deekey777]

Ich weiß überhaupt nicht, warum man jubeln soll, dass eine Grafikkarte so viele Punkte erreicht. Das ist doch irrelevant.

[Gast]

Aber natürlich...
Warum liegt die X1900 vor der 7950GT oder auch 7900GTX?
http://www.3dcenter.org/artikel/2006/12-31_a.php
Dass der R580 kein Abkömling des Xenos ist, kann man auch nicht annehmen, dass dieser von den "Opmierungen" des Xbox360-Version profitiert, insbesondere weil die Xbox360 kein Windows XP, keine Treiber, kein DX9, keinen Treiberoverhead usw kennt.
Arithmetische Leistung und besseres Batching bei Multi-Core-CPUs.

[Gast]

885Mhz mit Standardkühler zeigen jedenfalls schonmal, wohin der Hase läuft.
Präselektiert.

[aehmkei]

Von Wombat eben im Forumdeluxx gepostet:

http://img457.imageshack.us/img457/1309/1177811939vh9.jpg

http://img457.imageshack.us/img457/729/1177811988np0.jpg

http://img457.imageshack.us/img457/1719/1177812078ix0.jpg

http://www.fx57.net/?p=637

[LovesuckZ]

Wenn sich ein bestimmter User weiterhin den Unwissenden spielt, werden seine Postings als Gast als Gastpostings behandelt und gelöscht.

Unwissend?
Du bist mir immer noch schuldig, warum denn Xenos die "first superscalar unified architectur" von ATi sein sollte, wenn diese doch nach ihnen nicht "superscalar" wäre.

[horn 12]

Also die HD 2900 XL mit nur einem Stromanschluss.:smile: :biggrin:
Bin äußerst auf die Performance dieser XL Karte gespannt und auf die tech. Daten dazu.:cool:

[deekey777]

Unwissend?
Du bist mir immer noch schuldig, warum denn Xenos die "first superscalar unified architectur" von ATi sein sollte, wenn diese doch nach ihnen nicht "superscalar" wäre.
Ich bin dir gar nichts schuldig und hör endlich auf, hier den Unwissenden zu spielen, es wurde alles erklärt.

[Gast]

Ich bin dir gar nichts schuldig und hör endlich auf, hier den Unwissenden zu spielen, es wurde alles erklärt.

Es wurde nichts geklärt - die Frage steht immer noch offen.
Die Verweise auf AMD's Marketingmaterial beachtest du nicht. Für dich zählt nur deine Definition einer "superscalaren" Architektur. Das AMD das Wort "superscalar" interpretiert ist offensichtlich. Dass sie den r600 als zweite Generation anpreisen, ist nicht so einfach zu verstehen.
Du kannst meine Posting noch so oft löschen, trotzdem bleibt die Ungewissheit, dass die Recheneinheiten des r600 eben nicht so splitbar sind wie es AMD sagt.

LovesuckZ

[Fetza]

Mich würde mal interessieren, warum die leute immer einen quadcore für 06er benches des r600 nehmen. Ich hätte gerne mal normale cd2 oder reine graka tests ohne den cpu teil. Quadcore benches sind doch müßig, das verfälscht den eigentlichen 06er bench.

Ich hoffe die glauben nicht tatsächlich, das es unbemerkt bleibt. Überhaupt sollte futuremark diese unsäglichen cpu tests mal aus dem eigentlich graka bench raushalten.

greetz

Es wurde nichts geklärt - die Frage steht immer noch offen.
Die Verweise auf AMD's Marketingmaterial beachtest du nicht. Für dich zählt nur deine Definition einer "superscalaren" Architektur. Das AMD das Wort "superscalar" interpretiert ist offensichtlich. Dass sie den r600 als zweite Generation anpreisen, ist nicht so einfach zu verstehen.
Du kannst meine Posting noch so oft löschen, trotzdem bleibt die Ungewissheit, dass die Recheneinheiten des r600 eben nicht so splitbar sind wie es AMD sagt.

LovesuckZ

Hast du angst, das man dich als bekennender nv-fanboy nicht ernstnimmt in so einer diskussion, oder warum logst du dich als gast ein? Bis zu dem eigentlichen release der karte könnten das alles auch noch fälschungen sein. Überhaupt könnte man erstmal warten bis die karte wirklich vorliegt.

greetz

[deekey777]

Es wurde nichts geklärt - die Frage steht immer noch offen.
Die Verweise auf AMD's Marketingmaterial beachtest du nicht. Für dich zählt nur deine Definition einer "superscalaren" Architektur. Das AMD das Wort "superscalar" interpretiert ist offensichtlich. Dass sie den r600 als zweite Generation anpreisen, ist nicht so einfach zu verstehen.
Du kannst meine Posting noch so oft löschen, trotzdem bleibt die Ungewissheit, dass die Recheneinheiten des r600 eben nicht so splitbar sind wie es AMD sagt.

LovesuckZ
Dann erklär du doch mal, was superskalar bedeutet.

Wie oft erwähnt nVidia eigentlich den NV2A oder den RSX in den Folien zu Desktop-Grafikkarten?
Edit: Und gerade die AMD-Folien deuten an, dass die ALUs des R600 splittbarer sind als die der vorherigen Chips.

[Gmax]

Kleiner Artikel zum R6oo:

http://it-review.net/index.php?option=com_content&task=view&id=1310&Itemid=1&limit=1&limitstart=0

[The_Invisible]

Mich würde mal interessieren, warum die leute immer einen quadcore für 06er benches des r600 nehmen. Ich hätte gerne mal normale cd2 oder reine graka tests ohne den cpu teil. Quadcore benches sind doch müßig, das verfälscht den eigentlichen 06er bench.

weil man so ca 1000 punkte mehr bekommt und der abstand zu der vorgängergeneration noch größer scheint

mfg

[deekey777]

Kleiner Artikel zum R6oo:

http://it-review.net/index.php?option=com_content&task=view&id=1310&Itemid=1&limit=1&limitstart=0
Was soll wieder die Tesselationseinheit des Xenos (Seite 2)?

[Coda]

Das frag ich mich auch. Xenos hat nichts dergleichen.

[Fetza]

weil man so ca 1000 punkte mehr bekommt und der abstand zu der vorgängergeneration noch größer scheint

mfg

jo genau, also das ist mir schon klar. Ich meinte mehr, ob sich leute wirklich dadurch blenden lassen? Kann ich mir irgendwie nicht vorstellen, schließlich ist der benchmark doch bekannt für seine multicore lastigkeit in den cpu szenen.

[deekey777]

jo genau, also das ist mir schon klar. Ich meinte mehr, ob sich leute wirklich dadurch blenden lassen? Kann ich mir irgendwie nicht vorstellen, schließlich ist der benchmark doch bekannt für seine multicore lastigkeit in den cpu szenen.
Dafür ist 3D 2006 zu wichtig, genaue wie 2005 oder 2003 und besonders 2001 davor.
Das frag ich mich auch. Xenos hat nichts dergleichen.
Der Anfang des Übels ist wohl dieses Bild:
http://img241.imageshack.us/img241/3841/66666kk4.jpg
Da steht was von "dynamic geometry acceleration".
Gelästert wurde darüber ab hier: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5434772#post5434772

[Hvoralek]

Irgendwie scheint mir der R600 komisch.

Da ist zum einen ein 512Bit GDDR3 800Mhz Interface, welches 80% mehr Bandbreite hat, als der G80. Auf der Gegenseite sind jedoch "nur" 16TMUs, welche nur 30% der Füllrate der G80 bringen. Nun, ich als Laie dachte bisher immer, v.a. die Texturen bräuchten Bandbreite und die Shaderinstruktionen im Vergleich wesentlich weniger. Wieso hat dann der R600 soviel Bandbreite nötig?Bandbreite ist noch eher für den Backbuffer wichtig als für TMUs. Wie viel genau wofür benötigt wird, hängt natürlich von den genauen Umständen ab (Texturgröße, AA). Ob man ~140 GiB/s wirklich sinnvoll nutzen kann bei der knappen Filterleistung und anscheinend "nur" bis zu 8x MSAA, scheint mir aber wirklich. Naja, ein paar Prozent wird es schon bringen und immerhin hat man so genug Reserven für einen 64- bit- Framebuffer und größere Texturen.

[deekey777]

Es ist denkbar, dass man beim R600 mehr als 8xMSAA haben wollte, dies aber nicht geklappt hat (Probleme bei den ROPs, die nur zwei Loops zuließen oder ähnlich). Also ist man bei 8xMSAA sitzen geblieben - wie auch mit 512-bit-SI.

[Gmax]

Der Anfang des Übels ist wohl dieses Bild:
http://img241.imageshack.us/img241/3841/66666kk4.jpg
Da steht was von "dynamic geometry acceleration".
[/url]

Findet man einen Hinweis in den Folien dazu? Was soll das überhaupt sein?

[deekey777]

Findet man einen Hinweis in den Folien dazu? Was soll das überhaupt sein?
Nein, aber gehofft, dass dieses Bild hier nicht gepostet wird.

Superskalare USA. Wow. Das hat der G80 auch. Und die Recheneinheiten meiner X1950GT sind auch superskalar.
Was für "24x Custom Filter AA"? Was für Filter? Blur?
Dynamic geometry acceleration? Was soll das denn sein?
Und Black Box von VALVe...
Ich tippe auf Fake, wäre nicht das erste Mal.
Bereits die R300 ALUs arbeiten superskalar.
Ich tippe auf CF-AA pro Karte oder Hybriden wie bei NV.
Vertexshader im USC ;) (passen sich ja dynamisch der Last an)
Das ist jetzt nicht dein Ernst? Ich dachte eher an die auferstandene Tesselationseinheit. ;D

Eine Tesslationseinheit ist in D3D10 nicht vorgesehen. Also Verschwendung von Transistoren. Da man von dynamischer Geometriebeschleunigung redet, gehe ich davon aus, dass man die Eigenheit von Unified Shader Cores meint. ;) (PR Gelaber halt)
PR-Gelabber...
Auch diese 1:1:1:1:1-Splittung ist noch nicht klar.
Man darf nicht vergessen: Die Folien zum R580 sprachen auch was von 12 "Ultra Threading Dispatch Processors", obwohl es nur vier waren.

[Gmax]

Ah, alles klar, danke:up:

[seahawk]

Es ist denkbar, dass man beim R600 mehr als 8xMSAA haben wollte, dies aber nicht geklappt hat (Probleme bei den ROPs, die nur zwei Loops zuließen oder ähnlich). Also ist man bei 8xMSAA sitzen geblieben - wie auch mit 512-bit-SI.

512Bit machen durchaus Sinn, wenn man mit 256Bit nicht mehr auskommt und einen Chip hat bei dem man die Speicheranbindung nicht so einfach verändenr kann, was bei ienem Ringbus eben der Fall ist.

[Henroldus]

PR-Gelabber...
Auch diese 1:1:1:1:1-Splittung ist noch nicht klar.
Man darf nicht vergessen: Die Folien zum R580 sprachen auch was von 12 "Ultra Threading Dispatch Processors", obwohl es nur vier waren.
aber gerade diese 12 war doch der Unterschied zum R520 wodurch die shaderleistung ordentlich erhöht wurde(3x).

[deekey777]

aber gerade diese 12 war doch der Unterschied zum R520 wodurch die shaderleistung ordentlich erhöht wurde(3x).
Du meinst die anderen 12. Die zwölf, die ich meine, waren eigentlich vier. Kompliziert, oder?:biggrin:
http://www.beyond3d.com/content/reviews/2/3

[PCGH_Carsten]

Edit: Und gerade die AMD-Folien deuten an, dass die ALUs des R600 splittbarer sind als die der vorherigen Chips.

Hypothetische Frage: Wären sie dazu nicht unabhängig von den Fähigkeiten der Hardware gezwungen, nachdem Nvidia seit ~6 Monaten solch einen Rummel um Skalar-Prozessoren macht?

[seahawk]

Und rechnet nicht jeder dieser Prozessoren im VEC5 Fall genau eine Instruktion ? 1+1+1+1+1

Kann man daraus folgern, dass eine Vec 3 und eine Vec 2 auch als 1+1+1+1+1

und nicht als

1+1+1+0+0
1+1+0+0+0

abgearbeitet werden ?

Carsten spricht den Hauptpunkt an imho.

[Godmode]

Und rechnet nicht jeder dieser Prozessoren im VEC5 Fall genau eine Instruktion ? 1+1+1+1+1

Kann man daraus folgern, dass eine Vec 3 und eine Vec 2 auch als 1+1+1+1+1

und nicht als

1+1+1+0+0
1+1+0+0+0

abgearbeitet werden ?

Carsten spricht den Hauptpunkt an imho.

IMHO ist das optimale Aufteilen oder Zusammenfassen der Berechnungen arbeit des Shadercompilers (SC) und je besser dieser arbeitet, desto beser kann die Hardware ausgelastet werden. Für Nvidia war der SC seit NV3x ein wichtiges Instrument um die Hardware bestmöglichst auszunützen, vor allem wegen den nicht nebenläufigen TMUs. Ich denke ATI wird wohl ein ähnliches Tool verwenden wie Nvidia.

Im Hinblick auf den G80 kann man nun schwer sagen ob der SC an Wichtigkeit verloren hat. Eventuell ist er einfacher geworden, da eben jetzt mit Skalaren gearbeitet wird und nicht mehr mit Vektoren. Was ich nicht weis ist, ob das Sheduling in Hardware gegossen ist, oder ob da auch noch Software in Form des Treibers beteiligt ist?

[|MatMan|]

Im Hinblick auf den G80 kann man nun schwer sagen ob der SC an Wichtigkeit verloren hat. Eventuell ist er einfacher geworden, da eben jetzt mit Skalaren gearbeitet wird und nicht mehr mit Vektoren. Was ich nicht weis ist, ob das Sheduling in Hardware gegossen ist, oder ob da auch noch Software in Form des Treibers beteiligt ist?
Ich glaube kaum, dass der SC an Bedeutung verloren hat, ok vielleicht etwas im Vergleich zu den Vorgängern, besonders NV3x.

Der G80 ist noch lange nicht der heilige Grahl. Wenn sich nur mal ein wenig anschaut, wie man das Ding mit CUDA zu programmieren hat, merkt man doch recht schnell, dass man etwas Aufwand treiben muss um nahe an die Peak Leistung zu kommen (mein Eindruck nachdem ich ein paar Artikel über CUDA gelesen habe) => da ist sicherlich noch etwas Potential im SC IMO

Beim R600 ist es sicher ähnlich. Ich glaube kaum, dass wir so schnell eine GPU haben, wo die Hardware direkt mit "unoptimiertem" Code super zurecht kommt.

[Coda]

Bei CUDA ist die GPU ja auch nicht auf ihrem Terrain. Man versucht damit "normalen Code" auf einem Streamprozessor bearbeiten zu lassen. Das man dabei einiges an Verrenkungen veranstalten muss ist nichts neues.

Normalen Shadercode mag die GPU natürlich viel lieber.

[robbitop]

"Unbalanciert" - woran machst du das fest? Welches ALU:TEX-Verhältnis ist denn "ausgewogen"? ATi schafft es offensichtlich auch mit diesen "unbalancierten" Chip die Leistung im Vergleich zu R580 annähernd zu verdoppeln, und ein R580 schaffte dies auch im Vergleich zu einem R480, der ebenfalls 16bi Samples pro Takt filtern konnte genau wie R520/R580 und R600. Vielleicht haben sich einfach die Anforderungen der Spiele geändert, oder vielleicht oder besser gesagt höchstwahrscheinlich hat sich auch die Effektivität der Einheiten während dieser drei Generationen stark verbessert.
Ich vermute, dass R600 auch wieder Filteroptimierungen in Anspruch nehmen muss. Wenn das AI wieder so flimmert, wie beim R580, braucht man sich nicht zu wundern, wenn die Journalisten nach und nach das AI deaktivieren.

[Coda]

Na, das hoffe ich doch ganz stark. Mit der X1xxx konnte man sich das ja noch leisten, aber gegen G8x nicht.

[|MatMan|]

Bei CUDA ist die GPU ja auch nicht auf ihrem Terrain. Man versucht damit "normalen Code" auf einem Streamprozessor bearbeiten zu lassen. Das man dabei einiges an Verrenkungen veranstalten muss ist nichts neues.

Normalen Shadercode mag die GPU natürlich viel lieber.
Ja klar ist normaler Shadercode der GPU lieber, dafür wurde sie ja primär gebaut. Mein Vergleich mit CUDA sollte ja eher in die Richtung zielen, dass die nVidia Treiberentwickler mit den gleichen Limitationen arbeiten müssen, wie sie auch in der CUDA Doku beschrieben sind (auch wenn die noch näher an der GPU programmieren können), aber vielleicht passt der Vergleich mit CUDA auch überhaupt nicht.

Was ist eigentlich "normaler" Shadercode? :tongue:
Der Folding@Home GPU-Client ist auch "normaler" DX9 Shadercode (jedenfalls ist er standardkonform), läuft aber wegen SC Probleme immernoch nicht auf nVidia Karten (<= G7x sind es wohl auch Hardwarelimitationen)...

Mal sehen ob F@H gleich zum Launch auf dem R600 läuft. :wink:

[Coda]

Der Folding@Home GPU-Client ist auch "normaler" DX9 Shadercode (jedenfalls ist er standardkonform)
Sicher? Ist das kein CTM?

läuft aber wegen SC Probleme immernoch nicht auf nVidia Karten (<= G7x sind es wohl auch Hardwarelimitationen)...
NV4x kann gleich viel wie G7x.

[Moralelastix]

Warum braucht NV so lange um dieses Problem in CUDA und FAH zu lösen?

[Coda]

Wer sagt denn das sie es überhaupt probieren? Mit CUDA ist das definitiv kein Problem.

[Moralelastix]

DK777 hat gesagt es sei ein Problem in CUDA.

Hat also einfach nur kein Programmierer Bock auf FAH @ CUDA?

[James Ryan]

Ich vermute, dass R600 auch wieder Filteroptimierungen in Anspruch nehmen muss. Wenn das AI wieder so flimmert, wie beim R580, braucht man sich nicht zu wundern, wenn die Journalisten nach und nach das AI deaktivieren.

Sollten beim R600-Treiber die wirklich sinnvollen Spiele-Optimierungen wieder am AI gebunden sein, grenzt das dann schon an Frechheit!
Ich hoffe inständig, dass wenn ATi mit dem AI-Murks so weiter macht, sie vom Kunden abgestraft werden.

MfG :cool:

[AnarchX]

VR-Zone scheint wohl schon einen Test vorzubereiten:
http://www.vr-zone.com/?i=4946&s=1

"UnReal Overclocking!" :D

[Henroldus]

VR-Zone scheint wohl schon einen Test vorzubereiten:
http://www.vr-zone.com/?i=4946&s=1

"UnReal Overclocking!" :D
wie findest du denn sowas?
musst du nicht studieren? :biggrin:

[AnarchX]

wie findest du denn sowas?
musst du nicht studieren? :biggrin:

Wer sagt, dass ich es gesucht/gefunden habe. ;)

[Henroldus]

Wer sagt, dass ich es gesucht/gefunden habe. ;)
ja weil es nicht im offiziellen review-index bei vr-zone zu sehen ist.
alle zahlen durchprobiert?

[AnarchX]

ja weil es nicht im offiziellen review-index bei vr-zonre zu sehen ist.
alle zahlen durchprobiert?

Ganz sicher nicht... ;D
Man muss einfach nur wissen, wo ab und zu mal ein paar neue Informationen gepostet werden ....;) (http://forum.beyond3d.com/showpost.php?p=982621&postcount=4626)

Naja, immerhin wissen wir jetzt das HD2400/2600 auch am 14. gelauncht werden, wenn auch sie wohl min. einen Monat später erhältlich sind.

[Nakai]

Das angegebene Datum find ich immer noch das beste....lol 1970^^

mfg Nakai

[Coda]

Ja wirklich äußerst witzig :rolleyes:

http://en.wikipedia.org/wiki/Unix_time

[Nakai]

Ich kenn das schon, finde es aber interessant, dass es bei sehr vielen Dingen vorkommt.

mfg Nakai

[|MatMan|]

Sicher? Ist das kein CTM?
aus einem Thread zum G80 im F@H Forum:
mhouston: (http://forum.folding-community.org/viewtopic.php?p=157525&highlight=#157525)
"Talk to Nvidia. The core is vanilla dx9 code, and it is reported driver bugs preventing things from running."

und mhouston: (http://forum.folding-community.org/viewtopic.php?p=157962&highlight=#157962)
"their compiler optimizers have never seen code like we give them. Optimizations that might be safe for games, are not safe for us. Also, are shaders are quite a bit larger than your average game. ATI has had working drivers for quite awhile now, it's an issue of them continuing to work. I have a feeling the same is going to happen with Nvidia. We need to have a robust regression test that they can run along side their gaming tests."

NV4x kann gleich viel wie G7x.
Ich meinte dass G7x und alle Vorgänger wohl Hardwarelimitation(en) haben, welche den F@H Cleint gar nicht laufen lassen (evtl. max. Shaderlänge) oder nur extrem langsam (evtl. Tempregister).

[reunion]

Hypothetische Frage: Wären sie dazu nicht unabhängig von den Fähigkeiten der Hardware gezwungen, nachdem Nvidia seit ~6 Monaten solch einen Rummel um Skalar-Prozessoren macht?

Damit könnte man argumentieren, wenn es auf den Folien irgendwelche wagen Formulierungen gäbe, doch die Aussagen auf beiden Folien zu den Shadereinheiten sind mehr als eindeutig. Wenn dort also nicht bewusst die Unwahrheit gesagt wird, dann ist ein 1:1:1:1:1-Split möglich.

[micki]

Normalen Shadercode mag die GPU natürlich viel lieber.dafuer mag cuda die GPU lieber als normaler shadercode die gpu mag, deswegen sind viele dinge mit cuda um einiges fixer.

[reunion]

Ich vermute, dass R600 auch wieder Filteroptimierungen in Anspruch nehmen muss. Wenn das AI wieder so flimmert, wie beim R580, braucht man sich nicht zu wundern, wenn die Journalisten nach und nach das AI deaktivieren.

Auch bei G80 ist die default Treibereinstellung AFAIK "Quality", und damit bri-Filterung. Was ATi allerdings natürlich dringend machen muss, ist AI von den anderen Optimierungen zu entkoppeltn, denn sonst wird man bei dem ein- oder anderen Test blöd aus der Wäsche schauen. Aber so schlau wird wohl auch ATi sein, die Filterqualität von G80 ist ja nicht gerade ein unbeschriebenes Blatt.

[Coda]

Ich meinte dass G7x und alle Vorgänger wohl Hardwarelimitation(en) haben, welche den F@H Cleint gar nicht laufen lassen (evtl. max. Shaderlänge) oder nur extrem langsam (evtl. Tempregister).
Die Shaderlänge ist seit NV3x schon unbegrenzt. Letzteres kann aber gut sein.

Auch bei G80 ist die default Treibereinstellung AFAIK "Quality", und damit bri-Filterung.
Es flimmert aber nix.

[reunion]

Naja, immerhin wissen wir jetzt das HD2400/2600 auch am 14. gelauncht werden, wenn auch sie wohl min. einen Monat später erhältlich sind.

Und offensichtlich auch die Mobility-Chips.

Es flimmert aber nix.

Bei mir auch nicht.

[Coda]

Bei mir auch nicht.
Ich hatte eine X1800XT und da hat AI merklich geflimmert. Und zwar schlimmer als G7x HQ.

[Gast]

Ich hatte eine X1800XT und da hat AI merklich geflimmert. Und zwar schlimmer als G7x HQ.Ja, AI-Standard auf R5x0 ist echt alles andere als schön. Ist das echt nur der Bri-Filter oder betreibt ATI da noch weitere Sauerein? Kommt mir jedenfalls so vor.

[Coda]

Da wird definitiv genauso an Samples gespart wie bei G7x auch. Mit dem Unterschied dass der Filter theoretisch quasi perfekt filtern kann ohne AI. HQ auf G7x spart immer noch.

[reunion]

Ich hatte eine X1800XT und da hat AI merklich geflimmert. Und zwar schlimmer als G7x HQ.

Spiel, Szene? Ich hab' zwar nur ne X800, aber das sollte irrelevant sein.

[PCGH_Carsten]

Damit könnte man argumentieren, wenn es auf den Folien irgendwelche wagen Formulierungen gäbe, doch die Aussagen auf beiden Folien zu den Shadereinheiten sind mehr als eindeutig. Wenn dort also nicht bewusst die Unwahrheit gesagt wird, dann ist ein 1:1:1:1:1-Split möglich.
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5465685#post5465685
Schauen wir mal:

5 instructions/clk
5 components

Mehr steht da nicht, gelle? Nirgends was von 1+1+1+1+1 und dergleichen. Theoretisch würde man sogar mit einem nicht-splittbaren Vec5 den Wahrheitsgehalt dieser Aussage nicht verletzen.

[Coda]

Spiel, Szene? Ich hab' zwar nur ne X800, aber das sollte irrelevant sein.
UT2004. Sieht man ziemlich deutlich, wenn man nich ne rote Brille auf hat. Und ob eine X800 da keinen Unterschied macht weiß ich nicht. Auf der X1800 war es sehr deutlich zu sehen.

[Gast]

Spiel, Szene? Ich hab' zwar nur ne X800, aber das sollte irrelevant sein.Nein, ist es nicht. Ich kann dir zwar nicht genau erklären warum, aber auf R4x0-Karten ist AI deutlich erträglicher als auf den R5x0-Modellen.

[reunion]

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5465685#post5465685
Schauen wir mal:

5 instructions/clk
5 components

Mehr steht da nicht, gelle? Nirgends was von 1+1+1+1+1 und dergleichen. Theoretisch würde man sogar mit einem nicht-splittbaren Vec5 den Wahrheitsgehalt dieser Aussage nicht verletzen.

Wenn man den Kontext nicht beachtet vielleicht. Doch da steht u.a.:

Radeon 9200 and earlier:
1 instructions/clk
3 components

Radeon 9700/X800/1800:
2 instructions/clk
3+1 or 4+1 components

Radeon HD2000 Series:
5 instructions/clk
5 components

Es ist IMHO mehr als offensichtlich, dass mit den "instructions/clk" die Anzahl der voneinader unabhängigen Instruktionen gemeint ist, die pro Takt ausgeführt werden können. Was bei "5 components" für die HD 2000 Serie nur einen 1:1:1:1:1-Split bedeuten kann. Auch das Schaubild lässt da IMO keine Zweifel aufkommen, was gemeint ist.

Auch auf der zweiten Folie zu den Shadereinheiten beginnt der erste Satz AFAIK sinngemäß mit den Worten "Co-Issue up to 5 skalar MAD instuctions per clock".

Sieht man ziemlich deutlich, wenn man nich ne rote Brille auf hat.

Man könnte auch zumindest einmal versuchen sachlich zu bleiben.

Nein, ist es nicht. Ich kann dir zwar nicht genau erklären warum, aber auf R4x0-Karten ist AI deutlich erträglicher als auf den R5x0-Modellen.

Das würde es erklären. Ich konnte auf meiner X800 jedenfalls trotz mehrmaliger Versuche kaum Unterschiede feststellen - auch nicht in UT2004.

[deekey777]

DK777 hat gesagt es sei ein Problem in CUDA.

Hat also einfach nur kein Programmierer Bock auf FAH @ CUDA?
Nein, du hast da was falsch verstanden.
Wer sagt denn das sie es überhaupt probieren? Mit CUDA ist das definitiv kein Problem.
Sie werden es auch nicht probieren, da sie das ganze Programm in CUDA schreiben müssen, was den Aufwand nicht rechtfertigt. Mit CTM wird nur das Backend ausgewechselt.
Aktuell:
GROMACS -> Brook -> DX9 -> jede Grafikkarte ab R520 bzw. G80
Mit CUDA:
CUDA -> ab G80
Mit CTM
GROMACS -> Brook -> CTM -> R520 und aufwärts

Nvidia hat sich nur quergestellt, damit FAH auf CUDA portiert wird, und genau das wollen sie (Stanford-Dudes) nicht. Erst nach dem öffentlichen Druck hilft NV bei der Suche nach dem Problem.
Man darf aber nicht vergessen: Den PS3-Client hat Sony geschrieben. Was hält NV ab, den FAH auf CUDA selbst zu portieren?

[Coda]

Sie werden es auch nicht probieren, da sie das ganze Programm in CUDA schreiben müssen
Müssen sie nicht.

[seahawk]

reunion,

auch bei den Vorgängergenrationene gibt man die maximal Werte an.