OpenCL-Spezifikationen sind draußen [Archiv]

Gast

2008-12-09, 12:22:11

Hat schon jemand Treiber angekündigt?

Snow Leopard wird als erstes BS OpenCL unterstützen.
Davor wird für die anderen Betriebssysteme wohl nichts erscheinen.
Gleichzeitig oder kurz danach wird es wohl für Linux und andere UNIX-Ableger erscheinen.
Vor Windows 7 würde ich mit keinem OpenCL Treiber für Windows rechnen.

Wobei man dazu sagen muss, dass OpenCL vor allem für den professionellen und prof. wissenschaftlichen Sektor interessant sein dürfte.
Mal abgesehen von AutoCAD und SolidWorks gibt es jede prof./prof. wissenschaftliche Software auch für UNIX-Ableger wie Linux, HP-UX, IRIX, Solaris, AIX oder OSX.
Es wäre natürlich weitaus einfacher, wenn OpenCL schnellstmöglich auch für Windows erscheinen würde, da man dann die genutzte Schnittstelle übernehmen könnte.
Man kann im prof. Sektor seit Vista jedoch wieder einen eindeutigen Trend in Richtung UNIX feststellen. Die alten Systeme laufen mit Windows 2000/XP und die neueren mit UNIX-Derivaten. Von daher wird GPGPU bei Windows wohl hauptsächlich durch die DirectX11-Komponenten gelöst werden und das dann wohl eher wieder in Richtung Games.
Das würde den Windows-Ruf als überladenes Daddelsystem leider nur weiter festigen und die Professionellen davon fernhalten.

Naja, warten wir mal ab.

mekakic

2008-12-09, 12:34:32

Versteh ich ehrlich gesagt nicht, das ist doch nicht Sache des Betriebssystem, sondern der Hardware? Wenn ich OpenCL Anwendungen bauen will, dann würde ich erwarten, daß mir NVIDIA Treiber mit entsprechende API Anbindung anbietet. Wie bisher mit CUDA auch...

deekey777

2008-12-09, 12:39:24

Hat schon jemand Treiber angekündigt?
Vielleicht kommen noch die entsprechenden Pressreleases, die Dokumentation ist auch auf den 12.08.08 datiert.

Gast

2008-12-09, 13:07:12

Pinoccio

2008-12-09, 13:23:13

Laut Nvidia laufen OpenCL-Applikationen nahtlos auf Grafikkarten, die über einen CUDA-tauglichen Treiber ins System eingebunden sind. Das sind – bis auf Mobil-Grafikchips mit proprietären Treibern der Notebook-Hersteller – praktisch alle (DirectX-10-tauglichen) Nvidia-GPUs der letzten zwei Jahre.

Quelle: heiseJa, (http://www.heise.de/newsticker/Progammierschnittstelle-OpenCL-verabschiedet--/meldung/120125) und bei ATi/AMD solls demnächst auch gehen. Nur Intel scheint nicht zu wollen mit seinem Larabee. :-(
Schade.

mfg

Gast

2008-12-09, 17:50:42

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

Warhammer Online

2008-12-09, 18:01:35

Bei Mobilen nVidia GPUS (8er Serie) sollte es doch auch gehen oder?
Meine 8800M GTX hat ja CUDA....oder?

thacrazze

2008-12-09, 18:31:43

Bei Khronos ist das leider so, die bringen einen Standard raus und dann fangen die an zu schlafen. Tiefer, seeehr tiefer Schlaf, nur kleinere Nuancen an Weiterentwicklung. Den Zocker interessiert das freilich nicht denn die Spiele laufen schon längst mit DirectCL 6.0.
<°)))o>< Jetzt krieg ich bestimmt ne Verwarnung von nem Moderator xD

Gast

2008-12-09, 18:31:59

Bei Mobilen nVidia GPUS (8er Serie) sollte es doch auch gehen oder?
Meine 8800M GTX hat ja CUDA....oder?
Ja definitiv. Ich hab auf meinem Lappi mit 8600M GT CUDA entwickelt, laufen lassen hab ichs dann aber doch auf der Tesla an der Uni... :D

SavageX

2008-12-09, 20:18:23

Nur Intel scheint nicht zu wollen mit seinem Larabee. :-(

Intel hat an OpenCL mitgearbeitet und wird es auch (so mir bekannt) unterstützen.

=Floi=

2008-12-10, 16:31:10

apple und nv arbeiten wohl intern enger zusammen. NV unterstützt ja jetzt schon opencl und dank apple konnten die wohl ihre wünsche durchdrücken...

thacrazze

2008-12-10, 18:14:02

Was meint ihr wer die besseren Chancen hat? OpenCL oder DX11CS?

dust

2008-12-10, 18:19:43

opencl + opengl

Coda

2008-12-10, 18:40:45

Was meint ihr wer die besseren Chancen hat? OpenCL oder DX11CS?
Im reinen GPGPU-Anwendungsbereich nehme ich an, dass OpenCL der Standard wird.

Für Spiele würde ich annehmen, dass die meisten natürlich die CS verwenden.

opencl + opengl
Ach halt dich doch einfach mal raus. Ganz ehrlich, du hast NULL Fachkompetenz.

Gast

2008-12-10, 18:46:46

wann ist denn mit passender software zu rechnen? kann erst jetzt mit der entwicklung angefangen werden oder war das schon vorher möglich?

Coda

2008-12-10, 19:06:42

Jetzt erst. Außerdem braucht man auch erst noch gut funktionierende Treiber.

Die Sache ist CUDA und Brook++ aber sehr ähnlich.

ScottManDeath

2008-12-11, 00:42:56

Praktisch waere ein nvcc mit OpenCL als back end. Dies sollte recht einfach moeglich sein, da OpenCL grob der CUDA Driver Runtime entspricht. Es bricht mich an das ich bei der CUDA driver Runtime und der OpenCL Runtime Funktionen aufrufen muss um Kernel Parameter zu setzen, waehrend der nvcc das schoen wrappt und hinter meinem Ruecken macht, so dass ich einfach C-code schreiben kann. Das macht SW Engineering, was bei der moeglichen Komplexitaet brauchbar und teilweise sinnvoll ist, eine ganze Ecke einfacher.

deekey777

2008-12-25, 18:56:01

http://sa08.idav.ucdavis.edu/
Dort sind einige Präsentationen zu OpenCL zu finden.

Nasenbaer

2008-12-25, 21:24:37

Weiß einer ab wann es Compiler usw. sowie Treiber (für nVidia GPUs) geben wird? Will nicht jetzt noch die CUDA Syntax lernen.

=Floi=

2008-12-26, 00:08:02

http://www.computerbase.de/news/hardware/grafikkarten/2008/dezember/khronos_opencl-10-spezifikationen/
http://www.nvidia.de/object/io_1229090804255.html
nv unterstützt es schon!

_DrillSarge]I[

2008-12-26, 00:15:36

mal am rande:
auf den nv-seiten zu cuda (kam da jetzt durch die opencl-pressemitteilung drauf):

"anzeige" an der seite:
Using NVIDIA CUDA Technology, a GeForce GTX 280 GPU runs SETI@home is nearly 10 times faster than a AMD Phenom 9950 multi-core consumer CPU.

im text steht dann:
Die Performance von SETI@home mit einer GeForce GTX 280 GPU ist über 2-mal schneller als mit der schnellsten Multi-Core-Consumer-CPU (3,2 GHz, Intel Core i7 965) und fast 8-mal schneller als mit einer üblichen Dual-Core-Consumer-CPU (2,66 GHz, Intel Core2 Duo E8200).
http://www.nvidia.de/object/io_1229578614612.html

hä?
c2d e8200>phenom 9950? in etwas wo jeder kern deutlich mehr bringt?

:biggrin:

deekey777

2008-12-26, 00:39:40

http://www.computerbase.de/news/hardware/grafikkarten/2008/dezember/khronos_opencl-10-spezifikationen/
http://www.nvidia.de/object/io_1229090804255.html
nv unterstützt es schon!
Tun sie nicht (keiner tut das). Denn OpenCL ist noch nicht fertiggestellt.
Wird OpenCL fertig, so wird man wohl auf der CUDA-Seite ein neues Tool-Kit mit OpenCL finden können (bei AMD bin ich mir nicht sicher).

Gast

2008-12-26, 01:12:24

deekey777

2008-12-26, 01:27:04

Häh?

Ich dachte das wäre schon fertig!? Siehe Anfangspost
Die Spzifikationen sind fertig, OpenCL 1.0 noch nicht ganz: http://www.engadget.com/2008/12/09/nvidia-dishes-about-opencl/

OpenCL isn't done yet -- 1.0 is still waiting on performance testing, and a 1.1 version with additional features the working group felt weren't an immediate priority is due later sometime in 2009.

Nasenbaer

2008-12-26, 01:36:21

Tun sie nicht (keiner tut das). Denn OpenCL ist noch nicht fertiggestellt.
Wird OpenCL fertig, so wird man wohl auf der CUDA-Seite ein neues Tool-Kit mit OpenCL finden können (bei AMD bin ich mir nicht sicher).
Ja genau das dachte ich mir nämlich auch. Derzeit kann man offiziell noch nicht in OpenCL entwickeln, da den Source-Code kein Compiler kompiliert.

Ich dachte vielleicht weiß jemand ab wann man loslegen darf. :)

deekey777

2008-12-26, 01:54:31

Nächstes Halbjahr?
AMD will im ersten Halbjahr die volle Unterstützung bieten, NV auch.

Gast

2008-12-26, 02:54:50

Was meint ihr wer die besseren Chancen hat? OpenCL oder DX11CS?
wenn mich nicht alles täuscht ist dx11cl auch nur wieder eine exklusive microsoft geschichte für ihre aktuelle ausgeburt...
das ist ja auch schon mit vista nach hinten los gegangen.

Gast

2008-12-26, 10:25:14

Was meint ihr wer die besseren Chancen hat? OpenCL oder DX11CS?

Diesmal ganz klar OpenCL.

Denn nun ist auch Intel mit Larabee dabei, die werden sich das nicht entgehen lassen.
Microsoft steht ganz alleine mit ihrem DX11CS da.

Und Intel ist ein Riese!

deekey777

2008-12-26, 13:12:40

Was meint ihr wer die besseren Chancen hat? OpenCL oder DX11CS?
Das ist ein zweischneidiges Schwert:
Compute Shader haben einen großen Vorteil, weil die IHVs diese CS für die DX11-Kompabilität nicht nur unterstützen müssen, sondern ihre Hardware darauf ausgerichtet haben; den Rest erledigen dann die Treiber. Und wenn DX11 draußen ist, werden die Softwarehersteller gaaaanz sicher sein, dass ihre Software, die CS nutzt, auch laufen wird (wobei ich mich auch Frage, ob die Treiberentwicklungsabteilungen dieses Anspruch auch erfüllen können, denn heutige Treiber können das nicht).

Bei OpenCL kommt noch eine weitere Hürde dazu: OpenCL ist "nur" eine Sprache, es wird immernoch ein weiterer Zwischenakt benötigt, damit der OpenCL-Code auf der Grafikkarte läuft. Und das ist der wohl wichtigste Punkt: Ist der Compiler (zB OpenCL -> IL für Radeons) mies, wird man OpenCL meiden, wenn man damit Radeon-GPUs nutzen will. Und Gleiches gilt für Nvidia-GPUs. Nur glaube ich nicht, dass das passieren wird.

Demirug

2008-12-26, 13:57:46

Das ist ein zweischneidiges Schwert:
Compute Shader haben einen großen Vorteil, weil die IHVs diese CS für die DX11-Kompabilität nicht nur unterstützen müssen, sondern ihre Hardware darauf ausgerichtet haben; den Rest erledigen dann die Treiber. Und wenn DX11 draußen ist, werden die Softwarehersteller gaaaanz sicher sein, dass ihre Software, die CS nutzt, auch laufen wird (wobei ich mich auch Frage, ob die Treiberentwicklungsabteilungen dieses Anspruch auch erfüllen können, denn heutige Treiber können das nicht).

Also wir hatten bisher recht wenige Problem was die Ausführung von Direct3D 10 Shadercodes angeht. Die neuen CS nutzen ja nun den gleichen Bytecode mit einigen Erweiterungen. Ich erwarte da ehrlich gesagt keine massiven Probleme.

Bei OpenCL kommt noch eine weitere Hürde dazu: OpenCL ist "nur" eine Sprache, es wird immernoch ein weiterer Zwischenakt benötigt, damit der OpenCL-Code auf der Grafikkarte läuft. Und das ist der wohl wichtigste Punkt: Ist der Compiler (zB OpenCL -> IL für Radeons) mies, wird man OpenCL meiden, wenn man damit Radeon-GPUs nutzen will. Und Gleiches gilt für Nvidia-GPUs. Nur glaube ich nicht, dass das passieren wird.

„Mies“ ist nicht das Problem. Ich fürchte nur dass es wieder zu den gleichen Problemen wie bei GLSL kommt. Jeder legt die Syntax etwas anders aus und schon haben wir wieder inkompatible Parser. Da man dieses Problem im Prinzip mit jeder Hochsprache hat glaube ich auch nicht dass es lösbar ist.

Hardwareabstraktion auf dieser Ebene funktioniert eben nur mit Bytecodes und VMs.

deekey777

2008-12-26, 19:24:36

Was dient eigentlich für OpenCL als Hardware-Basis, sprich welche Grafikkarte bzw. deren Features sind das gemeinsame Nenner?
Irgendwie habe ich das Gefühl, dass OpenCL erst ab HD4000 sowie auf der gesamten CUDA-fähigen Generation von Nvidia laufen wird. Ein ähnliches Statement von AMD wie das von NV (OpenCL läuft auf allen CUDA-fähigen Grafikkarten) habe ich noch nicht gesehen; R600&RV670 ist eigentlich GPGPU-mäßig bei Weitem nicht so fähig wie der G80.

SavageX

2008-12-26, 19:30:25

R600&RV670 ist eigentlich GPGPU-mäßig bei Weitem nicht so fähig wie der G80.

Kannst Du diesen Punkt weiter ausführen?

Gast

2008-12-26, 19:36:20

@ Deekey:

Es gibt aber schon seit LANGEM den RV770 (HD48x0)

_DrillSarge]I[

2008-12-26, 20:15:10

Kannst Du diesen Punkt weiter ausführen?
ich denke mal er meint die software-seite. irgendwelche hardware-limitierungen wären mir neu.

@gast: g80 gibt es noch viel länger ;)

Coda

2008-12-26, 20:34:51

Kannst Du diesen Punkt weiter ausführen?
NVIDIA unterstützt seit G80 arbitrary sharing von Daten für GPGPU. R600 und RV670 können gar nichts sharen und erst RV770 kann es halbwegs, aber auch nicht beliebig.

Für D3D11 Compute Shader (D3D11-Tech-Level) ist arbitrary sharing dann aber verpflichtend, also wird es der nächste erste ATI D3D11-Chip auch können.

Gast

2008-12-26, 23:26:24

NVIDIA unterstützt seit G80 arbitrary sharing von Daten für GPGPU. R600 und RV670 können gar nichts sharen und erst RV770 kann es halbwegs, aber auch nicht beliebig.

Für D3D11 Compute Shader (D3D11-Tech-Level) ist arbitrary sharing dann aber verpflichtend, also wird es der nächste erste ATI D3D11-Chip auch können.
Ergebnisse 1 - 2 von 2 Seiten auf Deutsch für "arbitrary sharing" . (0,47 Sekunden)
http://www.google.de/search?hl=de&client=firefox-a&rls=org.mozilla%3Ade%3Aofficial&hs=PML&q=%22arbitrary+sharing%22&btnG=Suche&meta=lr%3Dlang_de

Sicher das du dir das nicht ausgedacht hast?

Gast

2008-12-26, 23:28:05

Ok immerhin 747 einträge bei suche im web

deekey777

2008-12-26, 23:34:21

Hm...
Mit dem RV770 kam ein neuer Shader-Typ namens CAL Compute Shader. Hier die lange Version:
http://forum.beyond3d.com/showpost.php?p=1223138&postcount=2
Compute shaders provide an explicit "thread ID" based programming model. They're only programmable with CAL, which is basically a bastard offspring of D3D assembly with lots of machine-specific knobs and features (and backwards compatibility for HD2xxx-onwards GPUs).

Compute shaders also do away with the "graphics" sense of a kernel, so inputs can no longer include "interpolated attributes" (mirroring vertex attribute interpolation in graphics programming) and the outputs have to be explicit writes ("memexport") to memory locations, instead of outputs into a "virtual render target". Inputs can consist of "memimport" or sampling using the texturing hardware, but with no "vertex attribute interpolation" all sampling operations are forced to be dependent, i.e. computed based on thread ID and whatever else the programmer decides.

The explicit thread ID model also forms the basis of the "data share" mechanism in CAL. Here any "thread" can write data to any one of its own, 64 vec4 (128 bit) locations. Then, any other thread can read any of these 64 locations. So it's a sort of broadcast model without any explicit destination. Think of it as "write private/read public", which requires explicit synchronisation by the programmer. The Local Data Share and Global Data Share memories in RV7xx are where this action happens. I guess it involves a fair amount of juggling, moving LDS/GDS to/from video memory, and therefore involves a fair amount of latency-hiding, similar to the way GPUs hide the latency of texturing.

Overall, CAL compute shaders could be described as a CUDA-isation in terms of explicit thread ID based programming and the explicit use of shared memory. Or it could be the model that's been drawn up for D3D11 compute shaders. Or maybe just a significant portion of it. Note that RV7xx's shared memory model isn't the same as CUDA's. CUDA allocates a fixed-size block of memory to be shared by all warps extant in a multiprocessor (thread block). So with less warps each thread has more memory to use. And all threads can write to all locations. But data cannot be shared with warps on other multiprocessors or in other clusters. That requires the programmer to do a separate write/read via video memory.

Brook+ already exposes thread IDs and allows for "threads" to exchange data as well as hiding from the programmer the "graphics-ness" of GPGPU programming.

I suppose the changes in RV7xx architecture will increase the efficiency of threaded Brook+ programming. But progress on Brook+ is very slow, and I can imagine OpenCL and D3D11 will gain the lion's share of AMD's internal software engineering resources.

Brook programming was originally about a pure streaming model of computation with no ability to access and manipulate thread IDs and sharing data across threads. CUDA's main break with Brook was to abandon that pure streaming model as being too restrictive. AMD has basically come to the same realisation in Brook+ and is now on the second iteration of supporting this functionality directly in hardware. D3D11 Compute Shader is also based on that realisation. So one way or another AMD had no choice and I suspect CAL compute shader is either a preview of D3D11 CS or is a major step in that direction.

Jawed

Hier die kurze:
http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=104563&enterthread=y&STARTPAGE=1
Compute Kernels (aka Compute Shaders) are a more generic way of launching Kernels on R7xx GPUs. The best way to understand them is to recall that modern GPUs have graphics specific pipelines and currently, CAL by default launches kernels using Pixel Shaders. You can think of these shaders as being invoked during the rasterization of screen aligned quadrilaterals. However, this involves various kinds of interactions with and dependence on the graphics pipeline. e.g. If you look closely, each CAL kernel has a title il_ps_* (for pixel shader mode) and vPos/vWinCoord for current fragment position.

Compute Kernels basically relax these dependencies. You have direct access to thread IDs in the kernels and you can control various thread group parameters. Compute Kernels also allow you to access R7xx's on-ship per-SIMD shared memory.
Das kann der G80. Auch beherrscht er Scatter/Gather in Hardware, was erst der RV670 halbwegs beherrschte.

Coda

2008-12-26, 23:37:13

Sicher das du dir das nicht ausgedacht hast?
Ja. Such nach arbitrary memory read.

SavageX

2008-12-27, 11:37:05

deekey777

2009-02-06, 14:16:44

AMD OpenCL parallel computing demo from Siggraph Asia 2008 (http://fireuser.com/blog/amd_opencl_parallel_computing_demo_from_siggraph_asia_2008/)

Coda

2009-02-06, 17:00:27

Das läuft aber soweit ich den Text verstanden habe auf der CPU.

Nasenbaer

2009-02-07, 00:35:13

So hab ich das auch gelesen. Wobei ich das sogar recht cool finde, da man dann nicht nur eine einheitliche Möglichkeit zur für GPUs, sondern auch für CPUs hat und das auf allen relevanten Plattformen.
Man hat da dann zwar, soweit ich OpenCL verstanden hab, keine Objektorientierung wie man sie bei heutigen CPU Threading Libs hat aber dafür dürfte der Code recht leicht so zu schreiben sein, dass er sowohl auf Multicore CPUs als auch auf GPUs läuft.
Man diskutiert ja auch schon die Unterstützung für OpenCL im GCC: http://www.phoronix.com/scan.php?page=news_item&px=NzAzMA aber ob damit die Erzeugung von CPU oder GPU Code gemeint ist weiß ich allerdings nicht.

deekey777

2009-02-07, 00:55:12

Das läuft aber soweit ich den Text verstanden habe auf der CPU.
AMD baut auch CPUs. Und OpenCL muss auch auf CPUs überzeugen, denn Intel will ja mit Ct ein eigenes Süppchen kochen.
Andere Möglichkeit wäre, dass AMD Stream noch keinen Support für OpenCL hat.

deekey777

2009-03-08, 02:38:24

Boah, was ganz Interessantes vergessen:
http://forum.beyond3d.com/showpost.php?p=1271074&postcount=100
Linux OpenCL on a Quadro FX 570M:

http://www.youtube.com/watch?v=dXy_ssSGuy0

This is the demo we showed at SIGGRAPH Asia back in December. It's the CUDA SDK nbody sample ported to OCL (so no native kernels or anything like that, it's all 100% OCL).
Neues Overview:
http://www.khronos.org/developers/library/overview/opencl_overview.pdf

Gast

2009-03-08, 04:41:08

Wo kann man denn die OpenCL Demo downloaden?

Würde das gerne mal selber auf meiner Geforce 8800 GTS 640MB ausprobieren.

deekey777

2009-03-20, 01:19:17

Endlich wurde der Artikel zu OpenCL Hardware.fr (http://www.hardware.fr/articles/744-1/opencl-gpu-computing-enfin-democratise.html) ins Englische (http://www.behardware.com/articles/744-1/opencl-democracy-for-gpu-computing.html) übersetzt.
Hoffentlich wird die "CUDA ist tot"-Fraktion endlich still.

Gast

2009-03-20, 04:12:08

In dem Artikel steht eigentlich nur, daß Microsofts Direct3d 11 mit den Compute Shadern das Rennen mal wieder gewinnen wird:

It isn’t as easy to see what will happen in terms of general public products. Indeed, here, OpenCL is pretty disappointing in as much as it doesn’t standardise specs at all.

Fazit:
OpenCL ist schon tod bevor es zu leben beginnt.

Gast

2009-03-20, 04:14:28

Cuda wird niemals sterben da jetzt schon in wissenschaftlichen Bereichen auf Cuda gesetzt wird. Ein Beispiel ist folding@home, das reicht schon.

Gast

2009-03-20, 04:15:10

Weiter unten steht dann auch noch etwas mehr dazu:

Of course it is easier to use OpenCL for both GeForces and Radeons than C for CUDA for one and Brook+ for the other, but there is still a lot of work required. OpenCL suffers from the same problem as OpenGL in a bigger way and we’ll probably have to wait for DirectX 11 until GPUs can be used as massively parallel co-processors for general public solutions. Unless developers who exploit OpenCL decide to do so bearing in mind common spec defined in DirectX11, so as to nip any bad habits in the bud.

DirectX 11 ist schon jetzt der Sieger als GPGPU Lösung für die breite Masse, also vorrangig unserer Spiele, also da wo es wichtig ist.

Gast

2009-03-20, 04:16:33

Cuda wird niemals sterben da jetzt schon in wissenschaftlichen Bereichen auf Cuda gesetzt wird. Ein Beispiel ist folding@home, das reicht schon.
CUDA ist ne Nischenlösung, entscheident ist nur, was von den Spieleentwicklern benutzt werden wird und das ist nach aktueller Spec definitiv nicht OpenCL, sondern DirectX 11.

Gast

2009-03-20, 04:18:14

Directx11 wird in Spielen erst durchschlagen wenn die Karten in weiter Masse verbreitet sind. Cuda ist ähnlich DX11 und jetzt schon sehr verbreitet. Wie ich oben schrieb, Cuda wird JETZT im wissenschaftlichen sowie Videobearbeitungsbereich immer wichtig sein.

reunion

2009-03-20, 07:58:40

Cuda wird niemals sterben da jetzt schon in wissenschaftlichen Bereichen auf Cuda gesetzt wird. Ein Beispiel ist folding@home, das reicht schon.

folding@home konnte schon ein R5xx.

Ailuros

2009-03-20, 09:02:15

Khronos wird eventuell etwas aufraeumen muessen in zukuenftigen OpenCL Versionen (ebenso wie in OpenGL_ES im Vergleich zu OpenGL aufgeraeumt wurde).

OpenCL ist tatsaechlich Apple's "Kind" und anfangs wollten sie das API sogar unter einem anderen Namen patentieren. Dass Apple natuerlich eingesehen hat dass ein open source API nutzvoller fuer alle ist (ueberhaupt wenn Apple kein IHV ist) ist zum Vorteil aller.

Apple's Initiative hatte IMHLO nicht nur higher end computing im Hinterkopf sondern ein ziemlich weites Anwendungsgebiet von small form factor Geraeten bis zu high end PCs.

OpenCL is being created by the Khronos Group with the participation of many industry-leading companies and institutions including 3DLABS, Activision Blizzard, AMD, Apple, ARM, Barco, Broadcom, Codeplay, Electronic Arts, Ericsson, Freescale, HI, IBM, Intel, Imagination Technologies, Kestrel Institute, Motorola, Movidia, Nokia, NVIDIA, QNX, RapidMind, Samsung, Seaweed, Takumi, Texas Instruments and Umeå University.

Die SW Firmen mal zur Seite konzentriert sich die Mehrzahl dieser Firmen u.a. auf SoCs. Imagination Technologies entwickelt u.a. Grafik/Video IP die in SoCs von Intel, Samsung, Texas Instruments u.a. hergestellt werden. Apple's iPhone hat einen Imagination MBX onboard der von Samsung hergestellt wurde. NOKIA ist Texas Instruments groesster Kunde und Motorolla, Ericsson haben auch Handys im IMG IP.

Dementsprechend ist OpenCL schon jetzt als tot zu erklaeren genauso kurzsichtig als wenn jemand in der Vergangenheit OpenGL_ES gegen OpenGL als tot erklaert haette.

Heterogenes computing kann vom Vorteil in allen Maerkten sein; noch mehr in den vorerwaehnten wo CUDA keinen Sinn macht (selbst fuer NVIDIA Tegra momentan) und D3D11 wohl doch etwas zu anspruchsvoll ist fuer die Mehrzahl aller IHVs die HW fuer diese Maerkte entwickeln.

Uebrigens hab ich respektiere ich zwar Damien Triolet als Author, aber er hat auch nicht immer recht:

Indeed Neil Trevett, formerly of 3D Labs and currently VP of Embedded Content at NVIDIA, heads up the OpenCL work group. Given the similarity between C for CUDA and OpenCL and the fact that, officially, Apple initiated the idea and put it forward for discussion (after having decided to equip its new Macs with NVIDIA products…), NVIDIA can in reality be seen as a joint instigator.

Was zum Teufel hat Trevett damit zu tun? Er ist sowieso der "Vorstand" im gesamten Khronos Group und insgesamt sieht es eher so aus: http://www.khronos.org/about/ , wobei NVIDIA alles andere als ein Vorreiter fuer diese Maerkte ist. Apple hat einen multi-year/multi-license Vertrag mit IMG und auch ueber 3% in Aktien was IMG betrifft. Man koennte genauso behaupten dass Apple es mit IMG gebacken hat was auch nicht stimmt. Ich hatte die Chance Apple's Pantent fuer das API zu lesen (welches nie eingereicht wurde) und leider nicht irgendwo gespeichert. Mir als Laien klang das Ganze nach Apple's eigener Entwicklung. Als OpenCL daraus wurde haben natuerlich womoeglich andere auch noch mitgeholfen, aber bei weitem keine Apple/NV Initiative.

NVIDIA is hammering the point home by underlining the fact that OpenCL was developed on its GPUs and that they have been the first to demo it.

Man kann vieles behaupten; Tegra war auf jeden Fall nicht frueher lauffaehig als SGX...

Fuer den Rest: Innovation sollte nicht sterben, sondern eher kurzsichtige und parteiisch orientierte Perspektiven.

Gast

2009-03-20, 09:56:20

DirectX 11 ist schon jetzt der Sieger als GPGPU Lösung für die breite Masse, also vorrangig unserer Spiele, also da wo es wichtig ist.
CUDA ist ne Nischenlösung, entscheident ist nur, was von den Spieleentwicklern benutzt werden wird und das ist nach aktueller Spec definitiv nicht OpenCL, sondern DirectX 11.
Mir scheint manche haben nicht ganz verstanden worum es beim GPGPU geht. Nämlich um general purpose, also nicht um Spiele. Wenn man nur Spiele machen wollte könnte man ja gut mit den bestehenden Lösungen leben, CUDA & Co wurden jedoch explizit deswegen entwickelt um von den Beschränkungen einer Spiele Graphics-API loszukommen. (Gather/Scatter anyone?)
Insofern ist es für GPGPU relativ egal was sich am Spielemarkt durchsetzt, da es sich hier um zwei ganz unterschiedliche Baustellen handelt.

IMO hat CUDA einfach dadurch einen riesigen Vorteil dass es jetzt schon weit verbreitet und von der Community angenommen ist. In Kürze erscheint CUDA 2.2, welche andere Lösung kann denn überhaupt eine 1.x Versionsnummer aufweisen?
Bei so einem Vorsprung werden es andere Lösungen schwer haben...

lg

Coda

2009-03-20, 12:37:48

D3D11 CS können gather und scatter und Direct3D kann auch ab der Version 10 "headless" operieren, also ganz ohne grafische Ausgabe.

Der Vergleich zu CUDA und OpenCL ist also durchaus berechtigt.

deekey777

2009-03-20, 14:52:41

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.
http://twitter.com/CatalystMaker/status/1356572319
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

Da Brook+ eher ein Reinfall ist (Übertreibung), ist OpenCL für viele Leute, die ATi Stream nutzen (wollen), die (Er-)Lösung. AMD pusht OpenCL nicht umsonst so stark, so dass der Eindruck entsteht, dass Nvidia OpenCL als "nett" ansieht.

Was DX11 angeht:
Die Frage ist doch, ob mit DX11 CS Lösungen möglich sind, die die Hardware vollständig ausreizen können. Wenn man davon ausgeht, dass CS nicht nur von den künftigen DX11-GPUs unterstützt wird, sondern auch von den aktuellen GPUs, so ist die Wahrscheinlichkeit nicht gerade gering, dass auch hier die Entwickler mehrere HW-spezifische Codes schreiben werden.

Coda

2009-03-20, 15:03:02

Es wird fixe Techlevel geben bei den CS. Wahrscheinlich cs_4_0 und cs_5_0.

Gast

2009-03-20, 20:01:36

D3D11 CS können gather und scatter und Direct3D kann auch ab der Version 10 "headless" operieren, also ganz ohne grafische Ausgabe.

Der Vergleich zu CUDA und OpenCL ist also durchaus berechtigt.
Mit einem Bagger kannst du auch von A nach B fahren, aber trotzdem ist das Einsatzgebiet ein anderes als das eines PKWs.

Der Gast von vorher meint dass es entscheidend für den GPGPU Sektor ist was die Spieleentwickler nutzen, ich halte das Argument dagegen dass es irrelevant ist weil 2 verchiedene Baustellen.
Das D3D11 gather/scatter kann ist ja schön, aber es ist und bleibt eine (Spiele-)Grafik API, oder nicht? Genauso wie ein Bagger eben ein Bagger ist und man mit dem nicht zum Aldi einkaufen fährt. Für sowas nimmt man einen PKW (oder umweltfreundlich: ein Fahrrad). Wenn also Baggerfirma X auf einmal viel bessere Bagger baut als Baggerfirma Y, dann werden die Baggerfahrer fürderhin mit Baggern der Firma X arbeiten. Den Hausfrauen die zum Aldi einkaufen fahren wollen wird das aber herzlich egal sein. Ich hoffe du verstehst mich.

Vielleicht zur Erinnerung die Aussagen um die es geht:

DirectX 11 ist schon jetzt der Sieger als GPGPU Lösung für die breite Masse, also vorrangig unserer Spiele, also da wo es wichtig ist.

CUDA ist ne Nischenlösung, entscheident ist nur, was von den Spieleentwicklern benutzt werden wird und das ist nach aktueller Spec definitiv nicht OpenCL, sondern DirectX 11.

lg

Coda

2009-03-20, 22:50:44

Das D3D11 gather/scatter kann ist ja schön, aber es ist und bleibt eine (Spiele-)Grafik API, oder nicht?
Für das Anwendungsgebiet nicht. D3D11 wird die Stream-API sein die auch Microsoft verwenden wird. DirectX ist auch nicht speziell auf Spiele ausgelegt, schon gar nicht mehr ab 10.

Das Beispiel ist dämlich. Nur weil etwas Bestandteil von etwas ist was auch mehr kann ist es noch lange nicht schlecht.

Gast

2009-03-20, 23:20:54

Für das Anwendungsgebiet nicht. D3D11 wird die Stream-API sein die auch Microsoft verwenden wird. DirectX ist auch nicht speziell auf Spiele ausgelegt, schon gar nicht mehr ab 10.

Das wär mir neu, ich sah das Hauptanwendungsgebiet von DX immer bei Spielen:
Microsoft DirectX is a collection of application programming interfaces (APIs) for handling tasks related to multimedia, especially game programming and video, on Microsoft platforms. Quelle (http://en.wikipedia.org/wiki/DirectX)
Mit Hauptanwendungsgebiet meine ich dass es zu mehr als 85% in diesem Bereich eingesetzt wird.

Das Beispiel ist dämlich. Nur weil etwas Bestandteil von etwas ist was auch mehr kann ist es noch lange nicht schlecht.
Ich behaupte ja auch nicht dass es schlecht wäre.
Aber entscheident [für GPGPU, Anm.] ist nur, was von den Spieleentwicklern benutzt werden wird finde ich einfach nicht richtig, dafür sind die Anwendungsgebiete zu verschieden.
So wie es im Moment aussieht führt m.M.n. an CUDA kein Weg vorbei. Es ist ausgereift, es gibt eine große Community und es wird von Nvidia aktiv vorangetrieben. Nach meinen Informationen wird es beispielsweise mit CUDA 2.2 möglich sein aus einem Kernel heraus direkt in den Hauptspeicher zu schreiben/lesen. Ist zwar aus performancetechnischer Sicht vermutlich nicht so toll, aber es zeigt deutlich wohin CUDA geht: Nämlich weit über eine einheitliche GPU-API die halt "zufällig" auch gather/scatter unterstützt hinaus.
D3D11 hingegen ist noch nichtmal veröffentlicht, oder? Den Vorsprung wird man nur sehr schwer aufholen. Meine Meinung.

lg

Gast

2009-03-21, 18:18:00

albix64

2009-03-21, 18:56:22

http://www.khronos.org/news/events/detail/gdc_san_francisco_2009/

Freue mich da besonders auf die Vorstellung von OpenGL 3.1 und "OpenGL: Blizzard's Perspective on OpenGL"

Gast

2009-03-21, 19:47:41

Ja, alle Welt stürzt sich auf Cuda weil es auch so viele gibt die es unterstützen.
Wie viele Hersteller waren das nochmal?
Sonst wird über jeden hergezogen der etwas proprietäres durchsetzen will. Hier wird vor Freude ein Luftsprung nach dem anderen gemacht.
Irgendwo muss es anfangen, und in dem Fall waren halt Nvidia die ersten die (lange vor AMD/ATI und DX) was vernünftiges in Richtung GPGPU gemacht haben. Dass sie das mit ihren eigenen Chips tun kann man ihnen nun wirklich nicht vorwerfen.
Mit D3D11 bist du Windows only, mit CUDA Nvidia only, so what? (Wobei IMHO Plattformunabhängigkeit wichtiger ist als Herstellerunabhängigkeit. IMO)

Nur zur Klarstellung, mir wärs auch lieber wenn CUDA nicht auf Nvidia beschränkt wär, aber wie gesagt im Moment gibt es eben nichts was annähernd so ausgereift wäre. Vielleicht kann ja OpenCL diese Position übernehmen, aber die sind eben gut 2 Jahre hintendran.

lg

Gast

2009-03-21, 19:54:53

OpenCL 2 Jahre hinten? Na dann zeig mal die Nachteile der API gegenüber CUDA...

Gast

2009-03-21, 20:04:03

OpenCL 2 Jahre hinten? Na dann zeig mal die Nachteile der API gegenüber CUDA...
Ach komm, OpenCL 1.0 vs. CUDA 2.2? Glaubst du nicht dass sich dieser Versionsunterschied irgendwo bemerkbar macht? Ein paar Stichworte hierzu: Dokumentation, Ausgereiftheit der Tools, Anzahl der gefundenen und gefixten Bugs, Akzeptanz in der Community...
All diese Dinge sind neben den rein technischen Aspekten immens wichtig für eine so "neue" Disziplin wie GPGPU, und in dieser Hinsicht steht OpenCL eben ohne irgendwas da. Oder gibt es sowas ähnliches wie das (http://cudatemplates.sourceforge.net/doc/html/) auch für OpenCL? (Man beachte das Codebeispiel) Solche Sachen leben einzig und allein von der Community.

lg

HarryHirsch

2009-03-22, 00:26:24

Ach komm, OpenCL 1.0 vs. CUDA 2.2? Glaubst du nicht dass sich dieser Versionsunterschied irgendwo bemerkbar macht? Ein paar Stichworte hierzu: Dokumentation, Ausgereiftheit der Tools, Anzahl der gefundenen und gefixten Bugs, Akzeptanz in der Community...
All diese Dinge sind neben den rein technischen Aspekten immens wichtig für eine so "neue" Disziplin wie GPGPU, und in dieser Hinsicht steht OpenCL eben ohne irgendwas da. Oder gibt es sowas ähnliches wie das (http://cudatemplates.sourceforge.net/doc/html/) auch für OpenCL? (Man beachte das Codebeispiel) Solche Sachen leben einzig und allein von der Community.

lg

Schon mal daran gedacht das den Entwicklern eine breite und freie Softwareschnittstelle lieber sein könnte? Eine die halt alle Hardwareentwickler abdeckt?

Gast

2009-03-22, 20:17:22

Schon mal daran gedacht das den Entwicklern eine breite und freie Softwareschnittstelle lieber sein könnte? Eine die halt alle Hardwareentwickler abdeckt?
Hätte ich auch lieber, wenn ich mich mal selber zitieren darf:

Nur zur Klarstellung, mir wärs auch lieber wenn CUDA nicht auf Nvidia beschränkt wär[...]
Dass CUDA momentan allen davonläuft ist das Ergebnis der frühen Investitionen von Nvidia in GPGPU, das macht sich jetzt halt bezahlt. Das kann man persönlich gutheißen oder auch nicht, aber IMO kann man es Nvidia nicht ankreiden.

Lange gab es nichts für GPGPU, dann gibt es was und derjenige der die Pionierarbeit leistet wird hinterher dafür an die Wand gestellt? Gehts noch?

Sobald OpenCL einen ähnlich ausgereiften Status erreicht wie CUDA bin ich der erste der es benutzt, bis dahin bleibe ich bei CUDA. Das hat nämlich die lästige Phase der Kinderkrankheiten bereits überwunden.

lg

AnarchX

2009-03-29, 18:06:45

Nvidia scheint wohl doch nicht den Weg OpenCL -> CUDA -> GPU zu gehen, sondern OpenCL/CUDA -> PTX -> GPU:
http://img18.imageshack.us/img18/5069/kaigai497122619263.jpg (http://img18.imageshack.us/my.php?image=kaigai497122619263.jpg)
http://translate.google.ch/translate?u=http%3A%2F%2Fpc.watch.impress.co.jp%2Fdocs%2F2009%2F0330%2Fkaigai497 .htm%3Fref%3Drss&sl=ja&tl=de&hl=de&ie=UTF-8

deekey777

2009-03-29, 18:16:26

Man muss zwischen CUDA API und C for CUDA unterscheiden. C for CUDA ist so etwas wie Brook+, aber damit die Programme in Brook+/OpenCL auf einer Radeon laufen, werden diese in IL (Intermediate Language, "pseudo-assembler") übersetzt und dann an die jeweilige Grafikkarte als ISA weitergeleitet (dafür sind ja mehrere CAL-DLLs da). Der Unterschied bei ATi Stream ist, dass man - verrückt oder fähig genug - Programme gleich in IL schreiben kann.
Selbst wenn OpenCL C for CUDA oder Brook+ verdrängt, bleibt CUDA API bzw. CAL bestehen.

PTX ist Nvidias IL.

Oder?

mekakic

2009-04-03, 09:58:09

Gibt es oder wird es unter OpenCL evtl. etwas Vergleichbares zu NVCUVID geben? Evtl. eine Art Video Extension, mit der man standardisiert auf interne Videodecoder zugreifen kann? Auf OpenCL Geräten, die dann keine Videohardware haben, könnte dann eine Implementierung über normale Kernels verwendet werden?

Coda

2009-04-03, 15:50:26

Nvidia scheint wohl doch nicht den Weg OpenCL -> CUDA -> GPU zu gehen, sondern OpenCL/CUDA -> PTX -> GPU:
Das war von Anfang an klar. Du hast es nur falsch verstanden.

PTX ist Nvidias IL.
Ja.

Ailuros

2009-04-09, 08:38:00

http://www.imgtec.com/News/Release/eventsdetail.asp?EventID=21

http://www.khronos.org/members/benefits/

http://www.khronos.org/about/

deekey777

2009-04-21, 00:56:35

Booooom!!!!!!!

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

FOR IMMEDIATE RELEASE:

SANTA CLARA, CA—APRIL 20, 2009—NVIDIA Corporation, the inventor of the GPU, today announced the release of its OpenCL driver and software development kit (SDK) to developers participating in its OpenCL Early Access Program. NVIDIA is providing this release to solicit early feedback in advance of a beta release which will be made available to all GPU Computing Registered Developers in the coming months.

“The OpenCL standard was developed on NVIDIA GPUs and NVIDIA was the first company to demonstrate OpenCL code running on a GPU,” said Tony Tamasi, senior vice president of technology and content at NVIDIA. “Being the first to release an OpenCL driver to developers cements NVIDIA’s leadership in GPU Computing and is another key milestone in our ongoing strategy to make the GPU the soul of the modern PC.”

At the core of NVIDIA®’s GPU Computing strategy is the massively parallel CUDA™ architecture that NVIDIA pioneered and has been shipping since 2006. Accessible today through familiar industry standard programming environments such as C, Java, Fortran and Python, the CUDA architecture supports all manner of computational interfaces and, as such, is a perfect complement to OpenCL. Enabled on over 100 million NVIDIA GPUs, the CUDA architecture is enabling developers to innovate with the GPU and unleash never before seen performance across a wide range of applications.

Developers can apply to become a GPU Computing Registered Developer at: www.nvidia.com/opencl

_DrillSarge]I[

2009-04-21, 01:52:48

hehe :D

mal sehen, wann amd nachzieht. entweder sehr bald oder ewig später. :biggrin:

deekey777

2009-04-21, 02:05:37

Ich tippe mal, AMD zieht erst mit der Veröffentlichung des Stream SDK 1.5 nach (dass OpenCL bei ihnen läuft, haben sie gezeigt und zwar auf GPUs und CPUs).

deekey777

2009-05-14, 14:25:52

Ich tippe mal, AMD zieht erst mit der Veröffentlichung des Stream SDK 1.5 nach (dass OpenCL bei ihnen läuft, haben sie gezeigt und zwar auf GPUs und CPUs).
http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=112397&enterthread=y

We are working with strategic partners currently and providing them with a preview release of OpenCL. A public release of OpenCL will be available in the second half of 2009.

;(

deekey777

2009-05-14, 22:40:58

Nvidia submits its OpenCL 1.0 drivers for certification (http://www.tcmagazine.com/comments.php?shownews=26435&catid=3)

Jeder, der jetzt sagt, das wäre der Tod von CUDA, sollte sich schnell die aktuelle c't kaufen und sich für diesen Unsinn bei Nvidia entschuldigen.

Chris Lux

2009-05-14, 22:48:22

=Floi=

2009-05-14, 22:55:42

was soll denn die schleichwerbung für die ct?

deekey777

2009-05-14, 23:11:44

kannst du kurz die punkte zusammenfassen, warum?
In etwa (aus der c't 11/09):

Vorlesungen an Unis durch eigene Mitarbeiter über CUDA-Programmierung
Investitionen von Sachmitteln und Geld, um den Einsatz von CUDA zu forcieren
Stipendien für Studenten, wenn sie CUDA nutzen
Professor Partnership Program als Förderung ausgewählter Unis mit Geld oder Hardware von rund 25.000 US-$
CUDA Center for Excellence: bis zu 500.000 US-$ für ehrgeizige Projekte, wenn Tesla-HW benutzt werden soll
kontinuierliche Zusammenarbeit mit kleineren Firmen, die CUDA einsetzen
Nvidia beliefert Bull, Cray und NEC mit Tesla-Karten

Irgendwo steht, dass für Studenten GPGPU = CUDA ist.
Erst letzte Woche: http://www.hpcwire.com/offthewire/T-Platforms-Supercomputer-Uses-NVIDIA-Technology-44597862.html

Im nachfolgenden Interview sagt Prof. Kun Zhou (http://www.heise.de/ct/inhalt/2009/11/148/):
"Natürlich, diese Limitierung auf Geforce-Chips ist in der Tat ein Problem. Bleibt es dabei, dass CUDA ausschließlich Nvidia-Hardware unterstützt, werden OpenCL, Compute Shader oder langfristig andere Programmiersprachen die Oberhand gewinnen. Dennoch denke ich, dass CUDA in den kommenden Jahren de facto die GPGPU-Standardsprache bleibt - schließlich programmieren tausende Entwickler mit CUDA. [...]"

was soll denn die schleichwerbung für die ct?
Sonst alles klar bei dir?

deekey777

2009-06-23, 12:32:15

Nvidia claims first 'OpenCL 1.0 conformant' drivers (http://techreport.com/discussions.x/17088)
Two months after giving developers a sneak preview of its OpenCL development toolkit, Nvidia claims to have released the "world's first OpenCL 1.0 conformant drivers for Windows XP and Linux."

Es wird nicht sehr lange dauern, bis wir OCL-Treiber für alle sehen.

deekey777

2009-07-24, 00:21:59

Da ist was untergegangen:
ATI Jumps on OpenCL Bandwagon by Releasing OpenCL Drivers. (http://www.xbitlabs.com/news/video/display/20090610074239_ATI_Jumps_on_OpenCL_Bandwagon_by_Releasing_OpenCL_Drivers.html)
(Vom 10. Juni)
First Open CL Drivers from ATI (http://www.hardmac.com/news/2009/06/11/first-open-cl-drivers-from-ati)
"It will be very interesting to check if Open CL will be able to compete on PC and Windows with the proprietary solution made by Microsoft, the successor of DirectX10b."
;D

AMD liefert erste OpenCL-Treiber an Entwickler aus (http://www.maclife.de/index.php?module=Pagesetter&func=viewpub&tid=1&pid=13510)

deekey777

2009-08-04, 11:22:37

Introductory Tutorial to OpenCL (http://developer.amd.com/gpu/ATIStreamSDK/pages/TutorialOpenCL.aspx)
AMD just published its public OpenCL Beta for the CPU, soon to be followed with support for AMD’s latest GPUs.
Und wo ist diese Public Beta? ;(

Gast

2009-08-04, 11:35:39

http://www.abload.de/img/unbenak4di.jpg (http://www.abload.de/image.php?img=unbenak4di.jpg)

deekey777

2009-08-04, 11:39:31

http://www.abload.de/img/unbenak4di.jpg (http://www.abload.de/image.php?img=unbenak4di.jpg)
Und weiter?
http://developer.amd.com/documentation/presentations/Pages/default.aspx

-> GDC2009: ATI Stream™ Physics, Folie 5.

reunion

2009-08-05, 17:16:39

AMD Delivers Industrys First OpenCL Software Development Platform for x86 processors
http://www.tweak.dk/nyheder2.php?id=20998

deekey777

2009-08-05, 19:52:09

Das ist ja die CPU-Version, die ich gestern nicht finden konnte. Ich hab mich schon gewundert, wo die Treiber bleiben. ;(
Aus der Readme:
For test only: Expires on Wed Sep 30 00:00:00 2009
This warning message reminds you that ATI Stream SDK v2.0-beta2 is a beta release and expires September 30, 2009. This is an expected message, and nothing needs to be done in response. A new release of ATI Stream SDK v2.0 is scheduled to be available before the expiration date.

Wann kommt der Schneeleopard?

Gast

2009-08-05, 21:18:09

Wann kommt der Schneeleopard?
September - aber an welchem Tag ist noch nicht bekannt. Könnte also auch Ende September werden.

Godmode

2009-08-05, 22:21:49

Ich bin gespannt wie viel Leistung OpenCL auf die Straße bringt, im Vergleich zu CUDA?

=Floi=

2009-08-05, 22:25:13

wie funktioniert das für den prozessor? gibt es da auch bald einen treiber oder wird da eine dll mitgeliefert?

dust

2009-08-05, 23:04:55

AMD liefert Entwicklungsumgebung für OpenCL
http://www.heise.de/newsticker/AMD-liefert-Entwicklungsumgebung-fuer-OpenCL--/meldung/143083

Demogod

2009-08-05, 23:17:45

Wie isn das eigtl.. nicht jeder Task läuft auf jedem Transistor gleich schnell?! Wird dann der Code jedesmal kurz vorher für jede "Platform" kurz kompiliert, um zu schauen, wo es am schnellsten läuft oder ist OpenCL dann quasi full-JIT?

Man hat ja zb beim DNET-C-RC5-56 (später 64 uswusw afair.. so um 2k 2k1 rum. Nur ein Beispiel) gesehen, dass es mehr als nur eine Handvoll speziell optimierter Cores für verschiedene CPU types usw gab..

Coda

2009-08-05, 23:28:00

Bitte nochmal anders formulieren. Ich verstehe zumindest nicht was du meinst.

Demogod

2009-08-06, 00:02:42

:D
Na ab wann sagt dann der Scheduler (grand central @ apfel zb) ab wann die Performance/Watt/Whatever Ratio (könnte ja auch noch embedded energy profiles geben also zb dass der sched sagt: lieber dort oder dort laufen lassen) wo am besten ist und wo was ausgeführt wird.

Aber halt dieses WLAN Key cracking tool lief/läuft ja auch auf ATI (ATM) am besten...

Zusatz: In dieser new cloud computing era wird es doch zumindest in späteren Spezifikationen darauf hinauslaufen (auf special profiles.. erklärung kommt genau JETZT).., dass zb du irgendwelche Daten am iPhone vorbereitest, und sie dann entweder per VPN oder ähnlichem in das Firmeneigene CPU/GPGPU Netz einschleust, sobald du die WLAN Area des HQ betrittst, oder dass du per iNet login deine zu bearbeitenden Daten zu nem Trusted Computing Service rüberschickst, und der sie dir dann (zu seinen Stromkosten Konditionen zb) für dich durchkalkuliert.

P.S.: Suche immer noch nen Coder für ein >>EINFACHES<< iPhone Prog!! (remember.. one app right and you are out of money probs..)

Coda

2009-08-06, 01:56:28

He? Meinst du ob auf der CPU oder GPU ausgeführt wird oder was? :|

Demogod

2009-08-06, 10:55:05

Ja quasi. Wie ich da als Beispiel das WLAN Key cracking Tool anführte, wird es trotzdem Unterschiede in der Ausführungsgeschwindigkeit geben (Ati<>Nv<>Intel<>AMD CPU<> Cell Karte<>whatever). Und evtl will man ja nur dort Ausführen, wo für das aktuelle Problem am besten ist (es sei denn es geht nur um execution Speed also dass die Aufgabe einfach nur möglichst schnell fertig sein soll, und Stromkosten gänzlich unwichtig sind..)

Coda

2009-08-06, 12:42:00

In einem PC steckt aber normalerweise nicht eine CPU von Intel und AMD und dazu noch alle möglichen GPUs von ATI und NVIDIA. Ich weiß immer noch nicht auf was du hinaus willst.

Aquaschaf

2009-08-06, 12:47:37

Ich glaube klarer formuliert ist die Frage: entscheidet sich eine OpenCL-Runtime dynamisch dafür wo ein Programm ausgeführt wird, oder muss man das vorher festlegen? Bezogen auf Sachen die sowohl auf GPU als auch auf (Multicore-)CPU laufen könnten.

Demogod

2009-08-06, 12:59:25

In einer Cloud kann aber alles stecken.. und ja Aquaschaf artikuliert in etwa das was ich sagen will.. =)

"..oder muss man das vorher festlegen?" Das muss muss aber durch kann ersetzt werden. Dann halt wieder vor dem Hintergrund der energy efficiency (siehe RC-5 cores..)

Ganon

2009-08-06, 13:38:51

Soweit ich das verstanden habe ist die CPU nur ein Fallback bei OpenCL. D.h. wenn du etwas mit OpenCL machst, sollte es darauf ausgelegt sein, auf einer GPU zu laufen.

Wie es sich aber verhält, wenn man z.B. in einem Dual OctoCore eine 9400M drinnen hat, weiß ich jetzt auch nicht :D

Coda

2009-08-06, 14:43:32

Das Programm entscheidet wo es läuft. Was das mit Clouds zu tun hat erschließt sich mir aber dennoch nicht.

deekey777

2009-08-06, 15:13:44

Das Programm entscheidet wo es läuft. ...
Mit BarsWF haben wir zum Beispiel ein Programm, das auf GPU und CPU läuft (bei der Brook+-Version wird leider ein Kern der CPU für die GPU beansprucht, bei der CUDA-Version werden alle Kerne für Berechnungen genutzt).
wie funktioniert das für den prozessor? gibt es da auch bald einen treiber oder wird da eine dll mitgeliefert?
Vermutung: Um Probleme gleich aus dem Weg zu schaffen, werden Anwendungen gleich mit den nötigen DLLs kommen.
Oder so: Wenn keine OpenCL.DLL in System32, dann nutze die mitgelieferte DLL, sonst die im System32-Ordner.
Beispiel: Als die erste Version von SiSoft Sandra 2009 kam, so lieferte sie die CAL-DLLs gleich mit. Als AMD mit dem Cat. 8.12 die CAL-DLLs mit dem Treiber lieferte, hat SiSoft Sandra seitdem die entsprechenden DLLs nicht, sondern greift auf die im System32-Ordner zurück.

Coda

2009-08-06, 15:40:55

Mit BarsWF haben wir zum Beispiel ein Programm, das auf GPU und CPU läuft
Ja und? Dann erzeugt es halt zwei Contexts. Wobei bei BarsWF auf der CPU wohl eher gar kein Stream-Zeug verwendet wird.

Avalox

2009-08-06, 16:29:38

Die paar Versuche einer Audio Implementierung in CUDA scheinen ja doch ziemliche Latenzen, bzw. eine ziemlich unstetige Ausgabe zu erzeugen.
Bin mal gespannt ob man sich an solche Dinge, vielleicht mit umfassenderen Ergebnis, wagen wird, wenn GPGPU nun zum Allgemeingut wird.

Demogod

2009-08-06, 22:56:34

@Coda: heut (bei mir) stehste aber echt aufm Schlauch xD.
Selbst durch OpenCL kann doch Task X auf ner nVidia Karte besser laufen als auf ner Ati Karte oder auf ner Cell Karte. Klar könnte ein Cloud-activated (heavy multithreaded autosplitting (in threads)) Programm auf allen OpenCL aktivierten Clients im GAAANZEN (auch in Übersee falls die zu transferrierenden Daten gering genug sind (wie zb nen Keycracking (((=wenig Overhead & läuft zb bei ner Cpu da geringem L2-Cache Footprint komplett im L2))) ) Network (Cloud) gestartet werden. Wenn nun aber offensichtlich besagter Task X auf nV@OCL besser performt und Company Y grad zufällig kein eigenes Kernkraftwerk zur Seite stehen hat, hat diese also ein Interesse, den Task X dort auszuführen, wo es die beste Performance/watt Ratio ergibt. Und da kommt dann meine Frage wieder: kann man (nichts ist unmöglich) nen quickbench starten und dann jene Nodes aquirieren, welche die beste Performance/Watt Ratio bieten?

deekey777

2009-08-07, 11:07:19

Ja und? Dann erzeugt es halt zwei Contexts. Wobei bei BarsWF auf der CPU wohl eher gar kein Stream-Zeug verwendet wird.
Ich meinte nur, dass eine Anwendung, die die GPU nutzt, nicht gleich dazu führt, dass die CPU nur Däumchen dreht. Wie BarsWF das genau macht, ist eben Nebensache.
Noch weiter geht TMPGEnc: Mit der SpursEngine wird das Video kodiert und ggf. hohchskaliert, die CUDA-fähige GRafikkarte berechnet für das Video weitere Filter.

The important thing to note about OpenCL (http://fireuser.com/blog/the_important_thing_to_note_about_opencl/)
“The important thing to note about OpenCL, is that it is not simply about running on the GPU. OpenCL is about running on heterogeneous systems - ALL the processors in your system. With AMD’s OpenCL implementation, you will be able to take one source code base and re-target it to your CPUs or GPUs - it will run on both - and take advantage of your entire platform.”

Demogod

2009-08-07, 13:47:02

nV Vizepräsident zu OCL vs Compute Shaders (http://www.gamestar.de/hardware/news/grafikkarten/1958038/directx_11.html)

deekey777

2009-08-07, 14:40:08

Demirug

2009-08-07, 14:47:09

Das eigentliche Interview: Khronos' President talks OpenCL, DX Compute Shader, and more (http://www.techreport.com/articles.x/17321)

Ist wirklich interessant, wie er DX CS beschreibt (auf der zweiten Seite).

Bevor man über die Konkurenz lästert sollte man sich vorher vielleicht mal über den aktuellen Stand informieren.

Nighthawk13

2009-08-26, 16:50:52

(experimenteller) C++ Wrapper für OpenCL: http://www.khronos.org/registry/cl/api/1.0/cl.hpp-docs.zip

Schaut vom Überfliegen der doxygen-Doku gut aus.

Ganon

2009-08-27, 18:03:49

btw. Snow Leopard enthält ein CPU-Backend für OpenCL, einen sehr guten für NVidia-Grafikkarten und einen relativ schlechten für ATi.

Hier gibt es schon ein Benchmark:
http://www.mactechnews.de/news/index.html?id=144725

In den Kommentaren posten einige schon Ergebnisse ;)

DR.ZEISSLER

2009-08-27, 22:30:31

wann habe ich vorteile durch openCL ?
bei welcher art anwendungsbereich macht openCL sinn ?

Ganon

2009-08-27, 22:52:25

wann habe ich vorteile durch openCL ?

Wenn es genutzt wird :ugly:

bei welcher art anwendungsbereich macht openCL sinn ?

Alles das wo auch CUDA Sinn macht, also nicht allzu viel. Bei Video de-/encodern scheint es ja stellenweise noch an der Qualität zu kranken. Aber für OpenCL gibt's da ja noch absolut gar nichts, da es ja jetzt quasi erst raus ist.

DR.ZEISSLER

2009-08-27, 22:57:11

also für den popo...schade

dust

2009-08-27, 23:01:12

http://de.wikipedia.org/wiki/OpenCL
http://www.khronos.org/opencl/
OpenCL™ is the first open, royalty-free standard for cross-platform, parallel programming of modern processors found in personal computers, servers and handheld/embedded devices. OpenCL (Open Computing Language) greatly improves speed and responsiveness for a wide spectrum of applications in numerous market categories from gaming and entertainment to scientific and medical software.

also für alle hier brauchbar

deekey777

2009-09-15, 14:25:16

Ein interessanter Artikel bei HPC Wire: Compilers and More: OpenCL Promises and Potential (http://www.hpcwire.com/features/Compilers-and-More-OpenCL-Promises-and-Potential-58625442.html?page=1)
Ich weiß nicht, wie neutral der Autor ist, aber seine Intention ist definitiv bei OpenCL bodenständig zu bleiben und das Wunschdenken zu begraben.

Coda

2009-09-15, 14:38:46

Was für Wunschdenken gibt es denn? ;)

Das wir das in Wald-Und-Wiesen-Apps sehen werden halte ich auch für ausgeschlossen.

Ganon

2009-09-15, 14:48:19

Was für Wunschdenken gibt es denn? ;)

Außerhalb des Nerdkreises wird halt schlicht angenommen, dass OpenCL jetzt irgendwie alles schneller macht. Also z.B. große Tabellen in Tabellenkalkulationen usw. ;)

deekey777

2009-09-15, 14:54:12

Was für Wunschdenken gibt es denn? ;)

Das wir das in Wald-Und-Wiesen-Apps sehen werden halte ich auch für ausgeschlossen.
Es ist bei mir das gleiche Wunschdenken wie bei der Ankündigung des AVIVO-Converters im Dezember 2005, als Grafikkarten Videos kodieren sollten, oder das ganze Jahr 2006 mit HavokFX, ATIs Physics&DPP+CTM, dann CUDA etc. Sprich: OpenCL erweckt(e) das Gefühl, dass ab sofort alles besser wird (und schneller) und zwar IHV-unabhängig. Aber die Realität ist anders: Weder von Nvidia noch von AMD gibt es (für Windows und Linux) einen OpenCL-Treiber (für GPUs), alles ist im Beta-Stadium und nichtöffentlich.
Selbst bei Snow Leopard ist bis auf Quicktime X tote Hose.

Coda

2009-09-15, 15:10:16

Die Sache ist halt, dass GPGPU eigentlich nochmal schlimmer ist als normales Threading und selbst da versagt ja der Großteil der Entwickler.

Ganon

2009-09-15, 15:12:00

QuickTime X hat mit OpenCL nichts zu tun.

Coda

2009-09-15, 15:26:54

Also laut Wikipedia kann QT X "GPU Acceleration". Geht das nicht über OpenCL?

deekey777

2009-09-15, 15:28:57

QuickTime X hat mit OpenCL nichts zu tun.
Werden Videos zB fürs iPhone nicht über Quicktime umgewandelt?

Ganon

2009-09-15, 15:29:23

Also laut Wikipedia kann QT X "GPU Acceleration". Geht das nicht über OpenCL?

Nein, ganz normal über die H.264 Decodiereinheiten der 9400M. Wie hies das noch mal? PureVideoHD oder so? ^^

Werden Videos zB fürs iPhone nicht über Quicktime umgewandelt?

Doch, aber das läuft nicht über OpenCL.

deekey777

2009-09-15, 15:32:17

Nein, ganz normal über die H.264 Decodiereinheiten der 9400M. Wie hies das noch mal? PureVideoHD oder so? ^^
Es heißt Videoprocessor (dedizierte Einheit) und wird über eine spezielle Schnittstelle angesprochen (DXVA oder CUDA, siehe CoreAVC). Wie hat das Apple gelöst?

Ganon

2009-09-15, 15:42:15

Wie hat das Apple gelöst?

Da weder der NVidia-Treiber noch QuickTimeX OpenSource sind, musst du da wohl Apple fragen ;)

Da aber QuickTime X NUR (!) die 9400M unterstützt und NUR (!) PureVideHD der Unterschied zwischen den Karten ist (alle anderen von Apple angeboteten GPUs haben afaik eine ältere Version, oder gar keine davon (ATi/AMD)), kann es einfach nur das sein.

Nasenbaer

2009-09-15, 19:46:38

Es heißt Videoprocessor (dedizierte Einheit) und wird über eine spezielle Schnittstelle angesprochen (DXVA oder CUDA, siehe CoreAVC). Wie hat das Apple gelöst?
Nutzt man bei MacOS X die normalen Linux-Treiber oder gibts da nochmal was ganz anderes? Ansonst gibts ja von NV seit einiger Zeit VDPAU als Schnittstelle zu PureVideo bei den Linux-Treibern.

Coda

2009-09-15, 21:20:30

Nutzt man bei MacOS X die normalen Linux-Treiber oder gibts da nochmal was ganz anderes?
Wieso um alles in der Welt sollten Linux-Treiber für X11 auf Mac OS X laufen? :freak:

Nein, natürlich sind das keine Linux-Treiber.

Nasenbaer

2009-09-15, 22:13:53

Wieso um alles in der Welt sollten Linux-Treiber für X11 auf Mac OS X laufen? :freak:

Nein, natürlich sind das keine Linux-Treiber.
Ich weiß nur, dass der Kernel wohl mittlerweile auf Unix basiert und daher die Vermutung. Wie weit MacOS X dennoch vom Linux-Kernel entfernt ist und was die dort für ein Window-System nutzen weiß ich nicht und daher die Frage. Hab aber mal fix bei Wikipedia nachgeschaut und gelesen, dass da doch schon ein größerer Unterschied besteht. Also einfach vergessen was ich gesagt hab. :D

Gast

2009-09-15, 22:23:43

XNU (der Mac OS Kernel) stammt von NEXtstep und dürfte es schon länger geben als Linux (der Kernel). Natürlich haben sich die Kernel (XNU, Linux) weiterentwickelt.
http://events.ccc.de/congress/2007/Fahrplan/attachments/1053_inside-macosx-kernel.pdf

Ausserdem hat der Linux-Kernel einen entscheidenden Nachteil, auch wenn der Kernel ansonsten richtig gut sein mag: Es gibt keine stabile Treiber API. Die Hardcore-Linuxer bzw. OpenSourcler wollen das so. Bringt aber auch eine reihe von Nachteilen mit sich.

dust

2009-09-19, 05:07:29

http://www.brightsideofnews.com/news/2009/9/17/amd-supports-opencl-bullet3b-are-havok-and-physx-in-trouble.aspx
AMD supports OpenCL Bullet; Are Havok and PhysX in trouble?

Bullet Physics Library is an open source physics library that is now getting translated into OpenCL, thanks to the effort of companies such as AMD [who offered support to developers]. Somehow, we feel that this announcement was the highlight of the launch event for the upcoming Evergreen generation of graphics cards.

In case you wondered, according to Game Developer Magazine world's most popular physics API is nVidia PhysX, with 26.8% market share [if there was any doubt that nVidia PhysX isn't popular, which was defense line from many AMD employees], followed by Intel's Havok and its 22.7% - but Open sourced Bulled Physics Library is third with 10.3%.
We have no doubt that going OpenCL might be the golden ticket for Bullet. After all, Maxon chose Bullet Physics Library for its Cinema 4D Release 11.5 [Cinebench R11 anyone?].

blender verwendet bullet übrigens, ebenso gta4.

http://www.bulletphysics.com/Bullet/phpBB3/viewtopic.php?f=18&t=4067&p=15130&hilit=opencl#p15130
GPU physics kernels preview, in preparation for Bullet 3.x. Right now mainly CPU version, you can enable CUDA version manually. The OpenCL version is available in a separate branch. http://code.google.com/p/bullet/source/browse/#svn/branches/OpenCL See Bullet/Demos/Gpu2/3dDemo

gute neuigkeiten :biggrin:

Nasenbaer

2009-09-19, 09:15:20

Auf Arbeit habe ich zur Zeit mit Bullet zu tun. Ist ganz nett was man damit anstellen kann. :)

Fehlen nur endlich mal offiziellen OpenCL-Treiber und besser noch Entwicklngswerkzeuge - möchte auch mal OpenCL testen. :D

Ganon

2009-09-19, 20:37:41

Avalox

2009-09-19, 21:24:22

Wer Snow Leopard hat:

Ein OpenCL Benchmark, welcher 16 000 Sterne mit Gravitation rumfliegen lässt. Entstanden durch Unterstützung von Apple, ATi und NVidia, soweit ich das jetzt mitbekommen habe.

Das sieht ja so aus, wie das nVidia OpenCL Programm der Sigraph vom letzten Jahr.

deekey777

2009-09-21, 13:49:15

Wer Snow Leopard hat:
http://www.macupdate.com/info.php/id/32266/opencl-benchmark

Ein OpenCL Benchmark, welcher 16 000 Sterne mit Gravitation rumfliegen lässt. Entstanden durch Unterstützung von Apple, ATi und NVidia, soweit ich das jetzt mitbekommen habe.

Hier ein Video:
http://www.youtube.com/watch?v=bUJPdiUHnqs
Ganze 16.000? Hier gibt's bis zu 43.000: http://galaxy.u-aizu.ac.jp/trac/note/wiki/Astronomical_Many_Body_Simulations_On_RV770 X-D

AMD Advances its Commitment to OpenCL™ for GPU With Review by Standards Body (http://www.amd.com/us/press-releases/Pages/commitment-to-opencl-2009sep21.aspx)
AMD (NYSE: AMD) announced submission of conformance logs for its OpenCL graphics processing unit (GPU) implementation to the Khronos Working Group and awaits certification. The GPU submission puts AMD one step closer to being the only semiconductor provider to offer both GPU and central processing unit (CPU) development environments for OpenCL. AMD’s ATI Stream technology leverages OpenCL to help developers more easily divide software workloads between the CPU and GPU for more efficient execution

Ganon

2009-09-22, 23:18:18

deekey777

2009-09-22, 23:28:20

Also herstellerspezifische Optimierungen sind erlaubt, und AMD empfiehlt vektorisierten Code zu implementieren (wegen XYZWT).

Ganon

2009-09-23, 08:26:14

Also herstellerspezifische Optimierungen sind erlaubt, und AMD empfiehlt vektorisierten Code zu implementieren (wegen XYZWT).

Es geht mir weniger um das was erlaubt ist, sondern das was nötig ist. ^^ Weil da ja 3 komplett verschiedene Implementierungen mitgeliefert werden.

Hmmm... heute Abend mal testen, wenn ich die Datei einfach mal umbenenne, ob da trotzdem noch was passiert :D

S940

2009-09-23, 09:49:09

Was ich mich gerade nur frage, in dem Package von dem Galaxies OpenCL für SnowLeopard gibt es eine .cl für die CPU und eine .cl für GPU. In der CPU-Variante ist noch mal unterteilt in Vectorized und NonVectorized.

Hat man das jetzt nur aus Performance-Gründen gemacht? Weil ich hatte OpenCL so verstanden, dass er einen Code auf die jeweilige Hardware kompiliert. Somit wäre ja >eigentlich< nur ein Code nötig.

Ist das so, oder habe ich da was falsch verstanden?
Kennste das schon:

http://www.abload.de/img/opencl1t7gg.gif

? Prinzipiell sollte CPU/GPU code dann in einer Datei mit switch / case möglich sein. Aber da war man in Deinem Fall dann wohl eher zu faul dazu ^^

ciao

Alex

deekey777

2009-09-28, 18:51:22

Nvidias OpenCL-Treiber sind draußen: http://developer.nvidia.com/object/opencl-download.html
(Samt SDK usw)

dust

2009-10-09, 21:14:52

http://www.phoronix.com/scan.php?page=news_item&px=NzU4Ng
Benchmarking OpenCL On Linux With Phoronix Test Suite

deekey777

2009-10-13, 20:55:55

AMD Stream SDK 2.0 beta 4 mit GPU-Support: http://developer.amd.com/GPU/ATISTREAMSDKBETAPROGRAM/Pages/default.aspx
(Auch ein entsprechender Treiber ist dabei)

_DrillSarge]I[

2009-10-13, 20:56:33

+ simples tutorial
http://developer.amd.com/gpu/ATIStreamSDK/pages/TutorialOpenCL.aspx
€:^^ahhh ein neuer treiber, lade gerade mit gigantischen 25kb/s :D

deekey777

2009-10-13, 21:01:42

I[;7595441']...
€:^^ahhh ein neuer treiber, lade gerade mit gigantischen 25kb/s :D
Das ist leider normal.

deekey777

2009-10-15, 20:53:00

Lassen sich heute irgendwie OpenCL-Anwendungen schreiben, die auf Radeons und Geforces laufen?
Denn die den SDKs der beiden beigefügten OpenCL.DLL können nur jeweils eine Geforce oder eine Radeon/CPU ansprechen.

Demirug

2009-10-15, 21:08:27

In der Regel wird mal wohl davon ausgehen müssen das wenn man die OpenCL.DLL zugreift man die für die verbaute Grafikkarte hat. Das ist natürlich problemtisch für Leute die häufig wechseln oder noch schlimmer beides gleichzeitig im System haben. Solange das OS nicht den gleichen Weg wie bei OpenGL unterstützt wird es ein Trauerspiel bleiben. Die Spec ignoriert dieses Problem als Implementierungsdetail.

deekey777

2009-10-15, 23:52:11

Also einfaches Copy&Paste der DLL aus dem Stream SDK in das Nvidia SDK bringt nichts. Entweder wollen die Test erst gar nicht starten oder sie hängen sich auf (aber sie starten).
Solange das OS nicht den gleichen Weg wie bei OpenGL unterstützt wird es ein Trauerspiel bleiben.
Irgendwo wurde das angesprochen, es hieß, man sei sich uneinig oder so.

Bei OpenGL liefert der Treiber die nötigen DLLs, oder? Zumindest das Catalyst-Treiber liefert die nötigen CAL-DLLs mit (sie werden gar jeden Monat aktualisiert), die dann im System-Ordner abgelegt sind und jede Anwendung gleich darauf zurückgreift.

Demirug

2009-10-16, 00:01:48

Bei OpenGL liefert der Treiber die nötigen DLLs, oder? Zumindest das Catalyst-Treiber liefert die nötigen CAL-DLLs mit (sie werden gar jeden Monat aktualisiert), die dann im System-Ordner abgelegt sind und jede Anwendung gleich darauf zurückgreift.

Bei OpenGL gehört die eigentliche OpenGL.DLL zum System selbst. Nachdem man dann mit den WGL Funktionen den Grafikadapter ausgewählt hat (vereinfacht ausgedrückt) werden die Aufrufe an die spezifische OpenGL dll für diese Karte weitergeleitet. Auf diese Weise können mehrere OpenGL.dlls mehrere Hersteller koexistieren. Die DLLs haben natürlich andere Namen aber dieser wird bei der Installation dem System mitgeteilt.

Nasenbaer

2009-10-16, 19:51:42

Also einfaches Copy&Paste der DLL aus dem Stream SDK in das Nvidia SDK bringt nichts. Entweder wollen die Test erst gar nicht starten oder sie hängen sich auf (aber sie starten).
Hast denn die Beispiele aus dem nVidia SDK neu kompiliert oder haben einfach die fertigen EXE-Dateien gleich versagt?
AFAIK wird doch zumindestens bei nVidia OpenCL doch irgendwie über CUDA ausgeführt. Ich weiß nun nich der erst in CUDA-Code und dann in ptx oder direkt nach ptx übersetzt wird. Aber vielleicht hängt das Problem auch irgendwie damit zusammen.

Irgendwo im Netzt gabs mal nVidia Folien, die gezeigt haben wie OpenCL mit CUDA zusammenhängt.

deekey777

2009-10-18, 12:17:29

Nasenbaer

2009-10-18, 14:50:36

Ich habe wirklich nur die entsprechenden DLLs aus deM Stream-SDK-Ordner in den Ordner mit dem Nvidia-SDK verschoben.
Die OpenCL-DLL generiert den PTX-Code bei Nvidia, bei ATi eigentlich den IL-Code. Der generierte Code wird dann von den CAL-DLLs bzw. CUDA-DLLs in den entsprechenden Maschinencode übersetzt. Oder?
Keine Ahnung aber gut möglich.

Im FAQ vom Stream SDK (PDF im doc Ordner) steht jedenfalls drin, dass man GPUs anderer Hersteller nicht plant zu unterstützen aber man können den Sourcecode einfach erneut kompilieren und dann sollte es laufen, heißt es darin.

Nighthawk13

2009-10-18, 15:16:43

Ein OpenCL-ICD ist angestrebt, dauert aber noch:

http://www.anandtech.com/weblog/showpost.aspx?i=648:
[...]The solution to this problem is that OpenCL needs an Installable Client Driver (ICD), just like OpenGL does. With an ICD developers can link against that, and it will handle the duties of passing things off to vendor-specific drivers. However an ICD isn’t ready yet, and in fact we don’t know when it will be ready. NVIDIA - who chairs the OpenCL working group - tells us that the WG is “driving to get an ICD implementation released as quickly as possible”, but with no timetable attached to that. The effort right now appears to be on getting more OpenCL 1.0 implementations certified (NV is certified, AMD is in progress), with an ICD to follow.

Coda

2009-10-18, 18:48:12

Also das wundert mich nun wirklich. Selbst bei OpenAL haben sie das von Anfang an gebacken bekommen. Als ob das so ein Wunderwerk wäre :|

Im FAQ vom Stream SDK (PDF im doc Ordner) steht jedenfalls drin, dass man GPUs anderer Hersteller nicht plant zu unterstützen aber man können den Sourcecode einfach erneut kompilieren und dann sollte es laufen, heißt es darin.
Soviel zum Thema "offene Standards". Absolute Kotze.

Da hat man eine einheitliche API, und dann bindet man sie zur Compile-Time doch an seine Karten. Ich bin echt fassungslos.

Angesichts dessen fallen die Chancen dass OpenCL adaptiert wird ggü. DirectCompute erheblich. Was denken die Leute sich eigentlich?

Ganon

2009-10-18, 18:54:15

Wird bei OpenCL der Sourcecode nicht sowieso immer compiliert auf die Hardware die im RunTime-System steckt?

Coda

2009-10-18, 18:55:45

Es gibt keine Windows-ICDs und die DLLs der IHVs sind offenbar auch inkompatibel - wie auch immer sie das geschafft haben.

Apple wird wohl in Snow Leopard allerdings schon einen ICD-Wrapper mitliefern.

Das Problem ist, dass Microsoft sich wohl kaum dazu berufen fühlt dafür zu sorgen, dass es ICDs gibt. Das schlimme daran ist nun, dass wieder genug Kindergarten vorherrscht, dass sich die IHVs mit solchen Lächerlichkeiten bekriegen und selber dazu auch nicht in der Lage sind.

deekey777

2009-10-30, 01:06:31

http://forum.beyond3d.com/showpost.php?p=1352778&postcount=313
The OpenCL implementation in this beta driver uses the same link rules as ATI's implementation, so now it's possible to have one executable to work on both OpenCL implementation. Unfortunately, NVIDIA hasn't updated its publicly available GPU Computing SDK yet (which should be available soon, I think), so if you are stuck with the old OpenCL SDK, the compiled program won't work. However, as the link rule is the same as ATI's implementation, you can actually use ATI's Stream SDK beta 4 to compile/link your program and it will run on this driver. :)

Another thing is that the OpenCL implmentation in this driver supports double precision FP on GT200 (although there's a bug in the device query information: the best vector width for double is 0, which is of course wrong). I don't know whether it's standard conformant or not (regarding to its behavior), but in my simple test program the results are completely the same as CPU.
Hm, ist das interessant.
(gemeint ist der aktuelle Beta-Treiber)

deekey777

2009-10-31, 19:52:10

OpenCL Development Kit for Linux on Power (http://www.alphaworks.ibm.com/tech/opencl)

OpenCL-Treiber für PowerXCell 8i (http://en.wikipedia.org/wiki/Cell_%28microprocessor%29#PowerXCell_8i).

Ich habe eine Frage zu Local-Memory: Entspricht es eher dem LDS des DX11 CS 5(jeder Thread bzw. Work-Item kann überall schreiben und von überall lesen) oder CS 4.x (privat schreiben, aber von überall lesen)?

deekey777

2009-11-05, 13:56:21

Port of Apple demos to Windows.. (http://oscarbg.blogspot.com/2009/11/port-of-apple-demos-to-windows.html)

Einige von diesen Demos laufen tatsächlich mit meiner HD4850.

Aquaschaf

2009-11-18, 08:54:15

Ich habe eine Frage zu Local-Memory: Entspricht es eher dem LDS des DX11 CS 5(jeder Thread bzw. Work-Item kann überall schreiben und von überall lesen) oder CS 4.x (privat schreiben, aber von überall lesen)?

Ersteres. Ergo wird für RV7xx local memory auf den globalen Speicher der Karte abgebildet, und der lokale Speicher der Prozessoren liegt brach. Das macht nun leider OpenCL mit RV7xx ziemlich unattraktiv.

deekey777

2009-11-18, 11:21:40

Ersteres. Ergo wird für RV7xx local memory auf den globalen Speicher der Karte abgebildet, und der lokale Speicher der Prozessoren liegt brach. Das macht nun leider OpenCL mit RV7xx ziemlich unattraktiv.
Du hast gleich meine zweite Frage beantwortet, die ich dann stellen wollte.

Wie kurzsichtig ist das denn?
Für den G80 und aufwärts gilt das aber nicht, oder? Das ist wohl auch der Grund, warum DirectCompute 4.x nur "Überalllesen" beim LDS/Shared Memory beherrscht.

Aquaschaf

2009-11-18, 12:03:06

Du hast gleich meine zweite Frage beantwortet, die ich dann stellen wollte.

Wie kurzsichtig ist das denn?

G80 hat bereits local memory in der Form wie es OpenCL 1.0 fordert (bzw. entspricht OpenCL 1.0 ohne Extensions soweit ich das sehe praktisch genau den Fähigkeiten von G80). RV7xx ist die einzige Architektur auf der OpenCL ausgeführt werden kann die diese eingeschränkte Form von lokalem Prozessorspeicher hat. Was ein Grund dafür sein dürfte diese Eigenheit nicht im Programmiermodell zu berücksichtigen.

LovesuckZ

2009-11-18, 12:20:18

Wie kurzsichtig ist das denn?
Für den G80 und aufwärts gilt das aber nicht, oder? Das ist wohl auch der Grund, warum DirectCompute 4.x nur "Überalllesen" beim LDS/Shared Memory beherrscht.

Entspricht CS 4.x dann nicht von den Funktionalitäten OpenCL 1.0?

Aquaschaf

2009-11-18, 12:38:52

Entspricht CS 4.x dann nicht von den Funktionalitäten OpenCL 1.0?

Im Endeffekt: mit RV7xx ist es besser CS 4.x zu benutzen als OpenCL, wenn man kann. Für die Chips von Nvidia die nur CS 4.0 unterstützen ist OpenCL 1.0 vorzuziehen, wegen dem flexibleren Speichermodell. Mit CS 5 hat sich diese Problematik erledigt.

Es ist aber auch möglich dass - für die Dinge die man praktisch mit CS 4.x in Spielen machen kann/möchte - das restriktive Speichermodell kein Problem darstellt. Und in der Funktionalität - also in der Ausdrucksstärke - ist das alles gleich. Es geht "nur" um Performance bei den Unterschieden.

Coda

2009-11-18, 14:26:22

Ich dachte immer RV7xx sei bei der local storage auf dem G8x-Niveau angekommen. Hab ich wohl falsch im Hinterkopf gehabt.

deekey777

2009-11-18, 14:44:41

Ich dachte immer RV7xx sei bei der local storage auf dem G8x-Niveau angekommen. Hab ich wohl falsch im Hinterkopf gehabt.
Ich hatte das anders im Kopf: Beim G80 wird jedem Thread eines Threadblocks sein eigener Speicher im Shared Memory zugewiesen, in den nur er (der Thread) schreiben kann. Und genau dem entspricht das LDS des RV770.
In der Compute-Shader-Präsentation wird das beim CS 4.x als Einschränkung erwähnt.

Und jetzt kommt der Schlag: Das Shared Memory des G80 ist da weiter als das LDS des RV770. Nach dem Global Data Share, das brach liegt, eine weitere fragwürdige Designentscheidung.

Coda

2009-11-18, 15:04:11

Ja, ich erinnere mich.

Aquaschaf

2009-11-18, 15:05:29

Und jetzt kommt der Schlag: Das Shared Memory des G80 ist da weiter als das LDS des RV770. Nach dem Global Data Share, das brach liegt, eine weitere fragwürdige Designentscheidung.

Die Entscheidung liegt ja schon ein ganzes Stück in der Vergangenheit. Ich bin mir gerade nicht sicher wie "schlimm" diese Einschränkung überhaupt ist. Reduktion, Präfixsumme und Sortiernetzwerke lassen sich wenn ich mich gerade nicht vertue damit z.B. immer noch realisieren. Auf G80 kann man zwar frei schreiben, aber es gibt keine atomaren Instruktionen auf diesem Speicher (die hat dann G200). D.h. muss man sich dort trotzdem für viele Sachen überlappungsfreie Schreibmuster ausdenken.

Nützt aber natürlich nichts, wenn man unter OpenCL darauf gar keinen Zugriff hat. In ihrem Forum zu OpenCL haben Leute von AMD auch durchblicken lassen dass sie sich in erster Linie darauf konzentrieren werden ihre Implementierung für Evergreen zu optimieren.

Coda

2009-11-18, 15:13:43

Atomare Instructions hat auch schon G92 iirc.

Aquaschaf

2009-11-18, 15:19:07

Atomare Instructions hat auch schon G92 iirc.

Ja, aber nur auf globalem Speicher ;)

Gast

2009-11-18, 18:36:34

Taugt OpenCL für Videobeschleunigung bzw. kann man darüber auch PureVideo/UVD ansprechen?
Der Weg über DXVA ist sicherlich deutlich besser?!

Coda

2009-11-18, 18:45:12

kann man darüber auch PureVideo/UVD ansprechen?
Nein.

HarryHirsch

2009-11-25, 20:57:33

wie schauts bei opencl eigentlich mit mgpu aus?
muss ich da wie jetzt bei cuda/brook (folding@home) zwei clients laufen lassen oder gibt es da eine sli/cf unterstützung?

Nighthawk13

2009-12-07, 18:57:48

wie schauts bei opencl eigentlich mit mgpu aus?
muss ich da wie jetzt bei cuda/brook (folding@home) zwei clients laufen lassen oder gibt es da eine sli/cf unterstützung?

Mit Cuda und OpenCL kann man definitiv mehrere GPUs aus einer exe ansprechen, allerdings muss das explizit programmiert werden. Die Programmierer von Folding@home haben das wohl nicht gemacht.

- Bei Cuda ist jeder Context Thread-Local und man braucht pro GPU ein Context. D.h. man muss entweder für jede GPU einen Thread verwenden(Programmieraufwand) oder in einem Thread die Contexte durchwechseln(Performance?)
- Bei OpenCL kann man für jede GPU ein Context-Objekt erzeugen und Kommandos in die Contexte reinstreamen, d.h. es wird dem Prgrammierer die Threadverwaltung abgenommen.
-Brook k.A.

Dass der Treiber mehrere GPUs zu einer virtuellen GPU zusammenfasst und sich das Programm um nichts zu kümmern braucht(wie bei SLI/CF) wird es bei GPGPU wohl nicht geben.
Hoffentlich, wenn man sich die Problemchen mit SLI/CF mal ansieht :wink:

deekey777

2009-12-21, 21:23:22

FYI - The ATI Stream SDK 2.0 is now out of Beta and into a production release:

http://developer.amd.com/stream

What’s New in v2.0 First production release of ATI Stream SDK with OpenCL™ 1.0 support.
New: Support for OpenCL™ ICD (Installable Client Driver).
New: Support for atomic functions for 32-bit integers.
New: Microsoft® Visual Studio® 2008-integrated ATI Stream Profiler performance analysis tool.
Preview: Support for OpenCL™ / OpenGL® interoperability.
Preview: Support for OpenCL™ / Microsoft® DirectX® 10 interoperability.
Preview: Support for double-precision floating point basic arithmetic in OpenCL™ C kernels.
Updated OpenCL™ runtime to conditionally load ATI CAL runtime libraries to allow execution on compatible CPUs without ATI Catalyst™ installed.
Updated OpenCL™ runtime to allow simultaneous use of OpenCL™ and ATI CAL APIs in a single user application.
Updated cl.hpp from the Khronos OpenCL working group release.
Various OpenCL™ compiler and runtime fixes and enhancements (see developer release notes for more details).

Und wie es zu erwarten war, funktionieren die meisten OpenCL-Spielereien nicht. ;(

Coda

2009-12-21, 21:29:20

Ui, der Download-Server ist ja endlich schnell X-D

reunion

2009-12-21, 21:57:21

Und wie es zu erwarten war, funktionieren die meisten OpenCL-Spielereien nicht. ;(

Für alles außer den Dx11-GPUs gibt es auch weiterhin nur Beta-Support.

deekey777

2009-12-21, 22:24:28

Für alles außer den Dx11-GPUs gibt es auch weiterhin nur Beta-Support.
Du hast mich falsch verstanden: Bis auf den DC-Benchmark so wie einer Mandelbrot-Demo (MPMandelbrot) funktioniert nichts so richtig. pcchens Mandelbrot musste auch gefixt werden, damit es wieder läuft.

Demirug

2009-12-21, 22:35:31

Du hast mich falsch verstanden: Bis auf den DC-Benchmark so wie einer Mandelbrot-Demo (MPMandelbrot) funktioniert nichts so richtig. pcchens Mandelbrot musste auch gefixt werden, damit es wieder läuft.

Es war schon bei OpenGL eine dämliche Idee die Shader als Quellcode zu übergeben. Entsprechend war es abzusehen das bei OpenCL der gleichen Mist wieder passiert. Ich hoffe sie lernen es endlich mal und führen für diesen Zweck einen Bytecode für einen virtuellen Prozessor ein.

Nasenbaer

2009-12-22, 13:28:21

Es war schon bei OpenGL eine dämliche Idee die Shader als Quellcode zu übergeben. Entsprechend war es abzusehen das bei OpenCL der gleichen Mist wieder passiert. Ich hoffe sie lernen es endlich mal und führen für diesen Zweck einen Bytecode für einen virtuellen Prozessor ein.
Ich find die Idee jedenfalls wesentlich besser als bei CUDA gelöst. CUDA mit ner IDE außer VS2008 zum Laufen zu bringen, dass man nur noch "Build" klicken muss, ist echt ein Krampf. Wenn man sein Makefile nicht selbst schreiben will, ist man ganz schön aufgeschmissen find ich.

@deekey777
Und welche Spielereien funktionieren denn nicht? Arbeiten einige Funktionen nicht Standardkonform oder was meinst du damit?

Gast

2009-12-22, 13:49:46

Ich vermute jetzt 'mal es geht um das hier: KB71 - Updating your OpenCL™ code to work with the OpenCL™ ICD (http://developer.amd.com/support/KnowledgeBase/Lists/KnowledgeBase/DispForm.aspx?ID=71).

deekey777

2009-12-22, 16:41:55

...

@deekey777
Und welche Spielereien funktionieren denn nicht? Arbeiten einige Funktionen nicht Standardkonform oder was meinst du damit?
Es geht um mehrere OpenCL-Demos, die mit dem Stream SDK 2.0 nicht funktionieren. Nicht mehr. :)

dust

2010-01-26, 19:42:39

http://developer.amd.com/documentation/videos/OpenCLTechnicalOverviewVideoSeries/Pages/default.aspx
ATI Stream OpenCL™ Technical Overview Video Series

Abstract

The ATI Stream OpenCL™ Technical Overview Video Series provides ATI Stream developers an overview of the OpenCL™ application programming interface (API) and OpenCL™ C programming language.

Justin Hensley, Ph.D.
Senior Member of Technical Staff, Office of the CTO - Advanced Technology Initiatives

» Video 1: What is OpenCL™? (7:44)
» Video 2: What is OpenCL™? (continued) (6:37)
» Video 3: Resource Setup (11:06)
» Video 4: Kernel Execution (13:00)
» Video 5: Programming with OpenCL™ C (17:59)

crux2005

2010-01-30, 22:16:01

Könnte mir jemand Kompetenter erklären wieso nVidia will, das man den Code auf warp size optimalisiert? Auch beim GT200, obwohl jeder cluster nur 24 SPs hat. Oder mit was hängt es zusammen?

Danke

deekey777

2010-01-30, 23:36:00

Könnte mir jemand Kompetenter erklären wieso nVidia will, das man den Code auf warp size optimalisiert? Auch beim GT200, obwohl jeder cluster nur 24 SPs hat. Oder mit was hängt es zusammen?

Danke
Jeder Cluster hat 3x8 SM. Ein Warp mit 32 Threads wird dann in vier Takten auf jedem SM ausgeführt.
Näheres hier: http://www.realworldtech.com/page.cfm?ArticleID=RWT090808195242

Coda

2010-01-30, 23:41:33

Jupp. Und Fermi hat 2x16, wobei ein Warp dort in zwei statt vier Cycles pro Pipeline-Stufe läuft.

deekey777

2010-04-20, 19:20:18

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

There is no plan on supporting images on the 4XXX series of cards for OpenCL.
Wie schlimm ist das eigentlich? (Image-Support gibt es bei ATi aktuell gar nicht.)

Gipsel

2010-04-21, 02:27:54

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

Wie schlimm ist das eigentlich? (Image-Support gibt es bei ATi aktuell gar nicht.)
Ziemlich schlimm da nur mit Image-Support (Lesen/Schreiben von Werten in Texturen) die HD4000er an ihre normale Speicherbandbreite herankommen und die Texturcaches genutzt werden.

Die Teiber bzw. ATIs OpenCL-SDK unterstützen übrigens sozusagen inoffiziell schon ein paar mehr Features (http://forums.amd.com/devforum/messageview.cfm?catid=390&threadid=128237&enterthread=y). Der Imagesupport ist übrigens auch dabei.

deekey777

2010-04-21, 13:14:40

Also eine richtig uncoole Aktion von AMD?

So, wie er das ausdrückt, wird es auch keinen inoffiziellen Support geben.

Aquaschaf

2010-04-21, 13:23:55

Von Seiten AMD/ATI hat man schon öfters lesen können dass OpenCL auf HD4xxx eine eher geringe Priorität hat. Da der "shared memory" der Prozessoren dort prinzipiell nicht verwendet werden kann ist OpenCL für die meisten Anwendungen auf HD4xxx aber sowieso uninteressant, egal wie vollständig die Implementierung sonst ist.

Gast

2010-04-21, 23:08:33

Ich find die Idee jedenfalls wesentlich besser als bei CUDA gelöst. CUDA mit ner IDE außer VS2008 zum Laufen zu bringen, dass man nur noch "Build" klicken muss, ist echt ein Krampf. Wenn man sein Makefile nicht selbst schreiben will, ist man ganz schön aufgeschmissen find ich.

Ach was.
In die CMakeLists.txt ein find_package(CUDA REQUIRED COMPONENTS sdk) und die Geschichte läuft...

Shader per Quellcode übergeben ist wirklich nicht das gelbe vom Ei. :(

Also eine richtig uncoole Aktion von AMD?

So, wie er das ausdrückt, wird es auch keinen inoffiziellen Support geben.

Ohne Image Support kann man im Prinzip GPGPU komplett vergessen, also ja, eine "richtig uncoole" Aktion. Da hätten sie mal Hardware mit entsprechend Rohleistung und dann scheiterts an sowas. Der R&D Abteilung dort gehört mal ordentlich die Löffel langgezogen...

Nasenbaer

2010-04-21, 23:20:51

Ach was.
In die CMakeLists.txt ein find_package(CUDA REQUIRED COMPONENTS sdk) und die Geschichte läuft...

Shader per Quellcode übergeben ist wirklich nicht das gelbe vom Ei. :(
Naja seitdem ich DirectX für mich entdeckt habe werde ich wohl eh ComputeShader nutzen, denn MS' Paket ist in großen Teilen ziemlich gut durchdacht wie ich finde.

Aquaschaf

2010-04-21, 23:27:57

Ohne Image Support kann man im Prinzip GPGPU komplett vergessen, also ja, eine "richtig uncoole" Aktion. Da hätten sie mal Hardware mit entsprechend Rohleistung und dann scheiterts an sowas. Der R&D Abteilung dort gehört mal ordentlich die Löffel langgezogen...

Wie gesagt: bei HD4xxx fehlt sowieso prinzipiell der Zugriff auf den schnellen lokalen Speicher der SIMD-Prozessoren, da der den Anforderungen von OpenCL nicht genügt. Und ohne den kann man viele Sachen sowieso entweder vergessen, oder muss sie für HD4xxx-Karten sehr anders implementieren als für alles andere.

deekey777

2010-04-28, 18:58:23

GPCBenchmark - A OpenCL General Purpose Computing benchmark (http://www.hpctech.com/down/opencl/index_en.html)
GPCBencMarkOCL is a General Purpose Computing benchmark that evaluates the performance of OpenCL enabled devices with a collection of several algorithms and applications. The first generation of OpenCL and DirectCompute benchmarks have very limited functions and test items, which could not give a all-around performance evaluation. In fact, the performance of a OpenCL enabled device is affected by many factors. besides the number and frequency of computing units, the architecture, memory bandwidth, on-chip cache and memory, synchronize penalty also have impact. GPC bencmark could evaluate these factors in detail, and gives an all-around report.

deekey777

2010-04-30, 12:15:28

Wie gesagt: bei HD4xxx fehlt sowieso prinzipiell der Zugriff auf den schnellen lokalen Speicher der SIMD-Prozessoren, da der den Anforderungen von OpenCL nicht genügt. Und ohne den kann man viele Sachen sowieso entweder vergessen, oder muss sie für HD4xxx-Karten sehr anders implementieren als für alles andere.
Irgendjemand meinte, dass AMD die Nutzung des LDS der HD4000 irgendwie ermöglichen sollte, was schon ein Fortschritt wäre.

Bzgl. des Test von oben: Meine HD4800 kackt bei den Memory-Tests richtig ab. Auch sieht man recht deutlich, was noch im Stream SDK fehlt.

Gipsel

2010-04-30, 20:04:59

Irgendjemand meinte, dass AMD die Nutzung des LDS der HD4000 irgendwie ermöglichen sollte, was schon ein Fortschritt wäre.
Ich war der Meinung, daß man das machen könnte. Das Problem ist, daß die HD4000er nur bestimmte Zugriffsmethoden auf den LDS erlauben. Allerdings sind das die, die auch bei Nvidia und den HD5000er am schnellsten funktionieren und deswegen auch dort zu empfehlen sind (weil keine bank conflicts auftreten). Diese GPUs handhaben allerdings bank conflicts beim Schreiben (Lesen ist kein Problem) in Hardware (was es langsamer macht, aber es funktioniert), die HD4000er können das nicht.
Allerdings sollten viele Algorithmen "dort draußen" auch mit dem HD4000er LDS kompatibel sein, so daß der Compiler daß erkennen könnte und dann auch dort den LDS benutzen könnte. Den dazu nötigen Aufwand beim OpenCL-Compiler sieht ATI offensichtlich woanders besser investiert.

deekey777

2010-05-03, 22:42:05

Du bist 100pro nicht der einzige, der den LDS-Support wünscht. Aber: Das neue SDK ist draußen und es gibt keinen Image-Support für die HD4000-Serie.

deekey777

2010-08-12, 14:40:07

http://developer.amd.com/GPU/ATISTREAMSDK/Pages/default.aspx
Das neue SDK ist draußen. Jetzt mit SSE2-Support. :uup:
Im Ernst: http://developer.amd.com/gpu/ATIStreamSDK/assets/ATI_Stream_SDK_Release_Notes_Developer.pdf
Sind interessante Neuerungen dabei. Das finde ich aber ziemlich interessant:
Fixed various issues with LDS on RV770 GPUs.
Hm?

http://developer.amd.com/support/KnowledgeBase/Lists/KnowledgeBase/DispForm.aspx?ID=123
KB123 - Preview Feature: ATI Stream SDK v2.2 Support For Accessing Additional Physical Memory On The GPU From OpenCL™ Applications
Wow!

Nasenbaer

2010-08-12, 14:49:27

Also ich finde den hier viel interessanter:

Preview Feature: Support for printf() in OpenCL™ C kernels.

Endlich mal einigermaßen gescheit debuggen ohne Debug-Buffer auszulesen.

Gipsel

2010-08-12, 16:32:36

Sind interessante Neuerungen dabei. Das finde ich aber ziemlich interessant:
Fixed various issues with LDS on RV770 GPUs.
Hm?
Das betrifft den allgemeinen Shadercompiler, nicht den OpenCL-Compiler. Der unterstützt natürlich auch weiterhin nicht den RV770 LDS.

Gast

2010-09-13, 23:24:38

Parallelization of the x264 encoder using OpenCL
http://li5.ziti.uni-heidelberg.de/x264gpu/

deekey777

2010-10-27, 20:45:54

ArcSoft Collaborates with AMD on OpenCL Technology with AMD Radeon HD 6800 Series Graphics and Debuts TotalMedia Theatre 5 (http://www.arcsoft.com/en-us/press_detail.asp?prID=553)
ArcSoft, Inc., the world-leading multimedia software provider, announced today its collaboration with AMD (NYSE: AMD) on OpenCL™ technology with AMD Radeon™ HD 6800 series graphics and the pre-release of its best-selling multimedia player application, TotalMedia Theatre 5 this holiday season.
Interessant, wirklich interessant.

deekey777

2010-11-16, 18:43:51

Jetzt auch Intel mit OpenCL-SDK:
http://software.intel.com/en-us/articles/intel-opencl-sdk/
(Intel liegt so gar im Plan X-D)

Gipsel

2010-11-16, 18:55:26

Jetzt auch Intel mit OpenCL-SDK:
http://software.intel.com/en-us/articles/intel-opencl-sdk/
Das erfordert SSE4.1. Die AMD-Version kommt mit SSE2/3 aus.

Trap

2010-11-16, 19:07:30

Das erfordert SSE4.1. Die AMD-Version kommt mit SSE2/3 aus.
Eine AMD-Software die SSE4.1 voraussetzt wäre auch sehr schwer nachzuvollziehen :D

deekey777

2010-11-16, 19:09:03

Das erfordert SSE4.1. Die AMD-Version kommt mit SSE2/3 aus.
Was hat Intel davon? Noch ein Kartelverfahren? Ein PR-Desaster?
Sie schließen damit nicht nur ihre älteren Produkte aus, sondern auch die der Konkurrenz.

Coda

2010-11-16, 19:45:29

SSE 4.1 hat Dot Product Instructions. Das macht die Sache für den Anfang wesentlich einfacher.

Falls das aber so bleiben sollte bin ich darüber auch verärgert.

Nighthawk13

2010-11-16, 19:56:50

Hoffe mal, das wird nur in der Alpha so sein.

Gerade bei dynamisch generiertem Code kann man doch einfach eine SSE2-Minimalversion anbieten. Muss ja nicht gleich hochoptimiert sein in der ersten Fassung.
@Coda: Hatte mal mit dem DPPS Befehl rumgespielt und war eher enttäuscht von der Performance.

Gipsel

2010-11-16, 20:07:06

@Coda: Hatte mal mit dem DPPS Befehl rumgespielt und war eher enttäuscht von der Performance.
Ich denke mal, das wird microcoded (und aus normalen adds/muls zusammengesetzt) sein. Da spart man vermutlich also nur I$-/Decoding-Bandbreite und gewinnt nichts bei der Latenz/Durchsatz (bin zu faul mal nachzuschauen), oder?

Gipsel

2010-11-16, 20:11:43

Eine AMD-Software die SSE4.1 voraussetzt wäre auch sehr schwer nachzuvollziehen :D
Die Sache ist, daß dann (falls das so bleiben sollte) wohl die meisten auf die AMD-Variante setzen würden. Du weißt schon, Kompatibilität und so ;).
SSE4.1 kam ja erst mit den 45nm CPUs, das können die etwas älteren Core2 (oder auch neue Atoms) einfach noch nicht.

Coda

2010-11-16, 20:13:26

@Coda: Hatte mal mit dem DPPS Befehl rumgespielt und war eher enttäuscht von der Performance.
Es geht nicht um die Performance. Die Code-Generation ist damit weniger aufwändig.

S940

2010-11-16, 21:11:30

Was hat Intel davon? Noch ein Kartelverfahren? Ein PR-Desaster?
Sie schließen damit nicht nur ihre älteren Produkte aus, sondern auch die der Konkurrenz.
Wieso ?
Solange die Konkurrenz keinen SSE4.1 Prozessor draußen hat, ist sie selbst Schuld. Da kann doch Intel nichts für.
Probleme gäbs für Intel nur, wenn sie einer non-Intel CPU mit SSE4.1 das trotzdem vorenthalten würden. Wer nen Nano 3000 sein Eigen nennt, kann ja mal testen (falls es die Dinger irgendwo käuflich zu erwerben geben sollte).

ciao

Alex

Nighthawk13

2010-11-16, 22:22:45

Ich denke mal, das wird microcoded (und aus normalen adds/muls zusammengesetzt) sein. Da spart man vermutlich also nur I$-/Decoding-Bandbreite und gewinnt nichts bei der Latenz/Durchsatz (bin zu faul mal nachzuschauen), oder?
http://www.agner.org/optimize/instruction_tables.pdf : Latenz/Durchsatz: 11/3
Sollte theoretisch schon schneller sein als 3*mulss + 2*adss (für skalares dot3). Register spart es wenigstens.

Was anderes: Der Intel-OpenCL-Treiber erwartet auch, dass jeder Thread (SSE)-vektorfreundlich programmiert ist.

Im Prinzip wäre es auch möglich, 4 skalare Workitems parallel in den (SSE)-Vektorlanes auszuführen, ähnlich wie ne Grafikkarte.
Da gibt es aber noch keinen CPU-Treiber zu, oder?

(Macht natürlich nur in bestimmten, einfachen Kernel Sinn, da auf der CPU kein scatter/gather z.B.)

S940

2010-11-16, 22:51:02

Im Prinzip wäre es auch möglich, 4 skalare Workitems parallel in den (SSE)-Vektorlanes auszuführen, ähnlich wie ne Grafikkarte.
Da gibt es aber noch keinen CPU-Treiber zu, oder?

Klingt nach nem Überbleibsel von Larrabee, der hat doch 4fach SMT ...
Oder meinst Du was anderes ?

Nighthawk13

2010-11-16, 23:03:20

Klingt nach nem Überbleibsel von Larrabee, der hat doch 4fach SMT ...
Oder meinst Du was anderes ?
Meinte auf ner normalen CPU mit SSE: dass der OpenCL-Compiler 4 Workitems zu einem CPU-Thread bündelt. (Reine Softwaregeschichte)

deekey777

2011-03-31, 20:41:13

FahCore_16 (OpenCL) ist jetzt verfügbar: http://folding.typepad.com/news/2011/03/core-16-for-ati-released-also-note-on-nvidia-gpu-support-for-older-boards.html
Leider setzt dieser auf OpenCL 1.1, womit die HD4000-Serie draußen bleibt.

Coda

2011-03-31, 23:33:15

Was anderes: Der Intel-OpenCL-Treiber erwartet auch, dass jeder Thread (SSE)-vektorfreundlich programmiert ist.

Im Prinzip wäre es auch möglich, 4 skalare Workitems parallel in den (SSE)-Vektorlanes auszuführen, ähnlich wie ne Grafikkarte.
Da gibt es aber noch keinen CPU-Treiber zu, oder?
Das Problem ist, dass SSE dafür die Scatter- und Gather-Befehle fehlen. Außerdem gibt es keine Predicate-Maske für SSE-Befehle usw.

Es wäre aber echt nett sowas mal in den CPUs zu haben. Leider bringt das AVX soweit ich weiß wieder nicht mit.

Nighthawk13

2011-04-05, 12:21:18

Das Problem ist, dass SSE dafür die Scatter- und Gather-Befehle fehlen. Außerdem gibt es keine Predicate-Maske für SSE-Befehle usw.

Es wäre aber echt nett sowas mal in den CPUs zu haben. Leider bringt das AVX soweit ich weiß wieder nicht mit.

100% ACK: fehlendes Scatter/Gather/Predicate macht die SSE-Programmierung sehr umständlich im Vergleich zu Cuda. Die Larabee-Instructions(LNI) hätten das wohl in die CPU-Welt gebracht.

Allerdings könnte der OpenCL-Compiler das Scatter/Gather/Predicate auch in Software emulieren:
a.) Einen "Fast-Path" generieren, der davon ausgeht dass die Speicherzugriffe auf die Vektorregister passen und keine divergenten Sprünge auftreten. Falls doch, wird automatisch auf Fallback b.) gewechselt.
b.) Der "Slow-Path" rechnet dann alles konventionell skalar.

Als OpenCL-CPU-Programmierer müsste man darauf achten, das möglichst viele Threads den Fastpath benutzen. Wenn ein paar wenige Threads auf den Slowpath zurückfallen kostet das nur Performance aber die Korrekheit bleibt gewährleistet.
Im Prinzip arbeitet man als GPU-Programmierer mit einem ähnlichen Modell.

Nighthawk13

2011-06-30, 12:18:52

Der Intel SPMD Compiler scheint diese Idee tatsächlich umzusetzen(skalare Programme semi-automatisch auf die SSE/AVX-Vektorlanes aufzuteilen):
http://ispc.github.com/ispc.html
Upon entry to a ispc function, the execution model switches from the application's serial model to SPMD. Conceptually, a number of ispc program instances will start running in parallel. This parallelism doesn't involve launching hardware threads. Rather, one program instance is mapped to each of the SIMD lanes of the CPU's vector unit (Intel® SSE or Intel® AVX).

Beispielcode: http://ispc.github.com/example.html

Simon

2011-06-30, 13:47:06

Der Intel SPMD Compiler scheint diese Idee tatsächlich umzusetzen(skalare Programme semi-automatisch auf die SSE/AVX-Vektorlanes aufzuteilen):
http://ispc.github.com/ispc.html

Beispielcode: http://ispc.github.com/example.html
Naja, sowas besonderes ist das nicht: Der ispc Compiler wandelt den gegebenen Code in Intrinsics um. Kann man auch per Hand machen bzw. den "normalen" Compiler in der Optimierungsphase.

Ach ja, der Compiler selbst hat nix mit Intel zu tun.

deekey777

2011-08-03, 14:13:22

APP SDK 2.5 ist draußen:
http://blogs.amd.com/developer/2011/08/02/amd-app-sdk-2-5-provides-enhanced-performance-and-major-new-capabilities/

Kernel launch times have been further reduced.

The LLVM compiler version used for OpenCL kernels has been upgraded.
Includes support for use of SSE3 and SSE4.
Added support for partial use of FMA4 and XOP instructions.
It is no longer necessary to use the -fno-alias compiler command line option.

PCIe transfer overhead has been reduced under Linux.
Transfers between CPUs and GPUs are improved for buffers declared with either the CL_MEM_USE_HOST_PTR or the CL_MEM_ALLOC_HOST_PTR flag.
For APUs, zero copy buffers created as CL_MEM_ALLOC_HOST_PTR | CL_MEM_READ_ONLY offer improved GPU read performance.
The runtime supports multi-GPU, including simultaneous use of the GPU on both and APU and a discrete GPU on systems running under Windows.
OpenCL built-in functions leverage AVX on capable CPUs
Support for PowerExpress 4.0.
Support for atomic counters for discrete GPUs.
Support for headless GPU operation.
OpenCL can be used by a Windows service.
UVD3 / MPEG-2 support.
The clFFT library supports radix 3 and radix 5, including support for mixed radix 2/3/5.
The BLAS library supports the D/S SYRK, D/S SYR2K, D/S GEMV, D/S SYMV functions.
The FP64 extension is supported for the ATI Radeon™ HD 5900 and 5800 series, as well as the AMD FirePro™ V8800 and V8700 series.
gDEBugger 6.0 extension is available for Visual Studio.
Starting with Catalyst 11.8, improved runtime features appear regularly in the monthly Catalyst releases for Windows.
Kernel Analyzer 1.9 supports Catalyst releases 11.4 to 11.7.
APP Profiler provides

Improved API trace.
Improved timeline visualization
Support for analyzing OpenCL Application trace.
Thread ID and sequence number now are included in the profile output.

=Floi=

2011-08-03, 15:09:45

irgendwie tut sich zu open cl gar nichts.

Nasenbaer

2011-08-03, 16:06:26

irgendwie tut sich zu open cl gar nichts.
Wieso was vermisst du denn?
Ich bin ohnehin eher mal gespannt was die neue Spracherweiterung (C++ AMP) seitens MS bringen wird, die wohl C++ auf der GPU möglich machen soll, wenn ich das richtig gelesen hab.

Bräucht man nur noch nen Compiler, der einem erlaubt rekursiven Code zu schreiben, den er denn in GPGPU-geeigneten Code umwandelt. :freak:

LovesuckZ

2011-08-03, 16:23:28

Wieso was vermisst du denn?

Anwendungen? :confused:

Nasenbaer

2011-08-03, 16:28:49

Anwendungen sind ja nun nicht Aufgabe der Standardisierungsgremien, sondern der Softwareklitschen und mittlerweile haben ja immer mehr Multimedia-Tools (also Video-Bearbeitung z.B.) und 3D-Tools wie 3DS Max Support für GPGPU und sogar Adobe nutzt mittlerweile DXVA. ^^
Für Excel oder Thunderbird wirst das sicher nicht brauchen. :)

Simon

2011-08-03, 20:58:31

Im Nvidia 280.x-Treiber gibt es jetzt auch Support fuer OpenCL 1.1. Allerdings ist der Treiber an sich wohl ein starkes Stueck langsamer...

Ganon

2011-08-04, 00:53:55

Naja, der Einsatzbereich von GPGPU ist auf einem "normalen Desktop" dann doch eher schon stark eingeschränkt. Da gibt's kaum Anwendungsfälle, wo sich GPGPU lohnt.

Im Forschungsbereich geht GPGPU aber momentan recht gut ab. Sei es im Bereich Datenbanken, Betriebssysteme oder Hochleistungsrechnen. Überall schwirrt GPGPU rum...

deekey777

2011-09-30, 10:02:02

OpenCL SDK 1.5 unterstützt Vektorisierung per CPU (http://www.heise.de/newsticker/meldung/OpenCL-SDK-1-5-unterstuetzt-Vektorisierung-per-CPU-1351862.html)
Mit dem jetzt vorgestellten Release beherrscht die Software erstmals auch die mit Intels Sandy-Brige-Prozessorgeneration eingeführte SSE-Erweiterung Intel Advanced Vector Extensions (Intel AVX) – speziell fließkomma-intensive Operationen sollen damit um bis zu einem Faktor 8 beschleunigt werden.

Dazu enthält das OpenCL SDK 1.5 mit Implicit CPU Vectorization ein neues Modul für die automatische Vektorisierung von Programmcode, das selbstständig passende SIMD-Anweisungen für Intel AVX generiert.

deekey777

2011-11-15, 17:36:49

http://www.khronos.org/opencl/
OpenCL 1.2 in Startlöchern.

Device partitioning - enabling applications to partition a device into sub-devices to directly control work assignment to particular compute units, reserve a part of the device for use for high priority/latency-sensitive tasks, or effectively use shared hardware resources such as a cache;

Separate compilation and linking of objects - providing the capabilities and flexibility of traditional compilers enabling the creation of libraries of OpenCL programs for other programs to link to;

Enhanced image support - including added support for 1D images and 1D & 2D image arrays. Also, the OpenGL sharing extension now enables an OpenCL image to be created from OpenGL 1D textures and 1D & 2D texture arrays;

Built-in kernels represent the capabilities of specialized or non-programmable hardware and associated firmware, such as video encoder/decoders and digital signal processors, enabling these custom devices to be driven from and integrated closely with the OpenCL framework;

DX9 Media Surface Sharing - enables efficient sharing between OpenCL and DirectX 9 or DXVA media surfaces;

DX11 Surface Sharing - for seamless sharing between OpenCL and DirectX 11 surfaces.

ENKORE

2011-11-16, 20:55:24

Ein übliches Khronos-Update; nichts wirklich weltbewegendes aber durchdachte Erweiterungen, die die API mächter und Programmierer glücklicher macht. Sehr gut :)

=Floi=

2011-11-17, 20:09:08

wenn es nicht flächendeckend eingesetzt wird, dann ist es irgendwo unnütz.

Nasenbaer

2011-11-17, 20:50:24

Nur weil nich jede Consumer-Anwendung OpenCL nutzt, ist es gleich unnütz ... :rolleyes:

ENKORE

2011-11-17, 21:33:13

OpenCL ist ein sehr sehr großer Fortschritt im Bereich GPGPU/HPC, weil du deinen Algo in EINER Sprache nur EINMAL schreiben musst, er aber *überall* - Grafikkarten und CPUs - läuft. Theoretisch könntest du dir auch für nen Cluster einen OpenCL-Treiber schreiben, der im Hintergrund die OpenCL-Tasks einfach nur an einzelne Maschinen delegiert.

Du siehst also, dass OpenCL sehr sinnvoll und sehr mächtig ist. Und bereits jetzt an vielen Orten CUDA am verdrängen ist - allein schon wegen der Kompatibilität.

=Floi=

2011-11-18, 20:09:51

eben weil es innvoll und toll ist verstehe ich die zurückhaltung im consumerbereich nicht. der vorteil ist teilweise eklatant groß, nur ohne software macht es eben keinen sinn.

Nasenbaer

2011-11-18, 20:19:20

Das ist nicht das Problem von Khronos, sondern der unzähligen Softwareklitschen. Und überall ist der Vorteil ja auch nicht so gravierend. So manche Video-Bearbeitungsanwendung nutzt ja durch OpenCL oder halt CUDA bzw. ATi Stream.
Und andererseits ist der Aufwand ja auch nicht unerheblich bspw. nen Encoder für GPGPU zu programmieren. Das muss sich rentieren, sprich man muss das Geld wieder reinbekommen können.

EDIT: Will sagen: Das wird schon noch kommen, sei nicht so ungeduldig oder programmiers selbst. :) Aber im HPC oder allgemein wissenschaftlichen Bereich wird es schon genutzt. DirectCompute hab ich bspw. auch schon vor 1,5 Jahren sinnvoll für meine Projekte nutzen können aber davon merkt der Enduser natürlich nichts. Trotzdem ist die Entwicklung daran alles, nur nicht unnütz!

deekey777

2011-12-12, 22:12:51

roidal

2011-12-14, 09:59:51

Könnt ihr mir ein paar Beispiele zu existierenden Programmen geben welche schon OpenCL verwenden?

deekey777

2011-12-14, 13:14:13

Könnt ihr mir ein paar Beispiele zu existierenden Programmen geben welche schon OpenCL verwenden?
Vreveal:
http://www.vreveal.com/home
Wobei ich das Gefühl habe, die Unterstützung ist auf die APUs beschränkt oder zumindest AMD-CPU+AMD-GPU.
Folding@Home (Evergreens und höher). Dann gibt es Mainconcept, http://www.mainconcept.com/de/produkte/sdks/gpu-acceleration/opencltm-h264avc.html, aber null Ahnung, welche Software diesen Encoder nutzt. ArcSoft hat auch mal was angekündigt, aber ist nichts daraus geworden.

samm

2011-12-14, 16:16:52

Hm, hast du einen Link, dass ArcSoft das eingestellt hat? TMT 3 nutzt noch Stream, für TMT 5 war Open CL für die HD6xxx Karten und ein halbes Jahr später für die AMD A-Prozessoren angekündigt.

deekey777

2011-12-14, 16:58:10

Hm, hast du einen Link, dass ArcSoft das eingestellt hat? TMT 3 nutzt noch Stream, für TMT 5 war Open CL für die HD6xxx Karten und ein halbes Jahr später für die AMD A-Prozessoren angekündigt.
Hm stimmt:
http://www.arcsoft.com/forum/forum_posts.asp?TID=8996&title=totalmedia-theatre-501114-release-notes
NEW FEATURES
01. Support AMD Fusion platform (Brazos + SABINE)
02. Support Intel SandyBridge platform (eDP+HDMI1.4 3DTV)
03. Support multiple audio tracks in MKV
04. Support standard and VobSub subtitles in MKV
05. Support audio bitstreaming in MKV
06. Support automatic refresh rate switch to 24hz for 24FPS content (BETA)
07. Improve TM Remote support for iOS (also, download separate TM Remote update)
08. OpenCL support for SimHD on AMD graphics
09. Sim3D quality improvement
10. Support 3rd party MCE launch via PlayerLoader URI

deekey777

2011-12-22, 00:04:53

http://developer.amd.com/SDKS/AMDAPPSDK/DOWNLOADS/Pages/default.aspx#two
AMD APP SDK 2.6 ist draußen. Auch eine OpenCL 1.2 Vorabversion. Oder zumindest angedeutet, denn verlinkt wird auf APP SDK 2.5. X-D
Jetzt ist alles in Ordnung.
Key features supported in SDK 2.6 and the Catalyst 11.12 drivers include:
• OpenCL™ runtime integration into Linux and Windows® Catalyst drivers.
• Inclusion of the Khronos C++ wrapper API.
• Multi-GPU support on Linux platforms.
• PX5 support.
• Preview: Support for AVX instructions on CPUs that support AVX.
• Support for FMA4 instructions in OpenCL built-in function libraries on CPUs that support
FMA4.
• Kernel reflection, query kernel parameters, and enable use of OpenCL kernels in data-driven
applications.
• Support for atomic counters on APUs.
• Redesign of OpenCL run-time on CPU, significantly improving performance.
• Support for the cl_amd_media_ops2 extension, exposing hardware capabilities for
accelerating image-related processing.
• Async copies preview (set environment variable GPU_ASYNC_MEM_COPY=2 to enable).
The OpenCL™ 1.2 preview includes the following capabilities (requires 8.93.10 preview drivers):
• Host access flags for memory objects enables more efficient buffer handling.
• Pattern-based GPU buffer and image initialization eliminates need for certain buffer/image
transfers.
• Memory objects migration supports early transfer of buffers in preparation for when they are
needed.
• New generalized image creation API.
• Enhanced image/buffer map operations.
• OpenCL 1.2 CPU device partition, including partition of a CPU after addition to a context.
• Generalized 1D and 2D images, image arrays, and image<-->buffer interop.
The 8.93.10 preview drivers also enable use of the static C++ kernel language.
gDEBugger version 6.1 is a major improvement in performance and robustness over version 6.0.
It can be downloaded for use with this SDK from http://developer.amd.com/gDEBugger.
• Integrated with Microsoft® Visual Studio®
2 of 6 Developer Release Notes
APP KernelAnalyzer v 1.1:
• Support for AMD Radeon™ HD7000 series GPUs (compilation only, no analysis).
• Support for Catalyst revisions through 11.11.
• Support for compiling kernels with the installed driver (select Installed Driver under the CAL
version in the Options panel).
• Format and Target Object Code are now separated.
APP Profiler v2.4 includes several key new features, including:
• A kernel occupancy analyzer that estimates, for each kernel dispatch, the number of in-flight
wavefronts on a compute unit as a percentage of the theoretical maximum number of
wavefronts that the compute unit can support. In addition to reporting the occupancy
percentage, the profiler can display a report that can help the developer achieve a higher
occupancy percentage.
• The ability to navigate from the API trace to the source code that called an OpenCL API.
• Improved OpenCL API analysis that provides performance suggestions to the developer.
• The ability to filter which OpenCL APIs are traced.
• Several UI enhancements, including the ability to rename sessions from the Session Explorer
Window, and the ability to automatically delete Profiler sessions when closing a Microsoft®
Visual Studio solution®.
• Preview: Support for profiling with AMD Radeon™ HD7000 series GPUs (requires AMD APP
SDK v2.6 and an AMD Catalyst version that supports this hardware).
Samples
• HDRToneMapping
• OpenCLServices