Vulkan — che cos'è, API multipiattaforma e rendering

Cos'è Vulkan?

Vulkan è un'API di basso livello e multipiattaforma per lavorare con unità di elaborazione grafica, rilasciata per la prima volta da Khronos Group nel 2016. Vulkan ha succeduto OpenGL, offrendo un overhead CPU significativamente inferiore, prestazioni prevedibili e la possibilità di generazione multithread di comandi.

A differenza di OpenGL, dove il driver esegue validazione e sincronizzazione sulla CPU, Vulkan affida la gestione delle risorse allo sviluppatore. Allocazione della memoria, sincronizzazione tramite semafori e barriere, creazione di pipeline — tutto questo è controllato esplicitamente. Questo approccio offre fino al 50% di miglioramento delle prestazioni in scenari CPU-bound.

Vulkan è supportato su Windows, Linux, Android, iOS (tramite MoltenVK), macOS (MoltenVK), Nintendo Switch e console. Secondo Khronos Group (2026), l'API funziona su dispositivi con GPU di NVIDIA, AMD, Intel, Qualcomm (Adreno), ARM (Mali) e Apple (attraverso il layer Metal). Vulkan 1.4 (2026) ha aggiunto il supporto per Mesh Shaders e Video Encode API.

Storia di Vulkan

Originariamente, Vulkan è stato sviluppato con il nome in codice “glNext” — il successore di OpenGL. Vulkan 1.0 (2016) ha fornito un'API di base con gestione esplicita della memoria, shader SPIR-V e code multithread. Vulkan 1.1 (2018) ha aggiunto Subgroup Operations e supporto per tipi a 16 bit. Vulkan 1.2 (2020) ha introdotto Buffer Device Address e Timeline Semaphores.

Vulkan 1.3 (2022) ha standardizzato Dynamic Rendering e Graphics Pipeline Library. Vulkan 1.4 (2026) ha reso obbligatorio il supporto per Mesh Shaders e ha aggiunto Video Encode/Decode API per la codifica hardware di H.264/HEVC/AV1. Secondo Khronos (2026), Vulkan 1.4 è supportato su tutte le nuove GPU NVIDIA RTX 50xx, AMD RX 9000 e Intel Arc B-series.

Architettura di Vulkan: dispositivo e code

L'architettura di Vulkan è costruita su un layer di astrazione hardware (layer HW). L'applicazione interagisce con un dispositivo fisico (VkPhysicalDevice) attraverso un dispositivo logico (VkDevice). I comandi vengono inviati alle code (VkQueue), ciascuna appartenente a una specifica famiglia di code (graphics, compute, transfer).

VkInstance, VkDevice e VkQueue

VkInstance è l'oggetto radice di Vulkan, che memorizza informazioni sui layer di validazione e le estensioni. VkPhysicalDevice rappresenta la GPU fisica e permette di interrogare le sue proprietà, gli heap di memoria e le famiglie di code. VkDevice è un dispositivo logico con code ed estensioni richieste esplicitamente.

// Creazione di un dispositivo logico Vulkan
VkDeviceCreateInfo devInfo {};
devInfo.sType = VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO;
devInfo.queueCreateInfoCount = 1;
 
float queuePriority = 1.0f;
VkDeviceQueueCreateInfo queueInfo {};
queueInfo.sType = VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO;
queueInfo.queueFamilyIndex = 0;
queueInfo.queueCount = 1;
queueInfo.pQueuePriorities = &queuePriority;
devInfo.pQueueCreateInfos = &queueInfo;
 
VkDevice device;
vkCreateDevice(physicalDevice, &devInfo,
    nullptr, &device);
 
VkQueue queue;
vkGetDeviceQueue(device, 0, 0, &queue);

La funzione vkCreateDevice crea un dispositivo logico con le code specificate. VkQueue è un handle di coda per inviare comandi. Una singola coda può essere utilizzata per grafica, calcolo e copia se i flag corrispondenti sono supportati dalla famiglia di code. La priorità della coda (0.0–1.0) influisce sull'ordine di esecuzione in caso di contesa.

VkMemory e VkBuffer — gestione della memoria

In Vulkan, la memoria viene allocata esplicitamente tramite VkDeviceMemory. Lo sviluppatore interroga i tipi di memoria (HOST_VISIBLE, DEVICE_LOCAL) dal dispositivo fisico e alloca blocchi. I buffer (VkBuffer) e le texture (VkImage) non hanno memoria propria — vengono legati ai blocchi allocati tramite vkBindBufferMemory.

Vulkan Memory Allocator (VMA) è una libreria di AMD che semplifica la gestione della memoria. VMA raggruppa automaticamente le piccole allocazioni in grandi blocchi, gestisce la deframmentazione e seleziona il tipo di memoria appropriato. Secondo AMD (2025), VMA riduce il numero di allocazioni di memoria di 50–100 volte rispetto alla gestione manuale.

VkCommandPool e VkCommandBuffer

VkCommandPool gestisce la memoria per i buffer di comando. I buffer (VkCommandBuffer) vengono registrati sulla CPU e inviati alla GPU tramite vkQueueSubmit. Vulkan supporta buffer primari e secondari: i primari vengono inviati direttamente, i secondari possono essere chiamati dai primari per la costruzione multithread di comandi.

La registrazione dei comandi inizia con vkBeginCommandBuffer e termina con vkEndCommandBuffer. Tra di essi, vengono registrati comandi di rendering: vkCmdDraw, vkCmdDispatch, vkCmdCopyBuffer e vkCmdPipelineBarrier per la sincronizzazione. Un nuovo buffer di comando viene creato per ogni frame con pooling tramite reset del pool.

Rendering con Vulkan: pipeline e comandi

Il rendering in Vulkan è organizzato tramite pipeline (VkPipeline). A differenza di OpenGL, dove lo stato della pipeline viene modificato globalmente, Vulkan utilizza VkPipeline — una pipeline precompilata che include tutte le fasi: input dei vertici, shader, rasterizzazione, depth-stencil e blending.

VkPipeline — pipeline di rendering

VkGraphicsPipelineCreateInfo descrive la pipeline completa: shader dei vertici e dei frammenti, topologia (triangle list, triangle strip), rasterizzatore (fill mode, cull mode), multicampionamento, test depth-stencil, blending e impostazioni del viewport. La pipeline viene creata una volta e riutilizzata — cambiare stato richiede una nuova pipeline o stato dinamico.

// Configurazione della pipeline grafica
VkGraphicsPipelineCreateInfo pipelineInfo {};
pipelineInfo.sType =
    VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_CREATE_INFO;
pipelineInfo.stageCount = 2;
pipelineInfo.pStages = shaderStages;
pipelineInfo.pVertexInputState =&;
    vertexInputState;
pipelineInfo.pRasterizationState =&;
    rasterState;
 
VkPipeline graphicsPipeline;
vkCreateGraphicsPipelines(device,
    VK_NULL_HANDLE, 1, &pipelineInfo,
    nullptr, &graphicsPipeline);

Dynamic State (VK_DYNAMIC_STATE_VIEWPORT, VK_DYNAMIC_STATE_SCISSOR) consente di modificare determinati parametri senza creare una nuova pipeline. Vulkan 1.4 ha reso obbligatorio il supporto per Dynamic State 3 (VK_EXT_extended_dynamic_state_3) per gestire costanti di blending, depth bias e topologia al volo, riducendo il numero di pipeline in un progetto.

Render Pass e Dynamic Rendering

VkRenderPass descrive la struttura dei passaggi di rendering: quali attachment vengono utilizzati, come vengono cancellati e caricati. Dynamic Rendering (VK_KHR_dynamic_rendering, obbligatorio da Vulkan 1.4) semplifica il processo: il render pass viene creato al volo nel buffer di comando tramite vkCmdBeginRendering, senza un oggetto VkRenderPass preliminare.

Secondo Khronos (2026), Dynamic Rendering riduce il codice di inizializzazione di Vulkan del 30–40% e diminuisce il numero di permutazioni di pipeline. Per tecniche di rendering differito complesse (Deferred Shading), è ancora conveniente utilizzare VkRenderPass classico con più subpass per G-buffer e illuminazione.

Shader in Vulkan: SPIR-V e GLSL

SPIR-V è un formato binario universale di shader in Vulkan, sviluppato da Khronos. Gli shader possono essere scritti in GLSL, HLSL o linguaggio Zink e compilati in SPIR-V tramite glslangValidator, dxc o Google Shaderc. Vulkan non accetta shader in codice sorgente — solo SPIR-V binario.

GLSL in Vulkan

GLSL per Vulkan differisce dal GLSL standard di OpenGL. Vengono utilizzati blocchi (layout) con numeri di set e binding espliciti, invece di variabili integrate. Gli attributi dei vertici vengono specificati tramite location, gli uniform tramite uniform blocks o buffer. Push constants (fino a 128 byte) sono disponibili per il trasferimento rapido di dati senza buffer.

// Shader di vertici Vulkan/GLSL
#version 460
 
layout(location = 0) in vec3 inPosition;
layout(location = 1) in vec3 inNormal;
 
layout(binding = 0, set = 0)
uniform UniformBufferObject {
    mat4 modelViewProjection;
} ubo;
 
layout(location = 0) out vec3 outNormal;
 
void main() {
    gl_Position = ubo.modelViewProjection *
        vec4(inPosition, 1.0);
    outNormal = inNormal;
}

I qualificatori layout(set = N, binding = M) sono una differenza chiave tra Vulkan GLSL e OpenGL. Set corrisponde a un set di descrittori (VkDescriptorSet), binding corrisponde a una risorsa specifica (buffer, texture, sampler). La separazione in set consente di cambiare efficientemente i set di risorse tra le draw call senza legare singole risorse.

Descrittori e set di descrittori

VkDescriptorSet è un gruppo di risorse (buffer, texture, sampler) legate agli shader. Il layout dei descrittori descrive i tipi di risorse e i loro numeri di binding. I set di descrittori vengono aggiornati tramite vkUpdateDescriptorSets e riutilizzati tra le draw call. Vulkan 1.4 supporta VK_EXT_descriptor_buffer per l'accesso diretto ai descrittori dalla GPU.

Push Constants sono un meccanismo per il trasferimento rapido di piccoli volumi di dati (fino a 128 byte) agli shader senza creare descrittori. Le push constants vengono impostate tramite vkCmdPushConstants nel buffer di comando. Secondo Khronos (2025), l'uso delle push constants invece degli uniform buffers riduce l'overhead CPU del 10–15% a frequenze di draw call superiori a 10 mila per frame.

Vulkan su diverse piattaforme

Vulkan è l'unica API che funziona su tutte le principali piattaforme: Windows (tramite driver ICD ufficiale), Linux (RADV, AMDVLK, NVIDIA), Android (Vulkan 1.3+, obbligatorio da Android 10), e su dispositivi Apple tramite MoltenVK — un layer di traduzione da Vulkan a Metal.

Vulkan su Android

Su Android, Vulkan è obbligatorio per Android 10 e versioni successive. Google raccomanda Vulkan per nuovi progetti, specialmente giochi ad alte prestazioni e applicazioni AR tramite ARCore. Qualcomm Adreno e ARM Mali forniscono supporto completo a Vulkan 1.3 con ray tracing hardware su Adreno 8xx e Mali-G720.

Secondo Google (2026), il 98% dei dispositivi Android con Android 10+ supporta Vulkan. Per la retrocompatibilità, è disponibile ANGLE (Almost Native Graphics Layer Engine), che traduce OpenGL ES in Vulkan. Ciò consente di eseguire vecchie applicazioni OpenGL su un driver Vulkan con un miglioramento delle prestazioni fino al 20%.

Su Android, Vulkan ha un'alta priorità per l'efficienza energetica: le applicazioni Vulkan consumano il 25–40% di energia in meno rispetto a OpenGL ES sotto lo stesso carico grafico su dispositivi con Adreno 7xx+. Questo rende Vulkan l'API preferita per i giochi su dispositivi mobili.

Vulkan su Apple tramite MoltenVK

MoltenVK è un'implementazione di Vulkan su Metal, sviluppata da LunarG e Valve. MoltenVK traduce le chiamate dell'API Vulkan in Metal, supportando Vulkan 1.2 su iOS e macOS. Le prestazioni di MoltenVK sono vicine a Metal nativo: l'overhead di traduzione è del 5–15% a seconda dello scenario.

Secondo LunarG (2025), MoltenVK viene utilizzato in CrossOver (Wine per Mac) per eseguire giochi Windows su macOS. Dota 2, Civilization VI e Baldur's Gate 3 su macOS funzionano tramite MoltenVK con prestazioni di 30–60 FPS su M3/M4. MoltenVK supporta l'upscaling MetalFX per migliorare le prestazioni.

Vulkan Ray Tracing

VK_KHR_ray_tracing è un'estensione per il ray tracing hardware in Vulkan, obbligatoria da Vulkan 1.4. Supportata su GPU con core RT: NVIDIA RTX 20xx/30xx/40xx/50xx, AMD RX 6000+/9000, Intel Arc A/B. Vulkan RT fornisce VkAccelerationStructure, VkRayTracingPipeline e Shader Binding Table.

Vulkan Ray Tracing supporta riflessi, ombre, occlusione ambientale e illuminazione globale in tempo reale. Secondo Khronos (2026), sulla NVIDIA RTX 5090, Vulkan Ray Tracing raggiunge fino a 100 Giga rays/s in scene di qualità di riferimento. Per le piattaforme portatili, Vulkan RT scala tramite riduzione della sfocatura e denoising temporale.