Om OpenGL

Hva er OpenGL?

OpenGL er et grafikk API som ble utviklet av Silicon Graphics, Inc. som startet som IRIS GL. Det ble utviklet for å være plattformuavhengig, da det å få grafikk til å fungere tidligere hadde vært forskjellig på hvert sett med maskinvare. På grunn av press fra andre konkurrenter, åpnet SGI IRIS GL og kalte det OpenGL. I dag administreres OpenGL av Khronos Group, som også administrerer Vulkan. De definerer imidlertid standardene for APIene, men lager ikke drivere for APIene, og implementerer heller ikke kallene.

Så, Mesa kom inn og implementerte drivere og funksjoner for OpenGL. De implementerer også GLX og EGL som gir grensesnitt til vindussystemer som Xorg. Metoden deres håndterer imidlertid ikke anropene på en leverandørnøytral måte. For det meste er denne tilnærmingen grei og fører ikke til noen problemer. NVIDIA har bestemt at dette var en dårlig nok tilnærming til å rettferdiggjøre en ny implementering av OpenGL kalt libglvnd. Den tilbyr bare implementeringene for OpenGL, OpenGL ES, GLX og EGL. Dette har ført til eldre OpenGL kontra ny OpenGL på Linux.

Det finnes libGL som nå regnes som eldre OpenGL og leveres av både Mesa-25.1.4 og libglvnd-1.7.0. I mellomtiden er det libOpenGL som regnes som den nye OpenGL og leveres kun av libglvnd-1.7.0. Apper og biblioteker som lenker mot den gamle OpenGL vil fungere med begge leverandørene, men lenking mot den nye OpenGL, som bare har dispatching funksjoner, vil føre til at disse binærfilene blir ødelagt på systemer med bare Mesa-25.1.4 installert.

Dette er bare et problem for pakker som kun inneholder binære filer, og noen CMake byggesystemer. For denne boken og i BLFS, bør du ikke støte på noen av disse problemene med mindre du ønsker å bruke NVIDIA-575.64, som spesifikt krever libglvnd-1.7.0. SLFS har som mål å omgå problemer som oppstår fra pakker som har gjenstridige byggesystemer, som i tilfellet med OBS-Studio. For pakker som kun inneholder binærfiler, er det vanligvis ulikt om utviklerne lenker mot ny eller eldre OpenGL. Et spilleksempel er med porteringer og rekompileringer: binærfilen for Ship of Harkinian, en PC portering av Nintendo 64 spillet, Legend of Zelda: Ocarina of Time, lenker mot nye OpenGL og vil bare bli ødelagt med Mesa installert; dessuten fører det også til mange problemer å prøve å omgå problemet ved å bygge fra kildekode. Imidlertid er binærfilen til PC porteringen laget av statisk rekompilering av Nintendo 64 spillet, Legend of Zelda: Majora's Mask, kalt Zelda 64: Recompiled, lenker mot eldre OpenGL og fungerer med begge OpenGL leverandørene.

Hvis du bare vil ha eldre OpenGL, kan du bare installere Mesa-25.1.4. Hvis du ønsker ny OpenGL, støtte for noen binære fil pakker, NVIDIA-575.64, og komme forbi noen CMake byggesystemer, installer libglvnd-1.7.0. Hvis du ønsker en driver fra Mesa-25.1.4, kan du bygge det etter libglvnd. Mesa vil automatisk oppdage libglvnd og vil hoppe over å bygge OpenGL implementeringene sine.

[Notat]

Notat

Når du er i tvil, installer libglvnd-1.7.0. Førstegangsbyggere oppfordres på det sterkeste å installere denne.

[Viktig]

Viktig

Det anbefales ikke å bytte mellom leverandører. Du bør velge nøye hvilken leverandør du skal installere fra. Hvis du vil bytte, kan det være best å bygge systemet på nytt.

Om GLES (OpenGL ES)

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, nærmere bestemt v2 og v3, brukes noen ganger, men for det meste i ett område. Et slikt område er i Wayland kompositorer og kompositorerbiblioteker, som for eksempel Hyprland, Mutter, Wayfire, og Wlroots. Selv om kompositore kan bruke Vulkan, krever de fleste kompositore GLES rendering og tilbyr ikke en Vulkan løsning, eller noen annen rendering 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 siden 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.1.4, vil forklare alternativene som kreves for å deaktivere støtten. Videre, NVIDIA-575.64 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.