vladmradio

Випадково помітив як те, що обіцяли 2 роки тому, справдилосі:

Mesa Venus serializes Vulkan instructions on guest & sends them to host, which means GPU accelerated Vulkan on QEMU VMs, without GPU passthrough. Venus is same as VirGL, except it uses Vulcan instead of OpenGL.

Одного дня ви прокинетеся і побачите як слопгазети напередодні написали що ваша ОС більше не збирається тягати бібліотеки opengl, а 3d аватар полетівшого на луну Джона Кармака зазначить що 'ганебна інерція' була єдиною причиною за якою люди не полишили opengl 10 років тому, але пізно є краще аніж ніколи.

Щоб мати працюючий компóзітор ув VM раніше робили або gpu passthrough до QEMU, або користувалися vmware ws, яка мала звичку залиппппати на amdgpu з увімкненою 3d акселерацією. З QEMU без окремого gpu для кожної VM залишалося сумувати.

Але зараз всі негаразди є позаду! Попереду--захопливі часи, якщо guest+host є лайнакс (we got both kinds: country & western).

Ви коли-небудь тестуєте інші дістро? Дивитеся на колотнечу ув сусідньому таборі? Зазвичай є live iso, але як їх швидко подивитися без створення VM, чи записування того .iso на usb драйва?

Сучасний QEMU емулює фіктивного дівайса, який називається virtio-gpu. Зі свіжими (4-річної давнини) драйверами mesa на обох host та guest, свіжим кернелом (4-річної давнини) та свіжим графічним тулкітом (gtk3 4-річної давнини), guest використовує по протоколу virgl host'овий gpu для акселерації opengl. Зі сторони host'а йому відповідає бібліотека virglrenderer.

Майбутній світ opengl не використовує, а наполягає на vulkan. Якщо зійти з теми та згадати що рік тому llama.cpp отримала підтримку останнього, після чого навіть найпростіші інтегровані gpu стали у кілька разів швидше за cpu поряд стріляти токенами (якщо користувач для того має вдосталь ram), то заперечувати його корисність стає складно.

Нові дістро, окрім virgl, підтримують також venus, який працює за тією самою схемою, але акселерує vulkan замість opengl.

Перевірити це можна так:

(host) $ (. /etc/os-release && echo $PRETTY_NAME)
Fedora Linux 44 (Forty Four)

(host) $ alias qemu3d='qemu-system-x86_64 -enable-kvm -m 4G \
    -device virtio-vga-gl,hostmem=2G,blob=true,venus=true \
    -display gtk,gl=on'

(host) $ qemu3d debian-live-13.5.0-amd64-xfce.iso

Тест opengl:

То є вікно віртуальної мошини, а не хоста. Водичка морська там є не відео, а рендер шейдера за допомогою хостового gpu. Якщо ви думаєте що нічого особливого ув тому немає (біґ діл, комп'ютери зараз швидкі), спробуйте прибрати "-device virtio-vga-gl,…" і подивіться скільки fps воно намалює (підказка: жалюгідну цифру).

Синтетичний тест vulkan можна зробити

(guest) $ vkmark --fullscreen -b texture

і подивитися з -D $UUID (vkmark -L друкує списка всіх gpu) на різницю з software рендеринґом, але до RL це відношення мати не буде. Наприклад,

(host) $ GSK_RENDERER=vulkan gtk4-demo --run gears

запускається без проблем, але робить coredump ув guest.

Більш цікавий тест буде з іграшкою supertuxkart, яка отримала підримку vulkan кілька років тому.

Після розпакування .tar.gz:

(guest) $ ./run_game.sh --render-driver=vulkan \
    --screensize=1920x1080 -f --benchmark

якщо fps буде >= частоти оновлення монітора, venus працює.

Персистенція live iso

Недолік більшості live дістро полягає ув їх ефемерності: як тільки знищити QEMU процеса, всі налаштунки VM зникають. Деб'ян вміє робити оверлей / з додатковим партішоном на справжньому hardware, проте ув середині .iso ніякого writable додаткового партішона немає, тому оверйлеїть там є ні з чим.

Якщо підготувати lol.qcow2 хфайла, який (а) має хфайлову систему з лейблом persistence, та (b) хфайла persistence.conf на тій хфайловій системі, то з

(host) $ qemu3d -hda debian.iso -hdb lol.qcow2

така VM стане майже справжньою. Тобто не стане, тому що доведеться ще змінити boot/grub/grub.cfg всередині .iso, але як ви то зробите, коли loop дівайса буде змонтований ув read-only? Суто лайнакський винахід, де замінюють одні 12 байт на інші 12 байт:

(host) $ export LANG=C
(host) $ sed -i 's/splash quiet/persistence /;s/quiet splash/persistence /' \
    debian.iso

Варіянт божевільних (мій улюблений): додати ext4 партішона до .iso. Тоді такий деб'ян можна таскати як однохфайлову VM або зdd'їти її на usb драйва і ув обох випадках отримати персистенцію. Скрипта

(host) $ ./mdlip 2G debian-live-13.5.0-amd64-xfce.iso new.iso

додає 2GB до копії оригінального .iso та підготовлює ті гігабайти ув манері lol.qcow2. На жаль, менше за 38 рядків не вийшло:

#!/bin/sh

set -e

eh() { echo "mdlip error: $*" 1>&2; exit 1; }
cc() { for c; do command -v "$c" > /dev/null || { eh "no $c"; }; done; }

cc file sfdisk mkfs.ext4

size=$1; in=$2; out=$3

[ $# = 3 ] || eh 'Usage: mdlip SIZE in.iso out.iso'
[ "`file -b --mime-type "$in"`" = application/x-iso9660-image ] || eh 'bad .iso'
echo "$size" | grep -qxE '[0-9]+[MG]?' || eh "invalid SIZE"

export LANG=C
out_dir=`dirname "$out"`
tmp_dir=`mktemp -d "$out_dir/mdlip.XXXXXX.tmp"`
echo / union > "$tmp_dir"/persistence.conf
iso="$tmp_dir.iso"

trap 'rm -rf $tmp_dir $iso' 0 1 2 15

# STEP 1: replace bytes inside (hopefully) boot/grub/grub.cfg & resize the image
sed 's/splash quiet/persistence /;s/quiet splash/persistence /' < "$in" > "$iso"
truncate -s +"$size" "$iso"

# STEP 2: convert free space into a partition
sfdisk -F "$iso" | tail -1 |
    awk '{printf "start=%s, size=%s, type=L\n", $1, $3}' |
    sfdisk -q --append "$iso"

# STEP 3: create a filesystem & copy a .conf file to it
set -- `sfdisk -l "$iso" | tail -1 | awk '{print $2, $4}'`
mkfs.ext4 -q -L persistence -E offset=$(($1 * 512)) -d "$tmp_dir" "$iso" \
          $(($2 * 512 / 1024))

mv "$iso" "$out"

Якщо потім виявиться що 2GB було замало, можна завжди додати більше:

(host) $ truncate -s +2G new.iso
(host) $ echo ', +' | sfdisk -N 3 new.iso
(guest) $ sudo resize2fs /dev/sda3