Khronos Group udostępnia slajdy dotyczące OpenGL-Next

Apple ma Metal.

Metal ma tylko na mobilkach i tylko ze względu, na zacofany GLES (którego narzut jest dziesiątki jak nie setki razy wyższy niż zwykłego OpenGL (metal chwali się 10x mniejszym narzutem – niezbyt wielki sukces)) i tylko dlatego, że są oni uwiązani z PowerVR (ich opatentowana kompresja tekstur jest standardem w iOS), a PowerVR jest w tyle z wydajnością (ba nie wspiera nawet OpenGL ES 3.0, bo ten wymaga lepszego sprzętu niż PowerVR daje) względem konkurencji, więc Apple musiało jakoś to wyrównać.

Metal prawdopodobnie nigdy nie pojawi się na desktopowym MacOS i prawdopodobnie szybko zniknie z iOS. Metal to poziom API z PS3 (podobne możliwości i koncept). Dziś jest to fajniejsze api niż GLES, ale tylko dlatego, że GLES jest słabe – Metal jednak nie dorasta do pięt obecnemu już OpenGL, Mantle czy nawet jak sądzi Intel i DirectX 12 (ze slajdów Intela wygląda na to, że MS wycofał się ze wsparcia dla archaicznego sprzętu i chce zrobić nowoczesne API (wymagane bindless itp.), które faktycznie konkurować będzie z Mantle/GL-next).

Dzięki za mądre słowa.

Każde własne API to samobójstwo i vendor lock-in dla dających się w to wciągnąć. MS z DX jakoś się udało bo się wybił gdy OpenGL spał. 3dfx upadł. Mantle – nikt rozsądny komu AMD nie zapłaci na niego nawet nie patrzy żeby napisać silnik tylko na karty AMD żeby posiadacze tych kart mieli kilka FPSów więcej.

IMO Google rozwiązało to lepiej z AES (tak to było?), w sumie to po prostu dostęp do funkcji GPU do których OpenGL ES nie dopuszcza (ale już są), ale to nadal sam OpenGL ES jest.

BTW co za kretyn pozwala tak nazywać rzeczy. Metal, Material, Modern, nie da się już nazwy własnej wymyślić, tylko lecieć po rzeczownikach stosowanych codziennie? A potem szukasz właściwości metali w necie na fizykę i dokumentacja Metala tylko wyskakuje.

Apple to wie… dlatego gdy tworzyło OpenCL od razu wciskało się z nim do Khronos, bo by umarło zanim powstało. Tym razem jednak chodziło o to, że ze względu na kompatybilność wsteczną są uwiązani do jednej firmy GPU… a ze względu na to, ze konkurencja wyprzedziła ich GPU mocno (Adreno i GeForce) byli zmuszeni do stworzenia takiego API na max kilka lat.

Google to akurat zły przykład ;p. Zamiast OpenCL forsują swój RenderScript (którego mimo to nikt kijem tknąć nie chce). Zamiast desktopowego OpenGL… chcą protezę w postaci OpenGL ES + AEP (Android Extension Pack, a nie AES – to jest szyfrowanie Advanced Encryption Standard ;p).
Najlepiej zrobiła Nvidia w swoim tablecie i ogólnie w sterownikach Tegra K1 – dają GLES3.1+AEP… ale też dają pełnego desktopowego OpenGL 4.4 (i mają kilka gier na wyłączność korzystających z pełnego GL).

Mówisz o firmie nazywającej się Apple i jeszcze się pytasz? Nie zdziwiłbym się gdyby za kilka lat chcieli pozywać huty (tak jak pozwali nowy jork za to, że miasto znane od niepamiętnych czasów znane jako wielkie jabłko wykorzystuje ten owoc w do promocji).

Każde różne API to konkurencja. Konkurencja przyspiesza rozwój. Chyba, że liczysz na oligopol Khronos, którego przewodniczącym jest v-ce prezes Nvidii.

Dzięki Mantle od AMD mamy dziś taki nacisk na nowoczesne, wydajne rozwiązania w dziedzinie 3d.
AMD zwyczajnie nie mogło wytrzymać zastoju, przez który nie mogą pokazać mocy swoich APU (słabe CPU + silne GPU ze wspólną pamięcią).
Nvidia przecież by nie wprowadziła wydajnego współdzielenia pamięci GPU/CPU bo mają w tym zakresie ograniczenia sprzętowe (emulują współdzielenie, a potem i tak kopiują dane do przestrzeni GPU).

Ostatecznie wygrywa to API, które jest wygodniejsze i bliżej przyzwyczajeń developerów. Na takim zwyczajnie wydajniej się pisze. Nie ma w tym żadnej ideologii. To czy OpenGL-NG się przyjmie jeszcze nie wiadomo. Ale tym razem konkurencja będzie bardziej zażarta.

Pełnię mocy APU może pokazać GL_ARB_buffer_storage, który w Core jest od OpenGL 4.4 (ale rozszerzenie istnieje od 2011 i zostało stworzone przez pracownika AMD ;p) + MultiDrawIndirect (rozszerzenie przenoszące generowanie drawcalli z CPU na GPU przez co odciąża zupełnie CPU – to rozszerzenie tego samego pracownika AMD – który zresztą z Jeffem
Bolzem z Nvidii odpowiadają za specyfikację OpenGL Next).
Problemem było raczej to, że mieli braki w OpenGL, a nawet je poprawiając i promując nie mieliby żadnej przewagi nad Nvidią, która OpenGL wspiera wzorcowo. Mantle daje taką przewagę bo jest tam gdzie nie ma Nvidii.
AMD nie wprowadziło wydajnego współdzielenia pamięci przecież ;p. Jest to zwykła powolna szyna ram (chyba nie trzeba mówić, że jej przepustowość jest niższa niż PCI-E, dlatego nadaje się takie rozwiązanie tylko do integry, bo większe GPU zadławiłoby się powolną pamięcią współdzieloną).
Dalej mówisz o czymś zupełnie innym czyli zero-copy – czyli dostęp bezpośredni do pamięci (nie tyle wydajny, bo ogranicza prędkość powolnych pamięci i w dodatku przeciskanie tego przez powolne PCI-E, ale bez konieczności udziału CPU i kopiowania). Nvidia faktycznie tu później weszła, bo dopiero z Maxwellem (GeForce 750 i 750 Ti już robią zero-copy tak jak GCN bezpośrednio na pamięci RAM). Jednak prawdziwą rewolucją w współdzieleniu pamięci może być NVLink (lub podobne konstrukcje konkurencji, jednak puki co nie widać ich na horyzoncie) pozwalający według zapowiedzi na przepustowość do 200GB/s (PCI-E 3.0 16x do 32GB/s) i znacznie więcej kanałów pamięci (dwukanałowe ledwo zapychają PCI-E, a dla GPU to dużo za niska przepustowość (nie bez powodu VRAM mają nawet 10x większą przepustowość, aby nie ograniczać karty)).

API prawdopodobnie będzie w C. W Khronos wszyscy mają świadomość tego, że tylko C jest standardem, a w wypadku implementacji C++ wszystko zależy od kompilatora (biblioteki skompilowane z kompilatorem X nie działają z programem kompilowanym z Y (mimo tego, że oba to C++)), więc raczej wątpię w inny język API niż C (a przynajmniej mam taką nadzieję).

Na WebGL odbije się to tak, że będzie WebGL-next.

Apple to wie od dawna (wcześniej jeszcze więcej z tyłu byli). Apple za to jest bardzo szczęśliwe, że nie musi implementować wszystkiego z OpenGL (czego nie mają i co mają popsute (a mają problemy nawet z GL 3.2)), bo mieliby więcej do roboty niż przy napisaniu sterowników GL-next od zera – prawdopodobnie zobaczymy u nich wcześniej GL-next niż GL4.4.