Niedawno ukazała się wiadomość, że zaproponowano wstępną implementację sterownika drm-asahi dla procesorów graficznych serii Apple AGX G13 i G14 stosowane w chipach Apple M1 i M2 na liście mailingowej deweloperów jądra Linuksa.
Kontroler jest napisany w Rust plus, zawiera zestaw uniwersalnych linków dotyczących podsystemu DRM (Direct Rendering Manager), którego można użyć do opracowania innych sterowników graficznych w Rust.
Wydany zestaw poprawek do teraz został przedstawiony wyłącznie do dyskusji przez głównych programistów (RFC), ale może zostać przyjęty do głównego zespołu po zakończeniu przeglądu i usunięciu zidentyfikowanych braków.
To jest moja pierwsza wersja abstrakcji Rust dla DRM podsystem. Zawiera same abstrakcje, niektóre drobne wstępne zmiany po stronie C, a także sterownik GPU drm-asahi (w celu odniesienia się do sposobu używania abstrakcji, ale niekoniecznie przeznaczone do wspólnego lądowania).
Te łaty są stosowane na szczycie drzewa w [1], na którym opiera się 6.3-rc1 z dodanymi wieloma zatwierdzeniami obsługi abstrakcji/Rusta powyżej. Większość z nich nie jest warunkiem wstępnym dla abstrakcji DRM. siebie, ale tylko od kierowcy.
Od grudnia kontroler wchodzi w skład paczka z jądrem dla dystrybucji Linuksa Asahi i został przetestowany przez użytkowników tego projektu.
Sterownik może być używany w dystrybucjach Linuksa do zorganizować środowisko graficzne w dUrządzenia Apple z SoC M1, M1 Pro, M1 Max, M1 Ultra i M2. Podczas opracowywania sterownika starano się nie tylko zwiększyć bezpieczeństwo poprzez minimalizację błędów podczas pracy z pamięcią w kodzie wykonywanym po stronie CPU, ale także częściowo zabezpieczyć się przed problemami pojawiającymi się podczas interakcji z oprogramowaniem układowym.
W szczególności sterownik zapewnia pewne powiązania dla struktur pamięci współdzielonej niebezpieczne ze złożonymi ciągami wskaźników używanych w oprogramowaniu układowym do interakcji z kontrolerem. Proponowany sterownik jest używany w połączeniu ze sterownikiem asahi Mesa, który zapewnia obsługę OpenGL w przestrzeni użytkownika i pomyślnie przechodzi testy zgodności z OpenGL ES 2. i jest prawie gotowy do obsługi OpenGL ES 3.0.
Jednocześnie sterownik działający na poziomie jądra jest początkowo rozwijany z myślą o przyszłej obsłudze API Vulkan, a interfejs programowania do interakcji z przestrzenią użytkownika został zaprojektowany z myślą o interfejsie UAPI zapewnianym przez nowy sterownik Intel Xe.
Nad Znane problemy wspomina się o następujących kwestiach:
- Istniejąca integracja Rust obecnie nie obsługuje abstrakcji budowania jako modułów, więc abstrakcje Rust są dostępne tylko dla wbudowanych komponentów DRM.
- DRM w dużym stopniu opiera się na wzorcu „podklasy” dla obiektów kontrolerów, co nie pasuje do Rusta.
- Obecnie zaimplementowane jest tylko to, co jest niezbędne dla kontrolera (plus niewielka ilość
oczywiste dodatki, gdzie lepsza integralność API ma sens). - drm::mm wymaga zamiast tego muteksu wbudowanego w abstrakcję
przekazać to użytkownikowi ze zwykłymi regułami zmienności Rusta.
Dzieje się tak, ponieważ węzły można usunąć w dowolnym momencie i te operacje
musi być zsynchronizowany. - Po stronie Mesy masz obecnie sterownik Gallium, który jest już w większości upstream (głównie brakuje bitów UAPI) i
przechodzi testy dEQP GLES2/EGL, z większością testów GLES3.0
Prace w wyższych gałęziach. Jest to inżynieria wsteczna sterownika społecznościowego, więc wspomina się, że w tym aspekcie jest jeszcze wiele do zrobienia.
w końcu jeśli jesteś chcesz dowiedzieć się więcej na ten temat, możesz sprawdzić szczegóły w poniższy link.