CUDA irgendwann auch mal bei AMD/ATI?

[infinity]

Hi,

momentan sieht man, dass CUDA ziemlich gut vom Markt adaptiert wird. PhysX nutzt es auch, und Multimedia-Encoding-Software mittlerweile sogar auch... Sogar Photoshop CS4 nutzt die GPU als Stütze.

Plant AMD/ATI da langsam mal bei CUDA einzusteigen? Ich kann mir das einfach nicht erklären, wie man so am Markt vorbeisegeln kann und sogar solch eklatanten Vorteile wie Adobe-Software sie durch CUDA bietet, einfach ignorieren kann...Auf dem Spielemarkt kommt die PhysX-kompatibilität mittlerweile auch gut an!

Ohne CUDA sind die sonst extrem leistungsfähigen ATI-Grakas ja teilweise schon wertlos, wenn man bestimmte Einsatzgebiete im Auge hat. Und diese Einsatzgebiete erweitern sich momentan so rasch, dass es für ATI echt schmerzhaft werden könnte. Für mich wäre bspw. die HD4670 die optimale Graka, da sie wenig strom frisst und trotzdem relativ leistungsfähig ist. Die potenten Shadereinheiten könnten dank CUDA dann auch noch meine meisten Wünsche erfüllen, aber... nein...


Gibt es aktuell eine Petition oder sowas?

[Gast]

http://ati.amd.com/technology/streamcomputing/index.html

[Gast]

Plant AMD/ATI da langsam mal bei CUDA einzusteigen?Die Wunderwaffe bei Vista/Win7 heißt DirectX11 und für XP/Vista/Win7, Linux und Unixoide OpenCL.

CUDA und Stream waren mehr oder weniger helle, aber nur kurze Blitzlichter. Auch wenn die Hersteller es noch ne Weile supporten werden. Man sollte das nicht weiter fördern.

[deekey777]

Hi,

momentan sieht man, dass CUDA ziemlich gut vom Markt adaptiert wird. PhysX nutzt es auch, und Multimedia-Encoding-Software mittlerweile sogar auch... Sogar Photoshop CS4 nutzt die GPU als Stütze.

Plant AMD/ATI da langsam mal bei CUDA einzusteigen? Ich kann mir das einfach nicht erklären, wie man so am Markt vorbeisegeln kann und sogar solch eklatanten Vorteile wie Adobe-Software sie durch CUDA bietet, einfach ignorieren kann...Auf dem Spielemarkt kommt die PhysX-kompatibilität mittlerweile auch gut an!

Ohne CUDA sind die sonst extrem leistungsfähigen ATI-Grakas ja teilweise schon wertlos, wenn man bestimmte Einsatzgebiete im Auge hat. Und diese Einsatzgebiete erweitern sich momentan so rasch, dass es für ATI echt schmerzhaft werden könnte. Für mich wäre bspw. die HD4670 die optimale Graka, da sie wenig strom frisst und trotzdem relativ leistungsfähig ist. Die potenten Shadereinheiten könnten dank CUDA dann auch noch meine meisten Wünsche erfüllen, aber... nein...


Gibt es aktuell eine Petition oder sowas?

Nicht die Software ist entscheidend, sondern die Hardware und da ist Nvidia nunmal deutlich besser aufgestellt als ATi/AMD. Dh: Selbst wenn Stream so gut wie CUDA wäre, wäre Nvidia immernoch vorn, da sie seit Herbst 2006 die deutlich bessere GPGPU-Hardware anbieten.


CUDA und Stream waren mehr oder weniger helle, aber nur kurze Blitzlichter. Auch wenn die Hersteller es noch ne Weile supporten werden. Man sollte das nicht weiter fördern.
Quark.
Mal abgesehen davon, dass OpenCL CUDA/PTX bzw. CAL/IL als Schnittstelle zur GPU nutzt, wird zumindest CUDA so lange leben, wie Nvidia es supportet. Nicht im Consumer-Bereich (hier wird man auf OpenCL und vielleicht auf DX11 setzen), sondern im HPC-Bereich usw.: Wenn jemand einen Super-Computer mit Nvidia-Grafikkarten aufbaut, dann wird er gerade CUDA nutzen.

[infinity]

Mir ist bewusst, dass ATI "Stream" hat, und DX11 auch entsprechendes bieten wird. ABER es geht hier darum was am markt da ist und wie es angenommen wird. Und da ist es halt Fakt, dass CUDA momentan heftig im Aufwind ist und es für mich bspw. sehr wichtig wäre, dass genau das alles auch auf ATI hardware läuft! Marketinggesülz mit stream und allen kann ich mir auch antun... da steht eh immer nur, dass dies und das das beste ist... wichtig ist aber, was realität ist ---> und das ist momentan eindeutig CUDA!

[reunion]

CUDA auf AMD-Hardware kannst du vergessen.

[BlackBirdSR]

Mir ist bewusst, dass ATI "Stream" hat, und DX11 auch entsprechendes bieten wird. ABER es geht hier darum was am markt da ist und wie es angenommen wird. Und da ist es halt Fakt, dass CUDA momentan heftig im Aufwind ist und es für mich bspw. sehr wichtig wäre, dass genau das alles auch auf ATI hardware läuft! Marketinggesülz mit stream und allen kann ich mir auch antun... da steht eh immer nur, dass dies und das das beste ist... wichtig ist aber, was realität ist ---> und das ist momentan eindeutig CUDA!

Cuda ist eine Nvidia-Schnittstelle, um Nvidia-HW hardwarenah anzusprechen. Im Gegensatz zu DirectX oder OpenGl, reicht es also nicht einen Treiber zu schreiben und dann gleiche Behandlung zu erfahren.

Was könnte AMD also tun? Einfach "Yes we can" sagen und Cuda läuft geht nicht. Man müsste (mit Nvidias zustimmung denke ich mal) einen Wrapper schreiben, der Cuda-Aufrufe auf ATI-HW mapped. Zugleich muss man aber bedenken, dass Cuda natürlich die Eigenheiten der NV-Hardware ausnutzt. ATI könnte sich also anstrengen so viel sie wollen, auf lange Zeit wäre man weit hinter der möglichen Performance zurück.

Es passieren dann zwei Dinge:
* Man verhilft Cuda zu noch mehr Marktmacht und läuft Gefahr, ein Nvidia-Produkt quasi zum Standard zu erheben. Schlecht für die eigenen Produkte.
*In allen Benchmarks verlieren auch die schnellen ATI-Chips wahrscheinlich deutlich gegenüber der NV-HW. Man kann also überall mitmachen, sieht dabei aber schlecht aus. Schlecht für die eigenen Produkte.

Hand aufs Herz: Würdest du unter diesen Umständen deinen Grafikchips Cuda-Support an"treiben"?

[Gast]

* Man verhilft Cuda zu noch mehr Marktmacht und läuft Gefahr, ein Nvidia-Produkt quasi zum Standard zu erheben. Schlecht für die eigenen Produkte.


x86 ist ein Intel-Produkt und Standard. Ist das auch schlecht für AMD?

[BlackBirdSR]

x86 ist ein Intel-Produkt und Standard. Ist das auch schlecht für AMD?

x86 ist eine ISA, also eine abstrakte Abfolge von Befehlen, die von der CPU völlig unabhängig interpretiert werden. Nimmt man einem K10, Core2 oder Via Nano den x86-Vorbau weg, sind sie zueinander völlig inkompatibel und so unterschiedlich wie Nvidia oder ATI-Hardware. Nachteile hat dadurch weder AMD noch Intel, denn solange ihre CPUs x86 verstehen, können sie tun was sie wollen. Gleiches gilt für Intel und das AMD-Produkt AMD64.

Bei Grafikchips gibt es keine einheitliche ISA, die man abstrakt vor den Chip setzen kann. Cuda spricht daher gezielt Nvidia-Chips, eine Sprache die ATI-Chips nicht verstehen können. Ein Übersetzen wird immer Leistung kosten, und kann die Nachteile der spezifischen NV-Optimierung nicht wett machen.

Sicherlich: Wird Cuda zum Standard, dann wird es früher oder später neutraler an die Sache gehen müssen. Dann egalisiert sich das vielleicht etwas. Das wird aber sehr lange dauern, Zeit in der AMD kontinuierlich weit hinten liegen wird.

[infinity]

@BlackBirdSR

wo liegt das Problem, dass die ATI hardware bei CUDA evtl. langsamer laufen würde? Ich nehme lieber etwas leistungseinbußen in kauf, als die extremen Leistungssteigerungen durch CUDA einfach so an mir vorbeifliegen zu sehen. Aktuell wird sogar Mathematica 7 bald CUDA unterstützen... es wird anscheinend zu einem Standard, denn sonst würden sich nicht so viele namhafte Softwarehäuser so langsam drum kümmern. Also wenn ATI da nicht langsam mit einsteigt, wirds wirklich mies. CUDA wird besonders seit ca. 3 Monaten und in naher Zukunft zu einem absoluten Kaufargument bei den Retailkäufern, denn diese wissen um den Stand der Dinge und verlangen das was aktuell das meiste aus der Hardware rausholt.

Würdest du lieber einen potenten CoreI7 mit 3GHz oder was auch immer mit einer highend ATI-Karte paaren und damit (bspw.) 200% langsamer rendern lassen, wenn du genau das bei nVidia praktisch frei haus um ein vielfaches beschleunigt bekommst? Würdest du es nicht lieber haben, dass deine ATI-Karte 20% langsamer rendert als eine nVidia, aber dafür 180% schneller als sonst ohne?

[reunion]

@BlackBirdSR

wo liegt das Problem, dass die ATI hardware bei CUDA evtl. langsamer laufen würde? Ich nehme lieber etwas leistungseinbußen in kauf, als die extremen Leistungssteigerungen durch CUDA einfach so an mir vorbeifliegen zu sehen. Aktuell wird sogar Mathematica 7 bald CUDA unterstützen... es wird anscheinend zu einem Standard, denn sonst würden sich nicht so viele namhafte Softwarehäuser so langsam drum kümmern. Also wenn ATI da nicht langsam mit einsteigt, wirds wirklich mies. CUDA wird besonders seit ca. 3 Monaten und in naher Zukunft zu einem absoluten Kaufargument bei den Retailkäufern, denn diese wissen um den Stand der Dinge und verlangen das was aktuell das meiste aus der Hardware rausholt.

Würdest du lieber einen potenten CoreI7 mit 3GHz oder was auch immer mit einer highend ATI-Karte paaren und damit (bspw.) 200% langsamer rendern lassen, wenn du genau das bei nVidia praktisch frei haus um ein vielfaches beschleunigt bekommst? Würdest du es nicht lieber haben, dass deine ATI-Karte 20% langsamer rendert als eine nVidia, aber dafür 180% schneller als sonst ohne?


Was ist daran so schwer zu verstehen? AMD hätte eklatante Nachteile, wenn man CUDA unterstützen würde. Noch dazu würde man so CUDA wohl zum Durchbruch verhelfen. Man unterstützt es also bewusst nicht und setzt stattdessen auf OpneCL/DX11, welches mit allen GPUs läuft. Und ich glaube auch nicht das CUDA noch sonderlich von Bedeutung ist wenn erstmal OpenCL und DX11 verfügbar sind, da es einfach nur auf NV-Karten läuft und kein Hersteller Interesse daran hat eine so große Gruppe auszuschließen wenn es erstmal Alternativen gibt.

[BlackBirdSR]

@BlackBirdSR

wo liegt das Problem, dass die ATI hardware bei CUDA evtl. langsamer laufen würde?

Stell dir vor, du hast einen Cluster aus Prozessoren (Nvidia) die nach Methode X arbeiten und über Algortihmen Y am besten angesprochen werden können. Jetzt kommt ATI-Hardware mit Methode A und Algorithmen B. Beide Hersteller haben zwar ähnliche Ansätze, aber unterschiedliche Implementationen. ATI müsste nun mit einer zusätzlichen Schnittstelle X in A und Y in B umwandeln; ein alles andere als trivialer Vorgang, der leider viel Leistung kostet (siehe Virtualisierung, oder Konsolenemulation).

Es geht also nich um "evtl. langsamer" sondern um "definitiv langsamer, aber fragt sich nur wie viel?"


Ich nehme lieber etwas leistungseinbußen in kauf, als die extremen Leistungssteigerungen durch CUDA einfach so an mir vorbeifliegen zu sehen.

"Etwas" wird zu "viel". Natürlich wäre dir das als User lieber. Allerdings steht dann ganz klar fest: Willst du GGPU dann kauf Nvidia, ATI kanns zwar auch, aber selbst mit High-End Karten nicht so gut. Sehr schlecht fürs Geschäft.


Aktuell wird sogar Mathematica 7 bald CUDA unterstützen... es wird anscheinend zu einem Standard, denn sonst würden sich nicht so viele namhafte Softwarehäuser so langsam drum kümmern. Also wenn ATI da nicht langsam mit einsteigt, wirds wirklich mies. CUDA wird besonders seit ca. 3 Monaten und in naher Zukunft zu einem absoluten Kaufargument bei den Retailkäufern, denn diese wissen um den Stand der Dinge und verlangen das was aktuell das meiste aus der Hardware rausholt.

ATI versucht das (aus verständlichen Gründen) so lange wie möglich hinauszuzögern. Serzt sich Cuda vollends durch, dann bleibt ATI natürlich nichts anderes mehr. Aber bis dahin ignoriert man und hofft auf eine Ablösung.


Würdest du lieber einen potenten CoreI7 mit 3GHz oder was auch immer mit einer highend ATI-Karte paaren und damit (bspw.) 200% langsamer rendern lassen, wenn du genau das bei nVidia praktisch frei haus um ein vielfaches beschleunigt bekommst? Würdest du es nicht lieber haben, dass deine ATI-Karte 20% langsamer rendert als eine nVidia, aber dafür 180% schneller als sonst ohne?

Was ich will zählt nicht. Was ATI will und den Verkauf fördert, das zählt dagegen schon. Daher: ATI wird es solange hinauszögern, wie es nur geht. Kommt es dazu, dass ATI Cuda unterstützen muss - dann hat man bisher viel verloren und wird noch viel mehr verlieren, bis Cuda vielleicht irgendwann neutral wird.

[Coda]

Ein Übersetzen wird immer Leistung kosten, und kann die Nachteile der spezifischen NV-Optimierung nicht wett machen.
Ich bin mir da gar nicht so sicher, ob eine CUDA-Übersetzung gegenüber OpenCL (ohne Extensions) wirklich langsamer wäre. OpenCL ist nämlich eigentlich allgemeiner gefasst als CUDA - man muss bei CUDA mehr über die Warps/Threads usw. bei der Programmierung beachten. OpenCL abstrahiert das weg.

Die andere Frage ist allerdings, ob ATI CUDA überhaupt unterstützen dürfte. Ich bin mir da nicht so sicher.

Es könnte aber passieren, dass jemand einen CUDA->OpenCL-Wrapper schreibt.

[deekey777]

CUDA auf AMD-Hardware kannst du vergessen.
CUDA auf AMD-Hardware nennt sich OpenCL. :biggrin:

Zunächst: Die Programmiermodelle unterscheiden sich in Grundsätzen nicht (nur in Begrifflichkeiten). Ob ein Kernel als Execution Domain (Stream) oder Grid (CUDA) ausgeführt wird, ist egal, denn es ist immer das Gleiche. CUDAs Thread-Blocks sind Streams Wavefronts (nur etwas kleiner, dazu kommt noch die Sache mit den Warps). Auch OpenCL arbeitet gleich - nur mit anderen Begriffen.
Die Unterschiede macht die Hardware und diese spiegeln sich in der Software wider. Wie gesagt, ist schon der G80 GPGPU-iger (Komparativ) als der RV770: CUDA kennt mehrere Memory-Arten, CUDA kennt Shared-Memory (LDS beim RV770), mit CUDA kann man einzelnen Thread eigene IDs zuweisen (auch erst ab RV770, vgl. CAL Compute Shader) usw.
Ein C-for-CUDA-zu-IL-Compiler, der CUDA-Zeug ins IL übersetzt (also die Pseudo-Assemblersprache) würde gar in die Ideologie von AMD Stream passen, nur wäre dieser Weg damit verbunden, dass die Entwickler den generierten IL-Code manuell optimieren werden müssen. Und darauf haben nur die wenigsten Lust (das ist wohl einer der Gründe, warum CUDA populärer ist).

Was ist daran so schwer zu verstehen? AMD hätte eklatante Nachteile, wenn man CUDA unterstützen würde. Noch dazu würde man so CUDA wohl zum Durchbruch verhelfen. Man unterstützt es also bewusst nicht und setzt stattdessen auf OpneCL/DX11, welches mit allen GPUs läuft. Und ich glaube auch nicht das CUDA noch sonderlich von Bedeutung ist wenn erstmal OpenCL und DX11 verfügbar sind, da es einfach nur auf NV-Karten läuft und kein Hersteller Interesse daran hat eine so große Gruppe auszuschließen wenn es erstmal Alternativen gibt.
Nvidia-Ideologie:
Nutzt CUDA und nur CUDA.
AMD-Ideologie:
Macht, was ihr wollt. Alles, was nötig ist, ist ein Euer-Zeug-zu-IL-Compiler. Wenn ihr euer Programm in C for CUDA schreibt, bitte sehr, ihr braucht dann nur den passenden Compiler.

Das ist ein Grund, warum es nicht schon irgendwann 2007 einen GPU-Client für F@H auf Nvidia-Grafikkarten gab. Standford wollte bei BrookGPU bleiben, weil sie sich damit bestens auskennen. Nvidia wollte aber, dass sie CUDA nutzen. Bei ATi war das kein Problem, denn Book+ stammt von BrookGPU ab, womit die Stanford-Leute für den roten Client Brook+ nutzen (mit all seinen Nachteilen) und dann den entsprechenden IL-Code kompilieren.

[Gast]

Die andere Frage ist allerdings, ob ATI CUDA überhaupt unterstützen dürfte. Ich bin mir da nicht so sicher.


nVidia hat dies doch in einem Akt unfassbarer Großzügigkeit angeboten. Die würden sich in's Fäustchen lachen und selbstverständlich gerne annehmen, wenn ATI nach der ursprünglichen Ablehnung nun zu Kreuze gekrochen käme mit der Bitte, jetzt doch CUDA unterstützen zu dürfen.

[Coda]

nVidia hat dies doch in einem Akt unfassbarer Großzügigkeit angeboten.
Soweit ich weiß ist das ein Hoax.

[_DrillSarge]I[]

das alles erinnert lustigerweise schön an prä-directX zeiten mit glide, metal etc.. :D
die haben nix dazugelernt :(

[Fallacy]

Die Unterschiede macht die Hardware und diese spiegeln sich in der Software wider. Wie gesagt, ist schon der G80 GPGPU-iger (Komparativ) als der RV770: CUDA kennt mehrere Memory-Arten, CUDA kennt Shared-Memory (LDS beim RV770), mit CUDA kann man einzelnen Thread eigene IDs zuweisen (auch erst ab RV770, vgl. CAL Compute Shader) usw.


Sind ALU-Power und Double Precision (nicht beim G80) nicht auch irgendwie Architekturen-Kriterien um eine "GPGPU-ig" zu machen? CUDA gibt dem Programmierer expliziten Zugriff auf den Shared Memory, während das wohl so bei Stream nicht möglich ist (soweit ich mich erinnere). Aber nur weil man keinen Zugriff darauf hat, heisst das ja noch nicht, dass so etwas nicht in der Architektur exisitiert, kann ja genauso über den Compiler genutzt werden. Falls mit Thread ID der zugriff auf einzelne Threads über die Blocks und Grids gemeint ist, sowas muss mit Stream ja auch irgendwie gehen, irgendwie muss man ja auch die Threads zugreifen können.

Die Probleme die du geschildert hast, sehen für mich eher nach Software-seitigen Problemen aus. Nicht nach Unterschieden in der Hardware. Ich denke ebenfalls das CUDA über kurz oder lang nach dem Erscheinen von hardwareunabhängigen Software-Lösungen verschwinden wird.

[Coda]

Falls mit Thread ID der zugriff auf einzelne Threads über die Blocks und Grids gemeint ist, sowas muss mit Stream ja auch irgendwie gehen, irgendwie muss man ja auch die Threads zugreifen können.
Auf den HD2000- und HD3000-Karten gibt es keine Threads auf die man Zugriff hätte.

Genauer gesagt werden die Programme einfach als Pixelshader ausgeführt.

[infinity]

"Etwas" wird zu "viel". Natürlich wäre dir das als User lieber. Allerdings steht dann ganz klar fest: Willst du GGPU dann kauf Nvidia, ATI kanns zwar auch, aber selbst mit High-End Karten nicht so gut. Sehr schlecht fürs Geschäft.



Ich weiß auch nicht... verstehe zwar deine argumentation, aber irgendwie kann ich sie nicht ganz nachvollziehen...
Was ist daran schlecht fürs geschäft, wenn ein produkt ein feature, das sich am markt etabliert unterstützt? Ich sehe es gerade aus "meiner" Sicht als schlecht fürs geschäft an, dass sich AMD durch das Nichtunterstützen von CUDA selbst disqualifiziert. Ob wrapper, Leistungseinbußen und was für nachteile auch immer, ... es würde höchstwahrscheinlich eine gewisse Beschleunigung bewirken, und ein Argument gegen den Kauf von ATI-Hardware auch gleich auflösen... zumal bei Hardware doch eh immer gilt "besser haben und nicht brauchen, als brauchen und nicht haben" (außer bei aspekten, die die leistungsaufnahme steigen lassen) !

[deekey777]

Sind ALU-Power und Double Precision (nicht beim G80) nicht auch irgendwie Architekturen-Kriterien um eine "GPGPU-ig" zu machen?
Erst der RV770 ist auf dem Level des G80. Er beherrscht auch vollständig Gather/Scatter.
CUDA gibt dem Programmierer expliziten Zugriff auf den Shared Memory, während das wohl so bei Stream nicht möglich ist (soweit ich mich erinnere). Aber nur weil man keinen Zugriff darauf hat, heisst das ja noch nicht, dass so etwas nicht in der Architektur exisitiert, kann ja genauso über den Compiler genutzt werden.
Das geht erst mit dem RV770 und nur über IL, nennt sich LDS und ist bisher kaum dokumentiert. Ohne Shared-Memory/LDS hat man mit niedrigerer Bandbreite und hohen Latenzen zu kämpfen. Dass Shared-Memory das Leben nicht einfach macht, darf nicht vergessen werden, denn der Entwickler muss seine Kernel auf Blocks so aufteilen, dass die Daten nicht über 16 KB gehen. So oder so: Man hat eine bessere Performance.
Falls mit Thread ID der zugriff auf einzelne Threads über die Blocks und Grids gemeint ist, sowas muss mit Stream ja auch irgendwie gehen, irgendwie muss man ja auch die Threads zugreifen können.
Siehe oben: Mit dem RV770 wurde zusätzlich CAL Compute Shader eingeführt (siehe hier (http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=104563&enterthread=y)). Und wieder nur über IL.

Die Probleme die du geschildert hast, sehen für mich eher nach Software-seitigen Problemen aus. Nicht nach Unterschieden in der Hardware. Ich denke ebenfalls das CUDA über kurz oder lang nach dem Erscheinen von hardwareunabhängigen Software-Lösungen verschwinden wird.
CUDA wird nicht verschwinden, es sei denn, es wird eingestellt.
Das Problem bei Stream ist, dass die Software der Hardware hinterherhinkt. Besser gesagt: Das Zugpferd Brook+ hinkt mehreren Releases von IL hinterher. Für die Entwickler bedeutet das: Entweder sie haben ein "leichtes" Leben und nutzen Brook+, können die Hardware nicht ausreizen (es sei denn, sie optimieren den IL-Code nach der Kompilierung manuell nach), oder sie schreiben gleich in IL, was aber viel mehr Erfahrung verlangt.
AMD ist öffentlich vielleicht ein noch größerer OpenCL-Verfechter als Nvidia, denn Brook+ ist aktuell einfach nicht gut genug.

Was vergessen:
Egal ob GT200 oder G86: Der einzelne Core ist in Grundzügen gleich (8 SPs und 16KB-Cache), wie schnell ein Programm dann läuft, entscheidet die Anzahl der Cores.

[aylano]

Und da ist es halt Fakt, dass CUDA momentan heftig im Aufwind ist und es für mich bspw. sehr wichtig wäre, dass genau das alles auch auf ATI hardware läuft!
Momentan dürfte es eher umgekehrt aussehen.
Laut Fudzilla dürften die im 4Q einen Einbrauch von 47% (absolut) haben, während ATI vielleicht ein paar Prozent Marktanteile (relativ) zurückgewonnen haben dürfte.

Das ist für Nvidia eine Ungünstige zeit, paar Monate/Quartale vor der OpenCl & DX11-Einführung.

Was ist daran schlecht fürs geschäft, wenn ein produkt ein feature, das sich am markt etabliert unterstützt? Ich sehe es gerade aus "meiner" Sicht als schlecht fürs geschäft an, dass sich AMD durch das Nichtunterstützen von CUDA selbst disqualifiziert.
Ein weiteres Minus-Geschäft ist schlecht fürs Geschäft alias wegen Nvidia-Software sind ATi-Karten langsamer, was sich total in den Verkaufszahlen auswirkt.
Wozu den Aufwand, als ob AMD nicht andere Probleme hätte, wenn am Schluss vielelicht noch ein Minus rausschaut. Abgesehen davon, Cuda zum Standard zu verhelfen, was für ATI fatal wäre, weil ATI damit die Zukunft ziehmlich zerstören kann.

[Sven77]

Im Bereich, wo Cuda wirklich reinhaut und reinhauen wird ist in der DCC-Industrie, und hier ist ATI ein kleines Licht bis nicht existend. Der prof. Bereich ist fest in Nvidia's Händen, was aber auch mit der Zusammenarbeit mit den Branchenriesen zu tun hat, sei es auf Hardware- oder Softwareseite. Jedesmal wenn ATI wieder versucht einen Fuss in die Tür zu bekommen, scheiterts daran das die Karten nicht konkurrenzfähig sein (FireGL vs. Quadro), oder die Software, auf die man versucht zu optimieren von einem der Grossen aufgekauft wird..

[Coda]

Erst der RV770 ist auf dem Level des G80. Er beherrscht auch vollständig Gather/Scatter.
Ist das so? Was ich bisher gelesen habe deutet auf etwas anderes hin.

Was vergessen:
Egal ob GT200 oder G86: Der einzelne Core ist in Grundzügen gleich (8 SPs und 16KB-Cache), wie schnell ein Programm dann läuft, entscheidet die Anzahl der Cores.
Es ist kein Cache es ist Register-Storage. G8x/G9x haben 32KiB und GT200 hat 64KiB pro SM. Ansonsten hast du recht.

[deekey777]

Ist das so? Was ich bisher gelesen habe deutet auf etwas anderes hin.
Kann gut sein, aber der eine Russe (ein Umsteiger von CUDA auf Stream) meint, dass die Spielregeln bei der Programmierung jetzt in etwa gleich sind.


Es ist kein Cache es ist Register-Storage. G8x/G9x haben 32KiB und GT200 hat 64KiB. Ansonsten hast du recht.
Ich war nur zu faul wieder Shared Memory zu schreiben. 16 KB = Shared Memory (was AMD als LDS versteht und OpenCL als Local Memory).

[Coda]

Ich war nur zu faul wieder Shared Memory zu schreiben. 16 KB = Shared Memory (was AMD als LDS versteht und OpenCL als Local Memory).
Okay, dann ordne das bitte aber auch nicht den Funktionseinheiten zu. Das gehört da nur bedingt hin.

GT200 hat eine leicht höhere Effizienz pro Core (größeres Registerfile und effizienteres MUL).

[Fallacy]

Das geht erst mit dem RV770 und nur über IL, nennt sich LDS und ist bisher kaum dokumentiert. Ohne Shared-Memory/LDS hat man mit niedrigerer Bandbreite und hohen Latenzen zu kämpfen. Dass Shared-Memory das Leben nicht einfach macht, darf nicht vergessen werden, denn der Entwickler muss seine Kernel auf Blocks so aufteilen, dass die Daten nicht über 16 KB gehen. So oder so: Man hat eine bessere Performance.

Der R600 hatte ebenso ein Register File pro Shader Cluster, nur scheint man darauf per Stream eben nicht zugreifen zu können. Was aber nicht heißt, dass es sowas deswegen nicht gibt. Das ist aber wohl weniger ein Hardware-Defizit als einmal mehr ein Software-Nachteil.


CUDA wird nicht verschwinden, es sei denn, es wird eingestellt.
Das Problem bei Stream ist, dass die Software der Hardware hinterherhinkt. Besser gesagt: Das Zugpferd Brook+ hinkt mehreren Releases von IL hinterher. Für die Entwickler bedeutet das: Entweder sie haben ein "leichtes" Leben und nutzen Brook+, können die Hardware nicht ausreizen (es sei denn, sie optimieren den IL-Code nach der Kompilierung manuell nach), oder sie schreiben gleich in IL, was aber viel mehr Erfahrung verlangt.
AMD ist öffentlich vielleicht ein noch größerer OpenCL-Verfechter als Nvidia, denn Brook+ ist aktuell einfach nicht gut genug.

Also deiner Argumentation kann ich gar nicht widersprechen, das sehe ich ganz genauso. Nur der Schlussfolgerung, dass Cuda dann nicht von OpenCl verdrängt wird, kann ich nicht folgen.

[BlackBirdSR]

Ich weiß auch nicht... verstehe zwar deine argumentation, aber irgendwie kann ich sie nicht ganz nachvollziehen...
Was ist daran schlecht fürs geschäft, wenn ein produkt ein feature, das sich am markt etabliert unterstützt? Ich sehe es gerade aus "meiner" Sicht als schlecht fürs geschäft an, dass sich AMD durch das Nichtunterstützen von CUDA selbst disqualifiziert. Ob wrapper, Leistungseinbußen und was für nachteile auch immer, ... es würde höchstwahrscheinlich eine gewisse Beschleunigung bewirken, und ein Argument gegen den Kauf von ATI-Hardware auch gleich auflösen... zumal bei Hardware doch eh immer gilt "besser haben und nicht brauchen, als brauchen und nicht haben" (außer bei aspekten, die die leistungsaufnahme steigen lassen) !

Wenn es keine Alternative zu Cuda gäbe,okay.
Aber gerade diese Alternativen kommen ja in Zukunft und darauf setzten AMD und Intel.

[BK-Morpheus]

Hm, hab ich das falsch in Erinngerung, oder liegt der momentan besser angenommene CUDA Support im Verlgeich zu ATIs Stream nicht auch daran, dass Nvidia die Spezifikationen frei zugänglich gemacht hat und ATI eben nicht?

Irgendwas war da doch...naja vielleicht war's auch nur gefährliches Halbwissen. ;)

[Coda]

Der R600 hatte ebenso ein Register File pro Shader Cluster, nur scheint man darauf per Stream eben nicht zugreifen zu können.
:confused:

Natürlich hat man "Zugriff" auf das Register-File. Da werden die Zwischenergebnisse von allen Operationen gespeichert. Ein Programm ohne Registerfile kann auf der GPU gar nicht laufen :ugly:

[Gast]

Quark.
Mal abgesehen davon, dass OpenCL CUDA/PTX bzw. CAL/IL als Schnittstelle zur GPU nutzt, wird zumindest CUDA so lange leben, wie Nvidia es supportet. Nicht im Consumer-Bereich (hier wird man auf OpenCL und vielleicht auf DX11 setzen), sondern im HPC-BereichAlso doch nicht Quark. Gut daß wir darüber gesprochen haben.

[deekey777]

Also doch nicht Quark. Gut daß wir darüber gesprochen haben.
Lass mich raten: Du hast das Interview mit einem Intel-Mitarbeiter gelesen und gibst jetzt seine Meinung zu CUDA (also zu etwas, was Intel immernoch nicht hat) wieder?

[Fallacy]

:confused:

Natürlich hat man "Zugriff" auf das Register-File. Da werden die Zwischenergebnisse von allen Operationen gespeichert. Ein Programm ohne Registerfile kann auf der GPU gar nicht laufen :ugly:

Ich meinte den lokalen Speicher pro Shader Cluster, also das was bei NV als shared Memory und bei AMD als local data store bezeichnet wird. Und ich ging in der Annahme, dass der R600 doch so etwas wie den local data store hatte, was aber wohl nicht stimmt.

[Gast]

Lass mich raten: Du hast das Interview mit einem Intel-Mitarbeiter gelesen und gibst jetzt seine Meinung zu CUDA (also zu etwas, was Intel immernoch nicht hat) wieder?So ungefähr garnicht. Ich schrieb auch, daß Nv CUDA noch eine Weile, damit meine ich eine längere Weile, pflegen wird. Wo frißt sich das mit der anderen Aussage?

_DrillSarge]I[ hat das schon klasse assoziert. CUDA ist Glide. War eine erstklassige Geschichte. Und ist nun Geschichte. Viel weiter häte es das auch ohne den Untergang von 3dfx nicht gegeben. Irgendwannmal kommt ein DirectX der es "schluckt". So wie das ab DirectX11/OpenCL der Fall sein wird.

Über spezialisierte Lösungen die es auf der Basis von CUDA vielleicht neu auch 2011 gibt, brauchen wir deswegen nicht diskutieren. Das dürfte selbst uns hier nicht besonders interessieren. Die Fragen waren andere.

[Gast]

Wenn es keine Alternative zu Cuda gäbe,okay.
Aber gerade diese Alternativen kommen ja in Zukunft und darauf setzten AMD und Intel.Und Microsoft und Linux.

[Gast]

Ihr vergesst nur Eines, und zwar den Markteintritt von Intel ins Grafikkartengeschäft. Da wird mal eben eine Mrd. Euro oder mehr bereit gestelllt um entspr. Larrabee Projekte zu "fördern". Das beinhaltet dann letzten Endes wieder eine Politik die es den Softwarehäusern vergällt überhaupt Produkte an Nvidia oder Ati anzupassen. Offiziell heißt es dann wieder "es lohne sich nicht auf mehrere Plattformen zu optimieren". In den Sponsoringverträgen steht das dann natürlich völlig anders drin. Und schon wird man bei der versammelten Fachpresse auf wundersame Weise nichts mehr über Cuda, Stream oder Physx lesen können. Bzw. es werden häufig geschönte Berichte erscheinen, die Larrabee über alle Konkurrenzprodukte hinweg zum absoluten Stein der Weisen erklären. Und damit hat sich das Thema dann still und leise erledigt.

[Lolman]

Was passiert mit PhysX, wenn DX11/OpenCL da sind?:

http://www.computerbase.de/news/hardware/grafikkarten/2009/februar/was_physx_dx11_opencl/

[|MatMan|]

Ich denke ein Punkt, dass hier viele vergessen ist die "Entwicklungsumgebung", genauer gesagt die Bibliotheken die es vom IHV dazu gibt. Bei CUDA gibt es da z.B. schon fft und BLAS Funktionalitäten. LAPACK Fähigkeiten, also lineare Solver und Matrixzerlegungen sollen demnächst noch kommen.

Solche vom IHV durchoptimierten Bibliotheken sind sehr wichtig für Entwickler und können (je nach Anwendung) schon ein deutliches Argument für CUDA sein.

[deekey777]

So ungefähr garnicht. Ich schrieb auch, daß Nv CUDA noch eine Weile, damit meine ich eine längere Weile, pflegen wird. Wo frißt sich das mit der anderen Aussage?

_DrillSarge]I[ hat das schon klasse assoziert. CUDA ist Glide. War eine erstklassige Geschichte. Und ist nun Geschichte. Viel weiter häte es das auch ohne den Untergang von 3dfx nicht gegeben. Irgendwannmal kommt ein DirectX der es "schluckt". So wie das ab DirectX11/OpenCL der Fall sein wird.

Über spezialisierte Lösungen die es auf der Basis von CUDA vielleicht neu auch 2011 gibt, brauchen wir deswegen nicht diskutieren. Das dürfte selbst uns hier nicht besonders interessieren. Die Fragen waren andere.

http://www.hardware.fr/articles/744-3/opencl-gpu-computing-enfin-democratise.html
Das Bild sagt 1000 Worte.

[BigBen]

@|MatMan|:
Und hier pennt AMD/ATI und auch Intel (Intels Onboard-Grafik macht ... Probleme (http://www.golem.de/0808/61755.html)) gehörig, was mitunter auch an deren GPUs liegen mag.

Weil Bilder so schön verdeutlichen: nVidias Cuda Zone

http://img3.imageshack.us/img3/3941/cudazone.jpg (http://www.nvidia.com/object/cuda_home.html)


Während der vergangenen Tage, beschäftigte ich mich hinsichtlich eines Office-, HTPC sowie Laptops, wieder eingehender mit der Thematik.
Wem für eine möglichst gute HD-Beschleunigung ohne zusätzliche Grafikkare wichtig ist, erhält in den Foren deshalb auch die eindeutige Empfehlung für ein MB mit entsprechend integrierter nVidia-mGPU.
nVidias Cuda ist für den Anwender derzeit am fortgeschrittensten.

Alternativ zu DirectX11 und OpenCL darf man seitens AMD und Intel wohl nichts mehr erwarten. :(

[albix64]

Alternativ zu DirectX11 und OpenCL darf man seitens AMD und Intel wohl nichts mehr erwarten. :(
Hätte auch keinen Sinn.

Ich denke eine plattformunabängige Lösung wie OpenCL ist der beste Kompromiss den man finden kann/konnte.

[S940]

Alternativ zu DirectX11 und OpenCL darf man seitens AMD und Intel wohl nichts mehr erwarten. :(
Öh ja, die sind schließlich beide bei OpenCL vertreten, wieso sollten sie das Rad zum xten Mal nochmals neu erfinden ?

[|MatMan|]

Hätte auch keinen Sinn.

Ich denke eine plattformunabängige Lösung wie OpenCL ist der beste Kompromiss den man finden kann/konnte.
Die Frage ist trotzdem noch was es für libraries zu OpenCL gibt. Ist da überhaupt etwas standardisiert oder ist man komplett auf Drittanbieter angewiesen?

Von Intel und AMD gibt es auch optimierte x86 BLAS libraries. Die bieten die aber nur optional an - wohl um in Benchmarks besser dazustehen ;) Es wäre schön, wenn sowas für OpenCL Pflicht wäre - ich glaubs aber kaum.

Wie ich vorher schon geschrieben habe, wäre das ein nicht zu unterschätzender Vorteil für nVidia (und damit CUDA), zwar sicherlich hauptsächlich für den Profi/HPC Markt, aber da sind die Margen ja bekanntlich sehr hoch...

[albix64]

Die Frage ist trotzdem noch was es für libraries zu OpenCL gibt. Ist da überhaupt etwas standardisiert oder ist man komplett auf Drittanbieter angewiesen?
Da habe ich leider keine Ahnug. Soweit ich weiß, gibt es bisher nur die Spezifikation und Header-Files. (http://www.khronos.org/registry/cl/)

Einen Compiler bzw. eine Implementierung gibt es noch nicht.

[Gipsel]

Nicht die Software ist entscheidend, sondern die Hardware und da ist Nvidia nunmal deutlich besser aufgestellt als ATi/AMD. Dh: Selbst wenn Stream so gut wie CUDA wäre, wäre Nvidia immernoch vorn, da sie seit Herbst 2006 die deutlich bessere GPGPU-Hardware anbieten.
Das sehe ich ehrlich gesagt genau anders rum. Die Software ist sehr wichtig und ist genau das, wo nvidia ATI im Moment abhängt. Die Hardware der ATIs ist ziemlich potent, insbesondere wenn man noch Preis/Leistung berücksichtigt. Wie lange schon baut ATI GPUs die immer Vorreiter bei der Shaderleistung waren, aber wo man Abstriche hinsichtlich der Texturierleistung hinnehmen mußte?
Ein C-for-CUDA-zu-IL-Compiler, der CUDA-Zeug ins IL übersetzt (also die Pseudo-Assemblersprache) würde gar in die Ideologie von AMD Stream passen, nur wäre dieser Weg damit verbunden, dass die Entwickler den generierten IL-Code manuell optimieren werden müssen. Und darauf haben nur die wenigsten Lust (das ist wohl einer der Gründe, warum CUDA populärer ist).
Was glaubst Du wie das bei CUDA intern gelöst ist?
Und warum sollte man den generierten IL code unbedingt manuell optimieren müssen? Wie optimieren die Leute denn die Shader, die z.B. in HLSL geschrieben werden? Da läuft auch nur ein Compiler drüber (übrigens der Gleiche) und gut ist. Daß da performanter Code rauskommt, kann ja jeder mal mit ein bei Pixelshadertests auf ATI-Karten überprüfen.
Sicher sieht der Code nicht schön aus und hat hier und da vielleicht auch ein paar Schwächen, aber ich behaupte mal das man auch bei etwas komplexeren Shadern/Kernels recht selten mit Handanlegen deutlich mehr als 30% Performancezuwachs rausquetschen kann. Das liegt ja auch daran, daß der IL zur Laufzeit nochmal durch einen (optimierenden) Compiler gejagt wird. Man darf also nicht den IL vergleichen, sondern was letztendlich an Instruktionen für die Hardware rauskommt (z.B. mit dem SKA).

Also eigentlich sind die ATIs und nvidias ziemlich ähnlich zu programmieren, wenn man mal auf grundlegende Prinzipien schaut. Auch deswegen wird ATI wohl keine größeren Probleme haben, das recht CUDA ähnliche OpenCL zu unterstützen (wird aber wahrscheinlich auf RV7xx und neuer beschränkt werden). Den wesentlichsten Unterschied würde ich fast noch bei den 5-issue-VLIW Einheiten im Falle von ATI und den skalaren (oder besser 2-issue) Einheiten von nvidia sehen. Daß CUDA erheblich ausgereifter ist, steht vollkommen außer Frage. Hier hat nvidia viel mehr Entwicklungsarbeit investiert als ATI.

Daß ATI beim "ernsthaften" GPGPU-Computing eigentlich gut mithalten könnte, wird auch am Beispiel der double precision Unterstützung deutlich. Die wird ja bei vielen wissenschaftlichen Rechnungen einfach benötigt. Diese Rechnungen ließen sich deshalb bisher nur schlecht bis gar nicht auf GPUs portieren. Allerdings ist schon seit dem RV670 die double Unterstützung in Hardware gegossen. Von der Software-Seite sah es bisher aber eher mau aus (nur die Grundrechenarten gehen, keine Bibliotheksfunktionen). Nvidia macht groß Werbung mit ihrer double Unterstützung bei der GTX 2xx Linie, verschweigt aber, daß eine GTX280 weniger Leistung dabei hat als eine alte HD3850. Von den HD4800ern mal ganz zu schweigen (Faktor 2,5 bis 3 schneller). Hier hat ATI echt was versäumt.

@|MatMan|:
Wem für eine möglichst gute HD-Beschleunigung ohne zusätzliche Grafikkare wichtig ist, erhält in den Foren deshalb auch die eindeutige Empfehlung für ein MB mit entsprechend integrierter nVidia-mGPU.
Und ich dachte für HD-Beschleunigung wurde bisher meist ATI favorisiert ;)

[Gast]

Nvidia macht groß Werbung mit ihrer double Unterstützung bei der GTX 2xx Linie, verschweigt aber, daß eine GTX280 weniger Leistung dabei hat als eine alte HD3850. Von den HD4800ern mal ganz zu schweigen (Faktor 2,5 bis 3 schneller).
Auf dem Papier ja. Aber wie steht es da mit der Umsetzung in der Praxis? Ich kenne mich da nicht so gut aus, aber von dem, was man so lesen kann, wirkt es so, als wäre die DP-Unterstützung beim GT200 umfassender, während die RV770er zwar wesentlich schneller FMA rechnen, aber ansonsten relativ wenig Funktionsumfang bieten.

Weißt du dazu genaueres?


Carsten

[Gipsel]

Auf dem Papier ja. Aber wie steht es da mit der Umsetzung in der Praxis? Ich kenne mich da nicht so gut aus, aber von dem, was man so lesen kann, wirkt es so, als wäre die DP-Unterstützung beim GT200 umfassender, während die RV770er zwar wesentlich schneller FMA rechnen, aber ansonsten relativ wenig Funktionsumfang bieten.

Weißt du dazu genaueres?
Die Hardware kann bei nvidia auch nicht mehr rechnen als bei ATI, nvidia hat bloß weniger davon (30 double precision Shader-Einheiten, die ein FMA oder MUL oder ADD pro Takt können, ATI hat beim RV770 160 Einheiten, die 1 FMA oder MUL oder 2 ADDs pro Takt können). Beide implementieren den Grundumfang an Fließkommaoperationen für doubles, so daß man ohne Probleme das GPU-Äquivalent einer math.lib bauen kann. Sowas wie exp() oder pow() ist ja sowieso alles über Bibliotheken gelöst (bei einer CPU übrigens auch).
Und für die meisten Probleme sind die benötigten Operationen nunmal Multiplikation, Additionen, ab und zu mal eine Division oder eine Wurzel und ganz selten dann mal was Komplizierteres wie pow(), exp() oder trigonometrische Funktionen.

Ich habe jetzt erst ein einziges Problem auf einer GPU implementiert (Milkyway@home GPU-Applikation für ATIs), aber das rennt wie die Sau auf ATIs mit double precision. Eine HD4870 schafft real gemessen ziemlich genau das Doppelte der theoretischen Peakleistung einer GTX280. Was bei nvidia davon real bei rumkommt, muß sich erst noch zeigen, aber meine Vermutung wäre das eine GTX295 (mit 2 GPUs) etwa die Leistungsfähigkeit einer einzelnen HD4850 erreichen könnte (vielleicht auch nur HD4830-Niveau).

Wer viel double precision Leistung benötigt, kommt um ATI im Moment nicht herum. Gerade deswegen ist es ja so schade, daß die Software der Hardware bei ATI so stark hinterher hinkt. Mit einem ordentlichen SDK hätte man einen Großteil des Marktes für wissenschaftliche Anwendungen erobern können. Zumal man eigentlich auch ordentlich Vorlauf hatte, da ja schon der RV670 mit doubles rechnen kann, nvidia aber erst seit den GTX 2xx (und das noch nicht mal schneller als ATIs alte Gurken).

[Coda]

Die Hardware kann bei nvidia auch nicht mehr rechnen als bei ATI
Sie kann es wesentlich genauer.

[Gipsel]

Sie kann es wesentlich genauer.
Das glaube ich kaum, sowohl ATI als auch nvidia spucken mit doubles (64Bit floats) IEEE754 konforme Werte aus (<= 0.5 ulp). Der Unterschied zur Berechnung auf CPUs (und zur vollen IEEE754 Konformität) liegt bei beiden im Prinzip nur in eingeschränkten Rundungsmodi (gibt nur die gebräuchlichsten) und das normalerweise denormals auf 0 geflushed werden (gebräuchliche Option bei SSE-Anweisungen, ist auch schneller).
Die fehlende Hardwareunterstützung für komplexe Funktionen, die über Bibliotheken nachgebildet werden müssen trifft ebenfalls auf beide zu (kann man aber auch locker IEEE konform hinkriegen, einfach die math.lib von gcc portieren ;)).

[reunion]

Das sind ja interessante Aussagen, da gerade auch hier im Forum AMDs DP-Fähigkeit als ungenau und featuremäßig unterlegen belächelt wurde. Wenn das wirklich so ist dann stellt sich die Frage warum nV überhaupt extra DP-Einheiten integriert hat.

[Gipsel]

dann stellt sich die Frage warum nV überhaupt extra DP-Einheiten integriert hat.
Weil das mit ihren skalaren SP-Einheiten nicht so gut geht (geht nur über ziemlich aufwendige Multi-Pass-Verfahren, zwei oder auch drei Durchläufe werden für volle 64Bit Genauigkeit nicht ausreichen). Offensichtlich verspricht sich nvidia von den extra DP-Einheiten, die nur etwa 8% der Peakleistung der SP-Shader erreichen, mehr Performance als von solchen Softwarelösungen. Sonst hätten sie das ja nicht eingebaut, oder?

Durch die stärkere Kopplung der 32Bit-Shader in einer VLIW-Einheit (das ist ja nicht wirklich eine 4D+1 Vektor-Einheit, wie häufig gesagt, sondern eher 5 skalare mit Einschränkungen bei Wahl des Destination-Registers, man kann auch 5 unterschiedliche Befehle in einem Takt absetzen) haben die ATIs den Vorteil, daß das mit weniger Aufwand (keine Extraeinheiten) einfach dort geht (analog zu den SSE/2-Einheiten in CPUs, die ja entweder vier 32Bit floats oder zwei 64 Bit doubles rechnen können). Dadurch erreicht ATI bei DP mit den gleichen Einheiten, die auch für SP genutzt werden, 20% (FMA, MUL) bis 40% (ADD) des Durchsatzes von SP. Vom Design her auf jeden Fall eleganter würde ich mal behaupten.

[reunion]

Aja danke, hatte mir sowas schon gedacht. Da scheint der Weg über Vec5-ALUs auch in Hinsicht GPGPU der wesentlich sinnvollere gewesen zu sein, gerade wenn man sich ansieht das die paar DP-ALUs bei GT200 ja ganz schon Transistoren zu verschlingen scheinen. Und woher kommt die doppelte ADD Leistung? Ich dachte immer das eine Vec5-ALUs jeweils ein DP MADD ausspucken kann.

[Gipsel]

Und woher kommt die doppelte ADD Leistung? Ich dachte immer das eine Vec5-ALUs jeweils ein DP MADD ausspucken kann.
Im Prinzip hat so eine VLIW-Einheit (RV770 hat 10x16 davon) ja 5 Instruktionsslots. Für MULs und FMAs müssen 4 davon gekoppelt werden, so daß 4 Slots dafür draufgehen (der fünfte Slot kann gleichzeitig noch irgendwas 32bittiges anderes machen). DP-ADDs belegen aber nur 2 Slots, davon können also maximal 2 pro Takt von so einer VLIW-Einheit ausgeführt werden können (die fünfte Einheit kann wieder noch für irgendwas anderes benutzt werden).

Wenn man ein wenig mehr Hardware investiert, würde man auch bei MULs und FMAs mit 2 Slots auskommen. Aber dafür ist der Markt dann wohl doch zu klein. Außerdem wäre dann der Vorteil der ATIs bei DP schon obszön zu nennen (wären 480 DP GFlops gegenüber den 78GFlops einer GTX280) ;)

[Coda]

Das glaube ich kaum, sowohl ATI als auch nvidia spucken mit doubles (64Bit floats) IEEE754 konforme Werte aus (<= 0.5 ulp).
ATI kann keine Denorms mit double. Es gibt schon auch Nachteile wenn man Multipass rechnet.

Aja danke, hatte mir sowas schon gedacht. Da scheint der Weg über Vec5-ALUs auch in Hinsicht GPGPU der wesentlich sinnvollere gewesen zu sein
Was heißt hier "auch". Ansonsten hat das Konzept schlicht und einfach praktisch nur Nachteile. PowerVR verwendet genauso Skalareinheiten, nicht nur NVIDIA.

Mich würde es sehr stark verwundern wenn wir bei der nächsten echten Generation von ATI das noch sehen werden. Das können sie sich allein von der Verlustleistungseffizienz nicht erlauben.

[Gipsel]

ATI kann keine Denorms mit double. Es gibt schon auch Nachteile wenn man Multipass rechnet.
Das mit den Dernomals habe ich gesagt (nvidia kann bei singles übrigens auch keine). Denormals will man in einem Algo aber so oder so vermeiden, da dann die Genauigkeit sowieso hin ist (oder rechne das mal auf einer CPU, das wird ziemlich langsam).
Und ATI macht kein Multipass.

Mich würde es sehr stark verwundern wenn wir bei der nächsten echten Generation von ATI das noch sehen werden. Das können sie sich allein von der Verlustleistungseffizienz nicht erlauben.
Eigentlich ist es durch etwas eingesparte Kontrollogik effizienter, wenn der Compiler clever genug ist (und das Problem es erlaubt) die Instruktionsslots der Einheiten halbwegs voll zu bekommen.

[Coda]

Das mit den Dernomals habe ich gesagt (nvidia kann bei singles übrigens auch keine). Denormals will man in einem Algo aber so oder so vermeiden, da dann die Genauigkeit sowieso hin ist (oder rechne das mal auf einer CPU, das wird ziemlich langsam).
Ich weiß dass Denormals auf einer CPU extrem langsam werden, aber GT200 kann sie Full Speed.

Die Genauigkeit ist bei Denormals eben nicht hin. Nur wenn man Denormals are Zero macht ist das so.

Eigentlich ist es durch etwas eingesparte Kontrollogik effizienter, wenn der Compiler clever genug ist (und das Problem es erlaubt) die Instruktionsslots der Einheiten halbwegs voll zu bekommen.
"halbwegs voll" bedeutet in der Praxis zwischen 3 und 4 Slots.

Das ist nicht energieeffizient, weil man währendessen nicht das Taktsignal für die Einheit abschalten wird die ein NOP durchlaufen lässt. Bei Chips die bald 200W brauchen kann man sich das über den Chip gesehen einfach nicht mehr erlauben mal 30% mehr Energie in den ALUs zu verpulvern als überhaupt benötigt.

Genau den gleichen Tod ist auch Netburst gestorben mit ihrem Replay-Kram.

Die Kontrollogik von der G80-Architektur ist imho auch nicht größer als die der R600-Generation. Es sind im wesentlich nur mehr Threads In-Flight nötig um das vertikale Konzept zu verwenden.

[reunion]

Was heißt hier "auch". Ansonsten hat das Konzept schlicht und einfach praktisch nur Nachteile.

Nur Nachteile? Wenn ich mir den Vergleich RV770 vs. GT200 ansehe dann erreicht RV770 bei kaum mehr als der halben Die-Size eine höhere Rechenleistung sowohl unter SP als gerade auch unter DP. Klar hat GT200 Vorteile bei der TEX-Leistung, aber so nachteilig kann das Konzept wohl nicht sein. Alleine schon die ALUs bei GT200 benötigen mehr Platz als ein gesamtes RV770 Die.

[Coda]

Du kannst auch nicht über den Tellerrand denken oder?

GT200 ist ein Hängemattendesign, während ATI bei RV770 extrem im Zugzwang war. Nur weil die derzeitige Implementierungen so aussehen hat das noch lange nichts mit der Überlegenheit des Grundkonzepts zu tun. ATI kann vor allem die Transistoren dichter packen im Moment. Das ist aber vor allem Fleißarbeit der Layouter und Schaltungsdesigner.

In der Energieeffizienz sind sie bei gleichem Prozess jetzt schon deutlich hinterher (weniger Transistoren und mehr Verlustleistung, siehe GT200B ggü. RV770). Das kann mit 40nm nur noch schlimmer werden, weil die Prozesse leaken immer mehr.

Die Möglichkeit eines Vektordesigns hat man bei NVIDIA sicher auch evaluiert. Die Erfindungshöhe von einer splitbaren Vec5-ALU ggü. dem vertikalen Konzept ist wesentlich geringer.

[Gast]

Und ich dachte für HD-Beschleunigung wurde bisher meist ATI favorisiert ;)

nö, die performance ist bei beiden ausreichend, bei ATI ist aber die die BQ bei den IGPs leider deutlich schlechter.

[reunion]

Du kannst auch nicht über den Tellerrand denken oder?

Du solltest lieber mal vor der eigenen Haustüre kehren.


GT200 ist ein Hängemattendesign, während ATI bei RV770 extrem im Zugzwang war.

Wenn man sich die Dice so ansieht könnte man zum gegenteiligen Schluss kommen.


Nur weil die derzeitige Implementierungen so aussehen hat das noch lange nichts mit der Überlegenheit des Grundkonzepts zu tun. ATI kann vor allem die Transistoren dichter packen im Moment. Das ist aber vor allem Fleißarbeit der Layouter und Schaltungsdesigner.

Auch die Transistorenanzahl ist um fast 50% höher. Mag sein das skalare ALUs in Zukunft besser sein werden, wir werden sehen für was man sich entscheidet. Aber momentan sieht es nicht unbedingt so aus.


In der Energieeffizienz sind sie bei gleichem Prozess jetzt schon deutlich hinterher (weniger Transistoren und mehr Verlustleistung, siehe GT200B ggü. RV770). Das kann mit 40nm nur noch schlimmer werden, weil die Prozesse leaken immer mehr.


Bei den unzähligen Redesigns und Respins der Gt200(b)s könnte ich jetzt genau so frei nach dir sagen: "Nur weil die derzeitige Implementierungen so aussehen hat das noch lange nichts mit der Überlegenheit des Grundkonzepts zu tun." NV hat vielleicht einfach nur mehr in den Stromverbrauch investiert um irgend wie noch eine GX2 herausquetschen zu können. Und ein GT200b verbraucht auch noch immer mehr als ein RV770 (zugegebenermaßen natürlich bei mehr Leistung). Die Chipspannung ist bei NV allerdings auch bedeutend geringer.

[LovesuckZ]

Bei den unzähligen Redesigns und Respins der Gt200(b)s könnte ich jetzt genau so frei nach dir sagen: "Nur weil die derzeitige Implementierungen so aussehen hat das noch lange nichts mit der Überlegenheit des Grundkonzepts zu tun." NV hat vielleicht einfach nur mehr in den Stromverbrauch investiert um irgend wie noch eine GX2 herausquetschen zu können. Und ein GT200b verbraucht auch noch immer mehr als ein RV770 (zugegebenermaßen natürlich bei mehr Leistung). Die Chipspannung ist bei NV allerdings auch bedeutend geringer.

"Redesigns"? AMD benötigte zwei Redesigns, um überhaupt mit dem G80 mithalten zu können. Mit dem G92(b) befindet man sich auf einem technologischen Level von 2006 und dieses Level reicht vollkommen aus, um mit AMD mitzuhalten. Den Aufwand, den AMD betrieben haben muss, um überhaupt auf Augenhöhe zu sein, ist unverhaltensmäßig hoch. Da kann man noch immer so schön auf den GT200 verweisen, aber das Macht den rv770 nicht besser.

[deekey777]

"Redesigns"? AMD benötigte zwei Redesigns, um überhaupt mit dem G80 mithalten zu können. Mit dem G92(b) befindet man sich auf einem technologischen Level von 2006 und dieses Level reicht vollkommen aus, um mit AMD mitzuhalten. Den Aufwand, den AMD betrieben haben muss, um überhaupt auf Augenhöhe zu sein, ist unverhaltensmäßig hoch. Da kann man noch immer so schön auf den GT200 verweisen, aber das Macht den rv770 nicht besser.
Als mit der Entwicklung des RV770 2005 begonnen wurde, wusste man bei ATi, was sie machen müssen, um mit dem G80 GT200 auf der Augenhöhe zu sein? :| Und nein, der RV770 ist kein Re-Design des R600.

Ach, was freue ich mich auf OpenCL, wenn es sich herausstellt, dass nur RV770 und alle Geforces ab G80 OpenCL-fähig ist.

[Gast]

Weil das mit ihren skalaren SP-Einheiten nicht so gut geht (geht nur über ziemlich aufwendige Multi-Pass-Verfahren, zwei oder auch drei Durchläufe werden für volle 64Bit Genauigkeit nicht ausreichen). Offensichtlich verspricht sich nvidia von den extra DP-Einheiten, die nur etwa 8% der Peakleistung der SP-Shader erreichen, mehr Performance als von solchen Softwarelösungen. Sonst hätten sie das ja nicht eingebaut, oder?

Durch die stärkere Kopplung der 32Bit-Shader in einer VLIW-Einheit (das ist ja nicht wirklich eine 4D+1 Vektor-Einheit, wie häufig gesagt, sondern eher 5 skalare mit Einschränkungen bei Wahl des Destination-Registers, man kann auch 5 unterschiedliche Befehle in einem Takt absetzen) haben die ATIs den Vorteil, daß das mit weniger Aufwand (keine Extraeinheiten) einfach dort geht (analog zu den SSE/2-Einheiten in CPUs, die ja entweder vier 32Bit floats oder zwei 64 Bit doubles rechnen können). Dadurch erreicht ATI bei DP mit den gleichen Einheiten, die auch für SP genutzt werden, 20% (FMA, MUL) bis 40% (ADD) des Durchsatzes von SP. Vom Design her auf jeden Fall eleganter würde ich mal behaupten.

Danke für deine Ansichten - einige Dinge hat Coda ja auch noch beigetragen.
Du siehst also für AMD-Hardware keine wie schwer auch immer wiegenden Nachteile bei der DP-Unterstützung durch diese Dinge wie NaN-Support, DFMA, Overflow/Inifinty (frag nicht -> gegooglet!) oder full-speed denorms für die Nvidia es offenbar extra für nötig befunden hat, Hardware einzubauen?

Carsten

[Gast]

Da kann man noch immer so schön auf den GT200 verweisen, aber das Macht den rv770 nicht besser.
Wieso? Der ist doch so schon ziemlich gut.

Carsten

[Coda]

Du solltest lieber mal vor der eigenen Haustüre kehren.
Sicher nicht.

Wenn man sich die Dice so ansieht könnte man zum gegenteiligen Schluss kommen.
Bitte was?

Bist du wirklich der Meinung GT200 sei das Ergebnis einer enormen Anstrengung gegeben? Also mir kommt das Ding wirklich so vor, als hätte man sich ziemlich überheblich gefühlt.

Auch die Transistorenanzahl ist um fast 50% höher. Mag sein das skalare ALUs in Zukunft besser sein werden, wir werden sehen für was man sich entscheidet. Aber momentan sieht es nicht unbedingt so aus.
Momentan sieht was nicht so aus? Du weißt überhaupt nichts über das nächste AMD-Design.

Bei der Chipspannung hast du natürlich schon recht.

[Gast]

Auch die Transistorenanzahl ist um fast 50% höher. Mag sein das skalare ALUs in Zukunft besser sein werden, wir werden sehen für was man sich entscheidet. Aber momentan sieht es nicht unbedingt so aus.


mit gleichem unterbau erreicht NV mit ca. 3/4 der transistoren fast die gleiche leistung und das bei besserer bildqualität.

[LovesuckZ]

Wieso? Der ist doch so schon ziemlich gut.

Carsten

GT200 oder rv770? :confused:
Keiner der beiden ist "schon ziemlich gut", wenn man es mit dem G80 vergleicht. Selbst beim Vergleich mit dem G92 sind es eher lauwarme Updates als überragende Chips.

[Gipsel]

Ich weiß dass Denormals auf einer CPU extrem langsam werden, aber GT200 kann sie Full Speed.

Die Genauigkeit ist bei Denormals eben nicht hin. Nur wenn man Denormals are Zero macht ist das so.
Also wenn man schnellen Code haben will, der auch noch genau rechnet, dann achtet man tunlichst darauf, daß man keine Denormals auftauchen. Das dürfte bei ziemlich vielen wissenschaftlichen Codes der Fall sein. Die existieren ja schon und wurden bisher eben auf CPUs gerechnet.
Und daß mit Denormals die Genauigkeit im Eimer ist dürfte eigentlich klar sein. Wenn von den 53Bit Mantisse nur noch 20 oder so übrig sind, kann man sich die Auflösung sehr wohl in die Haare schmieren.

"halbwegs voll" bedeutet in der Praxis zwischen 3 und 4 Slots.

Das ist nicht energieeffizient, weil man währendessen nicht das Taktsignal für die Einheit abschalten wird die ein NOP durchlaufen lässt.
3 bis 4 ist das, was man wirklich in der Praxis als Durchschnitt sieht, da sind wir uns einig. Meiner Vermutung nach ist das sehr nahe am break even. Wenn Du genaue Daten hast (und nicht ebenfalls nur Deine Vermutung), dann laß sehen.
Genau den gleichen Tod ist auch Netburst gestorben mit ihrem Replay-Kram.Und nochmal, die ATIs benutzen kein Multipass-Verfahren.

Die Möglichkeit eines Vektordesigns hat man bei NVIDIA sicher auch evaluiert. Die Erfindungshöhe von einer splitbaren Vec5-ALU ggü. dem vertikalen Konzept ist wesentlich geringer.
Hatte das ja schon mal angesprochen, aber ein wenig flexibler als ein einfaches SIMD-Vektor-Design ist das schon. Im Prinzip sind es 5-issue VLIW Einheiten. Man kann durchaus 5 verschiedene Befehle absetzen, die auf unterschiedlichen Registern arbeiten.
Danke für deine Ansichten - einige Dinge hat Coda ja auch noch beigetragen.
Du siehst also für AMD-Hardware keine wie schwer auch immer wiegenden Nachteile bei der DP-Unterstützung durch diese Dinge wie NaN-Support, DFMA, Overflow/Inifinty (frag nicht -> gegooglet!) oder full-speed denorms für die Nvidia es offenbar extra für nötig befunden hat, Hardware einzubauen?
NaNs, Inf usw können die ATIs auch, bloß eben keine Denormals (die sind durch flush to zero aber auch full speed ;)). Kann ja sein, daß man das in ein paar Einzelfällen benötigt, aber daß das kein Showstopper ist, zeigt ja auch daß die nvidias das auch nur mit doubles können. Die meisten CUDA-Anwendungen bisher laufen ja mit floats.
Bei performancekritischen Code auf CPUs (SSEx), aktiviert man übrigens auch häufig die Option "flush denormals to zero".

Also falls irgendein Algo wirklich darauf angewiesen ist, daß denormals unterstützt werden, würde ich den Algo wegwerfen. Der ist dann nämlich in meinen Augen ein wenig knapp geplant. In meinen Augen ist das eher ein nice to have feature.

[reunion]

Bitte was?

Bist du wirklich der Meinung GT200 sei das Ergebnis einer enormen Anstrengung gegeben? Also mir kommt das Ding wirklich so vor, als hätte man sich ziemlich überheblich gefühlt.

GT200 ist jedenfalls der mit Abstand größte Endkunden-Chip der jemals verkauft wurde. Dazu das 512-bit SI. NV hat damit sicher geklotzt und nicht gekleckert. Ein "Hängemattendesign" sieht anders aus.


Momentan sieht was nicht so aus? Du weißt überhaupt nichts über das nächste AMD-Design.

Bei der Chipspannung hast du natürlich schon recht.

Natürlich weiß ich darüber nichts. Das war rein meine persönliche Meinung aufgrund der momentanen Situation.

[LovesuckZ]

GT200 ist jedenfalls der mit Abstand größte Endkunden-Chip der jemals verkauft wurde. Dazu das 512-bit SI. NV hat damit sicher geklotzt und nicht gekleckert. Ein "Hängemattendesign" sieht anders aus.


Wie denn? :rolleyes:
Ist also der rv770 ein "Hängemattendesign", weil er nur 260mm^2 groß ist? Oder ist es ein GT200, weil er auf der grundsätzlichen Architektur des G80 aufbaut? Nur weil der GT200 groß ist, bedeutet das nicht, dass viel Arbeit in ihm investiert wurde. Alleine nur der Vergleich zwischen dem G80 und dem G70 zeigt, dass beim GT200 wohl eher gekleckert statt geklotzt wurde.

[Gast]

Kleines Beispiel gefällig, reunion?
Was folgt ist "analog" ein Hängematten-Posting:

GT200 ist jedenfalls der mit Abstand größte Endkunden-Chip der jemals verkauft wurde. Dazu das 512-bit SI. NV hat damit sicher geklotzt und nicht gekleckert. Ein "Hängemattendesign" sieht anders aus.
[...]
Natürlich weiß ich darüber nichts. Das war rein meine persönliche Meinung aufgrund der momentanen Situation...........
Du siehst, ich habe lediglich eine winzige Änderung an deinem Posting vorgenommen, und zwar ein "[...]" eingefügt sowie Punkte ans Ende gehängt. Nun kommt nur Copy And Paste:

GT200 ist jedenfalls der mit Abstand größte Endkunden-Chip der jemals verkauft wurde. Dazu das 512-bit SI. NV hat damit sicher geklotzt und nicht gekleckert. Ein "Hängemattendesign" sieht anders aus.
[...]
Natürlich weiß ich darüber nichts. Das war rein meine persönliche Meinung aufgrund der momentanen Situation...........
GT200 ist jedenfalls der mit Abstand größte Endkunden-Chip der jemals verkauft wurde. Dazu das 512-bit SI. NV hat damit sicher geklotzt und nicht gekleckert. Ein "Hängemattendesign" sieht anders aus.
[...]
Natürlich weiß ich darüber nichts. Das war rein meine persönliche Meinung aufgrund der momentanen Situation...........
GT200 ist jedenfalls der mit Abstand größte Endkunden-Chip der jemals verkauft wurde. Dazu das 512-bit SI. NV hat damit sicher geklotzt und nicht gekleckert. Ein "Hängemattendesign" sieht anders aus.
[...]
Natürlich weiß ich darüber nichts. Das war rein meine persönliche Meinung aufgrund der momentanen Situation...........

Beispiel angekommen? ;)

Carsten

[deekey777]

...


3 bis 4 ist das, was man wirklich in der Praxis als Durchschnitt sieht, da sind wir uns einig. Meiner Vermutung nach ist das sehr nahe am break even. Wenn Du genaue Daten hast (und nicht ebenfalls nur Deine Vermutung), dann laß sehen.
Und nochmal, die ATIs benutzen kein Multipass-Verfahren.


...
Geht es um die VLIW-Auslastung? Die einzige Aussage, die als offiziell gelten kann, ist die von Mike Houston bezüglich des GPU2-F@H-Clients: http://foldingforum.org/viewtopic.php?f=51&t=4879&start=45#p50698

Dumm ist, dass Brook+ kein float5 beherrscht, womit die vollständige VLIW-Auslastung nicht einfach ist (wenn man den Stream-Nutzern glauben kann). Trotzdem glaube ich, dass die VLIW-Auslastung höher ist als die in den Spielen.

[Gipsel]

Geht es um die VLIW-Auslastung? Die einzige Aussage, die als offiziell gelten kann, ist die von Mike Houston bezüglich des GPU2-F@H-Clients: http://foldingforum.org/viewtopic.php?f=51&t=4879&start=45#p50698

Dumm ist, dass Brook+ kein float5 beherrscht, womit die vollständige VLIW-Auslastung nicht einfach ist (wenn man den Stream-Nutzern glauben kann). Trotzdem glaube ich, dass die VLIW-Auslastung höher ist als die in den Spielen.
Na dann ist das bei Folding ziemlich gut, die 3.5 bis 4 belegten slots habe ich mal in irgendeiner Statistik über ein paar hundert Shader aus Spielen gesehen.
Und float5 würden wegen einer Hardwarebeschränkung der R600 und aufwärts nicht gut funktionieren (read/write ports).
Der 5. Slot ist ganz nützlich beim Rechnen mit float4, da immer mal eine Adressberechnung, irgendein move anfällt oder ein Schleifenzähler erhöht werden muß usw. Sowas quetscht der Compiler normalerweise irgendwie dahin (außer den transzendenten Funktionen). Aber um über 4.5 im Schnitt zu kommen, muß man sich schon sehr exotischen Code ausdenken.

Eine wirklich vollständige VLIW-Auslastung ist aber aus Performancesicht auch gar nicht nötig um gegen nvidia anzustinken. Da die RV770 auf dem Papier schon mal glatt 20% mehr Shaderleistung als die GT200 besitzen, können die sich erlauben, öfter mal den fünften Slot frei zu lassen ;)
Und das mit dem FMA + MUL bei den nvidias klappt ja auch längst nicht immer. Und ohne das ist der Vorteil auf dem Papier für ATI sogar noch größer.

[Coda]

GT200 ist jedenfalls der mit Abstand größte Endkunden-Chip der jemals verkauft wurde. Dazu das 512-bit SI. NV hat damit sicher geklotzt und nicht gekleckert. Ein "Hängemattendesign" sieht anders aus.
Was hat die Größe des Dies damit zu tun wieviel Arbeit investiert wurde um die einzelnen Schaltungen zu optimieren? Richtig: Nichts.

Man dachte man könne es sich leisten das riesige Die zu fahren. Ist nach hinten los gegangen.

Zum Vergleich: ATI hat die ALUs auf fast 50% der ursprünglichen Größe bei gleichem Prozess geschrumpft. Bei NVIDIA hat sich nichts in dieser Richtung getan.

[Gast]

Zum Vergleich: ATI hat die ALUs auf fast 50% der ursprünglichen Größe bei gleichem Prozess geschrumpft. Bei NVIDIA hat sich nichts in dieser Richtung getan.
An den einzelnen SIMDs gabs aber auch ein paar Einsparungen gegenüber den ganzen Verbesserungen. Ansonsten wäre sicherlich nicht so ein tolles Ergebnis dabei herausgekommen.


Carsten

[Coda]

Also ich empfinde GT200 nicht gerade als toll, sorry.

Hätte RV770 anständige TMUs und vernünftigere Treiber, dann wäre für mich die Entscheidung sehr einfach gewesen.

[Triskaine]

Was soll an den TMus des RV770 schlecht sein? Davon abgesehen das der GT200 mehr von ihnen hat.

[Coda]

Was soll an den TMus des RV770 schlecht sein?
Sie unterfiltern. Auch mit ausgeschaltetem A.I.

Und mit A.I. ist es wirklich extrem schlecht was abgeliefert wird. Das muss 2009 einfach nicht mehr sein.

[Gast]

Sie unterfiltern. Auch mit ausgeschaltetem A.I.

Und mit A.I. ist es wirklich extrem schlecht was abgeliefert wird. Das muss 2009 einfach nicht mehr sein.

Das ist aber wohl eher eine Treiberangelegenheit.

[S940]

An den einzelnen SIMDs gabs aber auch ein paar Einsparungen gegenüber den ganzen Verbesserungen. Ansonsten wäre sicherlich nicht so ein tolles Ergebnis dabei herausgekommen.
Soviel ich mal bei nem review gelesen hab, wurden die sogar komplexer, die unterstützen bei den R7xx z.B. jetzt alle auch bit shifts, dazu kam auch ein lokaler Cache:
http://images.bit-tech.net/content_images/2008/09/ati-radeon-4850-4870-architecture-review/sp1.jpg
http://www.bit-tech.net/hardware/graphics/2008/09/02/ati-radeon-4850-4870-architecture-review/7

ciao

Alex

[Coda]

Das ist aber wohl eher eine Treiberangelegenheit.
Eher nicht, sonst würde A.I. off nicht auch das Verhalten zeigen.

Ich glaube nicht, dass die TMUs überhaupt im Stande sind ordentlich zu filtern. Da wurden wohl auch Transistoren gespart.

[|MatMan|]

Ich habe jetzt erst ein einziges Problem auf einer GPU implementiert (Milkyway@home GPU-Applikation für ATIs), aber das rennt wie die Sau auf ATIs mit double precision. Eine HD4870 schafft real gemessen ziemlich genau das Doppelte der theoretischen Peakleistung einer GTX280. Was bei nvidia davon real bei rumkommt, muß sich erst noch zeigen, aber meine Vermutung wäre das eine GTX295 (mit 2 GPUs) etwa die Leistungsfähigkeit einer einzelnen HD4850 erreichen könnte (vielleicht auch nur HD4830-Niveau).
Schreib doch mal einen Milkyway@home-CUDA-Client - da hätte man mal einen direkten Vergleich in einer realen Anwendung! :)

[Gipsel]

http://www.bit-tech.net/hardware/graphics/2008/09/02/ati-radeon-4850-4870-architecture-review/7
In dem Artikel zu den Folien stehen aber auch einige falsche Sachen. Die t-Einheit (nennen die fat unit im Artikel) hat mit den double Rechnungen herzlich wenig zu tun. Das ist sogar die, die immer unbeteiligt ist. Die dort erwähnten "quite serious performance penalties" beim Mischen von single und double Instruktionen ist auch überhaupt nicht existent. Man kann beides sogar in einer einzigen Anweisung für so eine VLIW-Einheit (ALU clause mit 5 Instruktionsslots, double-Anweisungen nehmen 2 oder 4 Slots ein) ohne irgendwelche Geschwindigkeitseinbußen kombinieren.
Schreib doch mal einen Milkyway@home-CUDA-Client - da hätte man mal einen direkten Vergleich in einer realen Anwendung! :)
Das macht das Projekt gerade selber (sollte recht schnell gehen). Mal sehen, was bei rauskommt ;)

[infinity]

http://www.tweakpc.de/news/15700/cuda-beschleunigt-nero/

oh man ey... Also langsam muss sich ATI doch mal an den Kopf fassen oder nicht?...
Ich hatte eigentlich vor mir demnächst mal eine ATI HD4670 wegen der niedrigen Leistungsaufnahme zu greifen... das hier ist zwar jetzt etwas offtopic, aber da hier in diesem Unterforum sowohl User von ATI als auch von Nvidia drin sind, hätte ich mal ne Frage was wie die Unterschiede in der TV-Out-Unterstützung zwischen Radeons und Nvidia Karten sind? Idle-Leistungsaufnahme bei Performance-Karten sind nun ja bei nVidia mittlerweile deutlich besser und CUDA ist nun auch eigentlich ziemlich vorteilhaft beim Encodieren usw. (x264 usw. ist mir wichtig).

Früher war die TV-Out-Qualität bei ATI ja angeblich besser... hab eine Radeon 9800 Pro und da gehts noch. Ist dies nun bei Nvidia besser geworden? (Seit der 9800er zeit ist ja viel neues gekommen denk ich ;) )

[Gast]

Haben aktuelle Karten überhaupt noch einen analogen TV-Out oder gibt es da nur noch HD über HDMI?

[h'lore]

Meine 9600GT bietet noch die Möglichkeit eine Kabelpeitsche mit analogen Videoausgängen (Component, S-Video, Composite) anzuschließen.

[deekey777]

Haben aktuelle Karten überhaupt noch einen analogen TV-Out oder gibt es da nur noch HD über HDMI?
Ja, aber nicht selten (eigentlich eher öfter) sind Billigteile wie meine HD3850 ohne TV-Out.

[Mr. Lolman]

Meine 9600GT bietet noch die Möglichkeit eine Kabelpeitsche mit analogen Videoausgängen (Component, S-Video, Composite) anzuschließen.

Die HD4870 genauso...

http://www.tweakpc.de/news/15700/cuda-beschleunigt-nero/

oh man ey... Also langsam muss sich ATI doch mal an den Kopf fassen oder nicht?...
Ich hatte eigentlich vor mir demnächst mal eine ATI HD4670 wegen der niedrigen Leistungsaufnahme zu greifen... das hier ist zwar jetzt etwas offtopic, aber da hier in diesem Unterforum sowohl User von ATI als auch von Nvidia drin sind, hätte ich mal ne Frage was wie die Unterschiede in der TV-Out-Unterstützung zwischen Radeons und Nvidia Karten sind? Idle-Leistungsaufnahme bei Performance-Karten sind nun ja bei nVidia mittlerweile deutlich besser und CUDA ist nun auch eigentlich ziemlich vorteilhaft beim Encodieren usw. (x264 usw. ist mir wichtig).

http://www.computerbase.de/news/hardware/grafikkarten/2009/februar/powerdirector_ati_stream_cuda/

Mal abgesehen davon, dass Ati ja auch den AVIVO Videoconverter anbietet - der entgegen aller Unkenrufe sehr wohl die GPU zur Berechnung nutzt (zumindest mit dem Catalyst 9.2 - ältere Catalysts hab ich auf der HD4870 nicht getestet)

[Savay]

http://www.tweakpc.de/news/15700/cuda-beschleunigt-nero/

oh man ey... Also langsam muss sich ATI doch mal an den Kopf fassen oder nicht?...

und ich persönlich muss mir angesichts der immer wieder auftauchenden "killer" apps für CUDA mal an den kopf fassen... ;D

GPGPU ist ja ne super idee...aber ich habe einfach zweifel das wir vor 2010 und DX11 oder OpenCL auch nur irgendetwas nützliches sehen werden das auch entsprechend ausgereift ist und nen größeren markt erreicht als nur ein paar freaks :rolleyes:

CUDA ist momentan noch ein schönes phantom und ehrlich gesagt IMO nicht mehr wert als nen spielplatz für an GPGPU interessierte programmierer. den echten durchbruch gibts erst dann wenn es eine herstellerübergreifende schnittstelle gibt...aber hauptsache das marketing buzzword "CUDA" wird hier im forum immer schön überstrapaziert ;)

[deekey777]

Ich habe Das Gefühl, dass man hier bloß Nvidias Encoder nutzen wird und nicht eigene auf CUDA portieren. Und das ist qualitativ nicht gerade ähm gut. Das Gleiche macht ja Power Director 7 (egal ob Nvidia oder ATi).

Nur der Vollständigkeit halber.

[Gast]

Ich habe jetzt nicht jeden Beitrag komplett gelesen, aber meiner Meinung nach, machen Intel und AMD/ATI in diesem Bereich alles richtig. Sie überlassen nVidia die Pionierarbeit und warten bis sich daraus evtl. ein Industriestandard entwickelt hat und zahlen später Lizenzgebühren bzw. basteln etwas in Software das vielleicht etwas langsamer ist oder aber OpenCL/DX11 wirds für die beiden richten.

nVidia bleit in der gegenwärtigen Situation gar nichts anderes übrig als Geld in neue Bereiche zu investieren um das eigene Überleben zu sichern. In ein paar Jahren wird die CPU und GPU auf einem Package zu haben sein. Dann hat nVidia im Lowendsegment noch weniger als bisher zu sagen. Der Chipsatzmarkt bricht gerade weg. Das zeigt auch schön der lediglich "umgelabelte" nForce 980a SLI (http://www.computerbase.de/news/hardware/mainboards/amd-systeme/2009/maerz/asus_m4n82_nvidia-nforce-980a-chipsatz/). Da wird im Moment kein Cent mehr als nötig investiert. Gibt ja auch keinen wirklichen Grund mehr für alternative Chipsätze als für jene der CPU-Hersteller. Für die von Intel hat es wohl noch nie einen anderen außer SLI gegeben. O. K. vielleicht auch der Preis. :D
Allein mit der Grafikchipentwicklung/-produktion wird nVidia nicht überleben können. Insbesondere dann wenn Intel mit Larrabee ernst macht und tatsächlich in das Geschäft mit den Midrange- und Highendkarten einsteigt.
Bezeichnend für die Situation ist die Ankündigung von nVidia in das x86-CPU-Geschäft (http://winfuture.de/news,45640.html) für portable Geräte einzusteigen.

Meiner Meinung nach setzen sowol AMD/ATI als auch Intel darauf, das nVidia mittelfristig (5-7 Jahre) vom Markt ganz verschwindet. oO

[deekey777]

AMD to support Nvidia's CUDA technology? (http://www.techradar.com/news/computing-components/graphics-cards/amd-to-support-nvidia-s-cuda-technology--612041)

Wenn das wirklich passieren wird, kann man nur eins sagen: "Na, guten Morgen, Nvidia!"
"In the future you'll be able to run C with CUDA extensions on a broader range of platforms," stated Dally, "so I don't think that will be a fundamental limitation."
Although Dally didn't name AMD outright, he added: "I'm familiar with some projects that are underway to enable CUDA on other platforms."

[_DrillSarge]I[]

AMD 'no comment'
...und wenn doch, dann sag ich nur eins: zu spät! ;)

€: das gerücht ist nun auch nicht wirklich neu.

[deekey777]

I[;7387735']...und wenn doch, dann sag ich nur eins: zu spät! ;)
Vielleicht hat Nvidia wirklich abgewartet, bis AMD ähnliche Hardware anbietet und diese auch über CAL-API nutzbar ist. AMDs Dummheit ist, dass die GPGPU-Entwicklung bei ihnen sehr langsam ist, während Nvidia Berge versetzt.
AMD muss ja nichts kommentieren. Wenn Nvidia wirklich C for CUDA auf Radeons lauffähig macht, dann ist es in erster Linie Bestätigung für AMD, dass ihr offener Ansatz richtig wahr.

€: das gerücht ist nun auch nicht wirklich neu.
Bisher waren es nur Hirngespinste (wie PhysX auf Radeons)

[_DrillSarge]I[]

das cuda-zeugs soll ja auch opencl backend bekommen (oder haben sie es schon? weiss nicht)
cuda -> opencl -> amd ?
vielleicht soll das so realisiert werden.

[deekey777]

Wenn, dann eher so: C for CUDA -> IL-Compiler -> CAL-Treiber -> Radeon.

C for Cuda wird zuerst in IL übersetzt, was der CAL-Treiber dann für die im PC steckende Grafikkarte umwandelt. Bei Nvidia ist es nicht anders, dort ist es PTX als Zwischenstufe.

[_DrillSarge]I[]

nur ist die ganze arbeit dafür JETZT eigentlich fürn arsch. glaube kaum, dass amd jetzt ne kehrtwende macht (ich nehme mal an, dass sie cuda nicht wollten, sondern was eigenes).
(oder amd schaltet nur unglaublich langsam :ugly:)

[S940]

Vielleicht meint der Typ mit "other Plattforms" ja auch Intels Larrabee ;-)

So oder so hört es sich aber komisch an, zu was gibts denn OpenCL ..

ciao

Alex

[deekey777]

Es ist nicht für den Arsch, ganz im Gegenteil: Es wäre sehr, sehr clever von Nvidia das CUDA-Zeug auch auf den Radeons lauffähig zu machen.
CUDA hat sich nicht deswegen durchgesetzt, weil es so toll ist, sondern weil Nvidia alles Mögliche macht, damit CUDA dominierend ist und bleibt.

[_DrillSarge]I[]

CUDA hat sich nicht deswegen durchgesetzt, weil es so toll ist, sondern weil Nvidia alles Mögliche macht, damit CUDA dominierend ist und bleibt.
ja. nur würde amd sich auch blamieren, da sie damit zugeben, dass "ihre" strategie mist ist (was sie ja auch ist. afaik schlecht dokumentiert, kaum software, irgendwie kümmert man sich auch nicht so richtig drum). :D

[Gipsel]

AMD to support Nvidia's CUDA technology? (http://www.techradar.com/news/computing-components/graphics-cards/amd-to-support-nvidia-s-cuda-technology--612041)
Der Kommentar unten drunter trifft es ganz gut. AMD wird den Teufel tun und CUDA unterstützen, jetzt, wo OpenCL vor der Tür steht. Was man sich vorstellen könnte, ist daß nv einen CUDA -> OpenCL CrossCompiler mit in sein CUDA-SDK packt. Oder gibt es sonst noch kreative Ideen?

[BlackBirdSR]

I[;7387796']ja. nur würde amd sich auch blamieren, da sie damit zugeben, dass "ihre" strategie mist ist (was sie ja auch ist. afaik schlecht dokumentiert, kaum software, irgendwie kümmert man sich auch nicht so richtig drum). :D

Nur muss man manchmal in den sauren Apfel beißen, wenn man überhaupt noch mitreden will. GPGPU mag aktuell für viele noch ein nettes Feature sein, nicht mehr - aber in naher Zukunft wird sich das schwer ändern. Wer hier den Zug verpasst, der kann sich auch mit laufen nicht mehr helfen.

[_DrillSarge]I[]

Nur muss man manchmal in den sauren Apfel beißen, wenn man überhaupt noch mitreden will. GPGPU mag aktuell für viele noch ein nettes Feature sein, nicht mehr - aber in naher Zukunft wird sich das schwer ändern. Wer hier den Zug verpasst, der kann sich auch mit laufen nicht mehr helfen.
ja. imo sollte amd seine "marketing-guys" austauschen. bei nv gibts dazu überall pressemeldungen, ankündigungen von partnerschaften mit entwicklern etc. und bei amd hat man auf der website eine 2 zeilen meldung und wenn man glück hat noch nen link zum sdk. so wie ich das mitbekommen habe, hat amd in keinster weise ihre technologie öffentlich "gepusht", dass hat nur nv gemacht (schlagwort physx etc.). letztendlich entscheidet nicht immer die bessere technik.

€: selbiges spiel mit d3d 10.1. da hätt ich doch riesen tam tam gemacht und wäre zu jedem entwickler hingelaufen und hätte direkt ähhh..."unterstützung" als gegenzug für 10.1 support angeboten.

[S940]

Es ist nicht für den Arsch, ganz im Gegenteil: Es wäre sehr, sehr clever von Nvidia das CUDA-Zeug auch auf den Radeons lauffähig zu machen.
CUDA hat sich nicht deswegen durchgesetzt, weil es so toll ist, sondern weil Nvidia alles Mögliche macht, damit CUDA dominierend ist und bleibt.

a) Weiss ich nicht, ob man sagen kann, dass sich CUDA bereits "durchgesetzt" hätte.

b) Was Du mit "Durchsetzen" meinst, ist mMn schlicht und ergreifend nur eine Monopol Stellung. Es gab einfach nichts andres für GPGPU ...

c) Wie das jetzt in Zukuft mit OpenCL und DX11 ausschaut muss man sehen, CUDA hat auf alle Fälle einen dicken Vorsprung, aber auf der andren Seite stehen Schwergewichte wie Intel und M$.

d) Unter dem Konkurrenzdruck könnte man sich jetzt durchaus vorstellen, dass *nV* an einem ATi CUDA bastelt, AMD könnte es egal sein bzw. sie könnten es leicht unterstützen, nach dem Motto: Schaden tuts nichts und die Kosten sind gering ;-)

ciao

Alex

[deekey777]

Der Kommentar unten drunter trifft es ganz gut. AMD wird den Teufel tun und CUDA unterstützen, jetzt, wo OpenCL vor der Tür steht.

AMD muss auch nichts tun, sie bieten doch die nötigen Tools an, um eigene Compiler zu schreiben, oder?

Was man sich vorstellen könnte, ist daß nv einen CUDA -> OpenCL CrossCompiler mit in sein CUDA-SDK packt. Oder gibt es sonst noch kreative Ideen?
Ist das nicht zu kompliziert, oder ist meine Idee zu abwegig?

Was OpenCL angeht:
Damit sich OpenCL durchsetzt, muss es auch so unterstützt werden, wie es Nvidia bei CUDA macht: Jointventure, Lehrgänge an Unis, Unterstützung von Forschungsprojekten usw. Es gibt heute wohl Tausende Studenten, die CUDA kennen und können, weil Nvidia bei deren Ausbildung mithalf. Das muss man nachmachen.

[BlackBirdSR]

Was OpenCL angeht:
Damit sich OpenCL durchsetzt, muss es auch so unterstützt werden, wie es Nvidia bei CUDA macht: Jointventure, Lehrgänge an Unis, Unterstützung von Forschungsprojekten usw. Es gibt heute wohl Tausende Studenten, die CUDA kennen und können, weil Nvidia bei deren Ausbildung mithalf. Das muss man nachmachen.

Ich denke das ist ein zentraler Punkt.
Irgendwie scheint bei vielen die Meinung verankert zu sein, dass jeder nur auf OpenCL wartet und dann endlich den bisherigen Mist loswerden kann. Nur weil OpenCL verfügbar ist, wird nicht jeder seine Entwicklungsumgebung auf den Müll werfen.

[S940]

Nv weicht aus und ATi dementiert:

Nvidia PR told us Dally had probably been referring to something else entirely, like a Linux-based tool designed to compile the CUDA programming model to a CPU architecture, or running C on anything from PCs, to handhelds, to servers and Playstations.

Still, for Cuda to be able to work on AMD GPUs, Nvidia would absolutely need AMD's support. Without it, Nvidia wouldn't be able to get low-level programming access to the GPU to develop the API. Even Nvidia admits that AMD would probably never allow this to happen. As for AMD, the company's point man on Stream seemed amazed we'd even asked.

AMD's Gary Silcott told the INQ "they [Nvidia] would intentionally damage performance to make Nvidia GPUs run the same app better." Then, perhaps thinking better of accusing Nvidia of hypothetical, yet outright, sabotage, Silcott added "Even if it wasn't intentional, it would not be optimized for our instruction set architecture like our own SDK."
http://www.theinquirer.net/inquirer/news/1432307/amd-won-nvidia-cuda-run-gpus

[Coda]

Ich denke das ist ein zentraler Punkt.
Irgendwie scheint bei vielen die Meinung verankert zu sein, dass jeder nur auf OpenCL wartet und dann endlich den bisherigen Mist loswerden kann. Nur weil OpenCL verfügbar ist, wird nicht jeder seine Entwicklungsumgebung auf den Müll werfen.
Vor allem ist OpenCL wirklich anstrengender als CUDA zum entwickeln. Und es ist ja nicht so, als wäre GPGPU an sich einfach.

Es sollte einfach jemand nen CUDA nach OpenCL-Wrapper schreiben. Aber wahrscheinlich scheitert das an der CUDA-Infrastruktur.

[Gast]

I[;7387827']ja. imo sollte amd seine "marketing-guys" austauschen.
Bedingt hast du Recht, AMD scheint wenig Wind um solche Dinge zu machen.
Ebenso waren sie lange Zeit recht zaghaft mit dem vorantreiben von D3D10.1.

Aber: Bei all der positiven Stimmung, die AMD erntet könnte man meinen das sie eine sehr gute Marketingabteilung haben.
Wie auch immer AMD das geschaft hat, es ist eine nicht zu verachtende Leistung und ein ordentlicher Vorteil im Vergleich zur Konkurrenz, wenn sie derart postiv glänzen.

[Exxtreme]

Nv weicht aus und ATi dementiert:




http://www.theinquirer.net/inquirer/news/1432307/amd-won-nvidia-cuda-run-gpus
Teile und herrsche heisst hier das Motto. So verhindert man effektiv, daß sich die Technologie des Mitbewerbers durchsetzt.

[deekey777]

Still, for Cuda to be able to work on AMD GPUs, Nvidia would absolutely need AMD's support. Without it, Nvidia wouldn't be able to get low-level programming access to the GPU to develop the API. Even Nvidia admits that AMD would probably never allow this to happen. As for AMD, the company's point man on Stream seemed amazed we'd even asked.

Wozu braucht Nvidia eine neue API? Es gibt schon eine und nennt sich CAL. Über IL bekommt man auch Zugriff darauf, oder?

Und AMD wird da gar nichts verbieten, denn das ist dieser "für alles offen"-Ansatz.