API:t (Application Programming Interface) tarjoavat laitteisto- ja ohjelmistokehittäjille keinot luoda ohjaimia ja ohjelmia, jotka toimivat nopeammin useilla eri alustoilla. Ohjelmistoohjaimet on suunniteltu olemaan vuorovaikutuksessa suoraan API:n kanssa käyttöjärjestelmän ja ohjelmiston sijaan.

Grafiikkasovellusliittymiä on tällä hetkellä kaksi - OpenGL (SGI) ja Direct 3D (Microsoft).

Vaikka näyttösovittimen valmistajat tukevat OpenGL-standardia, Microsoft tarjoaa Direct3D-tuen kattavammalle sovellusliittymälle nimeltä DirectX.

DirectX 9 ja uudemmat ovat ohjelmistoliitännän uusimmat versiot, jotka laajentavat 3D-grafiikan tukea ja tarjoavat paremmat peliominaisuudet. Lisätietoja DirectX:stä tai uusimman version lataamisesta on Microsoftin DirectX-Web-sivustossa: www.microsoft.com/directx.

CrossFire tai sli

Videokiihdytinmarkkinoiden pääkilpailija ATI kehitti ja otti käyttöön oman vastaavan ratkaisunsa, CrossFire-teknologian, vastauksena NVIDIA:n kehittämään ja edistämään vanhaa ja uutta SLI-teknologiaa (MK No. 30(357) 2005). Aivan kuten NVIDIA:n SLI, sen avulla voit yhdistää kahden näytönohjaimen resurssit yhdessä tietokoneessa keskenään, mikä lisää videoalijärjestelmän suorituskykyä. CrossFire-tekniikka eroaa perustavanlaatuisesti SLI:stä, ja siksi sillä on vähän yhteistä kilpailijansa kanssa. Antamalla etusijalle yhden tai toisen tekniikan tietyt edut, käyttäjät valitsevat lähitulevaisuudessa NVIDIA:n ja ATI:n välillä paitsi vuosien varrella muodostuneiden tuotemerkkien mielipiteiden, myös SLI- tai CrossFire-teknologioiden tosiasioiden perusteella.

Tekninen perusta

Analogisesti NVIDIA:n kanssa kahden ATI-näytönohjaimen sijoittamiseksi yhteen "valjaisiin" tarvitset emolevyn, jossa on saman valmistajan piirisarja (Intel i975X -piirisarjan on myös suunniteltu tukevan CrossFireä), jossa on kaksi PCI Express -paikkaa. SLI:n tavoin CrossFire vaatii järjestelmäresursseja, mikä edellyttää korkealaatuista virtalähdettä. Katsotaanpa järjestelmävaatimuksia yksityiskohtaisemmin.

Emolevy.Äidin on oltava piirisarjapohjainen ATI Radeon Xpress 200 CrossFire. Nämä levyt ovat saatavilla sekä AMD Sempron/Athlon 64- että Intel Pentium 4/Celeron -prosessoreille. Joten ATI ansaitsee nyt rahaa piirisarjoilla, joiden tuotanto ei ole aiemmin saavuttanut suurta mittakaavaa.

Videokortit. Jotta tekniikka toimisi, tarvitset CrossFire-pääkortin (lisätietoja alla) ja minkä tahansa muun näytönohjaimen, joka perustuu siruun, joka on peräisin isäntäkortin kanssa samasta perheestä. Master-kortin erottaa muista DMS-59-liittimen (joka on kytketty orjakortin DVI:hen), CrossFire-sirun ja tietysti hinta.

Virtalähde. Tällaisen vakavan sarjan ylläpitämiseksi tarvitset virtalähteen, jonka teho on vähintään 400–450 W, mieluiten tehokkaampi.

No, siinä on periaatteessa kaikki mitä tarvitset videojärjestelmän kokoamiseen CrossFire. Kuten olet huomannut, ATI on joustavampi asiakkaidensa kanssa, ei sido heitä kuin maata kolhoosiin kahden samalla sirulla varustetun kortin pakolliseen hankintaan samalta valmistajalta. Sidonta suoritetaan vain siihen videosiruperheeseen, johon kiihdytin perustuu. Eli voit ostaa johtavan Radeon X800 -videokiihdytin ja orja Radeon X800 XL:n. Master Radeon X800 on yhteensopiva minkä tahansa valmistajan korttien kanssa perustuen mihin tahansa X800-sirun modifikaatioon. Tämä on ehdoton etu kilpailijaan verrattuna - jos otat yhden kiihdytin, jossa on mahdollisuus modernisoida lisää asentamalla toinen näytönohjain, sinun ei tarvitse etsiä tietyn valmistajan korttia tietyn sirun perusteella. Tällä hetkellä CrossFire-tekniikkaa tukevat X800- ja X850-pohjaiset näytönohjaimet sekä uudet X1xxx-pohjaiset tuotteet.

niillä on korkeampi pakkaussuhde kuin kuvilla, joissa on vähän tällaisia ​​elementtejä (esimerkiksi kaavioita, kaavioita, yksinkertaisia ​​tekstuureja). Korkearesoluutioisia kuvia voidaan pakata korkealla pakkaussuhteella ilman, että ne vaikuttavat niiden laatuun. Jotta matalaresoluutioisten kuvien laatu säilyisi korkeana, tuloksena olevan pakkaussuhteen on oltava paljon pienempi. Kuvat, joissa on suuri värisyvyys (kuten 24-bittiset Truecolor-kuvat) pakataan tehokkaammin kuin kuvat, joissa on vähemmän bittejä pikseliä kohden (kuten 8-bittiset harmaasävyt).

Useimmat muut häviölliset pakkausmenetelmät ovat luonteeltaan symmetrisiä. Tämä tarkoittaa, että ne perustuvat tietyn toimintosarjan käyttöön, joka suoritetaan käänteisessä järjestyksessä pakkauksen purkamisen yhteydessä. Tietojen pakkaaminen ja purkaminen kestää suunnilleen saman ajan. Fraktaalipakkaus on epäsymmetrinen prosessi, joka kestää paljon kauemmin kuin purkaminen. Tästä seuraa, että fraktaalipakattu data on tarkoituksenmukaista käyttää tapauksissa, joissa kuvatiedostot usein puretaan mutta ei koskaan pakattu, esimerkiksi tallennettaessa kuvia grafiikkatietokantoihin CD-ROM-levyllä.

Joitakin yleisimpiä muotoja käsitellään lyhyesti alla:

Nykyaikaiset GUI API:t

Nykyaikaisten monimutkaisten grafiikkaohjelmien, erityisesti 3D-sovellusten, kehitys liittyy erottamattomasti API:iden käyttöön.

(Application Programming Interface).

API on joukko kirjastoja, jotka edustavat valmiita käyttöliittymää ohjelman työskentelyyn 3D-kiihdyttimien kanssa. Tällä hetkellä samanlaisia

Liittymiä on melko paljon, mutta ne kaikki voidaan jakaa kahteen luokkaan: universaaleihin ja erikoistuneisiin.

Universaalit API:t ovat yhteisiä kaikille 3D-kiihdyttimille, ja näiden API:iden laitteistokiihdytyksen tuki on kiihdyttimien itsensä vastuulla. Ensinnäkin meidän tulisi korostaa Microsoft DirectX:ää ja OpenGL:ää. Molempia käytetään pääasiassa tietokoneanimaatioohjelmissa.

Erikoistuneet sovellusliittymät on suunniteltu toimimaan tiettyihin 3D-piirisarjoihin rakennettujen grafiikkakiihdyttimien kanssa. tunnetuimmat niistä ovat Glide API - käyttöliittymä VooDoo®-sirujen kanssa työskentelemiseen - Savage3D-siruille jne. Erikoistuneiden sovellusliittymien avulla kirjoitetut ohjelmat toimivat vain niissä kiihdyttimissä, joita varten nämä API on luotu. Useimmat erikoistuneet API:t tarjoavat vain matalan tason ohjelmointirajapinnan, mutta viime aikoina DirectX:n uudet versiot sisältävät korkean tason tukirajapintoja, kuten DirectX for VisualBasic, joka tarjoaa kielituen Visual Basic -visuaaliseen ohjelmointiympäristöön kirjoitetuille multimediasovelluksille.

Microsoft DirectX API

Microsoft DirectX API on joukko ohjelmistorajapintoja, joita käytetään ratkaisemaan erilaisia ​​ongelmia: tietokonelaitteiston ohjelmallisesta ohjauksesta erityyppistä tietoa käyttävien multimediasovellusten kehittämiseen ja virtuaalimaailmojen luomiseen.

Päätavoitteena, johon Microsoft pyrki luodessaan DirectX-käyttöliittymää, oli tehdä Windows-käyttöjärjestelmää käyttävistä tietokoneista universaali alusta sovelluksille, joissa on runsaasti multimediaelementtejä: täysvärigrafiikkaa, videofragmentteja,

tami, 3D-animaatio ja stereoääni. Suoraan Windows-käyttöjärjestelmän ytimeen rakennettu DirectX-liittymä on integroitu palvelu

Windows 98 ja Windows 2000 sekä Microsoft Internet Explorer. Komponentit

DirectX voidaan myös ladata automaattisesti tietokoneellesi, kun asennat moderneja pelejä ja multimediasovelluksia, jotka on kehitetty Windows 95:lle. DirectX tarjoaa kehittäjille joukon ohjelmistorajapintoja, joiden avulla voit ratkaista kaksi pääongelmaa.

Ensin DirectX muuttaa sen avulla kehitetyt sovellukset ohjelmiksi, jotka ovat yhteensopivia minkä tahansa Windows-version kanssa ja toimivat kaikissa tietokoneissa, joihin tämä käyttöjärjestelmä on asennettu, käytetyn ohjelmiston tyypistä riippumatta. Samaan aikaan tällaiset sovellukset hyödyntävät tietokoneen teknisiä ominaisuuksia parhaalla mahdollisella tavalla ja tarjoavat parhaan suorituskyvyn. Tämä saavutetaan DirectX:n kahden pääkomponentin tarjoaman palvelun avulla: matalan tason liitännät, jotka muodostavat DirectX Foundationin, ja korkean tason liitännät, jotka muodostavat DirectX Median.

Toiseksi DirectX antaa kehittäjille mahdollisuuden irtautua tietyntyyppisestä näyttösovittimesta, äänikortista tai 3D-kiihdyttimestä ja keskittyä itse ohjelman logiikkaan.

DirectX Foundation tarjoaa kehittäjille joukon matalan tason ohjelmistorajapintoja, jotka tarjoavat tehokkaan pääsyn kaikkiin Windows-käyttöjärjestelmää käyttävän tietokoneen ominaisuuksiin, jotka on toteutettu laitteistotasolla - 3D-kiihdyttimet, äänikortit, syöttölaitteet. Ennen DirectX:n tuloa Windows-alustalle multimediasovelluksia luovien kehittäjien oli määritettävä ohjelmansa toimimaan erityyppisten laitteiden ja kokoonpanojen kanssa. Tämä ongelma on nyt ratkaistu. DirectX Foundation sisältää komponentin, joka tunnetaan nimellä Hardware Abstraction Layer (HAL), joka käyttää ohjelmistoja

ohjaimia ohjelmiston ja laitteiston välisen vuorovaikutuksen varmistamiseksi. Tämän seurauksena kehittäjät voivat luoda yhden version sovelluksesta DirectX-liitäntöjen avulla ilman, että heidän tarvitsee huolehtia siitä, että se toimii tietyissä laitteistokokoonpanoissa. DirectX tunnistaa automaattisesti tietokoneesi tekniset ominaisuudet ja asettaa tarvittavat parametrit. DirectX antaa sinun myös ajaa multimediasovelluksia, jotka vaativat laitteistotukea, jota ei ole saatavilla tietokoneessasi. Tässä tapauksessa HEL (Hardware Emulation Layer) -niminen komponentti emuloi niitä ohjelmistossa ja tarjoaa ohjelmisto-ajureita, jotka toimivat puuttuvina laitteina.

DirectX Media sijaitsee DirectX Foundationin päällä ja tarjoaa korkean tason palvelut - animaatiotuen, suoratoiston (kyky lähettää ja katsella ääni- ja videotietoja, kun ne ladataan Internetistä) ja vuorovaikutteisuutta. DirectX Foundationin tarjoamien matalan tason palvelujen ja DirectX Median tarjoamien korkean tason palvelujen automaattinen integrointi yksinkertaistaa multimediaelementtien luomis- ja toistamisprosessia, jolloin kehittäjät voivat sisällyttää ne sovelluksiinsa ja Web-sivuihinsa ja tarjota siten interaktiivista multimediasisältöä. jota ei aiemmin ollut saatavilla. Lisäksi DirectX Media auttaa ratkaisemaan erityyppisten multimediatehosteiden koordinointiongelman, mikä helpottaa niiden toiston synkronointia. Näiden kahden ydinkomponentin lisäksi Microsoft DirectX sisältää myös korkean tason komponentteja, jotka tarjoavat multimediatoimintoja Web-sovelluksille. Näitä ovat: NetMeeting - työkalu online-ryhmäkeskustelujen järjestämiseen ja Windows Media Player - työkalu multimediasisällön välittämiseen Internetin kautta. Tarkastellaanpa lyhyesti pääkomponentteja

DirectX Foundationin komponentit. Nämä sisältävät Microsoft DirectDraw, Direct3D(välitön ja säilytetty tila), DirectInput, DirectMusic, DirectSound,

DirectSound 3D ja DirectPlay. Nämä järjestelmätason ohjelmointirajapinnat

tarjoavat tehokkaan pääsyn erilaisiin tietokonelaitteisiin ja varmistavat sovellusten todellisen laitteistoriippumattomuuden, mikä eliminoi ajurien asennuksen ja laitteisto- ja ohjelmistoalustojen yhteensopimattomuuden ongelmat.

Microsoft Direct3D on käyttöliittymä 3D-näytönohjainten kanssa työskentelemiseen. Direct3D-arkkitehtuuri on esitetty kuvassa 1.5.

Win32 sovellus

Direct3D tukee kahta toimintatilaa - välitöntä tilaa ja säilytettyä tilaa. Välittömässä tilassa Direct3D tarjoaa kehittäjille laitteistotuen peli- ja multimediasovelluksille Microsoft Windows -ympäristössä. Sen avulla voit saavuttaa laitteistoriippumattomuuden, tukee vaihdettavaa Z-puskurointia ja Intel MMX -suoritinarkkitehtuuria. Tässä tilassa perusgrafiikkaprimitiivit toteutetaan suoraan, ilman suorituspuskureita.

Säilytetty tila helpottaa 3D-maailmojen luomista ja animointia, ja se tukee kahta uutta ominaisuutta: animaatiointerpolaattoreita värisekoituksella, sujuvaa objektien liikkeitä ja monia erilaisia ​​muunnoksia sekä 3D-verkkorakenteen peräkkäistä täyttämistä.

objektit (silmät), mikä mahdollistaa niiden asteittaisen lataamisen etäpalvelimista. Tämä antaa kehittäjille mahdollisuuden käyttää 3D-grafiikkaa tehokkaasti ilman, että heidän tarvitsee suoraan manipuloida objektirakenteita matalalla tasolla.

On huomattava, että Direct3D-sovellukset kommunikoivat grafiikkalaitteiden kanssa samalla tavalla tilasta riippumatta. He voivat käyttää tai olla käyttämättä ohjelmistoemulointia ennen HAL:in käyttöä. Todellisuudessa Direct3D on tiiviisti integroitu DirectDraw-komponenttiin, joten kuvassa 1.2 laitteiston abstraktiokerros HAL on nimetty DirectDraw/Direct3D HAL. Direct3D Z-puskuroi ja hahmontaa pinnat, kun taas DirectDraw näyttää ne suoraan. Direct3D COM -liitäntä on DirectDraw-liitäntä.

DirectDraw on muistinhallinnan hallintaohjelma, joka tarjoaa ydintoimintoja Windows-alustalla toimiville grafiikka- ja multimediasovelluksille. Toisin kuin perinteinen Windows-grafiikka, DirectDraw käyttää suoraa pääsyä näyttömuistiin ja grafiikkalaitteisiin tarjoten samalla täyden yhteensopivuuden Windows-sovellusten kanssa.

Kuva 1.6 näyttää DirectDraw'n, käyttöjärjestelmän ydinkomponentin GDI (Graphics Device Interface), HAL-laitteiston abstraktiokerroksen ja laitteistoemulointikerroksen välisen vuorovaikutuksen.

(Hardware Emulation Layer, HEL). Kuten näet, DirectDraw on olemassa itsenäisesti

mo GDI:stä ja molemmilla liitännöillä on mahdollisuus käyttää grafiikkalaitteita suoraan laitteistosta riippumattomien kerrosten kautta. Toisin kuin GDI, DirectDraw ei käytä laitteisto-ominaisuuksia. Jos jokin laite ei tue vaadittuja toimintoja, DirectDraw yrittää emuloida sitä HEL:n avulla. DirectDraw tukee laajaa valikoimaa näyttösovittimia – yksinkertaisista näytöistä monimutkaisiin ammattilaitteisiin. Graafisten pintojen tasolla työskentelevä DirectDraw palvelee

korkean tason graafisten toimintojen ja käyttöliittymien perusta ja mahdollistaa joko laitteiden tarjoamien laitteistoominaisuuksien käytön tai tarvittaessa emuloinnin.

Win32 sovellus

Näytönohjain

Kuva 1.6 – DirectDraw'n integrointi järjestelmään

DirectInput on rajapinta erilaisiin syöttölaitteisiin - näppäimistöön, hiiriin, joystickiin sekä pakkopalautteisiin. Perinteisiin vakioominaisuuksiin verrattuna tämä käyttöliittymä tukee useampia laitteita ja tarjoaa nopeamman vastauksen pyyntöihin. Työskentelemällä suoraan laiteajureiden kanssa DirectInput ei käytä Microsoft Windows -viestijärjestelmää.

Uusiin DirectInput-ominaisuuksiin kuuluu laajennettu luettelo tuetuista laitteista, mukaan lukien: peliohjaimet, lentokoneet

lentoikeet, virtuaalitodellisuuspäähineet

Ja palautetta sisältävät laitteet, jotka tarjoavat tehosteita, kuten tärinää, liikkeenkestoa jne., joiden käyttö tekee nykyaikaisista peleistä entistä realistisempia.

DirectMusic on DirectX-teknologiaperheen uusi komponentti, joka on ohjelmistokuori, jolla luodaan musiikkimalleja ja ohjeita käyttäjän toimiin reagoimiseksi. Näin kehittäjät voivat luoda taustamusiikkia reaaliajassa web-sivuilla tai multimediasovelluksissa määritettyjen algoritmien perusteella. DirectMusic tarjoaa täyden toteutuksen DownLoadable Sounds (DLS) -standardista, jonka avulla kehittäjät voivat luoda musiikkimalleja, joita voidaan toistaa käytännössä millä tahansa laitteistoalustalla. DirectMusic sisältää DirectMusic Producerin - integroidun editorin, jonka avulla voit työskennellä kaikkien DirectMusic-objektien kanssa: tyylit, mallit, DLS-työkalut jne.

DirectPlay on korkean tason ohjelmistoliitäntä sovellusohjelman ja viestintäpalvelujen välillä, joka yksinkertaistaa viestintää modeemin tai paikallisverkon kautta. DirectPlay sisältää joukon apuohjelmia, joiden avulla pelaajat voivat löytää kumppaneita ja Web-sivustoja, ylläpitää tiedonkulkua palvelimien välillä, ja samoja toimintoja tuetaan kaikille sovelluksen käyttäjille online-palvelun tai protokollien tyypistä riippumatta.

SISÄÄN Matalan tason DirectX Foundation -rajapintojen lisäksi DirectX sisältää korkeamman tason ohjelmointirajapintoja

ja DirectX Media -komponentit, jotka tukevat multimediasovelluksia, animaatioita ja suoratoistotietoja. DirectX Media koostuu tällä hetkellä seuraavista pääohjelmointiliitännöistä:

DirectShow (aiemmin ns ActiveMovieSDK); Suoraanimaatio (aiemmin ns ActiveX-animaatio); DirectX-muunnos. Huomaa, että DirectX Media -palvelut käyttävät DirectX Foundation -palveluita.

, sovelluksen (kirjasto, palvelu) tai käyttöjärjestelmän tarjoamat toiminnot, rakenteet ja vakiot käytettäväksi ulkoisissa ohjelmistotuotteissa. Ohjelmoijat käyttävät sitä kirjoittaessaan kaikenlaisia ​​sovelluksia.

Tietosanakirja YouTube

• 1 / 5

  API määrittelee ohjelman (moduulin, kirjaston) tarjoamat toiminnot, kun taas API mahdollistaa abstraktin siitä, miten tämä toiminto on toteutettu.

  Jos ohjelmaa (moduulia, kirjastoa) pidetään mustana laatikkona, API on joukko "kahvoja", jotka ovat tämän laatikon käyttäjän käytettävissä ja joita hän voi pyörittää ja vetää.

  Ohjelmistokomponentit ovat vuorovaikutuksessa toistensa kanssa API:iden kautta. Tällöin komponentit muodostavat yleensä hierarkian - korkean tason komponentit käyttävät matalan tason komponenttien API:ta, ja ne puolestaan ​​käyttävät vielä alemman tason komponenttien API:ta.

  Tiedonsiirtoprotokollat ​​Internetissä on rakennettu tälle periaatteelle. Standardiprotokollapino (OSI-verkkomalli) sisältää 7 kerrosta (fyysisestä bitinsiirtokerroksesta sovellusprotokollakerrokseen, kuten HTTP ja IMAP). Jokainen kerros käyttää edellisen ("alemman") tiedonsiirtokerroksen toiminnallisuutta ja tarjoaa vuorostaan ​​tarvittavan toiminnallisuuden seuraavalle ("korkeammalle") tasolle.

  On tärkeää huomata, että protokollan käsite on merkitykseltään lähellä API-käsitettä. Molemmat ovat toiminnallisuuden abstraktioita, vain ensimmäisessä tapauksessa puhumme tiedonsiirrosta ja toisessa sovellusten vuorovaikutuksesta.

  Funktio- ja luokkakirjastosovellusliittymä sisältää kuvauksen allekirjoituksia Ja funktioiden semantiikka.

  Toiminnon allekirjoitus

  Joskus ne erottavat kutsun allekirjoitus Ja täytäntöönpanon allekirjoitus toimintoja. Kutsuallekirjoitus kootaan yleensä funktiokutsun syntaktisesta rakenteesta ottaen huomioon annetun funktion laajuuden allekirjoitus, funktion nimi, kutsun varsinaisten argumenttityyppien järjestys sekä funktion tyyppi. tulos. Toteutusallekirjoitus sisältää yleensä joitain elementtejä funktion määrittelyn syntaktisesta rakenteesta: funktion laajuuden määritteen, sen nimen ja muodollisten argumenttityyppien sarjan.

  Esimerkiksi C++-ohjelmointikielessä kääntäjä tunnistaa yksinkertaisen funktion yksilöllisesti sen nimen ja argumenttien tyyppijonon perusteella, joka muodostaa funktion allekirjoituksen tällä kielellä. Jos funktio on tietyn luokan metodi, luokan nimi sisällytetään myös allekirjoitukseen.

  Ohjelmistoteollisuudessa yhteiset, vakiorajapinnat vakiotoiminnallisuudelle ovat tärkeitä, koska ne varmistavat, että kaikki yhteistä API:ta käyttävät ohjelmat toimivat yhtä hyvin tai ainakin tyypillisesti tutulla tavalla. GUI API:iden tapauksessa tämä tarkoittaa, että ohjelmilla on samanlainen käyttöliittymä, mikä helpottaa uusien ohjelmistotuotteiden oppimista.

  Toisaalta erot eri käyttöjärjestelmien API:issa vaikeuttavat sovellusten siirtämistä alustojen välillä. On olemassa useita menetelmiä tämän monimutkaisuuden kiertämiseksi - kirjoittaa "välitason" API:ita (wxWidgets, , GTK jne. GUI API), kirjoittaa kirjastoja, jotka yhdistävät yhden käyttöjärjestelmän järjestelmäkutsut toisen käyttöjärjestelmän järjestelmäkutsuihin (ajoajat, kuten Wine, cygwin jne. .), koodausstandardien käyttöönotto ohjelmointikielissä (esimerkiksi C-kielen standardikirjasto), tulkittujen kielten kirjoittaminen eri alustoilla (python, perl, php, tcl, Java jne.).

  On myös huomattava, että ohjelmoijalla on usein käytössään useita erilaisia ​​API:ita saman tuloksen saavuttamiseksi. Lisäksi jokainen API on yleensä toteutettu käyttämällä API-ohjelmistokomponentteja, joiden abstraktiotaso on alhaisempi.

  Esimerkiksi: nähdäksesi rivin "Hei, maailma!" ", sinun tarvitsee vain luoda HTML-dokumentti, jolla on minimaalinen otsikko ja yksinkertainen runko, joka sisältää tämän rivin. Kun selain avaa tämän dokumentin, selainohjelma välittää tiedostonimen (tai jo avoimen tiedostokuvaajan) HTML-dokumentteja käsittelevälle kirjastolle, joka puolestaan ​​lukee tämän tiedoston käyttöjärjestelmän API:n avulla ja ymmärtää sen rakenteen. , kutsu sitten peräkkäin API-kirjaston kautta tavallisia graafisia primitiivitoimintoja, kuten "tyhjennä ikkuna", "kirjoita "Hei, maailma!" Suorittaessaan näitä toimintoja grafiikkaprimitiivikirjasto ottaa yhteyttä ikkunan käyttöliittymäkirjastoon asianmukaisilla pyynnöillä, ja tämä kirjasto kutsuu käyttöjärjestelmän API:ta kirjoittamaan tietoja näytönohjaimen puskuriin.

  Lisäksi lähes jokaisella tasolla on itse asiassa useita mahdollisia vaihtoehtoisia sovellusliittymiä. Esimerkiksi: voisimme kirjoittaa lähdedokumenttia ei HTML:llä, vaan LaTeX:llä, ja voisimme käyttää mitä tahansa selainta näyttämiseen. Eri selaimet käyttävät yleensä erilaisia ​​HTML-kirjastoja, ja lisäksi koko juttu voidaan kääntää erilaisilla primitiivisillä kirjastoilla ja eri käyttöjärjestelmillä.

  Nykyisten monitasoisten API-järjestelmien tärkeimmät haasteet ovat siksi:

  • Vaikeus siirtää ohjelmakoodia API-järjestelmästä toiseen (esimerkiksi käyttöjärjestelmää vaihdettaessa);
  • Toimivuuden menetys siirryttäessä alemmalta tasolta korkeammalle. Karkeasti sanottuna jokainen API "kerros" on luotu helpottamaan joidenkin vakiotoimintojen suorittamista. Mutta samaan aikaan joidenkin muiden alemman tason API:n tarjoamien toimintojen suorittaminen tulee todella vaikeaksi tai muuttuu täysin mahdottomaksi.

  Tunnetuimmat API:t

  Käyttöjärjestelmät

  Muutama vuosi sitten Apple esitteli uuden grafiikkasovellusliittymän - Metal. Sen ero samasta Scene Kitistä oli se, että se ei ole korkean tason API, joka toimii OpenGL ES:n (OpenGL:n mobiiliversion) päällä, vaan matalan tason API renderöintiin ja laskemiseen, joka voi korvata OpenGL:n. Applen mukaan Metal on suuruusluokkaa nopeampi kuin OpenGL ES (todellisuudessa vain puhelujen piirtäminen ja tiedonsiirto GPU:lle ovat 10 kertaa nopeampia). Tämä API on saatavilla kaikille laitteille, joissa on A7-prosessori tai uudempi, sekä Mac-tietokoneille vuodesta 2012 alkaen.

  Miten grafiikkasovellusliittymät toimivat
  
  Ensinnäkin mikä on API? Tämä tulee sanoista Application Programming Interface, sovellusohjelmointirajapinta. Yksinkertaisesti sanottuna tämä on valmis koodi, joka voi tehdä ohjelmoijan elämästä paljon helpompaa ohjelmien kirjoittamisessa. Itse asiassa tämä on jonkinlainen puolivalmiste - tämän koodin perusteella voit kirjoittaa oman ohjelman paljon nopeammin ja helpommin.

  Katsotaan nyt, kuinka GPU itse toimii API:n kanssa. On väärin ajatella, että API-kutsu toimii suoraan GPU:ssa, ja vieläkin virheellisempi on ajatella, että GPU lopettaa puhelun käsittelyn, kun API-tulos palautetaan. Jos ohjain esimerkiksi suoritti renderöintikomentoja niiden luomishetkellä, se käyttäisi CPU:ta tyhjäkäynnillä odottaessaan renderöinnin valmistumista. Ja suorituksen jälkeen se olisi päinvastoin - GPU olisi tyhjäkäynnillä odottamassa uusia komentoja ajurilta.

  Tästä syystä CPU ja GPU toimivat asynkronisesti: näytönohjain kerää ensin kaikki piirtokutsut koko kehykseltä ja lähettää ne vasta sitten GPU:lle. Lisäksi, kun seuraavan kehyksen piirtämiskomento saapuu, GPU käsittelee jo tämän kehyksen. Eli saamme yhden kehyksen viiveen: kun CPU valmistelee kutsua nykyiselle kehykselle, viimeinen renderöidään GPU:ssa. Itse asiassa voit puskuroida useamman kuin yhden kehyksen ja saada siten suuremman kuvanopeuden: kaikki riippuu vain prosessorin ja näytönohjaimen suorituskyvystä.

  API-metallin innovaatiot
  
  Mitä vikaa yllä kuvatussa menetelmässä on? Huono puoli siinä on, että GPU:n ja API:n välillä on välittäjä – ohjain. Ja se on hän, joka hallitsee viivästyksiä. Metal API:ssa komentopuskurit ovat auki, ja sovellus voi täyttää ne itse ja lähettää ne komentojonoon suoritettavaksi GPU:lla. Tällä tavalla sovellus hallitsee työtä täysin ja voi hallita viiveitä. Lisäksi nyt on mahdollista helposti rinnakkaista komentoja ja sijoittaa ne puskuriin tietyssä järjestyksessä, koska ohjelmoijalle tulee selvemmäksi, mitkä tulokset ovat saatavilla missä järjestyksessä.

  Toinen tärkeä innovaatio on laitteisto: Apple A7:ssä ja sitä uudemmissa prosessoreissa Metal on suunniteltu toimimaan jaetun muistin kanssa, eli CPU ja GPU voivat käyttää samoja tietoja ilman, että niitä tarvitsee siirtää PCI-väylän kautta. Metalli antaa ohjelmalle suoran pääsyn CPU-puskureihin, ja ohjelmoija voi "sekoittaa" laskelmia GPU:lla ja CPU:lla, mikä voi nopeuttaa ohjelmaa merkittävästi.

  Todellinen hyöty API Metalista
  
  Kuten yllä selitin, jokainen piirtokutsu kestää jonkin aikaa CPU:ssa ja GPU:ssa. GPU:lla renderöimistä ei voida tehdä ilmeisistä syistä nopeammaksi (se riippuu vain itse GPU:n suorituskyvystä), mutta voit voittaa muilla tavoilla: ensinnäkin voit lyhentää tiedonsiirtoaikaa (koska Metal toimii jaetun muistin kanssa) , ja toiseksi, voit lyhentää puhelunkäsittelyaikaa CPU:ssa. Puhelun käsittelyaika CPU:ssa lyhenee väliohjaimen puuttumisen ja komentopuskurin rinnakkaisrakenteen vuoksi.

  Ja tässä herää kysymys - mistä tuottavuuden kymmenkertaisesta kasvusta Apple puhui? Kyllä, juuri sitä CPU:n puheluaika on nyt paljon lyhyempi. Mutta GPU ei juuri vaikuta tässä, joten loppujen lopuksi on valitettavasti mahdotonta parantaa grafiikkaa suoraan Metal API:n avulla. Mutta koska prosessori on ilmainen, siihen voi ladata fysiikkaa: hiukkasfysiikan laskemista, monien esineiden vuorovaikutusta (muistavatko kaikki sata lentävää apinaa iPhone 7:n esittelyssä?), kankaan ja veden vaikutusten laskemista ja pian. Ja koska grafiikkasuoritin teki tämän ennen, vapautamme sen ja käy ilmi, että epäsuorasti se voi nyt tuottaa paremman kuvan, mikä on mitä näemme peleissä (mukaan lukien Asphalt 8) (kiinnitä huomiota katukivien yksityiskohtiin ja tehosteet):

  

  Yhteentoimivuus OpenGL:n ja Metallin välillä
  
  Kuten yllä olevasta voidaan nähdä, metalli todella parantaa prosessorin käyttöikää. Siksi, jos järjestelmä ei tue metallia, mutta siinä on erittäin tehokas prosessori, ei ole erityisen vaikeaa kirjoittaa peliä uudelleen OpenGL:lle - ja tämä on juuri se, mitä näemme Vainglory for Android -sovelluksessa - maksimaalisen grafiikan saamiseksi (Apple A9 -taso ) OpenGL:ssä vaaditaan Snapdragon 820 -tason huippuluokan prosessori , joka raakasuorituskyvyn suhteen (FLOPSissa) on kaksi kertaa tehokkaampi kuin A9.

  Apple Metal 2
  
  Kesäkuun esittelyssä Apple esitteli uuden version Metalista. Tärkeimmät parannukset ovat tuki VR:lle, koneoppimiselle ja ulkoisille grafiikkasuorituksille, jotka teoriassa mahdollistavat PC-pelien siirtämisen Macille ilman grafiikan heikkenemistä (tällä hetkellä useimpien pelien porteissa on pääasiassa Wine, mikä heikentää merkittävästi suorituskykyä ja sillä on erittäin voimakas vaikutus jo melko heikkoihin grafiikkasuorituksiin Macissa). Mutta katsotaan, miten tämä todellisuudessa tulee käymään vasta tulevaisuudessa.

  Viime viikolla Vulkan API esiteltiin, ja AMD ja NVIDIA ilmoittivat laajan tuen sille. Uuden graafisen käyttöliittymän on kehittänyt vuonna 2000 perustettu konsortio Khronos Group. Khronos Group vastaa avoimien standardien kehittämisestä ja ylläpitämisestä multimediasovelluksille eri alustoilla ja laitteilla. Konsortiota tukevat AMD ja NVIDIA sekä monet muut yritykset.

  Viime viikolla Vulkan API:n lopullinen versio 1.0 ratifioitiin. AMD ja NVIDIA esittelivät vastaavat beta-ohjaimensa. AMD esijulkaisi Radeon Softwaren beta-version helmikuun 14. päivänä. NVIDIA esitteli GeForce 356.39 -ohjaimen, joka on myös keskittynyt tukemaan Vulkan API:ta.

  Vulkan API:n lähestymistapa on hyvin samanlainen kuin Mantle API. Ajatuksena on, että kehittäjät saavat syvemmän pääsyn laitteistoon saadakseen siitä kaiken irti. Tämän lähestymistavan avulla voit välttää olemassa olevia pullonkauloja niin paljon kuin mahdollista. Toisaalta kehittäjien on tiedettävä tarkalleen, mitä he tekevät - esimerkiksi työskennellessään muistin kanssa. OpenGL-käyttöliittymä ei ole yhtä suosittu kuin DirectX, mutta sen avulla voit puristaa enemmän irti.

  Vulkan API versiossa 1.0 on tuettu Windows 7:ssä, Windows 8.1:ssä, Windows 10:ssä, Androidissa ja Linuxissa. Pelien kehittäjät eivät ole vielä ilmoittaneet tuesta tietyille peleille, mutta kannattaa odottaa Games Developer Conference -konferenssia, joka pidetään 14.-18. maaliskuuta San Franciscossa. Pelimoottoreilta löytyy edelleen tietoa Source 2:sta, joka jo tukee Vulkan API:ta. Virheenkorjausprosessia helpottaa Valven, LunarG:n ja Codeplayn tuki.

  Talos-periaate

  Okei, mutta mikä peli tai moottori tukee Vulkan API:ta? Talos-periaatteen on kehittänyt Croteam, jonka tiedetään aiemmin tukevan monia grafiikkasovellusliittymiä. Ja uusimmassa iteraatiossa Talos Principle ei ole poikkeus - se tukee DirectX 9:ää, DirectX 11:tä, OpenGL:ää ja nyt Vulkania. Kehitysstudiolle Vulkan on kokeilupallo, vaikka Vulkan API on saatavilla versiossa 1.0, tuki on vielä betavaiheessa. Croteamin kehittäjät lisäsivät tukea noin kolme kuukautta. Mutta API:n universaali luonne mahdollistaa Linux-version esittelemisen pian.

  Vulkan API on teoriassa yhteensopiva useiden alustojen kanssa - mutta toistaiseksi testejä ja vertailuja voidaan tehdä vain Windowsilla, ja tällä on rajoituksensa. Täytäntöönpano on vielä hyvin varhaisessa vaiheessa. DirectX 11 -renderöintipolkua on jalostettu useiden vuosien ajan, joten optimoinnille ei ole varaa. Tässä tilanne riippuu enemmän ajurien kehittäjistä, nimittäin AMD:stä ja NVIDIAsta. Talos Principle oli ensimmäinen peli, joka tuki Vulkania. Tästä syystä ei ole vielä mahdollista tehdä vertailevaa testiä tuen hyvän tai huonon toteutumisen arvioimiseksi.

  Uudet tekniikat otetaan käyttöön ensin valmistajien valmistamissa esimerkeissä. DirectX 12:n tapauksessa painopiste oli Draw Callsissa, sama 3DMark DirectX 12 -testi perustuu vain Draw Calls -suorituskyvyn mittaamiseen, DirectX 12 -pelit, kuten Star Wars, myös yrittävät käyttää samanlaista kuormaa. Mutta Talos Principle ei luota niin paljon korkeaan Draw Call -nopeuteen, jotta matalan tason API:lla olisi paljon eroa.

  Tuki Vulkan API -versiolle 1.0 on alkuvaiheessa, ja sama koskee AMD- ja NVIDIA-ajureita. Molemmat ajurit ovat pohjimmiltaan beta-versioita, joten GPU-valmistajat näkevät ne. Yleensä ei ole olemassa uusia suorituskykyparannuksia tai tukea uusille teknologioille, joten saamme askeleen taaksepäin. Mutta kun tietty kehitystaso on saavutettu, molempien GPU-kehittäjien ajureilla on Vulkan-tuki lopullisessa versiossa. Milloin tämä tapahtuu, ei ole täysin selvää. Mutta toistaiseksi keskeiset sovellukset eivät käytä Vulkania, ja API:ta tukevat pelit ovat betavaiheessa, joten GPU-kehittäjät voivat turvallisesti jalostaa ohjaimiaan.

  Testejä varten otimme näyttökorttien testijärjestelmämme. Olemme jo kuvanneet edellä AMD- ja NVIDIA-näytönohjainkorttien ajurit. Asetimme grafiikkaasetukset maksimitasolle, mutta testasimme myös alhaisia ​​resoluutioita 1 280 x 720 pikseliin asti Draw Callin suorituskyvyn parantamiseksi.

  Talos Principle -testi - 1,280 x 720 pikseliä
  

  Talos Principle -testi - 2,560 x 1,440 pikseliä
  

  Talos Principle -testi - 3,840 x 2,160 pikseliä
  

  Kuten tuloksista näkyy, Vulkan API tarjoaa merkittävän lisäyksen OpenGL:ään verrattuna. Mutta uusi API ei saavuta DirectX 11:n suorituskykyä. Tähän on useita syitä. Toisaalta Vulkanin kehitys on alkuvaiheessa. Tämä koskee itse API:ta, ohjainta ja peliä The Talos Principle. Verrattuna OpenGL:ään uudella käyttöliittymällä voit vapauttaa resursseja ja välttää pullonkauloja. Mutta DirectX on parantunut useiden vuosien ajan nykyiselle tasolleen. Joka tapauksessa Vulkan API:n potentiaali on erittäin hyvä.

  Jos sukeltaamme yksityiskohtiin, emme löytäneet visuaalisia eroja Vulkan API:n ja DirectX 11:n välillä. Joten renderöintipolku on erittäin hyvin sovitettu. Nykyisessä The Talos Principlen toteutuksessa 2 Gt:n muistia sisältävien näytönohjainkorttien suorituskyky heikkenee, mikä johtuu luultavasti ei tehokkaimmasta muistin toiminnasta. Kuten Mantle ja DirectX 12, Vulkan API voi käyttää muistiresursseja syvemmällä tasolla - tämä tosiasia voidaan nähdä etuna, mutta siitä voi tulla myös haitta, jos kehittäjät eivät pysty käyttämään muistia tehokkaasti.

  Olin hieman pettynyt nykyisen NVIDIA-ohjaimen virheeseen, jonka vuoksi jouduin käynnistämään järjestelmän uudelleen jokaisen testin jälkeen. Ilman uudelleenkäynnistystä peli kaatui. Vaikka emme kohdanneet samanlaista virhettä AMD-ohjaimen kanssa.

  Vulkan API:n nykyinen toteutus vaikuttaa lupaavalta. Toistaiseksi se ei ole niin relevantti pöytätietokoneiden peleissä, koska DirectX 11- ja 12-markkinat ovat erittäin suuret ja samaan DirectX 12:een verrattuna toteutuskustannukset voivat olla liian korkeat ja tuotto liian pieni. Mutta jos pelien on toimittava eri alustoilla erilaisilla laitteistovaatimuksilla, Vulkanilla voi olla tärkeä rooli. Joka tapauksessa meidän pitäisi odottaa pelinkehittäjien reaktiota, muuten päädymme kana-muna-ongelmaan, josta on vaikea päästä eroon.