Aktualizacja sterownika WSL przynosi lepszą obsługę GPU dla aplikacji Linux

Gdy pracujesz na komputerze, system operacyjny, który uruchamiasz, niemal całkowicie determinuje, jakie oprogramowanie możesz uruchomić natywnie. Ale co jeśli chcesz pracować z aplikacjami napisanymi dla innego systemu? Przez lata był to problem, który zmuszał użytkowników do wyboru: albo przychodzisz do systemu, albo rezygnujesz z aplikacji. Teraz ta dynamika zaczyna się zmieniać. W ostatnich dniach marca 2026 roku Microsoft i społeczność deweloperów stojąca za projektem WINE jednocześnie opublikowali aktualizacje graficzne, które obiecują znacznie lepszą wydajność podczas uruchamiania aplikacji niezgodnych z systemem hosta. To może wydawać się technicznym szczegółem, ale w rzeczywistości oznacza przesunięcie paradygmatu – granice między systemami operacyjnymi stają się coraz bardziej płynne.

Dwie niezwiązane ze sobą aktualizacje sterowników graficznych dotarły do społeczności deweloperów w tym samym tygodniu, a mimo że powstały niezależnie od siebie, realizują dokładnie ten sam cel: znaczną poprawę wydajności grafiki podczas uruchamiania aplikacji niezgodnych z systemem operacyjnym, na którym pracują. Dla użytkownika oznacza to proste: gry Windows uruchamiane na Linuksie będą działać szybciej, a aplikacje Linuksa wewnątrz Windows Subsystem for Linux będą wykazywać lepszą wydajność GPU. Dla branży oznacza to coś znacznie większego – że tradycyjne podziały między ekosystemami stają się coraz mniej istotne.

Dxgkrnl wraca po czterech latach nieaktywności

Historia sterownika dxgkrnl jest fascynująca z punktu widzenia ewolucji technologicznej. Microsoft przedstawił go szerszej publiczności sześć lat temu, gdy opublikował artykuł promujący nowy sterownik jądra, który pozwala Linuksowi uruchamiającemu się wewnątrz WSL2 (Windows Subsystem for Linux w wersji 2) na dostęp do funkcjonalności DirectX karty graficznej hosta. To było znaczące osiągnięcie – przekładanie instrukcji DirectX z wirtualnej maszyny Linux na rzeczywisty sprzęt Windows to skomplikowana operacja, która wymaga głębokich zmian w stosie sterowników.

Po wprowadzeniu w 2020 roku sterownik przez cztery lata praktycznie nie zmienił się. Otrzymał znaczną przebudowę w 2022 roku – efektywnie wersję 2.0 – a kilka miesięcy później Microsoft refaktoryzował kod dla jasności i łatwości przeglądu, etykietując to jako PATCH v3. Teraz, po prawie dokładnie czterech latach czekania, pojawił się na liście mailingowej jądra Linux nowy patch wprowadzający wersję 4 sterownika.

Ta nowa wersja wprowadza wsparcie dla GPU przeznaczonych tylko do obliczeń, które są niezbędne dla uruchamiania modeli dużych języków (LLM) – technologii, która w ostatnich latach stała się wszechobecna w branży AI. Dodatkowo sterownik obsługuje teraz wiele wirtualnych GPU na maszynę wirtualną oraz udostępnianie bufora sterownika poprzez dma-fence, mechanizm synchronizacji, który zapobiega wyścigom danych między procesami. Należy jednak pamiętać, że sam DirectX pozostaje zamknięty, a sterownik jest użyteczny wyłącznie w kontekście uruchamiania go pod Hyper-V na szczycie Windows – nie ma tu żadnego uniwersalnego rozwiązania.

Cztery lata między wersjami 3 i 4 mogą wydawać się długim czasem, ale w rzeczywistości odzwierciedlają fakt, że wiele aplikacji biznesowych pracujących na WSL2 nie wymagało drastycznych zmian. Jednak pojawienie się AI i potrzeba uruchamiania LLM-ów w wirtualnych środowiskach Linuksa sprawiło, że Microsoft musiał ponownie zwrócić uwagę na ten sterownik.

WSL2 to nie to samo co jego poprzednik

Aby zrozumieć znaczenie aktualizacji dxgkrnl, warto cofnąć się i wyjaśnić architekturę WSL. Współczesny WSL2 uruchamia jedną rzeczywistą kopię Linuksa wewnątrz Windows, z kontenerami udającymi różne dystrybucje. To radykalna zmiana w stosunku do oryginalnego WSL, znanego teraz jako WSL1, który został wprowadzony dekadę temu. WSL1 zapewniał warstwę translacji konwertującą wywołania API Linuksa na równoważne wywołania Windows – technologia pochodzi z długo nieistniejącego Project Astoria, środowiska uruchomieniowego stworzonego do uruchamiania aplikacji Android na Windows Phone.

Interesujące jest to, że WSL1 ma więcej wspólnego z tym, jak działa WINE, niż z WSL2. WINE to również warstwa translacji, ale pracująca w drugą stronę – konwertuje wywołania API Windows na równoważne wywołania Linuksa. To podejście pozwoliło społeczności WINE przez dziesięciolecia utrzymywać starsze aplikacje Windows w działaniu na systemach Unix-like, ale zawsze z pewnym kosztem wydajności i kompatybilności.

Różnica między WSL1 a WSL2 jest kluczowa dla zrozumienia, dlaczego aktualizacja dxgkrnl ma znaczenie. WSL1 był bardziej jak WINE – warstwa translacji. WSL2 jest bardziej jak wirtualna maszyna – rzeczywisty Linux działający pod hypervisorem Hyper-V. To oznacza, że WSL2 może potencjalnie oferować lepszą wydajność dla wielu scenariuszy, ale wymaga bardziej skomplikowanego podejścia do dostępu do zasobów hosta, w tym GPU.

WINE 11 i rewolucja 32-bitowa na 64-bitowych systemach

Podczas gdy Microsoft pracował nad ulepszeniami dla WSL, społeczność stojąca za WINE osiągała własne przełomy. W 2024 roku WINE 9.0 wprowadził funkcję 32-bitowego do 64-bitowego thunkingu – zdolność do uruchamiania 32-bitowych binariów Windows na 64-bitowych systemach hosta bez konieczności używania jakiegokolwiek 32-bitowego podsystemu na hoście. To było kluczowe dla macOS, gdzie wszystkie wersje od 10.15 "Catalina" porzuciły obsługę 32-bitowych aplikacji.

Teraz, wraz z wydaniem WINE 11 w bieżącym roku, ta funkcjonalność jest tak dobrze zintegrowana, że tradycyjne polecenia wine32 i wine64 już nie istnieją. Użytkownik po prostu uruchamia wine, a system automatycznie obsługuje różne architektury binarne. To może brzmieć jak mały szczegół, ale dla użytkowników próbujących uruchamiać stare oprogramowanie na nowoczesnym sprzęcie, to zmiana, która może oznaczać różnicę między możliwością uruchomienia aplikacji a całkowitą niemożliwością.

Sukces WINE w ostatnich latach jest w dużej mierze zasługą Valve. Ich dystrybucja SteamOS 3, pierwotnie zbudowana dla konsoli do gier przenośnych Steam Deck, uruchamia gry Windows na Linuksie przy użyciu Proton Valve – oprogramowania zbudowanego na bazie WINE i zintegrowanego z klientem Linux dla platformy gier Valve Steam. SteamOS 3 odniosło tak duży sukces, że Valve planuje wprowadzić więcej sprzętu Steam w późniejszym okresie tego roku. To nie jest przypadek – Valve aktywnie inwestuje w poprawę kompatybilności, ponieważ ma bezpośredni interes finansowy w sprzedaży sprzętu opartego na systemach Linux.

Wkład Valve w ekosystem grafiki Linux

Sukces Valve w sprzedaży konsumenckiego sprzętu opartego na emulacji na poziomie systemu operacyjnego nie tylko napędza rozwój Linuksa – napędza również zmiany w OpenGL, otwartym standardzie grafiki, który przez dziesięciolecia konkurował z zamkniętym DirectX Microsoftu. W 2024 roku Derek Lesho z CodeWeavers zgłosił nowy problem na liście mailingowej mesa-dev: jak pomóc WINE w używaniu 64-bitowych sterowników Mesa OpenGL dla 32-bitowych aplikacji Windows.

Problem jest klasyczny dla komputerów z architekturą mieszaną. Gdy WINE przydzielałoby blok pamięci GPU dla gry przy użyciu API glMapBuffer, adres tego bufora byłby adresem 64-bitowym – ale WINE nie mógłby przekazać tego adresu do 32-bitowej aplikacji, jeśli adres nie mieściłby się w zakresie adresów 32-bitowych. Każdy, kto kiedykolwiek próbował dodać więcej niż 4 GB RAM do komputera z Windows XP i odkrył, że 32-bitowy XP nie widzi dodatkowej pamięci, napotyka inną stronę tego samego problemu.

Po dyskusjach w społeczności deweloperów rezultatem było stworzenie nowego API OpenGL o nazwie MESA_map_buffer_client_pointer. Jego opis mówi: "To rozszerzenie pozwala aplikacji określić zakresy wskaźników, w obrębie których bufory powinny być mapowane." Innymi słowy, podczas przydzielania bufora, pozwala aplikacji zażądać, aby bufor znajdował się w danym zakresie adresów, dzięki czemu jest dostępny dla kodu 32-bitowego bez powolnych operacji kopiowania.

OpenGL żyje, mimo że Vulkan przejął przyszłość

Przeszło dekadę minęła od czasu, gdy media branżowe po raz pierwszy szeroko opisały specyfikację Vulkan 1.0, otwartego standardu grafiki, który miał zastąpić zarówno OpenGL, jak i DirectX. Jednak mimo pojawienia się Vulkana i jego adoption przez wiele nowoczesnych gier, rozwój OpenGL nadal się toczy. Microsoft porzucił obsługę aplikacji 16-bitowych z Windows, a Apple wycofało obsługę 32-bitowych aplikacji z macOS, ale WINE pracuje nad tym, aby stare binaria Windows działały dobrze na nowoczesnych 64-bitowych systemach operacyjnych Unix-like.

To pokazuje fundamentalną różnicę w podejściu między gigantami technologicznymi a społecznością open source. Gdy Microsoft i Apple mogą po prostu porzucić starsze formaty, WINE musi je wspierać, ponieważ wiele osób wciąż ma oprogramowanie, które chce uruchamiać. Nowe API MESA_map_buffer_client_pointer jest eleganckim rozwiązaniem tego problemu – nie jest to hack ani obejście, ale właściwe rozszerzenie standardu.

Implikacje dla użytkowników i deweloperów

Praktycznie rzecz biorąc, te dwie aktualizacje oznaczają, że użytkownik może teraz uruchamiać więcej aplikacji z lepszą wydajnością na systemach, które nie były pierwotnie do nich przeznaczone. Dla kogoś pracującego na Linuksie, ale potrzebującego uruchamiać starą 32-bitową grę Windows, nowe API OpenGL oznacza mniej opóźnień i lepszą responsywność. Dla kogoś pracującego na Windows, ale chcącego uruchamiać narzędzia Linuksa z intensywnym wykorzystaniem GPU, aktualizacja dxgkrnl oznacza, że te narzędzia będą działać znacznie szybciej.

Dla deweloperów implikacje są głębsze. Te aktualizacje pokazują, że zarówno Microsoft, jak i społeczność open source zainteresowani są interoperacyjnością. To nie jest zwycięstwo jednego systemu nad drugim – to ewolucja w kierunku świata, w którym granice między systemami operacyjnymi są coraz bardziej przezroczyste. Deweloper może pisać kod raz i oczekiwać, że będzie działać rozsądnie dobrze na wielu platformach, bez konieczności utrzymywania całkowicie odrębnych baz kodów.

Kontekst szerszy: emulacja jako strategia biznesowa

Warto zauważyć, że te aktualizacje nie pojawiają się w próżni. Stanowią część szerszego trendu, w którym emulacja i translacja na poziomie systemu operacyjnego stały się istotnymi strategiami biznesowymi. Apple zrobiło to z Rosettą 2 na Apple Silicon, pozwalając na uruchamianie aplikacji Intel na swoim sprzęcie ARM. Microsoft robi to z WSL, pozwalając użytkownikom Windows na uruchamianie narzędzi Linuksa. Valve robi to z Proton, pozwalając graczom Linux na uruchamianie gier Windows.

Każda z tych technologii ma inną architekturę i inny cel, ale wszystkie realizują ten sam cel: zmniejszenie tarcia przy przechodzeniu między ekosystemami. To jest istotne dla użytkowników, ale ma również implikacje dla konkurencji. Jeśli użytkownik może łatwo uruchamiać aplikacje z innego ekosystemu, to zmniejsza się "lock-in" – przywiązanie użytkownika do danej platformy.

Przyszłość: konwergencja czy koegzystencja?

Pytanie, które pozostaje, to czy te aktualizacje reprezentują kroki w kierunku konwergencji – gdzie wszystkie systemy operacyjne staną się zasadniczo wymienne – czy raczej koegzystencję, gdzie systemy pozostają odrębne, ale mogą bezproblemowo pracować razem. Biorąc pod uwagę obecne trendy, wydaje się bardziej prawdopodobna koegzystencja. Każdy system operacyjny ma swoje unikalne cechy i bazę użytkowników, które nie znikną w dającej się przewidzieć przyszłości. Ale przyszłość, w której uruchamianie aplikacji "niezgodnej" z systemem jest normą, a nie wyjątkiem, wydaje się coraz bardziej realna. Te dwie aktualizacje są małymi krokami w tym kierunku, ale małe kroki mogą prowadzić do znaczących zmian.