Hello, Thanks for the suggestion on using Nvidia. An Nvidia card worked much better.
In case anyone needs them, here are my notes on getting VirtualGL to work: Thanks, Jason ============================================================================== ## These instructions are my rough notes. I still need to do a wipe and rebuild to verify and clean up the instructions. ## These instructions are tailored for installing Virtgual GL on a server running RHEL 7.6 with two graphics cards. Xorg DISPLAY :0 is an integrated Matrox graphics card that is not suitable for use with VirtualGL. The second video card is an Nvidia M4000. We set up a second Xorg instance running on DISPLAY :1 and use that for VirtualGL. Display :1 is running NOTHING, not even lightdm/gdm. # My efforts with an AMD card failed. The 18.50 version of the AMD proprietary driver caused the kernel to crash 5 minutes after boot. Using the RedHat-supplied drivers would not work with Virtual GL. # all commands should be run as root. for the most part, these should just be copy and paste into a command-line (bash) # lightdm is probably not needed. The server can run the multi-user target without a GUI. yum -y install lightdm systemctl stop gdm systemctl disable gdm systemctl enable lightdm systemctl start lightdm systemctl isolate multi-user.target # We need both 32bit and 64bit virtualGL if the application is 32bit. rpm -e VirtualGL --allmatches wget -O /tmp/VirtualGL-2.6.1.x86_64.rpm https://sourceforge.net/projects/virtualgl/files/2.6.1/VirtualGL-2.6.1.x86_64.rpm/download yum -y localinstall /tmp/VirtualGL-2.6.1.x86_64.rpm wget -O /tmp/VirtualGL-2.6.1.i386.rpm https://sourceforge.net/projects/virtualgl/files/2.6.1/VirtualGL-2.6.1.i386.rpm/download yum -y localinstall /tmp/VirtualGL-2.6.1.i386.rpm ## # install the nvidia driver from elrepo # Remove ocl-id because it conflicts with the nvidia driver because of OpenCL yum -y remove ocl-icd.x86_64 nvidia-detect | grep -qs kmod && yum -y install $(nvidia-detect) # lammps will be reinstalled by puppet on the next puppet run # reboot for the nvidia drives to detect everything. reboot # Grab the bus ID for the nvidia card. this should similar to "PCI:1:0:0". lspci can provide the same info, but the format is slighly different. nvidia-xconfig shuold provide a format that is compatible with "Xorg -isolateDevice" bus=$(nvidia-xconfig --query-gpu-info|grep PCI|awk '{print $4}') #### ### Configure a new Xorg server on Display :1. Configuration is two-stage, because nvidia-xconfig assumes DISPLAY :0 and doesn't allow you to override it on the command line. Xorg :1 -configure -isolateDevice $bus # xorg written as /root/xorg.conf.new # Run "Xorg :1 -config /root/xorg.conf.new" and check for errors. Ctrl-C to cancel cp -f /root/xorg.conf.new /etc/X11/xorg.1.conf # Add the magic nvidia bits to xorg.conf nvidia-xconfig -a --allow-empty-initial-configuration --busid=$bus --use-display-device=none --virtual=1920x1200 -c /etc/X11/xorg.1.conf ### Set up a systemd service to manage Xorg Display :1 ### begin headlessx.service ##### Just copy and paste into bash cat > /etc/systemd/system/headlessx.service <<EOF [Unit] Description=Headless X server for VirtualGL After=network.target [Service] Type=simple ExecStart=/bin/bash -c "Xorg :1 -config /etc/X11/xorg.1.conf" Restart=on-failure [Install] WantedBy=multi-user.target EOF ### end headlessx.service ##### systemctl daemon-reload systemctl enable headlessx systemctl restart headlessx #configure VirtualGL systemctl stop lightdm # configure virtualGL to allow all users. disable XTEST /opt/VirtualGL/bin/vglserver_config -config +s +f -t # refresh X display permissions as changed by vglserver_config systemctl stop headlessx rmmod nvidia_drm nvidia_modeset nvidia systemctl start headlessx #rmmod nvidia_drm nvidia_modeset nvidia #systemctl isolate graphical.target reboot ######## example commands below for running VirtualGL as a normal user. This is intended for use with the StarNet FastX. #Testing VirtualGL. Login to fastX. Tested by RDP to mws939, then fastX to lxs-hfss2 #vglrun -c proxy +v /opt/VirtualGL/bin/glxspheres64 VGL_DISPLAY=:1 vglrun -c proxy +v /opt/VirtualGL/bin/glxspheres64 # To accelerate an entire FastX session, login to the FastX admin web backend and add a new bookmark. For Mate, the command should be the following: /bin/bash -c 'VGL_DISPLAY=:1 vglrun -c proxy +v mate-session' On Tue, Jan 22, 2019 at 5:29 PM DRC <[email protected]> wrote: > Things to try: > - Run ‘/opt/VirtualGL/bin/glreadtest -pbo’ directly on Display :1. That > will validate whether Pbuffers are working properly. > - Run ‘/opt/VirtualGL/bin/glxspheres64 -i’ directly on Display :1 and take > a screenshot to verify that the application is displaying properly. That > will validate whether OpenGL is working properly on the 3D X server. > - Try displaying glxgears with vglrun to :0 without fastX, rather than to > :101, and see if that works. > - Try displaying glxspheres64 with vglrun rather than glxgears, and see if > that works (NOTE: in VirtualGL land, glxspheres/glxspheres64 is *always* > the baseline test, not glxgears.) > > The error message would suggest a problem with the 2D X server, since that > is where the X_CreatePixmap request is being sent. It may be that glxgears > (NOTE: you said you were trying to run glxgears, but your command line > showed glxinfo— please clarify) doesn’t work but other OpenGL applications > that don’t use Pixmaps do, so that’s why I suggested running glxspheres > instead. > > In general, you’re not likely to get good performance with Red > Hat-supplied drivers, and I echo your experience with the AMD proprietary > drivers having either poor stability or compatibility. I wish AMD would > prove me wrong about that, but right now, both of my AMD GPUs are stuck on > RHEL 6 for compatibility reasons. Meanwhile the nVidia GPUs I have that are > of similar or older vintage continue to be supported on the latest Linux > distributions. I don’t want VirtualGL to be an nVidia-only solution, but > the reality is that most serious VGL users are on nVidia hardware, because > there seems to be a significantly higher probability that nVidia hardware > and drivers will actually work properly with VGL. > > On Jan 22, 2019, at 4:01 PM, Jason Edgecombe <[email protected]> wrote: > > Hi everyone, > > I'm having trouble setting up virtualGL. I'm running a server with two > graphics card. I'm using the integrated graphics (Display :0) for normal X > and an AMD card (Display :1) for virtualGL. > > I configured the 2nd X server using the command commands: > > % /opt/VirtualGL/bin/vglserver_config -config +s +f -t > % Xorg :1 -configure -isolateDevice 'PCI:3:0:0' > # xorg written as /root/xorg.conf.new > > I put the command "Xorg :1 -config /root/xorg.conf.new" in a systemd > service. > > Display :1 is headless. I can set "DISPLAY=:1" and run xterm without any > output. Taking a screenshot of display :1 confirms that the program > displayed. > > a simple test of glxgears with vglrun fails for me. > > % vglrun +v -d :1 glxinfo > [VGL] Shared memory segment ID for vglconfig: 6193165 > [VGL] VirtualGL v2.6.1 64-bit (Build 20190101) > name of display: :101.0 > [VGL] Opening connection to 3D X server :1 > [VGL] Using Pbuffers for rendering > failed to create drawable > X Error of failed request: BadValue (integer parameter out of range for > operation) > Major opcode of failed request: 53 (X_CreatePixmap) > Value in failed request: 0x1e > Serial number of failed request: 33 > Current serial number in output stream: 34 > > I'm connected to the server using fastX. The goal is to use vglrun to do > 3D rendering on display :1 and have the output display in my remote FastX > session (display :101). I'm not using vglconnect, because the X application > and graphics card are in the same machine. > > I'm running on RHEL 7.6 with the RedHat-provided AMD drivers, because the > proprietary drivers caused the server to crash every 5 minutes. > > Any help is appreciated. > > Thanks, > Jason > > -- > You received this message because you are subscribed to the Google Groups > "VirtualGL User Discussion/Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/virtualgl-users/c9c7263c-3d16-4d14-947c-63e9fae522fc%40googlegroups.com > <https://groups.google.com/d/msgid/virtualgl-users/c9c7263c-3d16-4d14-947c-63e9fae522fc%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "VirtualGL User Discussion/Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/virtualgl-users/EEBD0622-7594-4830-8615-77FE77C8D4F4%40virtualgl.org > <https://groups.google.com/d/msgid/virtualgl-users/EEBD0622-7594-4830-8615-77FE77C8D4F4%40virtualgl.org?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/CAAR6MGCZSE8BX-nhXuNFge6ukGqXk%3DdB9j_TCcN6d-UtmsOrhQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
