API (Application Programming Interface) надають розробникам апаратного та програмного забезпечення засоби створення драйверів та програм, що працюють швидше на великій кількості платформ. Програмні драйвери розробляються для взаємодії безпосередньо з API, а не з операційною системою та програмним забезпеченням.

В даний час існує два графічні API - OpenGL (компанія SGI) та Direct 3D (Microsoft).

Хоча виробники відеоадаптерів підтримують стандарт OpenGL, компанія Microsoft надає підтримку Direct3D для комплексного API, званого DirectX.

DirectX 9 і вище є останніми версіями програмного інтерфейсу, що розширив підтримку тривимірної графіки та забезпечив покращені ігрові можливості. Для отримання додаткової інформації щодо DirectX або завантаження його останньої версії зверніться на веб-сайт DirectX компанії Microsoft: www.microsoft.com/directx.

CrossFire або sli

У відповідь на розробку та просування старої-нової технології SLI (МК №30(357) 2005) компанією NVIDIA, головний конкурент на ринку відеоприскорювачів, компанія ATI розробила та впровадила своє аналогічне рішення - технологію CrossFire. Так само, як і SLI від NVIDIA, вона дозволяє поєднувати ресурси двох відеокарт в одному комп'ютері між собою, підвищуючи продуктивність відеопідсистеми. Технологія CrossFire докорінно відрізняється від SLI, відповідно, має мало спільного з конкурентом. Віддаючи перевагу певним перевагам тієї чи іншої технології, в недалекому майбутньому користувачі будуть вибирати між NVIDIA і ATI не тільки виходячи з думок про бренди, що сформувалися, але і базуючись на фактах про технології SLI або CrossFire.

Технічна база

За аналогією з NVIDIA, для розміщення двох відеокарт ATI в одній «упряжці» буде потрібна материнська плата з чіпсетом того ж виробника (планується, що підтримувати CrossFire також буде чіпсет Intel i975X) з двома слотами PCI Express. Як і SLI, CrossFire вимоглива до системних ресурсів, що вимагатиме якісного БП. Розглянемо вимоги до системи детальніше.

Материнська плата.Мати має бути заснована на чіпсеті ATI Radeon Xpress 200 CrossFire. Дані плати випускаються як процесорів AMD Sempron/Athlon 64, так Intel Pentium 4/Celeron. Отже, ATI тепер зароблятиме і на чіпсетах, виробництво яких раніше не досягало великих масштабів.

Відеокарти.Для роботи технології необхідна провідна карта CrossFire master (детальніше про це нижче) і будь-яка інша відеокарта на базі чіпа з того ж сімейства, що і провідна картка. Провідну картку від інших відрізняє наявність роз'єму DMS-59 (що з'єднується з DVI на карті), чіпа CrossFire, ну і, звичайно ж, вартість.

Блок живлення.Для такого серйозного комплекту знадобиться БП з потужністю 400–450 Вт мінімум, бажано потужніший.

Ну ось, власне, і все, що потрібно для складання відеосистеми CrossFire. Як ви помітили, ATI гнучкіше ставиться до своїх покупців, не прив'язуючи їх, як землю до колгоспу, до обов'язкової купівлі двох карток з однаковим чіпом від одного виробника. Прив'язка здійснюється лише до сімейства відеочіпа, на якому базується прискорювач. Тобто, можна придбати провідний відеоприскорювач Radeon X800 і Radeon X800 XL. Master Radeon X800 буде сумісний із карткою будь-якого виробника на базі будь-якої модифікації чіпа X800. Це безумовна перевага над конкурентом – якщо брати один прискорювач, з перспективою подальшої модернізації шляхом доустановки ще однієї відеокарти, то не доведеться нишпорити у пошуках картки якогось певного виробника на базі конкретного чіпа. На даний момент технологію CrossFire підтримують відеокарти на базі X800 та X850, а також новинки на базі X1xxx.

зуються більш високим ступенем стиснення, ніж зображення з низьким вмістом таких елементів (наприклад, графіки, схеми, прості текстури). Зображення з високою роздільною здатністю можна стискати з високим ступенем стиснення, не впливаючи на їхню якість. Для збереження високої якості зображень з низькою роздільною здатністю підсумковий ступінь стиснення повинен бути набагато нижчим. Зображення з великою глибиною кольору (наприклад, 24-бітові Truecolor-зображення) стискаються ефективніше, ніж зображення з меншою кількістю біт на піксель (зокрема, 8-бітові напівтонові).

Більшість інших методів стиснення із втратами за своїм характером симетричні. Це означає, що вони ґрунтуються на використанні конкретної послідовності операцій, які при розпакуванні виконуються у зворотному порядку. На стиснення та розпакування даних потрібен приблизно однаковий час. Фрактальний стиск – процес асиметричний, стиск триває набагато довше, ніж розпакування. Звідси випливає, що фрактально стислі дані доцільно застосовувати у тих випадках, коли файли зображень часто розпаковуються, але ніколи не стискаються, наприклад, при зберіганні зображень у графічних базах даних на CD-ROM.

Нижче коротко розглянуті деякі найбільш поширені форми

Сучасні графічні API-інтерфейси

Розробка сучасних складних графічних програм, особливо 3D-додатків, нерозривно пов'язана з використанням API-інтерфейсів

(Application Programming Interface).

API – це набір бібліотек, що є готовим інтерфейсом для роботи програми з 3D-акселераторами. В даний час подібних ін-

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

Універсальні API є спільними для всіх 3D-акселераторів, а підтримка апаратного прискорення для цих API покладається на прискорювачі. У першу чергу тут слід виділити Microsoft DirectX і OpenGL. Обидва вони використовуються переважно в програмах комп'ютерної анімації.

Спеціалізовані API призначені для роботи з графічними акселераторами, які побудовані на певних 3D-чіпсетах; найбільш відомими серед них є Glide API – інтерфейс для роботи з чіпами VooDoo®; Metal – для чіпів Savage3D і т.п. Програми, написані з використанням спеціалізованих API, працюють лише тих акселераторах, під які створювалися ці API. Більшість спеціалізованих API надає лише низькорівневий інтерфейс програмування, однак останнім часом нові версії DirectX включають інтерфейси високорівневої підтримки, такі як DirectX for VisualBasic, який здійснює мовну підтримку мультимедіа-додатків, написаних у середовищі візуального програмування Visual Basic.

API Microsoft DirectX

API Microsoft DirectX – це набір програмних інтерфейсів, які застосовуються для вирішення різних завдань: від програмного управління апаратним забезпеченням комп'ютера до розробки мультимедійних програм, що використовують різні типи інформації, та створення віртуальних світів.

Основна мета, яку переслідувала фірма Microsoft, створюючи інтерфейс DirectX - перетворити комп'ютери, що працюють під керуванням операційної системи Windows, на універсальну платформу для додатків, багатих на мультимедійні елементи: повнокольоровою графікою, відеофрагмен-

тами, тривимірною анімацією та стереозвуком. Вбудований безпосередньо в ядро ​​Windows інтерфейс DirectX є інтегрованим сервісом

Windows 98 та Windows 2000, а також Microsoft Internet Explorer. Компоненти

DirectX можуть бути також автоматично завантажені на комп'ютер при установці сучасних ігор та мультимедійних програм, розроблених для Windows 95. Для розробників DirectX представляє набір програмних інтерфейсів, використання яких дозволяє вирішити дві основні завдання.

По-перше, DirectX перетворює розроблені з його допомогою програми на програми, сумісні з будь-якою версією Windows і працюють на будь-якому комп'ютері, де встановлена ​​ця операційна система, незалежно від типу програмного забезпечення, що використовується. При цьому подібні програми максимально використовують технічні можливості комп'ютера, забезпечуючи найвищу продуктивність. Це досягається за рахунок сервісу, що надається двома основними компонентами DirectX: низькорівневими інтерфейсами, що входять до складу DirectX Foundation, та високорівневими інтерфейсами, що становлять DirectX Media.

По-друге, DirectX надає розробникам можливість абстрагуватися від конкретного типу дисплейного адаптера, звукової карти або 3D-прискорювача і зосередитися на логіці роботи самої програми.

DirectX Foundation надає у розпорядження розробників набір низькорівневих програмних інтерфейсів, який забезпечує ефективний доступ до всіх можливостей комп'ютера, що працює під керуванням Windows, реалізованим на рівні апаратного забезпечення – 3D-прискорювачам, звуковим картам, пристроям введення інформації. До появи DirectX розробники, які створювали мультимедійні програми для платформи Windows, мали налаштовувати свої програми працювати з різними типами пристроїв і конфігурацій. Тепер цю проблему усунуто. DirectX Foundation містить компонент, відомий як "шар апаратної абстракції" (Hardware Abstraction Layer, HAL), який використовує програмні

драйвери для забезпечення взаємодії програмних та апаратних засобів. В результаті розробники можуть створювати єдину версію програми з використанням інтерфейсів DirectX, не переймаючись тим, щоб вона працювала на конкретних апаратних конфігураціях. DirectX автоматично визначає технічні можливості комп'ютера та встановлює відповідні параметри. DirectX також дозволяє виконувати мультимедійні програми, які потребують апаратної підтримки, яка відсутня на цьому комп'ютері. У цьому випадку вони програмно емулюються компонентом, який називається шар апаратної емуляції (Hardware Emulation Layer, HEL) і забезпечує програмні драйвери, що працюють як відсутні пристрої.

DirectX Media розташовується над DirectX Foundation та забезпечує високорівневі сервіси – підтримку анімації, потоковий висновок (можливість передачі та перегляду аудіо- та відеоінформації в міру її завантаження з Internet) та інтерактивність. Автоматична інтеграція низькорівневих сервісів, що реалізуються DirectX Foundation, та високорівневих, реалізованих у DirectX Media, полегшує процес створення та відтворення мультимедійних елементів, дозволяючи розробникам включати їх у свої програми та Web-сторінки та забезпечуючи тим самим недоступне раніше інтерактивне мультимедійне. Крім того, DirectX Media допомагає вирішити задачу координації різних типів мультимедійних ефектів, полегшуючи синхронізацію їх відтворення. Крім двох зазначених основних складових Microsoft DirectX до їх складу також входять високорівневі компоненти, які забезпечують мультимедійні функції для Web-додатків. До них відносяться: NetMeeting – засіб для організації групових онлайнових дискусій та Windows Media Player – засіб для передачі мультимедійного вмісту по Internet. Розглянемо коротко основні ком-

Поненти DirectX Foundation. До них відносяться Microsoft DirectDraw, Direct3D(режимиImmediate іRetained ), DirectInput , DirectMusic , DirectSound ,

DirectSound 3D і DirectPlay. Ці програмні інтерфейси системного рівня

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

Microsoft Direct3D є інтерфейс для роботи з 3Dвідеокартами. Архітектура Direct3D представлена ​​малюнку 1.5.

Win32-додаток

Direct3D підтримує два режими роботи - Immediate Mode і Retained Mode. У режимі Immediate Mode Direct3D забезпечує розробникам апаратну підтримку ігрових та мультимедійних програм у середовищі Microsoft Windows. Він дозволяє домогтися апаратної незалежності, підтримує Z-буферизацію, що перемикається, і Intel ММХ-архітектуру процесорів. У цьому режимі основні графічні примітиви реалізуються безпосередньо без використання буферів виконання (execute buffers).

Режим Retained Mode полегшує створення та анімацію тривимірних світів, підтримуючи дві нові функції: інтерполятори анімації зі змішуванням кольорів, плавними переміщеннями об'єктів та безліччю різних видів трансформації, а також послідовне заповнення сіткової структури 3D-

об'єктів (meshes), що дозволяє здійснювати їхнє поступове завантаження з віддалених серверів. Це дає можливість розробникам ефективно використовувати тривимірну графіку, звільняючи їхню відмінність від необхідності прямого управління структурами об'єктів низькому рівні.

Слід зазначити, що Direct3D-програми спілкуються з графічними пристроями однаково, незалежно від режиму. Перед використанням HAL можуть використовувати або не використовувати програмну емуляцію. Реально Direct3D тісно інтегрований з компонентом DirectDraw, тому малюнку 1.2 шар апаратної абстракції HAL позначений як DirectDraw/Direct3D HAL. Direct3D здійснює Z-буферизацію та рендеринг поверхонь, а їх безпосереднє відображення виконує DirectDraw. СОМ-інтерфейс Direct3D є інтерфейсом до DirectDraw.

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

На малюнку 1.6 показано взаємодію між DirectDraw, компонентом ядра операційної системи GDI (Graphics Device Interface), шаром апаратної абстракції (Hardware Abstraction Layer, HAL) та шаром апаратної емуляції

(Hardware Emulation Layer, HEL). Як видно, DirectDraw існує незалеж-

Мо від GDI і обидва інтерфейси мають можливість прямого доступу до графічних пристроїв через апаратно-незалежні шари. На відміну від GDI DirectDraw, можливості використовує апаратні функції. Якщо конкретний пристрій не підтримує потрібні функції, DirectDraw намагається їх емулювати, використовуючи HEL. DirectDraw підтримує роботу з великою кількістю дисплейних адаптерів - від найпростіших моніторів до складних професійних пристроїв. Працюючи на рівні графічних поверхонь, DirectDraw служить

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

Win32-додаток

Відеокарта

Рисунок 1.6 – Інтеграція DirectDraw у систему

DirectInput є інтерфейс до різних пристроїв введення інформації - клавіатурі, маніпулятору типу «миша», джойстику, а також до пристроїв зі зворотною віддачею (force-feedback). У порівнянні зі звичайними стандартними функціями даний інтерфейс підтримує більшу кількість пристроїв і забезпечує більш швидку реакцію на запити. Працюючи безпосередньо з драйверами пристроїв, DirectInput не використовує систему обміну повідомленнями Microsoft Windows.

До нових можливостей DirectInput відноситься розширений список підтримуваних пристроїв, у тому числі: ігрові панелі (game pads), авіаційні

рулі (flight yokes), шоломи віртуальної реальності (virtual-reality headgear)

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

DirectMusic – це новий компонент сімейства технологій DirectX, що є програмною оболонкою для створення музичних шаблонів та інструкцій щодо реакції на дії користувача. Це дозволяє розробникам створювати фонову музику в реальному часі на основі алгоритмів, що задаються на веб-сторінках або мультимедійних додатках. DirectMusic забезпечує повну реалізацію стандарту DownLoadable Sounds (DLS), що дозволяє розробникам створювати музичні шаблони, які відтворюються практично на будь-якій апаратній платформі. До складу DirectMusic входить DirectMusic Producer - інтегрований редактор, що дозволяє працювати з усіма об'єктами DirectMusic: стилями, шаблонами, інструментами DLS і т.д.

DirectPlay є високорівневим програмним інтерфейсом між прикладною програмою та комунікаційними сервісами, який спрощує зв'язок по модему або локальній мережі. До складу DirectPlay входить набір утиліт, що дозволяє граючим знаходити партнерів та Web-вузли, підтримувати потік інформації між серверами, причому для будь-якого користувача програми підтримується однаковий набір функцій незалежно від типу онлайнового сервісу або протоколів.

У доповнення до низькорівневих інтерфейсів DirectX Foundation до складу DirectX входить більш високорівневий набір програмних інтерфейсів

та компонентів DirectX Media , що забезпечують підтримку мультимедійних програм, анімації та потокового виведення інформації. В даний час DirectX Media складається з наступних основних програмних інтерфейсів:

DirectShow (раніше називався ActiveMovieSDK); DirectAnimation (раніше називався ActiveX Animation); DirectX Transform. Зазначимо, що сервіси DirectX Media використовують сервіси DirectX Foundation.

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

Енциклопедичний YouTube

• 1 / 5

  API визначає функціональність, яку надає програма (модуль, бібліотека), при цьому API дозволяє абстрагуватися від того, як ця функціональність реалізована.

  Якщо програму (модуль, бібліотеку) розглядати як чорний ящик , то API - це безліч «ручок», які доступні користувачеві даної скриньки і які він може крутити і смикати.

  Програмні компоненти взаємодіють один з одним за допомогою API. При цьому компоненти зазвичай утворюють ієрархію - високорівневі компоненти використовують API низькорівневих компонентів, а ті, у свою чергу, використовують API ще більш низькорівневих компонентів.

  За таким принципом побудовано протоколи, передачі даних по Інтернету. Стандартний стек протоколів (мережева, модель, OSI) містить 7 рівнів (від фізичного рівня передачі біт до рівня протоколів додатків, подібних до протоколів HTTP та IMAP). Кожен рівень користується функціональністю попереднього («нижньолежачого») рівня передачі і, своєю чергою, надає потрібну функціональність наступному («вищележачому») рівню.

  Поняття протоколу близьке за змістом до поняття API. І те, й інше є абстракцією функціональності, тільки в першому випадку йдеться про передачу даних, а в другому – про взаємодію додатків.

  API бібліотеки функцій і класів включає опис сигнатурі семантики функцій.

  Сигнатура функції

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

  Наприклад, у мові програмування C++ проста функція однозначно пізнається компілятором з її імені та послідовності типів її аргументів, що становить сигнатуру функції у цій мові. Якщо функція є способом деякого класу, то сигнатурі братиме участь і ім'я класу.

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

  З іншого боку, відмінності в API різних операційних систем суттєво ускладнюють перенесення програм між платформами. Існують різні методи обходу цієї складності - написання «проміжних» API (API графічних інтерфейсів wxWidgets , , GTK тощо), написання бібліотек, які відображають системні виклики однієї ОС у системні виклики іншої ОС (такі середовища виконання, як Wine , cygwin і т. п.), запровадження стандартів кодування в мовах програмування (наприклад, стандартна бібліотека мови C), написання інтерпретованих мов, що реалізуються на різних платформах ( , python , perl , php , tcl , Java тощо).

  Також необхідно відзначити, що в розпорядженні програміста часто знаходиться кілька різних API, що дозволяють досягти одного і того ж результату. У цьому кожен API зазвичай реалізований з допомогою API програмних компонент нижчого рівня абстракції.

  Наприклад: щоб побачити у браузері рядок «Hello, world! », Досить лише створити HTML-документ з мінімальним заголовком і найпростішим тілом, що містить цей рядок. Коли браузер відкриє цей документ, програма-браузер передасть ім'я файлу (або вже відкритий дескриптор файлу) бібліотеці, що обробляє HTML-документи, та, у свою чергу, за допомогою API операційної системи прочитає цей файл і розбереться у його пристрої, потім послідовно викличе через API бібліотеки стандартних графічних примітивів операції типу «очистити віконце», «написати „Hello, world!“ вибраним шрифтом». Під час виконання цих операцій бібліотека графічних примітивів звернеться до бібліотеки віконного інтерфейсу з відповідними запитами, ця бібліотека звернеться до API операційної системи, щоб записати дані в буфер відеокарти .

  При цьому практично на кожному рівні реально існує кілька можливих альтернативних API. Наприклад: ми могли б писати вихідний документ не на HTML, а на LaTeX, для відображення могли б використовувати будь-який браузер. Різні браузери, взагалі кажучи, використовують різні HTML-бібліотеки, і, крім того, все це може бути зібрано з використанням різних бібліотек примітивів та різних операційних системах.

  Основними складностями існуючих багаторівневих систем API, таким чином, є:

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

  Найбільш відомі API

  Операційних систем

  Ще кілька років тому Apple представила нове графічне API – Metal. Відмінність його від того ж Scene Kit була в тому, що він є не високорівневим API, що працює поверх OpenGL ES (мобільної версії OpenGL), а низькорівневим API для рендерингу та обчислень, який може замінити OpenGL. За словами Apple, Metal на порядок швидше за OpenGL ES (правда, насправді в 10 разів швидше відбуваються тільки виклики відмальовки - draw calls, передача даних на GPU). Цей API доступний для всіх пристроїв, що працюють на процесорі A7 і новіші, а також на Mac починаючи з 2012 року.

  Принципи роботи графічних API
  
  Для початку – що таке API? Розшифровується це як Application Programming Interface, програмний інтерфейс програми. Говорячи простою мовою – це готовий код, який дозволяє суттєво полегшити життя програмісту під час написання програм. По суті це деякий напівфабрикат – ґрунтуючись на цьому коді можна набагато швидше та простіше написати свою програму.

  Тепер розберемося з тим, як сам GPU працює з API. Невірно думати, що виклик API безпосередньо працює з GPU, і тим більше невірним є те, що GPU закінчує обробку виклику при поверненні результату API. Наприклад, якби драйвер виконував команди рендерингу в той момент, коли вони були створені, то простоював CPU, очікуючи виконання рендерингу. А після виконання було б навпаки - простоював GPU, чекаючи поки прийдуть нові команди від драйвера.

  З цієї причини CPU і GPU працюють асинхронно: графічний драйвер спочатку збирає всі виклики для всього кадру, і тільки потім відправляє їх на GPU. Далі, коли приходить команда на відтворення наступного кадру, цей кадр вже буде оброблений GPU. Тобто ми отримуємо затримку в один кадр: доки CPU готує виклик для поточного кадру, на GPU рендерується минулий. Насправді можна буферизувати і більше одного кадру, і тим самим отримувати більшу частоту кадрів: все залежить лише від продуктивності процесора та відеокарти.

  Нововведення в API Metal
  
  У чому поганий метод, описаний вище? Він поганий у тому, що між GPU та API є посередник – драйвер. І саме він керує затримками. В API Metal ж буфери команд відкриті, і програма може сама їх заповнювати і відправляти в чергу команд для виконання на GPU. Таким чином, програма має повний контроль над завданням і може керувати затримками. Більше того - тепер можна легко паралелити команди і поміщати їх у буфер у певному порядку, тому що для програміста стає очевиднішим те, які результати в якому порядку будуть доступні.

  Ще одне важливе нововведення вже апаратне: на процесорах Apple A7 і вище Metal заточено під роботу із загальною пам'яттю, тобто CPU та GPU можуть отримувати доступ до одних даних без необхідності перекидати їх по шині PCI. Metal дає прямий доступ для програми до буферів CPU, і програміст цілком може «змішувати» обчислення на GPU та CPU, що може суттєво прискорити програму.

  Реальний виграш від API Metal
  
  Як я пояснював вище, кожен виклик малювання займає деякий час на CPU та GPU. Ренденринг на GPU зробити швидше не можна з очевидних причин (він зав'язаний лише на продуктивність самого GPU), але можна виграти в іншому: по-перше, можна зменшити час на передачу даних (оскільки Metal працює із загальною пам'яттю), по-друге - зменшити час обробки дзвінка на CPU. Час обробки виклику на CPU зменшується за рахунок відсутності посередника-драйвера та за рахунок паралельної побудови буфера команд.

  І тут виникає питання - а про яке десятикратне збільшення продуктивності йшлося Apple? Та ось саме про те, що час виклику на CPU тепер значно менший. Але ось GPU тут майже не торкається, так що в результаті безпосередньо покращити графіку за рахунок API Metal на жаль – не можна. Але так як звільнився процесор - його можна завантажити фізикою: обчисленням фізики частинок, взаємодії безлічі об'єктів (усі пам'ятають сотню мавп, що літають, на презентації iPhone 7?), обчисленням ефектів тканини і води, і так далі. І оскільки цим раніше займався GPU, то ми його звільняємо, і виходить що опосередковано він тепер може виводити найкращу картинку, що ми в іграх (у тому ж Asphalt 8) і бачимо (зверніть увагу на деталізацію бруківки та ефекти):

  

  Взаємодія OpenGL та Metal
  
  Як видно з вищенаписаного – реально Metal покращує життя процесору. Тому якщо система не підтримує Metal, але має дуже потужний процесор, то особливих труднощів переписати гру під OpenGL немає - і саме це ми і бачимо у Vainglory під Android - для отримання максимальної графіки (рівень Apple A9) на OpenGL потрібен топовий процесор рівня Snapdragon 820 , Що за голою продуктивності (у FLOPS-ах) потужніше A9 в два з копійками рази.

  Apple Metal 2
  
  На червневій презентації Apple представила нову версію Metal. Основні поліпшення - це підтримка VR, машинного навчання та зовнішніх GPU, що в теорії дозволить портувати під Mac ігри з PC без усілякого погіршення графіки (на даний момент порти більшості ігор є по суті запуск Wine, що досить сильно знижує продуктивність і дуже відбивається на і так досить слабких GPU в Mac). Але як це буде реальність – побачимо вже тільки в майбутньому.

  Минулого тижня було представлено API Vulkan, про широку підтримку якого заявили AMD та NVIDIA. Новий графічний інтерфейс розробляв Khronos Group, консорціум, заснований у 2000 році. Khronos Group відповідає за розробку та підтримку відкритих стандартів у сфері мультимедійних програм на різних платформах та пристроях. Консорціум підтримують AMD та NVIDIA, а також багато інших компаній.

  Минулого тижня було ратифіковано фінальну версію 1.0 API Vulkan. AMD та NVIDIA представили відповідні бета-драйвери. AMD наперед випустила бета-версію Radeon Software ще 14 лютого. NVIDIA представила драйвер GeForce 356.39, який також орієнтований на підтримку API Vulkan.

  Підхід API Vulkan дуже схожий на API Mantle. Суть у тому, щоб розробники отримали глибший доступом до «залізу», щоб вичавити з нього максимум. Такий підхід дозволяє максимально уникнути існуючих «вузьких місць». З іншого боку, розробники повинні точно знати, що роблять – наприклад, під час роботи з пам'яттю. Інтерфейс OpenGL не такий популярний, як DirectX, але дозволяє вичавити більше.

  Інтерфейс API Vulkan у версії 1.0 підтримується під Windows 7, Windows 8.1, Windows 10, Android та Linux. Розробники ігор поки що не оголосили підтримки в конкретних іграх, але тут варто дочекатися Games Developer Conference, яка проводитиметься з 14 по 18 березня в Сан-Франциско. З ігрових движків поки є інформація про Source 2, який вже підтримує API Vulkan. Процес налагодження полегшується підтримкою Valve, LunarG та Codeplay.

  The Talos Principle

  Добре, але яка гра чи двигун підтримують API Vulkan? Гра The Talos Principle розроблялася компанією Croteam, яка й у минулому була відома підтримкою багатьох графічних API. І в останній ітерації гра The Talos Principle не стала винятком - вона підтримує DirectX 9, DirectX 11, OpenGL і тепер Vulkan. Для студії розробників Vulkan є пробною кулею, хоча API Vulkan доступний у версії 1.0, підтримка поки що знаходиться в бета-стадії. На додавання підтримки розробники Croteam витратили близько трьох місяців. Але універсальний характер API дозволяє невдовзі уявити варіант Linux.

  API Vulkan теоретично сумісний з кількома платформами – але поки що тести та порівняння можна провести лише під Windows, причому тут є обмеження. Реалізація поки що залишається на дуже ранньому етапі. Шлях рендерингу DirectX 11 удосконалювався багато років, тож потенціалу для оптимізації тут уже немає. Тут ситуація більше залежить від розробників драйверів, зокрема AMD і NVIDIA. Гра The Talos Principle стала першою за підтримки Vulkan. Тому поки що немає можливості зробити порівняльний тест для оцінки хорошої чи поганої реалізації підтримки.

  Нові технології спочатку реалізуються в прикладах, підготовлених виробниками. У випадку DirectX 12 акцент був виставлений на Draw Calls, той же тест 3DMark DirectX 12 спирається тільки на вимірювання продуктивності Draw Calls, ігри DirectX 12, подібні до Star Wars, теж намагаються задіяти подібне навантаження. Але The Talos Principle не дуже залежить від високої швидкості Draw Call, щоб низькорівневий API дав велику різницю.

  Підтримка API Vulkan версії 1.0 знаходиться на ранній стадії, те саме стосується драйверів AMD і NVIDIA. Обидва драйвери по суті ставляться до бета-версій, саме так їх розглядають виробники GPU. Тут зазвичай немає нових покращень продуктивності або підтримки нових технологій, тому ми отримуємо крок назад. Але як тільки певного рівня розробки буде досягнуто, драйвери обох розробників GPU отримають підтримку Vulkan у фінальній версії. Коли це станеться – не зовсім зрозуміло. Але поки що ключові програми не використовують Vulkan і ігри з підтримкою API знаходяться в стані бета-версії, так що розробники GPU можуть спокійно допрацьовувати свої драйвери.

  Для тестів ми взяли нашу тестову систему відеокарт. Драйвери відеокарт AMD та NVIDIA ми вже описали вище. У налаштуваннях ми виставили максимальний рівень графіки, але протестували і низькі дозволи аж до 1.280 x 720 пікселів, щоб збільшити продуктивність Draw Call.

  Тест The Talos Principle - 1.280 x 720 пікселів
  

  Тест The Talos Principle - 2.560 x 1.440 пікселів
  

  Тест The Talos Principle - 3.840 x 2.160 пікселів
  

  Як бачимо за результатами, API Vulkan дає істотний приріст проти OpenGL. Але до продуктивності DirectX 11 новий API не дотягує. Тому є кілька причин. З одного боку, розробка під Vulkan знаходиться на ранній стадії. Це стосується і самого API, і драйвера, і The Talos Principle. Порівняно з OpenGL новий інтерфейс дозволяє звільнити частину ресурсів та уникнути «вузьких місць». Але DirectX багато років удосконалювався до поточного рівня. У будь-якому випадку, потенціал API Vulkan дуже хороший.

  Якщо поринути у деталі, то візуальних відмінностей між API Vulkan та DirectX 11 ми не виявили. Отже, шлях рендерингу дуже добре адаптований. У поточній реалізації The Talos Principle відеокарти з 2 Гбайт пам'яті отримують падіння продуктивності, ймовірно, через не найефективнішу роботу з пам'яттю. Як і Mantle і DirectX 12, API Vulkan може звертатися до ресурсів пам'яті на глибшому рівні – цей факт можна розглядати як перевагу, але може стати і недоліком, якщо розробники не зможуть ефективно використовувати пам'ять.

  Дещо розчарувала помилка в поточному драйвері NVIDIA, через яку після кожного тесту доводилося перезавантажувати систему. Без перезавантаження гра "вилітала". Хоча з драйвером AMD ми не виявляли такої помилки.

  Нинішня реалізація API Vulkan здається обіцяючою. Поки що для ігор на настільних ПК вона буде не така актуальна, оскільки ринок DirectX 11 і 12 дуже великий, і в порівнянні з тим же DirectX 12 витрати на реалізацію можуть бути занадто великі, а віддача занадто мала. Але якщо ігри необхідно запускати на різних платформах із різними апаратними вимогами, Vulkan може відіграти важливу роль. У будь-якому випадку, слід дочекатися реакції з боку розробників ігор, інакше ми отримуємо проблему курки та яйця, з якої важко вийти.