OpenGL vs. Vulkan

OpenGL vs. Vulkan není akademické srovnání, ale praktická volba architektury renderingu. Jedno API vám ušetří čas na začátku, druhé dává výrazně větší kontrolu nad CPU overheadem, synchronizací a správou paměti. V tomhle textu projdeme, kde se liší, proč je Vulkan náročnější a kdy se pořád vyplatí zůstat u OpenGL.

Kde se OpenGL a Vulkan liší už v návrhu API

Základní rozdíl je v tom, kolik práce dělá driver a kolik aplikace. OpenGL je historicky postavené jako vysokoúrovňové stavové API. Měníte globální state, posíláte draw cally a ovladač se snaží domyslet zbytek. To zjednodušuje start, ale část ceny platíte v nepředvídatelnosti.

Vulkan jde opačným směrem. Je explicitní: pipeline state připravíte dopředu, command buffery nahráváte sami, synchronizaci řídíte ručně a paměť alokujete vědomě. Výsledek je méně magie v driveru a více deterministické chování. Nevýhoda je zřejmá: výrazně víc kódu, více míst, kde se dá udělat chyba, a vyšší nárok na návrh enginu.

CPU overhead, draw cally a proč Vulkan škáluje lépe

Pokud renderer naráží na CPU a ne na GPU, bývá Vulkan často lepší volba. OpenGL má větší režii na draw call, protože driver průběžně validuje state, řeší interní přechody a serializuje část práce. U menších scén to nevadí. U tisíců objektů na snímek už ano.

Vulkan navíc od začátku počítá s multithreadingem. Command buffery můžete připravovat paralelně, práci rozdělit po frame graphu nebo po render passech a CPU vytížit rovnoměrněji. OpenGL umí více kontextů a různé workaroundy, ale není to jeho přirozený model. Když potřebujete stabilní frame time, explicitní API obvykle vede.

Správa paměti a synchronizace: tady se láme jednoduchost

Největší mentální skok mezi OpenGL a Vulkanem není v shaderu, ale ve správě zdrojů. V OpenGL vytvoříte buffer nebo texturu a typicky neřešíte, v jaké heap oblasti skutečně leží ani kdy přesně proběhne přechod mezi stavy. Driver to za vás nějak udělá. Někdy dobře, někdy draze.

Ve Vulkanu řešíte alokaci paměti, resource barriers, ownership mezi frontami i pořadí přístupů. To je pracnější, ale také přesnější. Když aplikace trpí stutteringem, náhodnými spiky nebo špatným využitím GPU, právě explicitní synchronizace bývá rozdíl mezi "nějak to běží" a stabilním renderem.

// Vulkan: zjednodušený zápis bariéry mezi transfer a fragment shader čtením
VkImageMemoryBarrier barrier = {0};
barrier.sType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER;
barrier.oldLayout = VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL;
barrier.newLayout = VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL;
barrier.srcAccessMask = VK_ACCESS_TRANSFER_WRITE_BIT;
barrier.dstAccessMask = VK_ACCESS_SHADER_READ_BIT;
barrier.image = textureImage;
barrier.subresourceRange.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
barrier.subresourceRange.levelCount = 1;
barrier.subresourceRange.layerCount = 1;

vkCmdPipelineBarrier(
  cmd,
  VK_PIPELINE_STAGE_TRANSFER_BIT,
  VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT,
  0,
  0, NULL,
  0, NULL,
  1, &barrier
);

Tohle je přesně typ věci, kterou v OpenGL většinou nevidíte takhle explicitně. Výhoda OpenGL je nižší vstupní bariéra. Nevýhoda je, že optimalizační rozhodnutí zůstávají v rukou ovladače. U jednoduchého vieweru je to pohodlné. U vlastního enginu často omezující.

Pipeline state, shadery a proč Vulkan trestá improvizaci

OpenGL dovoluje postupně skládat stav renderingu: bind textur, VAO, program, blending, depth test a pak draw. Je to flexibilní, ale snadno vznikne chaos. Změny stavu jsou rozptýlené po kódu a ladění, proč se konkrétní draw call renderuje jinak než jiný, bývá zbytečně drahé.

Vulkan tlačí na předpřipravené pipeline state objekty. To je zpočátku nepohodlné, protože musíte promyslet varianty shaderů, layout descriptor setů i kompatibilitu render passů. Ale z dlouhodobého pohledu je to zdravější model. Renderer je čitelnější, méně spoléhá na skrytý stav a lépe se profiluje.

Důležitý detail je i formát shaderů. Vulkan běžně pracuje se SPIR-V, tedy mezireprezentací vhodnou pro validaci a tooling. To otevírá prostor pro robustnější build pipeline, reflektování resource bindingů a generování metadat. U větších projektů je to praktická výhoda, ne jen akademická poznámka.

Debugging a tooling: jednodušší start versus lepší kontrola

Na první pohled vypadá OpenGL jednodušeji i na ladění, protože rychle něco vykreslíte. To je pravda jen do určité složitosti. Jakmile řešíte synchronizační chyby, skryté reallocace, driver-specific chování nebo výkonové anomálie, implicitní model vám začne informace spíš skrývat než zpřístupňovat.

Vulkan je v tomhle tvrdší, ale férovější. S validačními vrstvami hned vidíte porušení pravidel API, špatný layout image, chybnou synchronizaci nebo nekompatibilní descriptor binding. Doporučujeme začít oficiálními materiály z Khronos Vulkan a při implementaci mít po ruce Vulkan Guide.

U OpenGL má smysl sledovat hlavně omezení konkrétního driveru a chování na různých platformách. Oficiální vstup je pořád OpenGL overview, ale reálná praxe je často víc o zkušenosti s konkrétními GPU vendor implementacemi než o samotné specifikaci.

Kdy dává OpenGL smysl a kdy už je lepší Vulkan

OpenGL doporučujeme tam, kde potřebujete rychlý prototyp, interní nástroj, menší vizualizaci, výukový projekt nebo výzkumný rendering bez ambice vyždímat maximum z CPU a GPU. Čas do prvního obrazu je kratší a tým nemusí hned řešit celý aparát kolem front, descriptorů a bariér.

Vulkan dává smysl pro moderní engine, náročnější realtime grafiku, větší scénu s vysokým počtem draw callů, konzistentní frame pacing a situace, kde chcete mít výkon pod kontrolou místo spoléhání na heuristiky driveru. Pokud aplikace poroste několik let, explicitní architektura se často vrátí.

Co si z porovnání OpenGL a Vulkan odnést

Rozdíl mezi OpenGL a Vulkanem není jen v rychlosti, ale hlavně v rozdělení odpovědnosti. OpenGL šetří čas a zjednodušuje vstup. Vulkan přenáší složitost do aplikace, ale za to vrací kontrolu, předvídatelnost a lepší škálování. Pokud stavíte menší nástroj, OpenGL je pořád rozumné. Pokud navrhujete renderer jako dlouhodobý základ produktu, Vulkan je obvykle správnější investice.