Te zmiany mogą się wiązać z chęcią przypodobania się branży gier komputerowych: bardzo się programistom gier podobał taki ruch w DirectX.

Szkoda, że autorzy niektórych innych narzędzi wizualizacyjnych polegali na wysokopoziomowym API języka C, w którym jednym wywołaniem funkcji ustawiało się parametry sceny, i gdzie prosty i spójny mechanizm maszyny stanów zawiadywał sposobem wyświetlania obrazu.

Właściwie nie jest poważnym problemem sam fakt nie wspierania przez karty bezpośrednio funkcjonalności wysokopoziomowych (jeśli będą one na przykład zaimplementowane > nad < nowymi niskopoziomowymi). Problemem jest zubożenie interfejsu i złamanie wstecznej zgodności.

OpenGL tradycyjnie nie był jedynie API dostępu do sprzętu graficznego, ale biblioteką graficzną (patrz na nazwę). W czasach, gdy pecetowe karty graficzne obsługiwały jedynie mały podzbiór funkcji "prawdziwego" OpenGLa ta reszta musiała być implementowana software'owo – nikt nie postulował wywalenia tych funkcji z argumentem "twórcy pecetowych gier ich nie potrzebują".

Trzeba było kiedyś posprzątać –
np. powolny (najgorszy z dostępnych) tryb bezpośredni (glBegin/glEnd), którego i tak nikt nie korzysta i listy wyświetlania których działanie było bardzo nieprzewidywalne – to jak działało zależało od twórcy sterowników (zostają tablice wierzchołków, VBO czy nowe w 3.0 VAO).

Działania na macierzach w sumie mogły zostać, ale i tak nikt poważnie ich nie traktował, bo były niezbyt wygodne i każdy pisał swoje klasy, które działają o niebo wygodniej, i dodatkowo można było napisać to optymalniej, z użyciem np. sse (teraz zapewne przepisze te działania do openCL).

Buffor akumulacji ostatni raz użyłem z 5 lat temu. Z bufforem selekcji jest gorzej… trudno przepiszę picking za pomocą fbo ;p.

Nie rozumiem głosów o zmniejszeniu możliwości fixed pipeline (tak naprawdę to nic nie zmniejszono tylko wywalono z core do rozszerzeń z powrotem), bo ja tu widzę tylko usunięcie zbędnych rzeczy (wszystkie można z powodzeniem zastąpić nowszymi i też bez shaderów) aby nowe firmy, które będą chciały implementować nie musiały się babrać ze starymi funkcjami – na razie dla programistów to nic nie zmienia, bo nVidia i amd mówią, że nie mają żadnych interesów, żeby wywalać wyrzucone ze standardu funkcje i funkcje zostaną (tylko standard będzie bardziej przejrzysty).

BTW. wywalenie fixed pipeline to normalna droga ewolucji – ten twór miał prawo istnieć tylko jeśli nie było większego dostępu do sprzętu.

@Zombiak: Nie tyle do przodu o lata świetlne co, implementuje rzeczy, które w openGL programista musi zaimplementować sam, i dx jest napisany w C++ (celniej działa podpowiadanie składni) dlatego łatwiej i szybciej się w nim pisze.

@stilgar: Jakie ograniczanie funkcjonalności? Wręcz przeciwnie to "fixed pipeline" była ograniczona w stosunku do programowalnego potoku i była jego kulą u nogi. Jedynym powodem dla którego to coś przetrwało tyle czasu jest ciągła presja producentów oprogramowania typu CAD/3D modelling, bo średnio im się kalkuluje przepisywanie części istniejącego softu.