Czy wiele kontenerów multimedialnych może współdzielić jeden układ GPU bez konfliktów urządzeń?

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Tak, wiele kontenerów multimedialnych może współdzielić jeden procesor graficzny, jeśli sterownik hosta i środowisko uruchomieniowe obsługują jednoczesny dostęp, a każde z kontenerów prawidłowo otrzymuje dostęp do urządzenia.

Kontenery zwykle nie przejmują procesora graficznego na wyłączność tak jak w pełni przekazanej maszynie wirtualnej. Intel Quick Sync i AMD VA-API zazwyczaj udostępniają współdzielone urządzenia renderujące, natomiast kontenery NVIDIA mogą współdzielić ten sam stos sterowników i procesor graficzny, z uwzględnieniem ograniczeń sprzętu, sterowników, kodeków, pamięci i liczby sesji. Konflikty pojawiają się, gdy orkiestrator przydziela urządzenie na wyłączność, uprawnienia są różne, kontenery zawierają niezgodne biblioteki lub jednoczesne transkodowanie przekracza praktyczną wydajność procesora graficznego.

Potwierdź, że host obsługuje jednoczesne zadania GPU

Najpierw zainstaluj i zweryfikuj sterownik hosta, a następnie uruchom transkodowanie z akceleracją sprzętową poza kontenerem lub wewnątrz jednego sprawdzonego kontenera. Zapisz model procesora graficznego, wersję sterownika, obsługiwane kodeki kodowania i dekodowania, pamięć oraz zaobserwowane wykorzystanie zasobów.

W dyskusji społeczności TrueNAS opisano współdzielenie jednego procesora graficznego przez wiele aplikacji, gdy jest on udostępniony do użycia, a nie przydzielony aplikacji jako zasób na wyłączność. Różnica polega na współdzielonym dostępie do urządzenia i przekazaniu go na wyłączność.

Jeśli jeden kontener nie może niezawodnie korzystać z procesora graficznego, nie dodawaj kolejnego. Przed testowaniem jednoczesnego użycia napraw sterownik hosta, urządzenie jądra, oprogramowanie układowe lub środowisko uruchomieniowe.

Udostępnij właściwe urządzenie każdemu kontenerowi

W przypadku Intel i AMD porównaj urządzenia węzłów karty i renderowania /dev/dri przekazywane do każdego kontenera. W przypadku NVIDIA porównaj środowisko uruchomieniowe lub żądanie urządzenia, zmienne określające widoczne urządzenia oraz możliwości sterownika.

Przypadek Jellyfin w systemie NixOS opisuje sytuację, w której ten sam procesor graficzny hosta działał inaczej w różnych kontenerach, ponieważ zmieniło się środowisko systemu operacyjnego i urządzenia. Pokazuje to, dlaczego zgodne udostępnienie urządzenia i bibliotek ma większe znaczenie niż kopiowanie pojedynczego wiersza Compose.

Używaj minimalnego zestawu urządzeń wymaganego przez każdą aplikację i nie traktuj trybu uprzywilejowanego jako rozwiązania zastępczego. Po przebudowaniu kontenerów potwierdź, że oczekiwany węzeł renderowania lub urządzenie NVIDIA jest widoczne wewnątrz każdego kontenera.

Dopasuj uprawnienia i grupy użytkowników w kontenerach

Zapisz numeryczny właściciel i grupę urządzenia renderującego na hoście, a następnie potwierdź, że proces w każdym kontenerze ma odpowiednią dodatkową grupę lub uprawnienia. Nazwy użytkowników zależne od obrazu mogą być mapowane na różne identyfikatory numeryczne.

Kontener, który wykrywa procesor graficzny, ale nie może go otworzyć, może przełączyć się na transkodowanie programowe lub zgłosić odmowę dostępu. Taka awaria może wyglądać jak konflikt urządzenia, gdy drugi kontener multimedialny nadal działa.

Przetestuj każdy kontener osobno, używając tego samego pliku i kodeka. Zdefiniuj poprawki uprawnień jawnie w Compose, aby aktualizacje i odtwarzanie obrazów ich nie usuwały.

-15% OFF

Sprawdź zgodność kodeków, sterownika i środowiska uruchomieniowego

Porównaj kodeki i filtry, których uruchomienia na procesorze graficznym żąda każda aplikacja, w tym H.264, HEVC, AV1, mapowanie tonów, napisy, skalowanie oraz filtry OpenCL lub CUDA. Jedno zadanie może wymagać funkcji, których inne w ogóle nie używa.

Aktualny przewodnik dotyczący przekazywania procesora graficznego do Jellyfin podkreśla konieczność dopasowania konfiguracji kontenera do Intel QSV, NVIDIA NVENC lub AMD VA-API, zamiast traktowania wszystkich ścieżek akceleracji sprzętowej jako równoważnych. Środowisko uruchomieniowe musi odpowiadać rodzinie procesora graficznego.

Utrzymuj zgodność sterownika hosta z bibliotekami środowiska uruchomieniowego kontenera i unikaj dołączania konfliktowych sterowników do poszczególnych kontenerów multimedialnych. Testuj osobno dekodowanie, kodowanie i mapowanie tonów.

Zmierz limity jednoczesnych sesji, pamięci i temperatury

Rozpocznij jedno transkodowanie sprzętowe w każdym kontenerze i monitoruj procesy procesora graficznego, jego wykorzystanie, obciążenie kodera i dekodera, pamięć, temperaturę, błędy oraz stabilność strumienia. Stopniowo zwiększaj liczbę jednoczesnych zadań, korzystając z reprezentatywnych plików multimedialnych.

W konfiguracji społeczności Proxmox opisano jednoczesne transkodowanie przez wiele instancji Jellyfin i weryfikowanie aktywności z poziomu hosta. Pokazuje ona również, że jednoczesne sesje mają praktyczne ograniczenia określane przez sprzęt i oprogramowanie.

Współdzielony procesor graficzny działa prawidłowo, gdy obie aplikacje nadal korzystają z akceleracji i pozostają responsywne. Zacinanie się obrazu, nieudane tworzenie kodera, błędy braku pamięci, resety termiczne lub przełączanie jednej aplikacji na tryb programowy przez drugą wskazują, że obciążenie przekracza obecny margines wydajności.

Zachowaj osobne konfiguracje i ścieżki transkodowania przy współdzieleniu procesora graficznego

Przydziel każdemu kontenerowi multimedialnemu własną bazę konfiguracji, pamięć podręczną, katalog transkodowania, porty i tożsamość. Udostępniaj tylko bibliotekę multimediów w trybie tylko do odczytu oraz urządzenie procesora graficznego, chyba że aplikacje wyraźnie obsługują wspólny katalog stanu.

Przewodnik ZimaSpace dotyczący izolowania zależności kontenerów pomaga odróżnić konflikt procesora graficznego od awarii bazy danych, pamięci podręcznej, sieci lub punktu montowania.

Projekt jest zweryfikowany dopiero wtedy, gdy oba kontenery przetrwają przebudowanie, jednocześnie korzystają z akceleracji sprzętowej, respektują własne uprawnienia i stan oraz mieszczą się w limitach sesji, pamięci i temperatury. Użyj osobnych procesorów graficznych lub awaryjnego trybu programowego, gdy jednoczesne zadania nie mogą niezawodnie zapewnić wymaganej jakości.

Wsparcie i wskazówki

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.