Il miglior pesce d'aprile del mondo Linux? La proposta di integrare Zink in Wine che in realtà funziona

Una merge request aperta su GitLab di WineHQ potrebbe cambiare sostanzialmente il modo in cui Wine gestisce le chiamate OpenGL. A firmarla è Rémi Bernon, sviluppatore di CodeWeavers (la società che collabora con Valve allo sviluppo di Proton) con una proposta dal titolo diretto: "opengl32: Just use Zink (as PE-side OpenGL implementation)". L'annuncio è arrivato il primo aprile e Bernon ha confermato che la MR nasceva come omaggio scherzoso all'April Fool's Day ma allo stesso tempo ha specificato che il codice funziona davvero e che l'approccio è "genuinamente interessante e merita di essere esplorato".

L'architettura della proposta

Il meccanismo è semplice nella formulazione e con implicazioni sostanziali: la merge request incorpora direttamente un sottoinsieme di Mesa 26.0.3 compilato come DLL Windows, usando Zink come implementazione OpenGL lato PE sopra un layer Vulkan anch'esso lato PE. In pratica, le applicazioni Windows in esecuzione su Wine che fanno chiamate OpenGL le vedrebbero gestite da Zink, che le traduce in chiamate Vulkan prima che raggiungano il driver host. Nella proposta originaria Bernon riporta che sia Steam sia Star Wars: Knights of the Old Republic funzionano con questa configurazione: "which means everything else will as well".

Sul fronte delle prestazioni, Bernon ha ammesso che l'implementazione è attualmente più lenta del bridge Unix GL esistente. Non si tratta di un degrado drammatico dato che le applicazioni girano e il risultato è utilizzabile, ma nei benchmark come quelli della suite Unigine il divario è misurabile. Si tratta di limite atteso per una proposta ancora in forma grezza, non un indicatore della validità o meno dell'approccio: Zink ha già dimostrato nel corso degli anni di poter raggiungere e in alcuni casi superare le implementazioni OpenGL native, ma richiede un lavoro di ottimizzazione dedicata.

Un driver che ha percorso molta strada

Zink non è un progetto recente: il driver è stato introdotto nel 2018 da Erik Faye-Lund di Collabora come implementazione OpenGL hardware-accelerata per sistemi con solo un driver Vulkan disponibile. Tecnicamente è un driver Mesa Gallium: invece di generare comandi specifici per l'hardware come fanno i driver tradizionali, produce chiamate Vulkan hardware-agnostiche che vengono poi delegate all'implementazione Vulkan del sistema. Questo meccanismo permette di ottenere supporto OpenGL completo anche quando il driver della GPU non ne dispone nativamente, il che ha implicazioni rilevanti sia per hardware vecchio sia per GPU senza driver OpenGL dedicato.

Dall'introduzione nel 2018, Zink è stato oggetti di miglioramenti sostanziali. Una tappa fondamentale è arrivata nel 2022 con il merge di Kopper, il componente che ha permesso a Zink di gestire la window system integration tramite Vulkan WSI. Prima di Kopper, l'uso di Zink richiedeva combinazioni di variabili d'ambiente poco pratiche; con Kopper, MESA_LOADER_DRIVER_OVERRIDE=zink è sufficiente per qualsiasi driver, e Zink acquisisce swapchain vere con pieno supporto ai compositori. Mesa 26.0, da cui è estratto il sottoinsieme proposto per Wine, include fix mirati al driver Zink nelle release di manutenzione 26.0.2 e 26.0.3, comprese correzioni alla logica di conversione dei formati e alla gestione delle immagini generate.

Perché la proposta ha senso tecnico

Il razionale dietro l'integrazione di Zink in Wine riguarda la compatibilità cross-driver. Oggi il layer OpenGL di Wine agisce come bridge verso l'OpenGL del sistema host: le applicazioni Windows ereditate dipendono quindi dalla qualità dell'implementazione OpenGL del driver installato sulla macchina dell'utente. Vulkan opera a un livello più basso e tende a essere meno soggetto a queste variazioni tra implementazioni diverse, il che si traduce in una superficie di compatibilità più prevedibile. Bernon ha citato esplicitamente il caso di macOS come scenario emblematico: Apple ha deprecato OpenGL da anni e il bridge Unix GL in Wine incontra su quella piattaforma problemi di compatibilità strutturali che un'implementazione PE-side sopra Vulkan potrebbe aggirare in modo netto.

Il contesto industriale non è irrilevante. Il focus dei produttori di driver si è spostato progressivamente su Vulkan: il caso più evidente è NVIDIA, che ha dismesso il driver Nouveau legacy basato su OpenGL in favore di NVK, la nuova implementazione Vulkan open source. Se in futuro altri driver abbandonassero il supporto OpenGL nativo, la possibilità di contare su un'implementazione OpenGL integrata in Wine e che dipende solo da Vulkan host garantirebbe compatibilità senza richiedere interventi sull'infrastruttura del sistema.

Il percorso verso un'architettura ICD

Bernon ha indicato che la soluzione ideale a lungo termine non sarebbe scegliere tra il bridge Unix GL attuale e l'implementazione Zink PE-side, ma renderle coesistenti tramite un meccanismo ICD (Installable Client Driver), analogo a quello usato da Vulkan. Questo permetterebbe a Wine di caricare dinamicamente l'implementazione OpenGL più adatta al contesto, che si tratti del bridge Unix per chi ha un driver OpenGL maturo, o Zink per chi non ce l'ha o lo ha parziale, senza che l'utente debba intervenire manualmente. L'autore riconosce che questa strada richiederebbe un refactoring significativo dell'infrastruttura OpenGL di Wine, e che la merge request attuale è lontana da quel modello; resta però un obiettivo architetturale dichiarato. La proposta è al momento in fase di revisione e non è ancora chiaro se e quanto cambierà prima di un eventuale merge nelle build ufficiali.