3d-Leistung bei mehreren Grafikkarten auf mehreren Displays

[Aranha]

Hallo zusammen!

Ich soll eine Workstation planen, die auf sechs unterschiedlichen Monitoren je eine oder mehrere VMs laufen lassen soll, in denen je eine 3D-Anwendung etwas rendert.
Da die sechs Displays etwas weiter weg vom Schreibtisch an der Wand Platz finden sollen, soll ein weiterer Bildschirm auf den Schreibtisch zum „ranholen“ der VMs und bearbeiten der Jobs angeschlossen werden.
Zu allem Überfluss, soll die Maschine nicht alt zu laut werden…
BUFF!

Ich weiß leider überhaupt nicht, wie es sich mit der Verteilung der Rechenleistung auf die GPUs verhält.
Wäre es denkbar, eine halbwegs leistungsstarke Karte zu kaufen, deren GPU das Rendern übernimmt, während zwei kleinere Karten einfach nur die Ports für die Displays zur Verfügung stellen?
Ein VM müsste dann also die GPU der „dicken“ Karte nutzen, während die VM seinen Inhalt über eine andere Grafikkarte auf ein Display ausgibt. Ist so etwas denk- oder sogar realisierbar?

Irgendwelche Gedanken oder hinweise darauf wie VM-Ware mit GPU-Leistung umgeht, und welche Stellschrauben und Einstellungen es dafür gibt wäre super.

Vielen Dank im Voraus und bis denne,
Aranha

[stefan.becker]

Vergiss es, daran kannst du gar nichts drehen oder verteilen.

[UrsDerBär]

Also eine Rendermaschine virtualisiern ist imho ziemlicher Käse. Da wird viel zu viel Performance verbraten. Davon abgesehn wird es schwierig bis unmöglich die GPU auch an den Gast weiterzureichen.

Oder haben die Software wenig oder unregelmässig arbeit? Wie willst gscheites 3D in eine VM bekommen? Das geht ned sinnvoll.

Eine Idee:
- Supermicro Rack-Computer mit 4 Nodes und doppeltem Netzteil --> Recht günstig und stromtechnisch einigermassen interessant
- jeweils eine GPU und eine oder zwei CPU
- Eine PCoIP Host Karte in jeden Node
- Ein Bildschirmausgang der GPU auf die Bildschirme hinten legen
- Den zweiten Bildschirmausgang auf die PCoIP Karte legen
- Zum ranholen jeweils mit der entsprechenden Karte verbinden (mit dem Portal)

Das laute könntest du folgendermassen abstellen in dem du das Ding in einen anderen Raum verfrachtest.

EDIT: Die Supermicro Twin mit 4 Boards haben leider nur 1 PCIex, die 2U Twins haben zwei Boards, da wäre es möglich GPU's einzubauen.
Haben auchTwins mit extra GPU-Schacht: http://www.supermicro.com/GPU/

Edit2: Guter, recht günstiger Händler für Supermicro: http://www.Happyware.de

[Aranha]

Hallo Urs.

Danke für die schnelle Antwort!

Die Rechenleistung der VMs an die GPU ist wie du schon anschnitten hast tatsächlich nicht sonderlich anspruchsvoll.
Da ich um die Performance-Problematik der VMs weiß, wäre ich sonst auch nicht auf die Idee der Virtualisierung gekommen.
Wie das ganze in der Praxis aussieht, würde ich ganz gern mal hier mit zwei VMs mit anderer Hardware testen. Um überhaupt mal einen Eindruck davon zu haben, ob das Praktikabel ist, was ich mir da ausdenke.
Denn Leider ist dein Vorschlag fernab jeglichen Bugets... leider

Nun, nochmal die Frage: Wo kann ich einstellen welche GPU benutzt werden soll, und ist das überhaupt unabhängig davon einstellbar, über welche GraKa bzw. Monitor die VM angezeigt wird?

Viele Grüße,
Aranha

[UrsDerBär]

Naja, wenn die GPU-Leistung nicht sonderlich ist, setze doch einfach mal nen ESXi auf und gucke was passiert. Halt ohne GPU, soll er den krempel hatl via CPU machen. Wens ned viel Last ist und die Software das zulässt, gehts vielleicht auch.

GPU's kannst du nicht wirklich gscheit virtualisieren. Geht höchstens mit Direktem Durchreichen. ABER das ist experimentell und dann auch nur eine GPU für eine VM verfügbar!

3D-Darstellungsleistung wirst du keine prickelnde haben. Aber beim rendern vielleicht gar nicht nötig.

Darstellung auf den Bildschirmen: Nun, damit ist wohl ziemlich Schluss dann.

Einzeln Darstellen Bei schmalem Budget (Davon ging ich nicht aus wenn 6 Screens zum Einsatz kommen sollen) reicht doch vielleicht auch einfach der vSphere-Client und die Konsole. Dann kannst rumklickern von VM zu VM.

Apropo Preis: Wenn die Supermicro-Maschinen zu teuer sind, was bitte willst du dann verwenden? Günstiger geht es für gute Marken-Hardware selten.

[stefan.becker]

Hab ich was verpasst? Seit wann kann VMWARE eine GPU durchreichen?

Rudimentäres 3D wird doch bei der Workstation unterstützt.

[UrsDerBär]

Mit vmDirectPath beim ESXi wurde das teilweise schon erfolgreich getestet. Weiss aber nimmer welches Grafikkartenmodell das war. Ein nVidia soweit ich mich erinnere.

[Dayworker]

Urs spielt auf Sapphire Radeon 4550 512MB/PCI-Ex16 an.
Wie immer sollte man da extrem aufpassen, da nicht immer die komplette Produktbezeichnung hinterlegt wird und häufig schon ein(e) Buchstabe(Zahl) über den Erfolg entscheidet.

[stefan.becker]

Mit vmDirectPath beim ESXi wurde das teilweise schon erfolgreich getestet. Weiss aber nimmer welches Grafikkartenmodell das war. Ein nVidia soweit ich mich erinnere.

Danke für die Rückmeldung, das hatte ich noch nicht mitbekommen.

[McStarfighter]

Dann könnte man sich ja eventuell nen guten und leistungsfähigen virtuellen Desktop basteln ... Schwelg, schwärm ...

[Dayworker]

Könnte...die Probleme lauern im Detail.
Auch wenn VT-d eigentlich für VMdirectPath ausreichen würde, hat VMware das bisher nur für Nehalem-Xeons und die 55XX-Chipsätze freigegeben. Selbst AMD mit seinem VT-Pendant ist dort nur Nase...

[McStarfighter]

Naja, ich habe ja durchaus die Hoffnung, daß VMDirectPath mal universeller wird und so ziemlich alles ermöglicht, was VT-d hergibt.

Die Zeit wird es zeigen ...

[UrsDerBär]

@Dayworker: Stimmt genau, die wars. Doch ned nVidia.

Aber eben, er bräuchte ja eine pro VM. Irgendwie schwierig könnte ich mir vorstellen. Und ob die tatsächlich alle eingebaut, genutzt UND weitergereicht werden können?

Der Tag wo das universell klappt, wird kommen. Xen forscht da auch extrem zusammen mit Hardwareherstellern, VmWare wirds auch. Also ein Hypervisor für Desktops wo man dann immer das OS generell in eine VM installiert.

[McStarfighter]

Xen kann es sogar bereits mit der kürzlich erschienenen Version 4.0. Expliziter Support für das PCI-Passthrough von GPUs ... Und beim KVM-Projekt wird auch fleißig dran gearbeitet ...
Ein direkter Hypervisor embedded? Da wirds von verschiedensten Seiten zu viele Widerstände hageln, wird also noch ne ganze Ecke länger dauern damit.

Nen Bare-Metal-Hypervisor für Desktops hat Citrix übrigens vor ner Woche released: Den Citrix XenClient. Kann man derzeit für lau runterladen (Tante Google fragen). Um den aber sinnvoll nutzen zu können, brauchts im Desktop VT UND VT-d, sonst kann die Hardware nicht switchen ...

[Dayworker]

...und wenn wir schon dabei sind, "Parallels Workstation 4.0 Extreme" bietet das auch schon seit längerem an. Siehe auch den Thread Parallels Workstation 4.0 Extreme im Feedback&Smalltalk-Bereich.
Der große Pferdefuß dabei sind die extremen HW-Anforderungen, zu den bekannten Xeon55XX-CPU und 55XX/X58-Chipsatz kommt hier noch eine Tesla-Karte der Reihen FX 3800/4800/5800 hinzu und zum Zeitpunkt meines Postings war auch nur die HP-Workstation Z800 dafür zertifiziert. Inzwischen umfaßt die kurze Liste folgende Systeme:

• Dell Precision T5500 und T7500
• Fujitsu Celsius R650 Und R670
• HP Z800
• Lenovo S20 & D20

[McStarfighter]

Naja, der Support an Host- und auch Gast-Systemen ist ja mehr als nur dürftig ...

Host: Seit XP alle 64-Bit-Versionen eines Desktop-Windows, kein Linux als Host
Gast: Ab XP alle 64-Bit-Windows sowie RedHat 4.7 und 5.3, dazu noch Fedora 10

Sorry, aber bei so nem "wegweisenden" Virtualisierer stell ich mir das ein wenig aktueller und "breiter" vor ...

[Dayworker]

Ähem, von Parallel als Host-OS werden unterstützt:
64-Bit Windows-Ausgaben: Windows Vista SP1, Windows XP SP2 & Windows 7
64-Bit Linux-Ausgaben: Red Hat Enterprise Linux 5.3

...und als Gast-OS:
64-Bit Windows-Ausgaben: Windows Vista SP1, Windows XP SP2 & Windows 7
64-Bit Linux-Ausgaben: Red Hat Enterprise Linux 4.7 & 5.3 und Fedora 10


Der Grund für die 64bit-OS ist nicht in deren Treiberversorgung sondern in der meist wesentlich besseren Treiberqualität zu suchen, da sich Alt-Treiber oder 32bit-Treiberversionen nicht mehr auf einem 64bit-System installieren lassen. Die 64bit-Windows wollen auch noch für alle systemkritischen Treiber und dazu zählen alle Virtualisierungsprodukte, eine Herstellersignatur sehen, sonst lassen sie sich nicht installieren. Ein weiterer Grund ist auch im längeren Pflegezeitraum aller Windows-Versionen zu sehen. Damit umgeht man ganz einfach das leidige Kernel-Gefrickel bei den meisten Linux-Distributionen und deren ständigen Änderungen an den Kernelschnittstellen mit jeder neuen Kernelversion. Jede neue Kernelversion im 3-Monatsrhythmus stellt eigentlich ein neues Betriebssystem dar und kaum ein unabhängiger Hersteller macht sich die Mühe, seine Produkte noch diesem Wahn hinterherzupatchen. Es sind vermutlich nicht mal die häufig vorgeschobenen Geldgründe, daß sowas nicht mehr gepatcht wird, sondern vermutlich ausschließlich Zeitgründe. Wenn man seine Produkte endlich auf verschiedener Hard- und Software relativ fehlerfrei bekommen hat, kommt die nächste Kernelversion und schmeißt mit ihren Änderungen an sämtlichen Kernelschnittstellen wieder alles über den Haufen. Nur die SW die von den Kernel-Hackern im Zuge der Kernelentwicklung mit gepflegt wird (KVM, alle im Quelltext vorliegenden Treiber, etc), hat so überhaupt noch eine Chance auf einen funktionalen Betrieb.

Von der Warte aus ist es für mich auch völlig verständlich, weshalb nur ein Server-Linux als Host-OS unterstützt wird. RHEL5.3 wird wie CentOS5.4 immer noch auf dem schon lange gereiften Kernel 2.6.18 aufsetzen. Leider wird es da inzwischen manchmal etwas eng mit der Treiberversorgung neuerer HW für ältere Kernelversionen. Viele entscheidende Kernelschnittstellen haben sich seitdem geändert und darauf aufsetzende Treiberquellen lassen sich dann auch nicht mehr so einfach kompilieren oder backportieren. Also beschränkt man sich sicherheitshalber wieder auf längerfristig mit derselben HW & SW ausgestattete Serverhersteller.

Im Endeffekt hat Parallel in meinen Augen aus dieser VMware-Misere gelernt und setzt die Anforderungen ausreichend hoch, damit man einen stabilen Betrieb auch längerfristig sichern kann. Gleichzeitig entkommt man so auch dem Spieltrieb der meisten Desktop-Distributionen.

PS: Sorry, es wurde wieder mal etwas länger.