Talizman Microsoftu

Talisman był projektem firmy Microsoft mającym na celu zbudowanie nowej architektury grafiki 3D w oparciu o szybkie komponowanie „podobrazów” 2D na ekranie, adaptację renderowania kafelkowego . Teoretycznie takie podejście radykalnie zmniejszyłoby przepustowość pamięci wymaganą do gier 3D, a tym samym doprowadziłoby do tańszych akceleratorów graficznych . Projekt miał miejsce podczas wprowadzania pierwszych wysokowydajnych akceleratorów 3D, które szybko przewyższyły Talismana zarówno pod względem wydajności, jak i ceny. Żaden system oparty na Talismanie nie został nigdy wypuszczony na rynek, a projekt został ostatecznie anulowany pod koniec lat 90.

Opis

Konwencjonalne 3D

Tworzenie obrazu 3D do wyświetlenia składa się z szeregu kroków. W pierwszej kolejności do pamięci wczytywane są obiekty do wyświetlenia z poszczególnych modeli . Następnie system wyświetlania stosuje funkcje matematyczne w celu przekształcenia modeli we wspólny układ współrzędnych, widok świata . Z tego światopoglądu tworzona jest seria wielokątów (zwykle trójkątów), które przybliżają oryginalne modele widziane z określonego punktu widzenia, kamery . Następnie system komponowania tworzy obraz, renderując trójkąty i nakładając tekstury na zewnątrz. Tekstury to małe obrazy namalowane na trójkątach w celu uzyskania realizmu. Powstały obraz jest następnie łączony z różnymi efektami specjalnymi i przenoszony do buforów wyświetlacza. Ten podstawowy układ koncepcyjny jest znany jako potok wyświetlania .

Ogólnie rzecz biorąc, wyświetlacz niewiele się zmienia z jednej klatki na drugą; generalnie dla dowolnego przejścia z klatki do klatki obiekty na wyświetlaczu prawdopodobnie będą się nieznacznie poruszać, ale ich kształt i tekstura raczej nie ulegną zmianie. Zmiana geometrii jest stosunkowo lekką operacją dla procesora , ładowanie tekstur z pamięci jest znacznie droższe, a następnie wysłanie wynikowej renderowanej klatki do bufora ramki jest najdroższą operacją ze wszystkich.

Rozważmy na przykład ustawienia renderowania z epoki z 24-bitowym kolorem, z podstawowym komponowaniem 3D z trójliniowym filtrowaniem i bez wygładzania : przy rozdzielczości 640 x 480 wymagałoby to 1900 Mbit/s przepustowości pamięci; przy rozdzielczości 1024 x 768 wymagałoby to 4900 Mbit/s. Oczekuje się, że nawet podstawowy antyaliasing z grubsza podwoi te liczby. Dla porównania, ówczesne maszyny RealityEngine2 firmy SGI charakteryzowały się wysoką wówczas przepustowością pamięci wynoszącą około 10 000 Mbit / s, co było powodem, dla którego maszyny te były szeroko stosowane w grafice 3D. Typowy komputer PC z epoki AGP 2X mógł oferować tylko 508 Mbit/s.

Pierwszym atakiem na ten problem było wprowadzenie akceleratorów graficznych , które obsługiwały przechowywanie i mapowanie tekstur. Karty te, podobnie jak oryginalna grafika Voodoo , miały procesor ponownie obliczający geometrię dla każdej klatki, a następnie wysyłał wynikową serię współrzędnych do karty. Karta obsłużyła następnie resztę operacji; nakładanie tekstur na geometrię, renderowanie klatki, stosowanie filtrowania lub wygładzania krawędzi oraz przesyłanie wyników do lokalnego bufora ramki. Wymagania dotyczące przepustowości w takim systemie zostały radykalnie zmniejszone; scena z 10 000 trójkątów może wymagać od 500 do 1000 kbit / s, w zależności od tego, ile punktów geometrii może być współużytkowanych przez trójkąty.

Renderowanie kafelkowe

Wraz ze wzrostem złożoności sceny potrzeba ponownego generowania geometrii dla tego, co było w zasadzie stałym zestawem obiektów, sama w sobie zaczęła stawać się wąskim gardłem. Znacznie większą poprawę wydajności można by uzyskać, gdyby karta graficzna również przechowywała i przetwarzała wielokąty. W takim systemie cały potok wyświetlania mógłby działać na karcie, wymagając minimalnej interakcji z procesorem. Wymagałoby to znacznie „mądrzejszej” karty graficznej; w przeciwieństwie do bardzo prostych operacji związanych z nakładaniem tekstur, karta musiałaby teraz mieć kompletny procesor zdolny do obliczania funkcji używanych w modelowaniu 3D. W tym czasie wiele firm eksplorowało tę drogę, tzw. przekształcać i oświetlać karty lub T&L, ale złożoność i koszt systemów wydawały się znaczne.

Jednym z rozwiązań, które badano w tym okresie, była koncepcja renderowania kafelkowego . Opierało się to na obserwacji, że niewielkie zmiany położenia kamery można symulować, manipulując małymi obrazami 2D, „kafelkami”. Na przykład ruch kamery w scenie można symulować, biorąc każdą płytkę i nieco ją powiększając. Podobnie, inne ruchy w scenie mogą być symulowane za pomocą odpowiedniej transformacji afinicznej . Jednak ten proces jest tylko przybliżony, ponieważ wraz ze wzrostem ruchu wierność wizualna będzie się zmniejszać. Taki system może zredukować konieczność ponownego obliczania geometrii średnio co dwie, trzy klatki.

Problem z tym podejściem polega na tym, że nie wszystkie kafelki muszą być renderowane za każdym razem, tylko te, które zawierają obiekty blisko kamery. Jeśli cała geometria zostanie przesłana na kartę, zadanie to można wykonać całkowicie na karcie, ale wymaga to kart o podobnej złożoności jak systemy T&L. Jeśli geometria jest kontrolowana przez procesor, to idealnie byłoby, gdyby karta mogła poprosić procesor o ponowne renderowanie tylko tych obiektów w kafelkach, które są przestarzałe. W wielu przypadkach wymagałoby to zmiany potoku renderowania procesora. W każdym przypadku karta i/lub kierowcy muszą wiedzieć o kolejności i położeniu przedmiotów, co zwykle jest ukryte w kodzie.

Talizman

Talisman był kompletnym zestawem oprogramowania i sprzętu, który próbował rozwiązać problem renderowania kafelkowego. System udostępnił pewne informacje o kaflach i znajdujących się w nich obiektach, aby dowiedzieć się, które kafelki są nieaktualne. Jeśli kafelek stał się nieaktualny, procesor był proszony o ponowne renderowanie obiektów w tym kafelku i przesłanie wyników z powrotem do sterownika, a następnie do karty. Gdy dany kafelek został wyrenderowany na karcie, był przechowywany na karcie w formacie skompresowanym, aby można go było ponownie wykorzystać w przyszłych klatkach. Microsoft obliczył, że każdy kafelek może być ponownie użyty średnio przez około cztery klatki, zmniejszając w ten sposób obciążenie procesora około czterokrotnie.

W Talisman bufory obrazu zostały podzielone na „kawałki” o wymiarach 32 x 32 piksele, które były indywidualnie renderowane przy użyciu obiektów 3D i tekstur dostarczonych przez procesor. Wskaźniki do fragmentów były następnie przechowywane na liście uporządkowanej z (od przodu do tyłu) dla każdych 32 linii skanowania na wyświetlaczu. Jednym z problemów jest to, że kawałków nie można czysto „zszyć”, problem, który czasami był widoczny w różnych grach wideo korzystających z renderowania programowego . Aby tego uniknąć, Talisman przechowywał również oddzielny „bufor brzegowy” dla każdego fragmentu, który zawierał obszar „przepełnienia”, który obejmowałby luki w mapowaniu.

Potok renderowania

W konwencjonalnym systemie 3D geometria jest okresowo generowana, przesyłana do karty w celu złożenia, składana do bufora ramki, a następnie ostatecznie pobierana przez sprzęt wideo w celu wyświetlenia. Systemy talizmanów zasadniczo odwróciły ten proces; ekran był podzielony na paski o wysokości 32 linii i podczas gdy sprzęt wideo rysował jeden z tych pasków, sprzęt dzwonił do strony Talisman i kazał jej przygotować szczegóły do ​​następnego paska.

System zareagowałby, pobierając wszelkie fragmenty widoczne na tym pasku, biorąc pod uwagę bieżącą lokalizację kamery. W typowym przypadku wiele fragmentów byłoby zasłoniętych przez inne fragmenty i można je zignorować podczas komponowania, oszczędzając czas. To jest powód sortowania z kawałków, co pozwala na ich efektywne wyszukiwanie w „kolejności widoczności”. Jeśli fragmenty można było modyfikować bez zniekształceń, wywoływano odpowiednią transformację afiniczną, aby zaktualizować fragment na miejscu. Jeśli nie mógł, powiedzmy, ponieważ kamera przesunęła się za bardzo od ostatniej pełnej aktualizacji, procesor został poproszony o dostarczenie nowej geometrii dla tego fragmentu, który następnie karta wyrenderowała i umieściła z powrotem w pamięci.

Talisman nie miał odpowiednika bufora ramki, renderując fragmenty na żądanie bezpośrednio na ekran, gdy linia skanowania monitora przesuwała się w dół ekranu. To ciekawy analog z Atari 2600 , który wykorzystuje podobny system do renderowania obrazów 2D na ekranie, metodą znaną jako „wyścigi wiązki”. W obu przypadkach zmniejszyło to ilość potrzebnej pamięci i przepustowość pamięci używanej między systemem wyświetlania a sprzętem wideo. W obu przypadkach wymagało to również radykalnie ściślejszej integracji między systemem wideo a programami, które go obsługują. W przypadku Talismana programy musiały przechowywać swoje obiekty w określonym formacie zrozumiałym dla sterowników oprogramowania Talisman, co pozwalało na szybkie pobieranie ich z pamięci podczas przerwań .

Historia

Wstęp

Wysiłek Talismana był próbą Microsoftu skomercjalizowania koncepcji, nad którymi eksperymentowano od jakiegoś czasu. W szczególności system PixelFlow opracowany w Hewlett-Packard na Uniwersytecie Północnej Karoliny w Chapel Hill można uznać za bezpośredniego rodzica Talismana.

Kiedy Talisman został po raz pierwszy upubliczniony na spotkaniu SIGGRAPH w 1996 roku , obiecali radykalną redukcję kosztów wdrożenia podsystemu graficznego. Planowali współpracować z dostawcami w celu sprzedaży koncepcji Talisman w celu włączenia do systemów wyświetlania innych firm. Oznacza to, że Talisman miał być częścią większego układu multimedialnego, w przeciwieństwie do całego systemu 3D, który byłby samodzielny w systemie. Ich podstawowy system obsługiwałby 20-30 000 wielokątów na wyświetlaczu 1024 x 768 przy 32 bitach/piksel, z szybkością renderowania wielokątów 40 Mpixel/s i szybkością komponowania warstwy obrazu 320 Mpixel/s.

eskalacja

W tym czasie Microsoft współpracował z kilkoma dostawcami w celu opracowania referencyjnej implementacji znanej jako Escalante . Samsung i 3DO pracowali razem nad zaprojektowaniem jednoukładowego „Media Signal Processor” (MSP) podobnego do DSP , łączącego funkcjonalność Talismana z dodatkowymi funkcjami multimedialnymi. Cirrus Logic zapewni VLSI chip, który pobierałby dane umieszczone w pamięci przez MSP, stosował efekty i wysyłał je do wyświetlenia. Ten układ, znany jako „Polygon Object Processor” (POP), był okresowo sprawdzany przez inny układ Cirrus Logic, „Image Layer Compositor” (ILC), który był powiązany z obwodami wideo. Dodatkowo Escalante zamierzał wyposażyć 4 MB pamięci RDRAM na dwóch 8-bitowych kanałach 600 MHz, oferując przepustowość 1,2 GB / s. Później Philips wkroczył do walki z planowaną nową wersją swojego procesora TriMedia , który zaimplementował większość Talismana w jednym procesorze, oraz Trident Microsystems , z podobnymi planami.

To właśnie w trakcie projektu Talisman gatunek strzelanek pierwszoosobowych zaczął wysuwać się na pierwszy plan w grach. Stworzyło to zapotrzebowanie rynku na akceleratory, których można by używać z istniejącymi grami przy minimalnych zmianach. Zanim projekt referencyjny Escalante był gotowy do produkcji, siły rynkowe zaowocowały serią nowszych projektów kart o tak ulepszonych parametrach, że karty Talisman po prostu nie mogły z nimi konkurować. Karty z dużą ilością pamięci RAM rozmieszczone tak, aby umożliwić ekstremalnie wysokie prędkości, rozwiązały problem z przepustowością, po prostu brutalnie wymuszając problem zamiast próbować go rozwiązać poprzez sprytną implementację.

Dodatkowo koncepcja Talismana wymagała ścisłej integracji systemu wyświetlania z oprogramowaniem, które go wykorzystuje. W przeciwieństwie do nowych kart 3D pojawiających się wówczas na rynku, systemy Talisman musiałyby być w stanie poprosić procesor o ponowne renderowanie części obrazu w celu aktualizacji ich fragmentów. Wymagało to, aby gry miały określoną organizację w pamięci, aby odpowiedzieć na te żądania. Aby pomóc programistom w tym zadaniu, Direct3D został zmieniony, aby lepiej odpowiadał potrzebom Talizmanów. Jednak w przypadku każdej gry, która została już napisana lub która nie chciała być powiązana z Talismanem, system D3D był wolniejszy i znacznie mniej interesujący.

Zanik

W wyniku tych zmian Talisman nigdy nie stał się produktem komercyjnym. Cirrus Logic i Samsung zrezygnowali z systemu jakiś czas w 1997 roku, co skłoniło Microsoft do porzucenia planów wydania Escalante w 1997 roku, a zewnętrznym obserwatorom wydawało się, że cały projekt był martwy.

Jednak wkrótce potem nastąpiło krótkie odrodzenie, kiedy Fujitsu twierdziło, że pracuje nad implementacją jednoukładową, która będzie dostępna w 1998 roku, z plotkami o podobnych projektach w S3 Graphics i ATI Technologies . Żaden z tych systemów nigdy nie został wysłany, a Talisman został po cichu zabity. To bardzo ucieszyło zewnętrznych dostawców akceleratorów graficznych, a także ludzi w firmie Microsoft, którzy wspierali ich na rynku z DirectX .

Dziedzictwo

Niemniej jednak kilka pomysłów zapoczątkowanych w systemie Talisman stało się od tego czasu powszechne w większości akceleratorów. W szczególności kompresja tekstur jest obecnie szeroko stosowana. W nowszych kartach kompresja została również zastosowana w buforach Z, aby zmniejszyć zapotrzebowanie na pamięć podczas sortowania wyświetlacza. Pomysł wykorzystania „kawałków” do sortowania wyświetlacza został również wykorzystany w niewielkiej liczbie kart, określanych jako renderowanie oparte na kafelkach , ale stał się konkurencyjny w przestrzeni biurowej znacznie później, wraz z wypuszczeniem procesorów graficznych NVidia opartych na Maxwell w 2014 r. Wiele procesorów graficznych zaprojektowanych specjalnie dla urządzeń mobilnych (takich jak telefony komórkowe) wykorzystuje podejście kafelkowe. Tylko jedna kluczowa idea Talismana, polegająca na prośbie o aktualizacje geometrii tylko „w razie potrzeby”, nie została od tego czasu podjęta.

Linki zewnętrzne

• Chicken Crossing , krótki film renderowany w czasie rzeczywistym przy użyciu koncepcji Talisman, zaprezentowany na SIGGRAPH '96