CUDA-Gegenschlag von ATI – ATI Stream

[=Floi=]

http://www.computerbase.de/news/hardware/grafikkarten/ati/2008/november/ati_stream_jedermann_dezember/

So, nun zieht auch ATI nach und ich bin schon auf erste ergebnisse gespannt. Ich hoffe es gibt auch ein programm, das auf beiden karten beschleungit wird und dann geht es rund! ;D

edit
3003 posts ;D

[HarryHirsch]

und wie sie gleich wieder auf die kacke hauen:

http://www.abload.de/img/5l4jr.png (http://www.abload.de/image.php?img=5l4jr.png)

http://www.abload.de/img/6z4tm.png (http://www.abload.de/image.php?img=6z4tm.png)

[V2.0]

AMD hat halt nen Lauf.

[mekakic]

Schön das sich im Bereich Videoencoding on GPUs langsam was tut.

[reunion]

Wundert mich das beide Hersteller kurz vor dem ComputeShader und OpenCL noch so viel Ressourcen in eigenen Schnittstellen binden, die wohl wenig Chancen auf Erfolg haben dürften. Aber womöglich ist es nur so möglich die unterschiedlichen Architekturen gut auszulasten. Aber sonst natürlich Daumen hoch, ATi dürfte hier dank sehr hoher Shaderleistung sicher gute Karten haben.

[mekakic]

Vielleicht trainieren sie schon mal, wie ihre OpenCL, CS Treiber und Compiler wohl aussehen müssen :)

[reunion]

Der Vidoe-Converter kommt auch wieder:
http://www.computerbase.de/news/hardware/grafikkarten/ati/2008/november/der_ati_video_converter/

/edit: In den Threadtitel könnte man auch den Namen "ATi Stream" einfügen.

[deekey777]

http://www.computerbase.de/news/hardware/grafikkarten/ati/2008/november/ati_stream_jedermann_dezember/

So, nun zieht auch ATI nach und ich bin schon auf erste ergebnisse gespannt. Ich hoffe es gibt auch ein programm, das auf beiden karten beschleungit wird und dann geht es rund! ;D

edit
3003 posts ;D

Wow, wie kann man nur soviel Quark schreiben, liebe CB!

Ich weiß wirklich nicht, wie man auf die Idee kommt, dass erst mit 8.12 irgendwas freigeschaltet wird. Nur so ein Beispiel: Der GPU2-Client von F@H läuft seit April (Open-Beta), nutzt Brook+ und CAL. Auch konnte man seit Langem das Stream SDK frei herunterladen.

[deekey777]

und wie sie gleich wieder auf die kacke hauen:

http://www.abload.de/img/5l4jr.png (http://www.abload.de/image.php?img=5l4jr.png)

http://www.abload.de/img/6z4tm.png (http://www.abload.de/image.php?img=6z4tm.png)
Absichtliches Doppelposting:

http://www.abload.de/img/3fhla.png

Wahrheit tut weh, darum unterschlägt AMD die klitzekleine Kleinigkeit, dass der Badaboom-Converter auf allen CUDA-fähigen Geforces läuft. Und das ist unbezahlbar.

[Pinoccio]

Leicht oT: Gibts schon mehr gute Bücher zur GPGPU-Programmierung? Bislang stoße ich immer nur auf GPU-Gems 3, aber das macht viel zu viel (nicht GP-Zeugs), was ich nicht brauche.

mfg

[deekey777]

http://ati.amd.com/technology/streamcomputing/stream-consumer.html

In December 2008, AMD is scheduled to release an update to its ATI Catalyst™ drivers, software version 8.12, that instantly unlocks new ATI Stream acceleration capabilities already built into millions of ATI Radeon™ graphics cards

Da wird nix freigeschaltet. Das Catalyst-Paket wird einfach die nötigen CAL-DLLs und etwas GPGPU-Zeug von Haus aus liefern. Denn bisher liefert jede Anwendung die nötigen DLLs (SiSoft Sandra oder F@H).

[2B-Maverick]

Absichtliches Doppelposting:

http://www.abload.de/img/3fhla.png

Wahrheit tut weh, darum unterschlägt AMD die klitzekleine Kleinigkeit, dass der Badaboom-Converter auf allen CUDA-fähigen Geforces läuft. Und das ist unbezahlbar.

Wobei es absolut unbezahlbar ist, dass nicht nur so micker-Auflösungen wie bei NV unterstützt werden.
Und alles ab HD3xxx Serie ist doch schon ganz vernünftig von der Unterstützung, oder?

Aber worauf es wirklich ankommt, nämlich die Qualität, kann man momentan eh noch nicht beurteilen.
Sollte es mieser ausschauen als x264 oder ähnliche Encoder, ist mir die Zeit zum Encodieren meiner HD-Videos so was von egal. Da muss dann im Zweifel eben doch der Quad-Core arbeiten.

CU
Markus

[deekey777]

Das Videozeug (AVT) läuft nur auf der HD4000-Serie. Auch sprach man bei Upscaling nur im Zusammenhang mit der HD4000-Serie.
Es würde mich nicht wundern, wenn die kommenden Videoprogramme wie PowerDirector 7 oder ArcSoft Zeug nur die HD4000-Serie unterstützen.

Die HD4000-Serie unterscheidet sich von ihren Vorgängern deutlich mehr, als man denkt, wenn es um GPGPU geht.

[Gast]

Frage mich gerade was die da für eine NVIDIA Karte für 664 US Doller meinen, die GTX 280 kostet schon seit Monaten doch nur 499.-

[Coda]

Ordentlichen Support für GPGPU wird ATI erst mit OpenCL und D3D11 anbieten. Da bin ich mir ziemlich sicher.

Was bisher da ist ist relativ halbgar und der Dev-Support ist mal wieder lächerlich im Gegensatz zu CUDA.

[Spasstiger]

Warum gibts eigentlich keinen Support für die HD2xxx-Serie? Die technischen Unterschiede zur HD3xxx-Serie können ja wohl nicht so groß.

[deekey777]

Warum gibts eigentlich keinen Support für die HD2xxx-Serie? Die technischen Unterschiede zur HD3xxx-Serie können ja wohl nicht so groß.
Wie kommst du darauf?

[V2.0]

Immerhin ist die ATI Software umsonst. PureVideo hingegen nicht.

[_DrillSarge]I[]

^^kostenlos ;)
€: obs auch sowas wie physX geben wird? immerhin wird das bei der hd4xxx serie mit unter features aufgeführt. ;)

[deekey777]

Immerhin ist die ATI Software umsonst. PureVideo hingegen nicht.
Was hat jetzt PureVideo mit dem Thema zu tun?

Ja, der MPEG2-Decoder ist nicht umsonst, aber den braucht keiner. Das kostenlose AVIVO-Paket enthält zwar verschiedene Videodecoder (bishin H.264), braucht auch kein Mensch.

[Gast]

Und auf AMD Pressefolien geb ich erstmal gar nix!

[Gast]

Wie kommst du darauf?

"Gleicher" Chip 600/670 evtl. ist das gemeint.

Das Videozeug (AVT) läuft nur auf der HD4000-Serie. Auch sprach man bei Upscaling nur im Zusammenhang mit der HD4000-Serie.

Was ist denn bitte das Videozeug AVT ?

[d2kx]

Aus dem Catalyst 8.12 Changelog:

Additional notes
B. This driver includes runtime driver support for the AMD Stream SDK http://ati.amd.com/technology/streamcomputing/sdkdwnld.html

[Botcruscher]

Das Videozeug (AVT) läuft nur auf der HD4000-Serie.

Unwichtig. Und auf welchen Karten CUDA läuft ist eben so unwichtig.

OpenCL und D3D11 werden die Technologische Trittstufe sein an der sich (zukünftige) Karten und Anwendungen messen lassen.
Imo ist das ganze eh nur ein großer Vorlauf um Feedback für die Entwicklung zu bekommen.

[BvB123]

Frage mich gerade was die da für eine NVIDIA Karte für 664 US Doller meinen, die GTX 280 kostet schon seit Monaten doch nur 499.-

Steht doch dort. Preise resultieren aus CPU & GPU und Software.

[Gast]

Steht doch dort. Preise resultieren aus CPU & GPU und Software.
Achso, man kombinert eine 8400 GS mit einem Q9650 gegenüber einer 4870 und einem Q9300. :eek:

[Gast]

Wollte AMD Stream iGentlich nicht zu Gunsten von OpenCL iNstellen?

[Gast]

Ja, nur haut Nvidia mit CUDA so auf die Kacke, dass die da doch noch was machen müssen.

ATI hat ja auch eigentlich die flotteren Karten wenn es um sowas geht.

Im übrigen kann ich mir vom Cuda selbst heute nix vernünftiges kaufen.
Bis auf PhysX (welches zu Recht nur in den wenigsten Spielen Einsatz findet),
gibt es keine freie, vernünftige Encodingsoftware....
Gerade den Mpeg2-Encoder per GPU von ATI könnte ich gebrauchen, tja hab ich wieder mal aufs falsche Pferd gesetzt. Bei NVidia gibbet erstmal nur Badabom als Scherzversion.

[Gast]

Wollte AMD Stream iGentlich nicht zu Gunsten von OpenCL iNstellen?
wollten sie nicht. Aber eine falschmeldung wie diese ist nicht so einfach aus den Köpfen zu bekommen

[deekey777]

"Gleicher" Chip 600/670 evtl. ist das gemeint.



Was ist denn bitte das Videozeug AVT ?
Ich hab da nicht aufgepasst: Die Präsentation spricht tatsächlich von HD3000 und HD4000. Warum das so ist, keine Ahnung. Da aber der GPU2-Client für F@H auf HD2000 läuft, kann ich dies einfach nicht verstehen.

AVT ist DAAMITs Technologie zur Transcodierung von Videos auf HD4000 (anders als Nvidia bietet DAAMIT nicht nur die Hardware, sondern die Software an). Videozeug sind verschiedene Filter (wie "CUDA-Filter" in TMPGEnc oder PowerDirector 7).

[=Floi=]

warum muß alles kostenlos sein? Wenn die qualität sehr gut ist und die software auch weiterentwickelt wird, dann soll sie auch etwas kosten. Photoshop oder office sind nicht deshalb so gut, weil sie kostenlos sind!
OS ist schön und gut, aber auch oft nicht das man man wirklich möchte. (auch sollte man hier noch an lizenzen und patente anderer denken! )

Eine 4850 gibt es ab 132€ und das ist nicht wirklich so viel. im gegenzug bekommt man noch mehr performance dazu.

edit
ich könnte mir auch noch ganz andere bereiche vorstellen. Im serverbereich ist da sicherlich sehr viel potential vorhanden.

[Gast]

Toll und wer hat will sein Geld aus dem Fenster werfen?

Wenn die Konkurenz direkt eine Software kostenlos anbietet womit ich
zB. MPEG2 und HD-Material encodieren kann und dies wahrscheinlich
die gleiche Qualität aufweist wie das Badaboomzeugs, warum soll ich nicht dann dazu greifen?
Eine DVD zu produzieren dauert auch ein Stückchen und wenn es die GPU 13x flotter macht habe ich da nix einzuwenden.

[deekey777]

warum muß alles kostenlos sein? Wenn die qualität sehr gut ist und die software auch weiterentwickelt wird, dann soll sie auch etwas kosten. Photoshop oder office sind nicht deshalb so gut, weil sie kostenlos sind!
OS ist schön und gut, aber auch oft nicht das man man wirklich möchte. (auch sollte man hier noch an lizenzen und patente anderer denken! )

Eine 4850 gibt es ab 132€ und das ist nicht wirklich so viel. im gegenzug bekommt man noch mehr performance dazu.

edit
ich könnte mir auch noch ganz andere bereiche vorstellen. Im serverbereich ist da sicherlich sehr viel potential vorhanden.

Was hat jetzt dein Posting mit dem Thema zu tun? Oder bezieht sich das jetzt auf den Badaboom-Converter?

[Palpatin@work]

Wenn ATI Stream gut ist und alles Free ist dann muss ne ATI Karte her, da führt für mich dann kein Weg drann vorbei, doch wo und wie usw, hau ich die GTX 280 ausm Hauptrechner raus und ne X2 rein?, alternativ Media Center PC soweit Hochrüsten damit er das kann??, alternativ zur Geforce ne ATI nur zum encoden? aber ob das Treibermäsig so gut Funktioniert hmmm...

[Gast]

Mit Vista sicher nicht und ich würde jetzt keinen so großen Aufwand machen wenn man schon eine GTX 280 drin stöpseln hat.

Finde es aber nicht gut, dass bei NVidia nix in der Richtung gemacht wird...
Cuda hier Cuda da, aber bis auf den Badaboom-Kramm der ja bekanntlich keine
supertolle Qualität bietet und einen freien Encoder der noch mehr schlecht als Recht ist, muss man sich auf Recht teure Software (teilweise aus dem Profibereich)berufen. Wäre eben recht praktisch wenn die es auch mal schaffen würden solche Software anzubieten.

[deekey777]

Jetzt mal ehrlich: Ja, der Badaboom-Converter ist nicht gerade eine Qualitätsbestie, aber je nach Grafikkarte und CPU kann das Programmchen seinen Zweck locker erfüllen, wenn es ums Umwandeln fürs iPhone und Co geht.

Aber auf der anderen Seite: Die CPU ist immernoch wichtig, aber mit CUDA ist es schon jetzt möglich bestimmte Filter von der Grafikkarte berechnen zu lassen, dazu entlastet diese die CPU beim Decodieren des Videos. Und die Software ist nicht unbedingt teuer, aber dieses Zusammenspiel bringt seine Vorteile.

[Walkman]

Badaboom kann aber momentan leider kein DivX umwandeln :/

[deekey777]

ATI Stream Computing (http://www.rage3d.com/articles/stream/index.php?p=1)@Rage3D samt Interview. Auch ist dort die gesamte Präsentation als PDF zu finden.

[=Floi=]

http://www.rage3d.com/articles/stream/pics/market.jpg
was ist denn CAE und für was steht Defense genau?

[Gast]

CAE = Computer Aided Engineering zb. Finite Elemente Methode

[Sven77]

Die FirePro dürfte dann der Nachfolger der FireGL sein... hoffentlich schafft ATI es dann mal anständige Treiber zu liefern, die aktuellen FireGLs sind absolut unbrauchbar

[Gast]

@topic: Ich halte das ganze für reines Marketing und letztlich unnütz. Sobald von M$ die allgemeine Spezifikation da ist, wird alles auf diese hinauslaufen... was, bei aller Abneigung gegen Microsoft, eigentlich auch vernünftig ist. Dann kommt die ganze GPGPU-Sache vielleicht mal aus dem Nischenbereich raus...

btw: Ich find's irgendwie witzig dass ne Firma wie AMD mal wieder mit großspurigen Ankündigungen um sich wirft, und Klein-S3 mal eben schnell ein Tool auf die Webseite stellt das die GPU für Bildbearbeitung nutzt, ganz ohne Fanfaren und 1000 Marketing-Folien... (natürlich ist das mit CUDA & Co. nicht vergleichbar!!! Trotzdem amüsant irgendwie... und von Ankündigungen kann man sich erstmal nichts kaufen. Gut, die Aktionäre vielleicht... *g*)

[deekey777]

Warum sollte jemand DirectX11 (das nebenbei wohl erst Anfang 2010 kommt) für GPGPU-Anwendungen nutzen, wenn OpenCL vor der Tür steht?

[Gast]

Warum sollte jemand DirectX11 (das nebenbei wohl erst Anfang 2010 kommt) für GPGPU-Anwendungen nutzen, wenn OpenCL vor der Tür steht?

DirectX11 -> gut

OpenCL -> nicht gut

mfg

[_DrillSarge]I[]

momentan ist das ganze gpgpu zeug für den mainstream user eh sinnfrei.
nvidia wirbt ja kräftig damit (physx und co noch dazu), aber im moment bringt es nix. (kommt mir nicht mit den paar sinnlosen sachen für physx und einem miesen converter)
ati springt da jetzt auch (spät) auf.
toll, zwei apis, inkompatibel zueinander, vor der tür stehende standards...das zeug ist eigentlich beides zum sterben verdammt

[Sven77]

Nein, Nvidia hat mit Mental Ray einen Trumpf in der Hand.. sollte dieser Cuda only werden, dürfte Cuda eine Weile bestand haben... MR ist immer noch der am meisten verwendete 3D-Renderer, und ist in allen 3 grossen 3D-Softwarepaketen standardmässig integriert, die seit kurzem alle auch noch Autodesk gehören, die ja bekanntlich gerne mit Nvidia kuscheln... ein Teufelskreis.. Aber im Pro Bereich ist ATI schon immer am abstinken, also dürften sich hier keine grossen Verschiebungen in eine Richtung ergeben..

[=Floi=]

es braucht eben zeit, bis eine flächendeckende unterstützung gegeben ist. Es geht nicht alles von heute auf morgen und wichtig ist, dass die schnittstellen da sind.
Der ganze bereich ist erst noch im wachsen und das braucht eben auch seine zeit. Meistens wechst das ganze dann exponentiell und mit der zeig wird es dann auch mehr solcher programme geben. Man kann das auch bei D3D10 sehen.

[Gast]

I[;6916575']
nvidia wirbt ja kräftig damit (physx und co noch dazu), aber im moment bringt es nix. (kommt mir nicht mit den paar sinnlosen sachen für physx und einem miesen converter)


nix würde ich nicht gerade sagen, im gegenteil, angesichts des anfangsstadiums von CUDA sieht es garnicht mal so schlecht aus.

damit meine ich weniger den miesen konverter, sondern eher Adobe Premiere und Cyberlink Powerdirector, auch PhysX ist imo nicht so sinnlos wie es immer hingestellt wird, vor allem jetzt wo es mit jedem PC mit einer NV-karte ab der GF8 in hardware möglich ist.

[_DrillSarge]I[]

damit meine ich weniger den miesen konverter, sondern eher Adobe Premiere und Cyberlink Powerdirector, auch PhysX ist imo nicht so sinnlos wie es immer hingestellt wird, vor allem jetzt wo es mit jedem PC mit einer NV-karte ab der GF8 in hardware möglich ist.
ok, das mit adobe und co lasse ich mal gelten ;). aber physx ist imo komplett sinnlos momentan. was gibts dafür? warmonger -> crap, ut3 levels? 3 oder 4 stück und die sind nichtmal besonders sinnvoll oder eher schlecht gemacht (lighthouse/tornado). zudem gibts custommaps wo das viel besser ohne physx funzt (dm-lego/dm-nowhere).
dazu gibts noch paar demos/trials. auch ältere spiele (graw) profitieren nicht wirklich davon.

[Unyu]

Immerhin gibt es etwas und das seit PhysX Start.
Gewisse andere Features tun sich schwer überhaupt irgendwo unterstützt zu werden, auch wenn sie seit 12 Monaten beworben werden. ;)

Zudem sollen ja noch die PhysX Kracher kommen. ;)

[_DrillSarge]I[]

Immerhin gibt es etwas und das seit PhysX Start.
Gewisse andere Features tun sich schwer überhaupt irgendwo unterstützt zu werden, auch wenn sie seit 12 Monaten beworben werden. ;)
d3d 10.1? ja, das ist auch leicht FAIL :D

Zudem sollen ja noch die PhysX Kracher kommen. ;)
das hat schon ageia andauernd behauptet. jetzt macht das nv. passiert ist nix (das physx pack lass ich nicht als "kracher" durchgehen).

[Gast]

I[;6917471']
das hat schon ageia andauernd behauptet. jetzt macht das nv. passiert ist nix (das physx pack lass ich nicht als "kracher" durchgehen).

naja, immerhin wurde einiges an lauffähiger software gezeigt die sich im alpha oder betastatus befindet, das ist schon mehr als nur eine ankündigung.

[=Floi=]

bei physx ist ja noch immer der fehlende support von ati (und theoretisch auch larrabee) schuld. Man kann es sich einfach nicht leisten, nur einen hersteller zu unterstützen und so ist noch ein hemschuh mehr dabei...
Die möglichkeiten und technik im allegeinen ist aber ganz gut.

[deekey777]

PhysX ist sowas von egal. Hier geht es um GPGPU und nicht um diese Kleinigkeit in Spielen.

[Gast]

Warum sollte jemand DirectX11 (das nebenbei wohl erst Anfang 2010 kommt) für GPGPU-Anwendungen nutzen, wenn OpenCL vor der Tür steht?
Vielleicht aus demselben Grund, weswegen manche DX statt OpenGL nehmen / genommen haben ?

[deekey777]

Vielleicht aus demselben Grund, weswegen manche DX statt OpenGL nehmen / genommen haben ?
Nenne mir eine GPGPU-Anwendung, die DirectX nutzt.
Ok, ich fang an: F@H GPU1-Client. Du bist jetzt dran.

[Coda]

Erm deekey, das liegt wohl auch einfach daran, dass Direct3D <= 10 nicht wirklich darauf ausgelegt ist? :|

Direct3D 11 bietet da in der Tat eine sehr gute Basis. Man muss erstmal schauen wie der Dev- und Treiber-Support von OpenCL dann wirklich aussieht.

[Gast]

Nenne mir eine GPGPU-Anwendung, die DirectX nutzt.
Ok, ich fang an: F@H GPU1-Client. Du bist jetzt dran.

seit wann?

[deekey777]

Erm deekey, das liegt wohl auch einfach daran, dass Direct3D <= 10 nicht wirklich darauf ausgelegt ist? :|

Direct3D 11 bietet da in der Tat eine sehr gute Basis. Man muss erstmal schauen wie der Dev- und Treiber-Support von OpenCL dann wirklich aussieht.
OpenCL ist nicht auf GPUs beschränkt, dazu kommst, dass OpenCL früher kommst als DX11.
Ich kann es mir einfach nicht vorstellen, dass zB Adobe CS567 für GPGPU DirectX verwendet, dann aber für MacOS OpenCL.
Wir werden's sehen. Zumindest stehen ATi/AMD und NV sehr stark hinter OpenCL.
seit wann?
Schon immer.

[Coda]

Wie gesagt, meiner Meinung nach liegt's daran wie gut OpenCL dann auch wirklich von den IHVs unterstützt wird. Ich würde auch lieber eine Cross-Platform-API für GPGPU nehmen.

[Gast]

Nenne mir eine GPGPU-Anwendung, die DirectX nutzt.
Ok, ich fang an: F@H GPU1-Client. Du bist jetzt dran.
Scherzkeks ... hab keine Ahnung, ob der GPU1 client wirklich unter DX lief, aber das ist auch egal, denn dass der nicht mit der GPGPU Erweiterung von DX11 lief, sollte glasklar sein -> interessiert keinen.

Weder die DX11 mit dessen GPGPU Erweiterung gibts im Moment fertig zum Download, noch OpenCL.

Du hattest nur gefragt, wieso jemand DX11 GPGPU einsetzen sollte, deswegen habe ich den Vergleich mit OpenGL gebracht.
OpenGL war DX damals Jahre vorraus, nicht nur ein paar Monate .. und was hat sich durchgesetzt ? Richtig DX ...

Wenn ich mich recht erinnre, stand mal in einer c't, dass die M$ Entwickler viel enger mit den Spielehersteller und deren Programmierer zusammenarbeiteten.

Falls OpenCL dann genauso "schlecht" auf die Kundenbedürfnisse einrichtet, wirds wohl wieder ähnlich laufen.

OpenCL für professionelle Berechnungen, d.h. den derzeitigen FireStrorm / Tesla Markt
DX11 für Physikberechnung u.ä. bei Spielen.

Wie die story ausgeht sehen wir 2009 / 2010.

[Gast]

I[;6917471']
das hat schon ageia andauernd behauptet. jetzt macht das nv. passiert ist nix (das physx pack lass ich nicht als "kracher" durchgehen).

PhysX auf GPU gibt es erst seit ein paar Monaten Offiziel und du VERLANGST jetzt schon massen weise Super Tolle Spiele die das auch ausnutzen?!?!?

Irgend wie hab ich das Gefühl das du da gewaltig nicht den durchblick hast ;)

und spiel mal gra2 im PhysX Level und sag mir noch mal das Hardware PhysX für nichts ist!

[_DrillSarge]I[]

PhysX auf GPU gibt es erst seit ein paar Monaten Offiziel und du VERLANGST jetzt schon massen weise Super Tolle Spiele die das auch ausnutzen?!?!?

Irgend wie hab ich das Gefühl das du da gewaltig nicht den durchblick hast ;)

und spiel mal gra2 im PhysX Level und sag mir noch mal das Hardware PhysX für nichts ist!
physx mit hw-beschleunigung gibts schon eine ganze weile ;)
und ja d´graw2@physx ist auch nicht so extrem weltbewegend.

[deekey777]

Das AMD Stream SDK 1.3 ist draußen: http://ati.amd.com/technology/streamcomputing/sdkdwnld.html

[thacrazze]

Das AMD Stream SDK 1.3 ist draußen: http://ati.amd.com/technology/streamcomputing/sdkdwnld.html
Warum entwickelt AMD eigentlich noch Stream weiter? Wollten die nicht auf OpenCL setzen?

[reunion]

Das Stream SDK 1.4 kommt noch im Q1/2009:

http://journal.mycom.co.jp/articles/2008/12/17/streme/images/012l.jpg

http://journal.mycom.co.jp/articles/2008/12/17/streme/images/004l.jpg

http://journal.mycom.co.jp/articles/2008/12/17/streme/images/011l.jpg

http://journal.mycom.co.jp/articles/2008/12/17/streme/images/007l.jpg

http://journal.mycom.co.jp/articles/2008/12/17/streme/images/009l.jpg

http://journal.mycom.co.jp/articles/2008/12/17/streme/001.html

[SavageX]

Warum entwickelt AMD eigentlich noch Stream weiter? Wollten die nicht auf OpenCL setzen?

Das Stream SDK legt die Grundlage für OpenCL. ATI unterstützt ja derzeit schon das, was früher CTM hieß und Brook über ein einheitliches Framework - demnächst kommen halt noch OpenCL und DX11 Compute-Shaders hinzu.

Ist halt wie mit den üblichen Graphikshadern... ARB Shaders, HLSL, GLSL, ... läuft sowohl bei ATI als auch bei Nvidia über einen gemeinsamen Compiler mit austauschbarem Frontend.

[Gast]

Weitere Info/Picz aus Japan:
http://plusd.itmedia.co.jp/pcuser/articles/0812/17/news044.html
Im holl. Tweakers.net Forum (CJ) laden die Bilder schneler...
http://gathering.tweakers.net/forum/view_message/31217980

[deekey777]

AMD Responds ATI AVIVO Video Converter Feedback (http://hothardware.com/News/AMD-Responds-ATI-AVIVO-Video-Converter-Feedback/)

Q: Why are reviewers seeing so little GPU processing during transcoding?
A: The ATI Video Converter uses the GPU for only a portion of the video encoding. Specifically, the GPU currently offloads only the motion estimation portion of the encoding pipeline which is the most compute intensive part of the encoder. The GPU is particularly well-suited for this task. Given that a fixed workload is being offloaded to the GPU the load on the GPU may be relatively low or high based on the specific model of GPU.

Ich hätte noch gefragt, warum ATI hier absolut versagt hat (und das seit Ende 2005). Es ist ja nicht so, dass dieses Unternehmen keine Ahnung und null Erfahrung in Multimedia-Anwendungen hat.

Die aktuelle Lage sieht für mich so aus: Während Nvidia mit CUDA Geld verdient (ich glaube kaum, dass Elemental und andere Hersteller keine Lizenzgebühren für CUDA zahlen), schaltet ATi auf STUR und bringt dieses lausige kostenlose Stück Software, um NV auszuwischen (inspiriert von einem Posting aus dem iXBT-Forum, das PhysX auf der einen Seite (wo NV Geld verdient) und AMDs Havok-Engement, wo gar nichts passiert).
Letztes Jahr (Dezember) hat AMD ein Plug-in für Adobe gezeigt, mit dem eine HD3870 X2 hochauflösende Videos in HD-MPEG2 umwandelte. Und ich glaube kaum, dass hier die Qualität des AVIVO-Converters geliefert wurde. Aber irgendwie hat man das vergessen, um die HD4000 zu pushen.
Warum bietet Elemental kein Badaboom für die HD4000-Serie an? Insbesondere wenn AMD mit AVT die nötige Grundlage bietet. Mit solchen kleinen Tools und angenehmen Preisen verdient man Geld, denn PowerDirector kostet deutlich mehr und richtet sich an ganz andere Nutzer.

[=Floi=]

ati und nv müssten in mereren bereichen zusammenarbeiten um den grafikkartenmarkt für spiele im pc bereich erfolgreich halten zu können.
Wenn die zwei da standards bilden würden, dann wären wir im softwarebereich auch schon viel weiter

[deekey777]

CyberLink PowerDirector 7 Optimized for ATI Stream Technology from AMD (http://www.cyberlink.com/eng/press_room/view_1997.html)
The First Consumer Video Editing Software Optimized for ATI Stream Encoder

Taipei, Taiwan—January 10, 2009—CyberLink Corp. (5203.TW), innovative solution provider for the connected media lifestyle, launches today the latest PowerDirector 7 optimized for ATI Stream technology with accelerated MPEG2 and H.264 video encoding performance.

ATI Stream technology allows applications to take advantage of a graphic processing unit’s massive compute capability for demanding algorithms such as video editing. CyberLink PowerDirector 7 leverages ATI Stream technology to maximize transcoding performance when rendering MPEG2 and H.264 video files that users can output and view on the iPod®. PowerDirector 7 supports Stream-enabled ATI Radeon™ HD 4800 and ATI Radeon™ HD 4600 series graphic card solutions.

“PowerDirector 7 is a prime example of how ATI Stream technology can accelerate and streamline processing intensive PC tasks to improve the experience for consumers,” said Matt Skynner, vice president of product marketing, Graphics Products Group, AMD. “We are excited about the impressive results PowerDirector 7 is yielding with our innovative GPU technology and we applaud CyberLink’s commitment to deliver great HD video editing performance for video enthusiasts.”

"CyberLink is happy to collaborate with AMD, optimizing PowerDirector 7 as the first consumer video editing software with ATI Stream technology,” said Alice H. Chang, CEO of CyberLink. “With the growing popularity of video editing and AMD’s focus on developing advanced graphic and computing solutions, we felt it was a natural step to deliver accelerated software performance to allow users to spend more time on creating and sharing HD videos and less time waiting."
...
Product Availability
PowerDirector 7 optimized for ATI Stream technology will be available on CyberLink’s online store early February.

[Coda]

läuft sowohl bei ATI als auch bei Nvidia über einen gemeinsamen Compiler mit austauschbarem Frontend.
Hrm. So einfach is das nich. Bei D3D bekommt der Treiber Bytecode vorgesetzt, weil die Runtime auf jeden Fall HLSL selber kompiliert, bei OpenGL aber direkt GLSL, also muss da weitaus mehr selber gemacht werden.

Bei D3D11 CS und OpenCL verhält sich das genauso.

[deekey777]

Also das neue SDK 1.4 ist da: http://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx

http://www.abload.de/img/streamt1cz.jpg

Irgendwie klngt das nach CUDA. :biggrin:

Aber der Programming Guide ist immernoch sehr löchrig, immernoch RV670-mäßig (wobei angemerkt werden muss, dass die Neuerungen in Brook+ erwähnt werden).

[Gast]

Was bedeutet das denn nun fuer HD38xx User ? Bei mir schauen die Videos [AVIVO Con.] schlechter als das Original aus, und haben immer mehr Megabytes als das Original[700 <> 1000]...

Viel einstellen kann man ja nicht, und das ATT laesst eig. bis auf eine Aenderung der Aufloseung nicht viel zu. Ach ja, egal wie haevy das Source File[720p,DVD] war, das Neucodieren brauchte immer genua 25min. Ob 3min Schnippsel oder FullFilm und noch die 100% CPU Last sowie ungenutzte GPU dazu, irgendwie taugt der AVIVO Con. nicht viel.

[Lolman]

Was bedeutet das denn nun fuer HD38xx User ? Bei mir schauen die Videos [AVIVO Con.] schlechter als das Original aus, und haben immer mehr Megabytes als das Original[700 <> 1000]...

Viel einstellen kann man ja nicht, und das ATT laesst eig. bis auf eine Aenderung der Aufloseung nicht viel zu. Ach ja, egal wie haevy das Source File[720p,DVD] war, das Neucodieren brauchte immer genua 25min. Ob 3min Schnippsel oder FullFilm und noch die 100% CPU Last sowie ungenutzte GPU dazu, irgendwie taugt der AVIVO Con. nicht viel.

Die GPU wird sehr wohl genutzt - durch die starke Speicherübertaktung (von 3.6GHz auf 4.6GHz) hör ich ein leichtes Spulenpfeifen sobald Last anliegt - und weit flotter als 25min gehts auch.

[deekey777]

Die HD3800 werden gerade nicht benutzt.

[Gipsel]

Also das neue SDK 1.4 ist da: http://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx

http://www.abload.de/img/streamt1cz.jpg

Irgendwie klngt das nach CUDA. :biggrin:

Aber der Programming Guide ist immernoch sehr löchrig, immernoch RV670-mäßig (wobei angemerkt werden muss, dass die Neuerungen in Brook+ erwähnt werden).
Ich würde sagen, das klingt nach OpenCL ;)

Nee, ist gut zu sehen, daß AMD bei der Funktionalität ein paar Fortschritte macht. Und ein wenig haben sie die Doku ja auch aufgehübscht. Ist noch ein langer Weg, aber immerhin sind sie wohl auf dem richtigen :rolleyes:

[DaBrain]

Wie gesagt, meiner Meinung nach liegt's daran wie gut OpenCL dann auch wirklich von den IHVs unterstützt wird. Ich würde auch lieber eine Cross-Platform-API für GPGPU nehmen.

Da GPGPU vorraussichtlich sehr stark im Grafik und Video Sektor eingesetzt werden wird, in dem häufig Macs verwendet werden, kann ich mir gut vorstellen, dass OpenCL bei der Softwareenwicklung eher den Stich machen wird.
Besonders bei Adobe Produkten gehe ich schon ziemlich fest davon aus.

Die IHVs werden dann nachziehen.
An zwei Lösungen hat im Grunde genommen keiner ein Interesse.
Und es gibt nur zwei mögliche Kombinationen:

OpenCL alleine, oder DX11 und OpenCL. Die DX11 Lösung kann nicht alleine bestehen, da sie nicht Cross-Platform tauglich ist.

[_DrillSarge]I[]

bleibt das jetzt bei ATIstream oder wirds wieder zu AMDstream? ;)

zudem steht auf der amd-seite unten:
NOTE: ATI Catalyst 9.3 does not work properly on Windows XP systems for ATI CAL applications, including Brook+ applications. If you are using a Windows XP system, you will need to use ATI Catalyst 9.2 or wait for a later driver.
;D

[deekey777]

ATI/RapidMind demos the relevance of Stream computing to financial markets (http://fireuser.com/blog/ati_rapidmind_demos_the_relevance_of_stream_computing_to_financial_markets/)


In der aktuellen c't (07/09) gibt einen Artikel über GPGPU. Unglücklicherweise ist der Artikel für die Tonne, weil der Autor die R580 nicht ausreichend würdigte, für die es im Oktober 2006 einen F@H-Client gab.

[deekey777]

Monte Carlo über ATi Stream: http://arxiv.org/abs/0903.3053

[_DrillSarge]I[]

ATI GPU Physics strategy and ohhh maybe a demo being thrown down next week at GDC. If you're there GO see it http://budurl.com/cxrq
http://twitter.com/catalystmaker

sprich:
https://www.cmpevents.com/GD09/a.asp?option=C&V=11&SessID=9333

Session Description
AMD's Neal Robison and OTOY's Jules Urbach will explore how improved realism in games doesn't have to increase development time and effort. Hear the latest on game computing featuring open, standards-based physics with OpenCL and ATI Stream, and increasing content scalability through server-side rendering powered by AMD's Fusion Render Cloud.

[w0mbat]

Yup it is. Havok is indeed our partner of choice. Go check out the session if you are around, should be educational.
http://twitter.com/CatalystMaker/status/1356774985

Also AMD mit Havok gegen Nvidia mit PhysiX. Ich sehe da deutlich bessere Chancen für AMD.

[_DrillSarge]I[]

http://twitter.com/CatalystMaker/status/1356774985

Also AMD mit Havok gegen Nvidia mit PhysiX. Ich sehe da deutlich bessere Chancen für AMD.
korrekt ist es: Intel und AMD gegen Nvidia.

eigentlich lustig, wenn man bedenkt, was zurzeit zwischen amd und intel abläuft ;D

[Nakai]

Solange das exklusiv bleibt, bringt es nichts. Interessant wird es erst, wenn Intel ihre eigenen Grafiklösungen anbietet. Dann steht AMD evtl alleine da.


mfg Nakai

[AnarchX]

Und trotz dieser starken Konkurrenz ist noch nichts weiter herausgekommen als Ankündigungen und nun eine Demo auf der GDC, während GPU-Physik bei Nvidia schon seit über einem halben Jahr für den Endnutzer verfügbar ist und auf allen GPUs ab G80 läuft.
Wenn Havok(Intel) wirklich auf OpenCL setzt könnte das wohl hier erst ab HD4000 heißen und aber vielleicht auch Support von >G80. :D

Aber langfristig könnte wohl auch PhysX in Richtung OpenCL gehen, sodass dem Endnutzer schließlich egal sein kann, ob nun seine GPU PhysX oder Havok rechnet...

[_DrillSarge]I[]

Aber langfristig könnte wohl auch PhysX in Richtung OpenCL gehen, sodass dem Endnutzer schließlich egal sein kann, ob nun seine GPU PhysX oder Havok rechnet...
man wird ja JETZT nicht so doof sein und irgendeine physikengine auf cuda bzw. stream zuschneiden, wenn "jetzt bald" DX11/OpenCL verfügbar ist.

[deekey777]

I[;7181186']man wird ja JETZT nicht so doof sein und irgendeine physikengine auf cuda bzw. stream zuschneiden, wenn "jetzt bald" DX11/OpenCL verfügbar ist.
Ähm... Nein.
Selbst wenn du OpenCL als Solver nutzt, wirst du deinen Code auf den G80 oder RV770 oder CPU oder CELL oder Larrabee zuschneiden.
Von CUDA auf OpenCL zu wechseln, wird wohl einfach sein. Aber damit dieser Code dann auf einer Radeon läuft, wird man einige Anstrengungen unternehmen müssen.
I[;7181143']korrekt ist es: Intel und AMD gegen Nvidia.

eigentlich lustig, wenn man bedenkt, was zurzeit zwischen amd und intel abläuft ;D
Korrekt ist: Havok vs. PhysX.
Was bietet Havok? Spiel-Physik, die nur auf CPUs läuft (und einige Effekte). Was bietet PhysX? Spiel-Physik auf CPUs sowie Effekte-Physik auf CPUs+GPUs.

[Coda]

Selbst wenn du OpenCL als Solver nutzt, wirst du deinen Code auf den G80 oder RV770 oder CPU oder CELL oder Larrabee zuschneiden.
Ich muss auch nicht den Code für Intel oder AMD unglaublich anders "zuscheiden".

Von CUDA auf OpenCL zu wechseln, wird wohl einfach sein. Aber damit dieser Code dann auf einer Radeon läuft, wird man einige Anstrengungen unternehmen müssen.
Wenn man keine Extensions verwendet: Wieso?

[Gast]

In der aktuellen c't (07/09) gibt einen Artikel über GPGPU. Unglücklicherweise ist der Artikel für die Tonne, weil der Autor die R580 nicht ausreichend würdigte, für die es im Oktober 2006 einen F@H-Client gab.Wegen den 2 grünen die bei c't für Grafikkarten verantwrtlich sind habe ich das Abo gekündigt. Das ging garnicht mehr.

ati und nv müssten in mereren bereichen zusammenarbeiten um den grafikkartenmarkt für spiele im pc bereich erfolgreich halten zu können.Schlechte Marktanalyse ;)
http://www.computerbase.de/news/hardware/grafikkarten/ati/2009/maerz/amd_intel_nvidias_physx/

[AnarchX]

Was bietet PhysX? Spiel-Physik auf CPUs sowie Effekte-Physik auf CPUs+GPUs.
Auf den GPUs läuft bei PhysX sowohl Effekt- auch als Spiel-Physik, z.B. Wasserlevel für Crazy Machines II oder auch die zerstörbare Geometrie in Warmonger, mit der man sich alternative Wege bahnen kann.

[_DrillSarge]I[]

speziell warmonger wird durch die physik auch nicht besser. :)
zumal dort die performance dadurch "künstlich" in den keller gezogen wird, dass wände bspw. in unrealistisch viele partikel zerfallen. ohne das würde es garantiert auch 100%ig auf cpu flüssig laufen. zudem ist es dort auch nur an vordefinierten stellen möglich.

crazy machines 2 kenn ich nur den vorgänger, dort ist der einsatz von physik mal sinnvoll (wie es dort jetzt genau aussieht weiss ich nicht), da spielprinzip.

[deekey777]

Yes, we were running Havok cloth demos on multi-core CPU as well as GPU via OpenCL, all with the same OpenCL code underneath the Havok API. As was said above, there is no visible difference between the OpenCL code on either the CPU or the GPU and Havok's native code. The dancer dances off screen if you don't have the camera follow enabled, but the camera follow has a "bob" to it that makes some people sick after watching it for awhile. ;-)

We had a few demos we were cycling between. All OpenCL with no specific AMD functions or native code. I'm still partial to the Powdertoy demo and I have probably spend more time than I should playing with it. All in the name of debugging and optimizations. ;-)

I really hope Andrew's talk (EA) gets posted soon (the slides should all go up in not too long) as I think it's pretty cool that he was able to extract the Ropa cloth code used in Skate, port to OpenCL, and throw his code at AMD and Nvidia after developing on a different platform, and have AMD showing multi-core CPU and GPU and Nvidia showing GPU, side by side on alpha implementations. OpenCL is a real thing and the implementations are getting there. This year is going to be interesting and some of us are going to be very busy. ;-)
http://forum.beyond3d.com/showthread.php?p=1280212#post1280212
:biggrin:

[Coda]

Würde mich auch nicht wundern, wenn NVIDIA intern schon längst ein OpenCL-Backend hat.

[Gast]

http://forum.beyond3d.com/showthread.php?p=1280212#post1280212
:biggrin:Spielen spielen spielen :( An CUDA-ähnlichen Zeug interessiert nicht nur das Zocken. Schade daß weder AMD noch euch nichts besseres einfällt.

Diese Echtzeit ist nur geil =)
http://www.golem.de/0903/66091.html

[AnarchX]

http://forum.beyond3d.com/showthread.php?p=1280212#post1280212
:biggrin:

Vor allem das sollte man hervorheben:
We had a few demos we were cycling between. All OpenCL with no specific AMD functions or native code.

Also wohl lauffähig auf jeder OpenCL-fähigen GeForce (was wohl alle ab GF8 sein dürften).:D

Von Nvidia gab es auch eine hübsche APEX Demo auf der GDC:
http://www.youtube.com/watch?v=RuZQpWo9Qhs

[nutel]

bullet @ cuda

http://www.youtube.com/watch?v=DcTRjsliNAo&fmt=22

demo: http://code.google.com/p/bullet/downloads/list

http://bulletphysics.com/GDC09_ErwinCoumans_BreakingBarriers_2nd.pdf

[deekey777]

bullet @ cuda

http://www.youtube.com/watch?v=DcTRjsliNAo&fmt=22

demo: http://code.google.com/p/bullet/downloads/list

http://bulletphysics.com/GDC09_ErwinCoumans_BreakingBarriers_2nd.pdf
Was hat das mit dem Thema zu tun? Nur weil sie auf einer Folie AMD erwähnen?
Würde mich auch nicht wundern, wenn Havok für NVIDIA intern schon längst ein OpenCL-Backend hat.
So ist das angenehmer.

Spielen spielen spielen :( An CUDA-ähnlichen Zeug interessiert nicht nur das Zocken. Schade daß weder AMD noch euch nichts besseres einfällt.

Diese Echtzeit ist nur geil =)
http://www.golem.de/0903/66091.html
AMDs größtes Problem ist, dass die Software bei Weitem nicht so nutzerfreundlich wie CUDA ist. Die ganze Dokumentation war bis 1.2.1 ein Desaster, dazu kommt, dass die Dokumentation nach neun Monaten nach dem Release der RV700-Generation die HD4000 immernoch nicht kennt, es wird immernoch der RV670 vor die Nase gesetzt. Die Programmierer fischen im Trüben, wenn sie die verbesserte Hardware der R700-Generation nutzen wollen. Brook+ kann erst seit 1.4 das, was IL seit 1.2.1 beherrscht (LDS, CAL CS). Wer will sich das antun?

[ROXY]

wayne interessiert denn video transcoding.

wie siehts denn mit effekten und farbsteuerung etc. aus?
photoshop batch konverter etc.?
die wichtigen sachen klappen weiterhin nur über die cpu.

ob die reine konvertierung ohne zwischenbearbeitung von rohmaterial 4 stunden oder 20 minuten dauert interessiert doch niemanden.
das wäre nur interessant wenn du hunderte filme im monat konvertierst.
bei einem normalen projekt dies sowieso wochen , monate oder gar jahre dauert juckt das keinen menschen ob es nun 4 stunden mehr oder weniger sind.


edit: der bei golem gezeigter "minimale" eingriff hat mit der realität im professionellen bereich nichts zu tun

[Gast]

wayne interessiert denn video transcoding.

wie siehts denn mit effekten und farbsteuerung etc. aus?
photoshop batch konverter etc.?
die wichtigen sachen klappen weiterhin nur über die cpu.

Nur weils für dich unwichtig ist ist es gleich kompletter Blödsinn? Mal ein bisschen über den eigenen Tellerrand schauen... :|

ob die reine konvertierung ohne zwischenbearbeitung von rohmaterial 4 stunden oder 20 minuten dauert interessiert doch niemanden.
das wäre nur interessant wenn du hunderte filme im monat konvertierst.
bei einem normalen projekt dies sowieso wochen , monate oder gar jahre dauert juckt das keinen menschen ob es nun 4 stunden mehr oder weniger sind.

Oh Mann, diese kurzsichtige Argumentation geht mir langsam auf den Keks. Nobody will ever need more than 640K anyone? Wenn ich das schon lese "ist doch egal wie lange es dauert, warum sollte das schneller gehen..." Rechenleistung wird immer genutzt/gebraucht werden, egal ob du es für sinnvoll erachtest oder nicht.
Nicht umsonst werden die GPUs mit dem Slogan "a supercomputer in pocket format" beworben.

edit: der bei golem gezeigter "minimale" eingriff hat mit der realität im professionellen bereich nichts zu tun
s. oben: Nur weils für dich unwichtig ist...
AFAIK werden da explizit Videos von Handykamers angesprcoehn, also ausdrücklich Consumermarkt. Und jetzt stell Otto Normalverbraucher vor die Wahl: Ein-Klick-Automatikbearbeitung ohne große Einstellmöglichkeiten in Echtzeit oder professionelle Bearbeitung mit 100.000 Optionen und 12h Rechenzeit. Na?

Und zu deiner Beruhigung: Professionelle Programme mit GPU Support werden kommen, und dann wirst auch du froh sein dass du nicht 10min, 1h, einen Tag warten musst sondern dass es in Echtzeit, 5min und 1h erledigt ist.

[Gast]

wayne interessiert denn video transcoding.Die Soft hat mit Transcoding nur randweise etwas zu tun.

ob die reine konvertierung ohne zwischenbearbeitung von rohmaterial 4 stunden oder 20 minuten dauert interessiert doch niemanden.
das wäre nur interessant wenn du hunderte filme im monat konvertierst.
bei einem normalen projekt dies sowieso wochen , monate oder gar jahre dauert juckt das keinen menschen ob es nun 4 stunden mehr oder weniger sind.Das was ich mit Handy, Fotokamera oder einer normalen Videokamera aufnehme sind alles Projekte :D die keine Wochen dauern. Jahre auch nicht.

edit: der bei golem gezeigter "minimale" eingriff hat mit der realität im professionellen bereich nichts zu tunAh wir beide sind Profis? In was? In den gegenüber Vollquatschen? Danke. Ich verzichte.

Eine dreifache Bearbeitungsgeschwindigkeit durch schnellere CPU würdest du im Profibereich also willkommen heißen, eine zehnfache durch GPU ist aber nur eine Spielerei? Oder wie meinst du das? Ich find dich lustig :up:

Wenn dein Batchjob auf dem Photoshop ausnahmslos auf der CPU läuft dann bedeutet das nur daß es nicht anders programmiert wurde. Über die Möglichkeiten sagt es nichts aus. Und das ist ein großes Teil dieses Threads.

Wenn im Vergleich zu XP die Oberfläche von Vista um 80% mehr auf der GPU gerechnet wird dann finden wenigstens das alle an Vista gut. Ich denke aber daß Profis vor allem durch dieses Feature Vista nie einsetzen würden. Dieses neumodische Zeug. Pfui deibel! :uup:

@deekay777
So einfach scheint das alles trotzdem nicht zu sein. Sogut wie bei jedem kommerziellen Projekt der erwähnenswert viel durch CUDA dazugewinnt wird kundgetan, daß man sehr eng mit NV gearbeitet hat. Vielleicht ist das in solchen Fällen eine Vorgabe von NV (Werbung), aber ich lege das eher anders aus. Selbst wenn NV das nicht groß in Rechnung stellt scheint es eher so zu sein, daß man doch immer größere Probleme hat alleine erwünschte Ergebnisse zu bekommen.

[Savay]

Die Soft hat mit Transcoding nur randweise etwas zu tun.

Das was ich mit Handy, Fotokamera oder einer normalen Videokamera aufnehme sind alles Projekte :D die keine Wochen dauern. Jahre auch nicht.



mal im ernst...du nimmst dauernd videos auf die in derart grottiger qualität vorliegen das du sie durch die software aufbrezeln musst?

das ist doch auch wieder nen schönes nieschen produkt...wer sich ernsthaft für photographie oder filmerei interessiert wird sicher keine billige kompakt 7MPix digitalknipse mit bildvernichtungsfeatures hernehmen sondern sich gleich eine anständige kamera kaufen die von vornherein schon basis material liefert das besser ist als ALLES was die software noch aus nem schlechten handy video oder foto rauskitzeln kann... :rolleyes:

interessant ist der ansatz schon aber relevant wirds dann beim batch processing in photoshop oder ähnlichem z.B. wo man eine komplette serie von RAWs mit den gleichen filtern und funktionen exportieren will wobei ich sagen muss das dort auch nen lahmarschiger AM3 prozessor von AMD locker ausreicht bisher es aber durchaus schneller sein dürfte :wink:

wer wirklich ernsthaft so ein hobby betreibt wird von vornherein zusehen das sein basis material so wenig wie möglich bearbeitet werden muss...vorsorge ist IMMER besser als nachsorge...denn details die nicht aufgezeichnet wurden kann man auch nicht wieder hineinrechnen...das sieht immer schlechter aus.

PS: mal so nebenbei beim batch processing von (in meinem fall NUR 10Mpix) RAWs limitiert bei mir auch durchaus die HDD zu einem nicht unwesentlichen teil das wird man auch nicht beliebig durch GPGPU beschleunigen können vorallem nicht da die RAWs auch immer größer werden dank der steigenden pixelzahlen :)

[Gast]

mal im ernst...du nimmst dauernd videos auf die in derart grottiger qualität vorliegen das du sie durch die software aufbrezeln musst?

Es soll Leute geben die das machen. Außerdem gehts nicht um das "muss" sonder um das "kann". Wenn man schlechte Videos (von denen es dank Handy, Digiknipse usw ja tatsächlich genug gibt) mit wenig Aufwand (sowohl zeitlich als auch bedienungstechnisch) besser machen kann, warum nicht? Zumal man sicher sein kann eine große Anzahl an Leuten damit zu erreichen.


das ist doch auch wieder nen schönes nieschen produkt...wer sich ernsthaft für photographie oder filmerei interessiert wird sicher keine billige kompakt 7MPix digitalknipse mit bildvernichtungsfeatures hernehmen sondern sich gleich eine anständige kamera kaufen die von vornherein schon basis material liefert das besser ist als ALLES was die software noch aus nem schlechten handy video oder foto rauskitzeln kann... :rolleyes:

Ich würde jetzt mal behaupten dass die Minderheit der Leute hier eine gescheite Digitalkamera hat. Das mit dem Nischenprodukt (=wenig Leute die es nutzen) wär IMO nochmal zu überdenken...


[...]
wer wirklich ernsthaft so ein hobby betreibt wird von vornherein zusehen das sein basis material so wenig wie möglich bearbeitet werden muss...vorsorge ist IMMER besser als nachsorge...denn details die nicht aufgezeichnet wurden kann man auch nicht wieder hineinrechnen...das sieht immer schlechter aus.

Rischtisch :)
Dennoch bleiben genug Funktionen übrig die über das reine "verbessern" hinaus gehen, gerade wenns künstlerisch wird. Und meistens sind dass dann auch die die ordentlich Rechenleistung brauchen.


PS: mal so nebenbei beim batch processing von (in meinem fall NUR 10Mpix) RAWs limitiert bei mir auch durchaus die HDD zu einem nicht unwesentlichen teil das wird man auch nicht beliebig durch GPGPU beschleunigen können vorallem nicht da die RAWs auch immer größer werden dank der steigenden pixelzahlen :)
Also dass das Lesen von der Festplatte länger dauert als die Berechnung des Filters nehm ich dir nicht ab... außer du liest von CD oder so :D

[Coda]

So ist das angenehmer.
Wieso ist es "so angenehmer". Die Havok-Leute haben doch gesagt, dass es Vanilla-OpenCL-Code ist, der natürlich auch auf NVIDIA-Hardware läuft.

[reunion]

Schon bekannt?
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1238094348

[Stebs]

Würde mich auch nicht wundern, wenn NVIDIA intern schon längst ein OpenCL-Backend hat.Du meinst ein OpenCL-Backend in PhysX?
Jupp, die konnten sich ja bestimmt schon seit längerem ausmalen dass PhysX ein OpenCL Backend braucht um gegenüber Havoc auf dem Markt weiterhin attraktiv zu sein, sobald diese aus den Puschen kommen und eben endlich auch GPU-Accel. (per OpenCL) anbieten.
Bis dahin (also bis jetzt) konnten sich PhysX mit der (GPU_accel.) Monopolstellung CUDA/Nvidia only leisten. Das ist nun vorbei (und ja nicht wirklich überraschend)
Würde mich auch nicht wundern, wenn Havok für NVIDIA intern schon längst ein OpenCL-Backend hat.
So ist das angenehmer.Finde ich auch seltsam diesen Satz, würde ja nur Sinn ergeben wenn Havok sowohl Stream als auch OpenCL Backend bekommen hätte.
1. Stream für ATI -evtl. natürlich "polierter" und schneller als:
2. OpenCL für alle anderen (Nvidia)

Deutet aber doch alles eher auf OpenCL-Only Backend hin? (also NUR 2.)
-> Insofern muss nun nur jeder IHV seine OpenCL Hausaufgaben in seinem Treiber machen damit Performance und Stabilität stimmen (Support ist ja afaik schon in den Treibern, obs schon richtig rund läuft ist natürlich eine andere Frage)

[deekey777]

Wieso ist es "so angenehmer". Die Havok-Leute haben doch gesagt, dass es Vanilla-OpenCL-Code ist, der natürlich auch auf NVIDIA-Hardware läuft.
Das klang für mich so, alsob Nvidia im dunklen Kämmerchen selbst an einem OpenCL-Solver für Havok gearbeitet hat.
:smile:

[Coda]

Nö, ich rede von PhysX.

Bin übrigens mal gespannt ob es Direct3D-Interop-Extensions für OpenCL geben wird.

[Savay]

Zumal man sicher sein kann eine große Anzahl an Leuten damit zu erreichen.

Ich würde jetzt mal behaupten dass die Minderheit der Leute hier eine gescheite Digitalkamera hat. Das mit dem Nischenprodukt (=wenig Leute die es nutzen) wär IMO nochmal zu überdenken...

das ist denke ich grade der trugschluss...all diejenigen die etwas mit cuda, openCL, G80 - GT200 und weiß der geier nicht alles etwas anfangen können gehören eher zu den typischen enthusiasten die auch bereit sind mehr geld in etwas solides zu investieren statt eine software zu kaufen die an sich untaugliche hardware zu kompensieren versucht :wink:


Rischtisch :)
Dennoch bleiben genug Funktionen übrig die über das reine "verbessern" hinaus gehen, gerade wenns künstlerisch wird. Und meistens sind dass dann auch die die ordentlich Rechenleistung brauchen.

ja nur limitiert in dem fall einfach nie der rechner weil man wenn man dort ordentliche ergebnisse und keine verschlimmbesserungen erzielen will eher der anwender der flaschenhals ist :)
wer blind irgendwelche effektfilter über ein bild jagd beschäftigt sich eh nicht ernsthaft mit dem thema und spielt da nur mal eben so mit rum...der braucht das auch nicht täglich

klar GPGPU ist ne tolle sache für soetwas aber der nutzen für privatuser wird hier im forum doch überbewertet.

wenn du ne 25Mpix DSLR hast jo dann ist es wirklich hochgradig interessant aber so jemand hat auch genug kohle für nen richtig professionelles multicore system zumal bei solchen datenmengen auch wirklich anfängt das I/O zu limitieren. wir sprechen da ja je bild von teilweise ~43MB(!) je nach RAW format und das für das noch nicht decodierte bild

im professionellen bereich sehe ich für GPGPU allgemein eher die größeren chancen...davon wird natürlich einiges auf den markt für privatnutzer abfärben dort aber auch zuerst bei den prosumern und auch dort wohl eher nur stockend weil einfach oft der bedarf für soviel rechenleistung oft garnicht vorhanden ist.

viele haben ja salopp gesagt schon probleme ihre multicore CPU zu beschäftigen ;)

mal als beispiel der mit abstand anspruchsvollste standard filter in photoshop CS4 ist der noise reduction filter...der rennt bei meinem lahmarschigen AMD TC (PS favorisiert recht deutlich Intel CPUs und ist ja sehr gut multithreaded) aber schon in etwa 1sek über nen 10MPix Tiff und bremst dabei das system subjektiv (bezüglich ansprechverhalten der tasks..browser usw) nichtmal wirklich aus :lol:
dabei ist das wie gesagt nichtmal nen quadcore noch ne highend CPU...oder ist irgendwie besonders performant bei den PS filtern :) nen i7 dürfte das einfach noch locker 2mal nebenher machen können... :D

rechenintensive anwendung von mehreren filtern hintereinander batcht man eh selten da eh jedes bild anders ist und auch anders bearbeitet werden muss...


Also dass das Lesen von der Festplatte länger dauert als die Berechnung des Filters nehm ich dir nicht ab... außer du liest von CD oder so :D

mag sein das die HDD probleme mit dem sequentiellen lesen und schreiben der daten hat aber die auslastung bei ner batchumwandlung liegt bei mir nicht bei konstanten >90% sondern schwankt zwischen 30 und 95% also scheint dort definitv irgendwo die I/O zu limitieren und es wird leistung verschenkt.

sauber multithreaded ist das programm jedenfalls (Canon DPP 3.5.2.0) (RAW -> noise reduction -> JPEG 90% mit 50% resize)

wäre mal mit ner ramdisk gegenzuprüfen.

[Gast]

das ist denke ich grade der trugschluss...all diejenigen die etwas mit cuda, openCL, G80 - GT200 und weiß der geier nicht alles etwas anfangen können gehören eher zu den typischen enthusiasten die auch bereit sind mehr geld in etwas solides zu investieren statt eine software zu kaufen die an sich untaugliche hardware zu kompensieren versucht :wink:

Nur weil man sich nicht mit dem Thema beschäftigt heißt das ja noch lange nicht dass man es nicht nutzen kann. Für CUDA brauchst du nur eine Graka ab der 8000er Generation, und selbst in billigen OfficePCs für den Consumermarkt ist sowas mittlerweile verbaut, z.b. hier (http://www.saturn.at/produktinfo/?cat=N01.01.&parentCat=T00.00.12.01.&sku=1112956) ein KomplettPC um 499€ mit Geforce 9500. Leistungsmäßig liegt diese Grafikkarte wahrschienlich um Welten hinter den aktuellen Modellen, bietet aber vergleichen mit CPUs (sogar mit aktuellen!) noch immer verhätnismäßig viel Rechenleistung. Otto Normalverbraucher braucht nur noch ein CUDA fähiges Programm und kann loslegen.


ja nur limitiert in dem fall einfach nie der rechner weil man wenn man dort ordentliche ergebnisse und keine verschlimmbesserungen erzielen will eher der anwender der flaschenhals ist :)
wer blind irgendwelche effektfilter über ein bild jagd beschäftigt sich eh nicht ernsthaft mit dem thema und spielt da nur mal eben so mit rum...der braucht das auch nicht täglich

klar GPGPU ist ne tolle sache für soetwas aber der nutzen für privatuser wird hier im forum doch überbewertet.

Gerade beim "rumspielen" ist es doch äußerst komfortabel wenn man nicht ewig auf das Ergebnis warten muss. Ich ärgere mich jedesmal wenn ich beim Ausprobieren bin un ich muss auf die Berechnung warten. Gerade wenn ich die optimalen Parameter noch nicht weiß will ich dass es in Echtzeit geht.


[...]
im professionellen bereich sehe ich für GPGPU allgemein eher die größeren chancen...davon wird natürlich einiges auf den markt für privatnutzer abfärben dort aber auch zuerst bei den prosumern und auch dort wohl eher nur stockend weil einfach oft der bedarf für soviel rechenleistung oft garnicht vorhanden ist.

viele haben ja salopp gesagt schon probleme ihre multicore CPU zu beschäftigen ;)

CPU != GPU
Das kann man so nicht vergleichen. Wenn du ein Datenparalleles Problem hast wird in 90% der Fälle die Rechenleistung limitieren. Das liegt einfach in der Natur Datenparalleler Probleme.

mal als beispiel der mit abstand anspruchsvollste standard filter in photoshop CS4 [...] in etwa 1sek über nen 10MPix Tiff [...]

1sek würde ich jetzt auch nicht unbedingt als anspruchsvoll bezeichnen...


mag sein das die HDD probleme mit dem sequentiellen lesen und schreiben der daten hat aber die auslastung bei ner batchumwandlung liegt bei mir nicht bei konstanten >90% sondern schwankt zwischen 30 und 95% also scheint dort definitv irgendwo die I/O zu limitieren und es wird leistung verschenkt.

sauber multithreaded ist das programm jedenfalls (Canon DPP 3.5.2.0) (RAW -> noise reduction -> JPEG 90% mit 50% resize)

wäre mal mit ner ramdisk gegenzuprüfen.
Ich mache auch immer wieder mal JPEG resizing (60% von um die 10MPix), das sollte theoretisch mehr I/O Last erzeugen weil die noise reduction die du machst wegfällt. Ich habe aber keine Probleme meinen Dualcore zu 50% auszulasten (Programm ist nicht multithreaded, wenn ichs 2 mal starte hab ich 100% Auslastung), und das mit einer langsamen USB-Platte. Ich verwende ein selbsgeschriebenes (Linux)-Script und das Programm convert (http://www.imagemagick.org/script/convert.php), kann ich dir zum Testen mal schicken wenn du willst. Ich wäre jedenfalls heilfroh über alles was mir das resizen irgendwie beschleunigt....
http://f.imagehost.org/t/0106/last.jpg (http://f.imagehost.org/view/0106/last)

[Savay]

CPU != GPU
Das kann man so nicht vergleichen. Wenn du ein Datenparalleles Problem hast wird in 90% der Fälle die Rechenleistung limitieren. Das liegt einfach in der Natur Datenparalleler Probleme.

ja und grade je datenparalleler du tasks auslegst umso schwerer wird es das system schnell genug mit daten zu füttern wenn diese nicht gänzlich prozedural oder in gut komprimierter/komprimierbarer form vorliegen und so in die caches oder den RAM passt

deswegen dürfte in zukunft für GPGPU wohl auch nen möglichst großer lokaler speicher immer wichtiger werden...und auch PCIe 2.0 könnte wohl auf dauer auch zu einer bremse werden.

ich kann mir gut vorstellen das ne GT200 beim resizing und der noise reduction eines einzelnen RAWs derart schnell wäre das fast nur noch ein reines I/O limit vorliegt.


1sek würde ich jetzt auch nicht unbedingt als anspruchsvoll bezeichnen...

eben...es ist aber der rechenintensivste filter der mit CS4 ausgeliefert wird. die ganzen kunstfilter die dabei sind erzeugen weniger last :)

wenn du vlt nen externen noise reduction filter wie neatimage etc. laufen lässt kann sein das die lasst nochmal hoch geht aber die ganzen entrauschungsfilter die nicht einfach weichzeichnen sind schon mit das anspruchsvollste bei der bildbearbeitung.



Ich mache auch immer wieder mal JPEG resizing (60% von um die 10MPix), das sollte theoretisch mehr I/O Last erzeugen weil die noise reduction die du machst wegfällt. Ich habe aber keine Probleme meinen Dualcore zu 50% auszulasten

die RAWs sind aber auch erstmal 3mal so groß wie vergleichbare JPEGs und sie müssen erst decodiert werden was sowohl rechenintensiver ist als auch mehr bandbreite erfordert. die blähen sich z.B. als TIFF mit RGB datenformat auf ca. 60MB auf

jeder der ausschläge auf dem pic war ein RAW...warum die auslastung zwischendrin immer runtergeht kann ich nicht genau sagen aber es riecht einfach nach einem I/O limit...

wenn ich btw mit dem PhII nen ordner mit jpegs umwandel und verkleinere geht das dermaßen schnell...15sek für 50 JPEGs 50% resize mit resample. und das ist nun wirklich nicht die stärke der CPU ;D
vorallem läuft das jpeg resize bei all meinen programmen nur auf einem kern..das ganze wird übrigens bedeutend schneller wenn man den thread auf einen kern festpinnt.
viele Apps nutzen ja nichtmal nen multicore anständig aus und wenn ich mir dann überlege das nen i7 bei sowas mal glatt 50% mehr IPC bringt plus nen kern mehr hat... :rolleyes:
jpegs umwandlung braucht ja nun wirklich kein GPGPU...ausser man batcht derer gleich 10.000 :wink:

Neatimage auch nen sehr effizientes denoise tool ist wiederrum sauber multithreaded und läuft in maximal 2sek über jedes bild das ich habe...dort kommt beim batch processing aber auch wieder das phänomen zu tage das nach jedem bild die auslastung auf <10% abfällt ähnlich wie bei der RAW konvertierung

die meisten previews in photoshop und co sind dagegen z.B. auch ruck zuck angezeigt...nix mit warten aber auch die filter sind alle nicht wirklich multithreaded programmiert

nicht falsch verstehen ich bin generell ein fan von GPGPU frage mich persönlich nur immernoch ein wenig wofür ich z.B. die zusätzliche rechenpower der 160Vec5 SPs meiner radeon brauchen kann ausserhalb von spielen :wink: mein lahmarschiger AMD TC kommt mir ja schon sau schnell vor für alles was ich so mache und auch der wird ja oft garnicht richtig ausgelastet...also wohin mit der ganzen leistung?!?! :|

andererseits muss man einmal sagen bietet PS CS4 ja schon eine gewisse GPGPU unterstützung...zumindest die anzeige der bilder scrolling, zooming und besonders interessant das tonemapping etc. wird ja schon über OpenGL beschleunigt und es ist ein enormer unterschied ggü. CS3...aber auch das nutzt die GPU auch nichtmal ansatzweise aus...die bleibt stets bei 0% auslastung und dauerhaft im 2D takt ;)

[Stebs]

frage mich persönlich nur immernoch ein wenig wofür ich z.B. die zusätzliche rechenpower der 160Vec5 SPs meiner radeon brauchen kann ausserhalb von spielen :wink: mein lahmarschiger AMD TC kommt mir ja schon sau schnell vor für alles was ich so mache und auch der wird ja oft garnicht richtig ausgelastet...also wohin mit der ganzen leistung?!?! :|Natürlich weiß ich nicht was du persönlich mit GPGPU anfangen kannst/willst, jedoch ist das ganze noch recht neu und es werden in Zukunft bestimmt vermehrt interessante Anwendungen auftauchen, natürlich neben auch weniger Sinnvollem, an die man bis jetzt noch gar nicht gedacht hatte. Nicht komplett auszuschließen dass auch mal was für dich dabei ist ;)

Mal ein Beispiel wie man die GPU sinnvoll in einem Media Center PC nutzen könnte (resp. teilweise schon kann):
Ein Media Center PC sollte ja sparsam, leise und nicht zu teuer sein, dank GPU ist das mittlerweile einfacher geworden:

Mit sowas wie AMD Sempron LE-1150 ab € 23,90 und GeForce 8400 GS ab € 28,47 (Onboard Geforce 8200 geht auch (http://www.mythtv.org/wiki/VDPAU)) kann man sich einen H.264 1080p fähigen Media Center PC bauen der z.B. mit XBMC (http://www.phoronix.com/scan.php?page=news_item&px=NzE2Mg) oder VDR (http://www.phoronix.com/scan.php?page=news_item&px=NzEzMA) dank VDPAU (Video GPU Beschleunigung) super unter Linux läuft (http://www.phoronix.com/scan.php?page=article&item=nvidia_vdpau_gpu&num=1)
Das funktioniert schon jetzt.

Und wenn diese kleine Kiste dank GPGPU dann in Zukunft auch noch Videos in kürzester Zeit in ein Wunschformat transkodieren könnte (z.B. die DVB-S HDTV Aufnahme (oder Blu-ray-Film) den Freunden nach dem glotzen in kürzester Zeit im Wunschformat in die Hand drücken), dann wäre das IMHO schon eine sinvolle Ausnützung vorhandener GPU-Power...

[DaBrain]

bullet @ cuda

http://www.youtube.com/watch?v=DcTRjsliNAo&fmt=22

demo: http://code.google.com/p/bullet/downloads/list

http://bulletphysics.com/GDC09_ErwinCoumans_BreakingBarriers_2nd.pdf


:eek:

Wenn jetzt noch Bullet @ OpenCL kommt, gibt es keinen Grund mehr warum ein Spiel nicht auf GPGPU Physik setzen sollte. Selbst kleinere Indie Titel.

Falls AMD und Nvidia sich nicht auf Havok oder PhysX einigen können, ist Bullet wahrscheinlich der beste Ausweg um einen Standard zu erreichen.

[Gast]

Wenn jetzt noch Bullet @ OpenCL kommt

Yes, AMD helped us with the OpenCL version. It will be open sourced soon, but you need to wait for a public available OpenCL device driver for GPU or CPU.
(the CUDA kernels are almost identical to the OpenCL)

:)

[Gast]

eine reihe von echtzeit nvidia GPU optionen/effekten und bildmasteringeinstellungen als plug in für videoprogramm xyz wäre mir lieber.

NNN :)

[deekey777]

In der aktuellen c't (11/09) ist ein Artikel über GPGPU zu finden, in dem auch auf ATi Stream und CUDA eingegangen wird. Insbesondere wird erklärt, warum CUDA so eine übermächtige Position in diesem Bereich hat.
Gleich danach kommt ein Interview, in dem es heißt, dass CUDA in den nächsten Jahren de fact Standard bleibt.

[Black-Scorpion]

Wie etwas proprietäres wie CUDA ein Standard bleiben soll, weiß dann wohl nur der der das Interview gegeben hat.

[deekey777]

Wie etwas proprietäres wie CUDA ein Standard bleiben soll, weiß dann wohl nur der der das Interview gegeben hat.
Das liegt einfach daran, weil Nvidia einen 2,5-jährigen Vorsprung bei der Hardware und einen zweijährigen Vorsprung bei der Software hat. Ok, strenggenommen sind es etwa 19 Monate bei der Hardware (Release des G80 vs. Release des RV770). Hinzu kommen die verschiedenen Lehrgänge, Kurse an Universitäten (und somit deutlich mehr an Literatur), Hilfe für Startup-Unternehmen, finanzielle Unterstützung des Studiums usw.
Und AMD? Nüschts. Selbst wenn morgen OpenCL und DX11 samt DX11-Grafikkarten kommen, ist Nvidias Vorsprung riesig.

[Black-Scorpion]

Da NVidia prinzipiell nur das unterstützt was von Ihnen kommt hätte auch ein stärkeres Engagement von ATI nichts daran geändert.
Wie offt haben andere schon Sachen vorgestellt und NVidia hat nicht einen Finger gerührt?
Und trotzdem können die sich auf den Kopf stellen und mit den Füßen klatschen, Cuda wird trotzdem kein Standard sein oder werden.

[Gast]

CUDA ist derzeit bereits der Standard für GPGPU, da kannst du dich auf den Kopf stellen und mit den Füßen klatschen, du wirst daran nichts ändern.;)

[Black-Scorpion]

Du auch. Es ist Nvidia only und sonst nichts.
Das es Standard wird gehöhrt schon mehr dazu wie das Wunschdenken von einem Hersteller der noch nicht mal alles offenlegt.

[Gast]

Du auch. Es ist Nvidia only und sonst nichts.
Das es Standard wird gehöhrt schon mehr dazu wie das Wunschdenken von einem Hersteller der noch nicht mal alles offenlegt.

Was bedeutet denn Standard deiner Meinung nach? Würdest du z.b. x86 als Standard bezeichnen (Es gibt auch andere Prozessorarchitekturen)? Wie siehts mit C/C++ aus? Standard für große Programmierprojekte (Es gibt eine ganze Menge anderer programmiersprachen)? Was ist mit DX/D3D? Standard für Spieleprogrammierung (Es gibt andere Grafikschnittstellen)?
Ich könnte noch lange so weitermachen.... Schau dich doch mal um, dann wirst du zweifelsohne feststellen dass CUDA im Moment der Standard für GPGPU ist. Es muss nicht erst Standard werden, es ist bereits Standard. So siehts nunmal aus.
Was nicht heißt dass es für alle Ewigkeiten Standard bleibt, aber wie gesagt bei dem Vorsprung von Nvidia wirds für Konkurrenten tendenziell schwierig.

[Black-Scorpion]

x86 ist ein schlechtes Beispiel.
DX/D3D ist Standard und offen für alle die es (unter Windows) nutzen wollen.
CUDA ist dicht und wird nur von Nvidia verwendet.
Was soll daran Standard sein?

[Aquaschaf]

Was soll daran Standard sein?

Dass es faktisch zur Zeit für die allermeisten GPGPU-Anwendungen benutzt wird.

[Gast]

DX/D3D ist Standard und offen für alle die es (unter Windows) nutzen wollen.


Und was ist mit anderen Betriebssystemen? D3D ist Windows-proprietär, CUDA ist es nicht.

[Gast]

x86 ist ein schlechtes Beispiel.

Sagt wer? Begründung?

DX/D3D ist Standard und offen für alle die es (unter Windows) nutzen wollen.

In diesem Sinne: CUDA ist Standard und offen für alle die es (mit einer Nvidia) nutzen wollen.

CUDA ist dicht und wird nur von Nvidia verwendet.
Was soll daran Standard sein?
Deshalb meine Frage vorhin: Was bedeutet denn Standard deiner Meinung nach? So wie wir das Wort verwenden und verstehen ist CUDA einer, aber du verstehst anscheinend was anderes darunter...

[Coda]

CUDA ist offenbar auch um einiges einfacher zu handhaben als OpenCL. Das sollte man nicht vergessen.

Wie es bei D3D11 CS aussieht muss ich mir noch anschauen.

[Gastprog]

CUDA ist offenbar auch um einiges einfacher zu handhaben als OpenCL. Das sollte man nicht vergessen.

Wie es bei D3D11 CS aussieht muss ich mir noch anschauen.

Ist es nicht, da letztlich beide einfach nur C portieren. CUDA ist näher an der Nvidia-Hardware als OpenCL, was ja auch verständlich ist. Dadurch arbeitet CUDA effizienter mit Nvidia-GPUs als OpenCL.
Kein Wunder: CUDA ist schon praxiserprobt, es gibt Feedbacks von Entwicklern und Usern, es ist auf dem Markt usw.

Das ändert jedoch nichts daran, dass die OpenCL-Idee die einzig richtige sein kann, wenn man vom Consumerbereich spricht.
Ansonsten könnten Nvidia, Intel und ATI auch eigene effektivere 3D-Schnittstellen entwickeln und auf Direct3D pfeifen.
Glide lässt grüssen.

[Aquaschaf]

CUDA ist offenbar auch um einiges einfacher zu handhaben als OpenCL. Das sollte man nicht vergessen.

Ohne OpenCL zu kennen: wieso ist das so? Direkt sehe ich nicht warum eine allgemeine GPGPU-Sprache überhaupt großartig andere Sprachkonstrukte braucht als man sie in CUDA findet.

[infinity]

vielleicht liegt es ja im aktuellen fortschrittsstatium daran, dass CUDA bereits weit entwickelte tools von nvidia hat... und OpenCL halt vollständig neu ist, ohne gute entwicklertools bereit zu stellen? hmmm... wär ja auf jeden fall schonmal ein punkt, so wie "GastProg" es schon sagt.

[Gast]

alles in allem kann CUDA jedoch nicht als "Standard" bezeichnet werden, denn dazu sollte es meiner Meinung nach von mehreren Mitstreitern gemeinsam definiert und vor allem von allen benutzt werden können - und letzteres ist nun mal einfach nicht der Fall...

[Grestorn]

Es kann doch jeder CUDA verwenden. Der Standard ist doch m.W. offen und niemand hindert ATI daran, ihn zu implementieren. Es war deren Entscheidung das nicht zu tun.

[Savay]

es wäre auch dumm gewesen es zu tun und sich dem diktat von nVidia zu unterwerfen.

der OS und IHV unabhängige ansatz von OpenCL ist eindeutig der bessere das kann man drehen und wenden wie man will. zu hoffen bleibt nur das der standard im consumer bereich im vergleich zu DX11 CS besser da stehen wird als OpenGL im vergleich zu D3D!

[LovesuckZ]

Komisch, bei D3D würde man wohl genau das Gegenteil sagen. :rolleyes:

[Black-Scorpion]

Es kann doch jeder CUDA verwenden. Der Standard ist doch m.W. offen und niemand hindert ATI daran, ihn zu implementieren. Es war deren Entscheidung das nicht zu tun.
Jeder kann für CUDA Programme schreiben. Das war es aber auch schon.
Das Thema wurde schon durchgekaut. Warum sollen andere nach deren Pfeife tanzen und sich auf Gedeih und Verderb deren Lust und Laune ausliefern?

[Savay]

Komisch, bei D3D würde man wohl genau das Gegenteil sagen. :rolleyes:

wenn OpenGL eine größere verbreitung hätte gäbe es das defakto monopol von MS im bezug auf spiele nicht...die portierbarkeit auf Linux und OSX würde sich deutlich leichter gestalten.

[LovesuckZ]

wenn OpenGL eine größere verbreitung hätte gäbe es das defakto monopol von MS im bezug auf spiele nicht...die portierbarkeit auf Linux und OSX würde sich deutlich leichter gestalten.

Und wieso hat sich dann OpenGL nicht durchgesetzt? :rolleyes:
Der propiritäre Standard D3D hat sich genau deswegen durchgesetzt, weil jemand vorhanden war, der als einziger die Entscheidung treffen dürfte.
Wieso dies bei CUDA nun schlechter sein sollte als bei D3D, scheint dagegen unklar sein.

[Grestorn]

Jeder kann für CUDA Programme schreiben. Das war es aber auch schon.
Das Thema wurde schon durchgekaut. Warum sollen andere nach deren Pfeife tanzen und sich auf Gedeih und Verderb deren Lust und Laune ausliefern?

Ich hab an der Diskussion nicht teilgenommen und vielleicht weiß ich das auch falsch, aber m.W. hat nVidia ATI dazu eingeladen an CUDA mitzuarbeiten und das mit zu implementieren, sprich eine Umsetzung für CUDA auf ATI Hardware zu realisieren.

Natürlich wäre das für nVidia ein Imagegewinn und für ATI ein Verlust gewesen. Aber es wäre dennoch für den Anwender das beste gewesen, was passieren kann.

MS hat das z.B. damals auch gemacht, als sie JavaScript im IE einbauten, ein Standard der von Netscape erfunden wurde. Und es hat niemandem geschadet.

[Gast]

es wäre auch dumm gewesen es zu tun und sich dem diktat von nVidia zu unterwerfen.

Wieso? (Mal abgesehen davon dass "Diktat" hier wohl etwas übertrieben ist) Warum sollte man vorhandene Technologie, die schon gut von der Community angenommen ist, nicht unterstützen? In anderen Bereichen wird das ganz selbstverständlich so gemacht. Nehmt doch mal die ATI/Nvidia Brille ab.

der OS und IHV unabhängige ansatz von OpenCL ist eindeutig der bessere das kann man drehen und wenden wie man will. zu hoffen bleibt nur das der standard im consumer bereich im vergleich zu DX11 CS besser da stehen wird als OpenGL im vergleich zu D3D!
Der bessere Standard in Bezug auf was? Soll ich dir sagen wieviele gute Standards es gibt, die nicht umgesetzt werden? Und wieviele Sachen es gibt, die erfolgreich sind ohne ein Standard zu sein? Im Endeffekt zählt doch gerade in einem so jungen und aktuellen Gebiet wie GPGPU nur das was verwendet wird, und das ist im Moment nunmal CUDA.


Und wieso hat sich dann OpenGL nicht durchgesetzt?
Der propiritäre Standard D3D hat sich genau deswegen durchgesetzt, weil jemand vorhanden war, der als einziger die Entscheidung treffen dürfte.

Eigentlich sollte ich dir auf sowas garnicht mehr antworten...

OpenGL hat sich auf dem Spielemarkt nicht durchgesetzt weil es auch andere Prioritäten hat und weil das Kommitee dahinter unfähig ist (leider).

D3D hat sich durchgesetzt weil Microsoft es entsprechend gepusht hat (s. IE) und weil einfach kein ernstzunehmender Konkurrent vorhanden war. Und nicht aus den Gründen die du schreibst.

[LovesuckZ]

Eigentlich sollte ich dir auf sowas garnicht mehr antworten...

Ja, weil man selbst nichts zu sagen hat. Aber das kennt man ja von Gästen: Beleidiungen und nichtssagende Texte. ;)


OpenGL hat sich auf dem Spielemarkt nicht durchgesetzt weil es auch andere Prioritäten hat und weil das Kommitee dahinter unfähig ist (leider).

D3D hat sich durchgesetzt weil Microsoft es entsprechend gepusht hat (s. IE) und weil einfach kein ernstzunehmender Konkurrent vorhanden war. Und nicht aus den Gründen die du schreibst.

Du hast genau das bestätigt, was ich geschrieben. Aber liebers erstmal trollen - vielleicht wird man dann auch erhöht. ;D

[deekey777]

Es kann doch jeder CUDA verwenden. Der Standard ist doch m.W. offen und niemand hindert ATI daran, ihn zu implementieren. Es war deren Entscheidung das nicht zu tun.
CUDA ist gerade nicht offen. Auch ist CUDAs Programmiermodell an Nvidia-Hardware gekoppelt. Damit man C for CUDA auch auf Radeons nutzen kann, muss dieses Programmiermodell "gesprengt" werden, hinzu kommt, dass CUDA verschiedene Memory-Levels kennt, die nicht auf die Radeons übertragbar sind. Oder?

[=Floi=]

in der industrie ist aber ein richtiger standard schon zwingend und da wird sich fast niemand mit größeren projekten auf bloße biliotheken einlassen deren fortbestehen über jahre nicht gesichert ist. Dank opencl und CS können sich auch die unternhemen verlassen und die investition wird auf einem sicheren boden gebaut. Das ist heutzutage wichtiger den je und wir reden ja nicht von open source.

edit
für ati ist da ebenfalls ein segen, denn beide fangen im grinde hier bei 0 an und sind absolut gleich bei der unterstützung. der schnellere macht das rennen!

[deekey777]

es wäre auch dumm gewesen es zu tun und sich dem diktat von nVidia zu unterwerfen.

der OS und IHV unabhängige ansatz von OpenCL ist eindeutig der bessere das kann man drehen und wenden wie man will. zu hoffen bleibt nur das der standard im consumer bereich im vergleich zu DX11 CS besser da stehen wird als OpenGL im vergleich zu D3D!
Egal ob CUDA bzw. C for CUDA oder Brook+: Beides basiert auf Standfords BrookGPU. Nvidia hat sich BrookGPU samt einem Teil der Entwickler geschnappt und das Konzept auf ihre Hardware angepasst. Die "Dummheit" von AMD/ATi war es im Jahr 2007 einen R600 herauszubringen, während Nvidia schon 2006 einen G80 herausbrachte (mit Thread-IDs, Shared Memory). Hätte DAAMIT schon damals einen RV770 herausgebracht oder zumindest einen R600, der die Neuerungen des RV770 besitzt, so hätten wir vielleicht schon damals einen gemeinsamen Nenner, womit diese Diskussion erst gar nicht stattgefunden hätte.

Ich hab an der Diskussion nicht teilgenommen und vielleicht weiß ich das auch falsch, aber m.W. hat nVidia ATI dazu eingeladen an CUDA mitzuarbeiten und das mit zu implementieren, sprich eine Umsetzung für CUDA auf ATI Hardware zu realisieren.
Das war PR-Blahblah (ich glaube kaum, dass jemand von Nvidia dies wirklich so sagte). CUDA ist ein geschlossenes System, das aus mehreren Bausteinen zusammengesetzt ist. Einmal gibt es C for CUDA, eine Sprache mit C-ähnlicher Synthax (kommt von dem Macher des x264), im Vergleich zu Brook+ soll das Teil deutlich komplizierter sein. Und das war's schon, denn C for CUDA ist eigentlich die einzige Programmiersprache für Nvidia-GPUs.
Bei ATi ist man offen, da ist man nicht auf Brook+ angewiesen, sondern kann den Brook+ Compiler an seine Bedürfnisse anpassen; auch kann man eigene Compiler entwickeln, die über CAL die GPU nutzen können.

[Gast]

Egal ob CUDA bzw. C for CUDA oder Brook+: Beides basiert auf Standfords BrookGPU. Nvidia hat sich BrookGPU samt einem Teil der Entwickler geschnappt und das Konzept auf ihre Hardware angepasst.

Klingt interessant, hast du dazu eine Quelle?
[...]
Das war PR-Blahblah (ich glaube kaum, dass jemand von Nvidia dies wirklich so sagte). CUDA ist ein geschlossenes System, das aus mehreren Bausteinen zusammengesetzt ist. Einmal gibt es C for CUDA, eine Sprache mit C-ähnlicher Synthax (kommt von dem Macher des x264), im Vergleich zu Brook+ soll das Teil deutlich komplizierter sein.

C for CUDA == CUDA.
Es ist im Grunde ein C-Compiler mit einigen Änderungen. Und das ist auch gut so, denn genau das war ja das erklärte Ziel: Grafikkarten für general purpose computing nutzen, und welche Sprache wäre da sinnvoller als C?
Insofern verstehe ich ich

Und das war's schon, denn C for CUDA ist eigentlich die einzige Programmiersprache für Nvidia-GPUs.
nicht. Meinst du damit dies wäre nvidia als Nachteil anzurechnen? Ich finde das ist ein großer Vorteil, C ist einfach die am weitesten verbreitete Programmiersprache. In C kann man fast jede Architektur programmieren. Ich würde eher jede GPGPU Lösung kritisch betrachten bei der die GPU nicht in C programmiert werden kann.
http://www.dailytech.com/NVIDIA+Clears+Water+Muddied+by+Larrabee/article12585c.htm

Bei ATi ist man offen, da ist man nicht auf Brook+ angewiesen, sondern kann den Brook+ Compiler an seine Bedürfnisse anpassen; auch kann man eigene Compiler entwickeln, die über CAL die GPU nutzen können.
Ja klar, solange man nichts hat kann man immer sagen man ist offen :D srykthx

CUDA ist gerade nicht offen. Auch ist CUDAs Programmiermodell an Nvidia-Hardware gekoppelt. Damit man C for CUDA auch auf Radeons nutzen kann, muss dieses Programmiermodell "gesprengt" werden, hinzu kommt, dass CUDA verschiedene Memory-Levels kennt, die nicht auf die Radeons übertragbar sind. Oder?
Inwiefern müsste das Programmiermodell "gesprengt" werden? Das Memory Model von CUDA eigentlich ziemlich sinnvoll, auch ist es IMO nicht so dass das Model an die GPU angepasst wurde, sondern die GPU wurde entsprechend konstruiert um das Model zu erfüllen. Insofern würde ich sagen dass wenn ATI das Memory Model nicht unterstützen kann dann sind deren GPUs für GPGPU sowieso nur bedingt geeignet.

Was gibt es denn groß? Global memory und shared memory, global mem dürfte für ATI wohl kein Problem sein, und wenn sie nichts haben was dem shared mem von nvidia entspricht, dann kann man das ganze für GPGPU eh vergessen, s. oben.
Alles andere (constant mem, texture mem usw.) ist im Prinzip dasselbe wie global mem, bzw. kann vom Compiler entsprechend gehandelt werden.

[Gast]

Nvidia hat sich BrookGPU samt einem Teil der Entwickler geschnappt und das Konzept auf ihre Hardware angepasst. [...]
Nachtrag: Nein, Nvidia hat ihre Hardware an das Konzept angepasst, nicht umgekehrt.

[deekey777]

Nachtrag: Nein, Nvidia hat ihre Hardware an das Konzept angepasst, nicht umgekehrt.
Kennt BrookGPU Thread-IDs? Kennt BrookGPU verschiedene Memory-Level?

[Gast]

Kennt BrookGPU Thread-IDs? Kennt BrookGPU verschiedene Memory-Level?

The NVIDIA computing architecture was specifically designed to support the C language - like any other processor architecture. [...] CUDA is just our brand name for the C-compiler. They aren't two different things.
Quelle (http://www.dailytech.com/NVIDIA+Clears+Water+Muddied+by+Larrabee/article12585c.htm)

Ich meinte mit "das Konzept" nicht BrookGPU, das hast du ins Spiel gebracht. Ich habe dich vorher schon gefragt inwiefern das überhaupt mit CUDA zu tun hat.

Ansonsten: Natürlich kennt BrookGPU auch sowas wie ThreadIDs, oder wie wollen sie sowas

Calling a kernel function on a set of input streams performs an implicit for loop over the elements of streams, invoking the body of the kernel for each element.

Quelle (http://graphics.stanford.edu/projects/brookgpu/lang.html)
sonst realisieren? Der Unterschied ist nur dass es bei Brook implizit passiert während man bei CUDA Zugriff auf die ThreadIDs hat.

Und wenn du mir noch sagst was du mit "Memory-Levels" meinst kann ich vielleicht darauf auch noch antworten.

[Gast]

Mittlerweile gebe ich es auf, ATi gedenkt das nicht zu verbessern. Die Lage ist die gleiche, bis auf Express Software irgendwas gibt es keine Software die Stream-ready ist.

Selbst dann unterliegt ATIs Steam, CUDA was die Bildquali. angeht; zus. dann die Limitierung auf die 48xx Serie. Warum duerfen die 38xx Besitzer nicht damit "rum spielen", sowas testen ?

Wird dx11/Windows 7 der Retter in der Not sein und GPGPU "massenmarkt" tauglich gestalten ?

[Gastprog]

Man kann Direct3D nicht mit CUDA vergleichen, da Microsoft im Gegensatz zu Nvidia keine GPUs herstellt.
Nvidia hat also logischerweise Interesse daran Features anzubieten, die ATI nicht anbieten kann. Das dies natürlich über eigene Technologien am einfachsten zu handhaben ist, sieht man sehr deutlich an SSE.
Wäre SSE von Microsoft, dann hätte AMD diesbezüglich auch keine Probleme und müsste keinen Technologietausch wie damals mit AMD64 vornehmen.

Von daher kann es für den Gesamtmarkt auf Dauer nur schlecht sein, wenn CUDA sich als Standard durchsetzt und Nvidia eine Position wie Intel mit SSE einnimmt.


Zu der Geschichte ATI und CUDA:
ATI kann CUDA nicht einfach mal so unterstützen, da sich die G8x-Gxxx Architektur zu sehr von den eigenen unterscheidet.

Das muss man hier jetzt aber nicht weiter erklären, da es so auch schwarz auf weiß im CUDA Programming Guide steht, wenn man was davon versteht.

http://www.nvidia.com/object/cuda_develop.html

[Coda]

ATI kann CUDA nicht einfach mal so unterstützen, da sich die G8x-Gxxx Architektur zu sehr von den eigenen unterscheidet.
So, was denn unterscheidet sich denn so sehr?

Seit RV770 sollten sie eigentlich alles haben um es zu unterstützen.

[Aquaschaf]

Das muss man hier jetzt aber nicht weiter erklären, da es so auch schwarz auf weiß im CUDA Programming Guide steht, wenn man was davon versteht.

Das CUDA-Programmiermodel ist in etwa: eine unbestimmte Zahl von CRCW PRAMs mit expliziter Synchronisation und ein zwischen ihnen geteilter globaler Speicher. Threads sind in Blöcken zusammengefasst. Ein Thread kennt seine ID und die ID seines Blocks. Threads in einem Block haben eine weitere Ebene gemeinsam genutzten Speichers.

Was davon soll nicht auf RV770 passen?

[reunion]

Es soll erstmal jemand ein offizielles Statement von Nvidia zeigen in welchen diese AMD erlauben CUDA zu verwenden. Danach kann man gerne über Sinn und Unsinn dessen philosophieren, aber solange CUDA dicht ist, ist eine solche Diskussion hinfällig.

[Grestorn]

Es soll erstmal jemand ein offizielles Statement von Nvidia zeigen in welchen diese AMD erlauben CUDA zu verwenden. Danach kann man gerne über Sinn und Unsinn dessen philosophieren, aber solange CUDA dicht ist, ist eine solche Diskussion hinfällig.

ATI konnte und kann das immer machen, sie wollen nur nicht.

Quelle: http://www.extremetech.com/article2/0,2845,2324555,00.asp

[Gast]

allgemein:
http://www.behardware.com/articles/744-3/opencl-democracy-for-gpu-computing.html

If you go through the documentation on OpenCL fully, you’ll see that the basis for OpenCL is quite obviously… C for CUDA. No need to reinvent the wheel after all! Put simply, we can say that the consortium has taken NVIDIA’s API and stretched it to include everything that its members wanted.

OpenCL doesn’t really have a fixed spec. However it does let you obtain all the accelerator specs that are going to be used… Developers will have to work with these and ensure compatibility between their code and the accelerator as in some cases the code will be incompatible with some accelerators.

speziell (ati bezogen):
http://developer.amd.com/gpu_assets/Stream_Computing_Overview.pdf

etwas praxis:
http://www.computerbase.de/forum/showpost.php?p=5702944&postcount=9

imo ist die ganze diskussion, ob es nvidia gelingt sich mit cuda durchzusetzen völlig überzogen. opencl wird kommen, nvidia hat seine arbeit schon getan. jetzt muss ati nachziehen. das wars dann auch schon. die einzige frage die sich stellt ist folgende: was machen die softwareentwickler die bereits auf cuda entwickeln/entwickelt haben? passen sie ihren code an (opencl-konform), damit ihr programm auch auf ati-karten läuft oder hat nvidia genug geld springen lassen und sich eine gewisse loyalität erkauft? wird wohl von der zielgruppe abhängen ...

[reunion]

ATI konnte und kann das immer machen, sie wollen nur nicht.

Quelle: http://www.extremetech.com/article2/0,2845,2324555,00.asp

Okay, das ist zumindest mal etwas. Trotzdem natürlich weit davon entfernt das es eine ernsthafte Erwägung wert wäre für ATi. ATi dürfte also eine art Wrapper schreiben welcher CUDA-Aufrufe auf AMD-Hardware übersetzt. Nichtsdestotrotz ist CUDA eine NV-Schnittstelle um NV-Hardware hardwarenah ansprechen zu können. Man hätte null Mitspracherechte, und müsste zwangsläufig mit Performancenachteilen leben. Noch dazu würde man so CUDA wohl zum Durchbruch verhelfen.

[Grestorn]

Wäre der "Wrapper" im Treiber intergriert würde man ihn schon nicht mehr so nennen. Oder nennst Du den OGL Treiber von ATI auch einen Wrapper?

Und natürlich würde das CUDA zum Durchbruch verhelfen. Keiner hätte einen Nachteil dadurch, am wenigsten der Gamer. Nur ATI/AMD hätte vielleicht einen kleinen Knacks im Selbstbewustsein. Einen echten Nachteil für AMD kann ich nicht erkennen.

[deekey777]

Das CUDA-Programmiermodel ist in etwa: eine unbestimmte Zahl von CRCW PRAMs mit expliziter Synchronisation und ein zwischen ihnen geteilter globaler Speicher. Threads sind in Blöcken zusammengefasst. Ein Thread kennt seine ID und die ID seines Blocks. Threads in einem Block haben eine weitere Ebene gemeinsam genutzten Speichers.

Was davon soll nicht auf RV770 passen?
Warps versus Wavefronts? Egal ob G84 oder GT200: Die Warps sind immer gleich groß. Bei AMD hängt die Größe der Wavefronts von der Anzahl der SPs pro SIMD ab.
:confused:

[Aquaschaf]

ATi dürfte also eine art Wrapper schreiben welcher CUDA-Aufrufe auf AMD-Hardware übersetzt.

CUDA ist eine Sprache, nicht mehr und nicht weniger. ATI müsste keinen "Wrapper" schreiben, sondern einen Compiler. Inhärente Performancenachteile gäbe es nicht.

Warps versus Wavefronts? Egal ob G84 oder GT200: Die Warps sind immer gleich groß. Bei AMD hängt die Größe der Wavefronts von der Anzahl der SPs pro SIMD ab.
:confused:

Um sowas zu berücksichtigen hat man in CUDA die Konstante 'warpSize' zur Verfügung. Könnte sich doch auch bei zukünftigen Chips von NVidia ändern.

[reunion]

Wäre der "Wrapper" im Treiber intergriert würde man ihn schon nicht mehr so nennen. Oder nennst Du den OGL Treiber von ATI auch einen Wrapper?

Nein, OpenGL ist aber auch ein offener Standard bei dem jeder Mitreden kann und es dann zu einer Mehrheitsentscheidung kommt. CUDA ist nVs hauseigenen Schnittstelle um ihre GPUs ansprechen zu können. ATi kann dabei nur verlieren.


Und natürlich würde das CUDA zum Durchbruch verhelfen. Keiner hätte einen Nachteil dadurch, am wenigsten der Gamer. Nur ATI/AMD hätte vielleicht einen kleinen Knacks im Selbstbewustsein. Einen echten Nachteil für AMD kann ich nicht erkennen.

Was ist wenn AMD irgend welche Algortihmen anders implementiert hat wie nV? Oder gar nicht unterstützt? Oder zusätzlich unterstützt? Wenn sie andere Methoden für was der Geier was verwenden? CUDA ist natürlich auf NV-Hardware optimiert, man müsste alles mögliche mittels einer zusätzlichen Schnittstelle umwandeln/übersetzen, eine Implementierung auf AMD-Hardware würde zwangsläufig Leistung kosten und Nachteile bringen.

[deekey777]

CUDA ist eine Sprache, nicht mehr und nicht weniger. ATI müsste keinen "Wrapper" schreiben, sondern einen Compiler. Inhärente Performancenachteile gäbe es nicht.

Das Stream SDK bietet dafür die nötigen Voraussetzungen, zB nutzt Rapidmind dies für seinen Ihr-Zeug-zu-CAL-Compiler. Das ist AMDs "Wir sind offen"-Prinzip.
Hat CUDA einen ähnlichen Ansatz, dass jederman so einen Compiler schreiben kann?

ATI konnte und kann das immer machen, sie wollen nur nicht.

Quelle: http://www.extremetech.com/article2/0,2845,2324555,00.asp
Es gibt ein Interview, das noch vor der Ageia-Übernahme stattfand, in dem ein AMD-Verantwortlicher klar gesagt hat, dass dies nicht geht (CUDA auf Radeons).
Dass PhysX auf Radeons lauffähig wäre, ist nicht unmöglich, AMD bietet das Stream-Zeug nicht erst seit Frühjahr 2008 an.

[LovesuckZ]

Nein, OpenGL ist aber auch ein offener Standard bei dem jeder Mitreden kann und es dann zu einer Mehrheitsentscheidung kommt. CUDA ist nVs hauseigenen Schnittstelle um ihre GPUs ansprechen zu können. ATi kann dabei nur verlieren.


Cuda ist nVidia's Schnittstelle zwischen der Hochsprache und der Maschinensprache. Cuda kümmert sich um die Umsetzung der C für Coda Befehle auf die Hardware von nVidia.
Du redest davon, dass AMD Cuda "implemtiert", das ist aber falsch. Genauso wie AMD für OpenCL ein BackEnd benötigt, würden sie auch eins für C für Cuda benötigen.

[Gast]

Was ist wenn AMD irgend welche Algortihmen anders implementiert hat wie nV? Oder gar nicht unterstützt? Oder zusätzlich unterstützt? Wenn sie andere Methoden für was der Geier was verwenden?

Was soll das sein? Jede Grafikkarte kann ADD/MADD und ein paar zusätzlich Basisoperationen, damit kannst du bereits alles machen. Man muss "nur" den entsprechenden Compiler schreiben. Du kannst ja CUDA Code auch auf der CPU laufen lassen, wie sollte das gehen wenn es von ach so speziellen Operationen auf der Graka abhängen würde.

CUDA ist natürlich auf NV-Hardware optimiert, man müsste alles mögliche mittels einer zusätzlichen Schnittstelle umwandeln/übersetzen, eine Implementierung auf AMD-Hardware würde zwangsläufig Leistung kosten und Nachteile bringen.
CUDA ist im Grunde ein C-Compiler. Kann jeder schreiben, auch ATI. Der Punkt "kostet Leistung" zählt somit nicht, bei CPUs sagt man ja auch nicht "Prozessor x ist schneller als y weil der Compiler auf Prozessor x optimiert ist." Wenn er schneller ist ist er eben schneller.

[Coda]

Hat CUDA einen ähnlichen Ansatz, dass jederman so einen Compiler schreiben kann?
Soweit ich weiß schon - Man kann direkt Bytecode ans Backend geben. Und der ist dokumentiert. Auf diesem Bytecode-Backend setzt ja auch OpenCL bei NVIDIA auf.

Du redest davon, dass AMD Cuda "implemtiert", das ist aber falsch. Genauso wie AMD für OpenCL ein BackEnd benötigt, würden sie auch eins für C für Cuda benötigen.
Das ist nicht falsch. Man braucht nicht nur einen Compiler, sondern auch die sonstige Infrastruktur von CUDA um CUDA-Applikationen zu unterstützen.

Was ist wenn AMD irgend welche Algortihmen anders implementiert hat wie nV? Oder gar nicht unterstützt? Oder zusätzlich unterstützt? Wenn sie andere Methoden für was der Geier was verwenden? CUDA ist natürlich auf NV-Hardware optimiert, man müsste alles mögliche mittels einer zusätzlichen Schnittstelle umwandeln/übersetzen, eine Implementierung auf AMD-Hardware würde zwangsläufig Leistung kosten und Nachteile bringen.
Da ist gar nichts "zwangsläufig" so. Ich habe in der CUDA-Dokumentation noch nicht wirklich etwas gefunden was eine ATI-GPU nicht genauso könnte oder wesentlich anders als in D3D11 CS oder OpenCL wäre. Die GPUs sind von den Funktionen nunmal sehr ähnlich. Das ergibt sich aus den Anforderungen von Direct3D - vor allem 11. In Zukunft wird das alles noch viel näher beieinanderliegen, weil man auch dort vereinheitlichte Schnittstellen unterstützen muss.

Das Argument zieht nicht. Das wahre Problem ist, dass AMD immer NVIDIA hinterherimplementieren müsste, worauf ich natürgemäß auch keinen Bock hätte. Eine API für beide Hersteller kann nur funktionieren wenn sie beide in den Entwicklungsprozess involviert sind.

[reunion]

Was soll das sein? Jede Grafikkarte kann ADD/MADD und ein paar zusätzlich Basisoperationen, damit kannst du bereits alles machen. Man muss "nur" den entsprechenden Compiler schreiben. Du kannst ja CUDA Code auch auf der CPU laufen lassen, wie sollte das gehen wenn es von ach so speziellen Operationen auf der Graka abhängen würde.


Ich bin kein Programmierer, das sind halt Dinge die mir durch den Kopf gingen. Wenn es nicht so ist dann ist es ja okay.

CUDA ist im Grunde ein C-Compiler. Kann jeder schreiben, auch ATI. Der Punkt "kostet Leistung" zählt somit nicht, bei CPUs sagt man ja auch nicht "Prozessor x ist schneller als y weil der Compiler auf Prozessor x optimiert ist." Wenn er schneller ist ist er eben schneller.

Es zählt vielleicht für dich nicht, für Ati ist das aber sicher von Bedeutung. Zumal ATi eh nichts anderes tun muss als zu warten. Wenn es Alternativen gibt, kann es sich kein Entwickler leisten auf 1/3 des Marktes zu verzichten.

Da ist gar nichts "zwangsläufig" so. Ich habe in der CUDA-Dokumentation noch nicht wirklich etwas gefunden was eine ATI-GPU nicht genauso könnte oder wesentlich anders als in D3D11 CS oder OpenCL wäre. Die GPUs sind von den Funktionen nunmal sehr ähnlich. Das ergibt sich aus den Anforderungen von Direct3D - vor allem 11. In Zukunft wird das alles noch viel näher beieinanderliegen, weil man auch dort vereinheitlichte Schnittstellen unterstützen muss.

Du schwächst deine eigenen Aussagen selbst mehrfach ab - was soll ich davon halten? Du hast "nicht wirklich etwas gefunden", was "wesentlich anders" ist. Daraus kann ich nur schlussfolgern das es eben sehr wohl Unterschiede gibt, und diese Unterschiede werden wohl kaum zum Vorteil von AMD sein.


Das Argument zieht nicht. Das wahre Problem ist, dass AMD immer NVIDIA hinterherimplementieren müsste, worauf ich natürgemäß auch keinen Bock hätte. Eine API für beide Hersteller kann nur funktionieren wenn sie beide in den Entwicklungsprozess involviert sind.

Das habe ich ja auch bereits erwähnt, ohne Mitspracherecht und damit Einbindung in die Entwicklung ist das für AMD witzlos.

[Coda]

Daraus kann ich nur schlussfolgern das es eben sehr wohl Unterschiede gibt, und diese Unterschiede werden wohl kaum zum Vorteil von AMD sein.
Nein, ich wollte damit nur ausdrücken, dass ich es (noch) nicht vollständig ausschließen kann. Ich halt es aber für extrem unwahrscheinlich. Die Konzepte hinter OpenCL und D3D11 CS sind praktisch 1 zu 1 auf CUDA übertragbar. Und das sind die APIs für beide. Ich halte es sogar durch den expliziten direkten Zugriff auf die Thread-ID und local storage für realistisch, dass CUDA-Code besser auf RV770 laufen würde als das OpenCL-Äquivalent.

Es gibt übrigens auch so genügend Gründe CUDA zu verwenden anstatt OpenCL, Brook++ oder D3D11 CS. Die Handhabung ist viel einfacher. Im wissenschaftlichen Bereich verbaut eh fast keiner ATI. Weil sie überall genau die gleichen Fehler machen. Viel zu wenig Dev-Support.

[Gast]

Es zählt vielleicht für dich nicht, für Ati ist das aber sicher von Bedeutung. Zumal ATi eh nichts anderes tun muss als zu warten. Wenn es Alternativen gibt, kann es sich kein Entwickler leisten auf 1/3 des Marktes zu verzichten.

Dann ist warten aber genau das falscheste was man machen kann. ATi ist bei GPGPU eh schon hintendran, wenn sie jetzt noch weiter warten sind sie weg vom (GPGPU-)Fenster

Das habe ich ja auch bereits erwähnt, ohne Mitspracherecht und damit Einbindung in die Entwicklung ist das für AMD witzlos.
Das wirklich Problem ist ja kein technisches, wie Coda schon erklärt hat wäre Ati durchaus in der Lage CUDA zu unterstüzen. Was sie daran hindert ist natürlich die Angst vor "Gesichtsverlust". Mit so einer Einstellung wird man aber der Entwicklung immer hinterherschauen bzw. ihr im Weg stehen. Wenn ATi jetzt CUDA unterstützt wäre das IMO sogar eine gute Möglichkeit das im wissenschaftlichen Bereich angekratze Image aufzubessern.
Man muss sich ja auch nicht gleich auf Gedeih und Verderb einem "Diktat" von Nvidia unterwerfen. Nur solange man selbst nichts hat sollte man nicht auf andere schimpfen...

[Jake Dunn]

New Stream Transcoder available now

http://www.theinquirer.net/inquirer/news/1137498/ati-ups-gpgpu-ante

[deekey777]

New Stream Transcoder available now

http://www.theinquirer.net/inquirer/news/1137498/ati-ups-gpgpu-ante
Ist er nicht. Von einem Hotfix ist nichts zu sehen.
Aber das PR-Zeug ist schon da: http://www.amd.com/us-en/0,,3715_16003,00.html http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543~131263,00.html
http://ati.amd.com/technology/streamcomputing/consumer-entertainment.html
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/ATI_Stream_Espresso_May2009_final.pdf


AMD verbessert Videokonverter und kündigt neue Tools an (http://www.golem.de/0905/67413.html)

[Jake Dunn]

Ist er nicht. Von einem Hotfix ist nichts zu sehen.
Aber das PR-Zeug ist schon da: http://www.amd.com/us-en/0,,3715_16003,00.html http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543~131263,00.html
http://ati.amd.com/technology/streamcomputing/consumer-entertainment.html
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/ATI_Stream_Espresso_May2009_final.pdf


AMD verbessert Videokonverter und kündigt neue Tools an (http://www.golem.de/0905/67413.html)

Ist dann wohl nur für die HD4K gedacht wegen dem UVD2 Support

[Gast]

"ATI Stream Technology Cuts Video Transcoding Time in Half

Video enthusiasts and media corporations alike will be looking very closely at ATI video cards"
http://www.dailytech.com/ATI+Stream+Technology+Cuts+Video+Transcoding+Time+in+Half/article15264.htm

[Gast]

Etwas Geduld wegen full support, bitte:
"Support is currently supplied by a hotfix to Catalyst 9.5, version 8.612.3 RC2 dated May 25. Full support will be included in Catalyst 9.6, which will be released in mid-June."
http://www.dailytech.com/ATI+Stream+Technology+Cuts+Video+Transcoding+Time+in+Half/article15264.htm

[Gast]

Ganz großes Kino!
AMD ATI Stream Technology Accelerates Adobe Premiere Pro CS4 Workflows
...
Benefits: The ATI Catalyst™ Driver enables millions of ATI Radeon™ and ATI FirePro™ users to unlock ATI Stream compute acceleration capabilities on their graphics cards. Upon downloading http://links.amd.com/adobepremiere and installing the latest plug-in, Adobe users with the plug-in and the latest Catalyst driver may experience an encoding performance improvement of up to 8X.1
http://intel-only.blogspot.com/2009/06/amd-ati-stream-technology-accelerates.html

http://forums.amd.com/amdlive/messageview.cfm?catid=366&threadid=114667&enterthread=y

Das wirft auch ein ganz neues Licht auf Apple-Adobe Premiere-M¨glichkeiten! :up:

[deekey777]

Das wirft gar kein Licht auf Adobe, sondern ein ganz schlechtes auf AMD.
Warum? Weil sie schon Ende 2007 ein Plug-In für Premiere gezeigt haben - auf einer HD3800!

[2B-Maverick]

Das wirft gar kein Licht auf Adobe, sondern ein ganz schlechtes auf AMD.
Warum? Weil sie schon Ende 2007 ein Plug-In für Premiere gezeigt haben - auf einer HD3800!

Hoffentlich (für die Premiere-User - ich habe VegasPro hier) benutzt ATI andere Routinen als beim Encoder-Tool aus dem Catalyst.
Glaube aber nicht daran.... :frown:

Wäre interessant, hier mal einen Erfahrungsbericht zu lesen von jemandem der dieses Plugin einsetzt.

[deekey777]

Hoffentlich (für die Premiere-User - ich habe VegasPro hier) benutzt ATI andere Routinen als beim Encoder-Tool aus dem Catalyst.
Glaube aber nicht daran.... :frown:

Wäre interessant, hier mal einen Erfahrungsbericht zu lesen von jemandem der dieses Plugin einsetzt.
http://forums.amd.com/amdlive/categories.cfm?catid=376&entercat=y

Sie haben auch ein Forum für ein Sony Plug-In, vielleicht kommt auch was für Vegas.

In den Releasenotes steht:
For H264 Blu-ray encoding, there is one preset which may give an error when importing into an Encore Blu-ray H264 project: 1440x1080p 23.976 High Quality. Playback issue with HDTV 1080i 29.97 High Quality. This will be fixed in a subsequent update.
You may experience quality issues with some h264 presets due to gpu enabling.

[deekey777]

http://developer.amd.com/gpu/ATIStreamSDK/pages/ATIStreamSDKv20BetaProgram.aspx

ATI Stream SDK v2.0 Beta Program. Leider muss man sich dafür anmelden.

[Gipsel]

http://developer.amd.com/gpu/ATIStreamSDK/pages/ATIStreamSDKv20BetaProgram.aspx

ATI Stream SDK v2.0 Beta Program. Leider muss man sich dafür anmelden.
Stream SDK 2.0 ist mit OpenCL Support. Alpha Version gab es schon vorher mit Zugang für "strategische Entwicklungspartner". Das mit der öffentlichen "Bewerbung" für den Zugang ist neu.

[deekey777]

Bei Nvidia kann man wenigstens einen Blick ins OpenCL-Forum werfen.
Stimmt es, dass Brook+ angenehmer als OpenCL ist?

[Coda]

Wahrscheinlich ist alles außer Assembler angenehmer als OpenCL ;)

Die Sprache an sich geht ja, aber das Interface drumrum ist mal wieder kotzig.

[Gipsel]

Stimmt es, dass Brook+ angenehmer als OpenCL ist?
Wo das einfache Stream-Modell gut auf das Problem paßt, ist Brook+ extrem einfach. Das schlägt da auch CUDA locker (was aus meiner eingeschränkten Sicht nicht viel besser als OpenCL ist).

[Coda]

CUDA ist um einiges einfacher zu verwenden als OpenCL, weil man die Kernel direkt in sein Programm einbetten kann.

Was die Kernel-Sprache an sich angeht sind sie doch sowieso alle ziemlich ähnlich.

[Gipsel]

CUDA ist um einiges einfacher zu verwenden als OpenCL, weil man die Kernel direkt in sein Programm einbetten kann.

Was die Kernel-Sprache an sich angeht sind sie doch sowieso alle ziemlich ähnlich.
Welches Projekt (das nicht nur eine kleinere Spielerei ist) benutzt denn nur eine Quelldatei?
Ich finde ehrlich gesagt eine Trennung von Kernel-Code und Host-Code in unterschiedlichen Quelldateien deutlich übersichtlicher als alles durcheinander zu schmeißen. ATI ist mit dem Stream-SDK 1.3 sogar explizit in diese Richtung gegangen (vorher hat man da auch gemixt).

Die Sprache im Kernel-Code ist bei allen ein eingeschränktes C mit ein paar spezifischen Erweiterungen, das stimmt. Ich meinte auch hauptsächlich wie man Kernel aufruft, Resourcen auf der Grafikkarte belegt und auf diese zugreift. Also wirklich die Basics. Mit CUDA und OpenCL hat man da immer gleich die ComputeShader mit all deren Möglichkeiten (und auch Pflichten für den Programmierer) am Hals. Brook+ versteckt das besser und erzeugt standardmäßig oft einfacher zu handhabende (und für naive Implementationen oft auch besser performende!) PixelShader. Also wenn man LocalMemory aka LDS und das ThreadGroup-Geraffel nicht benötigt, geht es mit Brook+ auf jeden Fall erstmal einfacher.

[Coda]

Welches Projekt (das nicht nur eine kleinere Spielerei ist) benutzt denn nur eine Quelldatei?
Spielt doch keine Rolle, das funktioniert auch mit Headern.

[deekey777]

Brook+ wird jetzt auf SourceForge veröffentlicht, http://sourceforge.net/projects/brookplus/
Und keiner kriegt das mit...

Einige Videos:
Adobe Premiere Pro using FirePro V7750 and Stream 4X acceleration for encoding at SIGGRAPH 2009 (http://fireuser.com/blog/adobe_premiere_pro_using_firepro_v7750_and_stream_4x_acceleration_for_encod/)
Free OpenCL for CPU beta download from AMD (http://fireuser.com/blog/free_opencl_for_cpu_beta_download_from_amd/)

[Gipsel]

Brook+ wird jetzt auf SourceForge veröffentlicht, http://sourceforge.net/projects/brookplus/
Und keiner kriegt das mit...Open Source war es doch vorher schon (BSD-Lizenz, konnte und kann also auch in closed source Projekten frei verwendet werden). Ich habe den Sourcecode seit einem halben Jahr auf der Platte liegen (und auch modifizierte Versionen kompiliert und verteilt). Die Auslagerung zeigt doch nur, daß der Brook+ Support von ATI zurückgefahren wird (war ja sowieso eher mäßig ;)) und man in Zukunft voll auf OpenCL setzt.

Wird zwar nicht passieren, aber eigentlich würde ich das ganz lustig finden, wenn irgendwer dem brcc (brook c compiler) ein PTX-Backend verpaßt. CPU, OpenGL, DirectX und IL (für ATI) sind ja schon drin, wobei IL praktisch das Equivalent zu nvidias PTX ist.
Aber nvidia wollte das schon nicht machen, als Stanford (da kommt Brook her, wurde/wird für Folding@home benutzt) arge Probleme mit den OpenGL und DirectX Backends auf nvidia hatte (lieferte keine korrekten Ergebnisse). Nvidia hat sich damals für eine CUDA Version von Folding entschieden. Und jetzt ist das Zeitfenster wohl schon lange dafür zu.

[deekey777]

...
Aber nvidia wollte das schon nicht machen, als Stanford (da kommt Brook her, wurde/wird für Folding@home benutzt) arge Probleme mit den OpenGL und DirectX Backends auf nvidia hatte (lieferte keine korrekten Ergebnisse). Nvidia hat sich damals für eine CUDA Version von Folding entschieden. Und jetzt ist das Zeitfenster wohl schon lange dafür zu.
Das war eine sehr seltsame Geschichte. Zuerst hieß es, es liege an Nvidia, da es ein Problem mit dem Treiber gab, das Nvidia nicht fixen wollte und stattdessen auf CUDA verwies, was Stanford wiederum nicht wollte. Dann aber wurde es relativiert, denn es war auch der Core selbst, der mit dem Treiberproblem die Fehler verursachte, der das Folding auf einer G80 unmöglich machte.

Zu Brook+: Die Version bei Source Forge ist 1.4.1, also neuer als die des SDK 1.4 und das seit Anfang Juli. Dass sie Brook+ vollständig aufgegeben haben, glaube ich nicht, vielleicht baut die Gemeinde Brook+ zur OpenCL-Konkurrenz aus (siehe deine Idee). :biggrin:

[deekey777]

http://forums.amd.com/devforum/messageview.cfm?catid=390&threadid=117001&enterthread=y#bottom

With Brook+ on SourceForge, this means that it is now a community-driven project and will not be tied to AMD's v2.0 schedules. It most certainly doesn't mean that Brook+ no longer exists with OpenCL. It is now running in parallel with OpenCL. If the maintainers chose, an OpenCL backend for Brook+ is not out of the question.
Hm...

[deekey777]

Das aktuelle Update für PowerDVD9 Ultra bringt auch TrueTheater über ATi Stream mit. Interessant ist, dass das "Upscaling" über Brook+ läuft und deswegen gibt es es auch eine Textdatei "brook_license". :D

[_DrillSarge]I[]

Stream SDK 2.01
http://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx

Update release for ATI Stream SDK v2.0.
Support for Red Hat® Enterprise Linux® 5.3.
Support for debugging OpenCL™ with GDB on x86 CPUs under Linux® (see application note for more details).
Preview: Support for OpenCL™ / Microsoft® DirectX® 9 interoperability. Please see this knowledge base article for more information about this preview feature.
Additional OpenCL™ samples:
o BoxFilter
o FFT
o GaussianNoise (under cpp_cl)
o URNG
Stream KernelAnalyzer with OpenCL™ support (available for download separately from Stream KernelAnalyzer Product Page).
Various OpenCL™ compiler and runtime fixes and enhancements (see developer release notes for more details).
Support for ATI Radeon™ HD 5670 GPU and ATI Radeon™ HD 5570 GPU.

[Coda]

Additional OpenCL™ samples:
o BoxFilter
o FFT
o GaussianNoise (under cpp_cl)
o URNG
ZOMG wow! scnr X-D

[Air Force One]

ZOMG wow! scnr X-D

German Please! :confused: :freak:

[Coda]

Naja, die Samples sind nicht gerade die Highlights im Stream SDK ;)

[Benedikt]

Existiert mittlerweile brauchbare Video-Re/Encodingsoftware, die ATI Stream zur Beschleunigung nutzt und gute Videoqualität bietet? Bräuchte sowas in die Richtung für iPhone, iPad und co.

Oder bleib' ich da am besten bei Handbrake?

[_DrillSarge]I[]

Stream SDk 2.1


Support for openSUSE™ 11.2 and Red Hat® Enterprise Linux® 5.4.
Support for OpenCL™ / OpenGL® interoperability.
Support for OpenCL™ byte addressable stores3,4.
Support for OpenCL™ images3.
Extension: Support for double-precision floating point basic arithmetic in OpenCL™ C kernels.
Extension: Support for AMD media operations in OpenCL™.
Extension: Support for device fission in OpenCL™ 4.
Extension: Support for device attribute queries in OpenCL™.
Preview Feature: Support for binary OpenCL™ kernels.

Additional OpenCL™ samples:
HistogramAtomics
MatrixMulDouble (under cpp_cl)
MatrixMulImage
SimpleGL
SimpleImage
SobelFilterImage (under cpp_cl)
URNGNoiseGL

Stream KernelAnalyzer 1.5 installer now bundled with the ATI Stream SDK v2.1.
Various OpenCL™ compiler and runtime fixes and enhancements (see developer release notes for more details).

Support for new hardware:
ATI Radeon™ HD 5830 GPU
ATI Radeon™ HD 5450 GPU
ATI FirePro™ V8800 GPU
ATI FirePro™ V7800 GPU
ATI FirePro™ V5800 GPU
ATI FirePro™ V4800 GPU
ATI FirePro™ V3800 GPU
ATI Mobility Radeon™ HD 5800 Series GPUs
ATI Mobility Radeon™ HD 5700 Series GPUs
ATI Mobility Radeon™ HD 5600 Series GPUs
ATI Mobility Radeon™ HD 5400 Series GPUs
ATI FirePro M7820™ GPU
ATI FirePro M5800™ GPU
http://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx

[deekey777]

ATI Stream SDK roadmap (http://oscarbg.blogspot.com/2010/07/ati-stream-sdk-roadmap.html)
Da hat sich AMD viel vorgenommen, aber lässt sich auch viel Zeit dafür.

[=Floi=]

gut gesagt. es fehlt ja dann auch an der perfekten unterstüzung und irgendwie geht das bei ati völlig unter.