Kaasaegsed graafika API-d. Apple Metal API: mis on konks

WWDC 2014 raames ootas meid kõiki üllatus: väljakuulutamine uuest 3D-graafika API-st nimega Metal. Kuid seekord ei ole meil tegemist uue kõrgetasemelise API-ga OpenGL ES-i peal (nagu Scene Kit'i puhul), vaid uue madala taseme API-ga renderdamiseks ja andmetöötluseks, mis võib asendada OpenGL-i. mängudes. Apple'i sõnul võib Metal olla kuni 10 korda kiirem kui OpenGL ES (täpsemalt võib see genereerida loosikutseid [ helistada; GPU andmeedastus] 10 korda kiirem) ja on saadaval ainult iOS-i seadmetes, millel on uusima põlvkonna A7 protsessor.

See teade kutsus esile uue arutelulaine ja arutelu vajaduse üle uute graafika API-de järele, mis peaksid (või ei peaks – kes teab) OpenGL-i asendama. See postitus ei kavatse selles arutelus osaleda – selle eesmärk on selgitada, mille poolest Metal erineb OpenGL ES-ist, mille asendaja see on. Et mõista, mis on Metal API-s nii erilist (või vastupidi, ei midagi erilist), peame vaatama veidi graafika API ja GPU "kapoti" alla.

Kuidas GPU-d ja graafika API-d töötavad
Naiivne lugeja võib eeldada, et API-le otse helistamine teeb midagi GPU-s või võimaldab GPU-s midagi juhtuda. Veelgi naiivsem lugeja eeldab, et GPU on selle kõne töötlemise lõpetanud, kui API tagastab tulemuse. Mõlemad väited on tegelikkusest kaugel. Kui draiver täitis renderduskäsud samal hetkel, kui need loodi, ja ootas renderdamisprotsessi lõppu enne tulemuse tagastamist API-kutsele, siis ei saa ei protsessor ega GPU tõhusalt töötada, kuna üks protsessoritest oleks alati blokeeritud huvides teisele.

GPU jõudluse lihtsaks parandamiseks tuleks seda protsessi käitada asünkroonselt; siis GPU ei blokeeri CPU-d ja API kõned tagastavad tulemuse peaaegu kohe. Sel juhul ei pruugi GPU olla 100% ära kasutatud, kuna see võib oodata, kuni protsessor teeb uued renderduskutsed (= kaadri algus), samal ajal kui teised käsud ootavad eelmiste lõpetamist. See on põhjus, miks enamik graafikadraivereid kogub kõike helistada(ja muud toimingud, mida tuleb GPU-l täita – näiteks olekute muutmine), et renderdada kogu kaader enne selle GPU-le saatmist. Need puhverdatud käsud saadetakse seejärel tagasi pärast järgmise kaadri joonistamise käsu saamist, tagades GPU võimalikult tõhusa kasutamise. Loomulikult lisab see ühe kaadri viivituse: samal ajal, kui protsessor loob praeguse kaadri jaoks ülesande, renderdatakse eelmine kaader GPU-s. Tegelikult on võimalik puhverdada rohkem kui ühte kaadrit ja seeläbi saavutada suurem kaadrisagedus – veelgi suurema latentsusaja arvelt.

Teine viga meie naiivses oletuses on see, et me eeldame, mida olekumuutuskutsed teevad.

Seega oleme õppinud vähemalt kahte olulist asja selle kohta, mis toimub OpenGL-i ja kaasaegsete GPU-dega koostöö tagaplaanil: olekute muutmine võib olla keeruline, kui on vaja uut olekukombinatsiooni ja kõik GPU toimingud viibivad teatud aja võrra.

Rakenduses genereeritakse ja saadetakse GPU-le korraga üks voog tegelikke käske ühe kaadri jaoks, mida GPU-s täidetakse (tegelikult on see veidi keerulisem, aga ärgem süvenegem veel).

Kaasaegse arvutigraafika konveieri toimimise kohta saate rohkem lugeda Fabian Giesensi artiklite sarjast "Reis mööda graafikatoru".

Miks võib erineval programmeerimismudelil olla eeliseid?
Nagu juba nägite, on programmeerija eest peidetud tohutul hulgal keerukusi ja nutikaid nippe (neid on ilmselt isegi rohkem, kui mainisin), mis varjavad otseselt toimuvat. Mõned neist teevad lihtsa arendaja elu lihtsamaks, teised panevad otsima võimalusi draiveri üle kavaldamiseks või API-kutsete kõrvalmõjude poole "kaevamiseks".

Mõned graafika API-d püüavad tänapäeval enamikku neist nippidest eemaldada, paljastades nendes peituva "põimumise" – ja mõnel juhul jättes kõigi sellega seotud probleemide lahendamise programmi enda hooleks. PS3 graafika API läks selles suunas, sinna läheb AMD oma Mantle’iga, sinna lähevad ka tulemas DirectX 12 ja Apple Metal.

Mis on muutunud?
Käsupuhvrid on nüüd avatud ja rakendus peab need puhvrid täitma ja käsujärjekorda saatma, mis käivitab need puhvrid GPI-s määratud järjekorras – nii on rakendusel täielik kontroll GPU-le saadetava töö üle ja määrata, kui palju viivituskaadreid lisada (lisades latentsust, aga ka suurendades GPU kasutust). GPU puhverduskäskude ja nende asünkroonse saatmise järgmisse kaadrisse peab rakendus ise rakendama.

Kuna saab selgeks, et neid puhvreid ei käivitata kohe (st loomise ajal) ja et teatud järjekorras saab luua ja käitamisjärjekorda lisada mitu puhvrit, võib rakendus lubada nende ehitamist mitmele niidid paralleelselt. Samuti muutub programmeerijale selgemaks, millised arvutustulemused on juba olemas ja millised mitte.

Olekumuudatused on nüüd jaotatud olekuobjektideks, mida saab lihtsalt ümber lülitada, samas kui nende objektide loomine läheb kallimaks. Näiteks MTLRenderPipelineState sisaldab varjutajaid ja kõiki olekuid, mis on rakendatud nende paikamise teel.

Veel üks uue API eelis on see, et see ei pea kandma eelmiste versioonidega ühilduvuse koormust ega ole seetõttu nii konservatiivne.

A7 jaoks on teritamises nüanss - tänu sellele on Metall teritatud töötama ühismäluga süsteemides, st. CPU ja GPU pääsevad otse juurde samadele andmetele, ilma et peaksid neid PCI siini kaudu edastama. Metall annab programmile otsese ligipääsu protsessori puhvritele ja programmeerija kohustus on tagada, et GPU ei kasutaks neid andmeid samaaegselt. See kasulik funktsioon võimaldab teil segada GPU ja CPU arvutuste korrutist.

Ja kuidas see 10 korda kiirem on?
Iga loosikõne maksab natuke aega CPU-l ja mõnda aega GPU-l. Metal API vähendab CPU aega, lihtsustades oleku jälgimist ja vähendades sellega draiveri veakontrollide arvu kehtivate olekukombinatsioonide jaoks. Samuti aitab olekute eelarvutamine: te ei saa mitte ainult ehitamise ajal vigu kontrollida, vaid oleku muutmine ise nõuab vähem API-kutseid. Võimalus luua paralleelselt käsupuhvreid suurendab veelgi joonistamiskutsete arvu, kui rakendus on CPU-ga seotud.

Teisest küljest ei muutu GPU renderdamine kiiremaks, rakendus, mis teeb suurte võrgusilmade jaoks väga vähe joonistuskutseid ( võrk- objekti tippudest koosnev osa mudelist] ei saa metallile üleminekust kasu.

Kas sama saab teha ka OpenGL-is?
GDC 14-l oli Cass Everitti, John McDonaldi, Graham Sellersi ja Tim Foley suurepärane ettekanne teemal "Lähenemas nullijuhi ülekulu". Selle põhiidee oli vähendada draiveri tööd OpenGL-is, suurendades joonistuskutsete abil tehtavat tööd ning kasutades uusi GL-objekte ja vähem GL-kutseid tõhususe parandamiseks.

See ja teised ideed nõuavad OpenGL-i edasist laiendamist ja selle API uusi versioone, kuid suure osa sellest saab teisaldada OpenGL ES-i. Me kaotame võimaluse käsupuhvreid otse juhtida koos kõigi selle plusside ja miinustega.

Kui suur on tõenäosus seda tulevikus näha? Tagasiühilduvuse toe tõttu võib loota vaid funktsioonide komplektile, mida saab nimetada "kaasaegseks kerneliks", kuid suure tõenäosusega tuleb see teha ühilduvaks kõigega kuni algse glBegin () funktsioonini. See piirang kestab kogu OpenGL-i potentsiaalse tuleviku ja on selle arengu piiriks, muutes alternatiivid, nagu Metal API, üha eelistatumaks ...

Sildid:

  • Metallist API
  • Apple
  • opengl
Lisa märksõnu

API määratleb funktsionaalsuse, mida programm (moodul, teek) pakub, samas kui API võimaldab teil teha abstraktsiooni sellest, kuidas seda funktsiooni täpselt rakendatakse.

Kui programmi (moodulit, teeki) käsitleda musta kastina, siis API on selle kasti kasutajale kättesaadavate "käepidemete" komplekt, mida ta saab keerata ja tõmmata.

Tarkvarakomponendid suhtlevad üksteisega API-de kaudu. Sel juhul moodustavad komponendid tavaliselt hierarhia - kõrgetasemelised komponendid kasutavad madala taseme komponentide API-d ja need omakorda veelgi madalama taseme komponentide API-d.

Selle põhimõtte kohaselt protokollid andmete edastamiseks üle . Standardne Interneti-protokoll (OSI võrgumudel) sisaldab 7 kihti (bitipakettide edastamise füüsilisest kihist kuni rakendusprotokollide kihini, nagu HTTP ja IMAP). Iga kiht kasutab ära eelmise andmekihi funktsionaalsust ja annab omakorda soovitud funktsionaalsuse järgmisele kihile.

Oluline on märkida, et protokolli mõiste on oma tähenduselt lähedane API mõistele. Mõlemad on funktsionaalsuse abstraktsioonid, ainult esimesel juhul räägime andmeedastusest ja teisel - arvutirakenduste ehitamisest.

Funktsiooni ja klassiteegi API sisaldab kirjeldust allkirjad Ja funktsiooni semantika.

Rakenduse programmeerimisliides (API) on tarkvaraliides süsteemide vaheliseks suhtlemiseks, mis võimaldab teil:

  • Hankige juurdepääs ettevõtte äriteenustele
  • Teabe vahetamine süsteemide ja rakenduste vahel
  • Lihtsustage ettevõtete, partnerite, arendajate ja klientide vahelist suhtlust

Avatud API strateegia

API strateegia sisaldab:

  • Olemasolevatel API-del põhinevate äritoodete arendamine
  • Siseteenuste pakkumine arendajatele
  • API monetiseerimismudelid mitme kanaliga suhtluse loomiseks ja kasumi suurendamiseks

Avatud API kontseptsiooni juurutamine aitab muuta äri, kinnistada selle turuosaliste paindlikku projektiökosüsteemi, luua tingimused pidevaks uute ideede genereerimiseks ja lisaväärtuse loomiseks ettevõtte andmemassiivide haldamisel.

Integratsioonilahenduste turg areneb seoses API-de arenguga – alates EDI-st ja SOAP-ist kuni Web 2.0-ni, millega sai alguse avalike API-de ajastu. Selliste liideste arv võib järgmise 3 aasta jooksul kasvada enam kui 50 korda ja ulatuda 1 miljonini. See on tingitud mitmest kanalist: klientidega suhtlemise kanalid peavad muutuma koos nendega. Tarbijate arvu ja andmemahu pidev kasv on viinud API majanduse tekkeni, mis aitab luua uudseid avatud liidestel põhinevaid ärimudeleid ettevõtte varade ja teenuste kasutamiseks.

Funktsiooni allkiri

Funktsiooni allkiri- funktsiooni ülddeklaratsiooni osa, mis võimaldab tõlkevahenditel funktsiooni muu hulgas tuvastada. Erinevatel programmeerimiskeeltel on funktsiooni signatuurist erinev arusaam, mis on samuti tihedalt seotud funktsioonide ülekoormamise võimalustega nendes keeltes.

Mõnikord nad eristavad kõne allkiri Ja rakendamise allkiri funktsioonid. Väljakutse allkiri koostatakse tavaliselt vastavalt funktsioonikutse süntaktilisele konstruktsioonile, võttes arvesse selle funktsiooni ulatuse signatuuri, funktsiooni nime, kõne tegelike argumentide tüüpide jada ja funktsiooni tüüpi. tulemus. Rakendussignatuur hõlmab tavaliselt mõnda funktsiooni deklaratsiooni süntaktilisest konstruktsioonist pärit elementi: funktsiooni ulatuse spetsifikaatorit, selle nime ja formaalsete argumenditüüpide jada.

Näiteks C++ programmeerimiskeeles identifitseerib kompilaator lihtsa funktsiooni üheselt selle nime ja argumentitüüpide järjestuse järgi, mis moodustab selles keeles funktsiooni allkirja. Kui funktsioon on mõne klassi meetod, siis osaleb signatuuris ka klassi nimi.

Samuti tuleb märkida, et sageli on programmeerija käsutuses mitu erinevat API-d sama tulemuse saavutamiseks. Sel juhul rakendatakse iga API tavaliselt madalama abstraktsioonitasemega tarkvarakomponentide API-de abil.

Näiteks: selleks, et näha rida "Tere, maailm!" kõik, mida pead tegema, on luua HTML-dokument minimaalse pealkirja ja lihtsa kehaosaga, mis sisaldab antud stringi. Mis juhtub, kui brauser selle dokumendi avab? Brauseri programm edastab failinime (või juba avatud faili deskriptori) HTML-dokumente töötlevale teegile, mis omakorda loeb operatsioonisüsteemi API abil seda faili ja mõistab selle seadet ning kutsub esile operatsioone nagu "clear". aken”, “kirjuta valitud kirjatüübiga Tere, maailm!”, nende toimingute ajal pöördub graafiline primitiivne teek vastavate päringutega aknaliidese teegi poole, see teek pöördub juba operatsioonisüsteemi API poole selliste päringutega nagu “ pange mind videokaardi puhvrisse.

Samal ajal on tegelikult peaaegu igal tasemel mitu võimalikku alternatiivset API-d. Näiteks: me võiksime kirjutada lähtedokumendi mitte HTML-is, vaid LaTeX-is, kuvamiseks võiksime kasutada mis tahes brauserit. Erinevad brauserid kasutavad üldiselt erinevaid HTML-teeke ja pealegi saab selle (üldiselt) ehitada erinevate primitiivsete teekide abil ja erinevatel operatsioonisüsteemidel.

Olemasolevate kihiliste API süsteemide peamised keerukused on järgmised:

  • Raskused programmikoodi teisaldamisel ühest API-süsteemist teise (näiteks OS-i vahetamisel);
  • Funktsionaalsuse kaotus madalamalt tasemelt kõrgemale liikudes. Jämedalt öeldes on API iga "kiht" loodud selleks, et hõlbustada mõne standardsete toimingute komplekti rakendamist. Kuid samal ajal muutub tõesti keeruliseks või põhimõtteliselt võimatuks teha mõningaid muid toiminguid, mida madalam API tase pakub.

Põhilised API tüübid

Sisemised API-d

  • API juurdepääs on piiratud sisemiste arendajatega
  • Taotlused on suunatud ettevõtte töötajatele

Ettevõtte juhid:

  • Arengu järjepidevus
  • Kulude vähendamine
  • Arendustõhususe parandamine

Partner API-d

  • API-d on saadaval ainult piiratud hulgale äripartneritele
  • Rakendused, mis on mõeldud lõpptarbijatele ja ärikasutajatele

Ettevõtte juhid:

  • Arendusprotsessi automatiseerimine
  • Partnerlussuhete arendamine
  • Partneritega suhtlemise protsessi optimeerimine

Avalikud API-d

Juurdepääs antakse igale välisele arendajale Rakendused on suunatud lõppkasutajatele

Ettevõtte juhid:

  • Uute teenuste arendamine
  • Ökosüsteemi areng
  • Mitme kanaliga suhtlemine

Kõige kuulsamad API-d

Operatsioonisüsteemi API-d

GUI API-d

  • Direct3D (DirectX-i osa)
  • DirectDraw (DirectX-i osa)

on tihendatud suurema tihendusastmega kui pildid, millel on vähe selliseid elemente (nt graafika, diagrammid, lihtsad tekstuurid). Kõrge eraldusvõimega pilte saab tihendada kõrge tihendusastmega, ilma et see mõjutaks nende kvaliteeti. Madala eraldusvõimega piltide kõrge kvaliteedi säilitamiseks peab tekkiv tihendusaste olema palju väiksem. Suure värvisügavusega pilte (nt 24-bitised Truecolori pildid) tihendatakse tõhusamalt kui pilte, millel on vähem bitte piksli kohta (nt 8-bitised halltoonid).

Enamik teisi kadudeta pakkimismeetodeid on olemuselt sümmeetrilised. See tähendab, et need põhinevad teatud toimingute jada kasutamisel, mis tehakse lahtipakkimisel vastupidises järjekorras. Andmete tihendamiseks ja lahtipakkimiseks kulub ligikaudu sama kaua. Fraktaalne kokkusurumine on asümmeetriline protsess, tihendamine võtab palju kauem aega kui dekompressioon. Sellest järeldub, et fraktaali tihendatud andmed on kasulikud juhtudel, kui pildifailid on sageli lahti pakkinud, kuid mitte kunagi tihendatud, näiteks kui kujutised salvestatakse kujutiste andmebaasidesse CD-ROM-il.

Mõningaid levinumaid vorme käsitletakse lühidalt allpool.

Kaasaegsed graafika API-d

Kaasaegsete keeruliste graafikaprogrammide, eriti 3D-rakenduste arendamine on API-de kasutamisega lahutamatult seotud.

(Rakenduste programmeerimisliides).

API on teekide komplekt, mis kujutab endast valmis liidest, mis võimaldab programmil töötada 3D-kiirenditega. Praegu on sellised sisse-

Liideseid on palju, kuid need kõik võib jagada kahte klassi: universaalsed ja spetsiaalsed.

Universaalsed API-d on ühised kõigile 3D-kiirenditele ja nende API-de riistvarakiirenduse tugi on kiirendite endi käes. Esiteks tuleks siin esile tõsta Microsoft DirectX ja OpenGL. Neid mõlemaid kasutatakse peamiselt arvutianimatsiooniprogrammides.

Spetsiaalsed API-d on loodud töötama teatud 3D-kiibistikule ehitatud graafikakiirenditega; kuulsaimad neist on Glide API - liides VooDoo® kiipidega töötamiseks; Metal - Savage3D kiipidele jne. Spetsiaalsete API-de abil kirjutatud programmid töötavad ainult nendes kiirendites, mille jaoks need API-d on loodud. Enamik spetsialiseeritud API-sid pakuvad ainult madalatasemelist programmeerimisliidest, kuid viimasel ajal sisaldavad DirectX-i uued versioonid kõrgetasemelisi tugiliideseid, nagu DirectX for VisualBasic, mis pakub keeletuge Visual Basicu visuaalses programmeerimiskeskkonnas kirjutatud multimeediumirakendustele. .

Microsoft DirectX API

Microsoft DirectX API on programmeerimisliideste komplekt, mida kasutatakse mitmesuguste probleemide lahendamiseks alates arvuti riistvara programmilisest juhtimisest kuni erinevat tüüpi teavet kasutavate multimeediumirakenduste arendamise ja virtuaalmaailmade loomiseni.

Peamine eesmärk, mida Microsoft püüdles DirectX-liidese loomisel, oli muuta Windowsi operatsioonisüsteemiga arvutid universaalseks platvormiks rakendustele, mis on rikkad multimeediumielementidega: täisvärvigraafika, videoklipid,

tami, 3D animatsioon ja stereoheli. Otse Windowsi tuuma sisse ehitatud DirectX-liides on integreeritud teenus

Windows 98 ja Windows 2000, samuti Microsoft Internet Explorer. Komponendid

DirectX-i saab automaatselt arvutisse alla laadida ka siis, kui installite Windows 95 jaoks välja töötatud kaasaegseid mänge ja multimeediumirakendusi. Arendajatele pakub DirectX programmeerimisliideste komplekti, mille kasutamine võimaldab lahendada kaks peamist ülesannet.

Esiteks muudab DirectX sellega arendatud rakendused programmideks, mis ühilduvad mis tahes Windowsi versiooniga ja töötavad igas seda operatsioonisüsteemi kasutavas arvutis, olenemata kasutatava tarkvara tüübist. Samas kasutavad sellised rakendused arvuti tehnilisi võimalusi maksimaalselt ära, pakkudes suurimat jõudlust. See saavutatakse teenuse kaudu, mida pakuvad kaks DirectX-i peamist komponenti: madala taseme liidesed, mis moodustavad DirectX Foundationi, ja kõrgetasemelised liidesed, mis moodustavad DirectX Media.

Teiseks annab DirectX arendajatele võimaluse teatud tüüpi kuvaadapterist, helikaardist või 3D-kiirendist eemalduda ja keskenduda programmi enda loogikale.

DirectX Foundation pakub arendajatele madala taseme programmeerimisliideste komplekti, mis tagab tõhusa juurdepääsu kõikidele OS Windowsiga arvuti funktsioonidele, mis on realiseeritud riistvara tasemel - 3D kiirendid, helikaardid, sisendseadmed. Enne DirectX-i tulekut pidid Windowsi platvormile multimeediumirakendusi loonud arendajad kohandama oma programme erinevat tüüpi seadmete ja konfiguratsioonidega töötamiseks. See probleem on nüüd lahendatud. DirectX Foundation sisaldab komponenti, mida tuntakse kui "Hardware Abstraction Layer" (HAL), mis kasutab tarkvara

draiverid, et tagada tarkvara ja riistvara koostoime. Selle tulemusel saavad arendajad DirectX-liideste abil luua rakendusest ühe versiooni, ilma et peaks muretsema, et see töötab kindlates riistvarakonfiguratsioonides. DirectX tuvastab automaatselt arvuti tehnilised võimalused ja määrab vastavad seaded. DirectX võimaldab teil käivitada ka multimeediumirakendusi, mis nõuavad riistvaratuge, mis pole teie arvutis saadaval. Sel juhul on need tarkvara emuleeritud komponendiga, mida nimetatakse riistvara emulatsioonikihiks (HEL), mis pakub tarkvaradraivereid, mis toimivad puuduvate seadmetena.

DirectX Media asub DirectX Foundationi kohal ja pakub kõrgetasemelisi teenuseid, nagu animatsiooni tugi, voogedastusväljund (võimalus Internetist allalaaditava heli- ja videoteabe voogesitamiseks ja vaatamiseks) ning interaktiivsus. DirectX Foundationi juurutatud madala taseme teenuste ja DirectX Media juurutatud kõrgetasemeliste teenuste automaatne integreerimine hõlbustab multimeediumielementide loomist ja taasesitamist, võimaldades arendajatel lisada need oma rakendustesse ja veebilehtedele, pakkudes seega varem kättesaamatut interaktiivset multimeediumisisu. . Lisaks aitab DirectX Media lahendada erinevat tüüpi multimeediumiefektide koordineerimise probleemi, muutes nende taasesituse sünkroonimise lihtsamaks. Lisaks neile kahele Microsoft DirectX-i põhikomponendile sisaldavad need ka kõrgetasemelisi komponente, mis pakuvad veebirakenduste jaoks multimeediafunktsioone. Nende hulka kuuluvad: NetMeeting – tööriist võrgugrupi arutelude korraldamiseks ja Windows Media Player – tööriist multimeediumisisu Interneti kaudu edastamiseks. Vaatleme lühidalt peamist

DirectX Foundationi komponendid. Need sisaldavad Microsoft DirectDraw, Direct3D(vahetu ja säilitatud režiimid), DirectInput , DirectMusic , DirectSound,

DirectSound 3D ja DirectPlay. Need süsteemitaseme API-d

pakkuda tõhusat juurdepääsu erinevatele arvutiseadmetele ja tagada rakenduste tõeline riistvaraline sõltumatus, kõrvaldades draiverite installimise probleemid ning riist- ja tarkvaraplatvormide kokkusobimatuse.

Microsoft Direct3D on liides 3D-videokaartidega töötamiseks. Direct3D arhitektuur on näidatud joonisel 1.5.

win32 rakendus

Direct3D toetab kahte töörežiimi – vahetu režiim ja säilitusrežiim. Vahetu režiimis pakub Direct3D arendajatele Microsoft Windowsi keskkonnas mängu- ja multimeediumirakenduste riistvaratuge. See võimaldab teil saavutada riistvaralise sõltumatuse, toetab lülitatavat Z-puhverdamist ja protsessorite Inteli MMX-arhitektuuri. Selles režiimis realiseeritakse peamised graafilised primitiivid otse, ilma täitmispuhvreid kasutamata.

Säilitatud režiim muudab 3D-maailmade loomise ja animeerimise lihtsamaks, toetades kahte uut funktsiooni: animatsiooni interpolaatorid värvide segamisega, objektide sujuv liikumine ja palju erinevat tüüpi teisendusi, samuti 3D võrgustruktuuri järjestikust täitmist.

objektid (võrgud), võimaldades nende järkjärgulist laadimist kaugserveritest. See võimaldab arendajatel 3D-graafikat tõhusalt kasutada, vabastades nad vajadusest otseselt madalal tasemel objektistruktuuridega manipuleerida.

Tuleb märkida, et Direct3D rakendused suhtlevad graafikaseadmetega samamoodi, olenemata režiimist. Nad võivad enne HAL-ile juurdepääsu saamist kasutada tarkvara emulatsiooni, kuid mitte. Tegelikult on Direct3D tihedalt integreeritud DirectDraw komponendiga, nii et joonisel 1.2 on HAL-i riistvara abstraktsioonikiht sildiga DirectDraw/Direct3D HAL. Direct3D Z-puhverdab ja renderdab pindu ning DirectDraw tegeleb nende otsese renderdamisega. Direct3D COM-liides on DirectDrawi liides.

DirectDraw on mäluhaldushaldur, mis pakub Windowsi platvormil töötavate graafika- ja multimeediumirakenduste põhifunktsioone. Erinevalt traditsioonilisest Windowsi graafikast kasutab DirectDraw otsejuurdepääsu kuvamälule ja graafikaseadmetele, pakkudes samal ajal täielikku ühilduvust Windowsi rakendustega.

Joonis 1.6 näitab DirectDraw, GDI (Graphics Device Interface) operatsioonisüsteemi kerneli komponendi, Hardware Abstraction Layer (HAL) ja riistvara emulatsioonikihi vahelist koostoimet.

(Riistvara emulatsioonikiht, HEL). Nagu näete, eksisteerib DirectDraw iseseisvalt

mo GDI-st ja mõlemal liidesel on võimalus riistvarast sõltumatute kihtide kaudu otse graafikaseadmetele juurde pääseda. Erinevalt GDI-st ei kasuta DirectDraw ükski funktsioon riistvarafunktsioone. Kui konkreetne seade nõutavaid funktsioone ei toeta, proovib DirectDraw neid HEL-i abil emuleerida. DirectDraw toetab mitmesuguseid kuvaadaptereid, alates lihtsatest monitoridest kuni keerukate professionaalsete seadmeteni. Graafikapindade tasemel töötav DirectDraw teenindab

kõrgetasemeliste graafiliste funktsioonide ja liideste aluseks ning võimaldab kasutada kas seadmete pakutavaid riistvaralisi võimalusi või neid vajadusel emuleerida.

win32 rakendus

sioonikiht (HEL)

abstraktsioonikiht

videokaart

Joonis 1.6 – DirectDraw integreerimine süsteemi

DirectInput on liides erinevatele sisendseadmetele - klaviatuur, hiir, juhtkang, aga ka tagasisidega (force-feedback) seadmetele. Võrreldes tavaliste standardfunktsioonidega toetab see liides rohkem seadmeid ja pakub päringutele kiiremat reageerimist. Töötades otse seadme draiveritega, ei kasuta DirectInput Microsoft Windowsi sõnumsidesüsteemi.

Uued DirectInputi funktsioonid hõlmavad toetatud seadmete laiendatud loendit, sealhulgas: mängupadjad (mängupadjad), lennundus

Lennukiivrid, virtuaalreaalsuse kiivrid (virtuaalreaalsuse peakatted)

Ja tagasisideseadmed, mis pakuvad selliseid efekte nagu vibratsioon, liikumistakistus jne, mille kasutamine muudab tänapäevased mängud veelgi realistlikumaks.

DirectMusic on DirectX-tehnoloogiaperekonna uus komponent, mis on tarkvara kest muusikamallide ja kasutajatoimingutele reageerimise juhiste loomiseks. See võimaldab arendajatel luua veebilehtedel või multimeediumirakendustes määratud algoritmide alusel reaalajas taustamuusikat. DirectMusic pakub allalaaditavate helide (DLS) standardi täielikku juurutamist, võimaldades arendajatel luua muusikalisi mustreid, mis mängivad praktiliselt igal riistvaraplatvormil. DirectMusic sisaldab DirectMusic Producerit – integreeritud redaktorit, mis võimaldab töötada kõigi DirectMusic’u objektidega: stiilid, mallid, DLS-instrumendid jne.

DirectPlay on kõrgetasemeline programmeerimisliides rakendusprogrammi ja sideteenuste vahel, mis hõlbustab modemi- või LAN-suhtlust. DirectPlay sisaldab utiliite, mis võimaldavad mängijatel leida partnereid ja veebisaite, säilitada teabevoogu serverite vahel ning sama funktsioonide komplekt on toetatud iga rakenduse kasutaja jaoks, sõltumata võrguteenuse või protokollide tüübist.

IN Lisaks madala tasemega DirectX Foundationi liidestele sisaldab DirectX ka kõrgema taseme programmeerimisliideste komplekti

ja DirectX Media komponendid, mis pakuvad tuge multimeediumirakendustele, animatsioonile ja voogesitusväljundile. DirectX Media koosneb praegu järgmistest peamistest programmeerimisliidestest:

otsesaade (varem kutsuti ActiveMovieSDK); Otsene animatsioon (varem kutsuti ActiveX-animatsioon); DirectX-i teisendus. Pange tähele, et DirectX Media Services kasutab DirectX Foundation Services.

API-d (Application Programming Interface) pakuvad riist- ja tarkvaraarendajatele vahendeid draiverite ja programmide loomiseks, mis töötavad kiiremini paljudel platvormidel. Tarkvaradraiverid on loodud suhtlema vahetult API-ga, mitte operatsioonisüsteemi ja tarkvaraga.

Praegu on kaks graafika API-d – OpenGL (SGI) ja Direct 3D (Microsoft).

Kui videoadapteri tootjad toetavad OpenGL-i standardit, pakub Microsoft Direct3D-tuge keerukamale API-le nimega DirectX.

DirectX 9 ja uuemad on programmeerimisliidese uusimad versioonid, mis laiendasid kolmemõõtmelise graafika tuge ja pakkusid paremaid mängukogemusi. DirectX-i kohta lisateabe saamiseks või selle uusima versiooni allalaadimiseks külastage Microsoft DirectX-i veebisaiti: www.microsoft.com/directx.

Crossfire ehk sli

Vastuseks vana-uue SLI-tehnoloogia (MK nr 30(357) 2005) väljatöötamisele ja reklaamimisele NVIDIA poolt, videokiirendite turu peamine konkurent ATI töötas välja ja juurutas oma sarnase lahenduse – CrossFire tehnoloogia. Nii nagu NVIDIA SLI, võimaldab see kombineerida kahe videokaardi ressursse ühes arvutis, suurendades sellega video alamsüsteemi jõudlust. CrossFire tehnoloogia erineb SLI-st põhimõtteliselt, seega on sellel konkurendiga vähe ühist. Eelistades selle või selle tehnoloogia teatud eeliseid, valivad kasutajad lähitulevikus NVIDIA ja ATI vahel mitte ainult aastate jooksul kujunenud kaubamärkide arvamuste, vaid ka SLI või CrossFire tehnoloogiate faktide põhjal.

Tehniline baas

Analoogiliselt NVIDIA-ga on kahe ATI videokaardi paigutamiseks ühte "rakmetesse" vaja sama tootja kiibistikuga emaplaati (kavandatakse, et CrossFire'i toetab ka Intel i975X kiibistik), millel on kaks PCI Expressi pesa. . Nagu SLI, on ka CrossFire nõudlik süsteemiressursside suhtes, mis nõuab kvaliteetset toiteallikat. Mõelge süsteemi nõuetele üksikasjalikumalt.

Emaplaat. Ema peab põhinema kiibistikul ATI Radeon Xpress 200 CrossFire. Need plaadid on saadaval nii AMD Sempron/Athlon 64 kui ka Intel Pentium 4/Celeron protsessoritele. Seega hakkab ATI nüüd raha teenima kiibikomplektidega, mille tootmine pole varem laiaulatuslikuks jõudnud.

Videokaardid. Tehnoloogia nõuab juhtivat CrossFire'i põhikaarti (sellest lähemalt allpool) ja mis tahes muud videokaarti, mis põhineb juhtiva kaardiga sama perekonna kiibil. Põhikaart erineb teistest DMS-59 pistiku (ühendatud alamkaardil DVI-ga), CrossFire kiibi ja loomulikult maksumuse poolest.

Jõuseade. Sellise tõsise komplekti hooldamiseks vajate toiteallikat minimaalse võimsusega 400–450 W, eelistatavalt võimsamat.

Noh, tegelikult on see kõik, mida vajate videosüsteemi kokkupanekuks CrossFire. Nagu olete märganud, suhtub ATI oma klientidesse paindlikumalt, ei seo neid, nagu maad kolhoosiga, ühe ja sama tootja kahe sama kiibiga kaardi kohustusliku ostmisega. Sidumine toimub ainult selle videokiibi perekonnaga, millel kiirendi põhineb. See tähendab, et saate osta juhtiva videokiirendi Radeon X800 ja ori Radeon X800 XL. Master Radeon X800 ühildub mis tahes tootja kaardiga, mis põhineb X800 kiibi mis tahes modifikatsioonil. See on tingimusteta eelis konkurendi ees – kui võtta üks kiirendi, siis on väljavaade edaspidiseks moderniseerimiseks teise videokaardi paigaldamisega, ei pea te otsima kindla tootja kaarti konkreetse kiibi alusel. Hetkel toetavad CrossFire tehnoloogiat X800 ja X850 baasil videokaardid ning uued tooted X1xxx baasil.

Mõned aastad tagasi tutvustas Apple uut graafika API-t – Metal. Selle erinevus samast Scene Kitist seisnes selles, et see ei ole kõrgetasemeline API, mis töötab OpenGL ES-i peal (OpenGL-i mobiiliversioon), vaid madala tasemega API renderdamiseks ja arvutamiseks, mis võib asendada OpenGL-i. Apple'i sõnul on Metal suurusjärgu võrra kiirem kui OpenGL ES (kuigi tegelikkuses on 10 korda kiirem ainult joonistuskõned, andmete edastamine GPU-sse). See API on saadaval kõikidele seadmetele, mis töötavad A7 protsessoriga ja uuematel, samuti Macis alates 2012. aastast.

Kuidas graafika API-d töötavad

Esiteks, mis on API? See tähistab rakenduste programmeerimisliidest, rakenduste programmeerimisliidest. Lihtsamalt öeldes on see valmis kood, mis muudab programmeerija jaoks programmide kirjutamise palju lihtsamaks. Tegelikult on see mingi poolfabrikaat – selle koodi põhjal saab oma programmi palju kiiremini ja lihtsamalt kirjutada.

Nüüd vaatame, kuidas GPU ise API-ga töötab. On vale arvata, et API-kõne töötab otse GPU-ga ja veelgi enam, et GPU lõpetab kõne töötlemise, kui API tulemus tagastatakse. Näiteks kui draiver täitis renderduskäske nende loomise ajal, jääks see CPU jõudeolekusse, oodates renderdamise lõpetamist. Ja pärast täitmist oleks see vastupidi – GPU oleks jõude, oodates draiverilt uusi käske.

Sel põhjusel töötavad CPU ja GPU asünkroonselt: graafikadraiver kogub esmalt kõik joonistuskutsed kogu kaadri kohta ja alles seejärel saadab need GPU-le. Peale selle, kui tuleb käsk järgmise kaadri joonistamiseks, töötleb seda kaadrit juba GPU. See tähendab, et saame ühe kaadri viivituse: samal ajal kui protsessor valmistab ette praeguse kaadri kõnet, renderdatakse GPU-s eelmist. Tegelikult saate puhverdada rohkem kui ühe kaadri ja seeläbi saada suurema kaadrisageduse: kõik sõltub protsessori ja videokaardi jõudlusest.

Uus Metal API-s

Mis on ülalkirjeldatud meetodil valesti? See on halb selle poolest, et GPU ja API vahel on vahendaja - draiver. Ja see on tema, kes kontrollib viivitusi. Metalli API-s on käsupuhvrid avatud ja rakendus saab neid täita ja GPU-s täitmiseks käsujärjekorda saata. Seega on rakendusel täielik kontroll töö üle ja ta saab hallata viivitusi. Veelgi enam, nüüd on lihtne käske paralleelstada ja kindlas järjekorras puhverdada, kuna programmeerijale muutub selgemaks, millised tulemused millises järjekorras saadaval on.

Teine oluline uuendus on riistvara: Apple A7 protsessoritel ja uuematel protsessoritel on Metal loodud töötama ühismäluga, st CPU ja GPU pääsevad ligi samadele andmetele, ilma et peaksid neid PCI siini kaudu edastama. Metall annab programmile otsese ligipääsu CPU puhvritele ning programmeerija saab "segada" arvutusi GPU ja CPU peal, mis võib programmi oluliselt kiirendada.

Tõeline kasu API Metallist

Nagu ma eespool selgitasin, võtab iga joonistuskõne protsessoril ja GPU-l veidi aega. GPU-l renderdamist ei saa arusaadavatel põhjustel kiiremaks muuta (see sõltub ainult GPU enda jõudlusest), kuid võite võita ka muul viisil: esiteks saate lühendada andmeedastusaega (kuna Metal töötab jagatud mäluga), ja teiseks vähendage CPU kõnede töötlemise aega. Kõnetöötlusaeg protsessoris väheneb vahendaja draiveri puudumise ja käsupuhvri paralleelse ehitamise tõttu.

Ja siin tekib küsimus – millisest kümnekordsest jõudluse kasvust Apple rääkis? Jah, see on tõsiasi, et CPU kõneaeg on nüüd palju väiksem. Kuid siin GPU-d siin peaaegu ei mõjutata, nii et kahjuks pole Metal API tõttu graafikat otseselt võimalik parandada. Aga kuna protsessor on vabastatud, saab seda laadida füüsikaga: osakeste füüsika arvutamine, paljude objektide koosmõju ( iPhone 7 esitlusel on kõigil meeles sada lendavat ahvi?), kanga ja vee mõju arvutamine ning nii edasi. Ja kuna varem tegi seda GPU, vabastame selle ja selgub, et kaudselt suudab see nüüd kuvada paremat pilti, mida näeme mängudes (samas Asphalt 8) ja näeme (pöörake tähelepanu sillutise detailidele kivid ja efektid):

OpenGL-i ja Metalli koostoime

Nagu ülaltoodust näha, pikendab Metal protsessori eluiga tõesti. Seega, kui süsteem ei toeta Metalli, kuid sellel on väga võimas protsessor, pole mängu OpenGL-i jaoks keeruline ümber kirjutada - ja just seda näeme Androidi jaoks mõeldud Vainglorys - maksimaalse graafika saamiseks (Apple A9 tase) OpenGL-is on vaja tipptasemel Snapdragon 820 protsessorit, mis on tühise jõudluse poolest (FLOPSis) kaks korda võimsam kui A9.

Apple Metal 2

Juunis toimunud esitlusel tutvustas Apple metalli uut versiooni. Peamised täiustused on VR-i, masinõppe ja väliste GPU-de tugi, mis teoreetiliselt võimaldab teil mänge arvutist Maci portida ilma graafika halvenemiseta (praegu töötab enamiku mängude portides sisuliselt Wine, mis vähendab jõudlust oluliselt ja mõjutab suuresti Maci niigi üsna nõrku GPU-sid). Kuidas see aga reaalsuseks saab – seda näeme alles tulevikus.

SEOTUD ARTIKLID