deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak Hacker News – Front Page (native)

virtio-nvgpu, driver ioctl'larını ileterek KVM guest'lere近乎 native NVIDIA GPU erişimi sağlıyor

Deneysel bir virtio device, NVIDIA kernel driver ioctl'larını KVM guest'ler ile host arasında ileterek, değiştirilmemiş guest driver'larının dört VM tek bir kartı paylaşırken bare-metal hızının %2'si içinde render etmesini sağlıyor.

virtio-nvgpu, driver ioctl'larını ileterek KVM guest'lere近乎 native NVIDIA GPU erişimi sağlıyor

nestrilabs, host'taki bir NVIDIA GPU'ya KVM sanal makinelerine yakın-native erişim sağlayan deneysel bir virtio device olan virtio-nvgpu'yu yayınladı. Hacker News ana sayfasına ulaşan projenin GitHub repository'sine göre, bir guest aynı makinede bare-metal frame sürelerinin %2'si içinde, aynı CPU maliyetiyle render ediyor.

API çevirmek yerine ioctl iletmek

Mekanizmanın özü, çevirinin nerede gerçekleştiğinde yatıyor. Venus gibi yaklaşımlar guest'teki tekil Vulkan veya OpenGL çağrılarını serileştirip host'ta yeniden oynatır. virtio-nvgpu ise bunun yerine kernel driver ABI seviyesinde çalışıyor ve NVIDIA'nın kernel driver'ının işlediği ioctl'ları guest ile host arasında iletiyor.

Guest, NVIDIA'nın kendi user-mode driver yığınını — Vulkan, NVENC ve gerisini — değiştirilmeden, aynı fiziksel kart üzerinde çalıştırıyor. Bu kütüphaneler command buffer'ları guest belleğinde yerel olarak inşa ettiği ve o bellek host'unkine eşlendiği için, tekil draw call'ları hiçbir zaman sınırı geçmiyor. 813.691 benchmark frame'i boyunca backend yalnızca 13.792 mesaj servis etti; bu, kabaca her 59 frame'de bir geçiş demek ve bunun neredeyse tamamı device kurulumu.

Ölçümler

Rakamlar, 595.99.02 driver'ını çalıştıran bir RTX 3060'dan geliyor; aynı host'un bare-metal halindeki aynı headless Vulkan yükü altındaki sonuçlarıyla karşılaştırılıyor. Host'un 39 ms, 9,9 ms veya 2,0 ms'de çizdiği frame'lerde guest, bare-metal'in %2'si içinde kalıyor — 39 ms'lik frame bare-metal'den %0,4 daha hızlıydı; proje bunu gürültüye bağlıyor. Overhead yalnızca frame başına yaklaşık 2 ms'nin altında görünüyor: 0,5 ms'de +%7,1 ve 0,05 ms'de +%40,8; bu noktada tek bir wake yaklaşık 0,02 ms'ye mal oluyor. Oyunlar 2 ms'den çok daha ağır frame'ler çizdiği için, proje fast path'i normal durum olarak değerlendiriyor.

100 fps'ye yakın 12 saniyelik hızlandırılmamış bir koşuda CPU kullanımı host için 0,40 s, guest için 0,37 s oldu. Guest içinde nvidia-smi kartın gerçek güç ve belleğini raporluyor ve vulkaninfo hatasız çıkıyor. Uçtan uca bir demoda, bir Wayland client'ı guest compositor üzerinden sunum yaptı, frame'ler aynı GPU üzerinde Vulkan Video ile kodlandı ve ffmpeg ortaya çıkan 618 H.264 frame'ini hatasız decode etti.

Tek kartta dört guest

Aynı yükü tek bir RTX 3060 üzerinde çalıştıran dört guest 25,84, 26,49, 25,57 ve 25,79 fps'ye ulaştı — toplamda 103,7 fps, tek bir guest için 102,9'a karşı — ve medyan frame süreleri 39,164 ile 39,168 ms arasında, dört ondalık basamağa kadar eşleşecek şekilde. Dördü de 60 Hz'de eşzamanlı olarak render edip H.264 kodladı ve bir NVENC session limitine takılmadı. Proje dört tanesini çalıştırdı; bunu bir limit olarak belirlemedi.

Headless streaming için tasarlandı

Belirtilen hedef, monitörsüz bir VM'den streaming: bir oyun render ediyor, guest tarafındaki bir Wayland compositor pencereleri birleştiriyor, CUDA zero-copy birleştirilmiş frame'i içe aktarıyor ve NVENC onu kodluyor; böylece makineden yalnızca frame başına kabaca 100 KB'lık sıkıştırılmış bir H.264 veya H.265 bitstream çıkıyor.

Repository, mevcut seçeneklerin bu pipeline için neden yetersiz kaldığını açıklıyor. Venus tarzı API çevirisi, draw-call yoğun iş yüklerinde frame başına 1–3 ms serileştirme maliyetine yol açıyor — 60 fps'de 16,6 ms'lik bütçenin %6–18'i — ve host CPU'sunu yakıyor; host'a ait buffer'lar ise guest tarafı kodlamaya pratik bir yol bırakmıyor. DRM native context, Intel ve AMD guest'lerinin command buffer'larını yerel olarak inşa etmesini sağlıyor ama NVIDIA için bir eşleniği yok. VFIO passthrough native ancak GPU'nun tamamını tek bir VM'e devrediyor; çok kiracılı (multi-tenant) hosting bunu çoğu zaman kabul edemiyor.

Yapı, lisanslar ve sınırlar

Repository, üç lisans bölgesine yayılmış dört bileşen içeriyor. driver/, /dev/nvidia* device'larını kaydeden ve ioctl'ları ile mmap'ları virtqueue üzerinden ileten GPL-2.0 bir guest kernel modülü. device/, bağımlılık listesinde hiçbir sanal makine monitörü (VMM) bulunmayan Apache-2.0 lisanslı bir Rust crate'i; bir VMM, küçük bir trait kümesini uygulayarak onu benimseyebiliyor. protocol/, her iki yarımın paylaştığı çift lisanslı ABI tanımlarını taşıyor ve yerleşim chromeos/virtio-media'yı izliyor. isolate/, gerçek device dosya tanımlayıcılarını tutacak sandbox'lı, guest başına bir helper için bir tasarım notu; henüz yazılmadı ve backend bugün onları VMM'in süreci içinde kendisi tutuyor.

Sınırlar açıkça belirtilmiş: 720p'deki vkcube'dan daha ağır bir şey denenmemiş, iki kart kullanılmış ama yalnızca biri benchmark'lanmış, CUDA iletiliyor ama enumeration ötesinde test edilmemiş ve çok kiracılı izolasyon zarfı inşa edilmemiş. ABI profilleri 535.129.03, 580.178.04 ve 595.71.05 driver sürümlerini kapsıyor, aralığa göre eşleştiriliyor ve ilkinden daha eski her şey reddediliyor.

Neden önemli

NVIDIA, Linux GPU sanallaştırmasında eksik kalan üreticiydi: Intel ve AMD guest'leri command buffer'larını yerel olarak inşa edebiliyordu, NVIDIA guest'leri edemiyordu. virtio-nvgpu bu boşluğu, ölçülen overhead'i oyunların gerçekte ürettiği frame boyutlarında neredeyse sıfır olan ve tek bir kartı throughput kaybetmeden birkaç guest arasında paylaşan bir mimariyle kapatıyor. Sonuçlar 720p'lik bir demonstrasyonun ötesinde de tutarsa, GPU-host edilmiş oyun streaming'i ve çok kiracılı render daha ucuz hale gelir; çünkü bir kartın artık tek bir VM'e sabitlenmesi gerekmez. Yazılmamış sandbox ve test edilmemiş CUDA onu deneysel tutuyor — ama performans iddiası ölçülmüş, ileri sürülmüş değil.

  • #virtualization
  • #kvm
  • #nvidia
  • #gpu
  • #linux
  • #open-source

İlgili yazılar