Om OpenGL

libOpenGL

Mesa kan tilby:

libGL er knyttet til libGLX. Dette er et mindre problem med vindussystemer som ikke er Xorg, og det generelle målet å ha et system uten Xorg/GLX. libglvnd gir dermed libOpenGL som ikke er knyttet til noe vindussystem. Byggesystemer som sjekker for OpenGL har en tendens til å velge libOpenGL over libGL. Det bygde resultatet vil i så fall bli koblet mot libOpenGL. Å prøve å kjøre det på et system med Mesas kjerne OpenGL biblioteker installert vil føre til feil.

I de fleste tilfeller, hvis libOpenGL ikke er funnet under bygging av et prosjekt, libGL velges i stedet. Imidlertid, i noen prosjekter som støtter Wayland, vil byggesystemet nekte å konfigurere. Dette er fordi noen byggesystemer ikke liker å kombinere libGL med libEGL.

Forskjellige Sonames

Et soname er feltet etter filtypen til et bibliotek (delt objekt). Et eksempel er libGL.so.1. Etter libGL.so er .1. 1 ville være soname. Når et program eller bibliotek er koblet mot et bibliotek, kobler det mot navnet på biblioteket med soname. Når det eneste eksisterende biblioteket på systemet har et annet soname, vil programvaren ikke fungere fordi biblioteket ikke kan finnes.

sonameene til Mesa og libglvnds kjernebiblioteker i OpenGL er forskjellige, spesielt når det gjelder libGLX. De fleste binærfiler er lenket mot libglvnds kjernebiblioteker i OpenGL, så sonameene de forventer vil ofte avvike fra Mesas kjernebiblioteker i OpenGL. AppImages har en tendens til å falle inn under dette.

Holdningen til de fleste Linux distribusjoner, BLFS, GLFS, og SLFS

De fleste Linux distribusjoner har allerede byttet til libglvnd. Noen distribusjoner, som i tilfellet med Debian, tilbyr også Mesas kjerne OpenGL biblioteker. Dermed har brukeren et alternativ i slike tilfeller. De fleste tilfeller vil ikke være slik. Den generelle holdningen basert på flertallet er at libglvnd nå er standard OpenGL leverandør for Linux.

Dette har vært tilfelle i flere år. BLFS har vært et unntak ved at det ikke har libglvnd, ikke har instruksjoner for å tillate libglvnd, og bare støtter Mesa. Forsøk på å få dette endret har blitt avvist. Standpunktet som vil stå i minst et par år fremover vil være at BLFS ikke vil støtte libglvnd. Som et resultat forårsaker dette problemer for libglvnd brukere.

Til tross for at BLFS ikke støtter libglvnd, er denne boken og Supplerende LFS ^[4] støtter og foretrekker libglvnd fremfor Mesas kjernebiblioteker i OpenGL. Problemene som er beskrevet i forrige avsnitt, utgjør problemer som oppstår i denne boken og i SLFS, og for brukere av denne boken. Mesas kjernebiblioteker i OpenGL begrenser mengden programvare en bruker kan kjøre betraktelig.

Du kan fortsatt installere Mesas kjernebiblioteker i OpenGL hvis du ønsker det, men du vil støte på problemer utenfor BLFS. Valget er opp til deg. Instruksjoner er gitt for hver rute, men standardinstruksjonene er satt opp for libglvnd.

Hva er GLES?

GLES, eller OpenGL ES, eller OpenGL for innebygde systemer, er hva det fulle navnet antyder: det er en nedskalert versjon av OpenGL, et delsett, med et litt annet API her og der. Det brukes hovedsakelig for enheter med ARM brikker som smarttelefoner og nettbrett, men brukes også i spillkonsoller. På Linux skrivebordet har du vanligvis skrivebord, eller full, OpenGL, EGL, GLX og GLESv{1,2,3}.

GLES, spesielt v2 og v3 brukes noen ganger, men hovedsakelig på ett område: i Wayland kompositorer og kompositorbiblioteker. Disse inkluderer Hyprland, Mutter, Wayfire og Wlroots. Selv om kompositorer kan bruke Vulkan, krever de fleste kompositorer GLES gjengivelse og tilbyr ikke en Vulkan løsning, eller noen annen gjengivelses-API løsning. GLESv1 er derimot en utdatert spesifikasjon av GLES API som har blitt faset ut i mange år. Denne boken deaktiverer bygging for GLESv1 ettersom den er utdatert. Du kan bygge API spesifikasjonen hvis du ønsker det.

Historien om Wayland og GLES

Når Wayland sett med protokoller ble laget, måtte det lages en referanseimplementering for å vise hva som var mulig, og hvordan man oppretter en kompositor for den nye protokollen. Resultatet var Weston. For rendering APIet sitt brukte den, og bruker, GLES og EGL. Dette ble gjort slik at avhengigheten av bibliotekene fra X Vindussystemet var ikke nødvendig, at et Wayland basert oppsett var mulig. En liten fordel med å bruke GLES var at det kunne kjøre på innebygde systemer som Raspberry Pis.

Dermed fulgte kompositorer og kompositorbiblioteker etter og gjorde det samme. Imidlertid kan ethvert renderings API brukes så lenge det kan sendes gjennom EGL. Desktop OpenGL og Vulkan kan brukes uten problemer. I dag er situasjonen den samme, og de fleste kompositorer godtar ikke noe annet renderings API enn GLES.

Trenger jeg GLES?

Hvis du ønsker å bruke Wayland kompositorer, og skal bruke en som ikke støtter Vulkan gjengivelse, må du sannsynligvis bygge GLES v2 og v3, ellers vil ikke OpenGL og EGL gjengivelse være et alternativ. Det er svært få Wayland kompositorer som støtter Vulkan og ikke krever GLES. Hvis du finner en, som dwl, trenger du egentlig ikke GLES utover kompositoren. Wayland klienter, som er applikasjoner, vil vanligvis bare bruke OpenGL og/eller Vulkan med EGL. Dette betyr at du vil kunne hoppe over GLES støtte, men vil fjerne muligheten til å bruke andre Wayland kompositorer som krever GLES gjengivelse.

På den annen side, hvis du bruker X I vindussystemet vil GLES nesten aldri bli brukt, og støtten for APIet kan deaktiveres uten særlig bekymring. Du fjerner imidlertid muligheten til å bruke Wayland kompositorer som krever GLES gjengivelse hvis du ønsker å bytte til Wayland i fremtiden.

Deaktivere GLES

Hvis du har bestemt deg for å deaktivere GLES støtte, er det ganske enkelt å ikke bygge inn støtte for APIet. «Parameterforklaringer», for både libglvnd-1.7.0 og Mesa-25.2.2, vil forklare alternativene som kreves for å deaktivere støtten. Videre, NVIDIA-580.95.05 installerer drivere for GLES. Installasjonsinstruksjonene for den driveren vil forklare hvordan du sletter dem hvis du ikke trenger GLES.

Hvis du allerede har installert GLES fra en av OpenGL leverandørene, er det ganske enkelt å fjerne alle relaterte filer. Du kan følge instruksjonene nedenfor. Som root brukeren for å fjerne APIet:

for libdir in /usr/lib*; do
  rm -vf  $libdir/pkgconfig/gles*
  rm -vrf /usr/include/GLES*
  rm -vf  $libdir/libGLES*
done
ldconfig

Kompiler eventuelle pakker på nytt for å fjerne avhengigheten av GLES.

Hvis du har bestemt deg for å angre avgjørelsen din og ønsker å bygge støtte for GLES, kan du bare kompilere OpenGL på nytt fra den opprinnelige OpenGL leverandøren du valgte uten alternativet som trengs for å deaktivere GLESv2. Du kan imidlertid beholde alternativet for å deaktivere GLESv1, ettersom v1 er en utdatert spesifikasjon og ikke nødvendig i dag.