News ATI Stream SDK Roadmap aufgetaucht

<div class="newsfloatleft"><a href="http://www.amd.com"><img src="http://www.planet3dnow.de/photoplog/file.php?n=9124" border="1" alt="AMD Logo "The future is fusion""></a></div>Im offiziellen OpenCL Entwicklerforum von AMD ist eine Roadmap für die Weiterentwicklung des ATI Stream SDK aufgetaucht. Demnach wird die nächste Version im August 2010 erscheinen und erstmals die Unterstützung für den erst kürzlich verabschiedeten <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=381944">OpenCL 1.1</a> Standard mit sich bringen. Damit werden einige Features, die bisher nur als Extension angeboten wurden, fester Bestandteil von OpenCL. Leider zählt dazu aber auch weiterhin nicht die Unterstützung von Berechnungen mit Gleitkommazahlen doppelter Genauigkeit. AMD bietet zwar bereits heute eine <a href="http://developer.amd.com/support/KnowledgeBase/Lists/KnowledgeBase/DispForm.aspx?ID=88" target="b">entsprechende Extension</a> an, allerdings können damit aktuell nur einfache Additionen, Subtraktionen und Multiplikationen auf der GPU ausgeführt werden. Wenn man komplexere Berechnungen mit doppelter Genauigkeit durchführen will, muss derzeit auf die CPU-Implementierung von OpenCL bei AMD zurückgegriffen werden. Im August sollen weitere Basisoperationen und im Dezember dann endlich auch erste Trigonometrische Funktionen hinzukommen. Zusammen mit der „FFT library“, mit der Funktionen zur Berechnung der Fast-Fourier-Transformation bereitgestellt werden, wird die OpenCL Umsetzung von AMD langsam auch für wissenschaftliche Projekte interessant. Außerdem plant man im Dezember die Veröffentlichung einer ersten Beta-Version des OpenPhysics SDK, was wohl AMDs Gegenstück zu Nvidias PhysX SDK werden soll. Damit kann man <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=369130">ein Jahr nach der Ankündigung</a> der <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1269057977">Open Physics Initiative</a> erste Ergebnisse vorzeigen. Welche neuen Features sonst noch geplant sind, kann dieser Folie entnommen werden:
<p style="clear:left">
<center><a href="http://www.planet3dnow.de/photoplog/file.php?n=10164&w=o" target="b"><img src="http://www.planet3dnow.de/photoplog/file.php?n=10164&w=l" border="1" alt="ATI Stream SDK Roadmap"></a></center>

<a href="http://forums.amd.com/devforum/messageview.cfm?catid=390&threadid=135960&enterthread=y" target="b"><b>Quelle</b></a></p>

<b>Links zum Thema:</b>
<ul><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1272989740">ATI Stream Software Development Kit (SDK) v2.1</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1277300964">AMD FireStream 93xx offiziell angekündigt</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1270841138">MainConcept und AMD geben Zusammenarbeit bekannt</a></li></ul>

Nun ja, man koennte auch sagen, dass es Zeit wird... 'Fusion' steht vor der Tuer!

Schoen, dass etwas im Hintergrund passiert...

auch wenn man das Gefühl hat, dass es nur langsam voran geht, scheint es immerhin voran zu gehen.
Bei AMD scheint sich im Hintergrund in den letzten Jahren doch einiges zum positiven entwickelt zu haben.

Es ist wie verhext. AMD bietet von Hause aus die bzgl. doppelt genauer Arithmetik potentere Hardware (mit HD58XX vergl. mit FERMI), es klemmt aber mal wieder bei der Nutzbarkeit. nVidia hingegen kastriert die Massenmarkt Fermis, bietet aber den besseren Support via OpenCL/CUDA.

AMD sollte jetzt vor allem an der vollständigen C++ Unterstützung arbeiten und vor allem dem RV870 Nachfolger durchgehend mit ECC versehen.

Ohne ECC Schutz für L1/L2 Cache, Memory Bus und DRAM braucht ATi gar keine neue FireStream vorzustellen. Die würde nicht gekauft.

Außerdem sollten sie die Parallel Kernel vom nVidia GF100 kopieren. Ansätze sind beim RV870 schon vorhanden, aber das sollte ausgebaut werden.

SPINA schrieb:

AMD sollte jetzt vor allem an der vollständigen C++ Unterstützung arbeiten und vor allem dem RV870 Nachfolger durchgehend mit ECC versehen.

Ohne ECC Schutz für L1/L2 Cache, Memory Bus und DRAM braucht ATi gar keine neue FireStream vorzustellen. Die würde nicht gekauft.

Außerdem sollten sie die Parallel Kernel vom nVidia GF100 kopieren. Ansätze sind beim RV870 schon vorhanden, aber das sollte ausgebaut werden.

Zum Vergrößern anklicken....

Was diese C++ Geschichte genau bedeuten soll, kann mir vielleicht jemand erklären, denn ich blicke jetzt nicht, warum das so wichtig sein soll.

Ohne ECC kommt man beispielsweise in der Wolke (bezogen auf das Streaming von Videos und Games) aus. Da würde man es wahrscheinlich eh nicht nutzen, da es Performance kostet. Es gibt sicher auch eine Menge weiterer Anwendungen, wo es nicht notwendig ist.

Parallele Kernel sind rein von der Hardware bereits heute möglich. Es hapert am SDK.

siehe hier: klick

Dr@ schrieb:

Ohne ECC kommt man beispielsweise in der Wolke (bezogen auf das Streaming von Videos und Games) aus.

Zum Vergrößern anklicken....

Da braucht es aber auch keine erwähnte FireStream, sondern es tut auch eine FirePro oder Radeon HD.

Dr@ schrieb:

Parallele Kernel sind rein von der Hardware bereits heute möglich. Es hapert am SDK.

Zum Vergrößern anklicken....

Aber wohl in geringerer Anzahl als bei nVidia und dann auch noch mit seriellen Zwischenschritten.

Drohne schrieb:

Es ist wie verhext. AMD bietet von Hause aus die bzgl. doppelt genauer Arithmetik potentere Hardware (mit HD58XX vergl. mit FERMI), es klemmt aber mal wieder bei der Nutzbarkeit. nVidia hingegen kastriert die Massenmarkt Fermis, bietet aber den besseren Support via OpenCL/CUDA.

Zum Vergrößern anklicken....

Das hat nichts mit Hexerei zu tun ... es ist die gute alte eigene AMD-Krankheit Support auf der Softwareseite ... manches ändert sich wohl nie^^

Ich denke, runde Entwicklertools und AMD/ATI-Taskforces mit "gratis" Manpower bei bedeutsamen Softwareschmieden ist wichtiger als ECC-Fehlerkorrektur ... obwohl das auf ganz dicken Eisen sicherlich auch sehr wichtig ist.

SPINA schrieb:

Da braucht es aber auch keine erwähnte FireStream, sondern es tut auch eine FirePro oder Radeon HD.
Aber wohl in geringerer Anzahl als bei nVidia und dann auch noch mit seriellen Zwischenschritten.

Zum Vergrößern anklicken....

Du willst also ne FirePro in nen Sever stecken? Ok (Hat ja auch was mit Support und so zu tun ...)

Wie viele parallele Kernel gehen denn beim Fermi? Ich dachte bisher, es wären zwei?

Dr@ schrieb:

Wie viele Kernel gehen denn beim Fermi? Ich dachte bisher, es wären zwei?

Zum Vergrößern anklicken....

Soweit ich weiß sind es genauso viele, wie es CUDA Cluster gibt. Also 16 im Vollausbau des GF100 mit insgesamt 512 Unified Shadern.

Bei der Tesla C2050 werden es dementsprechend erst einmal nur 15 sein. Da kommen die gegenüber dem RV870 deutlich größeren Caches sehr gelegen.

Kann mir vielleicht jemand mit einfachen Worten erklären, was dieses Stream SDK überhaupt ist?

Bin lediglich mit den Consumer Karten von ATi vertraut und hab keine große Ahnung, was Stream sein soll.
Soweit ich weiß irgendwie ne Konkurrenz zu CUDA oder?

Ich vermutete (aus heiterem Himmel) schon länger eine Einführung von C++ in North-Island.

Und jetzt lese ich da was von C++.

Was meint iher, wie wahrscheinlich ist die Einführung von C++ in North-Island??
(Auch wenn das Softwaremäßig in Dezember kommen soll, kann ich mir es in South-Island nicht vorstellen, da bei South-Island keine neuen Shader kommen sollen.)

SPINA schrieb:

AMD sollte jetzt vor allem an der vollständigen C++ Unterstützung arbeiten und vor allem dem RV870 Nachfolger durchgehend mit ECC versehen.

Zum Vergrößern anklicken....

Ganz meiner Meinung.
ECC einzuführen sollte doch recht schnell gehen, da das doch nur den Speicher-Controller betrifft !!?
Also, in Sept 2009 hat AMD davon bei Fermi erfahren. Also müsste das doch im North-Island möglich sein?

nVidia hingegen kastriert die Massenmarkt Fermis, bietet aber den besseren Support via OpenCL/CUDA.
...
Das hat nichts mit Hexerei zu tun ... es ist die gute alte eigene AMD-Krankheit Support auf der Softwareseite ... manches ändert sich wohl nie^^

Zum Vergrößern anklicken....

Was meint ihr mit Support. Die Performance oder die Unterstützung von Software-Entwicklungen.
Immerhin will man jedes Quartal die Performance (laut Papier) verbessern.

@Topic
Die OpenCL-Roadmap und OpenPhysik-Ankündigung sieht sehr gut aus.
Wahrscheinlich wird AMD in beiden Dingen nie Nvidia überholen, aber sie werden IMO aufholen und irgendwann wird schon so viel unterstützt, dass dann beide in der Masse als gleichwertig angesehen werden.

Zumindestens war das so bei Crossfire. Am Anfang war es Features-mäßig und Performance-Mäßig ordentlich zurück und hatte nicht umsonst 5% Marktanteil. (So wie jetzt AMD im Professionellen Markt)
Mit neuen Features wie CrossfireX (ohne Kabel) sowie die regelmäßigen Performance-Verbesserung konnte AMD Stück für Stück aufholen.
Und irgendwann war dann Crossfire mit HD4870 X2 (bzw. 4000er-Serie als gleichwertig in der Masse angsehen, obwohl SLI AFAIK bis heute etwas besser ist.)

Crossfire gabs schon eine Zeitlang (AFAIK mit 1000er-Serie. Als ich die erste Roadmap über Crossfire sah, AFAIK Ende 2007/Anfang 2008 ist die Entwicklung recht schnell vorangekommen.

Weil es jetzt in SDK auch schon Roadmaps gibt, könnte das auch eben die hohe Priorität zeigen.

Der C++-Template-Support bedeutet nur, dass man nicht mehr mehrere Kernels schreiben muss um verschiedene Datentypen zu unterstützen.

Nehmen wir an wir wollen in einem Kernel Single-Precision (float) und Double-Precision (double) unterstützen. In der aktuellen Fassung von OpenCL müsste man den Code duplizieren und auf den Datentyp anpassen.

Mit Template-Support würde man im Kernel statt dem konkreten Datentypen ein abstrakten Typ wählen und könnte dann automatisch für verschiedene Datentypen den Code generieren.

In CUDA wird dies schon seit längerem unterstützt in OpenCL bisher nicht, da die OpenCL-Laufzeitumgebung "nur" C kann. NVIDIA benutzt in CUDA einen zusätzlichen Compiler-Schritt um die Templates auch in C zu unterstützen.


Die Unterstützung von ECC ist komplexer als nur den Speicherkontroller anzupassen, wenn man durchgängig, d. h. auch innerhalb der Register, unterstützen will. Für Consumer-Karten ist es unnötig für Server- und HPC-Anwendungen dagegen pflicht. Ich halte es für durchaus möglich, dass in den Consumer-Fermis (GF104) die ECC-Unterstützung entfällt, da Sie ohne ECC-RAM auch nur wenig Sinn macht und so Transistoren gespart werden können.

Morrich schrieb:

Kann mir vielleicht jemand mit einfachen Worten erklären, was dieses Stream SDK überhaupt ist?

Bin lediglich mit den Consumer Karten von ATi vertraut und hab keine große Ahnung, was Stream sein soll.
Soweit ich weiß irgendwie ne Konkurrenz zu CUDA oder?

Zum Vergrößern anklicken....

Die Stream SDK (Software Developer Kit) entspricht in etwa dem was Nvidia als CUDA SDK vermarktet.

Ausgerechnet im professionellen Umfeld erfreut sich hingegen CUDA großer Beliebtheit. Der grüne kalifornische Grafikgigant hat dort in etwa 90 Prozent Marktanteil (Quadro, Tesla).
AMDs ATI Fire- und FireStream-Grafikprodukte hingegen sind bei circa. 10 Prozent sehr marginal darin vertreten.

MFG Bobo(2010)

weiß jemand ob es mittlerweile Pläne gibt das ganze mit den gängigen Virtualisierungslösungen kompatible zu machen? Ich hätte hier eine Serveranwendung (die Bearbeitet jede Menge Bilder täglich) die davon durchaus profitieren würde. Eine entsprechende Grafikkarte könnte ich durchaus durchsetzen, aber an einem virtualisiertem System komme ich nicht vorbei. Bei den CPUs geht es ja auch, aber was OpenCL angeht herrscht ziemliche Funkstille.

Es besteht die Möglichkeit, dass man bei Virtualisierungslösungen wie KVM, Xen und VMWare (Server) das PCI-Gerät (in diesem Fall die GPU) durchreichen kann an den Gast.

Voraussetzung ist wohl ein Intel-Chipsatz mit VT-d Support. Ob das wirklich funktioniert kann ich nicht sagen. Ich hab da nur wenig Infos im Netz gefunden.

Zusätzlich brauchst du noch eine 2. GPU für den Host.

Und bei AMD funktioniert das (GPU + CPU in einer virtualisierten Umgebung) theoretisch nur mit dem neuen AMD 890 FX Chipsatz, bzw. dem Opteronbruder davon ... aber auch das ist noch eine sehr rohe Baustelle.

MFG Bobo(2010)

CapJo schrieb:

Es besteht die Möglichkeit, dass man bei Virtualisierungslösungen wie KVM, Xen und VMWare (Server) das PCI-Gerät (in diesem Fall die GPU) durchreichen kann an den Gast.

Voraussetzung ist wohl ein Intel-Chipsatz mit VT-d Support. Ob das wirklich funktioniert kann ich nicht sagen. Ich hab da nur wenig Infos im Netz gefunden.

Zusätzlich brauchst du noch eine 2. GPU für den Host.

Zum Vergrößern anklicken....

Mit KVM+Qemu habe ich es mal geschafft auf einem virtualisiertem WinXP den Treiber einer nVidia-Karte zu installieren ohne, dass die Setup-Routine sich über fehlende Hardware beschwerte. Nach dem Neustart konnte der Treiber allerdings nicht ordentlich geladen werden (das Feature ist auch eher für Netzwerkkarten u.Ä. gedacht) aber Xen soll das wohl mittlerweile können. Allerdings sind Boards+CPUs mit Intel VT-d eher selten - vorallem die Boards streiken hier oft. Wie es bei AMD mit ihrer IOMMU aussieht weiß ich nicht.

Was ich viel lieber im SDK sehen wollen würde, wäre ein Gegenstück zu nVidia Parallel nSight (http://developer.nvidia.com/object/nsight.html). Damit kann man, wenn man 2 Grafikkarten bzw. 2 PCs hat die Kernel direkt auf der GPU debuggen. Debugging ist IMO nach wie vor eines der größten Probleme bei der Programmierung auf der GPU - egal ob GPGPU oder die üblichen Grafikpipeline-Shader.

Bobo_Oberon schrieb:

Ausgerechnet im professionellen Umfeld erfreut sich hingegen CUDA großer Beliebtheit. Der grüne kalifornische Grafikgigant hat dort in etwa 90 Prozent Marktanteil (Quadro, Tesla).
AMDs ATI Fire- und FireStream-Grafikprodukte hingegen sind bei circa. 10 Prozent sehr marginal darin vertreten.

MFG Bobo(2010)

Zum Vergrößern anklicken....

Und weißt du zufällig auch woran das liegt?

Ist AMD einfach nicht performant genud oder gibt es softwareseitige Probleme?
Oder liegt es einfach mal wieder nur am Marketing?

Morrich schrieb:

Und weißt du zufällig auch woran das liegt?

Ist AMD einfach nicht performant genug oder gibt es softwareseitige Probleme?
Oder liegt es einfach mal wieder nur am Marketing?

Zum Vergrößern anklicken....

Ich vermute weniger Manpower.

MFG Bobo(2010)

SPINA schrieb:

Soweit ich weiß sind es genauso viele, wie es CUDA Cluster gibt. Also 16 im Vollausbau des GF100 mit insgesamt 512 Unified Shadern.

Bei der Tesla C2050 werden es dementsprechend erst einmal nur 15 sein. Da kommen die gegenüber dem RV870 deutlich größeren Caches sehr gelegen.

Zum Vergrößern anklicken....

Ich weiß nicht, wo du deine Infos her hast, aber AMD hat mit dem RV870 unter dem aktuellen OpenCL SDK 20 Compute units. Zudem sind die AMD Einheiten auf Vektorberechnungen ausgelegt, während NVIDIA den Weg gewählt hat eher auf Skalare zu optimieren.

Dia
.
EDIT :
.

Morrich schrieb:

Kann mir vielleicht jemand mit einfachen Worten erklären, was dieses Stream SDK überhaupt ist?

Bin lediglich mit den Consumer Karten von ATi vertraut und hab keine große Ahnung, was Stream sein soll.
Soweit ich weiß irgendwie ne Konkurrenz zu CUDA oder?

Zum Vergrößern anklicken....

Stream ist von AMD der Marketingbegriff für GPGPU (allgemeine Berechnungen auf GPUs). Das SDK bietet Beispiele, Hilfen, Tools, Header und Bibliotheken an, um OpenCL und CAL Anwendungen für AMD GPUs zu schreiben, wobei CAL wohl nicht mehr aktiv gepflegt wird. Zudem ist bisher im Catalyst noch keine OpenCL Runtime enthalten, weswegen man zur Ausführung oder Nutzung von OpenCL noch das SDK installieren muss.

Dia

CAL wird schon noch gepflegt - nur nicht so sehr ...

Es wird im Mediabereich verwendet (Cyberlink PowerDVD, Producer; Pinnacle Studio 14 .....) und natürlich auch bei Boinc und deshalb gibts noch "Minipflege", dh Bugfix, Optimierungen etc. Es kommen nur keine neuen Features mehr


Vergesst nicht, dass bei AMD der OpenCL-Support auf CAL aufbaut !!!



Bei Boinc gibts noch keinen OpenCL-Support - aber erste Sampleapps - nur solange OpenCL viel langsamer als CAL ist - warum sollte man da die guten (DNETC,) MW oder CC-Apps ignorieren ?

Bei Collatz schlägt AMD nVIDIA noch immer !

Crashtest schrieb:

Bei Boinc gibts noch keinen OpenCL-Support - aber erste Sampleapps - nur solange OpenCL viel langsamer als CAL ist - warum sollte man da die guten (DNETC,) MW oder CC-Apps ignorieren

Zum Vergrößern anklicken....

CAL - DNETC - CC-Apps



BIIINNNNGOOOOO!

Diapolo schrieb:

Ich weiß nicht, wo du deine Infos her hast, aber AMD hat mit dem RV870 unter dem aktuellen OpenCL SDK 20 Compute units.

Zum Vergrößern anklicken....

Und wieso heißt es dann in den offiziellen ATi Tech Docs:

Multiple ATI Stream applications can be run concurrently, as long as they do not access the same GPU at the same time.

ATI Stream applications that attempt to access the same GPU at the same time are automatically serialized by the runtime system.

Zum Vergrößern anklicken....

Irgendwie widerspricht das den Werbeversprechen. Auch die c't weiß nichts genaues: Klick

Was du schreibst hat ja nichts mit den Ausführungseinheiten einer GPU zu tun, sondern beschreibt das Verhalten, wenn man mehrere OpenCL Anwendungen parallel laufen lässt. Wenn ich also 2 OpenCL Anwendungen starte werden die seriell abgefrühstückt.

Dia