WinBoat prova l'accelerazione GPU: Windows su Linux fa un passo importante

Portare le applicazioni Windows su Linux senza affidarsi a Wine è la sfida di un software open source come WinBoat.

Come abbiamo raccontato nella guida all’uso di WinBoat, l’applicazione esegue un vero Windows 11 dentro una macchina virtuale KVM/QEMU, ne automatizza la gestione attraverso Docker o Podman e mostra le singole applicazioni sul desktop Linux tramite FreeRDP e RemoteApp. Finora, però, mancava un tassello importante: una modalità di accesso efficiente alla GPU del sistema host.

La differenza rispetto al tradizionale GPU passthrough è sostanziale: WinBoat non vuole consegnare in esclusiva una scheda video fisica alla macchina virtuale. L’obiettivo consiste nel lasciare la GPU disponibile a Linux e, contemporaneamente, permettere a Windows di sfruttarla attraverso una GPU virtuale basata su VirtIO GPU, Venus e virglrenderer. Se il lavoro arriverà a maturità, potrebbe diventare particolarmente interessante per software CAD, grafica, rendering e altre applicazioni professionali Windows che oggi risultano poco utilizzabili in WinBoat proprio per l’assenza di una vera accelerazione 3D.

WinBoat non è Wine: dentro gira davvero Windows

Per capire perché la novità sia rilevante bisogna tornare all’architettura di WinBoat: il programma non traduce le chiamate Win32 su Linux come fanno Wine, Proton o Bottles.

Come già evidenziato, WinBoat fa girare Windows dentro una VM KVM/QEMU, con il proprio kernel, i propri driver e il normale ambiente operativo Microsoft. Docker o Podman servono invece come strato di gestione: WinBoat li usa per predisporre e coordinare i componenti necessari alla macchina virtuale, automatizzando operazioni che altrimenti richiederebbero una configurazione manuale di QEMU, rete virtuale, dischi, condivisioni e servizi di supporto.

WinBoat cerca poi di nascondere il più possibile la presenza della macchina virtuale. Qui entra in gioco FreeRDP 3.x, implementazione open source del protocollo RDP: grazie alla funzione RemoteApp, Windows può esportare una singola applicazione invece dell’intero desktop. Sul sistema Linux compare quindi una normale finestra contenente Word, un gestionale o un altro programma Windows, accanto alle applicazioni native come Firefox o LibreOffice. Dietro quella finestra, però, il programma continua a essere eseguito interamente dentro Windows.

FreeRDP può trasportare sul desktop Linux il risultato prodotto dall’applicazione, ma non fornisce da solo a Windows una GPU potente. Se la VM dispone soltanto di un adattatore grafico virtuale con capacità 3D limitate, un software che usa Direct3D, Vulkan o OpenGL non può sfruttare in modo efficace la GPU fisica installata nel PC.

La finestra può quindi integrarsi perfettamente con il desktop Linux, mentre il rendering al suo interno resta lento. Il lavoro su Helios (ne parliamo al paragrafo seguente) nasce esattamente per colmare questa distanza: mantenere la GPU sotto il controllo dell’host Linux, ma consentire alla VM Windows di usarne una parte delle capacità attraverso un dispositivo grafico paravirtualizzato.

Il problema che Helios prova a risolvere

Gli sviluppatori di WinBoat stanno quindi battendo la strada di Helios, un progetto separato nato sotto il cappello dell’organizzazione winboat-org che punta a costruire un driver Windows 11 capace di comunicare con virtio-gpu e usare il protocollo Venus.

Helios non tenta semplicemente di convincere Windows che una GPU AMD, Intel o NVIDIA fisica si trovi direttamente nella VM. Costruisce invece un percorso attraverso il quale le operazioni grafiche originate nel sistema guest possono raggiungere il renderer Linux e, da lì, la GPU reale.

Il risultato ricorda concettualmente la virtualizzazione grafica già disponibile da tempo per guest Linux, ma il lato Windows rende il problema molto più complicato. Servono infatti un driver kernel per il dispositivo virtuale, un’implementazione Vulkan utilizzabile dalle applicazioni e meccanismi efficienti per trasferire comandi, memoria e sincronizzazioni fra guest e host.

Helios usa un driver KMDF anziché WDDM

Normalmente un driver grafico Windows si inserisce nell’architettura WDDM (Windows Display Driver Model): dialoga con il sottosistema grafico del kernel, in particolare con dxgkrnl.sys, e implementa una serie di interfacce DDI (Device Driver Interface) che Windows usa per gestire GPU, memoria video, code di comando, processi grafici e sincronizzazione. È il modello seguito, per esempio, dai normali driver AMD, Intel e NVIDIA.

Helios prende invece una scorciatoia volutamente diversa. Non cerca di presentarsi a Windows come un normale driver video WDDM e non deve quindi implementare tutta quella complessa infrastruttura. Il suo componente kernel funziona come un driver KMDF (Kernel-Mode Driver Framework) per il dispositivo virtio-gpu e mette a disposizione del software nello spazio utente un canale di comunicazione più diretto.

Il collegamento sfrutta DeviceIoControl, l’API di Windows che consente a un programma user mode di inviare richieste specifiche a un driver kernel. Helios registra una propria interfaccia di dispositivo, identificata tramite GUID; l’ICD (Installable Client Driver) Vulkan può individuarla, aprirla come un normale device Windows e trasmettere comandi attraverso appositi IOCTL, cioè codici che indicano al driver quale operazione eseguire.

Il vero ponte verso la GPU Linux si chiama Venus

Il cuore della soluzione che WinBoat sta adottando si chiama Venus, protocollo usato nell’area Mesa/virgl per trasportare le operazioni Vulkan attraverso una macchina virtuale.

L’idea di fondo è questa: il guest Windows non controlla direttamente la GPU fisica e non invia a essa i comandi come farebbe un normale driver installato sul sistema. Le chiamate Vulkan sono invece trasformate in un flusso di dati che può attraversare il confine tra guest e host; sul lato Linux, virglrenderer ricostruisce quelle operazioni e le inoltra al normale driver Vulkan della scheda video.

Per inserirsi in questo percorso Helios installa dentro Windows un Vulkan ICD (lo abbiamo menzionato in precedenza): è il componente che il loader Vulkan consulta per sapere quali implementazioni Vulkan sono disponibili nel sistema. Helios registra il proprio ICD attraverso il meccanismo standard che prevede l’utilizzo della chiave del registro HKLM\SOFTWARE\Khronos\Vulkan\Drivers. Non è quindi necessario che Windows consideri Helios una tradizionale GPU WDDM: per le applicazioni Vulkan è sufficiente che il loader trovi l’ICD e sappia a quale libreria affidare le chiamate.

Windows vede insomma un percorso grafico virtuale, mentre Linux continua a mantenere il controllo della GPU fisica.

WinBoat non sostituisce ancora una VM con passthrough

Helios tenta di risolvere uno dei problemi più difficili della virtualizzazione desktop senza chiedere agli utenti di acquistare una seconda GPU o dedicare quella principale a Windows. È una strada tecnicamente più complessa rispetto al passthrough proprio perché richiede un’intera catena grafica paravirtualizzata, ma potrebbe risultare molto più semplice da utilizzare una volta completata.

Per ora serve cautela: la documentazione parla apertamente di un progetto in via di sviluppo e gli stessi autori indicano ancora attività di benchmarking, ottimizzazione e integrazione del display.

WinBoat vuole nascondere la macchina virtuale dietro applicazioni che sembrano normali finestre Linux; Helios prova ora a fare qualcosa di simile con la GPU, mantenendola sotto il controllo dell’host e offrendo al guest potenza grafica sufficiente da rendere utilizzabili programmi che finora rimanevano esclusi.