Mesa (datagrafikk) - Mesa (computer graphics)

Mesa

Originale forfattere	Brian Paul
Utvikler (er)	Foreløpig: Intel , AMD , VMware Tidligere: Tungsten Graphics
Første utgivelse	Februar 1995
Stabil utgivelse	21.2.3  / 29. september 2021 ; 18 dager siden ( 29. september 2021 )
Oppbevaringssted
Skrevet inn	C , C ++ , monteringsspråk
Operativsystem	På tvers av plattformer ( BSD , Haiku , Linux , etc)
Type	Grafisk bibliotek
Tillatelse	MIT -lisens
Nettsted	mesa3d .org

Mesa , også kalt Mesa3D og The Mesa 3D Graphics Library , er en åpen kildekode-programvareimplementering av OpenGL , Vulkan og andre grafiske API- spesifikasjoner. Mesa oversetter disse spesifikasjonene til leverandørspesifikke grafikkmaskinvaredrivere.

De viktigste brukerne er to grafikkdrivere som for det meste er utviklet og finansiert av Intel og AMD for deres respektive maskinvare (AMD promoterer sine Mesa -drivere Radeon og RadeonSI over den utdaterte AMD Catalyst , og Intel har bare støttet Mesa -driveren). Proprietære grafikkdrivere (f.eks. Nvidia GeForce -driver og Catalyst) erstatter hele Mesa og gir sin egen implementering av et grafisk API. En åpen kildekode-innsats for å skrive en Mesa Nvidia-driver kalt Nouveau er for det meste utviklet av samfunnet.

Foruten 3D-applikasjoner som spill, moderne vindustjener ( X.org sin Glamour eller Wayland 's Weston ) bruk OpenGL / EGL ; derfor går all grafikk vanligvis gjennom Mesa.

Mesa er vert for freedesktop.org og ble initiert i august 1993 av Brian Paul , som fremdeles er aktiv i prosjektet. Mesa ble deretter bredt adoptert og inneholder nå mange bidrag fra forskjellige individer og selskaper over hele verden, inkludert fra grafikkmaskinvareprodusentene i Khronos Group som administrerer OpenGL -spesifikasjonen. For Linux har utviklingen også vært delvis drevet av crowdfunding .

Oversikt

Videospill outsourcer gjengivelsesberegninger til GPU over OpenGL i sanntid. Shaders skrives på OpenGL Shading Language eller SPIR-V og kompileres på CPU. De kompilerte programmene kjøres på GPU.

Illustrasjon av Linux -grafikkstakken: DRM og libDRM, Mesa 3D . Skjermserveren tilhører vindusystemet og er ikke nødvendig, f.eks. For spill.

Implementeringer av gjengivelse av APIer

De gratis implementeringene av Wayland er avhengige av Mesa -implementeringen av EGL . Spesialbiblioteket kalt libwayland-EGL , skrevet for å imøtekomme tilgang til rammebufferen , burde vært gjort foreldet av EGL 1.5-utgivelsen. På GDC 2014 utforsket AMD en strategiendring mot å bruke DRM i stedet for deres in-core blob.

Mesa er kjent som boligimplementering av grafiske APIer . Historisk sett er hoved -API som Mesa har implementert OpenGL , sammen med andre Khronos Group -relaterte spesifikasjoner (som OpenVG , OpenGL ES eller nylig EGL ). Men Mesa kan implementere andre APIer og det gjorde det faktisk med Glide (utfaset) og Direct3D 9 siden juli 2013. Mesa er heller ikke spesifikk for Unix-lignende operativsystemer: for eksempel Windows tilbyr Mesa et OpenGL API over DirectX.

Mesa implementerer et oversettelseslag mellom et grafisk API som OpenGL og grafikkmaskinvaredrivere i operativsystemets kjerne. Den støttede versjonen av de forskjellige grafiske API -ene er avhengig av driveren, fordi hver maskinvaredriver har sin egen implementering (og derfor status). Dette gjelder spesielt de "klassiske" driverne, mens Gallium3D -driverne deler felles kode som har en tendens til å homogenisere de støttede utvidelsene og versjonene.

Mesa opprettholder en støttematrise med statusen til gjeldende OpenGL -konformitet visualisert på mesamatrix .net . Mesa 10 overholder OpenGL 3.3, for Intel, AMD/ATI og Nvidia GPU -maskinvare. Mesa 11 ble kunngjort med noen drivere som var OpenGL 4.1 -kompatible.

Mesa 12 inneholder støtte for OpenGL 4.2 og 4.3 og Intel Vulkan 1.0.

Mesa 13 brakte Intel-støtte for OpenGL 4.4 og 4.5 (alle funksjoner som støttes for Intel Gen 8+, Radeon GCN, Nvidia (Fermi, Kepler), men ingen Khronos-Test for 4.5-Label) og eksperimentell AMD Vulkan 1.0-støtte gjennom samfunnsdriveren RADV. OpenGL ES 3.2 er mulig med Intel Skylake (Gen9).

Den første stabile versjonen av 2017 er 17,0 (nyttårstelling). Klarfunksjoner er sertifisert OpenGL 4.5, OpenGL 4.5 for Intel Haswell, OpenGL 4.3 for NVidia Maxwell og Pascal (GM107+). Stor ytelsesøkning ble målt med Maxwell 1 (GeForce GTX 750 Ti og mer med GM1xx). Maxwell-2-kort (GeForce GTX 980 og mer med GM2xx) er underklokket uten NVidia-informasjon.

Khronos CTS-testserie for OpenGL 4.4, 4.5 og OpenGL ES 3.0+ er inne nå (2017-01-24) Open Source og alle tester for Mesa 13 og 17 er nå mulig uten kostnader.

2. stabile versjon av 2017, 17.1.0, kom ut 10. mai 2017 med noen interessante forbedringer. OpenGL 4.2+ for Intel Ivy Bridge og OpenGL 3.3+ for Intel Open SWR Rasterizer er 2 av høydepunktene.

Vær oppmerksom på at på grunn av OpenGL's modulære natur, kan Mesa faktisk støtte utvidelser fra nyere versjoner av OpenGL uten å kreve full støtte for slike versjoner. For eksempel, i juli 2016, støttet Mesa OpenGL ES 3.1, men også alle OpenGL ES 3.2 -utvidelser bortsett fra fem, samt en rekke utvidelser som ikke er en del av noen OpenGL- eller OpenGL ES -versjon.

Et åpent spørsmål for Mesa og Linux er High Dynamic Range (HDR). Mange problemer og åpne punkter er på trappene for en ren og grunnleggende implementering.

3. versjon 17.2 er tilgjengelig siden september 2017 med noen nye OpenGL 4.6 -funksjoner og hastighetsforbedringer i 3D for Intel og AMD. Bare 1,4% av testene mislykkes for OpenGL 4.5 i Nouveau for Kepler.

4. versjon 17.3 er klar siden desember 2017. Mange forbedringer i mange drivere er tilgjengelige. OpenGL 4.6 er nesten fullt tilgjengelig (Spir-V er ikke klar). AMD Vulkan Driver RADV er nå helt i samsvar med Khronos-Test.

Første versjon av 2018 er 18.0 og tilgjengelig siden mars 2018 etter samme opplegg i 2017. Full OpenGL 4.6 -støtte er ikke klar, men mange funksjoner og forbedringer ble vellykket testet i RC3. 10-biters støtte for Intel i965 i farger er også et høydepunkt. Nytt er støtte for Intel Cannon Lake og AMD Vega med faktisk Linux -versjon. AMD Evergreen Chips (RV800 eller R900) er i nærheten av OpenGL 4.5 -støtte. Gamle AMD R600- eller RV700 -brikker kan bare støtte OpenGL 3.3 med noen funksjoner i OpenGL 4.x. Freedreno er driveren for Adreno -maskinvare og nær OpenGL 3.3 -støtte.

Andre versjon av 2018 er 18.1 og tilgjengelig siden mai. Målet er Vulkan 1.1.72 i Intel ANV og AMD RADV driver. OpenGL 4.6 med spir-V er også hovedmålet. Permanent arbeid er mulig ferdigstillelse av funksjoner og optimalisering av drivere for eldre maskinvare som AMD R600/Evergreen, Nvidia Tesla og før, Fermi, Kepler eller Intel Sandybridge, Ivybridge, Haswell eller Broadwell. ARM Architecture gjorde også store forbedringer i Adreno 3xx/4xx/5xx og Broadwell VC4/VC5 for Raspi med hovedmål OpenGL ES.

3. versjon av 2018 er 18.2 og tilgjengelig i kalenderstabil i september. OpenGL 4.6 med spir-V og Vulkan 1.1.80 er i WIP. Den myke driveren for virtuelle maskiner VIRGL er klar for OpenGL 4.3 og OpenGL ES 3.2. RadeonSI er også klar for OpenGL ES 3.2. ASTC Texture Compression Support og Compatibility Modus Support for OpenGL 4.4 (3.1 in 18.1) er andre høydepunkter i RadeonSI for AMD GCN -kort. Ny Vulkan 1.1 og flere funksjoner for Intel og AMD er tilgjengelige. Se flere detaljer for Vulkan i Mesamatrix.

4. versjon av 2018 er 18.3 og utgitt som stabil versjon 18.3.1 i desember 2018. Mange funksjoner i detalj og støtte for nyere maskinvare er hoveddeler. Full støtte for OpenGL 4.6 er ikke klar.

Første versjon av 2019 er 19.0 og ble nå utgitt i mars. Full støtte for OpenGL 4.6 er ikke klar, men mange forbedringer på denne måten er i alle drivere.

Andre versjon av 2019 er 19.1. Overgang av TGSI til NIR er her en hovedfunksjon på vei til OpenGL 4.6 med Spir-V og mer OpenCL. RadeonSI kjører godt i dev-versjon med NIR.

3. versjon av 2019 er 19.2. OpenGL 4.6 er Beta klar for ny Intel Iris Driver.

Fjerde versjon av 2019 er 19.3. OpenGL 4.6 er klar for Intel i965 og valgfri for ny Iris Driver.

Første versjon av 2020 er 20.0. Vulkan 1.2 er klar for AMD RADV og Intel ANV. Intel Iris er standard for Intel Broadwell Gen 8+. RadeonSI -driveren byttet til å bruke NIR som standard, i stedet for TGSI.

Andre versjon av 2020 er 20.1. Mange forbedringer er klare i mange drivere. Zink er en ny virtuell driver for OpenGL over Vulkan.

Tredje versjon av 2020 er 20.2. OpenGL 3.0 for Zink er en ny funksjon. LLVMpipe støtter OpenGL 4.3+ (4.5+ i 20.3). ARM Panfrost er stort sett forbedret med mange moduler. Delt virtuelt minne er mulig for OpenCL i Nouveau med Pascal og høyere.

Fjerde versjon av 2020 er 20.3. v3d og v3dv er nye drivere for OpenGL og Vulkan 1.0 med Broadcom -maskinvare som Raspberry Pi 4. OpenCL 1.2 er fullt støttet i kløvermodul. Zink -støtte OpenGL 3.3+. LLVMpipe virtuell driverstøtte nå OpenGL 4.5+ med 4.6 i visning. VALLIUM som Vulkan Tree av LLVMpipe er slått sammen.

I Mesa 21.0 d3d12 blir slått sammen med OpenGL 3.0 til 3.3. Microsoft og Collabora utvikler ny emulering d3d12 i WSL2 til Windows 10 med Direct 3D 12. OpenCL 1.2 er også mål i d3d12. En akselerasjon av faktor 2 til 5 utføres i Benchmark SPECviewperf med forbedret OpenGL -kode. Mange Mesa 21.0 -funksjoner forbedrer ytelsen. Ny utgivelse 21.0.0 er offentlig siden 11. mars 2021.

Mesa 21.1 er andre utgivelse i år 2021. OpenGL 4.6+ og OpenGL ES 3.1+ er tilgjengelig for Zink. AMD Driver 600g kan bytte til NIR med flere muligheter for gamle Radeeon HD 5000 og 6000 kort. Qualcomm Turnip når Vulkan 1.1+ og programvareemulering Lavapipe Vulkan 1.1+. Google VirtIO GPU -driver Venus med Vulkan 1.2+ er slått sammen i eksperimentell tilstand med lav ytelse i mesa -hovedtreet.

Mesa 21.2 er tredje utgivelse i år 2021. Google Virtual Vulkan IO Driver Venus vil bli offisielt introdusert med full Vulkan 1.2+ støtte (mer mesamatrix). ARM Panfrost: OpenGL ES 3.1+ støtte er tilgjengelig og panVK er den nye Vulkan -driveren. Første støtte startet for ARM Apple M1 med ny driver Asahi. 21.2 er tilgjengelig siden 4. august 2021.

En gammel plan er å dele gamle drivere i et klassisk tre med mange fordeler innen programmering, støtte, feilretting for den moderne gallium 3D -delen. Ett problem her er Intel i965 med støtte for populær gammel maskinvare til Intel Haswell og tidligere også med Windows 10 -støtte. En ny Gallium3D -driver Crocus for Intel Gen 4 Graphics til Haswell er her under utvikling for å fullføre gallium3D -området her med mulig splitt i neste årstid 2021. Crocus er valgfritt tilgjengelig i 21.2.

Tabell over gjengivelses -APIer

Vulkan

Den Khronos Gruppe offisielt annonsert Vulkan API mars 2015, og offisielt utgitt Vulkan 1.0 den 16. februar 2016. Vulkan bryter kompatibilitet med OpenGL og helt forlater sine monolittiske tilstandsmaskin konsept. Utviklerne av Gallium3D kalte Vulkan for å være noe i stil med Gallium3D 2.0 - Gallium3D skiller koden som implementerer OpenGL -tilstandsmaskinen fra koden som er spesifikk for maskinvaren.

Etter hvert som Gallium3D inntar TGSI, inntar Vulkan SPIR-V ( Standard Portable Intermediate Representation versjon "V" som i "Vulkan").

Intel lanserte implementeringen av en Vulkan -driver for maskinvaren den dagen spesifikasjonen ble offisielt utgitt, men den ble først mainlinet i april og ble dermed en del av Mesa 12.0, utgitt i juli 2016. Selv om i965 -driveren allerede ikke ble skrevet iht. Gallium3D -spesifikasjonene, for Vulkan -driveren er det enda mindre fornuftig å flense den på toppen av Gallium3D. Tilsvarende er det ingen teknisk grunn til å flange den med NIR, men likevel har Intels ansatte implementert Vulkan -driveren på den måten.

Det er forventet at AMDs egen proprietære Vulkan-driver, som ble utgitt i mars, og ble annonsert for å bli utgitt som gratis og åpen kildekode-programvare i fremtiden og bli hovedlinje i Mesa, også forlater Gallium3D.

RADV er et gratis prosjekt for AMD og er tilgjengelig siden versjon 13. Overensstemmelse med Khronos-Test kom i versjon 17.3. Faktisk er Full støtte for Vulkan 1.0 og 1.1 siden Mesa 18.1.

Nvidia lanserte sin proprietære GeForce -driver med Vulkan -støtte på lanseringsdagen og Imagination Technologies (PowerVR), Qualcomm (Adreno) og ARM (Mali) har gjort det samme eller i det minste annonsert proprietære Vulkan -drivere for Android og andre operativsystemer. Men når og om ytterligere gratis og åpen kildekode-Vulkan-implementering for disse GPU-ene vil dukke opp, gjenstår å se.

Mesa Software Driver VIRGL starter Vulkan Development i 2018 med GSOC -prosjekter for støtte for virtuelle maskiner.

Lavapipe er en CPU-basert Software Vulkan-driver og broren til LLVMpipe. Mesa versjon 21.1 støtter Vulkan 1.1+.

Google introduserer Venus Vulkan Driver for virtuelle maskiner i Mesa 21.1 med full støtte for Vulkan 1.2+.

Qualcomm Turnip og Broadcom v3dv er nye drivere for Qualcomm Adreno og Broadcom Raspberry 4 Hardware. Turnip er Vulkan -broren til freedreno for OpenGL. V3dv støtter Vulkan 1.0+ siden Mesa 20.3. I versjon 21.1 Turnip støtter Vulkan 1.1+.

Eksplisitt gjerde

En slags minnebarriere som skiller en buffer fra resten av minnet kalles et gjerde. Gjerder er der for å sikre at en buffer ikke blir overskrevet før gjengivelse og visningsoperasjoner er fullført på den. Implisitt gjerde brukes til synkronisering mellom grafikkdrivere og GPU -maskinvaren. Gjerdet signaliserer når en buffer ikke lenger brukes av en komponent, slik at den kan betjenes eller gjenbrukes av en annen. Tidligere hadde Linux -kjernen en implisitt gjerdemekanisme, hvor et gjerde er direkte festet til en buffer (jf. GEM -håndtak og FD -er), men brukerområdet er ikke klar over dette. Eksplisitt gjerde utsetter gjerder for userpace, hvor userpace får gjerder fra både Direct Rendering Manager (DRM) delsystemet og fra GPU. Eksplisitt gjerde kreves av Vulkan og gir fordeler for sporing og feilsøking.

Linux -kjernen 4.9 la til Androids synkroniseringsramme til hovedlinjen.

Generisk bufferbehandling

Generic Buffer Management (GBM) er et API som gir en mekanisme for tildeling av buffere for grafisk gjengivelse knyttet til Mesa. GBM er ment å brukes som en opprinnelig plattform for EGL på DRM eller openwfd. Håndtaket den lager kan brukes til å initialisere EGL og til å lage målbuffere for gjengivelse.

Mesa GBM er en abstraksjon av de grafikkdriverspesifikke bufferhåndterings -API -ene (for eksempel de forskjellige libdrm_* bibliotekene), implementert internt ved å kalle inn Mesa GPU -driverne.

For eksempel gjør Wayland -komponisten Weston gjengivelsen ved hjelp av OpenGL ES 2, som den initialiserer ved å kalle EGL. Siden serveren kjører på den "bare KMS -driveren ", bruker den EGL DRM -plattformen, som virkelig kan kalles GBM -plattformen, siden den er avhengig av Mesa GBM -grensesnittet.

På XDC2014 foreslo Nvidia -ansatt Andy Ritger å forbedre EGL for å erstatte GBM. Dette ble ikke tatt positivt av samfunnet, og Nvidia ombestemte seg til slutt og tok en annen tilnærming.

Implementeringer av video -akselerasjon -APIer

Det er tre mulige måter å gjøre beregningene som er nødvendige for koding og dekoding av videostrømmer:

1. bruk en programvareimplementering av en videokomprimerings- eller dekomprimeringsalgoritme (vanligvis kalt en CODEC) og kjør denne programvaren på C PU
2. bruk en programvareimplementering av en videokomprimerings- eller dekomprimeringsalgoritme (vanligvis kalt en CODEC) og kjør denne programvaren på G PU ( 3D -gjengivelsesmotoren )
3. bruke en fullstendig (eller delvis) maskinvareimplementering av en videokomprimerings- eller dekomprimeringsalgoritme; det har blitt veldig vanlig å integrere slike ASIC -er i brikken til GPU/CPU/APU/SoC og derfor rikelig tilgjengelig; Av markedsføringshensyn har selskaper etablert merker for sine ASIC -er, for eksempel PureVideo (Nvidia), Unified Video Decoder (AMD), Video Coding Engine (AMD), Quick Sync Video (Intel), DaVinci (Texas Instruments), CedarX (Allwinner), Crystal HD (Broadcom); noen ASIC -er er tilgjengelige for lisensiering som kjerne for halvlederens immaterielle rettigheter ; vanligvis implementerer forskjellige versjoner forskjellige videokomprimerings- og/eller videodekomprimeringsalgoritmer; Støtte for slike ASIC-er hører vanligvis til kjernedriveren, for å initialisere maskinvaren og gjøre ting på lavt nivå. Mesa, som kjører i brukerrom, huser implementeringen av flere APIer for programvare, f.eks. VLC mediespiller , GStreamer , HandBrake , etc., for enkel tilgang til slike ASIC:

• Video Acceleration API (VAAPI) - den vanligste API -en for Linux, brukt av AMD og Intel
• Video Decode and Presentation API for Unix (VDPAU) - brukt av Nvidia
• DirectX Video Acceleration (DXVA)-bare Microsoft Windows
• OpenMAX IL - designet av Khronos Group for videokomprimering
• Distribuert Codec Engine (DCE) - designet av Texas Instruments
• X -Video Bitstream Acceleration (XvBA) - utvidelse til Xv - etterfulgt av VAAPI
• X -Video Motion Compensation (XvMC) - utvidelse til Xv - etterfulgt av VAAPI

For eksempel støtter Nouveau , som er utviklet som en del av Mesa, men også inkluderer en Linux -kjernekomponent, som utvikles som en del av Linux -kjernen, PureVideo -merkede ASIC og gir tilgang til dem via VDPAU og delvis gjennom XvMC .

Den gratis radeon -driveren støtter Unified Video Decoder og Video Coding Engine via VDPAU og OpenMAX.

Vær oppmerksom på at V4L2 er et kjerne-til-bruker-mellomrom-grensesnitt for videobitstrømmer levert av webkameraer eller TV-tunere.

Enhetsdrivere

Grafiske enhetsdrivere implementeres ved hjelp av to komponenter: en UMD (brukermodusdriver) og en KMD (kjernemodusdriver). Fra og med Linux -kjernen 4.2 vil AMD Catalyst og Mesa dele den samme Linux -kjernedriveren : amdgpu . Amdgpu gir grensesnitt definert av DRM og KMS.

Tilgjengelige gratis og åpen kildekode-enhetsdrivere for grafiske brikkesett "styres" av Mesa (fordi den eksisterende gratis og åpen kildekode-implementeringen av APIer er utviklet inne i Mesa). For tiden er det to rammer for å skrive grafikkdrivere: "classic" og Gallium3D. En oversikt over noen (men ikke alle) av driverne som er tilgjengelige i Mesa er gitt på mesamatrix .net .

Det er enhetsdrivere for AMD/ATI R100 til R800, Intel og Nvidia -kort med 3D -akselerasjon. Tidligere eksisterte drivere for IBM/Toshiba/Sony Cell APU for PlayStation 3 , S3 Virge & Savage brikkesett, VIA brikkesett, Matrox G200 og G400 og mer.

Gratis- og åpen kildekode-driverne konkurrerer med proprietære lukkede drivere. Avhengig av tilgjengeligheten av maskinvaredokumentasjon og man-power, henger gratis- og åpen kildekode-driveren mer eller mindre bak for å støtte 3D-akselerasjon av ny maskinvare. Dessuten var ytelsen til 3D -gjengivelse vanligvis betydelig tregere med noen bemerkelsesverdige unntak. I dag gjelder dette fremdeles for Nouveau for de fleste NVIDIA -GPUer, mens på AMDs Radeon -GPUer den åpne driveren stort sett samsvarer med eller overgår den proprietære driverens ytelse.

Direkte gjengivelsesinfrastruktur (DRI)

Da 3D- grafikkort ble mer vanlige for PC-er, begynte enkeltpersoner som delvis ble støttet av noen selskaper, å jobbe med å legge til mer støtte for maskinvareakselerert 3D-gjengivelse til Mesa. Den Infrastruktur Direct Rendering (DRI) var en av disse tilnærminger til grensesnitt Mesa, OpenGL og andre 3D-rendering API bibliotek med drivere og maskinvare. Etter å ha nådd et grunnleggende brukervennlighet, ble DRI -støtte offisielt lagt til Mesa. Dette utvidet det tilgjengelige utvalget av maskinvarestøtte betydelig ved bruk av Mesa -biblioteket.

Med tilpasningen til DRI overtok Mesa -biblioteket endelig rollen som frontend -komponenten i et fullskala OpenGL -rammeverk med varierende backend -komponenter som kunne tilby forskjellige grader av 3D -maskinvarestøtte uten å miste hele programvaregjengivelseskapasiteten. Det totale systemet brukte mange forskjellige programvarekomponenter.

Selv om designet krever at alle disse komponentene samhandler nøye, er grensesnittene mellom dem relativt faste. Siden de fleste komponenter som samhandler med Mesa -bunken er åpen kildekode, utføres imidlertid ofte eksperimentelt arbeid ved å endre flere komponenter samtidig, så vel som grensesnittene mellom dem. Hvis slike eksperimenter viser seg å være vellykkede, kan de innlemmes i den neste større eller mindre utgivelsen. Det gjelder f.eks. Oppdateringen av DRI-spesifikasjonen som ble utviklet i tidsrammen 2007-2008. Resultatet av denne eksperimenteringen, DRI2, fungerer uten låser og med forbedret støtte for ryggbuffer. For dette ble en spesiell git -gren av Mesa opprettet.

DRI3 støttes av Intel -driveren siden 2013 og er standard i noen Linux -distribusjoner siden 2016 for å aktivere Vulkan -støtte og mer. Det er også standard på AMD -maskinvare siden slutten av 2016 (X.Org Server 1.18.3 og nyere).

Programvare gjengivelse

Mesa inneholder også en implementering av programvaregjengivelse kalt swrast som lar shaders kjøre på CPU -en som et tilbakeslag når ingen grafikkmaskinvareakseleratorer er tilstede. Gallium -programvaren rasterizer er kjent som softpipe eller når den er bygget med støtte for LLVM llvmpipe , som genererer CPU -kode ved kjøretid. Siden Mesa 10.x OpenGL 3.3+ støttes for Softpipe (10.3) og LLVMpipe (10.2). Faktisk er omtrent 80% av funksjonene fra OpenGL 4.x implementert i Mesa 17.3 (Se Mesamatrix).

I Mesa 12.0 er en ny Intel Rasterizer OpenSWR tilgjengelig med store fordeler i klynger for store datasett. Det er mer fokusert på ingeniørvisualisering enn i spill- eller kunstbilder og kan bare fungere på x86 -prosessorer. På den annen side støttes nå OpenGL 3.1+. Akselerasjonsverdier fra 29 til 51 relatert til LLVMPIPE ble målt i noen eksempler. OpenGL 3.3+ støttes for OpenSWR siden Mesa 17.1.

VirGL er en Rasterizer for virtuelle maskiner implementert i Mesa 11.1 siden 2015 med OpenGL 3.3 -støtte og vist i Mesamatrix siden Mesa 18. I den nye Mesa 18.2 støtter den mer enn de andre med OpenGL 4.3 og OpenGL ES 3.2. Omtrent 80% av OpenGL 4.4 og 4.5 -funksjonene er også nå klare. Vulkan Development starter med GSOC 2018 -prosjekter.

D3d12 er et Microsoft -prosjekt for WSL2 -emulering av OpenGL 3.3+ og OpenCL 1.2+ med Direct3D 12. D3D12 er slått sammen i 21.0.

Venus er en ny Vulkan VirtIO GPU -driver for GPU i virtuelle maskiner av Google. Venus er slått sammen i 21.1 og for publikum i 21.2 introdusert.

Mega sjåfører

Ideen om å samle flere sjåfører til en "mega" sjåfør ble foreslått av Emma Anholt. Det tillater at en enkelt kopi av den delte Mesa -koden brukes blant flere drivere (i stedet for at den finnes i hver driver separat) og gir bedre ytelse enn et eget delt bibliotek på grunn av fjerning av det interne bibliotekgrensesnittet. State trackers for VDPAU og XvMC har blitt separate biblioteker.

shader-db

shader-db er en samling på rundt 20.000 shaders samlet fra forskjellige dataspill og benchmarks, samt noen skript for å kompilere disse og samle inn litt statistikk. Shader-db er ment å hjelpe til med å validere en optimalisering.

Det ble lagt merke til at et uventet antall shaders ikke er håndskrevet, men generert. Dette betyr at disse shaders ble opprinnelig skrevet i HLSL og deretter oversatt til GLSL av et oversetterprogram, for eksempel f.eks. HLSL2GLSL . Problemet er at den genererte koden ofte er langt fra å være optimal. Matt Turner sa at det var mye lettere å fikse dette i oversetterprogrammet enn å måtte få Mesas kompilator til å bære byrden for å håndtere slike oppblåste shaders.

shader-db kan ikke betraktes som gratis og åpen kildekode-programvare. For å bruke det lovlig må man ha lisens for alle dataspillene som shaders er en del av.

Programvarearkitektur

En grafikkdriver består av en implementering av OpenGL -tilstandsmaskinen og en samlingsbunke for å kompilere shaders til GPUens maskinspråk. Denne samlingen, så vel som stort sett alt annet, kjøres på CPU'en, deretter sendes de kompilerte shaders til GPUen og kjøres av den. (SDL = Simple DirectMedia Layer ).

De mellomliggende representasjonene (IR) i Mesa: GLSL IR, Mesa IR, TGSI og LLVM IR . Mangler HIR, LIR og NIR.

Mesa IR skal fjernes helt.

De såkalte "user-mode graphics device drivers" (UMD) i Mesa har svært få fellestrekk med det som vanligvis kalles enhetsdriver . Det er et par forskjeller:

• de er ment å fungere i tillegg til i tillegg eksisterende kjernemodus grafikk enhetsdrivere, som f.eks. er tilgjengelige som en del av Linux -kjernen som finnes i kildekoden under /drivers/gpu/drm/Hver UMD kommuniserer med sin kjernemodemodstykke ved hjelp av et bestemt bibliotek, navn libdrm_specific og en generisk, kalt libdrm . Denne delen skal bare se på brukermodus-delen over libdrm
• det er en viss implementering av finite-state-maskinen som spesifisert av f.eks. OpenGL; denne implementeringen av OpenGL -tilstandsmaskinen kan deles mellom flere UMD -er eller ikke
• de består for en stor del av en slags kompilator, som inntar f.eks. GLSL og til slutt sender ut maskinkode . Parsere kan deles mellom flere UMD eller være spesifikke

Mesas mellomrepresentasjoner

Et mål med Mesa er optimalisering av kode som skal utføres av den respektive GPU. En annen er deling av kode. I stedet for å dokumentere programvarene, som gjør det eller det, skal denne Wikipedia -artikkelen i stedet se på mellomrepresentasjonene som ble brukt i prosessen med å kompilere og optimalisere. Se Abstrakt syntaks -tre (AST) og Statisk enkeltoppdragsskjema (SSA -skjema).

SPIR-V

SPIR-V er en viss versjon av Standard Portable Intermediate Representation . Tanken er at grafikkprogrammer sender ut SPIR-V i stedet for GLSL. I motsetning til sistnevnte, er SPIR-V binært for å unngå implementeringsforskjeller mellom GLSL-kompilatorfrontene til forskjellige driverimplementeringer, ettersom dette har vært en viktig kilde til programkompatibilitet og feil. Også SPIR-V binær gikk vanligvis også gjennom noen generelle optimaliseringer. Også til en viss grad tilbyr SPIR-Vs binære representasjon en viss grad av uklarhet, noe som kan appellere til noen programvareleverandører som en form for beskyttelse av intellektuell eiendom; SPIR-V inneholder imidlertid rikelig med informasjon for refleksjon, og det finnes verktøy som kan oversette SPIR-V tilbake til høy kvalitet, menneskelig lesbar kode på høyt nivå . En UMD trenger bare å bruke optimaliseringer som er spesifikke for maskinvaren som støttes.

• SPIR-V-spesifikasjon (foreløpig)

GLSL IR

• cgit.freedesktop.org/mesa/mesa/tree/src/compiler/glsl/README
• XDC2014, Matt Turner: Video på YouTube , Matt Turner - GLSL -kompilator: Hvor vi har vært og hvor vi skal
• XDC2015, Matt Turner: Video på YouTube , www .x .org /wiki /Events /XDC2015 /Program /turner _glsl _compiler .pdf

Mesa IR

NIR

NIR (New Internal Representation) ble introdusert for å overvinne TGSI -begrensninger. NIR ble utvidet i siste og faktiske utgivelser som base for Spir-V-støtte og er siden 2016 hovedutviklingsområde. LLVMpipe, i965, RadeonSI, Nouveau, freedreno, vc4 er endret til NIR fra TGSI. RADV, Zink og andre nye drivere starter med NIR. Alle drivere med full støtte for OpenGL 4.6 er relatert til NIR by SPIR-V-støtte. AMD r600 har også en gaffel med NIR for bedre støtte for HD5000- og HD6000 -serien. Dette alternativet for r600 er standard siden Mesa 21.0.

• Connor Abbott - NIR, eller beveger seg utover GLSL IR i Mesa XDC2014
  • (Mesa-dev) 2014-12-15 Gjeninnføring av NIR, en ny IR for mesa
• cgit.freedesktop.org/mesa/mesa/tree/src/compiler/nir/README
• fosdem.org/2016/schedule/event/i965_nir/attachments/slides/1113/export/events/attachments/i965_nir/slides/1113/nir_vec4_i965_fosdem_2016_rc1.pdf
• NIR i RadeonSI
• Noveau oppdatering 2018
• Noveau med NIR i Mesa 19.3

TGSI

Tungsten Graphics Shader Infrastructure (TGSI) ble introdusert i 2008 av Tungsten Graphics. Alle Gallium3D-stil UMD inntar TGSI. NIR er nå hovedutviklingsområdet, så TGSI er bare for eldre sjåfører som standardinfrastruktur på 300 g og vil bli avviklet om noen år.

LLVM IR

UMD -ene radeonsiog llvmpipesender ikke ut maskinkode, men i stedet LLVM IR. Herfra gjør LLVM optimaliseringer og kompilering til maskinkode. Dette betyr at en viss minimumsversjon av LLVM også må installeres.

RADV ACO IR

RADV ACO bruker egen IR som er nær NIR, for å optimalisere og generere ende binær kode for Vulkan SPIR-V shaders på toppen av Radeon GPUer (GCN 1+, aka GFX6+) GPUer. Fra versjon 20.1.0 brukes ACO bare i RADV (Vulkan -driver) og ikke i RadeonSI ennå.

Mesas GLSL -kompilator

Mesas GLSL -kompilator genererer sin egen IR. Fordi hver sjåfør har svært forskjellige krav fra en LIR, skiller den mellom HIR (IR på høyt nivå) og LIR (lavt nivå IR).

Gallium3D

Gallium3D er et sett med grensesnitt og en samling støttende biblioteker som er ment å lette programmeringen av enhetsdrivere for 3D -grafikkbrikkesett for flere operativsystemer, gjengivelse eller videoakselerasjons -APIer.

Det leveres en funksjonsmatrise på mesamatrix .net , og arbeidet med å skrive gratis og åpen kildekode-enhetsdrivere for grafikkbrikker blir separat dokumentert i Wikipedia: Gratis og åpen kildekode-enhetsdriver .

Utviklingen av Gallium3D startet i 2008 hos Tungsten Graphics, og implementeringen er tilgjengelig som gratis og åpen kildekode-programvare som en del av Mesa 3D som hostes av freedesktop.org . Hovedmålet med å gjøre driverutvikling enklere, kombinere ellers duplisert kode for flere forskjellige drivere på et enkelt tidspunkt, og å støtte moderne maskinvarearkitekturer. Dette gjøres ved å gi en bedre arbeidsdeling, for eksempel å overlate minnestyring til kjernen DRI -driveren.

Gallium3D har vært en del av Mesa siden 2009 og brukes for tiden av gratis og åpen kildekode- grafikkdriver for Nvidia ( nouveau- prosjekt), for AMDs R300 - R900 , Intels 'Iris' -driver for generasjon 8+ iGPUer og for andre gratis og drivere med åpen kildekode-GPU .

Programvarearkitektur

Gallium3D letter programmeringen av enhetsdrivere ved å dele grafikkdriveren i tre deler. Dette oppnås ved introduksjonen av to grensesnitt : Gallium3D State Tracker Interface og Gallium3D WinSys Interface . De tre komponentene kalles:

Gallium3D State Tracker

• Hver grafisk API som en enhetsdriver blir adressert for, har sin egen State Tracker, f.eks. Er det en Gallium3D State Tracker for OpenGL og en annen for Direct3D eller GLX . Hver State Tracker inneholder en implementering av Gallium3D State Tracker Interface, og er unikt. Dette betyr at alle eksisterende Gallium3D -enhetsdrivere deles.

Gallium3D maskinvareenhetsdriver

• Dette er den faktiske koden, som er spesifikk for den underliggende 3D -grafiske akseleratoren, men bare så langt Gallium3D WinSys -grensesnittet tillater det. Det er en unik Gallium3D -maskinvareenhetsdriver for hver tilgjengelig grafikkbrikke, og hver implementerer Gallium3D State Tracker -grensesnittet samt Gallium3D WinSys -grensesnittet. Gallium3D -maskinvareenhetsdriveren forstår bare TGSI (Tungsten Graphics Shader Infrastructure), et mellomspråk for å beskrive shaders. Denne koden oversatte shaders oversatt fra GLSL til TGSI videre til instruksjonssett implementert av GPU.

Gallium3D WinSys

• Dette er spesifikt for den underliggende kjernen i operativsystemet, og hver og en implementerer Gallium3D WinSys -grensesnittet for grensesnitt med alle tilgjengelige Gallium3D -maskinvareenhetsdrivere.

VC4 og freedreno kan både forbruke NIR direkte (og falle tilbake til tgsi_to_nir for shaders som ikke bruker glsl_to_nir).

Illustrasjon av Linux -grafikkstakken

Mesa / DRI og Gallium3D har forskjellige drivermodeller. Begge deler en masse gratis og open-source code

En mulig eksempelmatrise ved implementering av Gallium3D -drivermodellen. Gjennom introduksjonen av Gallium3D Tracker Interface og Gallium3D WinSys Interface kreves bare 18 i stedet for 36 moduler. Hver WinSys -modul kan fungere med hver Gallium3D -enhetsdrivermodul og med hver State Tracker -modul.

Forskjeller fra klassiske grafikkdrivere

Gallium3D gir et enhetlig API som avslører standard maskinvarefunksjoner, for eksempel skyggeenheter som finnes på moderne maskinvare. Således 3D-programmeringsgrensesnitt som Åpen 1.x / 2.x, Åpen 3.x, OpenVG , GPGPU infrastruktur eller til og med Direct3D (som finnes i vin kompatibilitetslaget) trenger bare en enkelt back-end, kalt en tilstand tracker, målrettet mot Gallium3D API. Derimot krever DRI-enhetsdrivere i klassisk stil en annen backend for hver maskinvareplattform, og flere andre APIer trenger oversettelse til OpenGL på bekostning av kodeduplisering. Alle enhetsdrivere fra leverandører, på grunn av sin proprietære og lukkede kilde, er skrevet på den måten, noe som betyr at f.eks. AMD Catalyst implementerer både OpenGL og Direct3D , og leverandørdriverne for GeForce har sine implementeringer.

Under Gallium3D vil Direct Rendering Manager (DRM) kjernedrivere administrere minnet og Direct Rendering Interface (DRI2) -drivere vil være mer GPU -behandlingsorientert. I overgangsperioden fra userpace -modusinnstilling til kjerneplassmodus som noen av Mesa 3D -driverne, for eksempel radeon -driveren eller Intels drivere, endte opp med å støtte både DRI1 og DRI2 og brukte DRI2 hvis tilgjengelig på systemet. Gallium3D krever i tillegg et nivå av skyggestøtte som ikke er tilgjengelig på eldre kort som f.eks. ATi r100-r200, så brukere for disse kortene må fortsette å bruke Mesa 3D med DRI2 for deres 3D-bruk.

Wolfram Graphics Shader Infrastructure

Wolfram Graphics Shader Infrastructure ( TGSI ) er en mellomrepresentasjon som LLVM Intermediate representasjon eller den nye standard Portable Mellom Representasjon (SPIR) som skal brukes av den Vulkan API og OpenCL 2.1. Shadere skrevet i OpenGL Shading Language skal oversettes/kompileres til TGSI, deretter foretas optimaliseringer, og deretter blir TGSI -shaders kompilert til shaders for instruksjonssettet til den brukte GPUen.

NIR er den nye Layer-representasjonen i Mesa med full SPIR-V-støtte og siden 2019 hovedutviklingsområde for alle nyere drivere med OpenGL 4.6-støtte.

LLVM -bruk

GlassyMesa er en LLVM-basert kompilatorbunke for shaders skrevet i GLSL . For SSA se artikkelen Statisk enkeltoppdragsskjema .

I tillegg, ved å bruke den modulære strukturen til Gallium3D, er det et forsøk på å bruke LLVM -kompilatorsuiten og lage en modul for å optimalisere shader -kode i farten.

Biblioteket representerer hvert skyggeprogram ved å bruke en utvidbar binær mellomrepresentasjon kalt Tungsten Graphics Shader Infrastructure (TGSI), som LLVM deretter oversetter til GLSL -skyggere optimalisert for målmaskinvare.

Adopsjon

Flere gratis og open-source grafikk enhetsdrivere , som har vært, eller blir skrevet basert på informasjon oppnådd gjennom rene rommet reverse engineering , vedtatt sjåføren modellen leveres av Gallium3D, f.eks nouveau og andre ( se gratis og åpen kildekode-skjermkort driver for en fullstendig liste ). Hovedårsaken kan være at Gallium3D -drivermodellen reduserer mengden kode som må skrives. Selvfølgelig, da denne lisensen er lisensiert under en gratis programvarelisens, kan hvem som helst når som helst omskrive den for å implementere DRI- eller en annen førermodell.

Historie

Originale forfattere av Gallium3D var Keith Whitwell og Brian Paul ved Tungsten Graphics (anskaffet av VMware i 2008).

Milepæler

Høsten 2011 var det minst 10 kjente, modne og fungerende Gallium3D -drivere. Drivere med åpen kildekode for Nvidia-grafikkort med navnet Nouveau- team utvikler driverne ved hjelp av Gallium3D-rammeverket.

2008-07-13: Nouveau-utvikling utføres utelukkende for Gallium-rammeverket. Den gamle DRI -driveren ble fjernet fra hovedgrenen til Mesa -depotet på Freedesktop.org.

2009-02-11: Gallium-0.2-grenen ble slått sammen til hovedlinjen Master branch of Mesa. Utvikling er gjort i Mesa mainline.

2009-02-25: Gallium3D kan kjøres på Linux så vel som FreeBSD-kjerner.

2009-05-01: Zack Rusin fra Tungsten Graphics la til OpenVG state tracker til Mesa 3D, som gjør det mulig å akselerere Scalable Vector Graphics av en hvilken som helst Gallium3D-basert driver.

2009-07-17: Mesa3D 7.5 er utgitt, den første versjonen som inkluderer Gallium3D.

2010-09-10: Første støtte for Evergreen GPU-er ble lagt til r600g-driveren.

2010-09-21: Det er to Gallium3D-drivere for ATI-maskinvare kjent som r300g og r600g for henholdsvis R300-R500 og R600-Evergreen GPUer.

2010-09-21: Det ble gjort store forpliktelser til koden for å støtte Direct3D 10 og 11. Med tiden kan dette tilby muligheten til å bruke nylige Direct3D-implementeringer på Linux-systemer.

2011-11-30: Intel 965g og Cell Gallium-drivere ble fjernet fra hovedgrenen i Mesa som vedlikeholdt og ødelagt.

2013-11-30: Mesa 10 med OpenGL 3.2, 3.3 og OpenCL 1.0+

2014-11-18: Det ble gjort store forpliktelser til koden for å støtte Direct3D 9.

2015-09-15: Mesa 11 med OpenGL 4.0, 4.1 og OpenCL 1.2 (ufullstendig)

2015-12-15: Mesa 11.1 Driver VIRGL for virtuelle maskiner med OpenGL 3.3

2016-07-08: Mesa 12 med OpenGL 4.2, 4.3 og Vulkan 1.0 (Intel ANV og AMD RADV)

2016-11-01: Mesa 13 med OpenGL 4.4 og OpenGL ES 3.2

2017-02-13: Mesa 17.0 med OpenGL 4.5 og freedreno driver med OpenGL 3.0 og 3.1

2017-05-10: Mesa 17.1 OpenGL 4.2+ for Intel Ivy Bridge (mer enn Intel-driver for Windows, OpenGL 3.3+ for Intel Open SWR Rasterizer (viktig for klyngedatamaskin for store simuleringer)

2017-12-08: Mesa 17.3 AMD Vulkan Driver RADV full kompatibel i Khronos Test av Vulkan 1.0

2018-05-18: Mesa 18.1 med Vulkan 1.1 (Intel ANV og AMD RADV)

2018-09-07: Mesa 18.2 med OpenGL 4.3 for Soft Driver VIRGL (viktig for virtuelle maskiner i cloud Cluster Computer), OpenGL ES 3.1 for Freedreno med Adreno A5xx

2019-06-11: Mesa 19.1 utgitt med Intels neste generasjon 'iris' grafikkdriver for generasjon 8+ iGPUer

2019-12-11: Mesa 19.3 ga ut OpenGL 4.6 med Intel i965 med gen 7+ og valgfri Iris Gen 8+

2020-03-18: Mesa 20.0 ga ut OpenGL 4.6 med AMD GCN og Vulkan 1.2 for Intel

2020-05-27: Mesa 20.1 ga ut NIR-vektoriseringsstøtte og delt virtuelt minnestøtte for OpenCL i Clover

2020-11-30: Mesa 20.3 full støtte for OpenCL 1.2 i Clover

2021-03-11: Mesa 21.0 initial support of „D3D12“: Direct 3D 12 for WSL2 in Windows 10 with OpenGL 3.3+, ARM Freedreno: OpenGL 3.3+

2021-05-05: Mesa 21.1 første støtte for Google VirtIO GPU-driver "Venus" med Vulkan 1.2+; Zink: OpenGL 4.6+, OpenGL ES 3.1+; Qualcomm Turnip, Lavapipe: Vulkan 1.1+

2021-08-04: Mesa 21.2 første støtte for ny Intel Crocus OpenGL 4.6-driver basert på gallium3D til Intel Sandy Bridge til Haswell for gamle i965, Vulkan Driver panVK for ARM Panfrost

Opptreden

• Ytelses sammenligning av gratis og åpen kildekode-grafikkdrivere

Historie

Prosjektinitiativtaker Brian Paul var en grafisk hobbyist. Han syntes det ville være morsomt å implementere et enkelt 3D -grafikkbibliotek ved hjelp av OpenGL API, som han deretter kan bruke i stedet for VOGL (helt vanlig GL Like Library). Fra 1993 brukte han atten måneder med deltidsutvikling før han ga ut programvaren på Internett i februar 1995. Programvaren ble godt mottatt, og folk begynte å bidra til utviklingen. Mesa startet med å gjengi all 3D -datagrafikk på CPU -en . Til tross for dette ble den interne arkitekturen til Mesa designet for å være åpen for festing til grafikkprosessor -fremskyndet 3D -gjengivelse. I denne første fasen ble gjengivelsen gjort indirekte i skjermserveren , noe som etterlot litt overhead og merkbar hastighet som ligger bak det teoretiske maksimumet. The Diamond Monster 3D ved hjelp av Voodoo Graphics chipset, var en av de første 3D-maskinvareenheter som støttes av Mesa.

Den første sanne grafikkmaskinvarestøtten ble lagt til Mesa i 1997, basert på Glide API for de da nye 3dfx Voodoo I/II grafikkortene og deres etterfølgere. Et stort problem med å bruke Glide som akselerasjonslaget var Glides vane å kjøre fullskjerm, som bare var egnet for dataspill. Videre Glide tok låse av skjermen minne, og dermed skjerm serveren ble blokkert fra å gjøre andre oppgaver GUI.

Se også

• Gratis og åpen kildekode-enhetsdriver

Referanser

Eksterne linker

• Offesiell nettside
• Edge, Jake (oktober 2013). "Historien til Mesa" .

Eksterne lenker for Gallium3D

• freedesktop.org - Gallium3D , en artikkel om den nåværende tilstanden til Gallium3D
• Fonseca, José (april 2008), Introduction into Gallium3D
• Rusin, Zack (21. september 2007), Gallium3D
• Corbet, Jonathan (november 2007), Minnestyring for grafikkprosessorer
• Generisk GPU-akselerert videodekoding , Google Summer of Code 2008-prosjektet ved bruk av Gallium, arkivert fra originalen 31. juli 2008
• Rusin, Zack (2008), Gallium3D: Graphics Done Right (PDF) (presentasjon), Akademy
• Rusin, Zack (2008), Gallium3D: Graphics Done Right (presentasjon), Akademy , arkivert fra originalen (video) 1. januar 2011
• Oppdatering om Gallium3D -porter til AROS og Haiku (PDF) , FOSDEM 2010, 7. februar 2010