27. April 2010
Remotevisualisierung mit VirtualGL
Das RRZE hat seit Ende 2009 acht Rechenknoten mit jeweils zwei NVIDIA Tesla M1060 Grafikkarten (baugleich zur C1060 jedoch rein passiv gekühlt) und DDR-Infiniband-Vernetzung: TinyGPU-Cluster
Diese Rechner können nicht nur als Rechenknechte (via CUDA oder OpenCL) genutzt werden, sondern auch zur Remote-Visualisierung mittels VirtualGL). Das LRZ betreibt zum gleichen Zweck bereits seit längerer Zeit einige leistungsfähige Systeme: LRZ-Dienst Visualisierung
Das GPU-Cluster am RRZE ist als experimentelles Forschungscluster ausgelegt. Daher ist, sowohl was CUDA/OpenCL als auch die Remote-Visualisierung betrifft, stets mit Änderungen zu rechnen, insbesondere da derzeit die Umstellung von CUDA-Tookit 2.3 auf Version 3.0 ansteht, was mit einem Upgrade des NVIDIA-Kernel-Treibers verbunden ist. (Update August 2010: inzwischen läuft sogar schon 3.1)
Um VirtualGL nutzen zu können, muss auf dem lokalen Rechner entweder VirtualGL (inkl. TurboJPEG oder libjpeg-turbo) oder aber TurboVNC (oder TigerVNC) installiert sein. Wenn dann eine Remote-Visualisierung ansteht, besorgt man sich auf TinyGPU am besten einen interaktiven Batchjob (ggf. auf einem bestimmten Knoten, da VirtualGL derzeit nicht auf allen Knoten installiert ist). Während der Batchjob läuft, kann man sich auf dem entsprechenden Knoten auch direkt per SSH einloggen. Sofern man VirtualGL nativ verwendet (bietet sich von Linux-Clients aus an), so verwendet man ein vglconnect -s kennung@tgXXX um auf den reservierten Knoten zu kommen. Dort kann man dann die Grafik-intensive Applikation mit vglrun a./out starten. (Für STAR-CCM+ muss vglrun -nodl starccm+ verwendet werden, wenn STAR-CCM+ im parallelen Modus laufen soll.) Wie man die beide GPUs via VirtualGL sinnvoll nutzen kann, ist derzeit noch unklar.
Bezüglich der aktuellen Konfiguration und weiterer Nutzungshinweise wenden Sie sich bitte an die HPC-Gruppe.
Seit 19. Juli 2010 muss die Eigenschaft virtualgl explizit von den Jobs angefordert werden, damit beim Jobstart ein X-Server gestartet wird.
18. August 2010: VirtualGL ist derzeit leider auf dem TinyGPU-Cluster nicht verfügbar. Wir hoffen, dass VirtualGL in Kürze wieder bereitgestellt werden kann.
30. August 2010: VirtualGL ist jetzt wieder auf dem TinyGPU-Cluster verfügbar, nachdem der Linux-Kernel aktualisiert wurde.
There are security problems in older NVidia driver versions (cf. http://nvidia.custhelp.com/app/answers/detail/a_id/3109).
Let’s hope that NVidia’s patch for old versions works properly …
Current versions of NVidia drivers (e.g. those coming with CUDA 4.1, i.e. 285.05.33) do not properly work together with VirtualGL and STAR-CCM+. As soon as you for example try to select a surface, the message “error in SendArray -777star.vis.PartDisplayer_0;ReconcileParts;-2224″ occurs and further visualization with the running process is broken.
On our Tesla M1060/C2070 cards, version 270.41.19 which came with CUDA 4.0 was fine, and even 285.03 works correctly with VirtualGL and STAR-CCM+. If you look at different forum posts, other people identified other/earlier versions of the NVidia driver as problematic. See e.g.
http://www.nvnews.net/vbulletin/showthread.php?t=166541
https://hpc-forge.cineca.it/trac/RemoteGraph/wiki/KnownStarCcmErrorOnVirtualGl
http://sourceforge.net/tracker/index.php?func=detail&aid=3238251&group_id=117509&atid=678327
We reported the issue to CD-adapco (the creator of STAR-CCM+) and to NVidia. Both are investigating the problems. Let’s hope the issue gets fixed in one of the next driver releases.
Right now, on TinyGPU we are installing different versions of the NVidia driver; 285.05.33 if CUDA is used on the nodes and 270.41.19 if VirtualGL is requested. The distinction is done using PBS/torque node properties, i.e.
:virtualglinstalls the alternative device driver and starts the X server during the prologue; during the epilogue, the X server is stopped and the default CUDA driver version is installed. That’s some sort of hack which works for now but wont support newer hardware which requires updated drivers.