Вступ

Якщо ви зіткнулися із проблемою низького FPS у DOOM і вам хочеться її виправити, то ви прийшли саме за адресою.
Магічна штука Vulkan API піднімає FPS в середньому на 15-25 кадрів (залежить від конфігурації вашого комп'ютера), перетворюючи некомфортні 20-30 FPS на грабельні 50-60.

УВАГА! НАПЕРЕД ЧИМ ВИКОНАВАТИ ДІЇ, ОПИСАНІ У КЕРІВНИЦТВІ, НЕОБХІДНО ПЕРЕКОНУТИСЯ, ЩО ВАШ КОМП'ЮТЕР ВІДПОВІДАЄ ХОЧЕ БІ МІНІМАЛЬНИМ СИСТЕМНИМ ВИМОГИ!

Що таке Vulkan API?

Що це за звір і як йому вдається так відчутно підвищити продуктивність?

Vulkan API – графічний інтерфес програмування, створений для відображення 3D та 2D графіки на ваших моніторчиках. Простіше кажучи, ця шняга використовує ресурси вашого комп'ютера для побудови графіки в іграх. OpenGL та DirectX з тієї ж опери.

Чому він дає такий приріст до FPS? Я, звичайно, можу почати вам розповідати про супер-пупер технології, що використовуються в ньому, але для простоти просто скажу, що він використовує комп'ютерне залізно набагато ефективніше, ніж його попередник OpenGL.

Як мені його ввімкнути?

Все дуже просто, почнемо з першого кроку:

Крок перший:

Оновіть драйвера вашої відеокарти останньої можливої ​​версії. Якщо не знаєте, як це зробити - запитайте у , тому що інструкції щодо їх оновлення досить довгі, та й керівництво зовсім не про це.

Крок другий:

Запускаємо сам DOOM. Заходимо в Параметри>Розширені та в пункті " Графічний API" вибираємо "Vulkan API" замість "OpenGL". Перезапускаємо гру.

Крок третій:

Заходимо в гру та радіємо підвищенню продуктивності!

ВАЖЛИВО:

Підвищення продуктивності дуже залежить від показників вашого комп'ютера. На моїй конфігурації приріст становив аж 30 FPS, у когось може виявитися набагато менше, а хтось взагалі не відчує різниці. Та й взагалі, безглуздо чекати від тостера хоча б 30 FPS з Vulkan"ом, якщо він на мінімалках ледве 10 видає.

Гра не запускається після увімкнення Vulcan API, що робити?

Причина одна:

Ви не оновили драйвера, або завантажили не ту їхню версію. Перекачуємо нову/стабільну версію.

Причина дві:

Ваша відеокарта не може у Vulkan API. Таке теж може статися, але ймовірність досить мала. Якщо відеокарта підходить під мінімальні вимоги- вона може працювати з Vulkan API. Якщо ні - відкочуємо гру до налаштувань за замовчуванням і мучимося з OpenGL"ом

Як відкотити гру назад до OpenGL, якщо нічого не працює?

Якщо гра після переходу на Vulkan відмовляється запускатися – ось спосіб переходу назад на OpenGL:
Насамперед потрібно зайти в папку збережень, вона знаходиться цим шляхом:
C:\Users\<имя_пользователя>\Saved Games\id Software\DOOM\base
Далі знаходимо у ній файл DOOMConfig.localта відкриваємо його блокнотом.
Шукаємо параметр r_renderapiі змінюємо його значення 1 на 0 (1 - VulkanAPI, 0 - OpenGL)
Зберігаємо файл та закриваємо його. Тепер гра має запуститися.

Дякую користувачеві arikuto за знайдену інструкцію!

Не забудьте оцінити керівництво чи залишити свою критику/побажання!

Відносно недавно вийшов новий Vulkan API – можна сказати, спадкоємець OpenGL, хоча заснований Vulkan на API Mantle від AMD.
Звичайно, розвиток та підтримка OpenGL не припинилося, а також у світ вийшов і DirectX 12. Що там з DirectX 12 і чому його поставили тільки на Windows 10 – я, на жаль (а може і на щастя) не знаю. Але ось кросплатформовий Vulkan мене зацікавив. У чому особливості Vulkan і як правильно його використовувати я постараюся розповісти вам у цій статті.

Отже, навіщо потрібний Vulkan і де може бути використаний? В іграх та додатках, що працюють з графікою? Звичайно! Обчислювати, як це робить CUDA чи OpenCL? Без проблем. Чи для цього нам потрібно вікно або дисплей? Звичайно, ні, ви можете самі вказати, куди транслювати ваш результат або не транслювати його взагалі. Але про все по порядку.

Оформлення API та основи

Мабуть, варто почати із найпростішого. Оскільки над Vulkan API працювали Khronous Group, синтаксис дуже схожий на OpenGL. У всьому API є префікс vk. Наприклад функції (іноді навіть з дуже довгими назвами) виглядають так: vkDoSomething(...), імена структур або хендлів: VkSomething, а всі константні вирази (макроси, макродзвінки та елементи перерахувань): VK_SOMETHING. Також є особливий вид функцій - команди, яким додається префікс Cmd: vkCmdJustDoIt(...).

Писати на Vulkan можна як C, так і C++. Але другий варіант дасть, звичайно, більше зручності. Є (і створюватимуться) порти іншими мовами. Хтось уже зробив порт на Delphi, хтось бажає (навіщо?) порт на Python.

Отже, як створити рендер контекст? Ніяк. Тут його нема. Натомість придумали інші речі з іншими назвами, які навіть нагадуватимуть DirectX.

Початок роботи та основні поняття

Vulkan поділяє два поняття – це пристрій (device) та хост (host). Пристрій виконуватиме всі команди, надіслані йому, а хост їх надсилатиме. Фактично наш додаток і є хост - у Vulkan така термінологія.

Для роботи з Vulkan нам знадобиться хендли на його екземпляр (instance), і може бути навіть не один, а також на пристрій (device), знову ж таки, не завжди може вистачати одного.

Vulkan може бути легко завантажений динамічно. У SDK (розробили LunarG), якщо був оголошений макрос VK_NO_PROTOTYPES і завантажувати бібліотеку Vulkan своїми руками (не лінковником, а певними засобами в коді), то насамперед потрібна буде функція vkGetInstanceProcAddr, за допомогою якої можна дізнатися адреси основних функцій Vul без екземпляра, включаючи функцію його створення, та функції, які працюють з екземпляром, включаючи функцію його руйнування та функцію створення пристрою. Після створення пристрою можна отримати функції, які працюють із ним (а також його дочірніми хендлами) через vkGetDeviceProcAddr.

Цікавий факт: у Vulkan завжди потрібно заповнити певну структуру даними, щоб створити будь-який об'єкт. І все в Vulkan працює приблизно таким чином: заздалегідь підготував - можна використовувати часто високою продуктивністю. У інформацію про екземплярі можна також помістити інформацію про вашу програму, версії движка, версії використовуваного API та іншу інформацію.

Шари та розширення

У чистому Vulkan немає сильних перевірок вхідних даних на правильність. Йому сказали щось зробити – він зробить. Навіть якщо це призведе до помилки програми, драйвера або відеокарти. Це зробили заради продуктивності. Тим не менш, можна без проблем підключити перевірочні шари, а також розширеннядо екземпляра та/або пристрою, якщо це необхідно.

Шари (layers)

В основному, призначення шарів – перевірити вхідні дані на помилки та відстежувати роботу Vulkan. Працюють вони дуже просто: припустимо, викликаємо функцію, і потрапляє вона у верхній шар, заданий при створенні пристрою або екземпляра раніше. Він все перевіряє на правильність, після чого передає виклик у наступний. І так буде, доки справа не дійде до ядра Vulkan. Звичайно, можна створити власні шари. Наприклад, Steam випустила шар SteamOverlay (хоча й не знаю, що він взагалі робить). Тим не менш, шари будуть мовчати, але не доведуть до краху програми. Як дізнатися, чи все правильно зроблено? Для цього є спеціальне розширення!

Розширення (extensions)

Як випливає з назви, вони розширюють роботу Vulkan додатковим функціоналом. Наприклад, одне розширення (debug report) виводитиме помилки (і не тільки) з усіх шарів. Для цього потрібно буде вказати необхідну Callback функцію, а що робити з інформацією, що надійшла до цієї функції - вирішувати вже вам. Врахуйте, що це Callback і затримка може дорого обійтися, особливо якщо виводити всю отриману інформацію прямо в консоль. Після обробки повідомлення можна вказати, передавати виклик функції далі (наступний шар) чи ні - так можна уникнути критичних помилокале постаратися працювати далі з менш небезпечними помилками.
Є також інші розширення, про деякі я розповім пізніше в цій статті.

Пристрій

Vulkan поділяє поняття фізичного устрою та логічного. Фізичним пристроємможе бути ваша відеокарта (і не одна) або процесор, який підтримує графіку. Логічне пристрійстворюється на основі фізичного: збирається інформацію про фізичні пристрої, вибирається потрібне, готується інша необхідна інформаціята створюється пристрій. Можливо кілька логічних пристроївна основі одного фізичного, але ось об'єднувати для єдиної роботи фізичні пристрої(поки що?) не можна.

Отже, що за інформацію ми збираємо? Це, звичайно ж, формати, пам'ять, можливості, що підтримуються, і, звичайно ж, сімейства черг.

Черги (queue) та сімейства черг (queue family)

Пристрій може (або не може) робити наступні 4 речі: малювати графіку, робити різні обчислення, копіювати дані, а також працювати з розрідженою пам'яттю (sparse memory management). Ці можливості представлені у вигляді сімейств черг: кожна родина підтримує певні (можливо все відразу) можливості. І якщо ідентичні сімейства були розділені, Vulkan все одно представить їх як одне сімейство, щоб ми не так сильно страждали з кодом і вибирали потрібну родину.

Після того, як ви вибрали потрібну (або потрібну) родину, з них можна отримати черги. Черги - це місце, куди надходитимуть команди для пристрою (потім пристрій їх братиме з черг і виконуватиме). Черг та сімейств, до речі, не дуже багато. NVIDIA зазвичай має 1 сімейство з усіма можливостями на 16 черг. Після того, як ви закінчили з підбором сімейств та кількістю черг, можна створювати пристрій.

Команди, їх виконання та синхронізація

Усі команди для пристрою поміщаються у спеціальний контейнер – командний буфер. Тобто. немає жодної функції в Vulkan, яка сказала б пристрою зробити щось відразу, і при завершенні операції повернути управління додатком. Є лише функції заповнення командного буфера певними командами (наприклад, намалювати щось або скопіювати зображення). Тільки після запису командного буфера на хості ми можемо його відправити в чергу, яка, як відомо, перебуває у пристрої.

Командний буфер буває двох видів: первинний та вторинний. Первинний вирушає у чергу. Вторинний ж може бути відправлений - він запускається у первинному. Записуються команди в такому самому порядку, в якому були викликані функції. У чергу вони надходять у такому порядку. А от здійсняться вони можуть майже в хаотичному порядку. Щоб не було повного хаосу в додатку, розробники Vulkan передбачили засоби синхронізації.

Тепер найважливіше: хост неочікує завершення виконання команд та командних буферів. за Крайній мірідо того моменту, доки не вкажете це явним способом. Після відправлення командних буферів у чергу управління відразу повертається додатку.

Є 4 примітиви синхронізації: паркан (fence), семафор (semaphore), подія (event) та бар'єр (barrier).

Парканнайпростіший метод синхронізації - він дозволяє хосту чекати на виконання певних речей. Наприклад, завершення виконання командного буфера. Але використовується паркан рідко.

Семафор- Спосіб синхронізації всередині пристрою. Не можна подивитися його стан чи почекати його на хості, не можна також чекати його всередині командного буфера, але можемо вказати, який семафор повинен подати сигнал при завершенні виконання всіх команд буфера, і який семафор чекати перед тим, як розпочати виконання команд у буфері. Лише чекатиме не весь буфер, а його певна стадія.

Стадії конвеєра (pipeline stages) та залежності виконання

Як уже було сказано, не обов'язково команди у черзі виконаються по порядку. Якщо бути точніше, то наступні команди не чекатимуть на завершення попередніх. Вони можуть виконуватися паралельно, або виконання попередньої команди може завершитися набагато пізніше. І це цілком нормально. Але деякі команди залежатьвід виконання інших. Ви можете розділити їх на два береги: «до» та «після», а також вказати, які стадії берега «до» повинні обов'язково виконатися (тобто команди можуть завершитися не повністю або не всі), перш ніж почнуть виконуватись зазначені стадії команд берега "після". Наприклад, зображення може призупинитися, щоб зробити певні речі, а потім знову продовжити малювати. Також може бути і ланцюжок залежностей, але не йтимемо глибоко в ліси Сибіру Vulkan.

Події- Елемент «тонкого» налаштування. Подати сигнал можна як з хоста, так і пристрою, чекати можна також і на пристрої, і на хості. Подія визначає залежність двох сетів команд (до і після) у командному буфері. І для події є також спеціальна псевдо-стадія, яка дозволяє чекати на хост.

Бар'єрзнову може бути використаний тільки у пристрої, а ще точніше - у командному буфері, оголошуючи залежності першого та другого сету команд. Також можна додатково вказати бар'єри пам'яті, які бувають трьох видів: глобальнийбар'єр, бар'єр буферата бар'єр зображення. Вони не дадуть ненароком прочитати дані, які в Наразізаписуються та/або навпаки, залежно від зазначених параметрів.

Конвеєри

Нижче показано два конвеєри Vulkan:

Тобто. у Vulkan є два конвеєри: графічнийі обчислювальний. За допомогою графічного ми, звичайно ж, можемо малювати, а обчислювальний... обчислювати. Що ще? Результати обчислень можуть потім вирушити до графічного конвеєра. Так можна з легкістю заощадити час на системі частинок, наприклад.

Змінити порядок чи змінити самі стадії конвеєра не можна. Виняток становлять програмовані стадії (шейдери). Також можна відправляти різні дані в шейдери (і не тільки) через дескриптори.

Для конвеєра можна створити кеш, який може бути використаний (знов і знову) і в інших конвеєрах і навіть після перезапуску програми.

Конвеєр необхідно налаштувати та асоціювати з командним буфером, перш ніж останній буде використовувати команди конвеєра.

Спадкування конвеєрів

Так як конвеєр, це фактично вся інформація про те, як потрібно працювати з даними, що надходять, то зміна конвеєра (а це інформація про шейдерів, дескрипторів, растеризації та інше) може дорого обійтися за часом. Тому розробники надали можливість наслідування конвеєра. При зміні конвеєра на дочірній, батьківський або між дочірніми піде менше витрат продуктивності. Але це також і зручність для розробників, наприклад ООП.

Прохід малювання, графічний конвеєр та фреймбуфер

Отже, отримуємо наступну матрьошку:

Щоб можна було використовувати команди отрисовки, потрібен графічний конвеєр. У графічному конвеєрі необхідно вказати прохід малювання (Render Pass), який містить інформацію про підпроходах (subpass), їх залежностей один від одного та прикріплення (attachment). Прикріплення - інформація про зображення, яке буде використовуватися у framebuffer"ах. Framebuffer створюється спеціально для певного проходу малювання. Щоб почати прохід, потрібно вказати як сам прохід (а також, якщо потрібно, підпрохід), так і framebuffer. Після початку проходу можна малювати Можна також перемикатися між підпроходами, а після завершення малювання можна завершити прохід.

Управління пам'яттю та ресурси

Пам'ять у Vulkan розподіляється хостом і тільки хостом (за винятком swapchain). Якщо зображення (або інші дані) потрібно помістити у пристрій – виділяється пам'ять. Спочатку створюється ресурс певних розмірів, потім запитується його вимоги до пам'яті, виділяється йому пам'ять, потім ресурс асоціюється з ділянкою цієї пам'яті і лише потім можна копіювати у ресурс необхідні дані. Також є пам'ять, яка може бути безпосередньо змінена з хоста (host visible), є локальна пам'ятьпристрої (пам'ять відеокарти, наприклад) та інші види пам'яті, що впливають на швидкість доступу до них.

У Vulkan можна написати свій розподіл пам'яті хоста, налаштувавши Callback функції. Але врахуйте, що вимоги до пам'яті, це її розмір, а й вирівнювання (alignment).

Самі ресурси бувають двох видів: буфери (buffers) та зображення (images). І ті й інші розділяються за призначенням, але якщо буфер - це просто колекція різних даних (вершинний, індексний або буфер констант), то зображення завжди має свій формат.

Настанова тим, хто пише на Vulkan

Виділяйте ділянку пам'яті, куди можете помістити відразу кілька ресурсів. Кількість виділень обмежена і вам може не вистачити. Натомість кількість асоціацій не обмежена.

Шейдери

Vulkan підтримує 6 видів шейдерів: вершинний, контроль тесселяції, аналіз тесселяції, геометричний, фрагментний(він же піксельний) та обчислювальний. Написати їх можна на SPIR-V, що читається, а потім зібрати в байт код, який в додатку ми запечатаємо в модуль, тобто. створимо shader-модуль із цього коду. Звичайно, ми можемо написати його на звичному GLSL і потім конвертувати в SPIR-V (транслятор вже є). І, звичайно ж, ви можете написати свій транслятор і навіть асемблер – вихідники та специфікації викладені в OpenSource, ніщо не заважає написати вам збирач для свого High Level SPIR-V. А може, хтось уже написав.
Байт-код потім транслюється в команди, специфічні для кожної відеокарти, але робиться це набагато швидше, ніж із сирого GLSL коду. Подібна практиказастосовується і в DirectX - HLSL спочатку перетворюються на байт код, і цей байт код може бути збережений і потім використаний, щоб не компілювати шейдери знову і знову.

Вікна та дисплеї

А закінчить цю статтю розповідь про WSI (Window System Integration) та ланцюжок перемикань (swapchain). Для того, щоб виводити щось у вікно або на екран, потрібні спеціальні розширення.

Для вікон це базове розширенняплощини та розширення площини, специфічної для кожної із систем (win32, xlib, xcb, android, mir, wayland). Для дисплея (тобто FullScreen) потрібне розширення display, але загалом і те й інше використовують розширення swapchain.

Ланцюжок перемикань не пов'язаний із графічним конвеєром, тому простий Clear Screen виходить без налаштування всього цього. Все досить просто. Існує певний движок показу (presentation engine), в якому є черга зображень. Одне зображення відображається на екрані, інші чекають своєї черги. Кількість зображень ми можемо також вказати. Існує також кілька режимів, які дозволять дочекатися сигналу вертикальної синхронізації.

Метод роботи приблизно такий: ми запитуємо індекс вільного зображення, викликаємо командний буфер, який скопіює результат із Framebuffer у це зображення, і відправляємо команду про відправлення зображення у чергу. Звучить легко, але з урахуванням того, що буде потрібно синхронізація - все трохи складніше, тому що єдине, чого очікує хост - це індекс зображення, яке незабаромбуде доступним. Командний буфер чекає сигналу семафора, який свідчить про доступність зображення, і потім сам подати сигнал через семафор про те, що виконання буфера, в результаті і копіювання, завершено. І зображення справді надійде у чергу за сигналом останнього семафору. Всього два семафори: про доступність зображення для копіювання та доступність зображення для показу (тобто про завершення копіювання).

До речі, я перевірив, що один і той же командний буфер справді вирушав у чергу кілька разів. Можете подумати самі, що це означає.

У цій статті я спробував розповісти про найважливіші частини Vulkan API, але багато що все ще не розказано і це ви можете дізнатися самі. Стабільного вам FPS та приємного кодингу.

У розробці 3D-додатків, відеоігор та систем віртуальної реальностінастає новий етап. Спільними зусиллями розробники зробили важливий крокна шляху до уніфікації коду та більше ефективному використаннюапаратних ресурсів Консорціум Khronos Group, який налічує понад сто компаній, офіційно представив першу версію відкритого кросплатформового API під назвою Vulkan (раніше – GLNext). Він забезпечує безпосередній контроль над ДП та ЦП, усуваючи «вузькі місця» та підвищуючи загальну продуктивність.

На форумах часто можна побачити однотипні питання про те, чи розкриє процесор X відеокарту Y і яка конфігурація при однаковому бюджеті буде продуктивнішою. конкретних додатках. Він виникає через те, що сучасні ДП мають більшу продуктивність, ніж ЦП того ж рівня і покоління. В іграх та інших 3D-додатках часом виникають ситуації, коли на ЦП доводиться велике навантаження, а ДП простоює. Наприклад, процесор обраховує взаємодію гравців та об'єктів, а відеокарта чекає від нього дані, щоб відобразити наступний кадр. Через незбалансованість навантаження виникають затримки, а динамічна гра може перетворитися на покадрове слайд-шоу навіть із потужною відеокартою.

Зазначені проблеми характерні для платформи PC та практично незнайомі власниками ігрових консолей. Розробники консольних ігор завжди знають детальні специфікації приставок і можуть виконувати глибоку оптимізацію коду з урахуванням їх особливостей. Комп'ютери, ноутбуки, планшети – це зоопарк не тільки з різних конфігурацій, а й принципово відмінних архітектур. При створенні ігор для такої різношерстої платформи пріоритетом стає універсальність коду, що негативно позначається на швидкості його виконання.

Розробники операційних системпо-різному намагаються вирішити проблему низької ефективності коду сторонніх додатків. Microsoft почала шукати шляхи оптимізації графічних обчислень давно, проте реальна підтримка низькорівневих операцій з'явилася тільки в DirectX 12. Цей API доступний лише в одній ОС - Windows 10. становище Appleвиявилося ближчим до такого у виробників ігрових консолей. Коли та сама компанія випускає мобільні процесори і софт, його узгодженої роботи досягти куди легше. Тим не менш, шляхи оптимізації самої розробки ігор та програм у Apple далеко не вичерпані. У iOS 8 з'явився Metal API, також орієнтований використання низькорівневих операцій.

Інші великі компаніївважають за краще діяти спільно і в рамках відкритих стандартів. Консорціум Khronos Group, що з'явився 16 років тому, об'єднав більше ста виробників, включаючи таких кревних друзів, як AMD, Nvidia і Intel. Свого часу консорціум виявив на світ відкриті стандарти OpenGL, OpenCL, OpenCV та багато інших.

У порівнянні з OpenGL Vulkan дає розробникам можливість використовувати низькорівневі операції без шкоди для переносимості коду. За допомогою Vulkan на різних платформахможна досягти майже такого ж збалансованого алгоритму, як на спеціалізованих ігрових консолях. Цей API допомагає ефективніше використовувати апаратні можливості дискретних відеокартта інтегрованих графічних чіпів у 2D та 3D-режимах.

Подібно до DirectX 12, Vulkan підтримує прямий доступ до пам'яті GPU. Додатково Vulkan знижує залежність швидкості малювання від якості драйверів. За рахунок трансляції коду шейдерних програм у проміжний двійковий формат їх компіляцію можна виконувати вже на етапі розробки, а не під час запуску 3D-додатка.

Vulkan розробляється із середини 2014 року. В його основу лягли графічні бібліотекиіншого низькорівневого API - AMD Mantle. Компанія AMD також виступала у ролі редактора офіційних специфікацій. Крім них Khronos group опублікувала низку тестів, що демонструють перевагу нового API. Усі вони доступні на порталі GitHub.

«У Vulkan є величезний потенціал, – каже Дін Секулік (Dean Sekulic), програміст Croteam. – Якщо сказати про нього в одному реченні, то з появою Vulkan завершилося давнє протистояння між борцями за продуктивність та переносимість коду. Зараз ми портуємо на нього The Talos Principle на підтвердження нової концепції розробки».

Компанія Valve спонсорує створення відкритого SDK LunarG з підтримкою API Vulkan. Однак, незважаючи на відкриті специфікації, доступні інструменти розробки, можливість глибокої оптимізаціїкоду та інші переваги, Vulkan ще якийсь час буде рідко використовуваним API. Більшість гравців залишаться вірними DirectX 11/12 і OpenGL. Куди простіше підвищити системні вимогиабо зменшити якість графіки, ніж освоювати нові способи розробки. Розуміючи це, консорціум Khronos Group намагатиметься забезпечити підтримку Vulkan не тільки в нових ОС та графічних рішеннях, а й у морально застарілих системах.

Зараз Vulkan підтримується у середовищі Windows(починаючи з сьомої версії), Linux, SteamOS та Android. Найближчим часом очікується додавання підтримки ОС Tizen від Samsung. Бета-версії драйверів з підтримкою API Vulkan вже випустили AMD та Nvidia. На черзі Intel, Qualcomm, ARM та інші виробники, що входять до консорціуму Khronos Group. Демонстрацію Vulkan на графічному чіпі ARM Mali можна побачити нижче.

В даний час Vulkan можна протестувати на відеокартах з графічними чіпами Nvidia GeForce GT 630 і вище, AMD Radeon HD 7700 та новіший. Також API Vulkan підтримує гібридні процесори AMDз графічним ядром Radeon HD 8500 – 8900 та R2 – R9. Вбудована графіка десктопних та мобільних процесорів Intel підтримується Vulkan починаючи з сімейства Coreп'ятого покоління.

Повністю можливості нового API розкриються перспективними графічними процесорами Nvidiaсерії Pascal та AMD з архітектурою GCN четвертого покоління. Відповідні відеокарти імовірно увійдуть до серію GTX 1xxx і Radeon Rx 400. За неофіційними даними, початок їх продажів планується на другий квартал 2016 року.

Vulkan – це нове API для створення 3D додатків. Його розробило Khronos Group, яка займається розвитком OpenGL. Великий внесок у створення APIвклала компанія AMD. Хоча багато інших компаній працювали над ним, наприклад Microsoft, Apple, Google, Sony. Це API підтримують такі творці "заліза" як: NVidia, AMD, Intel, Qualcomm, Imagination Technologies, ARM.

Чим відрізняється Vulkan від OpenGL

Стаття на Вікіпедії виділяє 4 основні відмінності:

1. Жодних глобальних станів, всі стани прив'язані до об'єктів.
2. Стану прив'язуються до буфера команд, а чи не до контексту, як у OpenGL.
3. У OpenGL робота з пам'яттю та синхронізація відбувається не явно, у Vulkan розробник буде мати можливість контролювати це.
4. Відсутність перевірки помилок у драйвері, для прискорення роботи.

Виходячи з того, що нове API з'явилося в наші дні і протягом 18 місяців Khronos Group його розробляло в тісному контакті з провідними IT компаніями світу, можна робити висновок, що API має краще підійти для сучасних 3D додатків.

Нижче ви можете побачити схему роботи Vulkan:

Чи буде Vulkan на Mac OS X?

Після того як специфікація Vulkan була опублікована, знайти драйвера для сучасних відеокартне складає труднощів. Але це лише для Windows та Linux. Так як вулкан це тільки кросплатформовий API, який не вимагає особливої ​​підтримки з боку відеокарт, оновивши драйвер, ви можете почати його використовувати (якщо звичайно ваша відеокарта в списку підтримуваних).

Для Mac OS X все набагато складніше. У El Capitan підтримки Vulkan немає, хотілося б чекати у наступних версіяхОднак є одне "але". Apple в El Capitan додала підтримку свого API – Metal. Раніше він використовувався лише для пристроїв на iOS. Виходячи з цього, а також враховуючи той факт, що Apple звикло контролювати все, що стосується їх пристроїв, можна дійти невтішного висновку, що Vulkan може і з'явитися на Mac OS X.

Що далі?

На мою думку, що чекає на Vulkan багато в чому залежить від того, наскільки активно його почнуть використовувати розробники та підтримувати виробники відеокарт. Якщо розвиток OpenGL на цьому зупиниться, то для нових програм вибору не буде і їх доведеться розробляти на Vulkan. Але існують тисячі програм на OpenGL, які ніхто так відразу не кинеться переписувати на Vulkan. Ще й питання з Mac OS X не зрозуміле, оскільки це дуже поширена система в США. Якщо для Mac OS X буде Metal, під Windows - DirectX, а під Linux Vulkan, то Vulkan не полегшить розробку кросплатформових додатків.