Rozšíření OpenCL pro záznam dávek příkazů přestalo být experimentální

Konsorcium Khronos, které vede specifikace Vulkanu, OpenGL i OpenCL, vydalo 17. září 2026 revizi OpenCL 3.1.2. Změn je v ní hrstka a většina z nich upřesňuje formulace, u kterých se dalo dosud váhat. Jedna položka v seznamu změn je ale jiného druhu: rozšíření cl_khr_command_buffer je podle ní dokončené a už není experimentální.

Do jádra specifikace se rozšíření nepřesunulo. Zůstává rozšířením a strojový popis rozhraní dál vede se závislostí na OpenCL 1.2. Mění se jen jeho stav: revize je nově 1.0.0 a příznak experimental u záznamu zmizel.

Co je dávka příkazů

Program, který počítá na grafické kartě nebo na jiném akcelerátoru, řadí příkazy do fronty jeden po druhém. Zkopíruj data tam, spusť výpočet, zkopíruj výsledek zpátky. Ovladač u každého takového volání ověří argumenty, spočítá je a sestaví z nich kus proudu příkazů pro zařízení. Když se tatáž úloha opakuje šedesátkrát za sebou, projde touhle přípravou šedesátkrát.

Rozšíření tu práci rozděluje na dvě části. Příkazy se nejdřív nahrají do objektu cl_command_buffer_khr, ten se uzavře voláním clFinalizeCommandBufferKHR a od té chvíle se posílá k vykonání vcelku. Text rozšíření to popisuje jako oddělení přípravy fronty od jejího spuštění, díky kterému jde už jednou sestavenou sadu příkazů přehrát znovu.

Ukázka, kterou specifikace přikládá, sčítá dva vektory po šedesáti snímcích. Každý snímek má 1 024 prvků a dělí se na šestnáct dlaždic, takže v nahrané dávce je šestnáct spuštění výpočtu a čtyřicet osm kopírování, tedy tři na každou dlaždici. Sestaví se jednou před smyčkou a uvnitř smyčky zbude zápis vstupů a jediné odeslání:

cl_command_buffer_khr command_buffer =
    clCreateCommandBufferKHR(1, &command_queue, nullptr, &error);

/* ... clCommandCopyBufferKHR a clCommandNDRangeKernelKHR pro každou dlaždici ... */

CL_CHECK(clFinalizeCommandBufferKHR(command_buffer));

for (size_t frame_index = 0; frame_index < frame_count; frame_index++) {
  /* ... clEnqueueWriteBuffer obou vstupů ... */
  CL_CHECK(clEnqueueCommandBufferKHR(0, NULL, command_buffer, 2,
                                     write_src_events.data(), nullptr));
  CL_CHECK(clFinish(command_queue));
}

Proč to vzniklo na vestavěných zařízeních

Zdůvodnění v textu rozšíření mluví o vestavěných zařízeních, ne o herních kartách. Na vestavěných zařízeních spolkne sestavení proudu příkazů podstatnou část prostředků a úlohy tam navíc bývají zřetězené, takže právě opakovaná příprava je to úzké hrdlo, které drží akcelerátor nevyužitý. Druhý důvod je latence: zařízení se dá zaměstnat opakovaným odesíláním, aniž se čeká, až hostitel tytéž příkazy poskládá znovu.

Tomu odpovídá i seznam přispěvatelů. Začíná pěticí lidí z Codeplay Software a pokračuje jmény z Qualcommu, Armu, Intelu, Nvidie, Googlu, Tampereské univerzity a Argonnské národní laboratoře.

Co znamenalo slovo experimentální

Rozdíl mezi dnešním a včerejším stavem není v tom, co rozšíření umí. Je v záruce. Příloha o experimentálních rozšířeních říká, že se jejich vlastnosti můžou přidávat, odebírat nebo měnit zpětně nekompatibilním způsobem (přeloženo). Kdo podle nich psal program, musel počítat s tím, že mu příští revize rozhraní přestaví pod rukama. Starší vydání specifikace používala pro týž stav slovo provisional.

Devět revizí za necelých pět let

Historie verzí v textu rozšíření začíná 10. listopadu 2021 revizí 0.9.0, označenou jako první přidělená verze. Pak přišlo osm dalších devítkových revizí a každá má u sebe poznámku experimental: doplnění chyby při opakovaném uzavření dávky, dotaz na kontext, zrušení neplatného stavu dávky, příkazy clCommandSVMMemcpyKHR a clCommandSVMMemFillKHR, parametr properties u všech záznamových vstupních bodů, dotaz na podporované vlastnosti fronty, přepracovaná slučitelnost front a nakonec 10. července 2025 předělaná definice souběžného použití.

Revize 1.0.0 nese datum 9. září 2026 a jedinou poznámku: první vydání, neexperimentální. Od první verze k ní uplynuly bez jednoho dne čtyři roky a deset měsíců.

Samotné rozhraní se v 3.1.2 skoro nehnulo. Jediná věcná změna, kterou seznam u rozšíření uvádí, je doplněná chybová podmínka u volání clEnqueueCommandBufferKHR. Povýšení revize na 1.0.0 přišlo samostatným příspěvkem z 9. září.

Otevřené body zůstaly i v jedničce

Oddíl Issues v textu rozšíření má tři položky a dvě z nich jsou pořád nevyřešené: vstupní bod clCloneCommandBufferKHR na klonování dávky a odpojené vykonávání, při kterém by dávka běžela na vlastní vnitřní frontě a neblokovala frontu uživatele. Třetí bod, ovládání kapacity dávky, je uzavřený odkazem na to, že by se dal řešit vrstveným rozšířením.

Experimentální navíc zůstávají obě příbuzná rozšíření. cl_khr_command_buffer_mutable_dispatch je u revize 0.9.5 a cl_khr_command_buffer_multi_device u 0.9.2; strojový popis u obou pořád uvádí, že vyžadují cl_khr_command_buffer 0.9.8 nebo novější. Příznak experimental nese v celém souboru osm rozšíření ze sto padesáti šesti, což je vlastní součet nad tím souborem u značky v3.1.2.

Dokončený stav se navíc týká rozhraní, ne přiloženého kódu. V ukázce ve specifikaci se pole událostí jmenuje write_src_events, ale uvolňuje se jako write_src_event; takhle by se příklad nepřeložil.

V implementacích to běží roky

Na dokončení se v implementacích nečekalo. Otevřená implementace OpenCL PoCL přidala základní podporu už ve verzi 3.1 z prosince 2022: parametry příkazů se ověřují při záznamu, data se uloží a při odeslání se příkazy předají zařízení, jako by se volaly jednotlivě, jen bez té přípravy. Tehdejší poznámka zároveň přiznává mez – podpora se hlásila jen u procesorových zařízení, protože technicky ji měly všechny ovladače, ale otestovaný byl jen procesorový.

Zbytek revize

Ostatní změny v 3.1.2 jsou drobné a míří na místa, kde šel text vyložit dvěma způsoby. Sjednotily se chybové kódy v popisu rozhraní pro paměťové objekty, upřesnilo se chování clSetProgramSpecializationConstant při odděleném překladu a linkování, doplnilo se, k čemu slouží příznak CL_MEM_KERNEL_READ_AND_WRITE, co vrací clGetSupportedImageFormats na zařízení bez podpory obrázků, co je prázdný řetězec u CL_PROGRAM_SOURCE a kdy se zařízení považuje za zařízení s podporou nestejnoměrných pracovních skupin. Jazyková část specifikace k tomu opravila celočíselnou podobu makra CL_VERSION_3_1. Nové je jedno rozšíření pro sdílení paměti přes dma-buf, cl_img_unified_svm_external_memory_dma_buf, a to je zatím experimentální.

Zdroje

• Khronos Group: vydání OpenCL-Docs v3.1.2 – značka z 17. září 2026, ze které jsou všechny citované soubory specifikace
• Text rozšíření cl_khr_command_buffer – popis, zdůvodnění, přispěvatelé, ukázka kódu, otevřené body a historie verzí
• Příloha E specifikace – seznam změn z 3.1.1 na 3.1.2
• Strojový popis rozhraní cl.xml – revize a příznaky jednotlivých rozšíření
• Phoronix: OpenCL 3.1.2 Released With cl_khr_command_buffer Promoted
• PoCL: soubor CHANGES – oddíl k verzi 3.1 z prosince 2022

Prameny jsou anglické. Čísla, data i názvy volání jsou z nich ověřené, text je psaný vlastními slovy; jediná doslovná citace je označená jako přeložená.