Direkte gengivelsesinfrastruktur - Direct Rendering Infrastructure

Der er to grafikhardwaredrivere: den ene findes inde i X -displayserveren . Der har været flere designs af denne driver. Den nuværende deler den i to dele: DIX (enhedsuafhængig X) og DDX (enhedsafhængig X)

Glamour vil forenkle X-serveren , og libGL-fglrx-glx kunne bruge libDRM fra radeon open-source driveren i stedet for den proprietære binære blob .

Gengivelsesberegninger er outsourcet over OpenGL til GPU'en for at blive udført i realtid. Den DRI regulerer adgangen og bogholderi.

Den Direct Rendering Infrastructure ( DRI ) er en ramme for at tillade direkte adgang til grafik-hardware under X Window System i en sikker, effektiv måde. Hovedanvendelsen af ​​DRI er at levere hardwareacceleration til Mesa -implementeringen af OpenGL . DRI er også blevet tilpasset til at levere OpenGL -acceleration på en framebuffer -konsol uden at en displayserver kører.

DRI -implementering er spredt gennem X Server og dens tilhørende klientbiblioteker, Mesa 3D og Direct Rendering Manager -kerneundersystemet. Hele kildekoden er gratis software .

Oversigt

I den klassiske X Window System -arkitektur er X Server den eneste proces med eksklusiv adgang til grafikhardwaren og derfor den, der udfører den faktiske gengivelse på rammebufferen . Alt, hvad X -klienter gør, er at kommunikere med X Server for at sende renderingskommandoer. Disse kommandoer er hardwareuafhængige, hvilket betyder, at X11 -protokollen giver en API, der abstraherer grafikkenheden, så X -klienterne ikke behøver at vide eller bekymre sig om detaljerne i den underliggende hardware. Enhver hardwarespecifik kode lever inde i Device Dependent X , den del af X Server, der administrerer hver type grafikkort eller grafikkort, og som også ofte kaldes video- eller grafikdriveren .

Stigningen af 3D -gengivelse har vist grænserne for denne arkitektur. 3D -grafikapplikationer har en tendens til at producere store mængder kommandoer og data, som alle skal sendes til X Server for gengivelse. Efterhånden som mængden af interprocesskommunikation (IPC) mellem X-klienten og X Server steg, led 3D-gengivelsesydelsen til det punkt, at X-driverudviklere konkluderede, at for at drage fordel af 3D-hardwarefunktionerne på de nyeste grafikkort blev en ny IPC-mindre arkitektur var påkrævet. X -klienter bør have direkte adgang til grafikhardware i stedet for at stole på en tredjepartsproces for at gøre det, hvilket sparer alle IPC -omkostninger. Denne fremgangsmåde kaldes "direkte gengivelse" i modsætning til den "indirekte gengivelse" leveret af den klassiske X -arkitektur. Den Direct Rendering Infrastructure blev oprindeligt udviklet til at tillade nogen X-klient til at udføre 3D-gengivelse ved hjælp af denne "direkte optegning" tilgang.

Intet forhindrer DRI i at blive brugt til at implementere accelereret 2D direkte gengivelse inden for en X -klient. Ingen har simpelthen haft behov for at gøre det, fordi den indirekte 2D -gengivelse var god nok.

Software arkitektur

Den grundlæggende arkitektur i Direct Rendering Infrastructure omfatter tre hovedkomponenter:

• DRI -klienten - en X -klient, der udfører "direkte gengivelse" - har brug for en hardwarespecifik "driver", der er i stand til at administrere det nuværende grafikkort eller grafikkort for at kunne gengives på det. Disse DRI -drivere leveres typisk som delte biblioteker, som klienten er dynamisk knyttet til . Da DRI blev udtænkt til at drage fordel af 3D -grafikhardware, præsenteres bibliotekerne normalt for klienter som hardware -accelererede implementeringer af en 3D API som OpenGL , leveret af enten 3D -hardwareleverandøren selv eller en tredjepart, f.eks. Gratis Mesa 3D -software projekt.
• X Server har en X11 -protokoludvidelse - DRI -udvidelsen - som DRI -klienterne bruger til at koordinere med både vinduesystemet og DDX -driveren. Som en del af DDX -driveren er det ret almindeligt, at X Server -processen også dynamisk linker til den samme DRI -driver, som DRI -klienterne, men for at levere hardware -accelereret 3D -gengivelse til X -klienterne ved hjælp af GLX -udvidelsen til indirekte gengivelse (f.eks. X -klienter, der ikke kan bruge direkte gengivelse). Ved 2D -gengivelse skal DDX -driveren også tage hensyn til DRI -klienter, der bruger den samme grafiske enhed.
• adgangen til grafikkortet eller grafikkortet reguleres af en kernekomponent kaldet Direct Rendering Manager (DRM). Både X -serverens DDX -driver og hver X -klients DRI -driver skal bruge DRM for at få adgang til grafikhardwaren. DRM giver synkronisering med de grafiske hardwares delte ressourcer - ressourcer som kommandokøen, kortregistrene, videohukommelsen, DMA -motorerne, ... - hvilket sikrer, at den samtidige adgang til alle de flere konkurrerende brugerpladsprocesser ikke ikke forstyrre hinanden. DRM fungerer også som en grundlæggende sikkerhedshåndhæver, der ikke tillader nogen X -klienter at få adgang til hardwaren ud over, hvad den har brug for for at udføre 3D -gengivelsen.

DRI1

I den originale DRI -arkitektur var der på grund af hukommelsestørrelsen på grafikkort på det tidspunkt en enkelt forekomst af skærmens forreste buffer og bagbuffer (også af den supplerende dybdebuffer og stencilbuffer ), delt af alle DRI -klienter og X -serveren. Alle blev gengivet direkte på bagbufferen, der blev byttet med den forreste buffer ved lodret blanking -interval . For at gengive til bagbufferen skal en DRI -proces sikre, at gengivelsen blev klippet til det område, der er reserveret til vinduet .

Den synkronisering med X Server blev gjort gennem signaler og en delt hukommelse buffer benævnt SAREA. Adgangen til DRM -enheden var eksklusiv, så enhver DRI -klient måtte låse den i begyndelsen af ​​en gengivelsesoperation . Andre brugere af enheden - herunder X Server - blev blokeret i mellemtiden, og de måtte vente, indtil låsen blev frigivet ved afslutningen af ​​den aktuelle gengivelsesoperation, selvom det ikke ville være nogen konflikt mellem begge operationer. En anden ulempe var, at operationer ikke bevarede hukommelsestildelinger, efter at den nuværende DRI -proces frigav låsen på enheden, så alle data, der blev uploadet til grafikhukommelsen, f.eks. Teksturer, gik tabt til kommende operationer, hvilket forårsagede en betydelig indvirkning på grafikydelsen.

I dag betragtes DRI1 som helt forældet og må ikke bruges.

DRI2

På grund af den stigende popularitet af sammensætning af vinduesadministratorer som Compiz , skulle Direct Rendering Infrastructure redesignes, så X -klienter også kunne understøtte omdirigering til "offscreen pixmaps", mens de udførte direkte gengivelse. Almindelige X-klienter respekterede allerede omdirigering til en separat pixmap leveret af X Server som et gengivelsesmål-det såkaldte pixmap uden for skærm-men DRI-klienter fortsatte med at gengive direkte i den delte backbuffer og effektivt omgå den komponerende vinduesmanager. Den ultimative løsning var at ændre måden, hvorpå DRI håndterede renderbuffere, hvilket førte til en helt anden DRI -udvidelse med et nyt sæt operationer, og også store ændringer i Direct Rendering Manager . Den nye udvidelse blev navngivet "DRI2", selvom den ikke er en senere version, men en anden udvidelse, der ikke engang er kompatibel med den originale DRI - faktisk begge har eksisteret sammen i X -serveren i lang tid.

I DRI2, i stedet for en enkelt delt (tilbage) buffer, hver DRI klient får sin egen private ryg buffer -along med deres tilhørende dybde og stencil buffers- at gøre sit vindue indhold ved hjælp af hardware-acceleration . DRI -klienten bytter den derefter med en falsk " frontbuffer ", som bruges af den vindende komponent i sammensætningen som en af ​​kilderne til at komponere (bygge) den sidste back -back -buffer, der skal byttes ved VBLANK -intervallet med den rigtige frontbuffer .

For at håndtere alle disse nye buffere, Direct Rendering manager måtte indarbejde ny funktionalitet, specifikt en grafisk hukommelse leder . DRI2 blev oprindeligt udviklet ved hjælp af den eksperimentelle TTM -hukommelsesstyring, men den blev senere omskrevet til at bruge GEM, efter at den blev valgt som den endelige DRM -hukommelsesstyring. Den nye DRI2 interne bufferhåndteringsmodel løste også to store ydelsesflaskehalse, der var til stede i den oprindelige DRI -implementering:

• DRI2 -klienter låser ikke længere hele DRM -enheden, mens den bruges til gengivelse, da hver klient nu får en separat renderbuffer uafhængig af de andre processer.
• DRI2 -klienter kan allokere deres egne buffere (med teksturer, toppunktlister, ...) i videohukommelsen og beholde dem, så længe de vil, hvilket reducerer forbruget af videohukommelsesbåndbredde betydeligt.

I DRI2 udføres allokeringen af ​​de private offscreen -buffere (bagbuffer, falsk frontbuffer, dybdebuffer, stencilbuffer, ...) til et vindue af X Server selv. DRI -klienter henter disse buffere for at gøre gengivelsen i vinduet ved at kalde operationer som DRI2GetBuffers og DRI2GetBuffersWithFormat tilgængelige i DRI2 -udvidelsen. Internt bruger DRI2 GEM -navne - en type globalt håndtag leveret af GEM API, der tillader to processer, der har adgang til en DRM -enhed, at henvise til den samme buffer - til at videregive "referencer" til disse buffere gennem X11 -protokollen . Grunden til at X Server er ansvarlig for buffertildelingen af ​​renderbuffere i et vindue er, at GLX -udvidelsen giver mulighed for flere X -klienter til at udføre OpenGL -gengivelse i samme vindue. På denne måde styrer X Server hele renderingsbuffernes livscyklus under hele gengivelsesprocessen og ved, hvornår den sikkert kan genbruge eller kassere dem. Når der udføres en størrelse på et vindue, er X Server også ansvarlig for at tildele nye renderbuffere, der matcher den nye vinduesstørrelse, og underrette ændringen til DRI -klientens (r) gengivelse i vinduet ved hjælp af en InvalidateBuffers -hændelse, så de ville hente GEM navne på de nye buffere.

DRI2 -udvidelsen giver andre kerneoperationer for DRI -klienterne, såsom at finde ud af hvilken DRM -enhed og driver, de skal bruge ( DRI2Connect ) eller blive godkendt af X Server for at kunne bruge gengivelses- og bufferfaciliteterne på DRM -enheden ( DRI2Authenticate ). Præsentationen af ​​de gengivne buffere på skærmen udføres ved hjælp af forespørgslerne DRI2CopyRegion og DRI2SwapBuffers . DRI2CopyRegion kan bruges til at lave en kopi mellem den falske frontbuffer og den rigtige frontbuffer , men det giver ikke nogen synkronisering med det lodrette blanking -interval, så det kan forårsage rive . DRI2SwapBuffers udfører på den anden side en VBLANK-synkroniseret swap mellem bag- og frontbuffer, hvis den understøttes, og begge buffere har samme størrelse eller en kopi ( blit ) på anden måde.

DRI3

Selvom DRI2 var en betydelig forbedring i forhold til den originale DRI, introducerede den nye udvidelse også nogle nye problemer. I 2013 blev en tredje iteration af Direct Rendering Infrastructure kendt som DRI3 udviklet for at løse disse problemer.

De største forskelle på DRI3 sammenlignet med DRI2 er:

• DRI3 -klienter tildeler sig selv deres renderbuffere i stedet for at stole på X -serveren til at foretage tildelingen - det var metoden understøttet af DRI2.
• DRI3 slipper af med den gamle usikre GEM- bufferdelingsmekanisme baseret på GEM-navne (globale GEM-håndtag) til overførsel af bufferobjekter mellem en DRI-klient og X Server til fordel for den mere sikre og alsidige baseret på PRIME DMA-BUF'er , som bruger filbeskrivelser i stedet.

Buffertildeling på klientsiden bryder GLX -antagelser i den forstand, at det ikke længere er muligt for flere GLX -applikationer at gengive samarbejde i samme vindue. På plussiden giver det faktum, at DRI -klienten har ansvaret for sine egne buffere gennem hele deres levetid, mange fordele. For eksempel er det let for DRI3 -klienten at sikre, at størrelsen på renderbufferne altid matcher den aktuelle størrelse af vinduet og derved eliminere artefakterne på grund af manglende synkronisering af bufferstørrelser mellem klient og server, der plagede vinduesstørrelse i DRI2. En bedre ydeevne opnås også, for nu sparer DRI3 -klienter den ekstra rundtur, der venter på, at X Server sender renderbufferne. DRI3 -klienter, og især komponistvinduesadministratorer, kan drage fordel af at beholde ældre buffere af tidligere rammer og genbruge dem som grundlag for kun at gengive de beskadigede dele af et vindue som endnu en ydelsesoptimering. DRI3 -udvidelsen behøver ikke længere at blive ændret for at understøtte nye særlige bufferformater, da de nu håndteres direkte mellem DRI -klientdriveren og DRM -kernel -driveren. Brugen af ​​filbeskrivelser tillader på den anden side kernen at udføre en sikker oprydning af ethvert ubrugt GEM -bufferobjekt - en uden henvisning til det.

Teknisk set består DRI3 af to forskellige udvidelser, "DRI3" udvidelsen og "Nuværende" udvidelsen. Hovedformålet med DRI3 -udvidelsen er at implementere mekanismen til at dele direkte gengivne buffere mellem DRI -klienter og X Server. DRI -klienter tildeler og bruger GEM -bufferobjekter som gengivelsesmål, mens X Server repræsenterer disse renderbuffere ved hjælp af en type X11 -objekt kaldet "pixmap". DRI3 giver to operationer, DRI3PixmapFromBuffer og DRI3BufferFromPixmap , den ene til at oprette en pixmap (i "X Server space") fra et GEM -bufferobjekt (i "DRI -klientrum"), og den anden for at gøre det omvendte og få et GEM -bufferobjekt fra et X pixmap. I disse DRI3-operationer sendes GEM-bufferobjekter som DMA-BUF- filbeskrivelser i stedet for GEM-navne. DRI3 giver også en måde at dele synkroniseringsobjekter mellem DRI -klienten og X -serveren, hvilket giver både en seriel adgang til den delte buffer. I modsætning til DRI2 returnerer den første DRI3Open -operation - den første hver DRI -klient skal anmode om at vide, hvilken DRM -enhed der skal bruges - en allerede åben filbeskrivelse til enhedsknudepunktet i stedet for enhedsnodens filnavn, med enhver påkrævet godkendelsesprocedure allerede udført på forhånd af X -serveren.

DRI3 giver ingen mekanisme til at vise de gengivne buffere på skærmen, men er afhængig af en anden udvidelse, den nuværende udvidelse, for at gøre det. Present er så navngivet, fordi dets hovedopgave er at "præsentere" buffere på skærmen, hvilket betyder, at den håndterer opdateringen af ​​framebufferen ved hjælp af indholdet af de gengivne buffere, der leveres af klientprogrammer. Skærmopdateringer skal udføres på det rigtige tidspunkt, normalt i løbet af VBLANK -intervallet for at undgå visning af artefakter såsom rivning . Present håndterer også synkroniseringen af ​​skærmopdateringer til VBLANK -intervallet. Det holder også X -klienten informeret om det øjeblik, hver buffer virkelig vises på skærmen ved hjælp af begivenheder, så klienten kan synkronisere sin gengivelsesproces med den aktuelle skærmopdateringshastighed.

Present accepterer enhver X pixmap som kilde til en skærmopdatering. Da pixmaps er standard X -objekter, kan Present ikke kun bruges af DRI3 -klienter, der udfører direkte gengivelse, men også af enhver X -klientgengivelse på en pixmap på nogen måde. For eksempel plejede de fleste eksisterende ikke- GL- baserede GTK +- og Qt- applikationer at udføre dobbeltbufret pixmap-gengivelse ved hjælp af XRender . Den nuværende udvidelse kan også bruges af disse applikationer til at opnå effektive og ikke-rive skærmopdateringer. Dette er grunden til, at Present blev udviklet som en separat selvstændig udvidelse i stedet for at være en del af DRI3.

Udover at lade ikke-GL X-klienter synkronisere med VBLANK, giver Present andre fordele. DRI3 -grafikydelse er bedre, fordi Present er mere effektiv end DRI2 til at bytte buffere. En række OpenGL -udvidelser, der ikke var tilgængelige med DRI2, understøttes nu baseret på nye funktioner fra Present.

Present leverer to hovedoperationer til X -klienter: opdater en region i et vindue ved hjælp af en del af eller alt indholdet i en pixmap ( PresentPixmap ) og indstil den type præsentationshændelser, der er relateret til et bestemt vindue, som klienten ønsker at få besked om ( PresentSelectInput ). Der er tre præsentationshændelser, som et vindue kan underrette en X -klient om: når en igangværende præsentationsoperation - normalt fra et opkald til PresentPixmap - er afsluttet ( PresentCompleteNotify ), når en pixmap, der bruges af en PresentPixmap -operation, er klar til at blive genbrugt ( PresentIdleNotify ) og når vindueskonfigurationen - for det meste vinduesstørrelse - ændres ( PresentConfigureNotify ). Uanset om en PresentPixmap -handling udfører en direkte kopi ( blit ) på den forreste buffer eller et bytte af hele bagbufferen med den forreste buffer, er en intern detalje i implementeringen af ​​nuværende udvidelse i stedet for et eksplicit valg af X -klienten, som den var i DRI2.

Adoption

Flere open source DRI-drivere er blevet skrevet, herunder dem til ATI Mach64, ATI Rage128, ATI Radeon, 3dfx Voodoo3 til og med Voodoo5, Matrox G200 til G400, SiS 300-serien, Intel i810 til i965, S3 Savage, VIA UniChrome grafikchipsæt og nouveau til Nvidia . Nogle grafikleverandører har skrevet lukkede DRI-drivere, herunder ATI og PowerVR Kyro.

De forskellige versioner af DRI er blevet implementeret af forskellige operativsystemer, blandt andet af Linux -kernen , FreeBSD , NetBSD , OpenBSD og OpenSolaris .

Historie

Projektet blev startet af Jens Owen og Kevin E. Martin fra Precision Insight (finansieret af Silicon Graphics og Red Hat ). Det blev først gjort bredt tilgængeligt som en del af XFree86 4.0 og er nu en del af X.Org Server . Det vedligeholdes i øjeblikket af gratis softwarefællesskabet .

Arbejdet med DRI2 startede på X -udviklermødet i 2007 fra et forslag fra Kristian Høgsberg . Høgsberg skrev selv den nye DRI2 -udvidelse og ændringerne til Mesa og GLX . I marts 2008 blev DRI2 for det meste udført, men det kunne ikke blive til X.Org Server version 1.5 og måtte vente til version 1.6 fra februar 2009. DRI2 -udvidelsen blev officielt inkluderet i X11R7.5 -udgivelsen i oktober 2009. Den første offentlig version af DRI2 -protokollen (2.0) blev annonceret i april 2009. Siden da har der været flere ændringer, som er den seneste version 2.8 fra juli 2012.

På grund af flere begrænsninger af DRI2 blev en ny udvidelse kaldet DRI-Next foreslået af Keith Packard og Emma Anholt på X.Org Developer's Conference 2012. Udvidelsen blev foreslået igen som DRI3000 på Linux.conf.au 2013. DRI3 og Present extensions blev udviklet i løbet af 2013 og fusioneret til X.Org Server 1.15 -versionen fra december 2013. Den første og eneste version af DRI3 -protokollen (1.0) blev frigivet i november 2013.

• 

  2D -drivere inde i X -serveren

• 

  Indirekte gengivelse over GLX ved hjælp af Utah GLX ; adskilt: fbdev

• 

  Tidlig DRI: Indstilling af tilstand udføres stadig af X -displayserveren , hvilket tvinger den til at køre som root

• 

  Endelig går al adgang via Direct Rendering Manager

• 

  I Linux -kerne blev 3.12 gengivelsesnoder introduceret; DRM og KMS -chaufføren blev delt. Wayland implementerer direkte gengivelse over EGL

Se også

• Direkte gengivelseschef
• Mesa 3D
• X Vinduesystem

Referencer

eksterne links

• Direkte gengivelsesinfrastrukturprojektets hjemmeside
• Aktuelle specifikationsdokumenter (altid opdateret til den seneste version):
  • DRI2 -udvidelsen (Kristian Høgsberg, 2008)
  • DRI3 -udvidelsen (Keith Packard, 2013)
  • Den nuværende udvidelse (Keith Packard, 2013)