Mesa (grafika komputerowa) - Mesa (computer graphics)

Mesa

Pierwotny autor (autorzy)	Brian Paul
Deweloper(zy)	Obecnie: Intel , AMD , VMware Dawniej: Tungsten Graphics
Pierwsze wydanie	Luty 1995
Wersja stabilna	21.2.3  / 29 września 2021 ; 18 dni temu ( 29 września 2021 )
Magazyn
Napisane w	C , C++ , asembler
System operacyjny	Wieloplatformowy ( BSD , Haiku , Linux itp.)
Rodzaj	Biblioteka grafik
Licencja	Licencja MIT
Strona internetowa	mesa3d .org

Mesa , zwana także Mesa3D i The Mesa 3D Graphics Library , to implementacja oprogramowania typu open source dla specyfikacji OpenGL , Vulkan i innych graficznych interfejsów API . Mesa tłumaczy te specyfikacje na sterowniki sprzętu graficznego specyficzne dla dostawcy.

Jego najważniejszymi użytkownikami są dwa sterowniki graficzne, w większości opracowane i finansowane przez Intel i AMD dla ich odpowiedniego sprzętu (AMD promuje swoje sterowniki Mesa Radeon i RadeonSI zamiast przestarzałego AMD Catalyst , a Intel wspiera tylko sterownik Mesa). Opatentowane sterowniki graficzne (np. sterownik Nvidia GeForce i Catalyst) zastępują wszystkie Mesa, zapewniając własną implementację graficznego API. Wysiłek open-source mający na celu napisanie sterownika Mesa Nvidia o nazwie Nouveau jest w większości rozwijany przez społeczność.

Oprócz aplikacji 3D, takich jak gry, nowoczesne serwery wyświetlaczy ( X.org w Glamour lub Wayland „s Weston ) wykorzystanie OpenGL / EGL ; dlatego wszystkie grafiki zazwyczaj przechodzą przez Mesę.

Mesa jest hostowana przez freedesktop.org i została zainicjowana w sierpniu 1993 roku przez Briana Paula , który nadal jest aktywny w projekcie. Mesa została następnie szeroko przyjęta i obecnie zawiera wiele wkładów od różnych osób i korporacji na całym świecie, w tym od producentów sprzętu graficznego z Khronos Group, którzy zarządzają specyfikacją OpenGL. W przypadku Linuksa rozwój był również częściowo napędzany przez finansowanie społecznościowe .

Przegląd

Gry wideo zlecają obliczenia renderowania do GPU przez OpenGL w czasie rzeczywistym. Shadery są napisane w OpenGL Shading Language lub SPIR-V i kompilowane na procesorze. Skompilowane programy są wykonywane na GPU.

Ilustracja stosu graficznego Linuksa : DRM i libDRM, Mesa 3D . Serwer wyświetlania należy do systemu okienkowego i nie jest potrzebny np. do gier.

Implementacje renderujących API

Bezpłatne implementacje Waylanda opierają się na implementacji EGL w Mesa . Specjalna biblioteka o nazwie libwayland-EGL , napisana w celu obsługi dostępu do bufora ramki , powinna zostać uznana za przestarzałą w wydaniu EGL 1.5. Na GDC 2014 AMD badało zmianę strategii w kierunku korzystania z DRM zamiast ich blobów w jądrze.

Mesa jest znana jako implementacja obudowy graficznych interfejsów API . Historycznie głównym interfejsem API, który zaimplementował Mesa, jest OpenGL , wraz z innymi specyfikacjami związanymi z Khronos Group (jak OpenVG , OpenGL ES lub ostatnio EGL ). Ale Mesa może zaimplementować inne API i rzeczywiście zrobiła to z Glide (przestarzałe) i Direct3D 9 od lipca 2013. Mesa nie jest również specyficzna dla systemów operacyjnych podobnych do Uniksa: na przykład w systemie Windows Mesa zapewnia API OpenGL przez DirectX.

Mesa implementuje warstwę translacji między graficznym interfejsem API, takim jak OpenGL, a sterownikami sprzętu graficznego w jądrze systemu operacyjnego. Obsługiwana wersja różnych graficznych interfejsów API zależy od sterownika, ponieważ każdy sterownik sprzętu ma własną implementację (a zatem status). Jest to szczególnie prawdziwe w przypadku „klasycznych” sterowników, podczas gdy sterowniki Gallium3D mają wspólny kod, który ma tendencję do ujednolicania obsługiwanych rozszerzeń i wersji.

Mesa utrzymuje macierz wsparcia ze statusem aktualnej zgodności z OpenGL zwizualizowanym w mesamatrix .net . Mesa 10 jest zgodna z OpenGL 3.3, dla sprzętu GPU Intel, AMD/ATI i Nvidia. Mesa 11 została ogłoszona z niektórymi sterownikami zgodnymi z OpenGL 4.1.

Mesa 12 zawiera obsługę OpenGL 4.2 i 4.3 oraz Intel Vulkan 1.0.

Mesa 13 wprowadziła wsparcie Intela dla OpenGL 4.4 i 4.5 (wszystkie funkcje obsługiwane dla Intel Gen 8+, Radeon GCN, Nvidia (Fermi, Kepler), ale nie Khronos-Test dla 4.5-Label) i eksperymentalne wsparcie AMD Vulkan 1.0 poprzez sterownik społeczności RADV. OpenGL ES 3.2 jest możliwy dzięki Intel Skylake (Gen9).

Pierwsza stabilna wersja 2017 to 17.0 (liczenie nowego roku). Gotowe funkcje to certyfikowane OpenGL 4.5, OpenGL 4.5 dla Intel Haswell, OpenGL 4.3 dla NVidia Maxwell i Pascal (GM107+). Ogromny wzrost wydajności został zmierzony z Maxwell 1 (GeForce GTX 750 Ti i więcej z GM1xx). Karty Maxwell-2-Card (GeForce GTX 980 i więcej z GM2xx) są podkręcone bez informacji NVidii.

Zestaw testów Khronos CTS dla OpenGL 4.4, 4.5 i OpenGL ES 3.0+ jest teraz (2017-01-24) Open Source, a wszystkie testy dla Mesy 13 i 17 są teraz możliwe bez żadnych kosztów.

Druga stabilna wersja 2017, 17.1.0, wyszła 10 maja 2017 z kilkoma interesującymi ulepszeniami. OpenGL 4.2+ dla Intel Ivy Bridge i OpenGL 3.3+ dla Intel Open SWR Rasterizer to dwie z najważniejszych atrakcji.

Zauważ, że ze względu na modularną naturę OpenGL, Mesa może faktycznie obsługiwać rozszerzenia z nowszych wersji OpenGL bez żądania pełnego wsparcia dla takich wersji. Na przykład w lipcu 2016 r. Mesa obsługiwała OpenGL ES 3.1, ale także wszystkie rozszerzenia OpenGL ES 3.2 z wyjątkiem pięciu, a także szereg rozszerzeń, które nie są częścią żadnej wersji OpenGL lub OpenGL ES.

Otwartą kwestią dla Mesy i Linuksa jest High Dynamic Range (HDR). Wiele problemów i otwartych punktów czeka na czystą i podstawową implementację.

Trzecia wersja 17.2 jest dostępna od września 2017 roku z kilkoma nowymi funkcjami OpenGL 4.6 i ulepszeniami szybkości w 3D dla Intel i AMD. Tylko 1,4% testów kończy się niepowodzeniem dla OpenGL 4.5 w Nouveau dla Keplera.

4. Wersja 17.3 jest gotowa od grudnia 2017. Dostępnych jest wiele ulepszeń w wielu sterownikach. OpenGL 4.6 jest prawie w pełni dostępny (Spir-V nie jest gotowy). AMD Vulkan Driver RADV jest teraz w pełni zgodny z testem Khronos.

Pierwsza wersja 2018 to 18.0 i dostępna od marca 2018 według tego samego schematu w 2017. Pełna obsługa OpenGL 4.6 nie jest jeszcze gotowa, ale wiele funkcji i ulepszeń zostało pomyślnie przetestowanych w RC3. 10-bitowe wsparcie dla Intel i965 w kolorach to także wyróżnienie. Nowością jest wsparcie dla Intel Cannon Lake i AMD Vega z aktualną wersją Linux. Chipy AMD Evergreen (RV800 lub R900) są bliskie wsparcia OpenGL 4.5. Stare układy AMD R600 lub RV700 obsługują tylko OpenGL 3.3 z niektórymi funkcjami OpenGL 4.x. Freedreno to sterownik dla sprzętu Adreno i bliskie wsparcie dla OpenGL 3.3.

Druga wersja 2018 to 18.1 i dostępna od maja. Celem jest Vulkan 1.1.72 w sterowniku Intel ANV i AMD RADV. OpenGL 4.6 ze spir-V jest również głównym celem. Stała praca to możliwość uzupełnienia funkcji i optymalizacji sterowników dla starszego sprzętu jak AMD R600/Evergreen, Nvidia Tesla i wcześniejsze, Fermi, Kepler czy Intel Sandybridge, Ivybridge, Haswell czy Broadwell. Architektura ARM dokonała również znacznych ulepszeń w Adreno 3xx/4xx/5xx i Broadwell VC4/VC5 dla Raspi z głównym docelowym OpenGL ES.

Trzecia wersja 2018 to 18.2 i dostępna w stabilnej kalendarzu we wrześniu. OpenGL 4.6 ze spir-V i Vulkan 1.1.80 są w WIP. Soft Driver dla maszyn wirtualnych VIRGL jest gotowy dla OpenGL 4.3 i OpenGL ES 3.2. RadeonSI jest również gotowy na OpenGL ES 3.2. Obsługa kompresji tekstur ASTC i obsługa modu zgodności dla OpenGL 4.4 (3.1 w 18.1) to inne zalety RadeonSI dla kart AMD GCN. Dostępny jest nowy Vulkan 1.1 i więcej funkcji dla Intela i AMD. Zobacz więcej szczegółów dotyczących Vulkan w Mesamatrix.

Czwarta wersja 2018 to 18.3 i wydana jako stabilna wersja 18.3.1 w grudniu 2018. Wiele szczegółowych funkcji i obsługa nowszego sprzętu to główne części. Pełna obsługa OpenGL 4.6 nie jest gotowa.

Pierwsza wersja 2019 to 19.0 i została wydana w marcu. Pełna obsługa OpenGL 4.6 nie jest jeszcze gotowa, ale wiele ulepszeń w ten sposób znajduje się we wszystkich sterownikach.

Druga wersja 2019 to 19.1. Przejście z TGSI do NIR jest tutaj jedną z głównych funkcji na drodze do OpenGL 4.6 ze Spir-V i więcej OpenCL. RadeonSI działa dobrze w wersji deweloperskiej z NIR.

Trzecia wersja 2019 to 19.2. OpenGL 4.6 jest gotowy do wersji Beta dla nowego sterownika Intel Iris.

4. Wersja 2019 to 19.3. OpenGL 4.6 jest gotowy na Intel i965 i opcjonalnie dla nowego sterownika Iris.

Pierwsza wersja 2020 to 20.0. Vulkan 1.2 jest gotowy na AMD RADV i Intel ANV. Intel Iris jest domyślny dla Intel Broadwell Gen 8+. Sterownik RadeonSI domyślnie przełączył się na NIR zamiast TGSI.

Druga wersja 2020 to 20.1. Wiele ulepszeń jest gotowych w wielu sterownikach. Zink to nowy wirtualny sterownik OpenGL over Vulkan.

Trzecia wersja 2020 to 20.2. Jedną z nowych funkcji jest OpenGL 3.0 dla Zink. LLVMpipe obsługuje OpenGL 4.3+ (4.5+ w 20.3). ARM Panfrost jest w większości ulepszony za pomocą wielu modułów. Współdzielona pamięć wirtualna jest możliwa dla OpenCL w Nouveau z Pascalem i wyższymi.

Czwarta wersja 2020 to 20.3. v3d i v3dv to nowe sterowniki dla OpenGL i Vulkan 1.0 ze sprzętem Broadcom, takim jak Raspberry Pi 4. OpenCL 1.2 jest w pełni obsługiwany w module Clover. Zink obsługuje OpenGL 3.3+. Sterownik wirtualny LLVMpipe obsługuje teraz OpenGL 4.5+ z widokiem 4.6. VALLIUM jako drzewo Vulkan z LLVMpipe zostaje połączone.

W Mesie 21.0 d3d12 zostanie połączone z OpenGL 3.0 do 3.3. Microsoft i Collabora opracowują nową emulację d3d12 w WSL2 do Windows 10 z Direct 3D 12. OpenCL 1.2 jest również celem w d3d12. Przyspieszenie od 2 do 5 odbywa się w Benchmark SPECviewperf z ulepszonym kodem OpenGL. Wiele funkcji Mesa 21.0 poprawia wydajność. Nowa wersja 21.0.0 jest upubliczniona od 11 marca 2021 r.

Mesa 21.1 to drugie wydanie roku 2021. OpenGL 4.6+ i OpenGL ES 3.1+ są dostępne dla Zink. AMD Driver 600g może zmienić się na NIR z większymi możliwościami dla starych kart Radeeon HD 5000 i 6000. Qualcomm Turnip osiąga Vulkan 1.1+ i emulację oprogramowania Lavapipe Vulkan 1.1+. Sterownik GPU Google VirtIO Venus z Vulkan 1.2+ jest połączony w stanie eksperymentalnym z niską wydajnością w głównym drzewie mesa.

Mesa 21.2 to trzecia wersja z roku 2021. Google Virtual Vulkan IO Driver Venus zostanie oficjalnie wprowadzony z pełną obsługą Vulkan 1.2+ (więcej mesamatrix). ARM Panfrost: Obsługa OpenGL ES 3.1+ jest dostępna, a panVK to nowy sterownik Vulkan. Pierwsze wsparcie rozpoczęło się dla ARM Apple M1 z nowym sterownikiem Asahi. 21.2 jest dostępne od 4 sierpnia 2021 r.

Stary plan polega na podzieleniu starych sterowników na klasyczne drzewo z wieloma zaletami w programowaniu, obsłudze i naprawianiu błędów dla nowoczesnej części 3D z galu. Jednym z problemów jest tutaj Intel i965 z obsługą popularnego starego sprzętu do Intel Haswell, a wcześniej również z obsługą Windows 10. Nowy sterownik Gallium3D Crocus dla Intel Gen 4 Graphics do Haswell jest w trakcie opracowywania, aby uzupełnić tutaj obszar gallium3D z możliwym podziałem w następnej porze roku 2021. Crocus jest opcjonalny dostępny w 21.2.

Tabela renderowania API

Vulkan

Khronos Group oficjalnie ogłosił Vulkan API w marcu 2015 roku, a oficjalnie wydany Vulkan 1.0 w dniu 16 lutego 2016 r Vulkan przerwy zgodności z OpenGL i całkowicie porzuca swoją monolityczną stan maszyny koncepcji. Twórcy Gallium3D nazwali Vulkan czymś na wzór Gallium3D 2.0 – Gallium3D oddziela kod implementujący maszynę stanów OpenGL od kodu specyficznego dla sprzętu.

Gdy Gallium3D przyjmuje TGSI, Vulkan przyjmuje SPIR-V ( Standard Portable Intermediate Representation wersja „V” jak w „Vulkan”).

Intel udostępnił implementację sterownika Vulkan dla swojego sprzętu w dniu oficjalnej publikacji specyfikacji, ale został on wprowadzony w kwietniu i stał się częścią Mesa 12.0, wydanego w lipcu 2016 roku. Chociaż już sterownik i965 nie został napisany zgodnie z specyfikacji Gallium3D, dla sterownika Vulkan jeszcze mniej sensowne jest umieszczanie go na górze Gallium3D. Podobnie nie ma żadnego technicznego powodu, aby łączyć go z NIR, ale mimo to pracownicy Intela zaimplementowali w ten sposób swój sterownik Vulkan.

Można się spodziewać, że autorski sterownik Vulkan firmy AMD, który został wydany w marcu i został ogłoszony w przyszłości jako darmowe oprogramowanie o otwartym kodzie źródłowym i zostanie włączony do Mesy, również porzuca Gallium3D.

RADV to darmowy projekt dla AMD i jest dostępny od wersji 13. Zgodność z testem Khronos pojawiła się w wersji 17.3. Rzeczywiste jest pełne wsparcie dla Vulkan 1.0 i 1.1 od Mesy 18.1.

Nvidia wydała swój zastrzeżony sterownik GeForce z obsługą Vulkan w dniu premiery, a Imagination Technologies (PowerVR), Qualcomm (Adreno) i ARM (Mali) zrobiły to samo lub przynajmniej ogłosiły własne sterowniki Vulkan dla Androida i innych systemów operacyjnych. Ale kiedy i czy pojawią się dodatkowe darmowe i open-source implementacje Vulkan dla tych procesorów graficznych, dopiero się okaże.

Mesa Software Driver VIRGL rozpoczyna Vulkan Development w 2018 roku z projektami GSOC dotyczącymi obsługi maszyn wirtualnych.

Lavapipe to oparty na procesorze sterownik Software Vulkan i brat LLVMpipe. Mesa w wersji 21.1 obsługuje Vulkan 1.1+.

Google wprowadza Venus Vulkan Driver dla maszyn wirtualnych w Mesa 21.1 z pełną obsługą Vulkan 1.2+.

Qualcomm Turnip i Broadcom v3dv to nowe sterowniki dla sprzętu Qualcomm Adreno i Broadcom Raspberry 4. Rzepa jest wolkańskim bratem freedreno dla OpenGL. V3dv obsługuje Vulkan 1.0+ od wersji Mesa 20.3. W wersji 21.1 Rzepa obsługuje Vulkan 1.1+.

Wyraźne ogrodzenie

Rodzaj bariery pamięci, która oddziela jeden bufor od reszty pamięci, nazywa się ogrodzeniem. Ogrodzenia mają zapewnić, że bufor nie zostanie nadpisany przed zakończeniem na nim operacji renderowania i wyświetlania. Niejawne ogrodzenie służy do synchronizacji sterowników graficznych ze sprzętem GPU. Ogrodzenie sygnalizuje, że bufor nie jest już używany przez jeden komponent, dzięki czemu może być obsługiwany lub ponownie używany przez inny. W przeszłości jądro Linuksa miało ukryty mechanizm ogrodzenia, w którym ogrodzenie było bezpośrednio dołączone do bufora (por. uchwyty GEM i FD), ale przestrzeń użytkownika nie jest tego świadoma. Jawne ogrodzenie udostępnia ogrodzenia w przestrzeni użytkownika, gdzie przestrzeń użytkownika otrzymuje ogrodzenia zarówno z podsystemu Direct Rendering Manager (DRM), jak i z GPU. Wyraźne ogrodzenie jest wymagane przez Vulkan i oferuje korzyści w zakresie śledzenia i debugowania.

Jądro Linuksa 4.9 dodało ramy synchronizacji Androida do mainline.

Ogólne zarządzanie buforami

Generic Buffer Management (GBM) to interfejs API, który zapewnia mechanizm przydzielania buforów do renderowania grafiki powiązanej z Mesą. GBM ma być używany jako natywna platforma dla EGL na DRM lub openwfd. Utworzony uchwyt może służyć do inicjowania EGL i tworzenia buforów docelowych renderowania.

Mesa GBM to abstrakcja interfejsów API zarządzania buforami specyficznych dla sterowników graficznych (na przykład różnych bibliotek libdrm_*), zaimplementowanych wewnętrznie przez wywołanie sterowników GPU Mesa.

Na przykład kompozytor Wayland Weston wykonuje renderowanie za pomocą OpenGL ES 2, które inicjuje, wywołując EGL. Ponieważ serwer działa na „gołym sterowniku KMS ”, używa platformy EGL DRM, którą można nazwać platformą GBM, ponieważ opiera się na interfejsie Mesa GBM.

Na XDC2014 pracownik Nvidii Andy Ritger zaproponował ulepszenie EGL w celu zastąpienia GBM. Społeczność nie przyjęła tego pozytywnie i Nvidia ostatecznie zmieniła zdanie i przyjęła inne podejście.

Implementacje API akceleracji wideo

Istnieją trzy możliwe sposoby wykonania obliczeń niezbędnych do kodowania i dekodowania strumieni wideo:

1. użyj implementacji oprogramowania algorytmu kompresji lub dekompresji wideo (powszechnie zwanego KODEK) i uruchom to oprogramowanie na C PU
2. użyj implementacji oprogramowania algorytmu kompresji lub dekompresji wideo (powszechnie zwanego KODEK) i uruchom to oprogramowanie na G PU ( silnik renderowania 3D )
3. używać pełnej (lub częściowej) implementacji sprzętowej algorytmu kompresji lub dekompresji wideo; bardzo powszechne stało się integrowanie takich układów ASIC z chipem GPU/CPU/APU/SoC i dlatego jest powszechnie dostępne; z powodów marketingowych firmy stworzyły marki dla swoich układów ASIC, takie jak PureVideo (Nvidia), Unified Video Decoder (AMD), Video Coding Engine (AMD), Quick Sync Video (Intel), DaVinci (Texas Instruments), CedarX (Allwinner), Kryształ HD (Broadcom); niektóre ASIC są dostępne do licencjonowania jako rdzeń własności intelektualnej półprzewodników ; zazwyczaj różne wersje implementują różne algorytmy kompresji i/lub dekompresji wideo; wsparcie dla takich ASIC zwykle należy do sterownika jądra, aby inicjalizować sprzęt i robić rzeczy niskopoziomowe. Mesa, która działa w przestrzeni użytkownika, zawiera implementacje kilku interfejsów API dla oprogramowania, np. VLC media player , GStreamer , HandBrake itp., aby wygodnie uzyskać dostęp do takich ASIC:

• Video Acceleration API (VAAPI) – najpopularniejszy interfejs API dla systemu Linux, używany przez AMD i Intel
• Video Decode and Presentation API for Unix (VDPAU) – używane przez Nvidię
• Akceleracja wideo DirectX (DXVA) — tylko w systemie Microsoft Windows
• OpenMAX IL – zaprojektowany przez Khronos Group do kompresji wideo
• Distributed Codec Engine (DCE) – zaprojektowany przez Texas Instruments
• X-Video Bitstream Acceleration (XvBA) – rozszerzenie do Xv – zastąpione przez VAAPI
• X-Video Motion Compensation (XvMC) – rozszerzenie do Xv – zastąpione przez VAAPI

Na przykład Nouveau , który został opracowany jako część Mesa, ale zawiera również komponent jądra Linux, który jest rozwijany jako część jądra Linux, obsługuje ASIC marki PureVideo i zapewnia dostęp do nich przez VDPAU i częściowo przez XvMC .

Darmowy sterownik radeon obsługuje zunifikowany dekoder wideo i silnik kodowania wideo za pośrednictwem VDPAU i OpenMAX.

Należy pamiętać, że V4L2 jest interfejsem jądra do przestrzeni użytkownika dla strumieni bitów wideo dostarczanych przez kamery internetowe lub tunery telewizyjne.

Sterowniki urządzeń

Sterowniki urządzeń graficznych są implementowane przy użyciu dwóch składników: UMD (sterownik trybu użytkownika) i KMD (sterownik trybu jądra). Począwszy od jądra Linuksa 4.2 AMD Catalyst i Mesa będą współużytkować ten sam sterownik jądra Linuksa: amdgpu . Amdgpu udostępnia interfejsy zdefiniowane przez DRM i KMS.

Dostępne bezpłatne sterowniki urządzeń o otwartym kodzie źródłowym dla chipsetów graficznych są „zarządzane” przez firmę Mesa (ponieważ istniejąca darmowa implementacja interfejsów API o otwartym kodzie źródłowym jest rozwijana wewnątrz firmy Mesa). Obecnie istnieją dwa frameworki do pisania sterowników graficznych: „klasyczny” i Gallium3D. Przegląd niektórych (ale nie wszystkich) sterowników dostępnych w Mesie znajduje się na stronie mesamatrix .net .

Istnieją sterowniki urządzeń dla kart AMD/ATI R100 do R800, Intel i Nvidia z akceleracją 3D. Wcześniej istniały sterowniki dla APU IBM/Toshiba/Sony Cell dla PlayStation 3 , chipsetów S3 Virge & Savage, chipsetów VIA, Matrox G200 i G400 i innych.

Darmowe i otwarte sterowniki konkurują z zastrzeżonymi sterownikami o zamkniętym kodzie źródłowym. W zależności od dostępności dokumentacji sprzętowej i siły roboczej, darmowy sterownik o otwartym kodzie źródłowym mniej lub bardziej pozostaje w tyle we wspieraniu akceleracji 3D nowego sprzętu. Ponadto wydajność renderowania 3D była zwykle znacznie wolniejsza, z kilkoma godnymi uwagi wyjątkami. Dziś jest to nadal prawdziwe w przypadku większości procesorów graficznych NVIDIA w przypadku Nouveau, podczas gdy w przypadku procesorów graficznych AMD Radeon otwarty sterownik w większości odpowiada lub przewyższa wydajność zastrzeżonego sterownika.

Infrastruktura bezpośredniego renderowania (DRI)

W czasie, gdy karty graficzne 3D stały się bardziej popularne na komputerach PC, osoby częściowo wspierane przez niektóre firmy zaczęły pracować nad dodaniem większej obsługi akcelerowanego sprzętowo renderowania 3D do Mesy. Infrastruktura Direct Rendering (DRI) był jednym z tych podejść do interfejsu Mesa, OpenGL i innych bibliotek API renderowania 3D ze sterownikami urządzeń i sprzętu. Po osiągnięciu podstawowego poziomu użyteczności, obsługa DRI została oficjalnie dodana do Mesy. To znacznie rozszerzyło dostępny zakres wsparcia sprzętowego osiągalnego podczas korzystania z biblioteki Mesa.

Wraz z dostosowaniem się do DRI, biblioteka Mesa przejęła wreszcie rolę komponentu frontendowego pełnowymiarowego frameworka OpenGL z różnymi komponentami zaplecza, które mogą oferować różne stopnie wsparcia sprzętowego 3D, nie rezygnując przy tym z pełnej możliwości renderowania oprogramowania. Cały system wykorzystywał wiele różnych komponentów oprogramowania.

Chociaż projekt wymaga ostrożnego współdziałania wszystkich tych komponentów, interfejsy między nimi są stosunkowo stałe. Niemniej jednak, ponieważ większość komponentów wchodzących w interakcję ze stosem Mesy to komponenty typu open source, prace eksperymentalne często przeprowadza się poprzez zmianę kilku komponentów jednocześnie, a także interfejsów między nimi. Jeśli takie eksperymenty okażą się skuteczne, można je włączyć do następnego wydania głównego lub drugorzędnego. Dotyczy to m.in. aktualizacji specyfikacji DRI opracowanej w perspektywie 2007-2008. Rezultat tego eksperymentu, DRI2, działa bez zamków i z ulepszonym wsparciem tylnego bufora. W tym celu stworzono specjalny oddział git firmy Mesa.

DRI3 jest obsługiwany przez sterownik Intel od 2013 roku i jest domyślnie używany w niektórych dystrybucjach Linuksa od 2016 roku, aby umożliwić obsługę Vulkan i nie tylko. Jest również domyślnie używany na sprzęcie AMD od końca 2016 r. (X.Org Server 1.18.3 i nowsze).

Renderowanie oprogramowania

Mesa zawiera również implementację renderowania oprogramowania o nazwie swrast, która umożliwia działanie shaderów na procesorze jako awaryjne, gdy nie ma akceleratorów sprzętowych graficznych. Rasteryzator oprogramowania Gallium jest znany jako softpipe lub gdy został zbudowany z obsługą LLVM llvmpipe , który generuje kod procesora w czasie wykonywania. Ponieważ Mesa 10.x OpenGL 3.3+ jest obsługiwany dla Softpipe (10.3) i LLVMpipe (10.2). W rzeczywistości około 80% funkcji z OpenGL 4.x jest zaimplementowanych w Mesa 17.3 (patrz Mesamatrix).

W Mesa 12.0 dostępny jest nowy Rasterizer OpenSWR firmy Intel z dużymi zaletami w klastrach dla dużych zestawów danych. Koncentruje się bardziej na wizualizacji inżynierskiej niż na obrazach w grach lub grafikach i może działać tylko na procesorach x86. Z drugiej strony, OpenGL 3.1+ jest teraz obsługiwany. W niektórych przykładach zmierzono wartości przyspieszenia od 29 do 51 związane z LLVMPIPE. OpenGL 3.3+ jest obsługiwany dla OpenSWR od wersji Mesa 17.1.

VirGL to Rasterizer dla maszyn wirtualnych zaimplementowany w Mesa 11.1 od 2015 roku z obsługą OpenGL 3.3 i pokazywany w Mesamatrix od Mesa 18. W aktualnej nowej Mesie 18.2 obsługuje więcej niż inne z OpenGL 4.3 i OpenGL ES 3.2. Około 80% funkcji OpenGL 4.4 i 4.5 jest teraz gotowych. Vulkan Development rozpoczyna się od projektów GSOC 2018.

D3d12 to projekt Microsoftu do emulacji WSL2 OpenGL 3.3+ i OpenCL 1.2+ z Direct3D 12. D3D12 jest scalony w 21.0.

Venus to nowy sterownik GPU Vulkan VirtIO dla GPU w maszynach wirtualnych firmy Google. Wenus połączyła się w 21.1, a dla publiczności w 21.2 wprowadzono.

Mega kierowcy

Pomysł połączenia wielu sterowników w jeden „mega” został zaproponowany przez Emmę Anholt. Pozwala na użycie pojedynczej kopii współdzielonego kodu Mesa wśród wielu sterowników (zamiast tego, który istnieje w każdym sterowniku osobno) i oferuje lepszą wydajność niż oddzielna współdzielona biblioteka ze względu na usunięcie wewnętrznego interfejsu biblioteki. Śledzenie stanu dla VDPAU i XvMC stały się osobnymi bibliotekami.

shader-db

shader-db to zbiór około 20 000 shaderów zebranych z różnych gier komputerowych i testów porównawczych, a także kilka skryptów do ich kompilacji i zbierania statystyk. Shader-db ma na celu pomóc w walidacji optymalizacji.

Zauważono, że nieoczekiwana liczba shaderów nie jest pisanych ręcznie, ale generowanych. Oznacza to, że te shadery zostały pierwotnie napisane w HLSL, a następnie przetłumaczone na GLSL przez jakiś program tłumaczący, taki jak np . HLSL2GLSL . Problem w tym, że wygenerowany kod często nie jest optymalny. Matt Turner powiedział, że o wiele łatwiej jest naprawić to w programie tłumacza, niż zmuszać kompilator Mesy do dźwigania ciężaru radzenia sobie z tak rozdętymi shaderami.

shader-db nie może być uważany za oprogramowanie darmowe i o otwartym kodzie źródłowym. Aby używać go legalnie, trzeba mieć licencję na wszystkie gry komputerowe, których częścią są shadery.

Architektura oprogramowania

Sterownik graficzny składa się z implementacji maszyny stanu OpenGL i stosu kompilacji do kompilacji shaderów do języka maszynowego GPU. Ta kompilacja, podobnie jak prawie wszystko inne, jest wykonywana na procesorze, a następnie skompilowane shadery są wysyłane do GPU i są przez niego wykonywane. (SDL = prosta warstwa DirectMedia ).

Pośredni reprezentacje (IRS), w Mesa GLSL IR Mesa IR TGSI i LLVM IR . Brakuje HIR, LIR i NIR.

Mesa IR ma zostać całkowicie usunięta.

Tak zwane „sterowniki urządzeń graficznych trybu użytkownika” (UMD) w Mesa mają bardzo niewiele podobieństw do tego, co ogólnie nazywa się sterownikiem urządzenia . Istnieje kilka różnic:

• mają pracować na dodatkowo istniejących sterownikach urządzeń graficznych trybu jądra, które są np. dostępne jako część jądra Linux, które można znaleźć w kodzie źródłowym pod /drivers/gpu/drm/Każdy UMD komunikuje się ze swoim odpowiednikiem w trybie jądra za pomocą określonej biblioteki, nazwa libdrm_specific oraz ogólny, o nazwie libdrm . Ta sekcja będzie dotyczyć wyłącznie części trybu użytkownika powyżej libdrm
• istnieje pewna implementacja maszyny skończonej określonej np. przez OpenGL; ta implementacja automatu stanu OpenGL może być współużytkowana przez wiele UMD lub nie
• składają się one w dużej mierze z pewnego rodzaju kompilatora, który pobiera np. GLSL i ostatecznie wyświetla kod maszynowy . Parsery mogą być współdzielone przez wiele UMD lub być specyficzne

Reprezentacje pośrednie Mesy

Jednym z celów Mesy jest optymalizacja kodu, który ma być wykonywany przez odpowiedni procesor graficzny. Innym jest dzielenie się kodem. Zamiast dokumentować fragmenty oprogramowania, które robią to lub tamto, ten artykuł Wikipedii powinien zamiast tego przyjrzeć się reprezentacji pośredniej używanej w procesie kompilacji i optymalizacji. Zobacz abstrakcyjne drzewo składni (AST) i statyczny formularz pojedynczego przypisania (formularz SSA).

SPIR-V

SPIR-V jest pewną wersją Standard Portable Intermediate Representation . Pomysł polega na tym, że aplikacje graficzne wyświetlają SPIR-V zamiast GLSL. W przeciwieństwie do tego ostatniego, SPIR-V jest binarny, aby uniknąć różnic w implementacji między frontonami kompilatora GLSL różnych implementacji sterowników, ponieważ jest to główne źródło niezgodności aplikacji i błędów. Również binarny SPIR-V zwykle również przechodził pewne ogólne optymalizacje. Również do pewnego stopnia binarna reprezentacja SPIR-V oferuje pewien stopień zaciemnienia, co może być atrakcyjne dla niektórych producentów oprogramowania jako forma ochrony własności intelektualnej; SPIR-V zawiera jednak wiele informacji do refleksji i istnieją narzędzia, które przekształcają SPIR-V z powrotem w wysokiej jakości, czytelny dla człowieka kod wysokiego poziomu . UMD wymaga tylko zastosowania optymalizacji, które są specyficzne dla obsługiwanego sprzętu.

• Specyfikacja SPIR-V (tymczasowa)

GLSL IR

• cgit.freedesktop.org/mesa/mesa/tree/src/compiler/glsl/README
• XDC2014, Matt Turner: Wideo na YouTube , Matt Turner – kompilator GLSL: Gdzie byliśmy i dokąd zmierzamy
• XDC2015, Matt Turner: Film w YouTube , www .x .org /wiki /Events /XDC2015 /Program /turner _glsl _compiler .pdf

Mesa IR

NIR

NIR (New Internal Representation) został wprowadzony w celu przezwyciężenia ograniczeń TGSI. NIR został rozszerzony w ostatnich i aktualnych wydaniach jako podstawa wsparcia Spir-V i od 2016 roku jest głównym obszarem rozwoju. LLVMpipe, i965, RadeonSI, Nouveau, freedreno, vc4 zostały zmienione na NIR z TGSI. RADV, Zink i inne nowe sterowniki zaczynają się od NIR. Wszystkie sterowniki z pełną obsługą OpenGL 4.6 są powiązane z NIR przez obsługę SPIR-V. Również AMD r600 ma widelec z NIR dla lepszej obsługi serii HD5000 i HD6000. Ta opcja dla r600 jest domyślna od Mesa 21.0.

• Connor Abbott - NIR, czyli wyjście poza GLSL IR w Mesa XDC2014
  • (Mesa-dev) 2014-12-15 Ponowne wprowadzenie NIR, nowego IR dla 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 w RadeonSI
• Nowa aktualizacja 2018
• Noveau z NIR w Mesie 19,3

TGSI

Tungsten Graphics Shader Infrastructure (TGSI) została wprowadzona w 2008 roku przez firmę Tungsten Graphics. Wszystkie urządzenia UMD w stylu Gallium3D przyjmują TGSI. NIR jest teraz głównym obszarem rozwoju, więc TGSI jest tylko dla starszych sterowników, takich jak domyślna infrastruktura r300g i zostanie przestarzały za kilka lat.

LLVM IR

UMD radeonsii llvmpipenie wyświetlają kodu maszynowego, ale zamiast tego LLVM IR. Odtąd LLVM wykonuje optymalizacje i kompilację do kodu maszynowego. Oznacza to, że należy również zainstalować pewną minimalną wersję LLVM.

RADV ACO IR

RADV ACO używa własnego IR, który jest zbliżony do NIR, do optymalizacji i generowania końcowego kodu binarnego dla shaderów Vulkan SPIR-V na kartach graficznych Radeon (GCN 1+, aka GFX6+). Od wersji 20.1.0 ACO jest używane tylko w RADV (sterownik Vulkan), a nie w RadeonSI.

Kompilator GLSL firmy Mesa

Kompilator GLSL firmy Mesa generuje własne IR. Ponieważ każdy sterownik ma zupełnie inne wymagania niż LIR, rozróżnia on HIR (podczerwień wysokiego poziomu) i LIR (podczerwień niskiego poziomu).

Gal3D

Gallium3D to zestaw interfejsów i zbiór bibliotek pomocniczych mających na celu ułatwienie programowania sterowników urządzeń dla chipsetów graficznych 3D dla wielu systemów operacyjnych, interfejsów API renderowania lub akceleracji wideo.

Na stronie mesamatrix .net udostępniana jest macierz funkcji , a wysiłki związane z pisaniem bezpłatnych sterowników urządzeń o otwartym kodzie źródłowym dla układów graficznych są osobno udokumentowane w Wikipedii: bezpłatny sterownik urządzeń graficznych o otwartym kodzie źródłowym .

Rozwój Gallium3D rozpoczął się w 2008 roku w Tungsten Graphics, a implementacja jest dostępna jako darmowe oprogramowanie o otwartym kodzie źródłowym w ramach Mesa 3D hostowanego przez freedesktop.org . Podstawowym celem jest ułatwienie tworzenia sterowników, łączenie w jednym miejscu powielonego kodu kilku różnych sterowników oraz wspieranie nowoczesnych architektur sprzętowych. Odbywa się to poprzez zapewnienie lepszego podziału pracy, na przykład pozostawiając zarządzanie pamięcią sterownikowi DRI jądra .

Gallium3D jest częścią Mesy od 2009 roku i jest obecnie używany przez darmowy sterownik graficzny o otwartym kodzie źródłowym dla Nvidii ( projekt nouveau ), dla AMD R300 – R900 , sterownik Intela „Iris” dla iGPU generacji 8+ oraz dla innych darmowych i sterowniki urządzeń GPU typu open source .

Architektura oprogramowania

Gallium3D ułatwia programowanie sterowników urządzeń, dzieląc sterownik karty graficznej na trzy części. Jest to osiągane przez wprowadzenie dwóch interfejsów : Gallium3D State Tracker Interface oraz Gallium3D WinSys Interface . Te trzy elementy to:

Śledzenie stanu Gallium3D

• Każdy graficzny interfejs API, przez który adresowany jest sterownik urządzenia, ma swój własny State Tracker, np. istnieje Gallium3D State Tracker dla OpenGL i inny dla Direct3D lub GLX . Każdy State Tracker zawiera implementację interfejsu Gallium3D State Tracker i jest unikalny, co oznacza, że ​​jest wspólny dla wszystkich istniejących sterowników urządzeń Gallium3D.

Sterownik urządzenia Gallium3D

• To jest rzeczywisty kod, który jest specyficzny dla bazowego akceleratora grafiki 3D, ale tylko na tyle, na ile pozwala interfejs Gallium3D WinSys. Dla każdego dostępnego układu graficznego istnieje unikalny sterownik sprzętowy Gallium3D, a każdy z nich implementuje interfejs Gallium3D State Tracker oraz interfejs Gallium3D WinSys. Sterownik urządzenia sprzętowego Gallium3D rozumie tylko TGSI (Tungsten Graphics Shader Infrastructure), język pośredni do opisywania shaderów. Ten kod przetłumaczył shadery przetłumaczone z GLSL na TGSI dalej na zestaw instrukcji zaimplementowany przez GPU.

Galium3D WinSys

• Jest to charakterystyczne dla bazowego jądra w systemie operacyjnym i każdy z nich realizuje gallium3d WinSys Interfejs do współpracy z wszystkimi dostępnymi sterownikami sprzętowymi gallium3d.

VC4 i freedreno mogą bezpośrednio wykorzystywać NIR (i wracać do tgsi_to_nir dla shaderów, które nie używają glsl_to_nir).

Ilustracja stosu graficznego Linuksa

Mesa/ DRI i Gallium3D mają różne modele sterowników. Obaj udostępniają dużo darmowego kodu o otwartym kodzie źródłowym

Możliwa przykładowa macierz podczas implementacji modelu sterownika Gallium3D. Dzięki wprowadzeniu interfejsu Gallium3D Tracker i interfejsu Gallium3D WinSys wymaganych jest tylko 18 zamiast 36 modułów. Każdy moduł WinSys może współpracować z każdym modułem sterownika urządzenia Gallium3D iz każdym modułem State Tracker.

Różnice w stosunku do klasycznych sterowników graficznych

Gallium3D zapewnia ujednolicony interfejs API udostępniający standardowe funkcje sprzętowe, takie jak jednostki cieniujące znajdujące się na nowoczesnym sprzęcie. Tak więc interfejsy API 3D, takie jak OpenGL 1.x/2.x, OpenGL 3.x, OpenVG , infrastruktura GPGPU , a nawet Direct3D (znajdujące się w warstwie kompatybilności Wine ) będą potrzebowały tylko jednego zaplecza, zwanego trackerem stanu, kierowanie na Gallium3D API. W przeciwieństwie do tego, sterowniki urządzeń DRI w stylu klasycznym wymagają innego zaplecza dla każdej platformy sprzętowej, a kilka innych interfejsów API wymaga translacji do OpenGL kosztem duplikacji kodu. Wszystkie sterowniki urządzeń dostawców, ze względu na ich zastrzeżoną i zamkniętą naturę, są napisane w ten sposób, co oznacza, że ​​np. AMD Catalyst implementuje zarówno OpenGL, jak i Direct3D , a sterowniki dostawców dla GeForce mają swoje implementacje.

W Gallium3D sterowniki jądra Direct Rendering Manager (DRM) będą zarządzać pamięcią, a sterowniki interfejsu Direct Rendering Interface (DRI2) będą bardziej zorientowane na przetwarzanie GPU. W okresie przejściowym od trybu ustawiania w przestrzeni użytkownika do ustawiania trybu w przestrzeni jądra niektóre sterowniki Mesa 3D, takie jak sterownik radeon lub sterowniki Intela, ostatecznie wspierały zarówno DRI1, jak i DRI2, i używały DRI2, jeśli są dostępne w systemie. Gallium3D dodatkowo wymaga takiego poziomu obsługi shaderów, który nie jest dostępny na starszych kartach, takich jak np. ATi r100-r200, więc użytkownicy tych kart muszą nadal używać Mesa 3D z DRI2 do korzystania z 3D.

Tungsten Graphics Shader Infrastructure

Tungsten Graphics Shader Infrastructure ( TGSI ) jest pośrednią reprezentacją, taką jak LLVM Intermediate Representation lub nowa Standard Portable Intermediate Representation (SPIR), która ma być używana przez Vulkan API i OpenCL 2.1. Shadery napisane w OpenGL Shading Language mają zostać przetłumaczone/skompilowane do TGSI, następnie wykonane zostaną optymalizacje, a następnie shadery TGSI zostaną skompilowane do shaderów dla zestawu instrukcji używanego GPU.

NIR to nowa reprezentacja warstwy w Mesa z pełną obsługą SPIR-V, a od 2019 roku głównym obszarem rozwoju wszystkich nowszych sterowników z obsługą OpenGL 4.6.

Wykorzystanie LLVM

GlassyMesa to oparty na LLVM stos kompilatora dla shaderów napisanych w GLSL . W przypadku SSA zobacz artykuł Statyczny formularz pojedynczego przypisania .

Ponadto, korzystając z modułowej struktury Gallium3D, trwają prace nad wykorzystaniem zestawu kompilatorów LLVM i stworzeniem modułu do optymalizacji kodu modułu cieniującego w locie.

Biblioteka reprezentuje każdy program cieniujący za pomocą rozszerzalnej binarnej reprezentacji pośredniej o nazwie Tungsten Graphics Shader Infrastructure (TGSI), którą LLVM następnie tłumaczy na moduły cieniujące GLSL zoptymalizowane pod kątem sprzętu docelowego.

Przyjęcie

Kilka darmowych sterowników urządzeń graficznych o otwartym kodzie źródłowym , które zostały lub są pisane na podstawie informacji uzyskanych w wyniku inżynierii wstecznej w czystym pomieszczeniu , przyjęły model sterownika dostarczony przez Gallium3D, np. nouveau i inne ( zobacz bezpłatne i otwarte urządzenie graficzne sterownik, aby uzyskać pełną listę ). Głównym powodem może być to, że model sterownika Gallium3D zmniejsza ilość kodu wymaganego do napisania. Oczywiście, będąc licencjonowanym na podstawie licencji wolnego oprogramowania, ten kod może w każdej chwili zostać przepisany przez każdego, aby zaimplementować model sterownika DRI lub inny.

Historia

Pierwotnymi autorami Gallium3D byli Keith Whitwell i Brian Paul z Tungsten Graphics (przejętej przez VMware w 2008 roku).

Kamienie milowe

Jesienią 2011 roku było co najmniej 10 znanych, dojrzałych i działających sterowników Gallium3D. Otwarte sterowniki do kart graficznych Nvidia, nazwane przez zespół Nouveau , rozwijają swoje sterowniki przy użyciu frameworka Gallium3D.

2008-07-13: Rozwój Nouveau odbywa się wyłącznie dla frameworka Gallium. Stary sterownik DRI został usunięty z głównej gałęzi repozytorium Mesa na Freedesktop.org.

2009-02-11: Gałąź galium-0.2 została połączona z główną gałęzią Master Mesy. Rozwój odbywa się w głównej linii Mesa.

2009-02-25: Gallium3D może działać zarówno na jądrach Linuksa, jak i FreeBSD.

2009-05-01: Zack Rusin z Tungsten Graphics dodał do Mesa 3D narzędzie do śledzenia stanu OpenVG , które umożliwia sprzętową akcelerację Scalable Vector Graphics przez dowolny sterownik oparty na Gallium3D.

2009-07-17: Wydano Mesa3D 7.5, pierwszą wersję zawierającą Gallium3D.

2010-09-10: Do sterownika r600g dodano wstępne wsparcie dla procesorów graficznych Evergreen.

2010-09-21: Istnieją dwa sterowniki Gallium3D dla sprzętu ATI znane jako r300g i r600g odpowiednio dla procesorów graficznych R300-R500 i R600-Evergreen.

2010-09-21: Wprowadzono duże zmiany w kodzie, aby wspierać Direct3D 10 i 11. Z czasem może to dać możliwość korzystania z najnowszych implementacji Direct3D w systemach Linux.

2011-11-30: Sterowniki Intel 965g i Cell Gallium zostały usunięte z głównej gałęzi Mesy jako nieutrzymywane i uszkodzone.

2013-11-30: Mesa 10 z OpenGL 3.2, 3.3 i OpenCL 1.0+

2014-11-18: W kodzie wprowadzono duże zmiany w celu obsługi Direct3D 9.

2015-09-15: Mesa 11 z OpenGL 4.0, 4.1 i OpenCL 1.2 (niekompletna)

2015-12-15: Sterownik Mesa 11.1 VIRGL dla maszyn wirtualnych z OpenGL 3.3

08.07.2016: Mesa 12 z OpenGL 4.2, 4.3 i Vulkan 1.0 (Intel ANV i AMD RADV)

2016-11-01: Mesa 13 z OpenGL 4.4 i OpenGL ES 3.2

2017-02-13: Mesa 17.0 z OpenGL 4.5 i sterownikiem freedreno z OpenGL 3.0 i 3.1

2017-05-10: Mesa 17.1 OpenGL 4.2+ dla Intel Ivy Bridge (więcej niż sterownik Intel dla Windows, OpenGL 3.3+ dla Intel Open SWR Rasterizer (ważne dla komputera klastrowego dla dużych symulacji)

08.12.2017: Mesa 17.3 AMD Vulkan Driver RADV w pełni zgodny w teście Khronos Vulkan 1.0

2018-05-18: Mesa 18.1 z Vulkan 1.1 (Intel ANV i AMD RADV)

2018-09-07: Mesa 18.2 z OpenGL 4.3 dla Soft Driver VIRGL (ważne dla maszyn wirtualnych w chmurze Cluster Computer), OpenGL ES 3.1 dla Freedreno z Adreno A5xx

2019-06-11: Wydano Mesa 19.1 ze sterownikiem graficznym „iris” nowej generacji Intela dla iGPU generacji 8+

2019-12-11: Mesa 19.3 wydała OpenGL 4.6 z procesorem Intel i965 z gen. 7+ i opcjonalnym Iris Gen 8+

2020-03-18: Mesa 20.0 wydała OpenGL 4.6 z AMD GCN i Vulkan 1.2 dla Intel

2020-05-27: Mesa 20.1 wydała obsługę wektoryzacji NIR i obsługę współdzielonej pamięci wirtualnej dla OpenCL w Clover

2020-11-30: Mesa 20.3 pełna obsługa OpenCL 1.2 w Clover

2021-03-11: Mesa 21.0 wstępne wsparcie dla „D3D12”: Direct 3D 12 dla WSL2 w Windows 10 z OpenGL 3.3+, ARM Freedreno: OpenGL 3.3+

2021-05-05: Mesa 21.1 wstępne wsparcie sterownika GPU Google VirtIO „Venus” z Vulkan 1.2+; Zink: OpenGL 4.6+, OpenGL ES 3.1+; Rzepa Qualcomm, Lavapipe: Vulkan 1.1+

2021-08-04: Mesa 21.2 wstępne wsparcie nowego sterownika Intel Crocus OpenGL 4.6 opartego na gallium3D do Intel Sandy Bridge do Haswell dla starego i965, Vulkan Driver panVK dla ARM Panfrost

Wydajność

• Porównanie wydajności bezpłatnych i open-source'owych sterowników urządzeń graficznych

Historia

Inicjator projektu Brian Paul był hobbystą grafikiem. Pomyślał, że fajnie byłoby zaimplementować prostą bibliotekę grafiki 3D za pomocą API OpenGL, której mógłby następnie użyć zamiast VOGL (bardzo zwyczajnej biblioteki GL Like Library). Począwszy od 1993 roku spędził osiemnaście miesięcy na rozwoju w niepełnym wymiarze godzin, zanim opublikował oprogramowanie w Internecie w lutym 1995 roku. Oprogramowanie zostało dobrze przyjęte, a ludzie zaczęli przyczyniać się do jego rozwoju. Mesa zaczął od renderowania całej grafiki komputerowej 3D na procesorze . Mimo to wewnętrzna architektura Mesy została zaprojektowana tak, aby była otwarta na podłączenie do akcelerowanego procesora graficznego renderowania 3D. W tej pierwszej fazie renderowanie odbywało się pośrednio na serwerze wyświetlania , pozostawiając trochę narzutu i zauważalną prędkość opóźnioną w stosunku do teoretycznego maksimum. Diament potwór 3D , za pomocą Voodoo Graphics chipset, był jednym z pierwszych urządzeń sprzętowych obsługiwanych przez Mesa 3D.

Pierwsza prawdziwa obsługa sprzętu graficznego została dodana do Mesy w 1997 roku, w oparciu o interfejs API Glide dla ówczesnych nowych kart graficznych 3dfx Voodoo I/II i ich następców. Głównym problemem związanym z używaniem Glide jako warstwy akceleracyjnej był zwyczaj uruchamiania Glide na pełnym ekranie, który był odpowiedni tylko dla gier komputerowych. Co więcej, Glide wziął blokadę pamięci ekranu, a tym samym serwer wyświetlania został zablokowany przed wykonywaniem jakichkolwiek innych zadań GUI.

Zobacz też

• Darmowy sterownik karty graficznej typu open source

Bibliografia

Zewnętrzne linki

• Oficjalna strona internetowa
• Edge, Jake (październik 2013). „Historia Mesy” .

Linki zewnętrzne dla Gallium3D

• freedesktop.org - Gallium3D , artykuł o obecnym stanie Gallium3D
• Fonseca, José (kwiecień 2008), Wprowadzenie do Gallium3D
• Rusin, Zack (21 września 2007), Gallium3D
• Corbet, Jonathan (listopad 2007), Zarządzanie pamięcią w procesorach graficznych
• Generic GPU-Accelerated Video Decoding , projekt Google Summer of Code 2008 przy użyciu galu, zarchiwizowany z oryginału w dniu 31 lipca 2008 r.
• Rusin, Zack (2008), Gallium3D: Graphics Done Right (PDF) (prezentacja), Akademy
• Rusin, Zack (2008), Gallium3D: Graphics Done Right (prezentacja), Akademy , zarchiwizowane z oryginału (wideo) 1 stycznia 2011
• Aktualizacja dotycząca portów Gallium3D do AROS i Haiku (PDF) , FOSDEM 2010, 7 lutego 2010