[...]
@Eisenfaust! D.h. man kann GPGPUs zum Rechnen aktuell nicht unter *BSD nutzen?
[...]
Das Schwert ist zweischneidig.
Nutzt man "klassische" Hacks unter OpenGL, also die Abstraktion eines mathematiswchen problems in der formalen Sprache der OpenGL Implementation, kann man auch unter FreeBSD die GPU bedingt zum Rechnen bewegen. Da aber das OpenGL-Backend wiederum abhängig von der Nutzung der Beschleunigungen in der Hardware abhangt, geht das, meines Wissens, nur sinnvoll mit den binären Treibern von nVidia. Ich habe mich eine Weile damit beschäftigt, diese Option aber schnell wieder verworfen, weil der Aufwand und der Nutzen in keinem vernünftigen Verhältnis steht.
Von Seiten PathScale wird eine Compiler Suite angeboten, die sich "Enzo2011" nennt. Zur GPU-gestützten Parallelisierung kommt hier HMPP, eine Compiler Erweiterung ähnlich OpenMP, ein API. HMPP und OpenACC sind "offene" Standards, die in den Quellcode mittels #pragma-Anweisungen eingebaut werden. PathScale garantiert die Funktion nur mit neueren TESLA Architekturen, die Compiler-Lizenz ist üppig und maschinengebunden. Wir konnten uns jedenfalls nicht zu dieser Investition durchringen, obwohl HMPP/OpenACC eine phantastische Möglichkeit bietet, bestehenden Code auch auf einer GPU ausführen zu lassen.
Seit einigen Jahren geistert nun die Mähr von der Verwendbarkeit der CUDA Binaries unter FreeBSDs Linuxulator, hierzu wird auch eine bereits seit langem völlig veraltete Anleitung im Netz angeboten. Diese "Lösung" ist aus mehreren Gründen nicht in Betracht zu ziehen, zumindest aus unserer Sicht.
Einerseits muß man den Code auf einer funktionierenden Linux-Plattform compilieren oder Cross-compilieren. Die Plattform muß dann 32bittig sein, weil der Linuxulator nur 32bittig arbeitet. Für unseren Modell-Code, der durchweg 64bittig arbeitet, ein Problem. Ich optimiere keinen Modell-Code auf 64Bit, um ihn dann mit angezogener Handbremse auf einem 32Bit System mit all seinen speicherlimitierenden Nachteilen laufen zu lassen. Zudem muß man, um vernünftig entwickeln und testen zu können, eine komplette Linux 32Bit Infrastruktur einrichten - meiner Meinung nach völliger Unsinn, denn ich benutze dann lieber ein wesentlich moderneres und schnelleres 64Bit Linux nativ.
Andererseits haben wir (und insbesondere ich) es nie geschafft, auf aktuellen FreeBSD Systemen (FBSD 9.0-STABLE, FBSD 10.0-CURRENT) CUDA und insbesondere OpenCL lauffähig zu machen. Der Aufwand ist einfach zu groß und ich bezweifele, daß es überhaupt geht - schon im Hinblick auf die 32-64-Bit-Problematik.
Es mag sein, daß es "irgendwie" gehen mag, es ist aber gemessen am Aufwand und letztlichen Ergebnis eher als Unsinn abzutun und völlig impraktikabel.
Wir entwickeln und forschen mitlerweile auf Linux mit TESLA Karten und nutzen OpenCL. openCL hat nach meiner Meinung den weitaus größeren Vorteil, CUDA ist zu sehr auf nVidia Karten festgelegt (wie auch PathScales ENZO-Lösung). Mal von Instabilitaten und unsauberen Verhaltensweisen des AMD SDK abgesehen, zeigen die aktuellen GCN-basierten AMD Karten einen gigantischen Leistungsvorteil gegenüber nVidia Karten, wenn es um doppelt genaue Fließkommaarithmetik geht. Eine 500-Euro teure AMD Karte nimmt es spielend mit einer fast zehnfach teureren TESLA Karte auf (die gröste TESLA, die wir derzeit haben, ist eine M2075 mit 6GB RAM). Zudem ist das Intel-SDK, ebenfalls OpenCL-fähig, wesentlich besser.
Diese Freiheiten lernt man schätzen mit der Zeit - und vermißt sie schmerzlich, wenn man den Blick von Linux wieder zurück auf FreeBSD wendet.
Was den OpenSource-Vorstoß PathScales betrifft, so kann ich sagen, daß ich vor zwei Jahren einmal Kontakt zu dieser Firma hatte und sich abzeichnete, daß es hier zu einem "Schritt in die richtige Richtung" kommen würde. Leider waren die Versprechungen aber vollmundiger als das Resultat - ich vermute, daß firmenpolitische Gründe zum Zurückrudern zwangen, denn PathScale kooperiert in Sachen HMPP/OpenACC über CAPS eng mit nVidia.
Daß nVidia keinen "Bedarf" auf Seiten der *BSD Linien sieht, halte ich für nicht haltbar. Gerade die Lizenzpolitik der BSD Systeme würde es Entwicklern viel einfacher machen, Produkte mit geschlossenen Quellen anzubieten - das ist Dank Linux und GPLv3 anders. Dennoch verstehe ich die Entwicklung nicht - sie erscheint mir als ein Paradoxon.
Letztlich, unter dem Strich, ist CUDA oder OpenCL NICHT mit FreeBSD verwendbar, zumindest wenn man ernsthaft HPC betreiben will. Neben eigens entwickleter Modellsoftware gibt es ja auch noch andere Bestrebungen softwareseitig, eine vorhandene GPU in den Rechenprozeß einzubeziehen. Auch kastriert eignen sich nVidias Graphikkarten hervorragend dazu, ich verwende zum Beispiel eine nVidia GTX570, wenn ich die TESLAs im hause nicht nutzen kann - nur verwende ich sie nicht unter FreeBSD.
Die GEGL-Bibliothek wird nun auf OpenCL erweitert, um graphische Operationen in GIMP zu beschelunigen. Filter profitieren ungeheuer von solchen Beschleunigungen! Blender, als nächstes Beispiel, beschleunigt mit Hilfe CUDA oder OpenCL (abhängig vom Treiber, unter Ubuntu kann ich mit Hilfe des nVidia 302.07-Treibers aber beides auswahlen). Der Zugewinn ist phänomenal! Wenn wir Präsentationen rechnen/rendern, die zwischen zwei und 10 Minuten lang sind und minimal HD-Qualität mit 25 BPS aufweisen sollen, ist eine GPU-Beschleunigung ein Segen. Zwar hält sich der Effekt der Beschleunigung in Grenzen, aber wenn man bedenkt, daß ein 2x 6-Kern XEON mit 2,8 GHz fast eine Woche für ein solches Video gerechnet hat und mit Zuschaltung der CUDA Erweiterung dann um den Faktor 3 - 6 beschleunigen konnte - das sind dann Zeiten, die man sehr, sehr deutlich spürt!
