Co faktycznie robi LIBGL_ALWAYS_INDIRECT = 1?

KDE SC 4.5.0 ma pewne problemy z niektórymi kartami graficznymi, w tym moją. Po wydaniu Arch zalecił kilka obejść . Jednym z nich był

wyeksportuj „LIBGL_ALWAYS_INDIRECT = 1” przed uruchomieniem KDE

Uznałem, że to najłatwiejsza, najlepsza metoda. Ale nie wiem, co robi ani jak wpływa na mój system. Czy jest wolniejszy niż domyślny? czy powinienem pamiętać o problemie i wyłączać go później, gdy zostanie naprawiony?

Pośrednie renderowanie oznacza, że ​​protokół GLX będzie używany do przesyłania poleceń OpenGL, a X.org wykona prawdziwy rysunek.

Bezpośrednie renderowanie oznacza, że ​​aplikacja może uzyskać bezpośredni dostęp do sprzętu bez uprzedniej komunikacji z X.org za pośrednictwem mesa.

Bezpośrednie renderowanie jest szybsze, ponieważ nie wymaga zmiany kontekstu na proces X.org.

Wyjaśnienie: W obu przypadkach renderowanie odbywa się za pomocą GPU (lub technicznie - może być wykonane przez GPU). Jednak w renderowaniu pośrednim proces wygląda następująco:

1. Program wywołuje polecenie (polecenia)
2. Polecenia są wysyłane do X.org przez protokół GLX
3. X.org wzywa sprzęt (tj. GPU) do rysowania

W renderowaniu bezpośrednim

1. Program wywołuje polecenie (polecenia)
2. Polecenia są wysyłane do GPU

Należy pamiętać, że ponieważ OpenGL został zaprojektowany w taki sposób, że może działać w sieci, renderowanie pośrednie jest szybsze niż naiwna implementacja architektury, tj. Pozwala wysłać wiele poleceń za jednym razem. Istnieje jednak pewien narzut związany z czasem procesora spędzanym na przełączaniu kontekstu i protokole obsługi.

Po pierwsze, LIBGL_ALWAYS_INDIRECTflaga związana z implementacją OpenGL po stronie klienta Mesa 3D (libGL.so). Nie będzie działać ze sterownikami binarnymi innych dostawców (np. NVIDIA).

Po drugie, aby bezpośrednio odpowiedzieć na twoje pytanie, ostatnio spojrzałem na kod Mesa, flaga działa w następujący sposób:

Przed ~ 2008 r., Kiedy Mesa pracował z pośrednim serwerem X (np. Zrobiłeś ssh -Xlub jawnie ustawiłeś swój wyświetlacz na nielokalny serwer), udostępniłaby listę wizualizacji GLX dostarczanych przez zdalny serwer X dla twojej aplikacji GLX. Wywołania aplikacji, np. GlXChooseVisual () i Mesa, znajdowałyby coś rozsądnego do dopasowania, a kolejne glFoo()wywołania byłyby wysyłane do zdalnego serwera X, gdzie były wykonywane przez dowolną bibliotekę libGL, do której podłączony był zdalny serwer X (prawdopodobnie twój GPU).

Pod koniec 2008 roku Mesa została zmieniona, tak aby chciała używać swojego wewnętrznego oprogramowania renderującego OpenGL ( sterownik Xlib ) do zdalnych połączeń X. (Niektóre dystrybucje, takie jak SuSE, specjalnie załatały to, aby powrócić do starego zachowania.) To by się uruchomiło tylko wtedy, gdy zdalny serwer X oferował grafikę GLX, która dokładnie pasowała do jednego z wewnętrznych mechanizmów renderujących oprogramowanie. (W przeciwnym razie pojawi się wspólny komunikat „ Błąd: nie można uzyskać obrazu RGB z podwójnym buforowaniem ”). Jeśli taki obraz zostanie znaleziony, Mesa wyrenderuje wszystkie glFoo()polecenia za pomocą lokalnego procesora (do aplikacji) i popchnie wynik do zdalnego serwera X za pomocą obrazów rastrowych ( XPutImage()); Ustawienie LIBGL_ALWAYS_INDIRECT=1(przed Mesa 17.3 działała dowolna wartość, od tego czasu musisz użyć 1 lub true) mówi Mesa, aby zignorowała normalne renderowanie bezpośrednie lub wewnętrzny program renderujący oprogramowanie i używała renderowania pośredniego tak jak kiedyś.

Wybór renderowania pośredniego lub bezpośredniego oprogramowania wpłynie na dwie rzeczy:

Wersja OpenGL

• Pośrednie renderowanie jest zasadniczo ograniczone do OpenGL 1.4.
• Bezpośrednie renderowanie oprogramowania będzie obsługiwać wszystko, co obsługuje rasterizer oprogramowania Mesa, prawdopodobnie OpenGL 2.1+

Wydajność

• Jeśli twoja aplikacja jest przeznaczona do połączeń pośrednich (wykorzystuje listy wyświetlania, minimalizuje zapytania w obie strony), możesz uzyskać rozsądną wydajność.
• Jeśli twoja aplikacja robi coś głupiego jak glGetInteger()100 razy na ramkę, to nawet w szybkiej sieci LAN każde z tych zapytań z łatwością zajmie 1 ms lub 100 ms łącznie na ramkę, co oznacza, że ​​nigdy nie uzyskasz więcej niż 10 FPS w aplikacji.
• Ta sama aplikacja, jeśli obciążenie renderowania nie jest zbyt duże, może działać bardzo dobrze w przypadku bezpośredniego renderowania programowego, ponieważ wszystkie te glGetInteger()połączenia są odbierane bezpośrednio w ciągu mikro lub nanosekund.
• Jeśli twoja aplikacja utworzy listę wyświetlania o milionie wierzchołków, a następnie wykona wiele obrotów, wówczas renderowanie pośrednie za pomocą prawdziwego procesora graficznego na drugim końcu da znacznie lepszą wydajność.
• Aplikacja może również powrócić do innej ścieżki kodu, jeśli ma dostępny tylko OpenGL 1.4 vs 2.x, co również może wpływać na wydajność.

Możesz więc zobaczyć bez dokładnych szczegółów aplikacji i charakterystyki sieci, nie można powiedzieć, czy bezpośrednie renderowanie oprogramowania czy renderowanie pośrednie jest lepsze w danej sytuacji.

W twoim przypadku wydaje się, że prowadzisz lokalną instancję kwin, więc efektem LIBGL_ALWAYS_INDIRECTjest wymuszenie pośredniego renderowania na lokalnym serwerze X. To najwyraźniej zmienia kwinzachowanie (tylko OpenGL 1.4) lub pozwala uniknąć innych błędów.

Zdecydowanie chcesz usunąć tę flagę, gdy podstawowy problem zostanie rozwiązany.