DirectX 12 contro Vulkan: l'API grafica non garantisce le prestazioni
Direct3D 12 e Vulkan danno controllo esplicito ai motori, con piattaforme diverse da considerare. Contano backend e implementazione, oltre al marchio.
DirectX 12 e Vulkan vengono spesso presentati come modalità concorrenti per ottenere più prestazioni. Per uno sviluppatore sono interfacce attraverso cui il motore affida lavoro alla GPU. Per chi gioca sono implementazioni realizzate dagli autori del gioco. Nessuno dei due nomi promette un frame rate maggiore indipendentemente da motore, driver e carico.
Il confronto preciso riguarda Direct3D 12, l'API grafica della famiglia DirectX di Microsoft, e Vulkan, l'API grafica e di calcolo multipiattaforma del Khronos Group. Questa distinzione evita di trattare un'intera piattaforma multimediale come un singolo interruttore del rendering.
Più controllo significa anche più responsabilità
L'introduzione Microsoft a Direct3D 12 descrive un'API che dà alle applicazioni un controllo più esplicito su gestione delle risorse e invio del lavoro. Khronos presenta Vulkan come un'API multipiattaforma e multifornitore che offre accesso a basso livello all'hardware grafico e di calcolo.
Un controllo esplicito può aiutare il motore a organizzare il lavoro con efficienza. Lascia però più decisioni al gruppo di sviluppo. L'applicazione deve coordinare correttamente risorse e dipendenze: un'interfaccia di livello inferiore non rende automaticamente migliori queste scelte. Offre spazio per eliminare un collo di bottiglia e, insieme, più occasioni per crearne uno.
Consideriamo una scena che attende ripetutamente una risorsa prima di proseguire. Cambiare il logo dell'API non elimina quella dipendenza. Il motore deve organizzare diversamente il lavoro oppure ridurlo. Una strategia migliore per inviare i comandi può invece aiutare una scena limitata dalla CPU senza modificare la qualità visiva. Conta individuare la fase che rallenta il fotogramma.
Piattaforme di destinazione e lavoro di sviluppo
Direct3D 12 è un candidato naturale per un progetto costruito attorno all'ambiente grafico Windows e ai relativi strumenti Microsoft. Il carattere multipiattaforma di Vulkan interessa chi vuole condividere un approccio al rendering fra sistemi operativi e fornitori diversi. Non significa che ogni dispositivo esponga le stesse capacità o che ogni destinazione non richieda altro lavoro.
Il vantaggio dipende dal resto della produzione. Un gruppo con un renderer Direct3D stabile potrebbe ottenere poco sostituendolo soltanto per un guadagno teorico. Chi pianifica più piattaforme può trovare in Vulkan un modo per ridurre le duplicazioni, a condizione che strumenti e driver delle destinazioni supportino il carico necessario.
| Domanda sul progetto | Considerazione per Direct3D 12 | Considerazione per Vulkan |
|---|---|---|
| Destinazione principale | Integrazione con l'ambiente grafico Windows | Adattamento a più piattaforme |
| Motore esistente | Riutilizzare un backend D3D12 maturo se adatto | Riutilizzare un backend Vulkan maturo se adatto |
| Funzioni necessarie | Verificare API, driver e hardware | Verificare API, estensioni, driver e hardware |
| Costo tecnico | Mantenere risorse e integrazione della piattaforma | Mantenere risorse e integrazione della piattaforma |
È una scelta produttiva oltre che tecnica. Un renderer che il gruppo sa correggere e distribuire vale più di un sostituto elegante sulla carta che assorbe il calendario delle consegne. La portabilità comprende inoltre compilazione, input, audio, contenuti e verifiche: l'API grafica non può sostenere da sola tutto questo lavoro.
Un gioco DirectX può usare Vulkan sotto la superficie
La distinzione diventa particolarmente utile su Linux. vkd3d-proton implementa Direct3D 12 sopra Vulkan per Proton. Un gioco Windows può quindi inviare comandi Direct3D mentre lo strato di compatibilità li traduce in lavoro destinato al driver Vulkan.
Non equivale a una versione Vulkan nativa distribuita dallo sviluppatore. È un percorso distinto, con requisiti di compatibilità propri. Spiega però perché il marchio DirectX di un gioco Windows non risponda, da solo, alla domanda se possa funzionare con Proton. Restano rilevanti anche gli altri componenti del gioco.
Come usare il selettore dell'API
Quando un gioco offre entrambi i backend, conviene confrontarli sul computer disponibile. Risoluzione, effetti e scena devono essere coerenti. Oltre al frame rate medio, contano blocchi, scatti e funzioni mancanti. Se un percorso omette un effetto costoso, il numero superiore non rappresenta una vittoria a parità di condizioni.
Non c'è molto motivo di abbandonare un backend stabile e soddisfacente perché un forum considera l'altra API superiore per principio. Per chi sviluppa, la scelta migliore si adatta alle destinazioni e alle capacità tecniche del gruppo. Per chi gioca, è l'implementazione che esegue il titolo in modo affidabile con le funzioni desiderate. Le due decisioni sono collegate, ma non costituiscono la stessa gara.
