O scurtă prezentare a API-ului Vulkan

Deci, care este mare lucru cu acest nou Vulkan API și de ce ar trebui să ne pese?

Iată API-ul Vulkan într-o sută de cuvinte sau mai puțin: este un API cu costuri reduse, aproape de metal pentru aplicații de grafică 3D și de calcul. Vulkan este practic o continuare a OpenGL. A fost denumită inițial „inițiativa OpenGL de generație următoare” și include câteva fragmente din API-ul AMD Mantle. Vulkan ar trebui să ofere numeroase avantaje față de alte API-uri GPU, permițând suport superior pentru mai multe platforme, suport mai bun pentru procesoare cu mai multe fire, încărcare mai scăzută a CPU și un pic de agnosticism al sistemului de operare. De asemenea, ar trebui să faciliteze dezvoltarea driverelor și să permită pre-compilarea driverelor, inclusiv utilizarea shaderelor scrise în diferite limbi.

Sunt 93 de cuvinte, așa că dacă nu ești interesat, poți sări peste următoarele 3.500. Dacă, pe de altă parte, doriți să aflați mai multe despre viitoarea API grafică care va fi cu noi în anii următori, voi începe cu elementele de bază.

Cum a apărut Vulkan API

Vulkan a fost anunțat inițial de grupul Khronos în martie 2015, cu o dată provizorie de lansare stabilită pentru sfârșitul anului 2015. În cazul în care nu sunteți familiarizat cu Khronos, este un consorțiu non-profit fondat în urmă cu cincisprezece ani de unele dintre cele mai mari nume din industria grafică, inclusiv ATI (acum o parte a AMD), Nvidia, Intel, Silicon Graphics, Discrete și Sun Microsystems. Chiar dacă nu ați auzit de Khronos, probabil că ați auzit de unele dintre standardele lor, cum ar fi: OpenGL, OpenGL ES, WebGL, OpenCL, SPIR, SYCL, WebCL, OpenVX, EGL, OpenMAX, OpenVG, OpenSL ES, StreamInput, COLLADA și glTF.

Până acum, probabil că te gândești „Ah, sunt tipii ăia”, așa că pot sări peste restul introducerii și să mă concentrez pe API-ul în sine.

Spre deosebire de predecesorul sau predecesorul său, Vulkan este proiectat de la zero pentru a rula pe diverse platforme, de la telefoane mobile și tablete, la console de jocuri și desktop-uri de ultimă generație. Designul de bază al API-ului este stratificat, sau ar trebui să spunem modular, astfel încât permite crearea unei arhitecturi comune, dar extensibile pentru validarea codului, depanare și profilare, fără a afecta performanța. Krhonos susține că abordarea stratificată va oferi mult mai multă flexibilitate, va cataliza inovația puternică în instrumentele GPU-uri între furnizori și va oferi un control mai direct al GPU-ului cerut de motoarele de joc sofisticate.

Acum, înțeleg că mulți tehnofili au rezerve în ceea ce privește termenii de marketing precum „flexibil”, „extensibil” și „modular”, dar de data aceasta avem de-a face cu adevăratul McCoy. De fapt, aceasta este ideea de bază din spatele Vulkan: este conceput ca un API pentru mase, de la copii care se joacă pe smartphone-uri, până la părinții lor care proiectează clădiri și jocuri pe stațiile de lucru.

În teorie, Vulkan ar putea fi folosit în hardware de calcul paralel, pentru a controla zeci de miliarde de nuclee GPU, în purtabile minuscule și drone de jucărie, în imprimante 3D, mașini, kit VR și aproape orice altceva cu un GPU compatibil în interior.

Pentru mai multe detalii, vă sugerez să aruncați o privire la prezentarea generală oficială a Vulkan în PDF.

ADN Manta AMD

Dacă abordarea aproape de metal sună ciudat de familiară, este posibil să fi urmărit anunțurile AMD GPU în ultimii doi ani și ceva. AMD a surprins observatorii din industrie când și-a anunțat Mantle API în 2013 și i-a surprins încă o dată când a decis să renunțe la API, anunțând în martie 2015 că nu va lansa Mantle 1.0 ca SDK public. Pe scurt, Mantle a promis că va oferi îmbunătățiri semnificative de performanță și eficiență în unele situații, în special pe partea CPU, deoarece ar reduce supraîncărcarea de procesare. S-a părut o idee bună, deoarece jucătorii puteau pune împreună PC-uri personalizate cu procesoare ceva mai lente și să investească mai mulți bani în plăci grafice de top. A sunat foarte convenabil și pentru AMD, deoarece compania nu a avut de ani de zile un procesor competitiv high-end, deși încă are produse GPU bune.

În timp ce fanboys AMD plângători s-au adunat pentru a plânge moartea salvatorului lor, Mantle a înviat în mod miraculos. Vestea bună a venit sub forma unei postări pe blog, scrisă de VP AMD pentru calcul vizual și perceptiv, Raja Koduri. Întâmplător, în concordanță cu tema religioasă, Koduri a ținut o predică pe o montură, în timpul evenimentului de lansare a AMD din Hawaii, în 2013, dar mă opresc.

Glume la o parte, echipa lui Koduri a făcut o treabă bună. Deși Mantle nu a devenit un nou standard industrial, a devenit o bază pentru Vulkan. Cea mai mare diferență este că Vulkan nu va fi limitat la hardware-ul AMD GCN; va funcționa pe mai multe GPU-uri de la diferiți furnizori. Probabil puteți vedea unde merg cu asta; este puțin mai bine să aveți o singură interfață grafică low-overhead care să funcționeze pe diferite sisteme de operare și platforme hardware decât să aveți API-uri proprietare pentru diferite arhitecturi GPU, sisteme de operare și așa mai departe.

Vulkan API pur și simplu ia o bună parte din plăcinta Mantle și o partajează cu toată lumea, indiferent de sistemul de operare, hardware, rasă sau religie.

Ah, și mai este un lucru: Mantle a forțat în cele din urmă Microsoft și Khronos să facă ceva în legătură cu balonarea și ineficiența DirectX și OpenGL. A fost o lovitură blândă și prietenoasă în spate, sau „badonkadonk”, așa cum îi place să spună unui coleg Toptaler.

Cum se compară Vulkan cu OpenGL?

Evident, trebuie să subliniez diferențele de bază dintre Vulkan și OpenGL. Khronos a venit cu o ilustrație simplă, care arată cât de multă umflare a driverului ar putea fi eliminată cu noul API.

Vulkan permite aplicațiilor să se apropie de metal, eliminând astfel nevoia de multă memorie și de gestionare a erorilor, precum și multă sursă de limbaj de umbrire. Șoferii vor fi mai ușori, mai slabi și mai răutăcioși. Vulkan se va baza doar pe limbajul intermediar SPIR-V și, deoarece are un API unificat pentru piețele mobile, desktop și console, ar trebui, de asemenea, să beneficieze de o îngrijire mai delicată și iubitoare din partea dezvoltatorilor.

Dar stai, nu descarcă acest lucru pur și simplu mai multă muncă dezvoltatorilor de jocuri? Sigur, vor putea folosi hardware-ul mai eficient, dar cum rămâne cu propriile ore de lucru? Aici intră în luptă abordarea ecosistemică stratificată.

Dezvoltatorii vor putea alege trei niveluri diferite, sau niveluri, ale ecosistemului Vulkan.

• Utilizați Vulkan direct pentru flexibilitate și control maxim.
• Utilizați biblioteci și straturi Vulkan pentru a accelera dezvoltarea.
• Utilizați Vulkan prin intermediul motoarelor de joc de la raft, complet optimizate prin noul API.

Prima opțiune în mod clar nu va fi pentru toată lumea, dar bănuiesc că ar fi un software bun de analiză comparativă. Khronos se așteaptă ca a doua opțiune să fie o „zonă bogată pentru inovare”, deoarece multe utilități și straturi vor fi în sursă deschisă și vor ușura tranziția de la OpenGL. Dacă un editor are unele titluri OpenGL care au nevoie de ajustare și actualizare, acesta este ceea ce ar folosi.

Ultima opțiune este, poate, cea mai tentantă, deoarece ridicarea grele a fost făcută de grele din industrie precum Unity, Oxide, Blizzard, Epic, EA, Valve și altele.

Iată un tabel rapid OpenGL vs. Vulkan:

Sincer să fiu, nu cred că este nici măcar corect să le compar pe cele două. Vulkan este un derivat Mantle, în timp ce OpenGL este un mastodont cu un bagaj de 20 de ani. Vulkan ar trebui să renunțe la o mulțime de lucruri moștenite; asta e toată ideea. Vulkan ar trebui să simplifice testarea și implementarea, să facă driverele mai slabe și să îmbunătățească portabilitatea programului shader prin limbajul intermediar SPIR-V.

Acest lucru ne duce la următoarea întrebare. Ce înseamnă Vulkan cu adevărat pentru dezvoltatori?

Se așteaptă ca SPIR-V să transforme ecosistemul limbajului

Deci, unde intervine SPIR-V și ce se întâmplă cu vechiul GLSL?

GSLS va rămâne în viață deocamdată și va fi primul limbaj de umbrire acceptat de Vulkan. Un traducător GLSL în SPIR-V va face treaba grea și voila!, veți pregăti SPIR-V pentru a alimenta timpul de rulare înfometat de Vulkan. Dezvoltatorii de jocuri vor putea folosi back-end-urile SPIR-V și Vulkan, bazându-se probabil pe front-end-uri de compilare cu sursă deschisă. În plus față de GLSL, Vulkan poate suporta kernel-urile OpenCL C, în timp ce se lucrează la adăugarea suportului pentru C++. Limbajele, cadrele și instrumentele viitoare specifice domeniului sunt o altă opțiune. Khronos menționează chiar și posibilitatea dezvoltării unor noi limbaje experimentale.

Indiferent ce aleg dezvoltatorii să facă, toate drumurile duc la Vulkan, prin SPIR-V, și apoi la o multitudine de dispozitive diferite.

SPIR-V ar trebui să îmbunătățească portabilitatea în trei moduri:

• Instrumente comune
• Un singur set de instrumente pentru un singur ISV
• Simplitate

Deoarece nu va fi nevoie ca fiecare platformă hardware să prezinte un traducător de limbi de nivel înalt, dezvoltatorii se vor ocupa de mai puține dintre ele.

Un ISV individual poate genera SPIR-V folosind un singur set de instrumente, eliminând astfel problemele de portabilitate ale limbajului de nivel înalt.

SPIR-V este mai simplu decât un limbaj tipic de nivel înalt, facilitând implementarea și procesarea.

Performanța va fi îmbunătățită în mai multe moduri, în funcție de modul în care este implementat Vulkan:

• Gata cu front-end-ul compilatorului, multe procesări pot fi făcute offline
• Permisele de optimizare se pot rezolva mai rapid, optimizările executate offline
• Mai multe surse de nuanță se reduc la același flux de instrucțiuni de limbă intermediară

Khronos nu specifică niciun număr de performanță și notează că „kilometrajul va varia cu siguranță”. Totul va depinde de modul în care este utilizat Vulkan. Dacă doriți să verificați detaliile grele, asigurați-vă că consultați hârtia albă SPIR-V.

Vulkan arată promițător din perspectiva dezvoltatorului

Am subliniat o serie de caracteristici care ar trebui să facă Vulkan și SPIR-V populare în comunitatea dezvoltatorilor, iar Khronos este dornic să transmită și acest punct. Perspectiva de a folosi aceleași instrumente și abilități pentru a dezvolta pentru mai multe platforme pare intrigantă, mai ales acum că decalajul de performanță dintre diferitele platforme se reduce.

Desigur, dezvoltarea unui joc AAA cu buget mare pentru PC-uri va rămâne un proces extrem de complex și consumator de timp, care implică o grămadă de bani și resurse umane, dar platformele mobile și GPU-urile integrate utilizate în cele mai recente procesoare Intel și AMD oferă deja o mulțime de Performanță GPU pentru jucătorul ocazional. În plus, dezvoltatorii mici, independenți sau freelanceri, au șanse mai mari să lucreze la jocuri casual multiplatforme decât titlurile AAA produse de marii editori.

Khronos subliniază următoarele avantaje posibile de SPIR-V:

• Dezvoltatorii pot folosi același compilator front-end pe mai multe platforme pentru a elimina problemele de portabilitate între furnizori
• Timpul de compilare a shader-ului/kernel-ului de rulare va fi redus, deoarece driverul trebuie doar să proceseze SPIR-V
• Dezvoltatorii nu trebuie să distribuie codul sursă shader/kernel, așa că se bucură de un nivel suplimentar de protecție IP
• Driverele sunt mai simple și mai fiabile, deoarece nu este nevoie să includeți compilatoare front-end
• Dezvoltatorii au o imagine mai bună a alocării memoriei și își pot modifica abordarea de alocare a memoriei în consecință

Sunt sigur că veți fi de acord că asta sună bine, dar mai este un drum lung de parcurs.

Vulkan: Funcționează, dar este o lucrare în curs

După cum am spus, Vulkan este încă o lucrare în curs de desfășurare și ar trebui să avem specificațiile complete până la sfârșitul anului. Cu toate acestea, din ceea ce am văzut până acum, noul API poate debloca o mulțime de performanțe chiar și cu hardware-ul de generație actuală.

Cea mai bună ilustrare a lui Vulkan pe care am văzut-o până acum vine de la Imagination Technologies, una dintre cele mai importante echipamente GPU mobile de acolo. Imagination Technologies GPU IP este utilizat în toate gadgeturile iOS, împreună cu numeroase alte modele System-on-Chip bazate pe ARM și chiar în unele cipuri Intel x86 de joasă tensiune.

Săptămâna trecută, Imagination a publicat o postare pe blog care detaliază câștigurile de performanță posibile de Vulkan. Alegerea sa de hardware a fost oarecum neobișnuită: un Google Nexus Player, bazat pe un procesor Intel quad-core rar folosit cu GPU PowerVR G6430. Dispozitivul a fost testat cu cel mai recent driver API Vulkan pentru GPU-uri PowerVR, în timp ce rularea de referință a fost efectuată pe OpenGL ES 3.0. Diferența de performanță a fost deloc uluitoare.

Scena include un total de 400.000 de obiecte, cu diferite niveluri de detaliu, variind de la 13.000 la 300 de vârfuri. Imaginea largă arată aproximativ un milion de triunghiuri, unele alfa pe plante și aproximativ zece texturi diferite pentru gnomi și plante. Fiecare tip de obiect folosește un shader diferit și gnomii nu sunt instanționați, fiecare apel de desen ar putea fi un obiect complet diferit, cu materiale diferite, dar rezultatul final ar fi similar.

Totuși, există o mare avertizare: acesta nu este genul de creștere a performanței la care te poți aștepta în viața reală. Echipa Imagination Technologies a folosit un scenariu exagerat pentru a evidenția superioritatea lui Vulkan, pentru a-l împinge până la limite, iar în acest scenariu particular limita este în favoarea Vulkan vs. OpenGL ES. De asemenea, rețineți că acest test este legat de GPU , dar este încă o ilustrare bună a utilizării superioare a CPU de către Vulkan.

Cum reduce Vulkan utilizarea procesorului?

Îți amintești că tabelul OpenGL vs. Vulkan pe care l-am avut mai devreme sau, pentru a fi mai specific, acel bit de randare în mosaic? Probabil că nu, așa că aici este, pe scurt: Imagination a folosit Vulkan pentru a aduna apelurile în loturi și a reda o placă la un moment dat. În funcție de locul în care se află țigla în momentul redării cadrului, aceasta poate intra sau ieși din vedere, își poate schimba nivelul de detaliu și așa mai departe. În OpenGL ES, toate apelurile draw sunt dinamice, sunt transmise cu fiecare cadru, în funcție de ceea ce este în câmpul vizual. Apelurile Draw care au fost deja executate nu pot fi stocate în cache.

Ca rezultat, OpenGL ES are nevoie de multe apeluri în modul kernel pentru a schimba starea driverului și a-l valida. Vulkan nu o face pentru că se bazează pe comenzi pregenerate (buffer-uri de comandă) pentru a reduce supraîncărcarea CPU și pentru a elimina necesitatea de a valida sau de a compila în timpul buclei de randare. Echipa Imagination a descris capacitatea de a reutiliza buffer-urile de comandă ca fiind „utilă în anumite circumstanțe” și posibil de utilizat „în mare măsură” în multe jocuri și aplicații.

Al doilea schimbător de joc este generarea paralelă a buffer- ului, care îi permite lui Vulkan să valorifice puterea tuturor nucleelor ​​CPU. OpenGL ES a fost proiectat înainte de apariția cipurilor mobile multi-core, dar în ultimii trei ani, industria a trecut de la două, la patru, la opt și zece nuclee CPU, cu SoC-urile Apple seria A și Nvidia Tegra din Denver. jetoane ca singure excepții notabile. Am vorbit despre tendințele SoC mobile într-una dintre articolele mele anterioare de blog, care acoperă viitorul compilator Optimizing Android, astfel încât să îl puteți verifica pentru informații suplimentare.

Să încercăm o analogie: dacă Vulkan ar fi un motor cu ardere internă, ar stoca și reutiliza o parte din puterea sa, în același mod în care ar face un turbocompresor și un intercooler (tampoane de comandă), și ar putea folosi patru, șase, opt sau chiar zece cilindri fără pierderi de eficiență (generare paralelă a tamponului). Compararea Vulkan cu OpenGL ES sună un pic ca a compara un motor turbo nou, redus cu un motor vechi, cu un singur cilindru pe Triumph Trophy al bunicului tău.

Ei bine, cel puțin bunicul era un rocker cu adevărat, nu un mod.

Rezultatul final este un mediu mult mai eficient, capabil să folosească întregul hardware disponibil, spre deosebire de OpenGL ES, care este legat de procesor în majoritatea scenariilor. Acest lucru înseamnă că Vulkan poate oferi niveluri similare de performanță, menținând CPU-ul la un ceas mai scăzut, reducând astfel consumul de energie și accelerarea.

Potențiale dezavantaje ale API-ului Vulkan (alertă spoiler: nu sunt atât de multe)

Eu nu strâng mintea; Consider că este, de asemenea, important să enumerați avantajele și dezavantajele Vulkan API. Din fericire, nu există atât de multe contra, în afară de câteva minore și, potențial, una sau două mari. Dacă crezi că Vulkan este cel mai bun lucru de la feliile de pâine și ești dornic să-l încerci în următorul tău proiect, poate vrei să iei în considerare câteva dintre aceste puncte:

• A adăugat complexitatea codului în anumite scenarii
• Timpul pentru cumparaturi
• Nivelul de sprijin al industriei
• Vulkan poate să nu fie la fel de relevant sau eficient pe unele platforme (desktop-uri)
• Convingerea dezvoltatorilor să folosească Vulkan pe unele platforme
• Compatibilitate limitată cu hardware-ul moștenit

Dacă un dezvoltator dorește să implementeze unele dintre caracteristicile clare prezentate în această postare, va implica o cantitate suficientă de muncă. Fiecare va trebui implementat în cod, dar vestea bună este că liderii din industrie vor face procesul mai ușor cu noile actualizări ale driverelor.

Time-to-market este o altă preocupare, la fel ca și implementarea Vulkan în aplicații și jocuri mai vechi. Vulkan este încă o previzualizare tehnică; specificațiile și implementările inițiale sunt așteptate până la sfârșitul anului 2015, așa că, în mod realist, probabil că nu vom vedea multe aplicații din lumea reală înainte de jumătatea anului 2016.

Sprijinul industriei nu ar trebui să fie o problemă; La urma urmei, acesta este un standard Khronos, dar poate dura ceva timp. Acesta este unul dintre motivele pentru care am concentrat această postare pe segmentul mobil; Software-ul și hardware-ul mobil evoluează mai repede și ar putea dura câteva sferturi înainte ca Vulkan să aibă un impact asupra platformelor desktop. Așa funcționează industria, există mult mai multe lucruri de care să vă faceți griji în nișa desktopului: suport pentru aplicații profesionale, hoardele de jucători care mânuiesc furculița care se învârtesc peste fiecare cadru rupt și așa mai departe. Cu toate acestea, faptul că Vulkan este derivat din Mantle lui AMD este încurajator.

În timp ce Vulkan poate face minuni într-o setare legată de CPU, în special cu SoC-uri mobile multi-core, aceste câștiguri de performanță vor fi limitate pe platformele desktop. Desktop-urile gestionează procesoare cu mai multe nuclee cu un nivel mai mare de eficiență, iar cele mai solicitante aplicații grafice sunt legate de GPU.

Până când toate piesele puzzle-ului vor ajunge la locul lor, unii dezvoltatori pot fi reticenți să facă pasul și să se încurce cu Vulkan. Mulți oameni pur și simplu nu au timp să experimenteze și învață noi abilități doar atunci când este absolut necesar. Arderea multor bani și pierderea de ore de muncă pentru a modifica jocurile existente pentru mobil pentru a utiliza Vulkan în această etapă incipientă nu va fi o opțiune pentru mulți dezvoltatori și editori.

Compatibilitatea cu hardware-ul mai vechi ar putea fi o altă sursă de îngrijorare. Vulkan va avea nevoie de hardware OpenGL ES 3.1 sau OpenGL 4.1, însoțit de noi drivere. De exemplu, GPU-urile PowerVR seria 6 de la Imagination Technologies îl pot accepta, dar seria 5 nu. Seria Adreno 400 de la Qualcomm acceptă OpenGL ES 3.1, dar seria 300 nu. Seriile Mali T600 și T700 de la ARM acceptă OpenGL ES 3.1, dar suportul lipsește pentru modelele mai vechi din seria T400. Din fericire, până când Vulkan devine relevant, majoritatea dispozitivelor cu GPU-uri neacceptate vor ieși din imagine. Acestea includ iPhone 5/5C, iPad de a patra generație și dispozitive Samsung bazate pe anumite cipuri Exynos din seria 5000. Dispozitivele bazate pe Qualcomm s-ar putea să nu fie la fel de norocoase, deoarece GPU-urile din seria Adreno 300 sunt folosite pe modele relativ recente și prolifique, cum ar fi Snapdragon 410, Snapdragon 600, Snapdragon 800 și 801. Cu toate acestea, bănuiesc că majoritatea dintre ele vor dispărea cu timpul Vulkan devine cu adevărat relevant.

Trăiește mult și redă

Este încă prea devreme să spunem dacă Vulkan va schimba sau nu jocul, dar cred că veți fi de acord că are o mulțime de potențial. Cred că va fi o mare problemă și mă bazez pe această presupunere pe un deceniu de experiență în industria GPU-urilor. Va dura, totuși, timp și bănuiesc că Vulkan își va face simțită prezența pe mobil înainte de a începe să schimbe peisajul desktopului.

Aproximativ în același timp, drivere, motoare de joc și jocuri optimizate pentru Vulkan, vom obține hardware nou cu care să ne jucăm și nu mă refer doar la modificări minore ale hardware-ului. Dezvoltarea SoC mobile s-a blocat din mai multe motive pe care nu le voi aborda acum, dar 2016 va fi un an mare pentru industrie, deoarece nodurile FinFET 14/16nm devin disponibile pentru mai mulți producători și devin viabile din punct de vedere economic pentru hardware-ul mainstream, mai degrabă decât chips-uri emblematice.

Dezvoltatorii vor avea hardware mult mai puternic și mai eficient cu care să se joace, iar o nouă interfață grafică low-overhead va fi cireașa de pe tort. Sper din tot sufletul că furnizorii de hardware nu vor mai folosi rezoluția afișajului ca un truc de marketing, deoarece rezoluțiile inutil de înalte nu fac nimic pentru calitatea vizuală, dar totuși irosesc energie. Din păcate, deoarece consumatorul mediu nu înțelege acest lucru și dorește să vadă numere mai mari pe cutie, bănuiesc că acest lucru nu se va întâmpla prea curând. Intenționez să examinez această problemă ciudată într-una dintre postările mele viitoare, așa că, dacă sunteți enervat de ea, rămâneți pe fază și nu ezitați să vă dezvăluiți în secțiunea de comentarii.