2012-06-16 14 views
6

Zajmuję się linuxem i graficznymi interfejsami API, jednak jestem zdezorientowany tym, jak opengl jest implementowany w systemach operacyjnych. Czy jest to tylko zestaw bibliotek, które używają jądra do "rozmawiania" z kartą graficzną o pikselach do pokolorowania, czy nie? Jeśli tak, to nie wiem, skąd bierze się potok - jak rasteryzowane są sceny 3D, a geometria efektów shaderów.Jak działa OpenGl w systemie operacyjnym?

Jak GPU może obsługiwać języki modułu cieniującego zarówno z DX, jak i OGL? - i gdzie faktycznie mieszczą się języki modułu cieniującego - czy są one kompilowane lub interpretowane w czasie wykonywania?

Sam nie mam zbyt dużego doświadczenia z graficznymi interfejsami API, mimo że używam kilku silników do gier - zwykle nitty gritty są daleko zagubione z kilkoma warstwami abstrakcji.

+1

Mogłeś spójrz na serię postów na blogu, które mogą Cię oświecić: http://fgiesen.wordpress.com/2011/07/01/a-trip-through-the-graphics-pipeline-2011-part-1/ – rotoglup

+2

możliwy duplikat [Jak działa OpenGL na najniższym poziomie?] (Http://stackoverflow.com/questions/6399676/how-does-opengl-work-at-the-lowest-level) – datenwolf

Odpowiedz

0

Nie mogę porozmawiać z implementacją interfejsu API.

Ale wiem z doświadczenia, że ​​moduły cieniujące są kompilowane. Więc je skompiluj i wyślij na GPU, gdzie zostaną wykonane.

0

Przynajmniej na większości typowych kart graficznych większość rurociągu OpenGL (stały lub programowalny) jest zaimplementowana w samym sprzęcie graficznym. Jest to jeszcze bardziej prawdziwe w przypadku DirectX (tzn. W DirectX brakuje całkiem sporo funkcjonalności w OpenGL, który nie jest bezpośrednio obsługiwany przez bieżący sprzęt).

Shadery są zwykle kompilowane. Karta graficzna ma procesor specjalnego przeznaczenia (lub, często, więcej niż jeden), więc kompilator przyjmuje dane wejściowe w języku modułu cieniującego i zamienia je na język asemblera dla tego procesora, podobnie jak kompilator języka C dla procesora. Wspieranie różnych języków wejściowych nie jest dużo różni się od pojedynczego procesora wspierającego wejście w C, C++, Pascal, Fortran, COBOL, itp

Powiązane problemy