Top10/Flop10 von HW-Komponenten?

Amin

Well-Known Member
Gibt es eigentlich eine Art Top 10 oder Flop 10 der best unterstützten Hardware-Komponenten?

Z.B. welche CPUs, welche Grafikchips, welche WLAN-Chips usw.?

Denn wenn man jetzt vor dem Kauf eines Computers steht, hat man z.B. die Qual der Wahl. Soll man lieber auf Intel-HD3000-Grafik oder AMD-RadeonHD-Grafik setzen? (nicht jeder braucht Nvidia-HighEnd-Grafik).

Ich finde, die entsprechende Information bzgl. *BSD ist wirklich nicht leicht zu finden...
 
Grundsätzlich gesagt hat sich in den letzten Jahren der Hardware-Support von FreeBSD drastisch verbessert. Das liegt einmal an wesentlich mehr Treibern, zum Anderen an immer generischerer Hardware. Als Beispiel gab es noch vor 7 Jahren diverse verschiedene Soundkarten auf dem Markt, selbst Onboard-Karten unterschieden sich zum Teil deutlich. Heute sind hingegen fast alles HDA-Karten, die sich mit einem Treiber ansprechen lassen. Ähnlich sieht es in fast allen anderen Bereichen aus, nur selten gibt es überhaupt noch mehr als zwei oder drei konkurrierende Architekturen, entsprechend weniger Treiber benötigt man. Wenn man heute einen Rechner kauft, sind die Chancen, dass FreeBSD alle Hardware greift, sehr hoch. Sicher über 90%.

Speziell für Prozessoren ist ein nie verschwindendes Gerücht, dass Betriebssysteme an Prozessoren angepasst werden müssen. Jedes x86/amd64-kompatible Betriebssystem sollte auf allen entsprechenden Prozessoren laufen. Außnahmen sind lediglich CPU, die die ISA eben nicht vollständig unterstützen. Der Klassiker sind die alten Geode-Prozessoren, die drastische Inkompatiblitäten aufweisen, um die man herumcoden muss. Das Betriebssystem muss allerdings unter Umständen angepasst werden, um neue Funktionen nutzen zu können. Wer zum Beispiel AVX möchte, benötigt einen Kernel mit entsprecher Funktionalität, sonst sind die Opcodes einfach nicht verfügbar.

WLAN ist eines der Problemfelder, was aber nicht zuletzt an einer großen Menge an Anbietern liegt, von dienen viele es nach wie vor nicht nötig haben ihre Spezifikation offen zu legen. Broadcom und Realtek sind unter allen Opensource-Systemen problematisch, die Palette reicht von "geht schlecht" (Linux) bis "gar nicht (FreeBSD). Gute Anbieter sind Atheros (Atheros schreibt seinen FreeBSD- und Linux-Treiber selbst, bzw. arbeitet eng mit den Entwicklern zusammen) und Intel. Ralink eingeschränkt ebenfalls, wobei es da auf die Bauserie angkommt.

Grafikkarten sind ein leidiges Thema. Ich bleibe dabei, dass Nvidia die beste Wahl ist. Und sie bauen nicht nur High-End-Karten, eine GT520 für unter 35 Euro ist zwar nicht unbedingt langsam, aber immerhin passiv gekühlt und nach heutigen Maßstäben für moderne Windows-Spiele weitgehend unbrauchbar. FreeBSD hat ja nun (ab 9.1) auch Unterstützung für alle Intel-GPU (inklusive Ivy Bridge), wobei es noch einige scharfe Kanten gibt. Von Radeon kann man derzeit leider nur abraten, da alle Karten nach der seeligen HD4000-Serie nicht unterstützt sind.
 
OK, wenn man also seinen Rechner (Desktop/Tower) selber zusammen stellt, kann man hier nicht viel falsch machen. Aber man muss halt wissen das man wohl ATI-Grafik meiden sollte. Und lieber zu Atheros-WLAN greift. Guter Richtwert.

Bei Laptops ist es aber nicht so leicht. Ich finde nämlich nie bei Notebooks die Angabe, welche WLAN-Chips verbaut sind. Die Bezeichnung der CPU und Grafikchips ist immer publik. Die angeblichen Spezifikationen auf den Laptop-Herstellerseiten sind nicht sehr aussagekräftig.
 
Auch ich habe mit Nvidia Grafikkarten schon seit Jahren die allerbesten Erfahrungen gemacht. Meine Geforce 9500 GT ist für meinen Arbeitsrechner ausreichend dimensioniert. Mein integrierter Soundchip 7.1 Kanal Sound Realtek ALC880 wird leider nicht richtig von freeBSD erkannt, obwohl es meineserachtens kein Exot ist. Bei dem Neukauf eines Rechners würde ich wohl auf den früheren Quasi Standard setzen und eine Soundblaster favorisieren. Mein Brenner PHILIPS DVDR1628P1 wird zwar richtig erkannt, aber das Brennen ist mir mit cdrecord immer noch nicht gelungen. Aber ich arbeite dran. Außerdem kommt mein Brenner nur noch selten zum Einsatz, Datensicherung erfolgt auf eine externe USB Platte.
 
Ich würde behaupten wenn man wirklich mal außerhalb von Windows arbeiten will kommt man um eine Nvidia Karte nicht herum. Man bekommt ja für alle gängigen Systeme Treiber wie Linux, FreeBSD, Solaris.

Bei Soundkarten habe ich die Erfahrung gemacht das Onboard Chips meist problemlos laufen. Bei pci/pci-e Soundkarten muss man schon aufpassen was für ein Chip dabei ist. Ich habe jetzt auch wieder eine nicht hda Karte da ich doch öfter auf Probleme wie Aussetzer bei Systemlast gestoßen bin. Mir kommt auch die Qualität bei günstigen Onboard Chips schlechter vor.

Aber im Prinzip kannst du mit Massenware nicht viel falsch machen. Probleme bekommst du meist bei unbekannten Geräten oder Sonderfälle wie Grafiktablets usb Grafik/Soundkarten. Einige Drucker sind auch problematisch.

Grüße
 
Wäre es nicht sinnvoll sowas in das BSDForen-Wiki aufzunehmen? Es muss ja nicht jeder Chip aufgeführt werden, aber eine FAQ wäre doch hilfreich? Diese paar Beiträge haben doch schon sehr viel nützliche Infos. Man müsste sie nur noch mal aufbereiten.

Evtl. wäre doch auch zusätzliche eine Auflistung von Chips hilfreich? Oder wird sowas schon von den BSDs dokumentiert?

Oder kann man eine solche Liste automatisiert aus den distributierten Treibern erzeugen lassen?
 
In die Flop 10 würde ich die diversen DVB-S PCI Karten ganz weit oben einreihen.
z.B. die Hauppauge WinTV Nexus-s mit SAA 7146 Chipsatz wird leider nicht von FreeBSD unterstützt.
 
WLAN ist eines der Problemfelder, was aber nicht zuletzt an einer großen Menge an Anbietern liegt, [...] Gute Anbieter sind Atheros (Atheros schreibt seinen FreeBSD- und Linux-Treiber selbst, bzw. arbeitet eng mit den Entwicklern zusammen) und Intel.

Letzteres kann ich nicht bestätigen. Meine Karte wird vom WPI-Treiber unterstützt und funktioniert mehr schlecht als Recht, insbesondere seit dem neuen wlan-geraffel mit den extra devices. Vorher liefs eigentlich rund, jetzt habe ich mit bestimmen Netzen immer Probleme, d.h. irgendwann kommen einfach keine Pakete mehr durch, obwohl ich nicht disconnected bin. Manchmal hilft ein up/down oder ein recreate von dem device, meistens aber nur ein Neustart. Sehr ärgerlich. Aber wie gesagt, ich glaube, das liegt an FreeBSD.
 
Ich muss zugeben, dass ich an wpi(4) gar nicht gedacht und nur iwn(4) im Blick hatte.
 
Bei mir landen die 64bit VIA Padlock CPUs in der Flop Liste.

Die CPUs von Via waren frueher mal x86 only (die neueren Nanos sind 64bit) und dementsprechend wurden die speziellen Features der Prozessoren (Hardware AES/SHA1/SHA256/RNG etc.) auch gecodet.

Auch die Performance ließ unter FreeBSD sehr zu wuenschen uebrig, da hatte ich mir von GELI und HMAC/SHA1 bzw. HMAC/SHA256 deutlich mehr erhofft.

Bis heute unterstuetzt kein freies OS die AES-CTR HW-Beschleunigung der Padlock CPUs…
 
stadtkind: OpenSSL nutzt AES-CTR das OS unabhängig. Der große Vorteil von Padlock gegenüber anderen HW-Cryptobeschleunigern ist unter anderem, das es keinen Kernelsupport braucht.
 
@stadtkind:
VIA cpu's sind im grunde nicht schlecht. Ich habe hier selbst eine VIA cpu (noch älteres Model) und klar für den Desktop sind die nicht optimal, aber z.B als NAS oder Homeserver mehr als ausreichend. VIA ist auch der einzige Anbieter den ich kenne der es schafft brauchbare cpu's zu bauen die sparsam sind und pasiv nutzbar sind. Außerdem sind die Boards immer gut ausgestattet (leider auch teuer). Besser als dieser Intel Atom Murks ist VIA auf alle fälle.

Grüße
 
Grafik Hardware aus FreeBSD Desktop Benutzer Sicht

Bin kürzlich auf diesen Thread gestoßen:
http://forums.freebsd.org/showthread.php?t=32764
Sieht für mich jetzt erst mal so aus, als wäre es als FreeBSD Desktop Benutzer besser, wenn irgendwie möglich, einen Bogen um Radeon Grafik Lösungen zu machen.

Meine erste Grafikkarte, mit der ich ein FreeBSD Desktop betrieben habe, war eine Nvida Geforce 3ti 200. Die wurde dann im Laufe der Jahre so weit wie möglich per Grafk-BIOS editieren übertaktet und bekam in einer Frankenstein Operation einen fetten Zalmann Kühler, damit lief sie jahrelang, die ist immer noch nicht kaputt! :ugly:
Intel Grafik hatte ich dann in Klappcomputern, FreeBSD Desktop lief, aber die Grafikbeschleunigung war ein derber Rückschritt im Vergleich zur Nvidia Grafik.
Machte sich besonders unangenehm in Verbindung mit Flash Videos bemerkbar.
Sogar eine Intel GMA X4500HD Grafiklösung zeigte sich bei Flash Videos völlig überfordert. Videos im KMPlayer liefen jedoch schon mit der Intel GMA950 Problemlos. Hardware Grafik-Beschleunigung im Browser gab es jedoch mit Intel Grafik nicht.

Nun verwende ich wieder Nvidia Desktop Grafikkarten mit dem proprietären nvidia-driver und bin damit als FreeBSD Desktop Benutzer von der Leistung her sehr glücklich. Die takten auch schön dynamisch runter, um den Stromverbrauch zu senken und im Fall von aktiver Kühlung angenehm leise zu bleiben.
Auch wenn Linus neulich Nvidia mal geschimpft hat:
http://heise.de/-1619616
Nvidia Optimus in Klappcomputern ist aber wohl auch noch ein böses Minenfeld.
http://www.bsdforen.de/showthread.php?t=27751
 
Noch mal zu Radeon: Das die Unterstützung für Usermode-Treiber entfernt wurde, hat realistisch gesehen weitaus weniger Auswirkungen, als man glauben darf. Denn ohne DRM war Radeon eigentlich immer mehr oder minder unbrauchbar, kaum besser als VESA. Und die Unterstützung dür das alte Nicht-KMS-DRM1 war schon länger sehr brüchig, da neuere Karten nur noch per KMS-DRM2 unterstützt wurden. Um Radeon zu unterstützten, reicht leider das in FreeBSD nun vorhandene KMS mit GEM nicht aus, man benötigt außerdem TTM. kib@ hat mal angedeutet, dass er ein grundsätzliches Interesse an einem TTM-Port hat, allerdings nicht sofort und besser würde es jemand anders machen. Ist auch irgendwo verständlich, wer 18 Monate in der Jauchgrube des freien Grafikstacks gerührt hat, hat irgendwann einfach keine Lust mehr. Parallel dazu versuchen die Linuxer im Moment TTM und GEM zusammenzuführen (anscheinend ist ihnen klar geworden, dass zwei Ansätze für das Gleiche nur doppelten Ärger bedeuten), was uns eventuell unter die Arme greift. Und selbst wenn es alles laufen würde, sind die freien Radeon-Treiber auch nicht sooo doll. Klar, sie funktionieren für 2D, aber das 3D ist nicht zuletzt aufgrund des kaputten Mesa eher rudimentär und die Stromsparfunktionen sind unter Linux auch nicht gerade wahnsinnig effizient implementiert. So wird Nvidia wohl bis auf weiteres die beste Wahl bleiben.
 
Ich habe unter FreeBSD mit allen Radeon HD47XX/HD46XX Karten, und zuletzt mit einer HD4830 Karte, nur Ärger. Der Rechner, egal ob FreeBSD 8, 9 oder jetzt FreeBSD 10, hat sich nach Verlassen des Desktops (in meinem Falle windowmaker, aber auch GNOME zeigte das Problem) und (vermeintlichen) Anzeigens des XDM die Kiste aufgehangen - gnadenlos und durch durch Hard-Reset lösbar. Oder es gab nur streifige Bilder.

Das Problem ist auch unterschiedlicher Hardware aufgetreten - zuletzt auf meiner Labormaschine auf Basis des X79-Chipsatz, also kein Hardware-Problem der Plattform.

Seither vermeide ich alles Graphische aus dem Hause AMD und deklariere für meinen Teil die HD-Graphikkarten als Flop im FreeBSD Kontext.
 
Worüber ich mich dieses Jahr besonders geärgert habe, sind die PowerVR Dinger(GMA 3600 aka Cedar Trail) die Intel in ihrer zwei tausender Reihe verbaut hat.

Nichts ahnend hatte ich mir ein passiv gekühltes Board zugelegt und habe erst dann erfahren das intel keine Treiber bereitstellt sondern nur PowerVR und die auch nur proprietäre. Die einzige Möglichkeit den Grafikkern zu nutzen ist im Moment Meego mit BLOB oder angeblich Windows7, was wohl auf einem Atom Dual Core mit 1.86GHz nicht besonder viel Spaß machen sollte und ich auch nicht will.

Ab linux 3.3 wird die GPU wenn auch ohne 2D/3D Beschleunigung unterstützt, aber z.B. ein Video in Vollbild schafft man damit leider nicht.

Aber Konsole geht :D
 
stadtkind: OpenSSL nutzt AES-CTR das OS unabhängig. Der große Vorteil von Padlock gegenüber anderen HW-Cryptobeschleunigern ist unter anderem, das es keinen Kernelsupport braucht.

Soweit ich weiß, geistert AES-CTR Support in OpenSSL hoechstens in Form von irgendwelchen Patches von Intel im OpenSSL Bugtracker rum, aber vielleicht gibts ja da inzwischen Neuigkeiten und wenn du weißt wie das geht, wuerde ich mich ueber eine HOWTO freuen.

Zum Thema Padlock AES-CTR im Kernel. Nun ohne Support kann ich GELI oder DM-Crypt mit der »sichereren« AES Verschluesselung (AES-XTS) vergessen und bin weiterhin auf CBC angewiesen.

Auch nutzt ssh inzwischen defaultmaeßig aes-ctr, so das man bei den Padlock CPUs inzwischen staendig nachjustieren muss, wenn man HW Crypto haben will.
 
Abseits der CPU-Spezifika, was sicherlich für eingebettete Systeme und Niedrigvolt-Prozessoren wichtig ist, die nicht unterstützt wird, hier noch einen anderen, viel gravierenderen FLOP.

Schlagwort GPGPU, Schlagwort OpenCL/CUDA. Nutzung einer nVidia oder AMD Graphikkarte als GPGPU-Device. Dank nVidia können "wir BSDler" froh sein, daß unter modernen 64bit Systemen 3D Beschleunigungen und OpenGL >3 nutzbar sind. Leider ohne CUDA, leider ohne OpenCL, denn der nVidia-eigene Compiler "nvcc" ist linuxbinär, die entsprechenden OpenCL und CUDA Bibliotheken sind nur als 32bit Versionen mit Hilfe des Linuxulators nutzbar - wenn überhaupt nutzbar (es geht jedenfalls nicht bei uns). Unsere TESLA Karten müssen mit Linux betrieben werden, will man diese im HPC Umfeld nutzen.

Unter FreeBSD ist weder unter OpenCL noch CUDA eine GPGPU-Nutzung möglich, die für mich/uns im wiss. Bereich zunehmend wichtiger wird. HPC ist eine Domäne, die ich als die Königsdisziplin der Betriebssystemnutzung sehe. FreeBSD bzw. die BSDs allgemein haben in den vergangenen 15 Jahren sehr viel Terrain verloren.

AMD blubbert zwar seit Jahren über offene Treiber und Dokumentation, aber dabei ist nicht sonderlich viel bei herumgekommen bis auf Lippenbekenntnisse. nVidia ist ausschließlich auf Markt und Profit fixiert. Die größte Enttäuschung aber sind Graphikkarten und treiber für AMD Karten allgemein, meine Probleme mit der HD4XXX Serie von AMD habe ich einem verlogenen Versprechen seitens AMD zu verdanken, die in einem Gespräch bemerkten, daß deren Chips OpenCL fähig seien und man die Chipspezifika offenlege werde, so daß die FOSS Treiber in spätestens einem Jahr OpenCL "können" sollten.

Der Chip hatte Probleme, die Dokumentation war nach nur zwei oder drei Wochen Präsenz auf den offiziellen Webservern von AMD plötzlich nicht mehr verfügbar. Der schleppende Stand der Entwicklung des Gallium3D und CLover Gespannes im Radeon-Treiber zeigt, daß das Problem nicht *BSD- bzw. FOSS spezifisch ist, sondern seine Ursache in AMDs Spielchen hat. AMD Graphikkarten sind meiner Ansicht nach unter FreeBSD für eine ernsthafte Anwendung völlig unbrauchbar! Es gibt keine Catalyst 64bit Treiber für FreeBSD. Die aktuellen Radeon/RadeonHD treiber in Xorg-X11 unterstützen keine HD7000er Karten. Wenn ich heute Hardware bestelle - und die Budgest sind, wie in einem Unternehmen auch, limitiert und auf längere Zeiträume ausgelegt, so werde ich keine Hardware von gestern ordern, sondern moderne, neue Hardware. In Maßstäben der Zyklenzeit, welche die gierige Industrie selbst mit ihren hohen Produktfrequenzen zu verschulden hat, sind sechs Monate eine halbe Ewigkeit und man sollte jetzt für die HD7000 auch für FreeBSD funktionierende 64bit Treiber erhalten. Wo sind diese? nVidia schafft das problemlos, wenn auch mit einem BLOB.
 
Die einzige Möglichkeit den Grafikkern zu nutzen ist im Moment Meego mit BLOB oder angeblich Windows7, was wohl auf einem Atom Dual Core mit 1.86GHz nicht besonder viel Spaß machen sollte und ich auch nicht will.

Also Windows 7 läuft selbst auf einem Atom Single Core ganz anständig, nicht wirklich langsamer als XP z.B.
 
Wie sieht es eigentlich mit dem Nvidia-Binary-Treiber für FreeBSD unter NetBSD/OpenBSD aus? Kann man den dort auch nutzen?

@Eisenfaust! D.h. man kann GPGPUs zum Rechnen aktuell nicht unter *BSD nutzen?

@all! Ich habe in einer News gelesen, das die FreeBSD Foundation an Intel-Grafiktreibern arbeitet. Was hat es damit aufsich?
 
Der Nvidia Treiber ist nur für FreeBSD. Es gab mal Interesse seitens NetBSD die notwendigen Anpassungen zu unternehmen, mittlerweile wurde das verworfen. Und Nouveau benötigt einiges(KMS, TTM) was bei Open- und NetBSD gänzlich fehlt.

Und zu GPGPU, pscnv wurde erweitert für FreeBSD, schaut zum. recht versprechend an.
 
Darüber hinaus kann man mit dem Nvidia-Treiber unter FreeBSD Linux-CUDA-Anwendungen ausführen, das CUDA-SDK läuft einwandfrei im Linuxulator. Es geht, da die CUDA-Unterstützung für den Kernel vorhanden ist, allerdings die Runtime-Bibliothek fehlt. Nvidias Statement dazu war, dass sich eine Portierung auf FreeBSD nicht lohnt und daher erst einmal mangels Nachfrage nicht durchgeführt wird. Der Nachteil der Linuxulator-Lösung ist, dass man auf 32-Bit Prozesse beschränkt ist.
 
[...]
@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!
 
Zurück
Oben