Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

OpenGL 4.4 czyli kolejny krok w rozwoju grafiki 3D

Khronos ogłasza OpenGL 4.4 dokładnie rok po wydaniu OpenGL 4.3
Podczas SIGGRAPH 2013 Khronos niezawodnie wydało kolejną specyfikację OpenGL w wersji 4.4. Ta wersja jak i poprzednie z serii 4.x działać powinna na wszystkich kartach graficznych obsługujących OpenGL 4 (jeśli producenci wydadzą zaktualizowane sterowniki).

Wsparcie od producentów GPU

W ciągu jednej doby Nvidia wydała już eksperymentalne sterowniki z nowym OpenGL'em, a AMD wreszcie dogoniło OpenGL 4.3, a obsługa 4.4 jest już zapowiedziana. Dużą zmianą w stosunku do poprzednich wersji "pełnego" OpenGL jest wymóg certyfikowania sterowników pod kątem testów zgodności które Khronos przygotował dla sterowników. Od czasu OpenGL 1.4 (czyli bardzo, bardzo, bardzo dawno temu), OpenGL nie posiadał oficjalnie takiego zestawu (programiści odpowiedzialni za sterowniki musieli takie tworzyć na swoje potrzeby, jednakże były one różne dla różnych producentów, a testy z projektu Mesa, były do nie dawna w ogóle nie zauważane i pokrywają w pełni tylko OpenGL 3.1). Zbiór testów powstał na bazie testów OpenGL ES 3.0 i testów które nadesłali członkowie Khronos, a całość na pewno przyczyni się do zmniejszenia ilości błędów w implementacjach OpenGL'a.

Nowości, czyli to co lubimy najbardziej

Jeśli chodzi o same nowości zaprezenowane przez Khronos, to możemy podzielić je na trzy kategorie:

(Kolejne) ułatwienia w portowaniu kodu z DX:

  • GL_ARB_buffer_storage -> Pozwalającą aplikacji na kontrolę w której pamięci powinny znaleść się dane potrzebne GPU dla renderowania. Przy założeniu, że aplikacja wie najlepiej co będzie robić z tymi danymi, może to zaowocować sporym przyspieszeniem w porównaniu do sytuacji gdy sterowniki błędnie zgaduje. Mechanizm ten był dostępny w DX, choć w mniej rozwiniętej formie.
  • GL_ARB_vertex_type_10f_11f_11f_rev -> Odpowiada formatowi upakowania 3 wierzchołków o mniejszej precyzji
  • GL_ARB_texture_mirror_clamp_to_edge -> Odpowiada trybowi łączenia tekstur z DX
Oprócz ARB_buffer_storage są to zmiany które zaoszczędzą programistom czasu przy przepisywaniu kodu z DX do OpenGL.

Druga kategoria to wymierne zmiany w API:

  • GL_ARB_query_buffer_object -> Pozwala na zostawienie danych z zapytań w GPU, tak, że CPU w ogóle nie musi być zaangażowane, ani też nie jest potrzebna synchronizacja pomiędzy CPU a GPU. Wzrost wydajności kiedy dane z zapytania mają być wykorzystane do kolejnych obliczeń na GPU.
  • GL_ARB_enhanced_layouts -> Pozwala na dokładniejsze określanie formatu danych wejściowych i wyjściowych dla shaderów, tak że nie trzeb ich specyfikować przez API (a kompilator i linker mogą dokładniej wymusić te wymagania).
  • GL_ARB_multi_bind -> To rozszerzenie poświęcone tylko poprawie wydajności. mW OpenGL "bindowanie" to operacja która ustawia w GPU konkretne obiekty jako te które mają być użyte. Takie operacje są kosztowne obliczeniowo (synchronizacja pomiędzy CPU a GPU, czas który sterownik GPU poświęca na przygotowanie operacji, czas który GPU poświęca na ustawianie, który mógł by być poświęcony na renderowanie). Od teraz operacje bindowania mogą być grupowane w jedno API, co powinno znacznie przyśpieszyć niektóre scenariusze.

Trzecia grupa czyli nowe (nie obowiązkowe) rozszerzenia ARB:

  • GL_ARB_bindless_texture -> Rozszerzenie wymyślone przez Nvidię, które zamiast bindowania tekstur do tak zwanych jednostek teksturowania (sprzętowych jednostek które pobierają dane z tekstur, na potrzeby dalszych obliczeń), wprowadzają wirtualne tekstury, gdzie ilość dostępnych adresów dla tekstur idzie w miliony. Odpada kosztowne bindowanie, a i ilość tekstur do których mają dostęp shadery na GPU rośnie o kilka rzędów wielkości
  • GL_ARB_sparse_texture -> Rozszerzenie tym razem od AMD, pozwalające na przechowywanie tylko części tekstury w pamięci GPU, dające kontrole nad tym które konkretnie dane znajdują się w pamięci w ręce programisty. Też potencjalnie ograniczające liczbę bindowań, oraz umożliwiającą lepsze wykorzystanie transferu danych do i z karty GPU.

Sterowniki Nvidi o których wspominałem na początku już obsługują ARB_bindless_texture i ARB_sparse_texture. Sterowniki od AMD jeszcze nie udostępniają żadnego rozszerzenia, jednak ARB_sparse_texture jest oparte o AMD_sparse_texture więc przynajmniej to rozszerzenie powinno szybko się pojawić.

Podsumowanie

Co w praktyce oznacza nowy OpenGL oraz nowe rozszerzenia? Khronos wywiązuje się ze swojej obietnicy szybkiego rozwijania OpenGL. Dodaje również niektóre obiecane możliwości z rewolucyjnego ale zawieszonego "OpenGL 3.0", w sposób ewolucyjny ułatwiając programistom pracę z API. Khronos zaczął też się troszczyć o zgodność sterowników ze standardem. Wyraźnie też widać, że szykuje się nam nowa generacja GPU czego wyrazem są nowe rozszerzenia. OpenGL 4.4 jest więc wyrazem solidnej strategii rozwoju API dla wysokowydajnych obliczeń graficznych. Świat w którym dominuje tylko jedna firma i jedno zamknięte API jest już za nami.

(Teraz czekamy na wieści o oficjalnym API w PS4 :D ) 

programowanie gry

Komentarze

0 nowych
  #1 25.07.2013 22:14

gimba// : Loll w PS4 będzie DirectX, bo OpenGL, to gówno, bo jest Ołpen...

A na poważnie, to świetnie, że takie zmiany następują, może z czasem wreszcie OpenGL zajmie zależne mu miejsce i podziękujemy Directowi :] troszkę by zagrało to przy okazji na nosku Mikromiekkim a i Linux by zyskał ;)

  #2 25.07.2013 23:09

W PS4 tak jak w PS3 będziesz wysyłał rozkazy bezpośrednio do Command Buffera GPU. Po co komu jakieś spowalniające API?

Yuri20   4 #3 26.07.2013 16:46

Rośnie i kila rzędów wielkości, nie rządów :D

przemo_li   11 #4 26.07.2013 18:39

@Yuri20
Poprawione :)

Marcin1147   4 #5 27.07.2013 13:34

SIGGRAPH, nie SIGHGRAPH :D

przemo_li   11 #6 27.07.2013 14:56

@Marcin1147
Poprawione :D

przemo_li   11 #7 28.07.2013 21:22

@Ryychuuu
OpenGL potrzebuje middlewaru i porządnych sterowników. API jest już bardzo dobre ( z widokiem na jeszcze lepsze gdy pojawi się sprzęt z kolejną iteracją sprzętu).

Do tego jest potrzebna popularność OSX i Linuksa na desktopach, Linuksa na konsolach (steambox) i Linuksa na urządzeniach mobilnych (Android & family).

Nowe wersje API, nie zmienią tutaj sytuacji tak bardzo jak firmy zarabiające miliony dolarów, potrzebujące narzędzi pod OpenGL :D ;)

@sprae
PS4 będzie posiadał rozbudowany OS (prawdopodobnie pochodna FreeBSD), i umożliwiał będzie natychmiastowe przełączanie do innych funjci (web, social, movie making, etc...).

Command Buffer nie będzie już dostępny na wyłączność dla gry.

Więc pewnie zobaczymy coś bardziej abstrakcyjniejszego.

Za to projektowanie takiego API (bo to dalej jest API ...), to dość duży wysiłek, który dodatkowo utrudnia biznes twórców gier, którzy chcieli by jak najłatwiejszego portowania (bo to oznacza jak największy zasięg wśród potencjalnych kupujących), oraz rozwoju oprogramowania.

"Pełne" API nie jest więc całkiem niemożliwe (MS -> Xbox One i DX11.2)...

(Sony oczywiście niczego nie potwierdził, więc nie wiem jak to będzie, tylko dzielę się swoimi uwagami)

  #8 29.07.2013 05:26

przemo_li: Przełączanie zapewni wirtualizacja. W jej ramach można GPU resetować i zmieniać kontekst w ułamku sekundy przy zmianie stanu konsoli. W razie wywalenia się gry można jej maszynę zabić, albo łatwo serializować stan na później.
Sony jest znane z tego, że daje developerom możliwość dowolnego manipulowania hardwarem, dzięki czemu mogą oni stosować niecodzienne sztuczki poprawiające wydajność. Taka jest tradycja prawdziwych konsol. Nad wszystkim i tak panuje supervisor.

Portowanie jest takim samym problemem jak między DXOpenGl. Duża część operacji GPU pokrywa się z tym co oferują biblioteki na niskim poziomie. AMD zapewni dodatkowo odpowiednie narzędzia i szkolenia.

Dla indyków powstanie jakaś namiastka biblioteki przypominająca znane rzeczy, ale bez szaleństw.

Sony pewnie nic nie powie. Takie rzeczy to tajemnica ze względu na możliwości explitowania i piracenia, które i tak się zwiększyły przez x86.