Virgil in PD 17.1 (if your graphics slow, there is an answer :) )

Discussion in 'Linux Guest OS Discussion' started by (GalaxyMaster), Oct 21, 2021.

  1. (GalaxyMaster)

    (GalaxyMaster) Kilo Poster

    Messages:
    114
    Finally, after so many years Parallels Inc did a very good move and introduced support for virtio-gpu inside Linux guests. What does it mean to us, consumers? For starters, any modern distribution will be able to fully utilise hardware acceleration inside a guest running on PD 17.1 without even installing any "guest tools". Nice, isn't it?

    OK, there is a catch in described in one of Parallels' KB (I can recall the number or URL), the new functionality is only available under several conditions:
    • you are creating a new VM profile with PD 17.1
    • you are installing Parallel Tools into the existing VM and your kernel is newer than 5.10.
    Unfortunately, whoever made a detection logic for the latter case made a mistake in their `awk` foo and as the result the command for detecting the version *does not* work. You can either fix the command or do what I did, which is:


    1. get rid of the `prl_vid.ko` module for your kernel (i.e. delete `/lib/modules/<your_kernel_version>/extra/prl_vid.ko*`) -- this ensures that prl_vid.ko won't be loaded on boot;
    2. ensure that `virtio_gpu` is *NOT* blacklisted in `/etc/modprobe.d/blacklist-parallels.conf`, if it is then comment it out -- this ensures that virtio_gpu is going to be loaded on boot
    3. restore your /usr/lib*/libEGL.so*, /usr/lib*/libGL.so*, and /usr/libgbm.so* files to the ones provided by your distribution (if you are running something like Fedora, then the easiest way would be to re-install the packages providing these files -- you can get info on the package name by using "rpm -qf /usr/lib64/libEGL.so.1"; for Arch, it is the same but the command would be "pacman -Qo /usr/lib/libEGL.so.1") -- this removes shims Parallels put in to handle OpenGL through their proprietary drivers and will enable to use the distro provided libraries to their fullest;
    4. restore libglx.so in `/usr/lib*/xorg/modules/extensions/` (you would want that file to come from your distro and not from Parallels, use the above trick to locate the name of the package to re-install)
    5. remove Parallels' drivers for video from your Xorg (i.e. `rm /usr/lib/xorg/modules/drivers/prl*`)
    6. remove Parallels' configuration drop-ins for Xorg (i.e. `rm /usr/share/X11/xorg.conf.d/*-prl*.conf`)
    7. ensure that you have at least one video driver for Xorg (e.g. the fbdev). You can install both fbdev and vesa Xorg drivers just to be safe
    8. ensure that you have the modesetting_drv.so in /usr/lib*/xorg/modules/driver/ -- this is the primary driver that will be used by your Xorg
    At this point in time we cleaned up the VM from Parallels Tools (as it relates to video drivers), so we need to shut the VM down and fix the host side of things.

    Once the VM is shutdown, go to your Parallels Control Center and click on a plus in the upper right corner, this will present you with the "Create New..." dialog. Follow the steps described below to create a new and empty profile for the VM:
    1. click on the "Install ... from a DVD or image file", then click on the "Continue" button
    2. on the next screen click on the "Choose Manually" button, then checkmark the "continue without source" box in the lower left, and click on the "Continue" button
    3. In the popup you will get, choose the closest operating system to your VM you are fixing (in my case, I chose "Fedora Linux" since PD does not support Arch Linux) -- this choice is not very important as long as you chose sme Linux distro and not Windows :)
    4. On the "Name and Location" screen you need to checkmark the "Customize settings before installation" box and give a name for your new VM profile (it should be different from the one you just stopped, since the name defines the directory name for all files associated with the profile)
    5. Click on the "Create" button
    At this point, you will have a brand new, but completely empty VM created in your ~/Parallels/ folder .
    Now, we need to link out virtual hard drives to that new VM and configure the settings of the profile to the way we like. The configuration of memory and CPU I will leave to you, but the hard drives swap in I will describe.
    1. When a new VM was created, Parallels would most likely provision the default virtual hard drive. We need to get rid of it. To do so, click on "Hardware" icon, then scroll down till you see "Hard Disk", click on it, and then click on the "-" button. If you want to play safe, let parallels move that disk to Trash (so you will be able to retrieve it if needed, but I doubt that you need an empty image :) )
    2. Now, open Finder or Terminal and copy (or move, if you are tight on space) your virtual hard drives from the folder of your old VM to the folder of the new VM (the virtual hard drives are directories ending with ".hdd"
    3. Once the hard drives were copied/moved over, click on the "+" button and select "Hard disk"
    4. In the new window, for the type select "Existing image file" from the drop down, then click on Location's drop down, and navigate to ~/Parallels/Name_of_your_new_VM, descend into the first virtual hard disk, and select the only file you have with the ".hdd" suffix. That file is 0 bytes long, but it is expected. Click the "Open" button, then click the "OK" button -- your virtual hard disk will be added to the profile
    5. Repeat step 4 for any additional virtual hard disks you copied/moved over
    At this stage, the new VM profile is ready to roll (given that you configured memory and CPU). So, start it and you should see a huge performance boost to your graphics + you will get your OpenGL sorted.

    To verify that everything is working, once the VM has booted, open the terminal and issue the followinng commands (and compare their output to mine):
    Code:
    [root@archlinux ~]# dmesg | grep '\[drm\] features'
    [    6.955900] [drm] features: +virgl -edid -resource_blob -host_visible
    [root@archlinux ~]# dmesg | grep 'virtio_gpu'
    [    7.006813] [drm] Initialized virtio_gpu 0.1.0 0 for virtio2 on minor 0
    [    7.161649] virtio_gpu virtio2: [drm] fb0: virtio_gpu frame buffer device
    [root@archlinux ~]#
    The above is run under root (you may get away by prefixing "dmesg" with "sudo", but my system does not have "sudo". The first command confirms that "virgl" is enabled for your VM, the second shows that "virtio_gpu" detected the device.
    Now, under your normal account run the following and compare to my output:
    Code:
    [galaxy@archlinux ~]$ xdriinfo
    Screen 0: virtio_gpu
    [galaxy@archlinux ~]$ glxinfo | grep 'OpenGL renderer'
    OpenGL renderer string: virgl
    [galaxy@archlinux ~]$
    The first command here confirms that Xorg is using modesetting_drv and leveraging virtio_gpu, while the second command demonstrates that accelerated virgl code is used by OpenGL.

    That's all, have fun folks. I hope this helped somebody :)
     
    Dmitry@Parallels likes this.
  2. Mark Fine

    Mark Fine Kilo Poster

    Messages:
    480
    Other reason(s): You don't have to use classic Gnome over xorg anymore.
    You can start using Wayland and you will be able to use Gnome 4.0 (actually 4.1, now)
     
  3. (GalaxyMaster)

    (GalaxyMaster) Kilo Poster

    Messages:
    114
    Well, 24 hours in and I see some issues with the Virgil implementation. My VM is using Apple's HV and what I found is that Chromium can trigger a VM crash when it is extensively using GPU for rendering. This is an unpleasant crash since VM just disappears instantly like it was never running at all. I am yet to trigger this on Fedora, but Arch is _very_ unstable in this regard. I would blame myself and that I misconfigured something inside the VM, but in my mind, the whole point of virtualisation is to contain stuff and no matter what I do inside the VM it should not be able to crash the VM process as it is seen from the host system.
     
  4. Mark Fine

    Mark Fine Kilo Poster

    Messages:
    480
    Try switching to the Parallels hypervisor. For some reason, the Apple one was causing one of my CPUs to halt when it wasn't even under load.
     
  5. andrewsi1

    andrewsi1 Bit Poster

    Messages:
    3
    same issue here also.
     

Share This Page