Udostępnij przez

Porównanie przyspieszania sprzętowego Direct2D i GDI

Direct2D i GDI to renderujące API 2D trybu natychmiastowego, a obie oferują pewien stopień przyspieszenia sprzętowego. W tym temacie omówiono różnice między funkcją Direct2D i GDI, w tym wcześniejszymi i obecnymi różnicami w funkcjach przyspieszania sprzętowego obu interfejsów API.

Ten temat zawiera następujące części:

Różnice między direct2D i GDI

pl-PL: GDI renderuje geometrie nieprzezroczyste, z aliasingiem, takie jak wielokąty, elipsy i linie. Renderuje aliasy i tekst ClearType, a także może obsługiwać mieszanie przezroczystości za pośrednictwem interfejsu API AlphaBlend. Jednak obsługiwanie przezroczystości jest niespójne, a większość API GDI po prostu ignoruje kanał alfa. Niewiele interfejsów API GDI gwarantuje, co będzie zawierać kanał alfa po operacji. Co ważniejsze, renderowanie GDI nie łatwo integruje się z operacjami 3D, a nowoczesny GPU renderuje najbardziej wydajnie w części 3D swojego silnika renderującego. Na przykład, w Direct2Dlinie z aliasingiem są projektowane tak, aby były implementowane po prostu jako dwa trójkąty renderowane na GPU, podczas gdy GDI używa algorytmu rysowania linii Bresenhama.

Direct2D renderuje nieprzezroczyste, przezroczyste, aliasowane i anty aliasowane elementy pierwotne. Nowoczesne interfejsy użytkownika często korzystają z przezroczystości i animacji. Direct2D ułatwia tworzenie nowoczesnego interfejsu użytkownika, ponieważ ma ścisłe gwarancje dotyczące sposobu akceptowania i renderowania przezroczystej zawartości, a wszystkie jego elementy pierwotne są renderowane przy użyciu przyspieszania sprzętowego. Direct2D nie jest czystym nadkompletem GDI: prymitywów, które byłyby nieuzasadnienie wolne po zaimplementowaniu na GPU, nie ma w Direct2D. Ponieważ direct2D jest zbudowany z tym naciskiem na przyspieszenie 3D, jest również łatwy w użyciu z Direct3D.

Począwszy od systemu Windows NT 4, GDI działa w trybie jądra. Aplikacja wywołuje interfejs GDI, który następnie wywołuje jego odpowiednik w trybie jądra, przekazujący prymitywy do własnego modelu sterownika. Następnie ten sterownik wysyła wyniki do globalnego sterownika wyświetlania w trybie jądra.

Począwszy od systemu Windows 2000, GDI i sterowniki GDI działają w niezależnej przestrzeni w jądrze, zwanej "przestrzenią adresową sesji". Przestrzeń adresowa sesji jest tworzona dla każdej sesji logowania, a każde wystąpienie interfejsu GDI działa niezależnie w tej odrębnej przestrzeni adresowej trybu jądra. Funkcja Direct2D jest jednak uruchamiana w trybie użytkownika i przekazuje polecenia rysowania za pośrednictwem sterownika trybu użytkownika Direct3D do sterownika trybu jądra.

rysunek 1 - direct2d w porównaniu z gdi-

Przyspieszanie sprzętowe GDI i Direct2D

Najważniejszą różnicą między Direct2D a przyspieszeniem sprzętowym GDI jest podstawowa technologia, która je napędza. Direct2D jest zbudowany na Direct3D, a GDI ma swój własny model sterownika, interfejs sterownika urządzeń GDI (DDI), który odpowiada prymitywom GDI. Model sterowników Direct3D odpowiada sprzętowi renderowania 3D w procesorze GPU. Gdy po raz pierwszy zdefiniowano interfejs DDI dla GDI, większość sprzętu przyspieszającego wyświetlanie była ukierunkowana na prymitywy GDI. W miarę upływu czasu coraz większy nacisk kładzie się na przyspieszanie gier 3D i mniej na przyspieszanie aplikacji. W związku z tym interfejs API BitBlt został przyspieszony sprzętowo, podczas gdy większość innych operacji GDI nie była.

To przygotowało grunt pod sekwencję zmian w renderowaniu GDI na ekranie. Na poniższej ilustracji pokazano, jak renderowanie wyświetlacza GDI zmieniło się z systemu Windows XP na Windows 7.

rysunek 2 — ewolucja renderowania wyświetlacza gdi

Istnieje również wiele dodatkowych czynników, które spowodowały zmiany w modelu sterowników GDI, jak wyjaśniono poniżej.

Zwiększenie złożoności i rozmiaru sterowników wyświetlania

Sterowniki 3D stały się bardziej złożone w miarę upływu czasu. Bardziej złożony kod ma tendencję do większej liczby wad, dzięki czemu sterownik może istnieć w trybie użytkownika, w którym usterka sterownika nie może spowodować ponownego uruchomienia systemu. Jak widać na powyższej ilustracji, sterownik wyświetlania jest podzielony na złożony składnik trybu użytkownika i prostszy składnik trybu jądra.

Trudności w synchronizowaniu sesji i globalnych przestrzeni adresowych jądra

W systemie Windows XP sterownik wyświetlania istnieje w dwóch różnych przestrzeniach adresowych: przestrzeni sesji i przestrzeni jądra. Części sterownika muszą reagować na zdarzenia, takie jak zdarzenia zarządzania energią. Należy to zsynchronizować ze stanem sterownika w przestrzeni adresowej sesji. Jest to trudne zadanie i może prowadzić do wad, gdy sterowniki wyświetlania próbują poradzić sobie z tymi odrębnymi przestrzeniami adresowymi.

Zarządzanie oknami złożonymi

Menedżer okien pulpitu (DWM), menedżer okien kompozycji wprowadzony w systemie Windows 7, renderuje wszystkie okna do powierzchni pozakadrowej, a następnie składa je razem, aby były wyświetlane na ekranie. Wymaga to GDI, aby możliwe było renderowanie na powierzchni, która następnie zostanie wyrenderowana przez Direct3D do wyświetlenia. Stanowiło to problem w modelu sterowników XP, ponieważ GDI i Direct3D były równoległymi stosami sterowników.

W rezultacie w systemie Windows Vista sterownik wyświetlania GDI DDI został zaimplementowany jako dostarczony przez Microsoft sterownik Canonical Display Driver (CDD), który renderował zawartość GDI do mapy bitowej pamięci systemowej, aby następnie była ona składana na ekranie.

Renderowanie GDI w systemie Windows 7

Model sterowników używany w systemie Windows Vista wymaga, aby każde okno GDI było wspierane zarówno przez powierzchnię pamięci wideo, jak i powierzchnię pamięci systemowej. Spowodowało to użycie pamięci systemowej dla każdego okna GDI.

Z tego powodu GDI został ponownie zmieniony w systemie Windows 7. Zamiast renderowania na powierzchni pamięci systemowej, GDI została zmodyfikowana tak, aby renderowała w segmencie pamięci apertury. Pamięć przysłony można zaktualizować z powierzchni pamięci wideo, która przechowuje zawartość okna. GDI może renderować z powrotem do pamięci apertury, a wynik można następnie wysłać z powrotem do powierzchni okna. Ponieważ segment pamięci przysłony jest adresowany przez procesor GPU, procesor GPU może przyspieszyć te aktualizacje na powierzchni pamięci wideo. Na przykład renderowanie tekstu, BitBlts, AlphaBlend, TransparentBlt i StretchBlt są w tych przypadkach przyspieszane.

Kontrastujące przyspieszenie Direct2D i GDI w systemie Windows 7

Direct2D i GDI to API do renderowania w trybie bezpośrednim 2D, które są przyspieszane sprzętowo. Istnieje jednak wiele różnic, które pozostają w obu interfejsach API.

Lokalizacja zasobów

GDI domyślnie utrzymuje swoje zasoby, w szczególności mapy bitowe, w pamięci systemowej. Direct2D utrzymuje swoje zasoby w pamięci wideo na karcie wyświetlania. Gdy GDI musi zaktualizować pamięć wideo, należy to zrobić za pośrednictwem magistrali, chyba że zasób znajduje się już w segmencie pamięci przysłony lub jeśli operacja może być wyrażona bezpośrednio. Z kolei Direct2D może po prostu przekształcić swoje prymitywy na prymitywy Direct3D, ponieważ zasoby są już w pamięci wideo.

Metoda renderowania

Aby zachować zgodność, GDI wykonuje dużą część renderowania do pamięci przysłony przy użyciu CPU. Natomiast Direct2D tłumaczy swoje wywołania API na prymitywy Direct3D oraz operacje rysowania. Wynik jest następnie renderowany na procesorze GPU. Niektóre renderowanie GDI jest wykonywane na procesorze GPU, gdy pamięć przysłony jest kopiowana do powierzchni pamięci wideo reprezentującej okno GDI.

Skalowalność

Wywołania renderowania Direct2Dsą niezależnymi strumieniami poleceń do GPU. Każda fabryka Direct2D reprezentuje inne urządzenie Direct3D. GDI używa jednego strumienia poleceń dla wszystkich aplikacji w systemie. Metoda GDI może prowadzić do nagromadzenia obciążenia związanego z kontekstami renderowania zarówno procesora GPU, jak i CPU.

Lokalizacja

Direct2D działa całkowicie w trybie użytkownika, w tym środowisko wykonawcze Direct3D i sterownik Direct3D trybu użytkownika. Pomaga to zapobiec awariom systemu spowodowanym przez wady kodu w jądrze. GDIma jednak większość swojej funkcjonalności w przestrzeni sesji trybu jądra, a interfejs API w trybie użytkownika.

Dostępność przyspieszania sprzętowego

GDI jest przyspieszane sprzętowo w systemie Windows XP, a przyspieszane w systemie Windows 7, gdy uruchomiony jest program Desktop Window Manager i używany jest sterownik WDDM 1.1. Direct2D jest sprzętowo przyspieszany na prawie każdym sterowniku WDDM, niezależnie od tego, czy DWM jest używany, czy nie. W systemie Vista interfejs GDI będzie zawsze renderowany na procesorze CPU.

Model prezentacji

Po pierwszym zaprojektowaniu systemu Windows nie było wystarczającej ilości pamięci, aby umożliwić przechowywanie każdego okna we własnej mapie bitowej. W rezultacie GDI zawsze był logicznie renderowany bezpośrednio na ekranie, z zastosowaniem różnych obszarów klipowania, aby upewnić się, że aplikacja nie renderuje się poza swoim oknem. W modelu Direct2D aplikacja renderuje na buforze wstecznym, a wynik jest wyświetlany, gdy aplikacja zakończy rysowanie. Dzięki temu direct2D może obsługiwać scenariusze animacji znacznie bardziej płynnie niż GDI może.

Konkluzja

Istniejący kod GDI będzie nadal działać dobrze w systemie Windows 7. Jednak podczas pisania nowego kodu renderowania grafiki należy wziąć pod uwagę Direct2D, ponieważ lepiej korzysta z nowoczesnych procesorów GPU.

 

 

  • Last updated on