GPGPU

Sieht so aus, als ob Nvidia sich entschlossen hat, Luxmark "unter die Arme zu greifen". Zumindest hat Dade gepostet, dass Nvidia zahlreiche Optimierungen vorgeschlagen hat.

Ich bin sehr gespannt, wie sich das auf die AMD-Karten auswirkt. Ist aber spannend, dass sich Nvidia nun einschaltet, da man bei Luxmark, welches sich inzwischen zum Standardbenchmark für OpenCL entwickelt hat, von AMD deutlich geschlagen wird. Das zeigt z.B. das aktuelle Titan X-Review von Anandtech wo die TitanX 27% schlechter abschneidet als eine Radeon HD 290X.

Dabei wird auch gemutmaßt, dass Nvidia speziell für Luxmark 2.0 optimiert hatte(um in Reviews besser dazustehen), da man nun bei Luxmark 3.0 wieder deutlich schlechter abschneidet als AMD.

Damit ist eine Beteiligung von Nvidia an der Entwicklung von Luxrender zwar prinzipiell begrüßenswert, aber nur solange das nicht zu Nachteilen für AMD führt. Wenn AMD clever ist, schicken sie Dade schnellstmöglich eine Fiji....
 
Zuletzt bearbeitet:
Bei Blender geht´s offensichtlich gut voran mit dem Cycles Split Kernel-Branch, der von AMD angestoßen wurde. Leider funzt das derzeit nur auf GCN Karten und da sind auch noch zahlreiche Features deaktiviert, die unter OpenCL nicht laufen. Aber AMD hat glaube ich wirklich verstanden, dass der Software-bereich nicht vernachlässigt werden sollte. Jedenfalls wird jetzt von mehreren Entwicklern eifrig daran gearbeitet, Cycles auf OpenCL zum Laufen zu bringen.
Siehe Posts zum Cycles Kernel Split Branch
Und der AMD/ATI-Thread bei Blenderartists.
 
Da kommt wohl bald eine AMD Multiuser GPU (pdf).
Bis zu 15 Anwender können per Hardware-basierter Virtualisierung die GPU nutzen, indem sie einfach den Treiber verwenden, der auch für eine normale FirePro verwendet wird.
Verfügbar wird auch OpenGL, DirectX und OpenCL 2.0.
MfG
 
Hui, danke für die Info. Das sieht mal richtig gut aus. Genau der Punkt, wo AMD momentan dicke aufzuholen hat. Das dürfte dann auch für MS und Sony höchst interessant sein.
 
Es macht mich stutzig, dass man die Resourcen anscheinend vorher aufteilen muss.
AMD bewirbt das so, dass man seine Resource garantiert bekommt und sie einem kein anderer Nutzer durch hohe Last abluchsen kann.
Schön und gut, aber effizienter ist es, wenn die gerade nicht genutzten Resourcen anderen Teilnehmern zugute kommen. Annehmbar wäre es, wenn die Resourcen nur im Bedarfsfall zugesichert werden, aber der Allgemeinheit zur Verfügung stehen, wenn ein Teilnehmer sie nicht ausschöpft.
Für mich klingt es danach, dass AMD gerade diese dynamische Lastverteilung nicht hinbekommt.
Wie seht Ihr das?
MfG
 
Wird die Fiji-basiert sein? Falls ja, wäre es ein weiterer kleiner/Teilgrund für die unbefriedigende Verfügbarkeit der Furys.
 
@Woerns
Bei einem multi User System bei dem mehrere User gleichzeitig darauf zugreifen halte ich es für wichtiger das jeder User jederzeit seine Ressourcen nutzen kann anstatt ein anderer User sie einem aufgrund der Dynamik blockiert oder soll dieser dann wieder Federn lassen, wodurch die benötigte Rechenzeit kaum noch planbar wird?
Dazu stellt sich mir die Frage ob Bereiche mit einem so hohen Leistungsbedarf besitzt das solche Sachen relevant werden nicht mit festen Systeme besser beraten sind.
 
ein pc zuhause, der als gaming-server fungiert und 3 15 watt carrizo thin-clients für die familie zum spielen an den fernsehgeräten. wäre doch prima.
 
Das wäre in meinen Augen Mist, sofern die Spiele von dem dollen Server berechnet werden sollen. ;)
Sitzen mehrere Spieler gleichzeitig drauf und der Server soll dafür genug Reserven besitzen dann übersteigen die Kosten für die entsprechende Hardware schnell mal die Kosten der gleich starken Hardware für getrennte Systeme.
Auch von der Stromrechnung her rechnet es sich nicht da jedes mal mindestens 2 Rechner laufen und der Server die ganze Zeit durch laufen muss.

Wer ne ganz simple Form des Streaming nutzen will kann sich ja mal das In-Home-Streaming vom Stream anschauen.
 
Dynamische Lastverteilung schön und gut nur auch beschweurt,
wenn nicht jedem Nutzer ein vernünftiges minimum an Leistung zugeteilt wird.
IMHO kann das durchaus sinnvoll sein um jedem Nutzer Rechenleistun g bereitzustellen wie es heute bei Webservern möglich ist nun hält einfach für opencl 2.0 Anwendungen auf der GPU.
 
Zumindest die gpu-ram größe müsste man für opencl fest dem jeweiligen nutzer zuordnen.
@unbekannter Krieger
Bezüglich fiji: 4gb eignen sich glaube ich für sowas nicht wirklich.
 
sompe schrieb:
...oder soll dieser dann wieder Federn lassen, wodurch die benötigte Rechenzeit kaum noch planbar wird?
Zum Vergrößern anklicken....

Ja, so meinte ich das. Zugesichert wird jedem ein Minimum, das aber andere nutzen können, wenn derjenige es nicht selbst abruft. Wer die Resourcen anderer mitnutzt, muss damit rechnen, dass diese jederzeit zurückgezogen werden.

Ich habe letztens was gelesen, wie hoch die Auslastung typischer Server ist. Ich weiß nicht mehr die genaue Zahl und die Art der Erhebung, aber es war erschreckend niedrig im einstelligen Prozentbereich. So ähnlich stelle ich es mir hier auch vor, wenn Herr X gerade im Außendienst ist, Herr Y krank ist und Herr Z gerade Word editiert. Aber vielleicht fehlt mir nur die Fantasie für ein sinnvolles Szenario, wo Administratoren über AMDs Lösung jubeln.
MfG
 
Woerns schrieb:
Ich habe letztens was gelesen, wie hoch die Auslastung typischer Server ist. Ich weiß nicht mehr die genaue Zahl und die Art der Erhebung, aber es war erschreckend niedrig im einstelligen Prozentbereich.
Zum Vergrößern anklicken....

Das hast du schon richtig gelesen. Für klassische Server bieten aktuelle CPUs meist viel zu viel Leistung. Virtualisiert hat man dann oft Engpässe bei RAM und IO, meist Storage. Dies macht dann auch den Löwenanteil der Kosten bei einem Server aus.

Spezielle Anwendungen wie Bilderkennung auf einem Server bilden die Ausnahme. Da braucht man dann auch Rechenleistung.
 
Zuletzt bearbeitet:
Mit HSA und OpenCL und bei entsprechender Software kann es schon von Vorteil sein auf einem Terminalserver so eine Resource zur Verfügung zu haben.

Die Architektur scheint damit da zu sein, müssen sie nur noch das Softwareökosystem hochziehen..
 
Woerns schrieb:
Ich habe letztens was gelesen, wie hoch die Auslastung typischer Server ist. Ich weiß nicht mehr die genaue Zahl und die Art der Erhebung, aber es war erschreckend niedrig im einstelligen Prozentbereich.
Zum Vergrößern anklicken....

Das RZ Geschäft ist ein Peak Geschäft, die Peaks müssen auch laufen wenn die eine Hälfte der Redundanz weg ist. Und quasi Vollauslastung im Peak will man nicht, weil sonst schneller irgentwelche Queues volllaufen als du gucken kannst und die Anwendungen in Folge austimen oder User ihre Arbeit nicht schaffen.

Wenn man also definiert das deine Maschinen nur auf einem Pott zu max. 70% ausgelastet sein sollen, bist du bei 35% im Peak auf zwei Pötten. Und die Peaks sind nicht den ganzen Tag lang, z.b. Schichtwechsel, Monatsende, Quartalswechsel, etc.
 
AMD hat ein SDK (bzw. eine Bibliothek) für Raytracing-Berechnungen veröffentlicht. Nennt sich FireRays und ist, wie für AMD typisch, nicht auf AMD GPUs/APUs beschränkt, setzt aber OpenCL1.2-Kompatibilität voraus.
 
Jules Urbach hat offenbar einen Crosscompiler für CUDA, der es ermöglicht, OTOY/Octane auf anderen GPUs auszuführen. Die Details sind vage, aber man darf gespannt sein.
Vielleicht hat er noch die OTOY Render Cloud mit Cypress im Keller. :D
 
Man sollte vielleicht noch erwähnen, dass es sich hierbei um ein 3ds Max Plugin handelt. Schaut auf jeden Fall sehr interessant aus. AMD scheint mittlerweile auch beim Thema Softwaresupport richtig Gas zu geben.
 
Wenn ich es richtig verstanden habe ist das ein C++ Framework, welches man für ein 3ds Max Plugin genutzt hat. Man kann es aber auch ausserhalb nutzen und es liegt komplett im Quellcode vor! Ich habe im Blender-Forum gelesen dass einige mal untersuchen wollen, ob man es nicht auch für Blender nutzen kann. Man war begeistert und hat dem Framework erstklassige Resultate bescheinigt.
 
mariahellwig schrieb:
Wenn ich es richtig verstanden habe ist das ein C++ Framework, welches man für ein 3ds Max Plugin genutzt hat. Man kann es aber auch ausserhalb nutzen und es liegt komplett im Quellcode vor! Ich habe im Blender-Forum gelesen dass einige mal untersuchen wollen, ob man es nicht auch für Blender nutzen kann. Man war begeistert und hat dem Framework erstklassige Resultate bescheinigt.
Zum Vergrößern anklicken....
:o wäre ja fast mal ein Versuch wert, gibt es schon ein "HowTo" ? *buck*
 
Scheint in der Tat auf einer allgemeinen C++ Bibliothek aufzubauen, welche es bereits seit vergangenem Jahr gibt und die praktisch in alle möglichen Anwendungen eingebunden werden kann. Umso besser!

http://developer.amd.com/tools-and-sdks/graphics-development/firepro-sdk/amd-firerender-technology/

The FireRender SDK provides a C++ library that allows for easy integration into applications wherever fast, high quality rendering is needed.
Zum Vergrößern anklicken....

Neu hingegen ist anscheinend das 3ds Max Plugin.
 
Oder mit anderen Worten, Nvidias OpenCL Support ist Grütze. Nix neues.
 
Zurück
Oben Unten