User Tools

Site Tools


howto:remote_viz

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
howto:remote_viz [2019/05/14 11:00]
ccrosby [Getting a Virtual Desktop on a compute node]
howto:remote_viz [2019/07/19 14:15]
ccrosby [Getting a Virtual Desktop on a compute node]
Line 173: Line 173:
 ssh -f jblogs@lengau.chpc.ac.za -L 5901:​cnode1234:​5901 -N ssh -f jblogs@lengau.chpc.ac.za -L 5901:​cnode1234:​5901 -N
 </​code>​ </​code>​
-As usual, use **your** username and compute ​number, not jblogs and cnode1234!+As usual, use **your** username and compute ​node, not jblogs and cnode1234!
  
 === Connect your VNC client === === Connect your VNC client ===
-Now, as before, fire up your VNC client, preferably TurboVNC, and connect to port 5901 (or 1 in VNC shorthand) on localhost. ​ Once connected, you will be confronted with a blank black screen. ​ Click your right mouse button to pop up a small menu, and select xterm, which will give you a small terminal. ​ You can resize the window by holding down the alt key and the right mouse button, and dragging the mouse. ​ Refer to the [[http://​fluxbox.org|Fluxbox homepage]] ​of you need help with other operations.+Now, as before, fire up your VNC client, preferably TurboVNC, and connect to port 5901 (or 1 in VNC shorthand) on localhost. ​ Once connected, you will be confronted with a blank black screen. ​ Click your right mouse button to pop up a small menu, and select xterm, which will give you a small terminal. ​ You can resize the window by holding down the alt key and the right mouse button, and dragging the mouse. ​ Refer to the [[http://​fluxbox.org|Fluxbox homepage]] ​if you need help with other operations.
  
 === Running Interactive Software === === Running Interactive Software ===
 Up to this point, the process has been basically identical to using a visualization node.  However, **the compute nodes do not support VirtualGL**,​ as they do not have dedicated graphics cards. ​ All is not lost however: Up to this point, the process has been basically identical to using a visualization node.  However, **the compute nodes do not support VirtualGL**,​ as they do not have dedicated graphics cards. ​ All is not lost however:
   - Software GUIs with menus, etc. will generally just work.   - Software GUIs with menus, etc. will generally just work.
-  - Software linking dynamically to OpenGL libraries will probably work well with the chpc/​compmech/​mesa/​19.0.3_swr module. ​ The currently installed Mesa-19.0.supports ​up to OpenGL-2.1 only.  ​We are working on improving ​this installation to support up to at least OpenGL-3.2.  Older programs, such as Paraview-4.3 ''/​apps/​chpc/​compmech/​CFD/​ParaView-4.3.1-Linux-64bit/​bin/​paraview''​ work very well with the Mesa-19.0.implementation.+  - Software linking dynamically to OpenGL libraries will probably work well with the chpc/​compmech/​mesa/​19.0.4_swr module. ​ The currently installed Mesa-19.0.supports ​software rendering using either LLVMpipe or Intel'​s swr.  ​By default the module activates the LLVMpipe method, but this is easily changed: ''​export GALLIUM_DRIVER=swr''​ or ''​export GALLIUM_DRIVER=llvmpipe''​. ​ The advantage of the LLVMpipe implementation is that it supports a more recent version of OpenGL. 
 +  Older programs, such as Paraview-4.3 ''/​apps/​chpc/​compmech/​CFD/​ParaView-4.3.1-Linux-64bit/​bin/​paraview''​ work very well with the Mesa-19.0.implementation.  More recent ParaView versions are built with --mesa-swr and --mesa-llvm support. ​ Although these work well with X-forwarding,​ they don't work in the VNC environment. ​ We are not sure why, but we are working on it.
   - Some software vendors provide binaries that are statically linked to a Mesa library. ​ These will generally work, but may be a bit slow.    - Some software vendors provide binaries that are statically linked to a Mesa library. ​ These will generally work, but may be a bit slow. 
   - STARCCM+ has its own version of Mesa-SWR. ​ Use the command line options ''​-mesa -rr -rrthreads N''​ , where N is the number of cores that should be used for graphics rendering. ​ In this implementation,​ you can use up to 16 threads.   - STARCCM+ has its own version of Mesa-SWR. ​ Use the command line options ''​-mesa -rr -rrthreads N''​ , where N is the number of cores that should be used for graphics rendering. ​ In this implementation,​ you can use up to 16 threads.
  
 === Notes on OpenSWR ===  === Notes on OpenSWR === 
-Historically,​ Mesa software rendering has been a way of getting OpenGL-enabled software to work, albeit very slowly, on hardware without dedicated graphics-processing capabilities. ​ However, the [[http://​www.openswr.org|OpenSWR]] framework makes full use of the sse and avx capabilities of modern CPUs to produce ​excellent ​rendering performance. ​  +Historically,​ Mesa software rendering has been a way of getting OpenGL-enabled software to work, albeit very slowly, on hardware without dedicated graphics-processing capabilities. ​ However, the [[http://​www.openswr.org|OpenSWR]] framework makes full use of the sse and avx capabilities of modern CPUs to produce ​good rendering performance. ​  Recent versions of the alternative [[https://​www.mesa3d.org/​llvmpipe.html|LLVMpipe]] implementation have similar performance,​ and the ''​apps/​chpc/​compmech/​mesa/​19.0.4_swr''​ module defaults to LLVMpipe, because it supports more recent OpenGL features.
  
/var/www/wiki/data/pages/howto/remote_viz.txt · Last modified: 2019/07/19 14:15 by ccrosby