W jaki sposób procesory graficzne obsługują zarówno uruchamianie OpenGL, jak i DirectX API?

Question

Próbuję zrozumieć, jak OpenGL i DirectX działają z kartą graficzną.

Jeśli napiszę program w OpenGL, który tworzy trójkąt, a drugi w DirectX, który robi to samo, co dokładnie stanie się z GPU?

Czy po uruchomieniu programu każde wywołanie biblioteki OpenGL i każde wywołanie biblioteki DirectX spowoduje wygenerowanie kodu dla GPU, a kod maszynowy GPU wygenerowany z tych dwóch programów będzie taki sam? (Podobnie jak DirectX i OpenGL są jak kod Java Bytecode, prekompilowany, a kiedy faktycznie działa, produkuje to samo)

Czy GPU ma 2 różne zestawy instrukcji, po jednym dla każdego. Mam na myśli, co jest exaclty OpenGL i DirectX dla GPU, jak może zrobić różnicę między 2 API?

Czy różni się to od perspektywy programisty?

Answer 1

już odpowiedział ci tutaj On Windows, how does OpenGL differ from DirectX?

pełny cytat z jednej z odpowiedzi następująco

---

To pytanie jest prawie niemożliwe, aby odpowiedzieć, ponieważ OpenGL sama w sobie jest tylko przedni koniec API, i tak długo, ponieważ implementacje są zgodne ze specyfikacją, a wynik jest zgodny z tym, można to zrobić w dowolny sposób.

Pytanie mogło być następujące: Jak działa sterownik OpenGL na najniższym poziomie. Teraz znowu nie da się udzielić odpowiedzi, ponieważ kierowca jest ściśle związany z jakimś sprzętem, co może znowu zrobić wszystko, co zaprojektował programista.

Pytanie powinno zatem brzmieć: "Jak wygląda przeciętnie za kulisami OpenGL i systemu graficznego?". Spójrzmy na to od dołu:

1. Na najniższym poziomie znajduje się jakieś urządzenie graficzne. W dzisiejszych czasach są to układy GPU, które zapewniają zestaw rejestrów sterujących ich działaniem (który dokładnie rejestruje się zależnie od urządzenia) mają pewną pamięć programową dla shaderów, pamięć masową dla danych wejściowych (wierzchołki, tekstury itp.) I kanał I/O do reszty systemu, z którego otrzymuje/wysyła strumienie danych i poleceń.

2. Sterownik karty graficznej śledzi stan GPU i wszystkie programy aplikacyjne zasobów, które korzystają z GPU. Jest również odpowiedzialny za konwersję lub jakiekolwiek inne przetwarzanie danych wysyłanych przez aplikacje (konwertowanie tekstur na format pikseli obsługiwany przez GPU, kompilowanie shaderów w kodzie maszynowym GPU). Ponadto zapewnia on abstrakcyjny, zależny od sterownika interfejs do aplikacji.

3. Następnie dostępna jest biblioteka/sterownik klienta zależny od sterownika OpenGL. W systemie Windows to dostaje ładowany przez pełnomocnika poprzez opengl32.dll na systemach Unix ten znajduje się w dwóch miejscach: w zależności

   • moduł X11 GLX i kierowca kierowca GLX
   • i /usr/lib/libGL.so może zawierać niektóre elementy zależne od sterownika do bezpośredniego renderowania:

   W systemie MacOS X jest to "struktura OpenGL".

   Jest to część, która tłumaczy wywołania OpenGL, w jaki sposób robisz to w celu wywoływania określonych funkcji sterownika w części sterownika opisanej w (2).

4. Ostatecznie rzeczywista biblioteka OpenGL API, opengl32.dll w Windows i na Unix /usr/lib/libGL.so; to głównie przekazuje polecenia do właściwej implementacji OpenGL.

Jak rzeczywista komunikacja dzieje nie można uogólnić:

W Unix 3 < -> 4 Połączenie może nastąpić albo poprzez gniazda (tak, to może, a nie iść na sieci, jeśli chcesz) lub poprzez pamięć współdzieloną. W systemie Windows biblioteka interfejsów i klient sterownika są ładowane do przestrzeni adresowej procesu, więc nie ma tyle komunikacji, ale proste wywołania funkcji i przekazywanie zmiennych/wskaźników. W systemie MacOS X jest to podobne do systemu Windows, tylko że nie ma żadnej separacji między interfejsem OpenGL a klientem sterownika (to jest powód, dla którego MacOS X jest tak wolny, aby nadążyć za nowymi wersjami OpenGL, zawsze wymaga pełnego uaktualnienia systemu operacyjnego w celu dostarczenia nowego struktura).

Komunikacja między 3 < -> 2 może przechodzić przez ioctl, odczyt/zapis lub poprzez mapowanie pamięci na przestrzeń adresową procesu i konfigurowanie MMU w celu wywołania kodu kierowcy po każdej zmianie tej pamięci. Jest to bardzo podobne w każdym systemie operacyjnym, ponieważ zawsze musisz przekroczyć granicę jądra/przestrzeni użytkownika: W końcu przechodzisz przez kilka syscall.

Komunikacja między systemem a GPU odbywa się za pośrednictwem magistrali peryferyjnej i zdefiniowanych przez nią metod dostępu, czyli PCI, AGP, PCI-E itp., Które pracują przez porty I/O, odwzorowane w pamięci I/O, DMA, IRQ .