Suora renderöintipäällikkö - Direct Rendering Manager

Direct Rendering Manager ( DRM ) on osajärjestelmänä Linux Kernel vastuussa vuorovaikutuksessa GPU modernin näytönohjaimet . DRM paljastaa sovellusliittymän, jonka avulla käyttäjätilaohjelmat voivat lähettää komentoja ja dataa GPU: lle ja suorittaa toimintoja, kuten näytön tila-asetuksen määrittämisen. DRM kehitettiin alun perin X Server Direct Rendering Infrastructure -järjestelmän ytimen tila -komponenttina , mutta siitä lähtien sitä on käytetty muissa graafisissa pinovaihtoehdoissa, kuten Waylandissa .

Käyttäjätilaohjelmat voivat käyttää DRM-sovellusliittymää käskemään GPU: ta tekemään laitteistokiihdytettyä 3D-renderointia ja videon dekoodausta sekä GPGPU-laskentaa .

Yleiskatsaus

Linux-ydin oli jo API nimeltään fbdev , käytetään hallita ruutupuskurille on näytönohjain , mutta sitä ei voitu käyttää käsittelemään tarpeisiin nykyaikaisen 3D-kiihtyi GPU -pohjaisen näytönohjainta. Nämä laitteet vaativat yleensä komentorivin asettamisen ja hallinnan omassa muistissaan lähettääkseen komentoja GPU: lle, ja ne edellyttävät myös puskureiden ja muistin vapaan tilan hallintaa. Aluksi käyttäjäavaruusohjelmat (kuten X Server ) hallitsivat suoraan näitä resursseja, mutta ne toimivat yleensä ikään kuin he olisivat ainoat, joilla oli pääsy niihin. Kun kaksi tai useampi ohjelma yritti hallita samaa laitteistoa samanaikaisesti ja asetti resurssit kullekin omalla tavallaan, useimmiten ne päättyivät katastrofaalisesti.

Ilman DRM: ää

DRM: n kanssa

DRM mahdollistaa useiden ohjelmien samanaikaisen pääsyn 3D -näytönohjaimeen välttäen törmäyksiä

Direct Rendering Manager luotiin, jotta useat ohjelmat voivat käyttää videolaitteistoa yhdessä. DRM saa yksinoikeuden käyttää GPU: ta ja vastaa komentojonon, muistin ja muiden laitteistoresurssien alustamisesta ja ylläpidosta. Ohjelmat, jotka haluavat käyttää GPU: ta, lähettävät pyynnöt DRM: lle, joka toimii välimiehenä ja välttää mahdolliset ristiriidat.

DRM: n soveltamisalaa on laajennettu vuosien aikana kattamaan enemmän toimintoja, joita käyttäjätilaohjelmat ovat aiemmin käyttäneet, kuten kehyspuskurin hallinta ja tilan asetus , muistinjako-objektit ja muistin synkronointi. Joillekin näistä laajennuksista annettiin erityisiä nimiä, kuten Graphics Execution Manager (GEM) tai ytimen tilan asetus (KMS), ja terminologia on etusijalla, kun niiden tarjoamat toiminnot mainitaan erikseen. Mutta ne ovat todella osa koko ytimen DRM -alijärjestelmää.

Suuntaus sisällyttää tietokoneeseen kaksi grafiikkasuoritinyksikköä - erillinen ja integroitu - johti uusiin ongelmiin, kuten grafiikkasuorittimen vaihtamiseen, jotka oli myös ratkaistava DRM -kerroksessa. Jotta voidaan vastata Nvidia Optimus tekniikka, DRM toimitettiin GPU purkamiseen kykyjä, nimeltään alkuluku.

Ohjelmistoarkkitehtuuri

Prosessi, jossa käytetään Linux -ytimen Direct Rendering Manageria 3D -kiihdytetyn näytönohjaimen käyttämiseen

Direct Rendering Manager sijaitsee ytintilassa , joten käyttäjätilaohjelmien on käytettävä ytimen järjestelmäpuheluita palvelujensa pyytämiseksi. DRM ei kuitenkaan määrittele omia mukautettuja järjestelmäpuheluitaan. Sen sijaan se seuraa Unix periaatetta " kaikki on tiedosto " paljastaa GPU läpi tiedostojärjestelmä nimi avaruudesta laitetiedostot alla /devhierarkiassa. Jokaista DRM: n havaitsemaa GPU: ta kutsutaan DRM -laitteeksi , ja laitetiedosto (jossa X on järjestysnumero) luodaan liittymään sen kanssa. Käyttäjätilaohjelmien, jotka haluavat puhua GPU: n kanssa, on avattava tämä tiedosto ja käytettävä ioctl- puheluita kommunikoidakseen DRM: n kanssa. Eri IP -osoitteet vastaavat DRM -sovellusliittymän eri toimintoja . /dev/dri/cardX

Kirjasto nimeltään libdrm helpottamiseksi luotiin käyttöliittymän käyttäjän avaruusohjelmien kanssa DRM osajärjestelmään. Tämä kirjasto on vain kääre, joka tarjoaa toiminnon, joka on kirjoitettu C : llä jokaiselle DRM -sovellusliittymän ioctlille, sekä vakioille, rakenteille ja muille avustajaelementteille. Libdrm: n käyttö ei ainoastaan ​​vältä ytimen käyttöliittymän paljastamista suoraan sovelluksille, vaan tarjoaa myös tavanomaiset edut koodin uudelleenkäytöstä ja jakamisesta ohjelmien välillä.

Direct Rendering Manager -arkkitehtuurin yksityiskohdat: DRM -ydin ja DRM -ohjain (mukaan lukien GEM ja KMS), joihin on liitetty libdrm

DRM koostuu kahdesta osasta: yleinen "DRM -ydin" ja erityinen ("DRM -ohjain") kullekin tuetulle laitteistotyypille. DRM-ydin tarjoaa peruskehyksen, johon eri DRM-ohjaimet voivat rekisteröityä, ja tarjoaa myös käyttäjätilalle minimaalisen joukon ioctleja, joilla on yhteiset, laitteistosta riippumattomat toiminnot. DRM-ohjain toisaalta toteuttaa API: n laitteistosta riippuvan osan, joka liittyy sen tukemaan GPU-tyyppiin; sen pitäisi tarjota DRM -ytimen ulkopuolelle jäävien muiden ioctlien toteuttaminen, mutta se voi myös laajentaa sovellusliittymää ja tarjota lisäyhteyksiä, joissa on lisätoimintoja vain tällaisessa laitteistossa. Kun tietty DRM-ohjain tarjoaa parannetun sovellusliittymän, käyttäjätilan tilaa libdrm laajentaa myös ylimääräinen kirjasto libdrm- ohjain , jota käyttäjätila voi käyttää liitäntään muiden ioctlien kanssa.

API

DRM-ydin vie useita rajapintoja käyttäjätilasovelluksiin, jotka on yleensä tarkoitettu käytettäviksi vastaavien libdrmkääretoimintojen kautta . Lisäksi ohjaimet vievät laitekohtaisia ​​käyttöliittymiä käyttäjätila-ajureiden ja laitetietoisten sovellusten käyttöön ioctls- ja sysfs- tiedostojen kautta. Ulkoisia rajapintoja ovat: muistin kartoitus, kontekstinhallinta, DMA -toiminnot, AGP -hallinta, vblank -ohjaus, aidanhallinta , muistinhallinta ja tulostenhallinta .

DRM-Master ja DRM-Auth

DRM-sovellusliittymässä on useita toimintoja (ioctls), jotka joko turvallisuustarkoituksiin tai samanaikaisuusongelmiin on rajoitettava, jotta niitä voi käyttää yksi käyttäjätilaprosessi laitetta kohden. Tämän rajoituksen toteuttamiseksi DRM rajoittaa tällaiset ioctls-kutsut vain prosessiin, jota pidetään DRM-laitteen, yleensä nimeltään DRM-Master, "isäntänä" . Vain yhden prosessin, jossa laitteen solmu on avattu, tiedoston kahva on merkitty päälliköksi, erityisesti ensimmäinen kutsu SET_MASTER ioctl. Kaikki yritykset käyttää yhtä näistä rajoitetuista yhteyskäytännöistä olematta DRM-Master, palauttavat virheen. Prosessi voi myös luopua pääroolistaan ​​- ja antaa toisen prosessin hankkia sen - kutsumalla DROP_MASTER ioctl. /dev/dri/cardX

X Server -tai muulla näyttö palvelin -on yleisesti prosessia, joka hankkii DRM-Master asema kaikissa DRM laitteessa se onnistuu, yleensä kun se avaa vastaavan laitteen solmun aikana käynnistyksen, ja pitää näitä oikeuksia koko graafisen istuntoon saakka se loppuu tai kuolee.

Muille käyttäjätilaprosesseille on toinen tapa saada etuoikeus kutsua joitakin rajoitettuja toimintoja DRM-laitteessa nimeltä DRM-Auth . Se on pohjimmiltaan menetelmä todennusta vastaan ​​DRM-laitetta vastaan ​​todistaakseen sille, että prosessilla on DRM-Masterin lupa saada tällaiset oikeudet. Menettely koostuu seuraavista:

• Asiakas saa ainutlaatuisen tunnuksen-32-bittisen kokonaisluvun-DRM-laitteelta GET_MAGIC ioctl -palvelun avulla ja välittää sen DRM-Master-prosessille millä tahansa tavalla (yleensä jonkinlainen IPC ; esimerkiksi DRI2: ssa on DRI2Authenticate- pyyntö minkä tahansa X -asiakas voi lähettää X -palvelimelle.)
• DRM-Master-prosessi puolestaan ​​lähettää tunnuksen takaisin DRM-laitteelle kutsumalla AUTH_MAGIC ioctl.
• Laite myöntää erityisiä oikeuksia prosessitiedoston kahvalle, jonka todennustunnus vastaa DRM-Masterilta vastaanotettua tunnusta.

Grafiikan suorituspäällikkö

Koska kasvava koko näyttömuistia ja kasvava monimutkaisuus grafiikkaa API kuten OpenGL , strategia uudelleenalustuksella näytönohjaimen valtiolle kussakin tilanteessa kytkin oli liian kallis, suorituskyky-viisasta. Lisäksi nykyaikaiset Linux-työpöydät tarvitsivat optimaalisen tavan jakaa näytön ulkopuoliset puskurit yhdistelmähallinnan kanssa . Nämä vaatimukset johtivat uusien menetelmien hallita piirroksia puskureita sisällä ydin. Graphics Execution Manager (GEM) tullut yksi näistä menetelmistä.

GEM tarjoaa sovellusliittymän, jossa on nimenomaiset muistinhallinnan primitiivit. GEM: n kautta käyttäjätilaohjelma voi luoda, käsitellä ja tuhota GPU-videomuistissa olevia muistiobjekteja. Nämä objektit, joita kutsutaan "GEM-objekteiksi", ovat pysyviä käyttäjätilaohjelman näkökulmasta, eikä niitä tarvitse ladata uudelleen aina, kun ohjelma saa hallinnan GPU: sta. Kun käyttäjätilaohjelma tarvitsee osan videomuistista ( kehyksen puskurin , tekstuurin tai muun GPU: n vaatiman tiedon tallentamiseksi), se pyytää varaamista DRM-ohjaimelle GEM-sovellusliittymän avulla. DRM -ohjain pitää kirjaa käytetystä videomuistista ja pystyy täyttämään pyynnön, jos muistia on vapaana, palauttamalla "kahvan" käyttäjätilaan viitatakseen edelleen varattuun muistiin tulevissa toiminnoissa. GEM API tarjoaa myös toimintoja puskurin täyttämiseksi ja sen vapauttamiseksi, kun sitä ei enää tarvita. Muisti julkaisemattomista GEM-kahvoista palautuu, kun käyttäjätilaprosessi sulkee DRM-laitteen tiedostotiedoston- tahattomasti tai sen vuoksi.

GEM mahdollistaa myös kahden tai useamman käyttäjätilaprosessin, jotka käyttävät samaa DRM-laitetta (siis samaa DRM-ohjainta) GEM-objektin jakamiseen. GEM-kahvat ovat paikallisia 32-bittisiä kokonaislukuja, jotka ovat ainutlaatuisia prosessille, mutta toistettavissa muissa prosesseissa, joten ne eivät sovellu jakamiseen. Tarvitaan maailmanlaajuinen nimitila, ja GEM tarjoaa sellaisen käyttämällä GEM -nimisiä globaaleja kahvoja . GEM-nimi viittaa yhteen ja vain yhteen GEM-objektiin, joka on luotu samassa DRM-laitteessa saman DRM-ohjaimen avulla käyttämällä ainutlaatuista 32-bittistä kokonaislukua . GEM tarjoaa toiminnan flink saada GEM nimi GEM kahvasta. Prosessi voi sitten siirtää tämän GEM-nimen (32-bittinen kokonaisluku) toiselle prosessille käyttämällä mitä tahansa käytettävissä olevaa IPC- mekanismia. Vastaanottajaprosessi voi käyttää GEM -nimeä paikallisen GEM -kahvan saamiseksi, joka osoittaa alkuperäiseen GEM -objektiin.

Valitettavasti GEM -nimien käyttö puskureiden jakamiseen ei ole turvallista. Haitallinen kolmannen osapuolen prosessi, joka käyttää samaa DRM-laitetta, voi yrittää arvata muiden kahden prosessin jakaman puskurin GEM-nimen yksinkertaisesti tutkimalla 32-bittisiä kokonaislukuja. Kun GEM -nimi on löydetty, sen sisältöön pääsee käsiksi ja sitä voidaan muuttaa, mikä rikkoo puskurin tietojen luottamuksellisuutta ja eheyttä . Tämä haitta voitettiin myöhemmin ottamalla DMA-BUF- tuki DRM: ään, koska DMA-BUF edustaa puskureita käyttäjätilassa tiedostojen kuvajina, jotka voidaan jakaa turvallisesti .

Toinen tärkeä tehtävä mille tahansa videomuistin hallintajärjestelmälle videomuistitilan hallinnan lisäksi on GPU: n ja suorittimen välisen muistin synkronoinnin käsittely. Nykyiset muistiarkkitehtuurit ovat hyvin monimutkaisia ​​ja sisältävät yleensä eri tason välimuisteja järjestelmämuistille ja joskus myös videomuistille. Siksi videomuistin hallitsijoiden tulisi myös käsitellä välimuistin johdonmukaisuutta varmistaakseen, että CPU: n ja GPU: n välillä jaetut tiedot ovat johdonmukaisia. Tämä tarkoittaa, että usein videomuistin hallinnan sisäiset osat ovat suuresti riippuvaisia ​​grafiikkasuorittimen ja muistiarkkitehtuurin laitteistotiedoista ja siten ohjainkohtaisista.

Intelin insinöörit kehittivät GEM: n alun perin tarjoamaan videomuistin hallinnan i915-ohjaimelleen. Intel GMA 9xx perheen integroidut näytönohjaimet Uniform Memory Architecture (UMA), jossa GPU ja CPU osuus fyysisestä muistista, ja ei ole oma VRAM. GEM määrittelee "muistialueet" muistin synkronointia varten, ja vaikka nämä muistialueet ovat GPU-riippumattomia, ne on suunniteltu erityisesti UMA-muistiarkkitehtuuria ajatellen, mikä tekee niistä vähemmän sopivia muille muistiarkkitehtuureille, kuten erilliselle VRAM-muistille. Tästä syystä muut DRM-ohjaimet ovat päättäneet altistaa käyttäjätilaohjelmille GEM-sovellusliittymän, mutta sisäisesti he ottivat käyttöön toisen muistinhallinnan, joka sopii paremmin heidän laitteistoonsa ja muistiarkkitehtuuriinsa.

GEM-sovellusliittymä tarjoaa myös ioctls-ohjelmia suoritusvirran hallintaan (komentopuskurit), mutta ne ovat Intel-erityisiä, ja niitä käytetään Intel i915: n ja uudempien GPU: iden kanssa. Kukaan muu DRM-ohjain ei ole yrittänyt toteuttaa mitään GEM-sovellusliittymän osaa muistinhallintakohtaisten ioctl-tiedostojen lisäksi.

Käännöstaulukot

Translation Table Maps (TTM) on ennen GEM: ää kehitetyn GPU: n yleisen muistinhallinnan nimi. Se on suunniteltu erityisesti hallita erilaisia muistia GPU voisi käyttää myös omistettu video RAM (yleisesti asennettu näytönohjain) ja järjestelmän muistin kautta saatavat I / O-muistinhallintayksikköä kutsutaan Graphics Osoite remapping taulukko (GART) . TTM: n tulisi myös käsitellä niitä video-RAM-muistin osia, joita suoritin ei voi suoraan osoittaa, ja tehdä se parhaalla mahdollisella suorituskyvyllä, kun otetaan huomioon, että käyttäjätilan grafiikkasovellukset toimivat tyypillisesti suurilla videotiedoilla. Toinen tärkeä asia oli säilyttää johdonmukaisuus eri muistojen ja välimuistien välillä.

TTM: n pääkäsite ovat "puskuriobjektit", videomuistialueet, jotka GPU: n on jossakin vaiheessa osoitettava. Kun käyttäjätilan grafiikkasovellus haluaa pääsyn tiettyyn puskuriobjektiin (yleensä sen täyttämiseksi sisällöllä), TTM saattaa vaatia sen siirtämistä muistin tyyppiin, jonka CPU voi osoittaa. Muita siirtoja - tai GART -kartoitustoimintoja - voi tapahtua, kun grafiikkasuoritin tarvitsee pääsyn puskuriobjektiin, mutta se ei ole vielä GPU: n osoitetilassa. Kunkin näistä siirtotoimista on käsiteltävä kaikki asiaan liittyvät tiedot ja välimuistin yhtenäisyysongelmat.

Toinen tärkeä TTM -konsepti on aidat . Aidat ovat pohjimmiltaan mekanismi CPU: n ja GPU: n välisen samanaikaisuuden hallitsemiseksi. Aita seuraa, kun GPU ei enää käytä puskuriobjektia, yleensä ilmoittamaan kaikille käyttäjätilaprosesseille, joilla on pääsy siihen.

Se, että TTM yritti hallita kaikenlaisia ​​muistiarkkitehtuureja, myös niitä, joilla on oma VRAM ja ilman sitä, sopivalla tavalla ja tarjota kaikki mahdolliset ominaisuudet muistinhallinnassa käytettäväksi minkä tahansa tyyppisten laitteiden kanssa, johti liian monimutkaiseen ratkaisu, jonka sovellusliittymä on paljon suurempi kuin tarvitaan. Jotkut DRM -kehittäjät ajattelivat, että se ei sovi hyvin mihinkään tiettyyn ohjaimeen, erityisesti sovellusliittymään. Kun GEM: stä tuli yksinkertaisempi muistinhallinta, sen API oli parempi kuin TTM. Jotkut kuljettajakehittäjät kuitenkin katsoivat, että TTM: n lähestymistapa sopi paremmin erillisille videokorteille, joissa on oma videomuisti ja IOMMU, joten he päättivät käyttää TTM: ää sisäisesti paljastamalla puskuriobjektinsa GEM -objekteina ja siten tukemalla GEM -sovellusliittymää. Esimerkkejä nykyisistä ohjaimista, jotka käyttävät TTM: ää sisäisenä muistinhallintana, mutta tarjoavat GEM -sovellusliittymän, ovat AMD -näytönohjainten radeon -ohjain ja NVIDIA -näytönohjainten uusi ajuri.

DMA -puskurin jakaminen ja PRIME

DMA Buffer Sharing API (lyhennetään usein DMA-BUF) on Linux-ytimen sisäinen API suunniteltu tarjoamaan yleinen mekanismi osake DMA puskureita useisiin laitteisiin, mahdollisesti hallinnoi erityyppisiä laiteohjaimet. Esimerkiksi Video4Linux- laite ja näytönohjainlaite voivat jakaa puskureita DMA-BUF: n kautta, jotta ensimmäisen videon tuottaman ja jälkimmäisen käyttämän videovirran tiedoista ei saada kopioita . Mikä tahansa Linux -laiteajuri voi toteuttaa tämän sovellusliittymän viejänä, käyttäjänä (kuluttajana) tai molempina.

Tätä ominaisuutta hyödynnettiin ensimmäistä kertaa DRM: ssä toteuttaakseen PRIME-ratkaisun, joka on GPU-purkuratkaisu, joka käyttää DMA-BUF: ää jakamaan tuloksena olevat kehyspuskurit erillisen ja integroidun GPU: n DRM-ohjainten välillä. DMA-BUF: n tärkeä piirre on, että jaettu puskuri esitetään käyttäjätilalle tiedoston kuvaajana . PRIME: n kehittämistä varten DRM-sovellusliittymään lisättiin kaksi uutta ioctlia, yksi paikallisen GEM-kahvan muuntamiseksi DMA-BUF-tiedoston kuvaajaksi ja toinen aivan päinvastaista toimintaa varten.

Näitä kahta uutta ioctlia käytettiin myöhemmin uudelleen keinona korjata GEM -puskurin jakamisen luontainen turvattomuus. Toisin kuin GEM -nimet, tiedostojen kuvaajia ei voi arvata (ne eivät ole maailmanlaajuinen nimitila), ja Unix -käyttöjärjestelmät tarjoavat turvallisen tavan siirtää ne Unix -toimialustan kautta SCM_RIGHTS -semantiikan avulla. Prosessi, joka haluaa jakaa GEM-objektin toisen prosessin kanssa, voi muuntaa paikallisen GEM-kahvansa DMA-BUF-tiedoston kuvaajaksi ja välittää sen vastaanottajalle, joka puolestaan ​​voi saada oman GEM-kahvansa vastaanotetusta tiedoston kuvauksesta. Tätä menetelmää käyttää DRI3 puskureiden jakamiseen asiakkaan ja X -palvelimen välillä sekä myös Wayland .

Ytimen tilan asetus

Käyttäjätilassa on oltava "DRM-master", tällä ohjelmalla on yksinoikeus käyttää KMS: ää.

Jotta videokortti tai näytönohjain toimisi kunnolla, sen on asetettava tila - näytön resoluution , värisyvyyden ja virkistystaajuuden yhdistelmä - joka on itse ja siihen liitetyn näytön tukemien arvojen rajoissa . Tätä toimintoa kutsutaan tilan asetukseksi , ja se vaatii yleensä raakakäyttöä grafiikkalaitteistoon-eli kykyä kirjoittaa tiettyihin näytönohjaimen rekistereihin. Tilan asetustoiminto on suoritettava ennen kehyksen puskurin käytön aloittamista ja myös silloin, kun sovellus tai käyttäjä vaatii tilan vaihtamista.

Alkuaikoina graafisen kehyksen puskurin käyttävät käyttäjätilaohjelmat olivat myös vastuussa tilan asettamistoimintojen tarjoamisesta, ja siksi niiden oli suoritettava etuoikeutettu käyttöoikeus videolaitteistoon. Unix-tyyppisissä käyttöjärjestelmissä X Server oli näkyvin esimerkki, ja sen tila-asetusten toteutus asui DDX-ohjaimessa kullekin videokorttityypille. Tämä lähestymistapa, josta myöhemmin käytetään nimitystä User Space Mode-Setting tai UMS, aiheuttaa useita ongelmia. Se ei ainoastaan ​​riko käyttöjärjestelmien tarjoamaa eristystä ohjelmien ja laitteistojen välillä, mikä nostaa esiin sekä vakautta että turvallisuutta koskevia huolenaiheita, mutta voi myös jättää grafiikkalaitteiston epäjohdonmukaiseen tilaan, jos kaksi tai useampi käyttäjätilaohjelma yrittää tehdä tilan samaan aikaan. Näiden ristiriitojen välttämiseksi X Serveristä tuli käytännössä ainoa käyttäjätilaohjelma, joka suoritti tilan asetustoimintoja; loput käyttäjätilaohjelmat luottivat X-palvelimeen sopivan tilan asettamisessa ja kaikkien muiden tilan asettamiseen liittyvien toimintojen käsittelyssä. Aluksi tilan asetus tehtiin yksinomaan X-palvelimen käynnistysprosessin aikana, mutta myöhemmin X-palvelin sai mahdollisuuden tehdä se ajon aikana. XFree86-VidModeExtension laajennus otettiin käyttöön vuonna XFree86 3.1.2 anna mitään X toimeksiantokohtaisesti modeline (resoluutio) vaihtuu X Server. VidMode -laajennus korvattiin myöhemmin yleisemmällä XRandR -laajennuksella.

Tämä ei kuitenkaan ollut ainoa koodi, joka asettaa tilan asettamisen Linux- järjestelmässä. Järjestelmän latauksen aikana prosessissa, Linux-ytimeen on asetettava minimaalinen tekstitilan varten virtuaalikonsoliin (perustuu standardiin tilat määritellään VESA BIOS laajennukset). Myös Linux-ytimen kehyspuskuriohjain sisälsi tilan asetuskoodin kehyspuskurilaitteiden määrittämiseksi. Välttääkseen tilan asetusten ristiriidat XFree86-palvelin- ja myöhemmin X.Org-palvelin- käsitteli tapauksen, kun käyttäjä siirtyi graafisesta ympäristöstä tekstivirtaali- konsoliin tallentamalla tilan asetustila ja palauttamalla se, kun käyttäjä vaihtoi takaisin X: ään. Tämä prosessi aiheutti ärsyttävää välkkymistä siirtymävaiheessa ja voi myös epäonnistua, mikä johtaa vioittuneeseen tai käyttökelvottomaan tulostusnäyttöön.

Käyttäjätilatilan asettamismenetelmä aiheutti myös muita ongelmia:

• Keskeyttää / jatkaa prosessia on turvauduttava käyttäjän tilaa työkaluja palauttaa edelliseen tilaan. Yksi näiden ohjelmien vika tai kaatuminen voi jättää järjestelmän ilman toimivaa näyttöä tilaasetusten virheellisten asetusten vuoksi ja siksi käyttökelvottomia.
• Ytimen oli myös mahdotonta näyttää virhe- tai virheenkorjausviestejä, kun näyttö oli grafiikkatilassa - esimerkiksi X: n ollessa käynnissä -, koska ainoat tilat, joista ydin tiesi, olivat VESA BIOS -standardit.
• Kiireellisempi ongelma oli X-palvelimen ohittavien graafisten sovellusten lisääntyminen ja muiden X-grafiikkapino-vaihtoehtojen syntyminen, mikä laajensi tilan asetuskoodin päällekkäisyyttä koko järjestelmässä.

Näiden ongelmien ratkaisemiseksi tilan asetuskoodi siirrettiin yhteen paikkaan ytimen sisällä, erityisesti olemassa olevaan DRM-moduuliin. Sitten jokaisen prosessin-myös X-palvelimen-pitäisi pystyä antamaan ytimelle tila-asetustoiminnot, ja ydin varmistaa, että samanaikaiset toiminnot eivät johda epäjohdonmukaiseen tilaan. Uutta ytimen sovellusliittymää ja koodia, jotka lisättiin DRM-moduuliin näiden tila-asetustoimintojen suorittamiseksi, kutsuttiin Kernel Mode-Settingiksi (KMS).

Kernel Mode-Setting tarjoaa useita etuja. Välitön on tietysti päällekkäisten moodin asetuskoodien poistaminen sekä ytimestä (Linux-konsoli, fbdev) että käyttäjätilasta (X Server DDX -ohjaimet). KMS helpottaa myös vaihtoehtoisten grafiikkajärjestelmien kirjoittamista, joiden ei nyt tarvitse ottaa käyttöön omaa tila-asetuskoodia. Tarjoamalla keskitetyn tilanhallinnan KMS ratkaisee välkkyvät ongelmat, kun se vaihtaa konsolin ja X: n välillä sekä myös X: n (nopea käyttäjän vaihto) välillä. Koska se on saatavana ytimessä, sitä voidaan käyttää myös käynnistysprosessin alussa, mikä säästää välkkymistä, joka johtuu tilanvaihdoksista näissä alkuvaiheissa.

Se tosiasia, että KMS on osa ydintä, sallii sen käyttää vain ydintilassa olevia resursseja, kuten keskeytyksiä . Esimerkiksi tilan palautus keskeytys-/jatkamisprosessin jälkeen yksinkertaistaa paljon, koska ydin hallitsee sitä itse ja parantaa tietoturvaa (ei enää käyttäjätilityökaluja, jotka edellyttävät pääkäyttäjän oikeuksia). Ydin mahdollistaa myös uusien näyttölaitteiden hotplugin helposti ja ratkaisee pitkäaikaisen ongelman. Tilan asettaminen liittyy myös läheisesti muistinhallintaan-koska kehyspuskurit ovat pohjimmiltaan muistipuskureita-, joten tiivistä integrointia grafiikkamuistin hallintaan suositellaan. Tämä on tärkein syy siihen, miksi ytimen tilan asetuskoodi sisällytettiin DRM: ään eikä erilliseksi osajärjestelmäksi.

Välttää rikkoutuminen taaksepäin yhteensopivuus DRM API, Kernel Mode Setting palvelee lisäksi kuljettaja ominaisuus tiettyjen DRM kuljettajia. Jokainen DRM -ohjain voi halutessaan antaa DRIVER_MODESET -lipun rekisteröidessään DRM -ytimen osoittaakseen, että se tukee KMS -sovellusliittymää. Niitä ohjaimia, jotka käyttävät ytimen tilan asetusta, kutsutaan usein KMS-ohjaimiksi erottaakseen ne vanhoista DRM-ajureista ilman KMS: ää.

KMS on otettu käyttöön siinä määrin, että tietyt ohjaimet, joilla ei ole 3D -kiihdytystä (tai joiden laitteistotoimittaja ei halua paljastaa tai ottaa sitä käyttöön), toteuttavat kuitenkin KMS -sovellusliittymän ilman muuta DRM -sovellusliittymää.

KMS -laitteen malli

KMS malleja ja hallinnoi tulostuslaitteet sarjana abstrakteja laitteistolohkoja yhteisesti todettu näyttökohteeksi putki on näytönohjain . Nämä lohkot ovat:

• CRTC : t : jokainen CRTC ( CRT -ohjaimesta) edustaa näytön ohjaimen skannausmoottoria , joka osoittaa skannauspuskuriin ( kehyspuskuri ). Tarkoituksena CRTC on lukea kuvapistedataa tällä hetkellä scanout puskuriin ja generoimaan siitä video-tilassa ajoitussignaalin avulla on PLL-piirin . Käytettävissä olevien CRTC-määrien määrä määrittää, kuinka monta itsenäistä tulostuslaitetta laitteisto pystyy käsittelemään samanaikaisesti, joten usean pään kokoonpanojen käyttämiseksi vaaditaan vähintään yksi CRTC näyttölaitetta kohden. Kaksi-tai enemmän-CRTCs voi myös työtä Kloonitilassa jos ne skannaamaan ulos samasta ruutupuskurointia lähettää saman kuvan useita output-laitteet.
• Liittimet : liitin osoittaa, missä näytön ohjain lähettää videosignaalin näytettävästä skannaustoiminnosta. Yleensä liitännän KMS-käsite vastaa fyysistä liitintä ( VGA , DVI , FPD-Link , HDMI , DisplayPort , S-Video , ...) laitteistossa, jossa lähtölaite ( näyttö , kannettavan tietokoneen paneeli, ... ) on pysyvästi tai voidaan liittää väliaikaisesti. Liittimeen tallennetaan myös nykyiseen fyysisesti liitettyyn lähtölaitteeseen liittyvät tiedot, kuten yhteyden tila, EDID -tiedot, DPMS -tila tai tuetut videotilat.
• Kooderit : näytön ohjaimen on koodattava CRTC: n videotilan ajoitussignaali aiotulle liittimelle sopivassa muodossa. Kooderi edustaa laitteistolohkoa, joka pystyy suorittamaan yhden näistä koodauksista. Esimerkkejä digitaalisten lähtöjen koodauksista ovat TMDS ja LVDS ; analogisille lähdöille, kuten VGA- ja TV -lähtöille , käytetään yleensä erityisiä DAC -lohkoja. Liitin voi vastaanottaa signaalin vain yhdestä enkooderista kerrallaan, ja jokainen liitäntätyyppi tukee vain joitakin koodauksia. Saattaa myös olla muita fyysisiä rajoituksia, joilla kaikkia CRTC: itä ei ole kytketty kaikkiin käytettävissä oleviin anturiin, mikä rajoittaa CRTC-anturiliittimen mahdollisia yhdistelmiä.
• Lentokoneet : kone ei ole laitteistolohko, vaan muistiobjekti, joka sisältää puskurin, josta syötetään skannausmoottori (CRTC). Kone, joka pitää ruutupuskurointia kutsutaan ensisijainen kone , ja jokainen CRTC oltava yksi liittyy, koska se lähde CRTC määrittää videotilaan-näytön resoluutio (leveys ja korkeus), pikselikoko, pikselin, virkistystaajuus, jne. CRTC: hen voi olla liitetty myös kohdistintason, jos näytönohjain tukee laitteistokursorin peittokuvia, tai toissijaisia ​​tasoja, jos se pystyy skannaamaan lisälaitteistokerroksista ja säveltämään tai sekoittamaan "lennossa" lopullisen kuvan, joka lähetetään lähtöön laite.

Atominäyttö

Viime vuosina on jatkuvasti pyritty tuomaan atomisuutta joihinkin KMS -sovellusliittymään liittyviin säännöllisiin toimintoihin, erityisesti tilan asetuksiin ja sivun kääntötoimintoihin . Tätä parannettua KMS-sovellusliittymää kutsutaan Atomic Display -näytöksi (tunnettiin aiemmin nimellä atomitila-asetus ja atomi- tai ydinsivun kääntö ).

Tarkoitus atomi tila-asetus on varmistaa oikea muutos tilassa monimutkaisia kokoonpanoja, joissa on useita rajoituksia, välttämällä välivaiheita, jotka voisivat johtaa epäjohdonmukaisia tai virheellinen video tilassa; se välttää myös riskialttiit videotilat, kun epäonnistunut tilan asetusprosessi on kumottava ("palautus"). Atomitilan asettaminen antaa mahdollisuuden tietää etukäteen, onko tietty tilakokoonpano sopiva, tarjoamalla tilan testausominaisuuksia. Kun atomitila testataan ja sen pätevyys vahvistetaan, sitä voidaan soveltaa yhdellä jakamattomalla (atomi) sitoutumisoperaatiolla . Sekä testi- että suoritustoiminnot tarjoaa sama uusi ioctl eri lipuilla.

Atomisivun kääntö toisaalta sallii päivittää useita tasoja samaan lähtöön (esimerkiksi ensisijainen taso, kohdistustaso ja ehkä joitain peittokuvia tai toissijaisia ​​tasoja), jotka kaikki synkronoidaan samalla VBLANK -aikavälillä , mikä takaa oikean näytön ilman repeytymistä. Tämä vaatimus koskee erityisesti mobiili- ja sulautettuja näyttöohjaimia, jotka käyttävät yleensä useita tasoja/peittokuvia virran säästämiseksi.

Uusi atomisovellusliittymä perustuu vanhaan KMS -sovellusliittymään. Se käyttää samaa mallia ja objekteja (CRTC: t, enkooderit, liittimet, tasot, ...), mutta yhä useammalla muokattavalla objektiominaisuudella. Atomimenetelmä perustuu asiaankuuluvien ominaisuuksien muuttamiseen testattavan tai sitoutuvan tilan luomiseksi. Ominaisuudet, joita haluamme muokata, riippuvat siitä, haluammeko tehdä tila-asetuksen (lähinnä CRTC: t, enkooderit ja liittimet) vai sivun kääntämisen (yleensä tasojen ominaisuudet). Ioctl on sama molemmissa tapauksissa, ero on luettelo ominaisuuksista, jotka kullekin annetaan.

Render solmut

Alkuperäisessä DRM-sovellusliittymässä DRM-laitetta käytetään sekä etuoikeutetuissa (tilan asettaminen, muu näytön ohjaus) että ei-oikeutetuissa (renderointi, GPGPU- laskenta) -toiminnoissa. Turvallisuussyistä siihen liittyvän DRM-laitetiedoston avaaminen vaatii erityisoikeuksia, jotka vastaavat pääkäyttäjän oikeuksia. Tämä johtaa arkkitehtuuriin, jossa vain joillakin luotettavilla käyttäjätilaohjelmilla (X -palvelimella, graafisella kompostoijalla ...) on täysi pääsy DRM -sovellusliittymään, mukaan lukien etuoikeutetut osat, kuten modeet -sovellusliittymä. Loput käyttäjätilasovellukset, jotka haluavat tehdä tai tehdä GPGPU -laskelmia, tulee myöntää DRM -laitteen omistajan ("DRM Master") käyttämällä erityistä todennusrajapintaa. Sitten todennetut sovellukset voivat tehdä tai tehdä laskelmia käyttämällä DRM -sovellusliittymän rajoitettua versiota ilman etuoikeutettuja toimintoja. Tämä rakenne asettaa vakavan rajoituksen: aina on oltava käynnissä oleva grafiikkapalvelin (X-palvelin, Wayland-komposiitti, ...), joka toimii DRM-laitteen DRM-isäntänä, jotta muille käyttäjätilaohjelmille voidaan myöntää jopa tapauksissa, joissa ei ole grafiikkanäyttöä, kuten GPGPU -laskutoimituksia. /dev/dri/cardX

"Render nodes" -konsepti yrittää ratkaista nämä skenaariot jakamalla DRM-käyttäjätilan sovellusliittymän kahteen rajapintaan-yhden etuoikeutetun ja toisen ei-oikeutetun-ja käyttämällä erillisiä laitetiedostoja (tai "solmuja") kullekin. Jokaista löydettyä GPU: ta vastaava DRM -ohjain - jos se tukee render -solmut -ominaisuutta - luo ensisijaisen solmun lisäksi laitetiedoston , nimeltään render -solmu . Asiakkaat, jotka käyttävät suoraa renderointimallia, ja sovellukset, jotka haluavat hyödyntää GPU: n laskentatoimintoja, voivat tehdä sen ilman lisäoikeuksia yksinkertaisesti avaamalla olemassa olevat renderöintisolmut ja lähettämällä GPU -toiminnot käyttämällä DRM -sovellusliittymän tuettua rajoitettua osajoukkoa nämä solmut - edellyttäen, että niillä on tiedostojärjestelmän käyttöoikeudet avata laitetiedosto. Näyttöpalvelimien, kompostoijien ja muiden ohjelmien, jotka edellyttävät modeet -sovellusliittymää tai muita etuoikeutettuja toimintoja, on avattava tavallinen ensisijainen solmu, joka antaa pääsyn koko DRM -sovellusliittymään, ja käytettävä sitä tavalliseen tapaan. Render -solmut kieltävät nimenomaisesti GEM -flink -toiminnon estääkseen puskurin jakamisen käyttämällä turvattomia GEM -globaaleja nimiä; vain PRIME (DMA-BUF) -tiedoston kuvauksia voidaan käyttää puskureiden jakamiseen toisen asiakkaan kanssa, mukaan lukien grafiikkapalvelin. /dev/dri/renderDX/dev/dri/cardX

Laitteiston tuki

DRM on tarkoitettu käyttäjätilan grafiikkalaitteiden ohjaimille, kuten esim. AMD Catalyst tai Mesa 3D . Käyttäjätilaohjelmat käyttävät Linux-järjestelmäkutsuliitäntää DRM: n käyttämiseen. DRM täydentää Linux -järjestelmäpuhelurajapintaa omilla järjestelmäpuheluillaan.

Linux DRM -alijärjestelmään kuuluu ilmaisia ​​ja avoimen lähdekoodin ohjaimia, jotka tukevat laitteistoja kolmelta pöytätietokoneiden grafiikkasuorittimien valmistajalta (AMD, NVIDIA ja Intel) sekä kasvavalta määrältä mobiili-grafiikkasuorittimia ja sirulla olevia järjestelmiä (SoC) integraattoreita. Jokaisen kuljettajan laatu vaihtelee suuresti riippuen valmistajan yhteistyöasteesta ja muista asioista.

Seuraavassa taulukossa on myös historiallisia tarkoituksia varten useita ajureita vanhoille, vanhentuneille laitteille. Jotkut niistä ovat edelleen ytimen koodissa, mutta toiset on jo poistettu.

Kehitys

Direct Rendering Manager on kehitetty Linux -ytimen sisällä , ja sen lähdekoodi sijaitsee /drivers/gpu/drmLinux -lähdekoodin hakemistossa. Osajärjestelmän ylläpitäjä on Dave Airlie, ja muut ylläpitäjät huolehtivat tietyistä kuljettajista. Kuten tavallista Linux -ytimen kehityksessä, DRM -alihallinnoijat ja avustajat lähettävät korjauksiaan uusilla ominaisuuksilla ja virheenkorjauksilla DRM: n pää ylläpitäjälle, joka integroi ne omaan Linux -arkistoonsa . DRM -ylläpitäjä puolestaan ​​toimittaa kaikki nämä korjaustiedostot, jotka ovat valmiita liitettäväksi Linus Torvaldsille aina, kun uusi Linux -versio julkaistaan. Torvalds, joka on ytimen ylläpitäjä, pitää viimeisen sanan siitä, sopiiko laastari ytimeen.

Historiallisista syistä libdrm -kirjaston lähdekoodi säilytetään Mesa -projektin alla.

Historia

Vuonna 1999, ja samalla kehittää DRI varten XFree86 , Precision Insight loi ensimmäisen version DRM varten 3dfx näytönohjaimet, kuten Linux-ytimen laastari kuuluvat Mesa lähdekoodia. Myöhemmin samana vuonna DRM koodia mainlined Linux-ytimen 02.3.18 alla /drivers/char/drm/hakemiston merkkilaitteille . Seuraavien vuosien aikana tuettujen videokorttien määrä kasvoi. Kun Linux 2.4.0 julkaistiin tammikuussa 2001, se tuki jo Creative Labs GMX 2000-, Intel i810-, Matrox G200/G400- ja ATI Rage 128 -laitteita 3dfx Voodoo3 -korttien lisäksi, ja luettelo laajeni 2.4.x -sarjan aikana, ohjainten ATI Radeon -kortit, jotkut SiS näytönohjaimet ja Intel 830M ja myöhemmin integroitu GPU.

DRM: n jakaminen kahteen komponenttiin, DRM -ydin ja DRM -ajuri, nimeltään DRM -ydin/persoonallisuusjako, tehtiin vuoden 2004 jälkipuoliskolla ja yhdistettiin ytimen versioon 2.6.11. Tämä jako mahdollisti useiden DRM-ajureiden toimimisen useille laitteille samanaikaisesti, mikä avasi tien useille GPU-tuille.

Ajatus kaikkien videotilan asetuskoodien sijoittamisesta yhteen paikkaan ytimen sisällä oli tunnustettu jo vuosia, mutta näytönohjainten valmistajat olivat väittäneet, että ainoa tapa tehdä tila-asetus oli käyttää itse tarjoamiaan rutiineja. Video BIOS kunkin näytönohjain. Tällainen koodi oli suoritettava käyttämällä todellista x86 -tilaa , mikä esti suojatussa tilassa toimivan ytimen kutsumisen siihen . Tilanne muuttui, kun Luc Verhaegen ja muut kehittäjät löysivät tavan tehdä tilan asetus natiivisti BIOS-pohjaisen sijasta, mikä osoitti, että se oli mahdollista tehdä käyttämällä normaalia ytimen koodia ja loi pohjan ytimen tilan asetukselle . Toukokuussa 2007 Jesse Barnes ( Intel ) julkaisi ensimmäisen ehdotuksen drm-modeetting- sovellusliittymästä ja toimivasta natiivitoteutuksesta Intelin grafiikkasuorittimien tilan asetukselle i915 DRM -ohjaimessa. Joulukuussa 2007 Jerome Glisse alkoi lisätä ATI-korttien natiivitilan asetuskoodia radeon DRM -ohjaimeen. Sekä sovellusliittymän että ohjainten työ jatkui vuoden 2008 aikana, mutta viivästyi, koska muistinhallinta oli välttämätöntä myös ydintilassa kehyksen puskurien käsittelemiseksi.

Lokakuussa 2008 Linux -ydin 2.6.27 toi suuren lähdekoodin uudelleenjärjestelyn ennen joitakin merkittäviä tulevia muutoksia. DRM -lähdekoodipuu siirrettiin omaan lähdehakemistoonsa /drivers/gpu/drm/ja eri ohjaimet siirrettiin omiin alihakemistoihin. Otsikot siirrettiin myös uuteen /include/drmhakemistoon.

Videomuistin hallinnan kasvava monimutkaisuus johti useisiin lähestymistapoihin tämän ongelman ratkaisemiseksi. Ensimmäinen yritys oli Translation Table Maps (TTM) -muistinhallinta, jonka on kehittänyt Thomas Hellstrom ( Tungsten Graphics ) yhteistyössä Emma Anholtin (Intel) ja Dave Airlien ( Red Hat ) kanssa. TTM: ää ehdotettiin sisällytettäväksi päälinjan ytimeen 2.6.25 marraskuussa 2007 ja jälleen toukokuussa 2008, mutta se hylättiin uuden lähestymistavan nimeltä Graphics Execution Manager (GEM). Intelin Keith Packard ja Emma Anholt kehittivät GEM: n ensin yksinkertaisemmaksi ratkaisuksi muistinhallintaan i915 -ohjaimelleen. GEM otettiin hyvin vastaan ​​ja se sulautettiin joulukuussa 2008 julkaistuun Linux -ytimen versioon 2.6.28. Samaan aikaan TTM joutui odottamaan syyskuuhun 2009 asti, jotta se lopulta sulautettiin Linux 2.6.31: een uuden Radeon KMS DRM -ohjaimen vaatimuksena.

Kun muistinhallinta on käytössä puskuriobjektien käsittelemiseksi, DRM -kehittäjät voisivat viimein lisätä ytimeen jo valmiiksi valmistetun sovellusliittymän ja kooditoiminto -asetuksen . Tätä laajennettua sovellusliittymää kutsutaan ytimen tilan asetukseksi (KMS), ja sen toteuttavia ohjaimia kutsutaan usein KMS-ohjaimiksi . Maaliskuussa 2009 KMS yhdistettiin Linux -ytimen versioon 2.6.29 yhdessä iMS15 -ohjaimen KMS -tuen kanssa. KMS -sovellusliittymä on ollut alttiina käyttäjätilaohjelmille libdrm 2.4.3: n jälkeen. Käyttäjätilojen X.Org DDX -ohjain Intel -näytönohjaimille oli myös ensimmäinen, joka käytti uusia GEM- ja KMS -sovellusliittymiä. KMS-tuki radeon DRM -ohjaimelle lisättiin Linux 2.6.31 -julkaisuun syyskuussa 2009. Uusi radeon KMS -ohjain käytti TTM-muistinhallintaa, mutta paljasti GEM-yhteensopivia käyttöliittymiä ja ioctleja TTM-käyttöliittymien sijaan.

Vuodesta 2006 nouveau -projekti oli kehittänyt ilmaisen ohjelmiston DRM -ohjaimen NVIDIA -näytönohjaimille virallisen Linux -ytimen ulkopuolelle. Vuonna 2010 nouveau -lähdekoodi yhdistettiin kokeelliseksi ajuriksi Linux 2.6.33: een. Sulautumisen yhteydessä ohjain oli jo muunnettu KMS: ksi, ja GEM -sovellusliittymän takana se käytti TTM: ää muistinhallintana.

Uusi KMS -sovellusliittymä - mukaan lukien GEM -sovellusliittymä - oli suuri virstanpylväs DRM: n kehittämisessä, mutta se ei estänyt sovellusliittymän parantamista seuraavina vuosina. KMS sai tukea sivun käännöksille yhdessä asynkronisten VBLANK -ilmoitusten kanssa Linuxissa 2.6.33 - vain i915 -ohjaimelle, radeon ja nouveau lisäsivät sen myöhemmin Linuxin 2.6.38 julkaisun aikana. Uusi sivun kääntöliittymä lisättiin libdrm 2.4.17: een. Vuoden 2011 alussa, Linux 2.6.39 -julkaisusyklin aikana, KMS-sovellusliittymään lisättiin niin sanotut tyhmät puskurit- laitteistosta riippumaton ei-kiihdytetty tapa käsitellä yksinkertaisia ​​puskureita, jotka soveltuvat käytettäväksi kehyksen puskureina. Tavoitteena oli vähentää Plymouthin kaltaisten sovellusten monimutkaisuutta, joiden ei tarvitse käyttää kuljettajakohtaisten ioctlien tarjoamia nopeutettuja erityistoimintoja. Ominaisuuden paljasti libdrm versiosta 2.4.25 alkaen. Myöhemmin samana vuonna se sai myös uuden päätyypin esineitä, nimeltään lentokoneita . Lentokoneita kehitettiin edustamaan skannausmoottorin tukemia laitteistokerroksia. Lentokoneen tuki yhdistettiin Linuxiin 3.3. ja libdrm 2.4.30. Toinen sovellusliittymään lisätty käsite - Linux 3.5- ja libdrm 2.4.36 -julkaisujen aikana - olivat yleiset objektiominaisuudet , menetelmä lisätä yleisiä arvoja mihin tahansa KMS -objektiin. Ominaisuudet ovat erityisen hyödyllisiä määritettäessä erityistä käyttäytymistä tai ominaisuuksia objekteille, kuten CRTC: lle ja tasolle.

Dave Airlie kehitti varhaisen todistuksen konseptista, joka tarjoaa GPU -purkamisen DRM -ajureiden välillä vuonna 2010. Koska Airlie yritti jäljitellä NVIDIA Optimus -tekniikkaa, hän päätti antaa sille nimen "PRIME". Airlie jatkoi työskentelyään PRIME-ohjelmassa vuoden 2011 lopulla, mutta perustuu uuteen DMA-BUF- puskurinjakomekanismiin, jonka Linux-ydin 3.3 esitteli. Perus DMA-BUF PRIME -infrastruktuuri valmistui maaliskuussa 2012 ja yhdistettiin Linux 3.4 -versioon sekä libdrm 2.4.34 -versioon. Myöhemmin Linux 3.5 -julkaisun aikana useat DRM -ohjaimet ottivat käyttöön PRIME -tuen, mukaan lukien i915 Intel -kortille, radeon AMD -kortille ja nouveau NVIDIA -kortille.

Viime vuosina DRM -sovellusliittymä on vähitellen laajentunut uusilla ja parannetuilla ominaisuuksilla. Vuonna 2013 osana GSoC : ta David Herrmann kehitti usean render -solmun ominaisuuden. Hänen koodinsa lisättiin Linux -ytimen versioon 3.12 kokeellisena ominaisuutena, jota tukevat i915-, radeon- ja nouveau -ohjaimet, ja se on oletuksena käytössä Linux 3.17: n jälkeen. Vuonna 2014 Matt Roper (Intel) kehitti universaalitasojen (tai yhtenäistettyjen lentokoneiden ) konseptin, jonka mukaan kehyksenpuskureita ( ensisijaisia ​​tasoja ), peittokuvia ( toissijaisia ​​tasoja ) ja kohdistimia ( kursoritasoja ) käsitellään yhtä ainoana objektityypinä, jolla on yhtenäinen sovellusliittymä. Universal -lentokoneiden tuki tarjoaa johdonmukaisemman DRM -sovellusliittymän, jossa on vähemmän ja yleisempiä ioctleja . Jotta API pysyisi yhteensopivana taaksepäin , DRM -ydin paljastaa ominaisuuden lisäominaisuutena, jonka DRM -ohjain voi tarjota. Yleinen koneen tuki esiteltiin Linuxissa 3.15 ja libdrm 2.4.55. Useat ohjaimet, kuten Intel i915, ovat jo ottaneet sen käyttöön.

Tuorein DRM API lisälaite on atomi mode-asetus API, joka tuo atomisuuden moodin asettamista ja sivu käännetään toimintansa DRM laitteella. Idea tilan määrittämiseen tarkoitetusta atomisovellusliittymästä ehdotettiin ensimmäisen kerran vuoden 2012 alussa. Ville Syrjälä (Intel) otti tehtävänsä suunnitella ja toteuttaa tällainen atomisovellusliittymä. Rob Clark ( Texas Instruments ) käytti työnsä perusteella samanlaista lähestymistapaa pyrkien toteuttamaan atomisivun kääntöjä. Myöhemmin vuonna 2013 molemmat ehdotetut ominaisuudet yhdistettiin uudelleen yhdeksi yhdellä ioctlilla molempiin tehtäviin. Koska se oli vaatimus, ominaisuus joutui odottamaan yleislentokoneiden tuen yhdistämistä vuoden 2014 puolivälissä. Vuoden 2014 jälkipuoliskolla Daniel Vetter (Intel) ja muut DRM -kehittäjät paransivat atomikoodia huomattavasti helpottaakseen nykyisten KMS -ohjainten siirtymistä uuteen atomikehykseen. Kaikki tämä työ liitettiin lopulta Linux 3.19- ja Linux 4.0 -versioihin ja otettiin käyttöön oletusarvoisesti Linux 4.2: n jälkeen. libdrm paljasti uuden atomisovellusliittymän versiosta 2.4.62 lähtien. Useita ohjaimia on jo muunnettu uuteen atomisovellusliittymään. Vuoteen 2018 mennessä Linux -ytimeen oli lisätty kymmenen uutta tähän uuteen atomimalliin perustuvaa DRM -ohjainta.

Hyväksyminen

Direct Rendering Manager ytimen alijärjestelmä on alunperin kehitetty käytettäväksi uuden Direct Annetaan infrastruktuuri on XFree86 4.0 näytön palvelimelle, myöhemmin peri sen seuraaja, X.Org Server . Siksi DRM: n pääkäyttäjät olivat DRI-asiakkaita, jotka linkittivät Mesa 3D -kirjastossa olevaan laitteistokiihdytettyyn OpenGL- toteutukseen sekä itse X-palvelimeen. Nykyään DRM: ää käyttävät myös useat Wayland -säveltäjät , mukaan lukien Westonin referenssikomposiittori. kmscon on virtuaalikonsolin toteutus, joka toimii käyttäjätilassa DRM KMS -palvelujen avulla.

Vuonna 2015 patentoidun Nvidia GeForce -ohjaimen versio 358.09 (beta) sai tuen DRM-tilan asetusrajapinnalle, joka on toteutettu uutena ytimenä nvidia-modeset.ko. Tämä uusi ohjainkomponentti toimii yhdessä ytimoduulin kanssa nvidia.koGPU: n näyttömoottorin (eli näytönohjaimen) ohjelmoimiseksi.

Katso myös

• Suora renderöintiinfrastruktuuri
• Ilmainen ja avoimen lähdekoodin grafiikkalaiteohjain
• Linux -kehyksenpuskuri

Viitteet

Ulkoiset linkit

• DRM -kotisivu
• Linux -näytönohjaimen ohjaimen kehittäjän opas (aiemmin Linux DRM -kehittäjän opas )
• Sulautettu Linux Conference 2013 - Anatomy of Embedded KMS kuljettaja on YouTubessa