wydanie projektu , oferującym implementację Direct3D 9, działającą poprzez translację wywołań w API graficznym . Projekt oparty jest na bazie kodu projektu , który został rozszerzony o wsparcie dla Direct3D 9. W porównaniu do implementacji Direct3D 9 oparty na WineD3D, D9VK pozwala uzyskać wyższą wydajność, ponieważ translacja Direct3D 9 przez OpenGL działa wolniej od translacji przez Vulkan.
D9VK może być używany do uruchamiania aplikacji 3D i gier w systemie Linux przy użyciu Wine. Obsługuje uruchamianie większości gier opartych na Direct3D 9, wykorzystujących 2 lub 3 wersję Shader Model. Kod projektu jest dostarczany na licencji Zlib. Aby używać D9VK, wymagane są sterowniki obsługujące API Vulkan, takie jak AMD RADV 18.3+, NVIDIA 415.22+, Intel ANV 19.0+ oraz AMDVLK.
Zaimplementowano wywołania systemowe waitid (oczekiwanie na zmianę stanu procesu), pinsyscall (do przekazywania informacji o punkcie wejścia execve w celu ochrony przed exploitami ROP), getthrname i setthrname (uzyskiwanie i ustalanie nazwy wątku).
- Zrealizowano możliwość użycia więcej niż 4 GB pamięci wideo w aplikacjach 32-bitowych, co rozwiązało problemy z uruchamianiem modów w grach Skyrim i Oblivion;
- Włączono asynchroniczne przetwarzanie wyjścia renderowania na ekran (etap prezentacji). Aby zmniejszyć opóźnienia w głównym wątku renderowania, przetwarzanie wyjścia odbywa się w wątku przesyłania poleceń (command submission thread);
- Usunięto zbędne punkty synchronizacji wątku poleceń przy ekstrakcji żądanych danych;
- Kod do określania wewnętrznego czasu został przetłumaczony na użycie specyficznego dla platformy timera, co pomogło rozwiązać problemy z nieprawidłowym działaniem high_resolution_clock z MinGW;
- Zrealizowano zwolnienie opóźnionych buforów MANAGED i SYSTEMMEM na etapie przed wykonaniem PrepareDraw, co rozwiązało problemy z wydajnością w grach Risen i Legend of the Heroes: Trails of the Sky;
- Dodano wsparcie dla , umożliwiającym realizację poprawnego renderowania w grach SpinTyres i Mudrunner;
- Poprawiono zgodność z (D3D9Ex). Uwzględniono specyfikę obsługi ResetEx i Reset;
- Przeprowadzono czyszczenie i refaktoryzację kodu;
- Zapewniono bezpośrednie mapowanie buforów WRITEONLY, co może pozytywnie wpłynąć na wydajność i obejść błąd w grze
Counter-Strike: Global Offensive, prowadzący do kontynuacji zapisu w buforze po jego odblokowaniu; - Zrealizowano metodę , umożliwiający użycie okien dialogowych w aplikacjach pełnoekranowych;
- Zrealizowano wsparcie , w tym , niezbędnego dla SWVP (SoftWare Vertex Processing);
- Przerobiono licznik próbki wyświetlany na bieżącym obrazie (heads-up display, HUD);
- Dodano opcję d3d9.dialogBoxMode, którą można wykorzystać do wyłączenia trybu pełnoekranowego;
- Wprowadzono optymalizacje wydajności i rozwiązano problemy występujące podczas uruchamiania gier GTA: San Andreas, The Masquerade Bloodlines, Max Payne 2, The Sims 2, Silent Hunter 3, Senran Kagura Shinovi, Dungeons and Dragons, Crysis, Metal Slug X, ANGLE, Need for Speed: Carbon i Risen 1.
Dodatkowo można zaznaczyć deweloper projektu (wdrożenie DXGI, Direct3D 10 i Direct3D 11 na bazie API Vulkan) na pewien czas skupić wysiłki tylko na naprawianiu błędów, wstrzymując rozszerzenie funkcjonalności. Takie pragnienie z obawami o obniżenie jakości bazy kodu oraz utrudnienie wsparcia w przyszłości. Każda aktualizacja gałęzi 1.4.x wywołuje skargi na regresywne zmiany, których nie udaje się odtworzyć, zlokalizować ani usunąć.
Te problemy wymagają zbadania przyczyn ich powstawania, w przeciwnym razie pozostawienie ich nierozwiązanymi przy kontynuacji rozwoju funkcjonalności może jedynie pogorszyć sytuację i zamienić proces wsparcia w koszmar. W planach, które deweloper DXVK zamierza zrealizować przed przejściem w tryb tylko naprawiania błędów, jest dodanie wsparcia dla niektórych przydatnych rozszerzeń Vulkan oraz połączenie z osiągnięciami projektu D9VK.
Dodatek: na gorącym uczynku poprawka D9VK 0.40.1, w której ustawienie domyślne vec4(1) dla COLOR0 w shaderach wierzchołków oraz naprawę błędu, w wyniku którego bity slotów dla wyjść shadera domyślnie niewłaściwie się stosowały i, co za tym idzie, były niepoprawnie poprawiane przez backend, co powodowało ich wymianę na vec4(0).
Źródło: opennet.ru
