Wird OpenCL CUDA verdrängen? [Archiv]

Krishty

2008-10-26, 12:26:41

@Krishty
Wenn man mal von Spielen absieht, ist D3D nicht besonders stark vertreten. Im professionellen Bereich wird entweder gar keine 3d-Beschleunigung, oder OpenGL eingesetzt.
Das meinte ich mit „an den Erfolg von OpenGL 3.0 gekoppelt“. Das sollte nicht heißen, dass es den Bach runtergeht. Tut OpenGL 3.0 ja auch nicht. Es hat genau den Joker, der auch OpenGL am Leben erhält – dass die professionelle Branche kaum Vista und Top-Hardware einsetzt, dass es von vielen Plattformen unterstützt wird.

Im Kontext von Windows und Spielen wird sich hingegen die DirectX-API durchsetzen. Ich sähe als Entwickler keinen Grund dafür, eine weitere API in meinem Code einzusetzen, wenn ich eh schon D3D nutze und die Ergebnisse der Compute-Shader ohne Umwege im Renderer weiterverwenden kann.

Kann mir jemand sagen, wie es mit Microsofts Physik-API aussieht? Wäre jetzt ein sehr, sehr kluger Schachzug. Atm sind in Spielen die Hauptgründe für Compute Shaders ja Partikel und Physik. Wenn die Physik-API DirectX beiliegt, und man sie nicht selber schreiben muss, dann entfällt automatisch auch die Frage, welche API man dafür nutzt. OpenCL, CUDA usw kämen für viele Entwickler – im wahrsten Sinne des Wortes – nicht mehr in Frage.

Gast

2008-10-26, 12:44:34

OpenCL wird sich durchsetzen, da der Bereich der Anwendung eine offene Schnittstelle benötigt um für alle Anwender übergreifend nutzbar zu sein.
Wir (Uni-Entwicklerteam) entwickeln auch gerade GPGPU-Programme, jedoch mit CUDA. Uns wurde aber von mehreren Seiten zugetragen (auch Nvidia!), dass man in Zukunft mit OpenCL entwickeln solle, da dies die einzige Plattform sei, die von der Khronos Group unterstützt werde.
CUDA war demnach nie als marktübergreifende Langzeitlösung gedacht, sondern eher als Nvidia spezifische Lösung, um die TESLA-Systeme frühzeitig auf den Markt bringen zu können.
Uns hat es auf jeden Fall schonmal nicht geschadet, erste Erfahrungen mit der G8x/G9x/G200 Architektur in Bezug auf GPGPU gesammelt zu haben.
Das wird bei OpenCL sicherlich ganz nützlich sein.
Vor allem können wir dann auch erstmal weiterhin CUDA nutzen, bis wir mit OpenCL richtig warm geworden sind. ;)

Aquaschaf

2008-10-26, 13:28:22

Kann mir jemand sagen, wie es mit Microsofts Physik-API aussieht?

Physik ist sehr viel spielspezifischer als Grafik, ich denke nicht dass Microsoft so etwas entwickelt.

Ganon

2008-10-26, 13:32:20

OpenCL, CUDA usw kämen für viele Entwickler – im wahrsten Sinne des Wortes – nicht mehr in Frage.

Nunja. Haupteinsatzgebiete von OpenCL und Co. sind nicht Spiele... von daher hat das eher wenig miteinander zu tun.

Der Bereich liegt hier mehr im Multimedia. Video/Audio-Codecs, Bildbearbeitung, Sound etc. Dort hat der OpenGL/Direct3D "Krieg" nicht viel Bedeutung.

Krishty

2008-10-26, 14:06:42

Der Bereich liegt hier mehr im Multimedia. Video/Audio-Codecs, Bildbearbeitung, Sound etc. Dort hat der OpenGL/Direct3D "Krieg" nicht viel Bedeutung.Touché.

Gast

2008-10-26, 16:45:18

Nunja. Haupteinsatzgebiete von OpenCL und Co. sind nicht Spiele... von daher hat das eher wenig miteinander zu tun.

Der Bereich liegt hier mehr im Multimedia. Video/Audio-Codecs, Bildbearbeitung, Sound etc. Dort hat der OpenGL/Direct3D "Krieg" nicht viel Bedeutung.

Das ist nicht korrekt.

Auch für Spiele wird OpenCL massiv verwendet werden.
Die Möglichkeiten sind bis jetzt in heutigen Spieletitel lediglich noch nicht erschlossen,
aber das kommt noch.

Coda

2008-10-26, 17:04:22

Auch für Spiele wird OpenCL massiv verwendet werden.
Wenn Direct3D als Render-API verwendet wird ist das sehr unwahrscheinlich, da die Datenübergabe dann wahrscheinlich nur über den Host möglich sein würde. Das ist zu ineffizient.

Außerdem braucht man zwei verschiedene Shadersprachen, etc. Es ist weitaus einfacher D3D11 CS zu verwenden wenn man eh schon D3D anwendet.

Gast

2008-10-26, 18:04:04

Da ATI und andere OpenCL nutzen, hat sich OpenCL quasi schon durchgesetzt.

Coda

2008-10-26, 18:17:15

War das jetzt der gleiche Gast? Weil irgendwie versteh ich den Zusammenhang nicht.

ScottManDeath

2008-10-26, 19:53:05

Das heisst aber das man z.b. das Geschaeftsmodell seiner Firma darauf aufbaut, dass man der Khronos Gruppe vertraut. Wenn man sich aber mal ansieht was Khronos die letzte Zeit gemacht hat, kann einem Angst und Bange werden. Ich rede nichtmal von den technischen Aspekten, einfach nur vom Projektmanagement, Informationspolitik usw. Das verheisst nichts gutes fuer OpenCL.

Gast

2008-10-26, 23:48:00

Wenn Direct3D als Render-API verwendet wird ist das sehr unwahrscheinlich, da die Datenübergabe dann wahrscheinlich nur über den Host möglich sein würde. Das ist zu ineffizient.

Außerdem braucht man zwei verschiedene Shadersprachen, etc. Es ist weitaus einfacher D3D11 CS zu verwenden wenn man eh schon D3D anwendet.

Richtig. Bei D3D-Spielen wird OpenCL nicht verwendet werden, da D3D11 seine eigenen Möglichkeiten der Nutzung mitbringt. Es gibt also keinen plausiblen Grund zwei Schnittstellen zu nutzen.

Das heisst aber das man z.b. das Geschaeftsmodell seiner Firma darauf aufbaut, dass man der Khronos Gruppe vertraut. Wenn man sich aber mal ansieht was Khronos die letzte Zeit gemacht hat, kann einem Angst und Bange werden. Ich rede nichtmal von den technischen Aspekten, einfach nur vom Projektmanagement, Informationspolitik usw. Das verheisst nichts gutes fuer OpenCL.

Was heisst aufbauen? OpenCL kommt, das steht fest. Da die Khronos Group ein industriell angelegtes Konsortium ist, wird es auch von den Mitgliedern unterstützt werden.
Mal abgesehen von Analog Devices dürfte wohl alle IT-Mitglieder grosses Interesse an OpenCL haben.

DaBrain

2008-10-27, 00:54:49

Die Khronos Group kann schon gut Arbeit leisten.
Wenn sich bei OpenGL einige Mitglieder querstellen, heisst das nicht dass OpenCL das selbe Schicksal erwartet, besonders nicht gleich in der ersten Version.
COLLADA ist meiner Meinung nach auch ziemlich gut geworden.

Gast

2008-10-28, 13:18:30

Es gibt auch noch OpenCU. Das ist ein API-Framework, mit dem Programme automatisch so angepasst werden sollen, dass die Rechenlast eines Prozesses über alle im individuellen System vorhandenen CPUs und GPUs verteilt werden kann.

http://www.informationweek.com/shared/printableArticle.jhtml?articleID=211600246

Gast

2008-10-28, 14:48:31

Gast

2008-10-28, 21:20:55

Die richtige Frage wäre wohl was für ein Marktanteil bei solchen Lösungen die beiden haben werden.

und damit könnte das eine das andere verdrängen, fallst der marktanteil des kleineren vernachlässigbar wird.

DaBrain

2008-10-28, 22:56:00

Die Frage ist von mir aus gesehen auch falsch gestellt, den OpenCL kann CUDA gar nicht verdrängen, wie auch?

Da CUDA von NV ist und CUDA extrem auf die GPU von ihnen Optiemiert ist wird die schnellste Lösung auf NV GPUs immer CUDA bleiben, zudem wird NV für ihre Software wie zb. PhysX natürlich auch immer ihr CUDA verwenden.

Die richtige Frage wäre wohl was für ein Marktanteil bei solchen Lösungen die beiden haben werden.

Ok... der Beitrag ist wirklich schlecht.
Die Frage ist vollkommen berechtigt, auch wenn es möglich ist, dass beides nebeinander bestehen bleibt. (Nur nebenbei, ich persönlich denke nicht dass es CUDA sehr lange geben wird...)

Sicherlich hat Nvidia CUDA so entworfen, dass es gut auf Nvidia GPUs läuft, aber das hängt doch hauptsächlich davon ab, was gefordert wird.
Ich bin kein Programmierer undwill mich nicht so weit aus dem Fenster hängen, aber ich denke, dass die Anforderungen an die Grafikkarte unterschiedlich sind, wenn z.B. PhysX über CUDA, oder zum Video Encoding über CUDA eingesetzt wird.
ATI und Nvidia GPUs haben, soweit ich das verstanden habe, unterschiedliche Stärken.
Also hängt es ehr davon ab was gemacht werden soll, als davon ob CUDA oder OpenCL eingesetzt wird.

Und "[...]wird die schnellste Lösung auf NV GPUs immer CUDA bleiben" ist komplett daneben. "Immer" ist schon eine ziemlich lange Zeit.
Wenn GPGPU Systeme sich durchsetzen, wir es sicherlich eine starke Weiterentwicklung der Hardware und auch der Software geben.

deekey777

2008-11-14, 12:56:57

Wieviel CUDA steckt eigentlich in OpenCL? Das ist wohl die richtige Frage.
Am Montag wird OpenCL der Öffentlichkeit präsentiert (http://www.khronos.org/news/events/detail/opencl_sc08/).

OpenCL on the Fast Track (http://www.hpcwire.com/blogs/OpenCL_On_the_Fast_Track_33608199.html)

But if OpenCL succeeds, what will become of proprietary solutions like CUDA and Brook+? Wearing his NVIDIA hat, Trevett says his company is fully supportive of the OpenCL effort and they're going to be careful not to set up CUDA as an OpenCL competitor. He says the two platforms offer essentially the same level of interface, and as far as they're concerned, the more ways the programming community is able to get to parallel processing goodness, the better it will be for all the players. AMD, likewise, was an early OpenCL advocate and is committed to supporting an implementation on its "stream computing" processors.
...
Version 1.0 of OpenCL is currently scheduled to be released in early December at SIGGRAPH Asia 2008 in Singapore.

deekey777

2008-11-14, 16:46:18

Immerhin ist OpenCL ein offener freier Standard während CUDA was NVidia spezifisches ist.

http://de.wikipedia.org/wiki/OpenCL

OpenCL replacement for CUDA
http://forums.ngemu.com/software-discussion/106500-opencl-replacement-cuda.html
Ich glaube, das Ganze wird zu einseitig betrachtet.
Wie bei Wiki zu lesen ist, ist OpenCL für CPUs (auch CELL usw) und GPUs gedacht. Es ist eine (Hoch-)Sprache für alles.
Auch CUDA ist eine Hochsprache(C-ähnliche Synthax oder so), nur ist der Unterschied der, dass man mittels CUDA auch Low-Level-HW-Access hat, was OpenCL allein nicht hat. Und wie es aussieht, wird CUDA wie auch AMDs CAL die Schnittstelle zur Hardware bleiben. Sprich: Selbst wenn alle Programme OpenCL verwenden, bleibt (ein Teil von) CUDA die Schnittselle zur Hardware.
(Darum sind diese immerwieder auftretende Postings, AMD habe CAL für OpenCL aufgegeben, Quark, denn ohne CAL kein Zugang zur Hardware.)

Oder auch nicht.

S940

2008-11-20, 20:09:51

Wieviel CUDA steckt eigentlich in OpenCL? Das ist wohl die richtige Frage.

Wenn ich sowas lese, dann steckt mMn ne Menge CUDA in OpenCL:
“If you go to some other larger standards bodies, it’s quite normal for a standard to take five years or more,” Trevett said. “That’s quite commonplace. You actually have to really push to get it down to eighteen months. Our record was 12 months, up to now; we’ve done this one in six.”Von 5 Jahre auf 1/2 Jahr .. wenn da mal nichts kopiert wurde ...

Am Montag wird OpenCL der Öffentlichkeit präsentiert (http://www.khronos.org/news/events/detail/opencl_sc08/).
Richtig präsentiert wirds erst in frühestens nen Monat:
“The bottom line is, we’ve defined it technically,” Mattson explained. “Now you go through a process where all the companies involved get all their lawyers to pore through and make absolutely sure there’s no IP and that all the i’s have been dotted and all the t’s have been crossed. There’s a minimum of 30 days where companies can pore over it and approve it to say that ‘yes, we bless this. It does not expose IP, it does not create any trademark problems, it’s okay.’ But until that 30-day period is up, and until all of our companies have signed the paperwork saying ‘yes, we bless this,’ we cannot release demos, we cannot release the specs.”
http://www.macworld.com/article/136921/2008/11/opencl.html

Präsentationsfolien gibts hier:
http://khronos.org/opencl/

ciao

Alex

Neon3D

2008-11-29, 05:29:43

Gast

2008-12-03, 10:57:55

Wenn ich das richtig in Erinnerung habe, hat Apple OpenCL über mehrere Jahre in den Grundzügen entwickelt und dann vor einiger Zeit der Khronos Group zur Standardisierung und Fertigstellung vorgelegt. Ist das richtig? Und das soll auch einer der Gründe für die schnellen Fortschritte sein.

kevsti

2008-12-07, 08:08:14

Die Frage ist von mir aus gesehen auch falsch gestellt, den OpenCL kann CUDA gar nicht verdrängen, wie auch?

Da CUDA von NV ist und CUDA extrem auf die GPU von ihnen Optiemiert ist wird die schnellste Lösung auf NV GPUs immer CUDA bleiben, zudem wird NV für ihre Software wie zb. PhysX natürlich auch immer ihr CUDA verwenden.

Die richtige Frage wäre wohl was für ein Marktanteil bei solchen Lösungen die beiden haben werden.

Auch nVidia ist nur ein kleines Schlachtschiff im Weltmeer der "IT"..

Soll heißen das nVidia zwar schon ein wenig Macht hat, aber sollte sich OpenCL/DX11 als Lukrativ erweißen, wird ATi&Co ganz schnell ihre Hardware auf OpenCL/DX11 anpassen und dann muss nVidia herziehen und nicht ihr CUDA auf nVidia anpassen sondern ebenfalls ihnre Karten auf OpenCL/DX11 anpassen.

Oder meinst du nVidia würde sich eine Schlagzeile wie:

"Während ATi sowohl DX11 wie auch OpenCL unterstützt, klammert sich nVidia immer noch fest an ihr CUDA - fraglich ist warum, da ATi mit DX11/OpenCL die gleiche Performenc wie nVidia mit CUDA erzielt. Nur das viel mehr Programme davon profitieren"

Fazit: Wenn sich DX11/OpenCL durchsetzt hat auch nVidia keine Chance mit ihren CUDA ein Alleingang zu machen.

PS: Ersetzt DX11 durch den Namen der Technologie die GPU Programming ermöglicht.... mir ist er gerade entfallen...

Coda

2008-12-07, 13:04:23

NVIDIA wird natürlich auch die Compute Shader unterstützen, darüber braucht man gar nicht sinnieren. Das ist eine Voraussetzung für D3D11-GPUs. Außerdem haben sie selbst in den D3D10-GPUs schon praktisch alle Voraussetzungen dafür (vor allem arbitrary sharing) - im Gegensatz zu derzeitigen ATI-GPUs.

Badesalz

2019-07-17, 11:26:02

(mal auf die Schnelle ;))

Nun, über 10 Jahre später, wie sehr enttäuscht seid ihr von der Entwicklung?

Kaum etwas ist passiert beim Consumer. Als ich damals noch mit den @home Sachen rumspielte und jemand Seti für OpenCL umschrieb, was dann hier kurz auf einer X1950 lief... WOW, dachte ich. Das ist also diese GPGPU Revolution. Wahnsinn wie das hämmert ;)

Seitdem hat sich kaum etwas getan. Ok es sind erstmal 30 oder 40 Fachidioten (komplette Units) mit welchen immer Panik und Chaos ausbricht, sobald man kurz was verwerfen muß. Bestehen solche Gefahren, macht SSE und AVX eher Sinn.
Es gibt aber eben so einige dieser Aufgaben wo man es prinzipbedingt nicht muß, und trotzdem wird es entweder kaum genutzt oder nur in Kleinstmengen.

Nvidia brachte jetzt Ende 2018 den ersten RT Chip, sein Treiber kann jetzt OpenCL 2.0. :freak: 5 Jahre nach der Verabschiedung.
Cuda geht es halt weiterhin nicht schlecht. U.a. weil man dauernd sowas macht wie eine Weile 3 Leute bei Adobe zu parken die sich für die Umsetzung paar wenigen Sachen in Cuda - für "Mercury" - kümmern. Von alleine würden die das wohl auch nicht machen wollen. Warum eigentlich nicht?

Wo wir aber bei sowas sind. Die einigen wenigen solchen Programme, nutzen die GPU wenn denn schon für die Darstellung auf dem Bildschirm, nicht aber für die gleichen Operationen, wenn das Ergebnis endlich gespeichert wird. Klingt komisch, ist aber so :confused: Weil? KP.
Ah ja. Viele der wenigen :) Programme die was auf der GPU rechnen, gibt es auch für Apple. Und die machen bekanntlich seit einigen Jahren Metal(2). Das, wohin Vulkan erst hinwill. Nur nun nicht mehr gemeinsam Apple und Khronos, wie damals, als Apple Khronos OpenCL geschenkt hat.

Und DirectCompute (5.0 :tongue:)? Nutzt das überhaupt jemand für irgendwas, ausser DX Spielentwickler für ambient occlusion?

Gebrechlichkeit

2019-07-17, 14:17:17

OpenCL wird sich durchsetzen, da der Bereich der Anwendung eine offene Schnittstelle benötigt um für alle Anwender übergreifend nutzbar zu sein.
Wir (Uni-Entwicklerteam) entwickeln auch gerade GPGPU-Programme, jedoch mit CUDA. Uns wurde aber von mehreren Seiten zugetragen (auch Nvidia!), dass man in Zukunft mit OpenCL entwickeln solle, da dies die einzige Plattform sei, die von der Khronos Group unterstützt werde.

Hmm ... scheint sich nicht viel getan zu haben. Meine 280XOC wurde nur spaerlich unterstuetzt, keine NLE mochte die. Die 6870 widerrum, war ein Traum. Aktuelle sehe ich nur die Vega Reihe als "AMD´s Hoffnung", die scheinen fuer beides geignet zu sein (workstation, gaming :techgage.com).

Aber von "wird sich durchsetzen", sehe ich, merke ich nichts ausser man gibt endlich zu, dass Intel´s Quicksync doch wat tolles ist. :wink:

Ganon

2019-07-17, 17:19:17

Nun, über 10 Jahre später, wie sehr enttäuscht seid ihr von der Entwicklung?

NVidia stand (und steht) hier als Marktführer einfach viel zu lange auf der Bremse und jetzt ist das Interesse an OpenCL eh kaum noch vorhanden. Selbst AMD kompiliert lieber CUDA um... Der Erschaffer von OpenCL, namentlich Apple, wird es zukünftig ganz entfernen.

Ich weiß nicht ob einige Projekte schon einmal über die Compute-Fähigkeiten von Vulkan nachgedacht haben, es gibt soweit ich weiß auch irgend ein Projekt, was OpenCL auf Vulkan mappen will.

Badesalz

2019-07-17, 20:25:47

Alles was irgendwie mit Veränderung von Bild/Ton was zu tun hat - in egal welcher Form - könnte auf der GPU laufen. Das wird aber selbst bei RAW-Software nur für irgendwelche 2-3 Filter genutzt. Und für das Speichern von Tifs, bei PhaseOne. Und da geht es jetzt nicht nur um OpenCL.
Auch Cuda und Consumer ist jetzt nicht so die Erfolgstory diesbezüglich. Paar Prestigeprojekte alle Jahre mal wieder, die man Tatkräftig unterstützt (im Gegensatz zu AMD).

Das wars aber auch schon. Von alleine macht sozusagen keiner was. Irgendwas wird auf SSE2 oder SSE4 umgemoddet, aber OpenCL/Cuda? Von selbst eher nicht. Weniger auf Kommerz gedachte Sachen (Freeware und Shareware) so fast überhaupt nicht.

Wo liegt das Problem? Pauschal dürfte das Interesse das sein. Daheim ist bzw. wäre in gleicher Generation von beiden, die GPU immer mind. 2-3x schneller. Bei "Middleware" schon. Sonst eher 4-8x schneller.

Kompression? Crypto?

Ganon

2019-07-17, 21:12:31

OpenCL bekam erweiterte Fähigkeiten für Kram rund um Bilder mit OpenCL 1.2. OpenCL 1.2 wurde 2011 spezifiziert. Der Support für OpenCL 1.2 von NVidia kam 2015 :ugly: Zum Vergleich: AMD hatte 2014 einen OpenCL 2.0 Treiber.

Wie gesagt, dadurch, dass OpenCL 1.2 sehr lange auf einem Großteil aller Computer schlicht nicht vorhanden war, stockte auch der Support und irgendwann ist das Thema auch eingeschlafen.

Diverse CUDA Projekte arbeiten auch an OpenCL Backends, aber aktuell ist das Thema "OpenCL Implementierung" ein ziemlicher Sauhaufen und afaik hat NVidia immer noch keine komplette OpenCL 2.0 Implementierung. Aber vielleicht kam das derweil auch. Aktuell ist OpenCL 2.2.

Badesalz

2019-07-17, 22:01:11

Jein… Weil wie gesagt siehts mit Cuda auch nicht so mega aus. Das wird zu 70% nur gemacht, wenn NV Hilfe anbietet.

Was mich nochmal zu der Frage bringt: Warum? Ist das viel komplizierter zu programmieren, daß die Leute sich lieber 4x SSE anschauen, bevor sie sich 1x mit GPUs abgeben? Mit speed ups kann man immer nur prahlen. Da gibt es kein pro und contra :tongue:
Trotzdem war und bleib ist das Interesse letztendlich eher marginal (für consumer)

Ganon

2019-07-17, 22:29:27

Das Problem ist der getrennte Speicher. Du musst halt so programmieren, dass dein Workload in den Speicher der GPU passt und du musst auch immer die Daten in den Speicher der GPU schreiben und auch von dort wieder rausholen (=langsam). Wenn die Datenmenge zu klein ist, dann bist du mit SSE/AVX Optimierungen wesentlich schneller. Ist die Datenmenge zu groß, hast du ggf. ein Problem mit dem VRAM. Je nachdem was du für ein Problem bearbeiten willst.

Ansonsten habe ich 3 Programme im Einsatz die OpenCL können. Die ImageMagick Suite hat ein Sachen für OpenCL, Blender macht ein paar Sachen mit OpenCL und LibreOffice Calc kann ggf. auch OpenCL benutzen.

Die Idee war damals auch, dass man nur OpenCL benutzt und das dann quasi für CPU und GPU benutzt. Aber es stellte sich auch heraus, dass man mit nur einer Codebasis nirgendwo wirklich effizient ist.

gmb

2019-07-17, 22:51:06

OpenCL bekam erweiterte Fähigkeiten für Kram rund um Bilder mit OpenCL 1.2. OpenCL 1.2 wurde 2011 spezifiziert. Der Support für OpenCL 1.2 von NVidia kam 2015 :ugly: Zum Vergleich: AMD hatte 2014 einen OpenCL 2.0 Treiber.

AMD hat das damals ziemlich gepusht mit Llano und die ersten 2-3 Jahre. Seitdem ist dann aber auch nicht mehr viel passiert, afaik haben sie noch kein OpenCL 2.1 für Windows? Und wenn ich mir die Open Source Entwicklung auf github so ansehe, ist da nicht viel Aktivität zu sehen. Am meisten Aktivität zeigt Intel seit der Entwicklung vom neuen "NEO" OpenCL Treiber, die haben für Icelake auch schon OpenCL 2.2 bestätigt, seit Q2 sind die OpenCL 2.2 ready.

aufkrawall

2019-07-17, 23:43:06

Und wenn ich mir die Open Source Entwicklung auf github so ansehe, ist da nicht viel Aktivität zu sehen.
Dann hast du offenbar etwas missverstanden, denn alle paar Wochen ein neues ROCm-Release ist nicht "nicht viel Aktivität".

gmb

2019-07-18, 00:23:58

Dann hast du offenbar etwas missverstanden, denn alle paar Wochen ein neues ROCm-Release ist nicht "nicht viel Aktivität".

So viel Aktivität das sie immer noch bei OpenCL 2.0 festhängen und SPIR-V immer noch auf sich warten lässt. Wie gesagt, AMD hat vor vielen Jahren eine riesen Welle gemacht, seitdem ist das stark eingeschlafen.

Badesalz

2019-07-18, 01:04:46

Das Problem ist der getrennte Speicher. Du musst halt so programmieren, dass dein Workload in den Speicher der GPU passt und du musst auch immer die Daten in den Speicher der GPU schreiben und auch von dort wieder rausholen (=langsam). Wenn die Datenmenge zu klein ist, dann bist du mit SSE/AVX Optimierungen wesentlich schneller. Ist die Datenmenge zu groß, hast du ggf. ein Problem mit dem VRAM. Je nachdem was du für ein Problem bearbeiten willst.Ist das nicht für die Art der Daten die auf der GPU Sinn ergeben und die man halt da durchschieben will, egal? Die sind für mich statisch.
Und wenn nicht, dann kommen sie halt als Strom an. Dann muss man sie doch nur in entsprechenden Happen (Vram) rüberschaufeln.
Das sollte spätestens ab 2GB Vram auf dem consumer PC für so einige "Probleme" ausreichen :confused:

Das macht schon fast sauer, wenn man überlegt welche Power die Leute auch heute noch mit einer 1060 oder auch nur rx470 haben, und das wird von den Programmen nur für bisschen FHD Daddeln genutzt.

@gmb
2.0 richtig eingesetzt würde erstmal ausreichen ;) Da könnte man schon einiges anschieben mit.

Ganon

2019-07-18, 09:31:18

Dann muss man sie doch nur in entsprechenden Happen (Vram) rüberschaufeln.

Ja und in der Zeit in der die Daten über den PCIe Bus von deinem RAM zum VRAM wandern und zurück, hat die CPU mit AVX Optimierungen den ganzen Kram schon fertig.

Du brauchst halt einen Sweetspot in Datenmenge und Berechnungszeit. Im Regelfall hat man halt mehrere GB Daten, die man dann je nach VRAM Menge aufspaltet und dann Stückweise zur GPU schiebt. Das ist dann schneller als auf CPU, da die GPU halt eben ordentlich mehr Leistung hat (z.B. bei Raytracing).

Soweit ich weiß hat OpenCL 2.0 auch Features für Shared Virtual Memory, sodass man sich darüber keinen Kopf machen muss (zumindest in der Theorie). Und sogar Nvidia unterstützt das, aber leider Apple nicht :ugly: Es ist halt leider ein ziemlicher Clusterfuck.

Ganon

2019-07-18, 09:38:11

AMD hat das damals ziemlich gepusht mit Llano und die ersten 2-3 Jahre. Seitdem ist dann aber auch nicht mehr viel passiert, afaik haben sie noch kein OpenCL 2.1 für Windows? Und wenn ich mir die Open Source Entwicklung auf github so ansehe, ist da nicht viel Aktivität zu sehen. Am meisten Aktivität zeigt Intel seit der Entwicklung vom neuen "NEO" OpenCL Treiber, die haben für Icelake auch schon OpenCL 2.2 bestätigt, seit Q2 sind die OpenCL 2.2 ready.

Die Frage ist halt (und das hat AMD auch in etwa so gesagt): Wofür? Sie konzentrieren sich afaik jetzt erst mal darauf einen soliden OpenCL 1.2 / 2.0 Compiler/Runtime zu haben, weil eben gut 99% aller Projekte genau das nutzen und es auch das ist was du von NVidia bekommst.

Jetzt großartig viel Energie in OpenCL 2.1 / 2.2 zu stecken ist halt irgendwo auch verschwendete Zeit.

- Apple unterstützt es nicht
- NVidia unterstützt es nicht
- Intel unterstützt es nur auf Top-Aktueller Hardware und eben auch nur auf krüppligen iGPUs

Welches Projekt soll jetzt bei den Gegebenheiten auf OpenCL 2.1 / 2.2 aufspringen?

Gast

2019-07-18, 10:59:30

Du brauchst halt einen Sweetspot in Datenmenge und Berechnungszeit. Im Regelfall hat man halt mehrere GB Daten, die man dann je nach VRAM Menge aufspaltet und dann Stückweise zur GPU schiebt. Das ist dann schneller als auf CPU, da die GPU halt eben ordentlich mehr Leistung hat (z.B. bei Raytracing).
Um es zu präzisieren: Vor allem braucht man einen Sweetsport zwischen Datenmenge und Menge der Rechenoperationen auf diesen Daten. 2MP Bilder auf die GPU schieben um sie bspw. zu addieren macht keinen Sinn: Pro Pixel ein ADD, das ist viel zu wenig und kann die Kosten des Datentransfers schwer amortisieren.
Anders kann es aussehen wenn man was anderes mit den Bildern macht, z.b. neuronale Netze trainieren. Die ImageNet Bilder werden üblicherweise in der Auflösung 256 x 256 verwendet, aber weil dann so massiv viel damit gerechnet wird zahlt sich das aus.

Entscheidend ist nicht die Datenmenge an sich, sondern das Verhältnis von Datenmenge zu Rechenoperationen. Deshalb hat sich GPU Unterstützung im Audio Bereich auch nicht durchgesetzt. Dort hätte man zwar große Datenmengen, aber die Operationen auf den Daten sind vergleichsweise simpel -> SSE/AVX wins.

Das macht schon fast sauer, wenn man überlegt welche Power die Leute auch heute noch mit einer 1060 oder auch nur rx470 haben, und das wird von den Programmen nur für bisschen FHD Daddeln genutzt.

Um die Power der GPU zu nutzen muss das Problem zuallererst einmal parallelisierbar sein, und das sind bei weitem nicht alle Probleme. Einfach so "die Power der GPU nutzen" und dann ist auf einmal alles 10 mal schneller - so funktioniert das nicht. Es ist ja kein Zufall dass die GPU Programmierung hauptsächlich in der Bildverarbeitung verwendet wird. Wenn man dort etwas macht, dann macht man üblicherweise für alle Pixel dasselbe -> parallel.
Im Gegensatz sind so grundlegende Probleme wie sortieren, suchen, alles was mit komplizierteren Datenstrukturen zu tun (z.b. Binärbaum u.ä.) schwer bzw gar nicht parallelisierbar.

Wo liegt das Problem? Pauschal dürfte das Interesse das sein. Daheim ist bzw. wäre in gleicher Generation von beiden, die GPU immer mind. 2-3x schneller. Bei "Middleware" schon. Sonst eher 4-8x schneller.

Kompression? Crypto?
Kompression und crypto sind Musterbeispiele für Algorithmen die schwer parallelisierbar sind.

@topic: OpenCL wird weiterhin ein Nischendasein fristen, und die Nische wird immer kleiner. Das liegt zum einen daran, dass es dort, wo der Hype und das große Geld zuhause ist, nämlich in der Welt von AI und neuronalen Netzen, überhaupt nur ein Option gibt: Cuda. OpenCL interessiert da niemanden. Und solange es nichts vergleichbares zur cudnn gibt wird sich das nicht ändern. nvidia hat da so ein starkes standing und so viel Vorsprung, dieser Zug ist abgefahren.

Zum anderen leidet OpenCL an dem "wir wollen es allen recht machen" Syndrom. Ich habe viel Cuda programmiert, und ich muss sagen im Vergleich dazu ist OpenCL ein einziger Krampf. Dadurch dass es auf CPU, GPU, irgendwelchen parallelen Koprozessoren laufen soll, sind die interfaces und die Art und Weise wie das OpenCL Ökosystem aufgebaut und struktueriert ist so allgemein, dass die Programmierung eine einzige Qual ist. Bei Cuda habe ich 80% der Zeit mit programmieren von Algorithmen verbracht und 20% mit dem tooling rundherum, bei OpenCL wars umgekehrt.

Das ist einfach eine Zumutung und macht keinen Spaß. Bei Cuda bekommt man eine ausgereifte toolchain, ordentliche Doku, einen Profiler und Debugger und tonnenweise bibliotheken und tools. Bei OpenCL ist vieles nur rudimentär vorhanden und manches gar nicht (bzw. vieles gar nicht vorhanden, und wenn, dann nur rudimentär ;) )

Schade, denn ich wäre der erste der es begrüßen würde wäre man nicht mehr auf nvidia festgenagelt. Aber im Moment sehe ich keine Anzeichen für eine Änderung.

Badesalz

2019-07-18, 11:30:41

Nun, das würde endlich auch daheim einen klareren Sinn ergeben, was PCIe 3.0 oder 4.0 angeht ;)

Und ob man meist mehrer GB großen Dataset hat? Auch bei 5min. Video ist das uninteressant. Interessant ist nur der eine Frame der grad durchläuft. Die Datasets kratzen daheim meist maximal am dreistelligen MB Bereich.
Wie hier bei Media, SSE vs. GPU
https://www.youtube.com/watch?v=LfNIEIbnA8E

EDIT:
Geizhals listet bei Polaris übrigens OpenCL 2.0. Bei Bonaire OpenCL 2.1 :freak:

Badesalz

2019-07-19, 10:16:16

iuno

2019-07-19, 11:36:40

Geizhals listet bei Polaris übrigens OpenCL 2.0. Bei Bonaire OpenCL 2.1 :freak:
Auf solche Angaben kann man eh nichts geben, da es oft eine reine Treibersache ist. Und dazu hat AMD auch noch >2 verschiedene CL runtimes (orca, roc, clover). Z.B. listet auch Intel selbst in ihrer eigenen ARK IGPs noch mit OpenGL 4.3, obwohl sie laengst 4.5 unterstuetzen.

OpenCL wird weiterhin ein Nischendasein fristen, und die Nische wird immer kleiner. Das liegt zum einen daran, dass es dort, wo der Hype und das große Geld zuhause ist, nämlich in der Welt von AI und neuronalen Netzen, überhaupt nur ein Option gibt: Cuda. OpenCL interessiert da niemanden. Und solange es nichts vergleichbares zur cudnn gibt wird sich das nicht ändern. nvidia hat da so ein starkes standing und so viel Vorsprung, dieser Zug ist abgefahren.
Das muss aber nicht fuer immer so bleiben. Es gibt ja schon effizientere Hardware als Nvidia GPUs, was NN angeht. Es kann auch sein, dass sich hier eine komplett neue, vendor-unabhaengige Schnittstelle etabliert. Es muss ja dann nicht CL sein.

Habana wollte im Linux Kernel schon ein neues Subsystem fuer solche Beschleuniger etablieren. Deren bisher einziger Treiber (IIRC) ist dann zwar in "misc" gewandert und das hat jetzt auch nichts mit einer userspace-API wie CL zu tun, koennte aber darauf hindeuten, dass so eine Abspaltung passiert und sich auch eine neue API etablieren kann.

Schade, denn ich wäre der erste der es begrüßen würde wäre man nicht mehr auf nvidia festgenagelt.
Was genau machst du denn? NN oder auch anderes GPGPU? Hast du dir mal angeschaut, ob sich Vulkan nicht eignen wuerde?
Zumindest schienen Codeplay/Google schon von Beginn an der Meinung zu sein, dass das Sinn ergebe.

Aber im Moment sehe ich keine Anzeichen für eine Änderung.
Ich glaube zwar auch nicht mehr an OpenCL, aber Intel tut das offenbar. Zumindest haben sie erst einen komplett neuen Treiber aufgebaut und wollen ja demnaechst wieder mit grossen GPUs in den Markt einsteigen.

Badesalz

2019-07-19, 17:03:23

Ich glaube zwar auch nicht mehr an OpenCL, aber Intel tut das offenbar. Zumindest haben sie erst einen komplett neuen Treiber aufgebaut und wollen ja demnaechst wieder mit grossen GPUs in den Markt einsteigen.Denke für Intel ist das mehr eine Investition in die Zukunft, in der Vulkan und SPIR-V verschmolzen sind ;)

Besser ist an Cuda nichts, außer eben der weit besseren Werkzeuge für die Coder.

Gast

2019-07-19, 23:06:51

Besser ist an Cuda nichts, außer eben der weit besseren Werkzeuge für die Coder.
Für die Frage nach der Verbreitung und der Nutzung in mehr Softwareprojekten ist "bessere Werkzeuge für Codes" so ziemlich das wichtigste Kriterium. Insofern müsste der Satz lauten: besser ist an Cuda vieles, vor allem die weit ausgereifteren Werkzeuge für coder.

Anders gesagt: die Antwort auf das Thread Thema "wird OpenCL cuda verdrängen?" liegt genau in dieser Tatsache, die du fälschlicherweise mit "...nichts, außer eben..." als unwichtig abtust.

Gast

2019-07-20, 13:39:47

@Gast
Allgemein:
Schätze du meinst, wenn es massiv-parallel geht, macht GPGPU Sinn. Ich habs mir wohl zu einfach vorgestellt :)
Für mich war das Geseier der Hersteller über "Tausende Cores" in dem Kontext immer nur PR-Bullshit. Ich habs eher wie bei AMD die CUs gesehen. Oder bei NV die SM (wobei das ja nicht 1 zu 1 vergleichbar ist).
Die tausenden cores ist schon nicht ganz falsch. Wenn du z.b. irgendwelche operationen auf bildern ausführen möchtest, dann kannst du das wirklich für mehrere tausend pixel zugleich machen. Dafür ist die HW ausgelegt.

Weil... die schlecht parallerlisierbare :freak: Fälle die du ansprichst, und die auf CPUs laufen, die laufen heute in Threads auf Mehrkerner schneller. Dazu gehört u.a. auch Crypto und Packen.
Wenn von den CUs (um mal bei dem einfacheren Beispiel AMD zu bleiben) jemand jetzt 36 Stück hätte, wäre das noch nicht ganz so "massiv" wie die direkte Denke (des Coders) über die dazu gehörenden 2048 ShaderUnits. Ich dachte man muß sich nur um die CUs halbwegs kümmern. Nicht um jede ShaderUnit einzeln (bei der Parallelisierung).

Ich weiß nicht genau was du mit "kümmern" meinst, aber aus Programmiersicht ist der Unterschied zwischen CU/SM und den einzelnen Kernen ziemlich egal. Der Programmierer schreibt Code und sagt dann der HW "bitte so und so oft auf diesen Daten ausführen" - das wars.

Packen und crypto funktioniert auf GPUs schlecht, weil die Algorithmen dahinter voll von Sprüngen, Verzweigungen, komplizierten Datenstrukturen sind, und weil es eben im Kern sequentielle Algorithmen sind. Man berechnet ein Teilergebnis und dieses Teilergebnis ist dann der input für den nächsten Schritt. Das ist gerade das Gegenteil von parallel, wo die (Teil)Ergebnisse unabhängig voneinander sind eben parallel berechnet werden können.
Außerdem mögen GPUs viele Verzweigungen und Sprünge gar nicht. Da sind CPUs viel besser, die haben eine mächtige Sprungvorhersage, können gut mit Verzweigungen umgehen usw.
Ein Aufspalten eines großen Problems in sagen wir 8 Teile, wobei diese 8 Teile jeweils auf einer vollwertigen CPU mit allem drum und dran laufen, ist etwas ganz anderes als ein massiv paralleles Problem, wo man viele tausende mal genau die gleichen Operationen auf verschiedenen Daten ausführt.

Das muss aber nicht fuer immer so bleiben. Es gibt ja schon effizientere Hardware als Nvidia GPUs, was NN angeht. Es kann auch sein, dass sich hier eine komplett neue, vendor-unabhaengige Schnittstelle etabliert. Es muss ja dann nicht CL sein.

Diese HW ist soweit ich weiß hauptsächlich für die Anwendung der fertigen Netze gedacht. Da mag es schon sein dass sich was neues etabliert, für die Verbreitung der Programmierumgebung ist das aber m.M.n. relativ irrelevant. Denn dafür zählt wo/wie die Entwicklung gemacht wird, und die Entwicklung wird bei Cuda bleiben. Weil diese spezielle HW für das Ausführen relativ unflexibel ist und damit für die Entwicklung nicht so praktisch.

Was genau machst du denn? NN oder auch anderes GPGPU? Hast du dir mal angeschaut, ob sich Vulkan nicht eignen wuerde?
Zumindest schienen Codeplay/Google schon von Beginn an der Meinung zu sein, dass das Sinn ergebe.

Ich habe einiges allgemeines GPGPU gemacht, verschiedene Algorithmen aus dem Bereich Computer Grafik und viel Computer Vision, Parallele Optimierungsalgorithmen usw.
Da will man eigentlich so etwas wie Cuda haben, wo man quasi C++ schreibt nur dass es statt auf der CPU auf der GPU läuft und auf viele tausend cores skaliert. Vulkan habe ich keine Erfahrung, aber wenn es so ähnlich ist wie die compute shader von OpenGL dann ist das nicht wirklich eine praktikable Alternative. Viel zu viel Einschränkungen wenn man mal den Komfort von "C++ für die GPU" gewohnt ist. :)

mksn7

2019-07-24, 10:38:21

Intel schenkt OpenCL und Sycl ja in letzter Zeit etwas mehr Liebe, weil sie das für ihre GPUs brauchen. Dann kommt vielleicht wieder etwas Leben in das in den letzten Jahren total eingeschlafene OpenCL, und den furchtbaren Zustand der OpenCL Plattformen.

Bei einer guten Unterstützung duch Intels IGPs ist OpenCL vielleicht mal wieder ein lohnendes Target im Consumerbereich.

Gast

2019-07-26, 14:13:39

@topic: OpenCL wird weiterhin ein Nischendasein fristen, und die Nische wird immer kleiner. Das liegt zum einen daran, dass es dort, wo der Hype und das große Geld zuhause ist, nämlich in der Welt von AI und neuronalen Netzen, überhaupt nur ein Option gibt: Cuda. OpenCL interessiert da niemanden. Und solange es nichts vergleichbares zur cudnn gibt wird sich das nicht ändern. nvidia hat da so ein starkes standing und so viel Vorsprung, dieser Zug ist abgefahren.
Dann nimm doch mal deine NV Fanboy Brille ab, und schau dir die Fakten an. Bei AI unterstützen inzwischen alle relavanten Frameworks auch OpenCL, quasi alle Autonomen Fahrzeuge fahren mit OpenCL, weil sich die Automobilhersteller großflächig auf SyCL als Framework geeinigt haben. Da nutzt niemand Cuda und wenn man sich mit dem Thema beschäftigt hätte, dann wüsste man das auch. Aber das hast du vermutlich noch nie gemacht, weil du gar kein Interesse daran hast von Cuda zu wechseln (wenn du überhaupt Cuda nutzt, was auch schon zweifelhaft ist).
Insofern ist deine Behauptung einfach falsch.

Badesalz

2019-07-27, 10:30:37

Anders gesagt: die Antwort auf das Thread Thema "wird OpenCL cuda verdrängen?" liegt genau in dieser Tatsache, die du fälschlicherweise mit "...nichts, außer eben..." als unwichtig abtust.
Geht so ;) Wenigert als unwichtig gemeint, als "das kann dann doch nicht so schwer sein". In meiner Naivität stelle ich mich das Coden der Werkzeuge nicht so schwierig wie eine ganze API (mit den dazugehörenden "Kernels") aus dem nichts zu stampfen.
Wenn man sich wirklich hinkniet ist OpenGL4/OpenCL2 (wo anschliessend Vulkan nochmals einen drauflegt), nicht soviel langsamer (?), daß man es automatisch abtut. Das Problem, was ich sehe, ist eben das "Hinknien" (müssen).

Irgendwie befremdlich wie Khronos doch immer weiter die Funktionen und ihre Leistungsfähigkeit signifikant verbessert (ist ja auch so), nicht aber die der Werkzeuge. Das sah man all die Jahre nicht, die absolute Wichtigkeit dessen? Die hatten bis Vulkan keine Idee gehabt, warum Microsoft schon 1997 VisualStudio brachte und es seitdem stark vorangepeitscht hat?

(wobei erstmal nichts vergleichbares mit Vulkan kam, aber an ihrem Machen&Tun im Hintergrund kann man wenigstens erkennen, daß es jetzt Priorität hätte, sowas zu haben :freak:)

pixeljetstream

2019-07-27, 11:52:27

@Badesalz
Tools sind ziemlich arbeitsaufwendig. Wenn man sich die top engines anguckt, Unreal/Unity so ist deren Wert extrem an die Tools gekoppelt, die Engine ist zwar der Kern, aber es arbeiten wesentlich mehr Leute an dem drumherum. Hier sind die tools aber Produkte, Khronos verkauft keine Produkte.
Daher kann ich das mit VisualStudio nicht ganz nachvollziehen, Khronos ist ja nicht Microsoft die hier ein Produkt machen, sondern eher das Gremium das den C++ Standard definiert.

Khronos ist eine Interessengemeinschaft von Firmen die in erster Linie Konkurrenten sind ;) die Entscheidungen sind demokratisch, jedes Mitglied hat das gleiche Stimmrecht, dadurch kann es sich schonmal hinziehen. Khronos ist hier eher ein non-profit. Den "eigentlichen Wert" wollen ja die Firmen für sich verbuchen... und die haben ja auch eigene Interessen, eigene Mittel etc.
Nichtsdestotrotz bemüht man sich und sammelt Geld von den Mitgliedern für Marketing, oder bezahlt Firmen für die Entwicklung von SDKs, sponsort Open-Source Projekte etc. Aber das ist eben nie in dem Rahmen wie das die Firmen für sich selbst tun, bzw. sie müssen ja die Zeit der eigenen Entwickler bereitstellen und das fehlt dann woanders.

Zu dem anderen Punkt: Apis entstehen ja heute nicht aus dem nichts, es gibt immer schon was ähnliches was man dann halt umstrukturiert, bzw. man hat ja die Erfahrung aus ähnlichen apis, meist gibt es ja schon proprietäre apis an denen man sich orientiert. Das größere Problem ist eben dann eher das Ökosystem, tools, libraries, samples, doku etc. Selbst wenn api X technisch besser ist, muss das investment was in vorheriges war ja erstmal umgeleitet werden bzw. die neue api so robust, so viel mehr bieten dass es sich für die ganzen software firmen lohnt zu wechseln. Und diese Kohle das zu promoten kommt eben meist von den Platformhaltern (MS, Google, Apple), die das aber eben auch eher für sich wollen.

Was nicht heißen soll dass alles furchtbar ist und die Firmen sich nur gegenseitig blockieren, imo wird die situation um Khronos definitiv besser und Microsoft engagiert sich auch stärker, aber es ist einfach ein komplexer Prozess wo nicht-technische Gründe auch mitreinspielen.

Badesalz

2019-07-27, 12:17:59

Daher kann ich das mit VisualStudio nicht ganz nachvollziehen, Khronos ist ja nicht Microsoft die hier ein Produkt machen, sondern eher das Gremium das den C++ Standard definiert.

Khronos ist eine Interessengemeinschaft von Firmen [...]Das verstehe ich widerum nicht. Der erste Absatz wird doch von dem zweiten erklärt (?) ;)

Wenn man da nicht zusammen am gleichen Strang zieht, hat man eben das was man heute gegenüber Cuda Toolboxen hat. Das fiel der Interessengemeinschaft erst 2018 auf?
Ich vermute die Khronos-Interessengemeinschaft ist nicht so organisiert, daß NV da ewig sabotieren kann? Wenn doch, hätte man zuerst die Organisationsstrukturen überarbeiten sollen...

pixeljetstream

2019-07-27, 12:53:09

NV sabotiert ja nicht, das geht ja auch nicht bei gleichem Stimmrecht. Mein Argument ist ja dass man nen großen Plattformhalter brauch der eine api pusht. Das war anfangs apple bei CL aber die haben ja auch früh aufgehört. Ergo hatte CL keinen großen "Sponsor" mehr und die api damit kommerziell einfach nicht mehr so relevant.

Wie gesagt Khronos ist keine Firma die ein Produkt verkauft, es gibt ganz wenig eigene Mitarbeiter, man organisiert die Standardiserung, regelt die Patente/IP Fragen untereinander und gut. (Da verstehe ich eben deine Anspielung auf VStudio nicht). Die eigentliche Arbeit in den Gremien etc. passiert von den Mitarbeitern der Mitgliedsfirmen.

MS, Google, apple werben mit ihren APIs um Entwickler auf ihre Platformen zu ziehen, HW Hersteller werben mit ihren Features etc.

Badesalz

2019-07-27, 22:02:40

OpenCL ist (wäre) ein Feature für eine GPU :rolleyes:

gravitationsfeld

2019-07-27, 22:28:38

NV sabotiert ja nicht, das geht ja auch nicht bei gleichem Stimmrecht.
Ach komm, das meinst du jetzt nicht ernst? Jahrelang neue Versionen nicht unterstuetzen und konstant schlechtere Performance als CUDA, aber ist naetuerlich alles Zufall.

pixeljetstream

2019-07-28, 00:33:03

Ach komm, das meinst du jetzt nicht ernst? Jahrelang neue Versionen nicht unterstuetzen und konstant schlechtere Performance als CUDA, aber ist naetuerlich alles Zufall.
Ich meine das ernst, der Erfolg einer offenen api kann ja nicht der Verantwortung eines Herstellers allein auferlegt werden. Hätten andere in größerem Maße investiert oder hätte einer der großen (MS, apple, Google) es für wichtig empfunden hätte es sich NV nicht leisten können hier nicht so viel zu machen, der Markt regelt das. Und die Geschichte gibt der Entscheidung ja Recht, Apple hat es aufgegeben, Khronos selbst fördert nun Projekte cl mit Vulkan zu ersetzen.

Ich verstehe nicht warum in der Angelegenheit es NV dermaßen nachgetragen wird nur weil sie in der Sache nicht den Geldhahn aufdrehten sondern sehen wollten was passiert und was der Rest macht.

Ohne Android und Streaming würde Vulkan auch nicht die große Aufmerksamkeit von allen jetzt bekommen. Es muss leider halt meist ein größeres Ziel dahinter sein, dass sich das Investment in die APIs lohnt. Kann ich in einem Markt damit etwas erreichen oder nicht. Dieses Politikum spielt da eben stark rein. Auch wenn es aus Entwicklersicht scheiße ist, wenn die großen sich umentscheiden, aber so agieren ja hier Firmen nach wirtschaftlichen Kriterien. Das gute bei Khronos ist ja, das man trotz dieses Hintergrunds dennoch technisch gut zusammenarbeitet bei design etc.

Badesalz

2019-07-28, 08:59:06

Ich meine das ernst, der Erfolg einer offenen api kann ja nicht der Verantwortung eines Herstellers allein auferlegt werden. Die auffallend schlechtere Leistung ist nicht den APIs geschuldet. OpenCL 2.0 brachte man jetzt (wohl) mit RTX.
Für sowas braucht man kein Mitglied bei Khronos sein...

edit:
OpenCL ist eine ähnliche Story wie vor RTX mit DX12. Nur ausgeprägter ;)

pixeljetstream

2019-07-28, 09:47:35

Wir leisten sehr viel in Khronos, nur weil wir in einer api nicht an vorderster Front waren, haben wir es nun nicht verdient? Ich benutze Mal das wir weil ich selbst an Meetings teilnehme und weiß was hinter den Kulissen abgeht, welche Mitglieder überhaupt und wie zahlreich erscheinen. Du richtest ohne einen Einblick zu haben weil es in das Bild passt was Du von der Firma habt. Das mache ich Dir auch nicht direkt zum Vorwurf, weil all das ja hinter NDA Mauern passiert, aber ich hoffe ich bin in meiner Darstellung sachlich genug.

Das eine proprietäre api wie cuda, die als offline Compiler erschaffen wurde (im Gegensatz zum ersten CL), wo man alle Repräsentationen in der hand hat, erstmal flotter ist, sollte einleuchten. Der Rest ist normale Entwicklung es wird soviel investiert wie es der Markt verlangt. Sobald mehr Druck da ist, eine api relevanter wird, ist auch mehr Budget da. Das ist imo normales wirtschaften, was sich bei den anderen Firmen nicht unterscheidet. Irgendwer ist immer der letzte mit einer Version, oder langsamer etc.

Wir sind bei GL und Vulkan immer die ersten mit Features zu neuen Versionen, wir haben als ihv afaik die meisten contributor für neue features, conformance etc.

Heißt das nun die anderen Firmen sollen dort alle raus? Wo ist hier der Realitätsanspruch deinerseits, dass alle Firmen für sich die richtige Balance beim Investment finden müssen. Das ist auch wieder etwas was Khronos recht gut löst, die Mitgliedschaft ist relativ günstig, stimmberechtigt ist wer sich an den Meetings beteiligt.

Badesalz

2019-07-28, 10:30:04

Ich bin da einmal ulkig böse: Viel leisten, heisst ja nicht pauschal, viel Gutes leisten ;) Man kann die Leute mit contributions auch zuschei..., so daß schon wieder etwas nicht finalized wird, weil mal wieder contributions durch die evaluations müssen, um dann zu merken, die Art wie es erledigt werden soll ist für die eigene Architektur eher kontraproduktiv.
(aber das ist wie gesagt nur ein böser Joke ;))

Sonst finde ich, wenn NV nicht genug Gutes für sich leisten würde, wären sie nicht da wo sie aktuell sind. Das sollten auch andere Fanboys anerkennen.
Allerdings wird das mit dem GoodBoy bei NV nicht mehr funktionieren. Sie leben das "economy is a war" schon zu lange ein Stück offensichtlicher als andere in dem Sektor...

Was OpenCL angeht hatte vor paar Jahren ich alleine und persönlich schon 2 Firmen an der Strippe die lieber OpenCL fahren. Die haben in ihrem Markt nämlich einen spürbaren Anteil von Kunden mit APUs und das ist Intel und AMD.
Deren Coder wären gerne auf 2.0 gegangen, aber es war/ist trotzdem nicht wirtschaftlich genug für sie, auf Desktops NV GPUs auszuschliessen. So lief und läuft das bei denen weiterhin auf 1.2.
Das ist 1x eine Bude für Mediadaten und 1x eine aus dem industrie-maschinellen Umfeld.

Wenn was im November 2013 fertig ist, kann man es sehr wohl spätestens im September 2015 bringen, wenn die Mitbewerber es im September 2014 hinbekommen. Praktisch also, interessieren die vielen Contributions an der Stelle nen Shice. So einen waschechten feuchten Dreck interessiert das.

Bevor ihr also noch und nöcher mal wieder mit neuen Ideen auftaucht, lasst erstmal stecken und macht endlich etwas fertig was längst hätte fertig sein sollen. 2.0 für Pascal wäre sowas -> Und zwar, und eben, in einer Form, in der ein Coder nicht erstmal 2 Wochen damit verbringen muss um rauszufinden, ob sein Code überhaupt läuft und ob der Umstieg auf 2.0 überhaupt etwas bringt. Wo es bei den anderen glasklar ist.
Thx.

pixeljetstream

2019-07-28, 11:19:51

Ja für kleinere Firmen ist das doof ohne Zweifel. Die großen können mehr Druck generieren und bekommen direkt Hilfe. Wie du jetzt schreibst agieren die Firmen in dem Sektor halt eher "grau" Mal heller Mal dunkler, wegen der komplexen Verhältnisse untereinander. Ich glaube die Motivation an 2.0 kommt nun eher von Automotive und für Tegra, wo man selbst unter die integrated Kategorie fällt, weniger für Desktop/Workstation. Zumindest höre ich das in dem Umfeld seid Metal kaum.

Allerdings sehe ich nicht warum wir in vk nun runterschalten sollten, wegen CL. Das sind unterschiedliche Teams, APIs etc. Oder war das auch eher im Scherz gemeint.

Meine persönliche Meinung ist dass VK CL in Workstation/Desktop ersetzen sollte als runtime, weil meist eh das Ergebnis visuell aufbereitet wird, und man sich dann den grausigen interop spart. Aus der Sicht bin ich eher für die Investition rund um vulkan. Auch weil es mit Google und Valve zwei Große gibt die auch auf die api setzen und es somit mehr Planungssicherheit gibt.

Badesalz

2019-07-28, 11:55:38

Das ist ok. Ich mag und honoriere eine ehrliche unbefangene Meinung. Egal ob es mir in den Kram passt oder nicht. Entsprechend stehe ich auch zum Gegensätzlichem ;)

Allerdings klingt das schon ziemlich eigen, wenn ich höre - die Blumen zu Seite geschoben - daß man sich an etwas aktiv beteiliegt, und das mit einem wie man wohl meint erwähnenswerten Aufwand bzw. Egagement, die Umsetzung dessen aber davon abhängig macht, wie Schwergewichte am Markt zum Zeitpunkt jeweils so drücken.

Einerseits mit einer weiteren Presentation möglichst charismatisch und effektwirksam den nächsten Heil für alle predigen, anschliessend die kleinen ignorieren. Ich verkneif mir dann mal einen mit Jokes gespickten Vergleich zum Christentum im Mittelalter...

Man liest sich.

aufkrawall

2019-07-28, 12:23:33

Wir sind bei GL und Vulkan immer die ersten mit Features zu neuen Versionen

Für Entwickler vielleicht, aber für Consumer ist das auch egal (hier war AMD btw. schneller mit Vulkan 1.1). Und von Features kann ich mir als Kunde auch nichts kaufen, wenn Nvidia im Fall von Doom oder World War Z Monate braucht, um die Vulkan-Performance irgendwie im Treiber zu "fixen".

Außerdem scheint die Zusammenarbeit mit Nvidia bei GL-Spielen so einige Male den Standard aufgeweicht zu haben, indem Entwickler offenbar zum Nutzen undefinierten Verhaltens motiviert werden:
https://bugs.freedesktop.org/show_bug.cgi?id=66067#c34
Solche Fälle gibts sogar mit D3D11 :freak: : https://github.com/doitsujin/dxvk/issues/777#issuecomment-461988174
Warum dreht sich das immer nur um Nvidia, oder gibts auch gegenteilige Beispiele? :rolleyes:

Quintessenz: Der gute Support von Nvidia kommt nicht selten mit einer versteckten Giftpille daher.

pixeljetstream

2019-07-28, 12:58:51

Public hatten wir auch 1.1 am release tag
https://developer.nvidia.com/vulkan-driver

In beiden Links lese ich dass die proprietären Treiber von AMD auch workarounds haben? Es gibt viele solche workarounds, sogar in vulkan gibt es die schon, weil Titel mit Fehlern shippen. Man gibt den Entwicklern bescheid und macht nen workaround im Treiber. Selbst Carmack hat sich dafür entschuldigt, dass er in quake nen Fehler hatte wo alle Hersteller nen workaround bastelten und auf Twitter äußerten sich auch andere ;)
Der Treiber ist die letzte Instanz die nen work around machen kann. Imo macht ein Finger zeigen wenig Sinn, Fehler passieren, also muss man sich arrangieren.

aufkrawall

2019-07-28, 13:08:03

Der AMD Linux-Treiber war so schlecht, dass jeder Nvidia verwendet hat und der NV-Treiber somit der "defakto-Standard" war. Wenn jemand also die Möglichkeit gehabt hätte, Dinge gerade zu rücken, dann NV.
Das HotS-Problem (ich meine nicht das mit den Streifen-Artefakten) gibts btw. bis heute noch, sieht nur mit NV D3D11 (und DXVK) "korrekt" aus.

iuno

2019-07-28, 16:07:43

Ich meine das ernst, der Erfolg einer offenen api kann ja nicht der Verantwortung eines Herstellers allein auferlegt werden. Hätten andere in größerem Maße investiert oder hätte einer der großen (MS, apple, Google) es für wichtig empfunden hätte es sich NV nicht leisten können hier nicht so viel zu machen, der Markt regelt das. Und die Geschichte gibt der Entscheidung ja Recht, Apple hat es aufgegeben, Khronos selbst fördert nun Projekte cl mit Vulkan zu ersetzen.
Die Verantwortung muss Nvidia auch keiner auferlegen. Die hat man ganz automatisch inne, wenn man praktisch alle Workstations, praktisch alle HPC Installationen und einen ueberwaeltigenden Anteil der Consumer bedient.

Du tust hier so, als waere Nichtstun keine Haltung. Als haette Nvidia alles richtig gemacht, indem man sich zurueckgelehnt und erstmal abgewartet hat. Das ist aber nicht passiert, sondern es fand ein aktives Blockieren statt. Nvidia war mit vertreten, als man OpenCL beschlossen hat, hat es dann aber nicht umgesetzt. Wenn *der* relevante Hardwarehersteller dann nicht mitmacht, natuerlich bekommt die API dann keine Relevanz.

Ich verstehe nicht warum in der Angelegenheit es NV dermaßen nachgetragen wird nur weil sie in der Sache nicht den Geldhahn aufdrehten sondern sehen wollten was passiert und was der Rest macht.
Was passiert, wenn Nvidia die anderen erstmal machen laesst und dann mal schaut, sieht man bei GBM vs. EGLStreams. :rolleyes:

Es muss leider halt meist ein größeres Ziel dahinter sein, dass sich das Investment in die APIs lohnt. Kann ich in einem Markt damit etwas erreichen oder nicht. Dieses Politikum spielt da eben stark rein. Auch wenn es aus Entwicklersicht scheiße ist, wenn die großen sich umentscheiden, aber so agieren ja hier Firmen nach wirtschaftlichen Kriterien.
Es gibt hinreichend Unternehmen, die wirtschaftlich und trotzdem nicht so destruktiv arbeiten wie Nvidia. Das eine schliesst das andere nicht aus. Wirtschaftlich zu arbeiten heisst nicht, dass der Gewinn ueber allem steht und alles andere scheissegal ist, auch wenn einige das so interpretieren.

Wir sind bei GL und Vulkan immer die ersten mit Features zu neuen Versionen, wir haben als ihv afaik die meisten contributor für neue features, conformance etc.
Herzlichen Glueckwunsch. Ihr habt ja auch mehr Mitarbeiter und ein viel fokussierteres Geschaeftsfeld als z.B. AMD. Von den anderen Beteiligten aus dem ARM Sektor fangen wir lieber gar nicht erst an.

aufkrawall

2019-07-28, 16:18:41

Was passiert, wenn Nvidia die anderen erstmal machen laesst und dann mal schaut, sieht man bei GBM vs. EGLStreams. :rolleyes:

War von Intel, Google und Mesa, das ist doch nicht gut genug für NV. :)

Ganon

2019-07-28, 17:18:49

Es ist ja nun hinreichend bekannt, dass Nvidia in Sachen API Implementierung nicht gerade Glanzleistungen abliefert. OpenGL heißt nicht umsonst gerne NVidiaGL, OpenCL kriegt kaum Support, offene Videobeschleunigungs-APIs unter Linux werden durch proprietäre Lösungen ersetzt, Eingliederung ins bestehende OpenSource Umfeld quasi nicht vorhanden...

Immerhin lässt Vulkan durch die API Validation Layers und intensivere Validierungen nicht soooo viel Spielraum und wenn dann nicht lange. Auch ist die Kommunikation und Einwirkung von außen etwas mehr vorhanden...

Ich meine das ernst, der Erfolg einer offenen api kann ja nicht der Verantwortung eines Herstellers allein auferlegt werden.

Das kannst du sagen, wenn der Markt 33 / 33 / 33 % aufgeteilt wäre. Realistisch ist der Markt aber eher 90% / Rest aufgeteilt. Und ich sagte es dir schon einmal. Die Leute haben nach OpenCL 1.2 geschrien (!) damals Richtung NVidia... und du kommst dann mit "War halt kein Bedarf da" :ugly: Und da braucht man auch nicht sagen "Hatten die anderen ja auch nicht"... Doch, hatten sie, nur der 90%ige Marktführer nicht. Bei OpenCL 2.x war der Zug eh schon lange abgefahren.

pixeljetstream

2019-07-28, 20:13:14

@Ganon ich sehe halt in solchen Fragen weniger nicht nur die Hardwarehersteller sondern eben auch die Platformhalter in der Pflicht was das Öksystem einer api angeht, die bestimmen ja welche apis überhaupt laufen, sponsoren events, tools, samples etc. Aber Du hast Recht bis CL 1.2 hätte man schon gehen können. Erst danach war ja der Apple-Ausstieg.

@Iuno mein Hinweis auf die Arbeit in den Standards war ja eine Antwort darauf, dass wir in den standards negative Arbeit leisten, und aus khronos sollten. Das war nicht als "alles super" gedacht, sondern dass es diese Seite halt auch gibt. Was ich in meiner täglichen Arbeit erlebe ist halt nicht "destruktiv", Forschung neuer Technologie, der Dialog mit Entwicklern, oder die Interaktion in Khronos, Konferenzen etc...
Deswegen fehlt mir hier in der Diskussion die Distanz, die Leute die sich in Khronos engagieren sind meine unittelbaren Kollegen. Andererseits denke ich mir bei einigen Antworten, dass anderen die Nähe / konkreten Details hinter den NDA Mauern fehlen und dann (aus meiner Sicht) zu vereinfacht argumentiert wird (schwarz/weiß). Wobei wenn ich es dann selbst aufs big picture reduziere (der wettkampf der großen ist nicht kontroversfrei) ist's auch nicht besser.

Badesalz

2019-07-28, 20:32:12

Die Verantwortung muss Nvidia auch keiner auferlegen. Die hat man ganz automatisch inne, wenn man praktisch alle Workstations, praktisch alle HPC Installationen und einen ueberwaeltigenden Anteil der Consumer bedient.Ähm... Sorry aber wenn man das so nimmt, dann macht NV genug für diese Leute. Cuda gibts nicht nur für Windows, sondern auch für Linux.

iuno

2019-07-28, 20:56:36

Natuerlich gibt es CUDA fuer Linux, es waere ja auch ein riesiger Schaden fuer Nvidia, wenn das nicht der Fall waere, weil das das einzig relevante OS fuer HPC ist. Ich verstehe gerade nicht, wie das in die Diskussion passt.

Badesalz

2019-07-28, 21:08:49

(sehe Edit)
(Ah. Ok. Dann verstehe ich nicht was das in #69 als Entgegnung bringen sollte. Mit eben dem zitierten Absatz. So gesehen, nimmt Nvidia seine Verpflichtungen damit auch wahr. Mit Cuda, falls man GPGPU machen will. Unter Win wie Linux. Hast du dich damit nicht Schachmatt gesetzt oder was sollte das zum Ausdruck bringen?
Oder war das keine negative Kritik? Weil wenn ja, dann sollte man die schon so ausformulieren, daß der Gegenüber sich nicht darüber freut... :confused:)

Der zweite Absatz dagegen ist RICHTIG. Genau so ist es. Wenn sie nicht dabei wären, wäre es bestenfalls ein Boykott. Oder, Nichtbeachtung. Ist ja jedem selbst überlassen. Sie hätten halt immernoch und weiterhin Cuda.
Da sie aber meinten mitzumischen, waren/sind deren Pseudoumsetzungen für mich einfach nur eine Verarsche. Darüber steht aber auch bisschen was in #64. Ich schätze damit ist das auch allen Beteiliegten soweit bewusst. Braucht man 2019 keinem (mehr) erzählen.

EDIT:
Ah (faceplam) Ja. Den Kontext jetzt doch verstanden. Ja, da hast du schon teils Recht, aber mit DER Marktmacht, damit also alle anderen solcher Konkurrenz ausgeliefert... Wer hätte sowas nicht erwartet? Sie sind in einem Gremium dabei, dessen Erfolg Teile ihres eigenen Erfolgs gefährdet. Das ist klar, daß man da nichts ausser Knüppel erwarten kann, die zwischen deine Beine zielen.
Das denke ich ist allen anderen Khronosmitgliedern auch soweit immer bewusst, daß dies noch dauern wird und man hier keine reale Schützenhilfe erwarten kann.

Man wird das weiter mit-trotz NV entwickeln. Wobei NV jetzt doch mehr dabei sein möchte als davor, weil auch Intel das ernster wahrnimmt. Intel will ja diesmal wirklich ernst ins GPGPU. Das wird Lösungen und Anwendungen in GPGPU nach sich ziehen bzw. bringen, die nicht Cuda sein werden, und da will NV vorsichtshalber auch ernsthafter mitmischen als davor bei OpenCL.
Wenn Vulkan + Spir-V zusammengemixt werden, und die Werkzeugkästen auch noch wenigstens halbwegs ok sind, dann darf das Cuda was vom Markt abluchsen, nicht aber zuviel der Marktes für NV GPUs. Man will da also gleichwertig fit sein, für den Fall der Fälle.

Andere Gründe gibt es dafür nicht. Lasst euch nichts erzählen. Man will für euch immer nur die besten "€€€€" Lösungen anbieten ;)

Gast

2019-07-29, 18:32:32

Was ich in meiner täglichen Arbeit erlebe ist halt nicht "destruktiv", Forschung neuer Technologie, der Dialog mit Entwicklern, oder die Interaktion in Khronos, Konferenzen etc...

So ist es eben wenn Leute bei Dingen anfangen mitzureden von denen sie keine Ahnung haben (können!)

Mancko

2019-07-29, 20:28:05

(sehe Edit)
Andere Gründe gibt es dafür nicht. Lasst euch nichts erzählen. Man will für euch immer nur die besten "€€€€" Lösungen anbieten ;)

Wie alle anderen halt auch. Einen anderen Auftrag haben diese Unternehmen auch gar nicht.

Badesalz

2019-07-29, 20:30:51

Und nu? Bisschen arg aus dem Kontext weggebrochen oder?

Gast

2019-08-01, 19:49:26

Dann nimm doch mal deine NV Fanboy Brille ab, und schau dir die Fakten an. Bei AI unterstützen inzwischen alle relavanten Frameworks auch OpenCL, quasi alle Autonomen Fahrzeuge fahren mit OpenCL, weil sich die Automobilhersteller großflächig auf SyCL als Framework geeinigt haben. Da nutzt niemand Cuda und wenn man sich mit dem Thema beschäftigt hätte, dann wüsste man das auch. Aber das hast du vermutlich noch nie gemacht, weil du gar kein Interesse daran hast von Cuda zu wechseln (wenn du überhaupt Cuda nutzt, was auch schon zweifelhaft ist).
Insofern ist deine Behauptung einfach falsch.

Gut getrollt Löwe!

"alle relevanten AI-Frameworks unterstützen OpenCL" - ja ne klar:
https://towardsdatascience.com/on-the-state-of-deep-learning-outside-of-cudas-walled-garden-d88c8bbb4342
Bei Tensorflow und PyTorch das gleiche trübe Bild

Tensorflow locked the issue as “too heated” and limited conversation to collaborators on 26.02.2019. There are 541 comments and no assignee.

Here is a statement from a contributor from the Facebook AI Research team:
We officially are not planning any OpenCL work because:
AMD itself seems to be moving towards HIP / GPUOpen which has a CUDA transpiler (and they’ve done some work on transpiling Torch’s backend). Intel is moving it’s speed and optimization value into MKLDNN. Generic OpenCL support has strictly worse performance than using CUDA/HIP/MKLDNN where appropriate.

"Die Automobilhersteller habe sich großflächig auf SyCL als Framework geeinigt"
Ja und? Ich schrieb doch oben, für die Verbreitung kommt es auf das Ökosystem rundherum an. Die wichtige Frage ist: Womit wird entwickelt? Pixeljetstream hat das oben ja ganz gut dargestellt, der Wert der großen Engines (Unreal,Unity) liegt in deren Tools und dem rundherum. Und da sieht es für OpenCL halt nicht gut aus. Im Bereich AI schon gar nicht. Wenn man erstmal irgendwelche epxerimentellen packages selber kompilieren muss damit dann vielleicht Tensorflow mit OpenCL läuft wird das nichts mehr. ich finde ja schon die offizielle Installationsanleitung von Tensorflow für die cuda unterstützung grenzwertig:
https://www.tensorflow.org/install/gpu
Und da steht immerhin google offiziell dahinter.

Und natürlich kann die Autoindustrie fertig trainierte Netze nehmen und die auf irgendeinem coprozessor mit einer hauseigenen Programmiersprache im Auto laufen lassen. Interessiert dann halt außerhalb der jeweiligen Firma eher weniger und wird für die Frage ob sich Cuda oder OpenCL durchsetzt einen ziemlich überschaubaren Effekt haben... ;)
Im übrigen:
https://trends.google.com/trends/explore?date=today%205-y&q=sycl,cudnn

Ich hatte übrigens oben geschrieben ich wäre der erste der es begrüßt wenn man nicht mehr auf nvidia/cuda festgenagelt ist, und das meine ich ernst. Die NV Fanboy Brille kannst du also ruhig stecken lassen.

Badesalz

2019-08-03, 09:49:26

So nebenbei...
Ich finds recht themabozogen (allgemein). FlopCL ist auch dafür gut um zu vergleichen wie sich OC auf OpenCL/(Cuda) auswirkt. Zuweilen interessant ;)
(FMAD)

http://olab.is.s.u-tokyo.ac.jp/~kamil.rocki/projects.html

danarcho

2019-08-03, 13:31:38

Wir sind bei GL und Vulkan immer die ersten mit Features zu neuen Versionen, wir haben als ihv afaik die meisten contributor für neue features, conformance etc.
Außer der Totalausfall mit VK_NV_glsl_shader macht ihr ganz solide Arbeit bei Vulkan, soweit ich das beurteilen kann.

Meine persönliche Meinung ist dass VK CL in Workstation/Desktop ersetzen sollte als runtime, weil meist eh das Ergebnis visuell aufbereitet wird, und man sich dann den grausigen interop spart. Aus der Sicht bin ich eher für die Investition rund um vulkan. Auch weil es mit Google und Valve zwei Große gibt die auch auf die api setzen und es somit mehr Planungssicherheit gibt.
Ich denke, das wird, wenn überhaupt, eine optionale EXT, da man nicht davon ausgehen kann, dass die mobile Sachen da mitziehen. Aber das ist doch mal eine interessante Frage: Würdet ihr eine Vulkan EXT implementieren, die beispielsweise OpenCL C++/SPIR-V compute kernel erlaubt (mit entsprechenden API calls um die auszuführen natürlich)?

pixeljetstream

2019-08-03, 15:02:12

Ich kann nicht für die Firma da sprechen, aber persönlich denke ich lieber eine api zu haben, wo dann auch noch andere Fähigkeiten drin sind, ist viel besser. Und imo spricht unter vulkan auch nix gegen devices die nur Compute exposen.

Sind zum Teil halt auch andere Märkte, daher meine Einschränkung auf Desktop/Workstation. Aber unter Apple werden die Apps alles mit Metal machen, ergo sollten die anderen Platformen auch nur eine api haben. Aber mein Fokus sind halt CAD/DCC/Medical etc.

Die glsl extension hätte gleich NVX genannt werden sollen weil sie temporär war. Es hat aber für die ersten Gehversuche in vulkan nicht geschadet imo, also diverse Partner fanden das gut, allen war bewusst dass man auf spir-v gehen wird, aber so konnte man schnell in einer GL Applikation was machen. Für uns war es praktisch weil man so auch zwei unterschiedliche Compiler direkt vergleichen konnte. Alle modernen APIs nutzen NVVM was auch in irgendeinem GDC Vortrag erklärt wurde. Während der pure glsl Pfad durch den legacy Compiler ging. Dass man nun alles in spir-v first oder wie bei raytracing exclusive macht dauerte halt bissl da intern umzustellen.

Badesalz

2019-08-12, 09:30:32

Ich kann nicht für die Firma da sprechen, aber persönlich denke ich lieber eine api zu haben, wo dann auch noch andere Fähigkeiten drin sind, ist viel besser. Und imo spricht unter vulkan auch nix gegen devices die nur Compute exposen.
@all
Wo ich das grad lese. Laufen die ganzen dafür sinnvollen Sachen wie zb. Xilinx Alveo auch unter Vulcan? Oder wie wird sowas angesprochen?

iuno

2019-08-12, 10:31:29

Nicht, solange der Hersteller keinen Vulkan-Treiber baut.
Wie er aber gesagt hat, spricht grundsaetzlich nichts dagegen. Dann wuerde dieses Geraet halt nur Compute- und keine Grafik-Queues anbieten. Dann wuerde man "ganz normal" eine compute Pipeline erstellen. Fuer OpenCL C -> SPIR-V gibt's clspv, was eine Portierung vereinfachen wuerde. Ansonsten koennte man natuerlich auch compute shader in glsl schreiben.

Badesalz

2019-08-12, 10:41:28

Die Frage ist wie das realisiert IST. Nicht was alles möglich wäre ;)
https://www.golem.de/news/alveo-u50-xilinx-bringt-fpga-beschleuniger-als-low-profile-karte-1908-143054.html

iuno

2019-08-12, 11:57:24

Die Frage ist wie das realisiert IST.
Was denn?
Da wird kein Wort ueber Vulkan verloren.

Ganon

2019-08-12, 13:00:59

Die Frage ist wie das realisiert IST.

In der Regel programmiert man Vektor-Karten und FPGA-Boards separat. Der Workflow ist halt ein anderer und darum ergibt die Frage nach Vulkan nicht viel Sinn.
Bei einer GPU lädst du zur Laufzeit beliebigen Code in die GPU und die macht das dann ganz fröhlich. Das machst du per OpenCL oder Vulkan.

Beim FPGA Board kannst du zwar ggf. mittels OpenCL-C einen Algorithmus definieren, dieser wird dann aber nicht in den FPGA geladen und dann ausgeführt, sondern die Suite erstellt einen FPGA Microcode, den du dann ins FPGA Board lädst und mit der Beschaltung die Karte startest.

Anders ausgedrückt:
Bei einer GPU benutzt du die Komponenten einer GPU, um deinen beliebigen Code auszuführen.
Bei einem FPGA "baust" du dir deinen speziellen Beschleuniger für einen einzelnen Anwendungsfall und ohne Reset wird die Karte dann auch nichts anderes machen als das was der letzte Microcode ihr aufgetragen hat.

Badesalz

2019-08-12, 13:25:37

Ah... Danke. Soweit klar. Das ist die Vorbereitung auf die Aufgabe.

Irgendwie muss man seinen Dataschnippel aber in so eine Karte auch gebeamt bekommen und das Ergebnis auch empfangen können. Ich wüsste keine Schnittstellen dafür (?) Daher die Verwirrung. Läuft das rein über den eigenen Treiber des Herstellers und damit muss man auch explizit auf dessen Schnittstellen/APIs seine Anwendung programmieren?

iuno

2019-08-12, 13:47:50

Wenn wir bei OpenCL bleiben, dann gibt's da auch mit FPGA eine runtime und ein host Programm, was dann letztlich mit dem Geraet kommuniziert. Dafuer ist der Standard ja da und ansonsten wuerde man nicht OpenCL draufschreiben.

Darueber hinaus gibt es fuer solche Hardware dann sicher auch herstellereigene Schnittstellen, ja. Schau doch einfach mal beim Hersteller nach(1 (https://www.xilinx.com/products/design-tools/software-zone/sdaccel.html#overview), 2 (https://www.xilinx.com/publications/solution-briefs/sdaccel-solution-brief.pdf)).

gmb

2020-05-23, 17:30:37

Khronos Announces OpenCL 3.0: Hitting the Reset Button on Compute Frameworks (https://www.anandtech.com/show/15746/opencl-30-announced-hitting-reset-on-compute-frameworks)

OpenCL is in something of a precarious state on the PC desktop, its original home. Over a decade since its inception, the GPU computing ecosystem is fracturing: NVIDIA’s interest is tempered by the fact that they already have their very successful CUDA API, AMD’s OpenCL drivers are a mess, Apple has deprecated OpenCL and is moving to its own proprietary Metal API. The only vendor who seems to have a real interest in OpenCL at this time is strangely enough Intel.

Ist AMDs OpenCL Treiber wirklich ein mess?

Vorläufige Spezifikationen für OpenCL 3.0 veröffentlicht (https://www.heise.de/developer/meldung/Vorlaeufige-Spezifikationen-fuer-OpenCL-3-0-veroeffentlicht-4710463.html)

Das macht die Adaption einfacher:

Funktionen, die über die von Version 1.2 hinausgehen, werden mit OpenCL 3.0 optional.

OpenCL 2.x Features sind in der neuen Version nur noch optional, für Nvidia macht es das einfacher. Aber mal abwarten, vielleicht hat Nvidia eh kein Interesse daran, dann wird das Zurückrudern in Version 3.0 auch nicht viel Belebung reinbringen. Derweil unterstützt Intels Open Source (https://github.com/intel/compute-runtime/commit/41fef1c71e63eb46cce6f6d0db3af31b63797170) Treiber schon jetzt Version 3.0 für Tigerlake.

Ganon

2020-05-23, 19:34:12

Unsinniges Release meiner Meinung nach und dient rein zur Augenwischerei. Dank Nvidia kann man weiterhin nicht sinnvoll OpenCL 2.x Features benutzen und jetzt quasi einfach OpenCL 1.2 in 3.0 umbenennen ändert an der Situation exakt nichts :ugly:

Modernes OpenCL ist und bleibt einfach ein Papiertiger.

Badesalz

2020-05-23, 22:50:55

Sie stellen sich imho schon recht dämlich an damit, imho. Muss man denen lassen. Im Gegensatz zu OpenGL/Vulcan ist das Ding ein fortlaufendes Drama... :mad:

Andererseits, alles wovon man diesbezüglich daheim profitieren könnte, ist halt schon ab OpenGL 3.3/(4.0) und später drin. Und eben in OpenCL 1.2. Wenn das mal wer wirklich nutzen würde.

p.s.:
Ich hab relativ viel mit dem 1.2 Set auf Polaris und dem 18.3.4 experimentiert und da war jedenfalls überhaupt nichts "mess" dran. Das hat sich was das Ergebnis wie auch Speed angeht immer so verhalten wie angedacht. Um nicht zu sagen, mustergültig :)

edit:
So in der Art
https://www.youtube.com/watch?v=EydeXZqJvGA

In Cuda 35% mehr Speed in der Hälfte der Proggerzeit? Möglich. Allerdings bleibt das obige, immernoch der Vergleich zwischen einer CPU und einer GPU. DAS könnte man ruhig so oder so mitnehmen, weil das dann auf NV auch nicht schlechter läuft.

Die Leute haben aber grundsätzlich keine Ahnung und/oder keine Zeit sich in derartiges einzuarbeiten. Die kriegen nichtmal hin Jpeg-Thumbs auf der Graka zu rechnen, optimieren lieber 4 Monate lang weiter ihren geliebten SSE2-Kode händisch. Den sie aber nur auf 1 Kern fahren können...
Kannste machen nix. Geschweige etwas in OpenCL zu basteln.