Microsoft Talisman
Talisman var ett Microsoft- projekt för att bygga en ny 3D- grafikarkitektur baserad på att snabbt sammansätta 2D "underbilder" på skärmen, en anpassning av kakelrendering . I teorin skulle detta tillvägagångssätt dramatiskt minska mängden minnesbandbredd som krävs för 3D-spel och därigenom leda till billigare grafikacceleratorer . Projektet ägde rum under introduktionen av de första högpresterande 3D-acceleratorerna, och dessa överträffade snabbt Talisman i både prestanda och pris. Inga Talisman-baserade system släpptes någonsin kommersiellt, och projektet avbröts så småningom i slutet av 1990-talet.
Beskrivning
Konventionell 3D
Att skapa en 3D-bild för visning består av en serie steg. Först laddas objekten som ska visas upp i minnet från enskilda modeller . Displaysystemet tillämpar sedan matematiska funktioner för att omvandla modellerna till ett gemensamt koordinatsystem, världsbilden . Från denna världsbild skapas en serie polygoner (vanligtvis trianglar) som approximerar de ursprungliga modellerna sett från en viss synvinkel, kameran . Därefter producerar ett kompositsystem en bild genom att rendera trianglarna och applicera texturer på utsidan. Texturer är små bilder som målas på trianglarna för att skapa realism. Den resulterande bilden kombineras sedan med olika specialeffekter och flyttas in i visningsbuffertarna. Denna grundläggande konceptuella layout är känd som displaypipeline .
Generellt sett ändras displayen lite från en bildruta till en annan; i allmänhet för en given övergång från bildruta till bildruta, kommer objekten i displayen sannolikt att röra sig något, men deras form och texturer kommer sannolikt inte att förändras alls. Att ändra geometrin är en relativt lätt operation för CPU:n , att ladda texturerna från minnet betydligt dyrare, och sedan skicka den resulterande renderade ramen till rambufferten den dyraste operationen av alla.
Överväg till exempel att rendera erans inställningar med 24-bitars färg, med grundläggande 3D-kompositering med trilinjär filtrering och ingen kantutjämning : Vid en upplösning på 640 x 480 skulle det kräva 1 900 Mbit/s minnesbandbredd; vid 1024 x 768 upplösning skulle det krävas 4 900 Mbit/s. Även grundläggande kantutjämning skulle förväntas ungefär fördubbla dessa siffror. Som referens, SGI: s då nuvarande RealityEngine2- maskiner hade en då hög minnesbandbredd på cirka 10 000 Mbit/s, vilket var anledningen till att dessa maskiner användes flitigt i 3D-grafik. En typisk PC från tiden som använder AGP 2X kunde bara erbjuda 508 Mbit/s.
Den första attacken mot detta problem var introduktionen av grafikacceleratorer som hanterade texturlagring och kartläggning. Dessa kort, liksom den ursprungliga Voodoo Graphics , fick CPU:n att räkna om geometrin för varje bildruta och sedan skicka den resulterande serien av koordinater till kortet. Kortet skötte sedan resten av operationen; applicera texturerna på geometrin, rendera ramen, tillämpa filtrering eller kantutjämning och mata ut resultaten till en lokal rambuffert. Bandbreddsbehoven i ett sådant system minskade dramatiskt; en scen med 10 000 trianglar kan behöva 500 till 1000 kbit/s, beroende på hur många av geometripunkterna som kan delas mellan trianglar.
Kakel rendering
När scenens komplexitet ökade började behovet av att återskapa geometrin för vad som i huvudsak var en fast uppsättning objekt att bli en egen flaskhals. Mycket större förbättringar i prestanda skulle kunna uppnås om grafikkortet också lagrade och manipulerade polygonerna. I ett sådant system kan hela displaypipelinen köras på kortet, vilket kräver minimal interaktion med CPU:n. Detta skulle kräva att grafikkortet är mycket "smartare"; till skillnad från de mycket enkla operationerna som är involverade i att applicera texturer, skulle kortet nu behöva ha en komplett processor som kan beräkna de funktioner som används i 3D-modellering. Vid den tiden som ett antal företag undersökte denna väg, de så kallade " transformerings- och ljuskorten " eller T&L, men komplexiteten och kostnaderna för systemen verkade betydande.
En lösning som studerades under denna period var konceptet med kakelputsning . Detta baserades på observationen att små förändringar i kamerapositionen kunde simuleras genom att manipulera små 2D-bilder, "brickorna". Till exempel kan kamerans rörelse in i scenen simuleras genom att ta varje bricka och göra den något större. På samma sätt kan andra rörelser i scenen simuleras med tillämpning av den lämpliga affina transformationen . Denna process är dock bara ungefärlig, eftersom rörelsen ökar kommer den visuella troheten att minska. Ett sådant system kan minska behovet av att räkna om geometrin till varannan till var tredje ram i genomsnitt.
Problemet med detta tillvägagångssätt är att inte alla brickor nödvändigtvis måste renderas om varje gång, bara de som innehåller objekt nära kameran. Om hela geometrin skickas till kortet kan denna uppgift hanteras helt på kortet, men detta kräver kort av liknande komplexitet som T&L-system. Om geometrin hålls under kontroll av CPU:n, bör kortet helst kunna be CPU:n att återrendera endast de objekt i brickor som är föråldrade. I många fall skulle detta kräva att CPU:ns renderingspipeline ändras. I vilket fall som helst behöver kortet och/eller förarna veta om objektens ordning och placering, något som normalt döljs i koden.
Talisman
Talisman var en komplett svit av mjukvara och hårdvara som försökte lösa problemet med kakelrendering. Systemet delade lite information om brickorna och objekten i dem för att ta reda på vilka brickor som var föråldrade. Om en bricka blev föråldrad ombads CPU:n att återrendera objekten i den plattan och skicka tillbaka resultaten till drivrutinen och sedan till kortet. När en viss bricka återgavs på kortet, lagrades den på kortet i komprimerat format så att den kunde återanvändas i framtida ramar. Microsoft beräknade att varje bricka kunde återanvändas i cirka fyra bildrutor i genomsnitt, och därigenom minska belastningen på CPU:n med cirka fyra gånger.
I Talisman bröts bildbuffertar upp i 32 x 32 pixlar "bitar" som renderades individuellt med hjälp av 3D-objekt och texturer som tillhandahålls av processorn. Pekare till bitarna lagrades sedan i en z-ordnad (framifrån till baksida) lista för varje 32 avsökningsrad på skärmen. En oro är att bitarna inte kan "sys ihop" rent, ett problem som ibland har varit synligt i olika videospel med mjukvarurendering . För att undvika detta lagrade Talisman också en separat "kantbuffert" för varje bit som lagrade ett "overflow"-område som skulle täcka luckor i kartläggningen.
Rendering pipeline
I ett konventionellt 3D-system genereras geometri periodiskt, skickas till kortet för sammansättning, komponeras till en rambuffert och plockas sedan upp av videohårdvaran för visning. Talisman-system vände i huvudsak denna process; skärmen var uppdelad i de 32 linjers höga remsorna, och medan videohårdvaran ritade en av dessa remsor ringde hårdvaran upp Talisman-sidan och sa åt den att förbereda detaljerna för nästa remsa.
Systemet skulle svara genom att hämta alla bitar som var synliga i den remsan med tanke på den aktuella kameraplatsen. I det typiska fallet skulle många av bitarna skymmas av andra bitar och skulle kunna ignoreras under sammansättningen, vilket sparar tid. Detta är anledningen till z-sortering av bitarna, vilket gör att de effektivt kan hämtas i "synlighetsordning". Om bitarna kunde modifieras utan distorsion anropades den korrekta affina transformationen för att uppdatera biten på plats. Om den inte kunde, säg för att kameran hade rört sig för mycket sedan den senaste fullständiga uppdateringen, ombads processorn att tillhandahålla ny geometri för den biten, som kortet sedan renderade och placerade tillbaka i lagring.
Talisman hade ingen analog till en rambuffert, och renderade bitar på begäran direkt till skärmen när bildskärmens skanningslinje fortskred ner på skärmen. Detta är en intressant analog med Atari 2600 , som använder ett liknande system för att återge 2D-bilder på skärmen, en metod som kallas "racing the beam". I båda fallen minskade detta mängden minne som behövs och minnesbandbredden som används mellan bildskärmssystemet och videohårdvaran. I båda fallen krävde detta också en dramatiskt tätare integration mellan videosystemet och programmen som körde det. I fallet med Talisman, krävdes programmen för att lagra sina objekt i ett speciellt format som Talisman-programvarudrivrutinerna förstod, vilket gjorde att det snabbt kunde plockas upp från minnet under avbrott .
Historia
Introduktion
Talisman-ansträngningen var Microsofts försök att kommersialisera koncept som man hade experimenterat med under en tid. I synnerhet kan PixelFlow-systemet som utvecklats vid ett Hewlett-Packard forskningslabb vid University of North Carolina i Chapel Hill betraktas som Talismans direkta förälder.
När Talisman först offentliggjordes vid SIGGRAPH- mötet 1996, lovade de en dramatisk minskning av kostnaderna för att implementera ett grafiskt delsystem. De planerade att arbeta med leverantörer för att sälja konceptet Talisman för att inkluderas i andra företags displaysystem. Det vill säga att Talisman hoppades vara en del av ett större mediachip, till skillnad från ett helt 3D-system som skulle stå ensamt i ett system. Deras grundläggande system skulle stödja 20-30 000 polygoner på en 1024 x 768-skärm med 32 bitar/pixel, med en polygonrenderingshastighet på 40 Mpixel/s och 320 Mpixel/s bildlagers sammansättningshastighet.
Escalante
Vid den tiden arbetade Microsoft med flera leverantörer för att utveckla en referensimplementation känd som Escalante . Samsung och 3DO arbetade tillsammans för att designa en single-chip DSP -liknande "Media Signal Processor" (MSP), som kombinerade Talisman-funktionalitet med ytterligare mediafunktionalitet. Cirrus Logic skulle tillhandahålla ett VLSI- chip som skulle hämta data som placerats i minnet av MSP, applicera effekter och skicka iväg den för visning. Känd som "Polygon Object Processor" (POP), pollades detta chip med jämna mellanrum av ett annat Cirrus Logic-chip, "Image Layer Compositor" (ILC), som var kopplat till videokretsen. Escalante avsåg dessutom att ha 4 MB RDRAM på två 600 MHz 8-bitars kanaler, som erbjuder 1,2 GB/s genomströmning. Senare Philips in i striden med en planerad ny version av deras TriMedia- processor, som implementerade det mesta av Talisman i en enda CPU, och Trident Microsystems , med liknande planer.
Det var mitt i Talisman-projektet som first-person shooter- genren började komma i förgrunden inom spel. Detta skapade marknadens efterfrågan på acceleratorer som kunde användas med befintliga spel med minimala förändringar. När Escalantes referensdesign var klar för produktion hade marknadskrafterna redan resulterat i en serie nyare kortdesigner med så förbättrad prestanda att Talisman-korten helt enkelt inte kunde konkurrera. Kort med stora mängder RAM-minne arrangerade för att tillåta extremt höga hastigheter löste bandbreddsproblemet och tvingade helt enkelt fram problemet istället för att försöka lösa det genom smart implementering.
Dessutom krävde Talisman-konceptet tät integration mellan displaysystemet och programvaran som använde det. Till skillnad från de nya 3D-kort som kom ut på marknaden vid den tiden, skulle Talisman-system behöva kunna be CPU:n att återrendera delar av bilden för att uppdatera sina bitar. Detta krävde att spelen hade en specifik organisation i minnet för att kunna svara på dessa förfrågningar. För att hjälpa utvecklare i denna uppgift ändrades Direct3D för att bättre matcha Talismans behov. Men för alla spel som redan hade skrivits, eller de som inte ville vara knutna till Talisman, gjorde detta D3D-systemet långsammare och betydligt mindre intressant.
Försvinnande
Som ett resultat av dessa förändringar blev Talisman aldrig en kommersiell produkt. Cirrus Logic och Samsung gav båda upp systemet någon gång 1997, vilket ledde till att Microsoft övergav planerna på att släppa Escalante 1997, och för externa observatörer verkade det som om hela projektet var död.
Det kom dock en kort återfödelse strax efter, när Fujitsu påstod sig arbeta med en enchipsimplementering som skulle bli tillgänglig 1998, med rykten om liknande projekt på S3 Graphics och ATI Technologies . Inget av dessa system har någonsin skickats och Talisman dödades tyst. Detta var till stor glädje för tredjepartsleverantörerna av grafikacceleratorer, såväl som de personer inom Microsoft som stödde dem på marknaden med DirectX .
Arv
Ändå har flera av idéerna som skapats i Talisman-systemet sedan dess blivit vanliga i de flesta acceleratorer. I synnerhet används texturkomprimering i stor utsträckning. På nyare kort har komprimering även använts på z-buffertarna för att minska minneskraven samtidigt som displayen sorteras. Idén att använda "bitar" för att sortera skärmen har också använts i ett litet antal kort, kallat kakelbaserad rendering , men det blir först konkurrenskraftigt på skrivbordet mycket senare, med lanseringen av NVidias Maxwell-baserade GPU:er år 2014. Många grafikprocessorer som är speciellt utformade för mobila enheter (som mobiltelefoner) använder en ruta-baserad strategi. Endast den enda nyckelidén med Talisman, att be om uppdateringar av geometrin endast "när det behövs", har inte försökts sedan dess.
externa länkar
- Chicken Crossing , kortfilm renderad i realtid med Talisman-koncept, presenterad på SIGGRAPH '96