Chwila, nie wiem czy pamietacie ze na implementacje Opengl w linuksie (czyli Mesa) czekalismy *3 lata*
http://liquidat.wordpress.com/2007/06/27/mesa-70-released/

korekta: na implementacje opengl 2.0 czekalismy 3 lata. Ile na 3.0 bedziemy czekac?

Zważywszy na fakt, że jednym z założeń OpenGL 3 było uproszenie API i ułatwienie jego efektywnej implementacji w sterownikach myślę że znacznie krócej. Stawiam na pierwszy prototyp za pół roku i pierwszą stabilną wersję Mesy 8.0 za rok. Oczywiście NVIDIA pewnie uraczy nas działającymi sterownikami beta z OpenGL 3 już październiku (ciekawe czy tak jak było z 2.0 i 2.1 najpierw wyda wersję linuksową ).

Implementacja OpenGL jest w sterownikach karty graficznej. Mesa to biblioteka potrafiąca wysyłać do karty graficznej komunikaty OpenGL albo emulować je renderując programowo. Instalator driverów NVidia i tak kopiuje swoje wersje bibliotek OpenGL.

Mesa zawiera w sobie także sterowniki (a w każdym razie pewną ich część, odpowiedzialną za tworzenie 3D przez DRI) i jest mocno zintegrowana pod tym względem z X-ami, choć nie tylko, bo obsługuje też np. DirectFB i może akcelerować bez udziału X-ów (nie wiem jaki jest obecny staus tego portu).

Z drugiej strony OpenGL nie wymaga bezośredniego dostępu do sprzętu. Za zarządzanie kontekstem OpenGL odpowiedzialne są osobne warstwy systemu: WGL (Windows), GLX (ogólnie X Window przez sieć – dzięki temu rozszerzeniu, jeśli działa asynchronicznie, jest taka zabawa z Compizem, bez konieczności zagnieżdżania serwerów X aby zainicjować kontekst OpenGL), DRI (X.org – bezpośredni dostęp do sprzętu), EGL (specyfikacja tworzona głównie z myślą o OpenGL ES i urządzeniach wbudowanych, ale mogąca w przyszłości bardziej się upowszechnić), i inne.
NVIDIA jak już wspomniałeś ma swoje własne rozwiązanie bezpośredniego dostępu do sprzętu pod X-ami, zintegrowane ze sterownikami, ale implementuje także asynchronicznie GLX (z akceleracją – ta własność w X.org powstała niedawno i nazywa się AIGLX, wcześniej komendy protokołu GLX nie były w X.org akcelerowane).

chyba nie do konca rozumiesz o czym piszesz.
mesa jest implementacja opengl. podobnie razem z zamknietymi sterownikami od nvidii, dostajesz ich implementacje opengl.

mesa moze czesc rzeczy wykonywac ze wsparciem hardware (jesli sterowniki na to pozwalaja, czytaj “wspierajace dri”) ale nie musi – bo ma pelna obsluge softwareowa. ta obsluga NIE MA NIC WSPOLNEGO z emulacja.

zanim raz jeszcze napiszesz takie glupoty wczesniej poczytaj o temacie, ktory chcesz poruszyc…

btw. przez to “zagniezdzanie” i to ze wojtek szybciej odemnie napisal sie zagubilo to ze odpisywalem miariowi

Dobra biblioteka audio pozwoli Ci synchronizować dźwięk do obrazu, a OpenGL w połączeniu z SDL stanowi ładny zamiennik dla DirectX.

OpenGL jest o wiele bardziej zaawansowanym tworem do DXów, jest rozszerzalny i kompatybilny wstecz. API OpenGL jest stałe, przez co nie musisz przebudowywać całej aplikacji aby skompilować ja pod nowszą wersją, np celem użycia nowych efektów. API DirectX zmienia się z wersji na wersję i to w każdym obszarze, nie tylko w obsłudze grafiki. Oczywiście do nowszych wersji DXów dołączone są starsze funkcje, dzięki czemu starsze aplikacje działają … choć różnie z tym bywa. Podczas gdy nigdy nie miałem problemów z uruchamianiem programów OpenGL na nowszych wersjach tej biblioteki.

> troszke tak, ale wiesz jak wazne jest by wszystko bylo w jednym miejscu
Wyjaśnij, bo jednak nie wiem. A zarówno programowaniem grafiki, jak i dźwięku się zajmowałem.

> a grafa nie jest zupelnie inna rzecza bo musi dzialac w tym samym czasie co dzwiek. wiec jednak nie masz racji
Tak, a rower ma silnik i trzeba lać benzynę, bo stoi na parkingu obok samochodu i ma koła. Weź załóż może jakiś kabaret?

Tak jak wyżej pisałem, zmiany są poważne już teraz. Całkowicie przerobione API to znacznie więcej niż wsparcie dla kolejnej wersji SM (nota bene nie ma czegoś takiego oficjalnie w OpenGL, GLSL wystarczająco dobrze, póki co, oddziela bardziej niskopoziomową specyfikację SM od wysokoposiomowego kodu shaderów – to jego duża zaleta), która w kolejnych wydaniach nie będzie raczej powodować wstecznej niekompatybilności. To jest wydarzenie bez precedensu – wzięto sprawdzone rozwiązania z dotychczasoej wersji, wyrzucono starocie i stworzono od podstaw nową abstrakcję potoku graficznego. Dość powiedzieć, że teraz nie wystarczy już stworzyć kontekst do rysowania, potrzeba stworzyć jeszcze całe środowisko renderowania z odpowiednim buforem ramki włącznie. Początkujący mogą się poczuć nieco zagubieni, ale profesjonaliści czekali na to już od dawna.

Kto programował choć trochę w OpenGLu i zapozna się z obecnymi pracami zobaczy, że zmiany są dość drastycznie, do tego stopnia, że dla ułatwienia portowania aplikacji na OpenGL 3 powstały specjalne rozszerzenia umożliwiające częściową kooperację między kontekstami GL i GL3.

Twórcy nowej wersji API dokładają wszelkich starań aby ta zmiana miała miejsce pierwszy i ostatni raz, stąd tyle szumu wokół niej już teraz, jeszcze przed oficjalną premierą. Taka postawa jest naprawdę godna uznania. Połączenie dawnego ARB i Khronos naprawdę wychodzi na dobre zarówno twórcom sprzętu (szersze wykorzystanie) jak i użytkownikom (_dużo_ bardziej otwarta współpraca z developerami, zarówno komercyjnymi jak i indywidualnymi – vide forum).