Hur interagerar CPU och GPU för att återge datorgrafik?

Din dators centrala processorenhet (CPU) och grafikbehandlingsenhet (GPU) interagerar varje ögonblick du använder din dator för att ge dig ett skarpt och lyhörd visuellt gränssnitt. Läs vidare för att bättre förstå hur de arbetar tillsammans.

Foto av sskennel .

Dagens Fråga & Svar-session kommer till oss med tillstånd av SuperUser - en underavdelning av Stack Exchange, en gruppdrivande gruppering av Q & A-webbplatser.

Frågan

SuperUser-läsaren Sathya ställde frågan:

Här kan du se en skärmdump av ett litet C ++ - program som heter Triangle.exe med en roterande triangel baserad på OpenGL API.

Visserligen ett mycket grundläggande exempel men jag tycker att det är tillämpligt på andra grafikkortoperationer.

Jag var bara nyfiken och ville veta hela processen från att dubbelklicka på Triangle.exe under Windows XP tills jag kan se triangeln rotera på skärmen. Vad händer, hur interagerar CPU (som först hanterar .exe) och GPU (som slutligen matar ut triangeln på skärmen)?

Jag antar att involverat i att visa denna roterande triangel är främst följande hårdvara / programvara bland andra:

Hårdvara

• Hårddisk
• Systemminne (RAM)
• CPU
• Videominne
• GPU
• LCD skärm

programvara

• Operativ system
• DirectX / OpenGL API
• Nvidia Driver

Kan någon förklara processen, kanske med något slags flödesschema för illustration?

Det borde inte vara en komplex förklaring som täcker varje enskilt steg (gissning som skulle gå bortom räckvidden), utan en förklaring som en mellanliggande IT-kille kan följa.

Jag är ganska säker på att många människor som till och med skulle kalla sig IT-proffs inte kunde beskriva den här processen korrekt.

Svaret

Även om flera samhällsmedlemmar svarade på frågan, gick Oliver Salzburg en extra mil och besvarade den inte bara med ett detaljerat svar utan utmärkt tillhörande grafik.

Bild av JasonC, finns som bakgrund här .

Han skriver:

Jag bestämde mig för att skriva lite om programmeringsaspekten och hur komponenterna pratar med varandra. Kanske kommer det att belysa vissa områden.

Presentationen

Vad krävs för att ens ha den enda bilden, som du publicerade i din fråga, ritad på skärmen?

Det finns många sätt att rita en triangel på skärmen. För enkelhetens skull antar vi att inga vertexbuffertar användes. (A vertex buffert är ett minnesområde där du sparar koordinater.) Låt oss anta att programmet helt enkelt berättade grafikbehandlingsrörledningen om varje enskilt toppunkt (ett toppunkt är bara en koordinat i rymden) i rad.

Men , innan vi kan rita någonting, måste vi först köra några ställningar. Vi får se Varför senare:

// Rensa skärmen och djupbufferten
glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

// Återställ den aktuella modellvisningsmatrisen
glMatrixMode (GL_MODELVIEW);
glLoadIdentity ();

// Rita med hjälp av trianglar
glBegin (GL_TRIANGLES);

  // Röd
  glColor3f (1.0f, 0.0f, 0.0f);
  // Top Of Triangle (Front)
  glVertex3f (0.0f, 1.0f, 0.0f);

  // Grön
  glColor3f (0,0f, 1,0f, 0,0f);
  // Vänster av triangeln (fram)
  glVertex3f (-1.0f, -1.0f, 1.0f);

  // Blå
  glColor3f (0,0f, 0,0f, 1,0f);
  // Right Of Triangle (Fram)
  glVertex3f (1.0f, -1.0f, 1.0f);

// Klar ritning
glEnd ();

Så vad gjorde det?

När du skriver ett program som vill använda grafikkortet väljer du vanligtvis något slags gränssnitt till drivrutinen. Några välkända gränssnitt till föraren är:

• OpenGL
• Direct3D
• MIRAKLAR

I det här exemplet håller vi oss till OpenGL. Nu, din gränssnitt till föraren är det som ger dig alla verktyg du behöver för att göra ditt program prata till grafikkortet (eller föraren, som sedan samtal till kortet).

Detta gränssnitt kommer säkert att ge dig vissa verktyg . Dessa verktyg har formen av en BRAND som du kan ringa från ditt program.

Det API är vad vi ser används i exemplet ovan. Låt oss titta närmare.

Byggnadsställningen

Innan du verkligen kan göra någon faktisk ritning måste du utföra en uppstart . Du måste definiera din visningsport (det område som faktiskt kommer att återges), ditt perspektiv (den kamera in i din värld), vilken aliasing du kommer att använda (för att släta ut kanterna på din triangel) ...

Men vi kommer inte att titta på något av det. Vi tar bara en titt på de saker du måste göra varje ram . Tycka om:

Rensa skärmen

Grafikrörledningen kommer inte att rensa skärmen för dig varje ram. Du måste säga det. Varför? Det här är varför:

Om du inte rensar skärmen gör du det helt enkelt dra över det varje ram. Det är därför vi ringer glClear med GL_COLOR_BUFFER_BIT uppsättning. Den andra biten ( GL_DEPTH_BUFFER_BIT ) säger till OpenGL att rensa djup buffert. Denna buffert används för att bestämma vilka pixlar som är framför (eller bakom) andra pixlar.

Omvandling

Bildkälla

Transformation är den del där vi tar alla inmatningskoordinaterna (hörnpunkterna i vår triangel) och tillämpar vår ModelView-matris. Detta är matrisen som förklarar hur vår modell (hörnpunkterna) roteras, skalas och översätts (flyttas).

Därefter använder vi vår projektionsmatris. Detta flyttar alla koordinater så att de vetter mot vår kamera korrekt.

Nu transformerar vi ännu en gång med vår Viewport-matris. Vi gör detta för att skala vårt modell till storleken på vår skärm. Nu har vi en uppsättning hörn som är redo att återges!

Vi kommer tillbaka till transformation lite senare.

Teckning

För att rita en triangel kan vi helt enkelt be OpenGL att starta en ny lista över trianglar genom att ringa glBörja med GL_TRIANGLES konstant.
^{Det finns också andra former du kan rita. Som en triangelremsa eller a triangelfläkt . Dessa är främst optimeringar, eftersom de kräver mindre kommunikation mellan CPU och GPU för att rita samma mängd trianglar.}

Efter det kan vi tillhandahålla en lista med uppsättningar med 3 hörn som ska bestå av varje triangel. Varje triangel använder tre koordinater (eftersom vi befinner oss i 3D-utrymme). Dessutom tillhandahåller jag också en Färg för varje toppunkt, genom att ringa glColor3f innan kallelse glVertex3f .

Skuggan mellan de tre hörnpunkterna (triangelns 3 hörn) beräknas av OpenGL automatiskt . Det interpolerar färgen över polygonets hela yta.

Samspel

Nu när du klickar på fönstret. Programmet behöver bara fånga in fönstermeddelande som signalerar klicket. Sedan kan du köra vilken åtgärd du vill i ditt program.

Detta får en massa svårare när du vill börja interagera med din 3D-scen.

Du måste först tydligt veta vilken pixel användaren klickade på fönstret. Ta sedan din perspektiv med hänsyn till, kan du beräkna riktningen för en stråle, från musklickpunkten till din scen. Du kan sedan beräkna om något objekt i din scen korsar varandra med den strålen . Nu vet du om användaren klickade på ett objekt.

Så, hur får du det att rotera?

Omvandling

Jag är medveten om två typer av transformationer som vanligtvis tillämpas:

• Matrisbaserad transformation
• Benbaserad transformation

Skillnaden är att ben påverkar singel hörn . Matriser påverkar alltid alla ritade hörn på samma sätt. Låt oss titta på ett exempel.

Exempel

Tidigare laddade vi vårt identitetsmatris innan vi ritar vår triangel. Identitetsmatrisen är en som helt enkelt tillhandahåller ingen transformation alls. Så vad jag ritar påverkas bara av mitt perspektiv. Så triangeln kommer inte att roteras alls.

Om jag vill rotera det nu kan jag antingen göra matte själv (på CPU) och helt enkelt ringa glVertex3f med Övrig koordinater (som roteras). Eller så kan jag låta GPU göra allt arbete genom att ringa glRotatef innan du ritar:

// Rotera triangeln på Y-axeln glRotatef (mängd, 0,0f, 1,0f, 0,0f);

belopp är naturligtvis bara ett fast värde. Om du vill animerad måste du hålla reda på belopp och öka det varje ram.

Så, vänta, vad hände med allt matrisprat tidigare?

I det här enkla exemplet behöver vi inte bry oss om matriser. Vi ringer helt enkelt glRotatef och det tar hand om allt detta för oss.

glRotate producerar en rotation av vinkel grader runt vektorn x y z. Den aktuella matrisen (se glMatrixMode ) multipliceras med en rotationsmatris med produkten som ersätter den aktuella matrisen glMultMatrix kallades med följande matris som argument:

x 2 ⁡ 1 - c + cx ⁢ y ⁡ 1 - c - z ⁢ sx ⁢ z ⁡ 1 - c + y ⁢ s 0 y ⁢ x ⁡ 1 - c + z ⁢ sy 2 ⁡ 1 - c + cy ⁢ z ⁡ 1 - c - x ⁢ s 0 x ⁢ z ⁡ 1 - c - y ⁢ sy ⁢ z ⁡ 1 - c + x ⁢ sz 2 ⁡ 1 - c + c 0 0 0 0 1

Tack för det!

Slutsats

Det som blir uppenbart är att det är mycket prat till OpenGL. Men det är inte berättande oss något. Var är kommunikationen?

Det enda som OpenGL berättar för oss i detta exempel är när det är klart . Varje operation tar en viss tid. Vissa operationer tar otroligt lång tid, andra är otroligt snabba.

Skicka ett toppunkt till GPU kommer att vara så snabbt, jag skulle inte ens veta hur jag skulle uttrycka det. Att skicka tusentals hörn från CPU till GPU, varje enskild bild, är troligtvis inget problem alls.

Rensa skärmen kan ta ett millisekund eller värre (kom ihåg att du vanligtvis bara har cirka 16 millisekunder tid att rita varje bildruta), beroende på hur stor din visningsport är. För att rensa det måste OpenGL rita varje pixel i den färg du vill rensa till, det kan vara miljoner pixlar.

Annat än det kan vi nästan bara fråga OpenGL om funktionerna i vår grafikkort (max upplösning, max utjämning, max färgdjup, ...).

Men vi kan också fylla en struktur med pixlar som alla har en specifik färg. Varje pixel har således ett värde och strukturen är en gigantisk ”fil” fylld med data. Vi kan ladda det i grafikkortet (genom att skapa en texturbuffert) och sedan ladda in a skuggning , berätta för den skuggaren att använda vår struktur som en inmatning och köra några extremt tunga beräkningar på vår "fil".

Vi kan sedan ”göra” resultatet av vår beräkning (i form av nya färger) till en ny struktur.

Det är så du kan få GPU att fungera för dig på andra sätt. Jag antar att CUDA presterar liknande den aspekten, men jag har aldrig haft möjlighet att arbeta med den.

Vi berörde verkligen bara hela ämnet. 3D-grafikprogrammering är ett jävla odjur.

Bildkälla

---

Har du något att lägga till förklaringen? Ljud av i kommentarerna. Vill du läsa fler svar från andra tekniskt kunniga Stack Exchange-användare? Kolla in hela diskussionstråden här .