Joshua Barczak stwierdza, że OpenGL jest przestarzałe

Joshua Barczak stwierdza, że OpenGL jest przestarzałe

przez -
23 671
OpenGL

Joshua Barczak, który w przeszłości pracował dla firmy AMD, a obecnie zajmuje się rozwojem gry Civilization V w firmie Firaxis Games, zamieścił artykuł: OpenGL is broken. Post jest w pewnym sensie kontynuacją wypowiedzi Richa Geldreicha, który wytykał błędy w OpenGL. Według Joshuy, który posiada ponad dziesięcioletnie doświadczenie w programowaniu z użyciem wielu bibliotek, OpenGL w porównaniu do DirectX 11, czy Mantle jest bardzo przestarzałe.

Deweloper wytyka takie błędy w specyfikacji, jak:

  • Zbyt dużo wersji na różne systemy operacyjne
  • Jakość sterownika OpenGL jest bardzo zróżnicowana
  • OpenGL jest gorsze od swoich konkurentów
  • GLSL jest złe
  • Wielowątkowość w OpenGL to lekkie nieporozumienie
  • Obsługa błędów jest źle zaimplementowana
  • Obsługa tekstur i modeli wymaga większej liczby wywołań
  • Zbyt dużo dublujących się funkcji

Joshua Barczak zaznacza, że specyfikacja OpenGL musi zostać zaprojektowana od zera, jeżeli biblioteka Khronos i jej implementacje u producentów kart graficznych, miały konkurować z Microsoftowym DirectX lub AMD Mantle.

  • JA

    “OpenGL jest gorsze od swoich konkurentów” Tym to mnie przekonał ;)

    • Ollbi

      Tak czytam te wypowiedzi, przykłady itp. Zastanawiam się, czy to faktycznie deweloperzy są źli i leniwi, czy faktycznie Khronos w ogóle nie słucha się głosu programistów i nie chce zaprojektować całkowicie od zera specyfikacji OpenGL 5.0, zrywając wsteczną kompatybilność.

    • pijaczek

      Programiści OpenGL nie chcą przeprojektowanego od zera OpenGL. Programiści DX o tym marzą, bo nie potrzebowali by wiedzy co jest w OpenGL przestarzałe i jak to można zrobić lepiej (najłatwiej przeportować i nie móc zrobić źle… a wsparcie dla starszego sprzętu olać). Dla programistów OpenGL i tych celujących w największy target byłby to strzał w kolano. Khronos słucha głosu programistów i ze względu, że chcemy IR to prawdopodobnie dostaniemy go w sierpniu.

    • Jakub Konieczny

      Oba. Zerwanie kompatybilności byłoby bolesne, czemu by się to dalej OpenGL miało wtedy nazywać? I tak w tej chwili jest problem z Legacy OpenGL(przed 2.0) i Modern OpenGL (3.3 i po)
      Osobiście jak pisałem coś pod OGLa ostatnio to najbardziej mnie wkurzał brak dobrej KONKRETNEJ dokumentacji z najprostszymi przykładami zamiast opisu: macie takie i takie bufory, radźcie sobie.

  • DD

    Tak Mantle takie super a API nie jest nawet publicznie dostępne.

    • sprae

      A komu mają udostępniać i po co. Jest program w którym każdy poważny developer może się zgłosić, zapoznać i wyrazić swoje zdanie.

    • DD

      Po to bystrzaku żeby trafić do większej grupy docelowej. Poza tym Apple również zapowiedziało swoje API o nazwie Metal.
      Więc nie robi się ciekawie.

  • pijaczek

    Jako programista OpenGL odniosę się tu do zarzutów:

    – “Zbyt dużo wersji na różne systemy operacyjne” – tak… OpenGL 4.4 dla Linux i Windows w wypadku AMD i Nvidii, OpenGL 4.2 w wypadku Intela na Windowsa i 4.1 na MacOS X… o Mesa nie wspominam, bo nie chccę się denerwować. Jednak to i tak lepiej niż obecnie w DX11.2 (wszędzie poziom OpenGL 4.1… czyli taki jaki jest bardzo bezpieczny w OpenGL) lub Mantle (tu poziom OpenGL 4.4… tyle że tylko u AMD).
    – “OpenGL jest gorsze od swoich konkurentów”… ciekawi mnie w czym? Od DirectX jest lepszy prawie we wszystkim, Mantle jest możliwościami zbliżony, ale braki ma względem OpenGL + rozszerzenia u Nvidii.
    – “GLSL jest złe” – nie to mówi w orginale, bo GLSL jest dobre… problem jest w tym, że programista musi dostarczać w formie źródeł, a to zmniejsza wydajność (sterowniki OpenGL muszą kompilować kod w locie i nie mają czasu na mocniejsze optymalizacje). Tu jednak Khronos (dokładniej Nvidia, AMD, Intel, Valve i kilka innych firm) pracuje właśnie nad kompilatorem i oficjalną reprezentacją pośrednią (jak to niedawno Khronos zrobił do OpenCL czyli SPIR) – z dobrych źródeł wiem, że prawdopodobnie IR dla OpenGL będzie zgodny z DirectX IR (co za tym idzie i z IR mantle), co pomoże przy portowaniu (czytaj brak portowania shaderów, bo jeden shader niezależnie od języka, będzie można użyć w różnych API)
    – “Wielowątkowość w OpenGL to lekkie nieporozumienie” – tak, co więcej wielowątkowość w DirectX to jeszcze większe nieporozumienie (w wielu wątkach przekazywane jest do bibliotek DirectX, a dalej idzie jednowątkowo, przez co wielowątkowość powoduje spowolnienie, a nie przyspieszenie). Rozwiązania są 2… albo jak w Mantle czy DirectX 12 dać dostęp do command bufforów (ryzykowne podejście), albo jak w OpenGL 4.3 przenieść wielowątkowość na inny poziom i pozwolić, aby to GPU generowało samo sobie pracę, a nie polegało na CPU (dlatego dobrze napisany program w OpenGL bije Mantle),
    – “Obsługa błędów jest źle zaimplementowana” – widać, że Joshua dawno OpenGL nie widział i narzekanie na glGetError wygląda śmiesznie, podczas gdy nikt go nie używa (od lat mamy rozszerzenie ARB debug_output, a od 4.3 jest w Core (jednak już od 2010/11 jest używane w branży bo rozszerzenie było szybko u AMD/Nvidia/Intel (ba obecnie nawet Mesa wspiera oba rozszerzenia – jedynie MacOS nie, ale on ma swoje EXT_debug_*))), a obecnie zarządzanie błędami działa dokładnie tak, jak sobie programista tego życzy.
    – “Obsługa tekstur i modeli wymaga większej liczby wywołań” – tak i nie. Tak w standardzie, nie z rozszerzeniem DSA. Co do samych tekstur i “modeli” (bufforów wierzchołków) to za to ma znaczną przewagę na AMD i Nvidia – podczas gdy na innych API trzeba wszystko bindować (te wywołania trwają wieki) to OpenGL zarówno w sterownikach AMD jak i Nvidii wspierają Bindless (brak bindowania przez CPU, bo GPU samo wie co gdzie ma).
    – “Zbyt dużo dublujących się funkcji” – tak, ale nie jest to wielkim problemem. Tzn mogłoby być mniej wariantów tych samych funkcji różniących się parametrami, ale nie chciałbym obcięcia przykladowo starszych funkcji do wysyłania danych na GPU mimo, że dublują nowe. Powód jest prosty – stare aplikacje przestałyby dzialać (łącznie z blenderem wspierającym OpenGL tu na poziomie wersji 1.5), a dublowanie sterowników (inne stery do starszych wersji i inne do nowszych) mnie nie przekonuje. Osobiścię lubię mieć nowoczesne API jak OpenGL 4.4 + rozszerzenia, a dodatkowo łatwo wspierać starsze karty za pomocą kilku alternatywnych linijek. Mówienie, że Mantle jest takie fajne, bo jest jednoznaczne jest śmieszne w kontekście tego, że wspiera jedną architekturę jednego producenta i programista pisząc w Mantle musi napisać w Mantle (odpowiednik OpenGL 4.4) dla GCN i DirectX dla VLIW i innych producentów (odpowiednik alternatywnych kilku linii dla kart niewspierających) – parodią jest mówienie, że dx+mantle jest fajniejsze niż jeden opengl (jeszcze bardziej śmieszne jest zapominanie, że przy mantle trzeba pisać i tak osobną wersję w innym API).

  • sprae

    Tym czasem Apple pokazało własne API do 3D o nazwie Metall. Ma dawać 10x więcej drawcall-i od OpenGL ES3. Jasno stwierdzili ze OGL ssie.

    • pijaczek

      Tymczasem OpenGL 4.x pozwala na 100x (lub więcej) drawcalli niż OpenGL ES 3. To nie OGL ssie, a OGLES (ten odpowiada OpenGL 5 lat temu (a dokładniej to OpenGL z rozszerzeniami te możliwości miał w 2006), a nie ma nic wspólnego z nowoczesnym OpenGL).
      Wydaniem OpenGL ES 3 (i 3.1) jestem trochę zniesmaczony – wydawać okrojone API OpenGL 2.1/3.0 w dzisiejszych czasach jako nowe, gdy mobilny sprzęt potrafi obsługiwać OpenGL 4+ czy Dx12 wygląda na niesmaczny żart.

    • sprae

      Dziękuję za poprawkę błędu.
      Pokazali też nowy język programowania Swift.

      Wydaje mi się, że z możliwościami sprzętu trochę przesadzasz. Ciężko do takiego PowerVR podchodzić jak do GeForce.To się inaczej skaluje i inaczej renderuje. Przez co Nv ma problem, bo skalują w dół i konkurencja nie ma problemu z ich przegonieniem. AMD chyba nawet się tam nie pcha.

    • pijaczek

      Ja wiem czy ciężko? Na rynku mobilnym mamy:
      – Nvidia Tegra K1… czyli zwykły GeForce Kepler,
      – Intel Atom (z HD Graphics zgodnym z GL4.x),
      – Adreno 420 (zgodne sprzętowo z DX 11.1 i OpenGL 4.x (Qualcomm jednak nie napisał jeszcze sterowników)),

      Jedynie PowerVR i Mali mają przestarzałą architekturę (Apple musi kombinować, bo uzależniło się od PowerVR i zmiana to strata kompatybilności wstecznej z grami które już są (gry na iOS korzystają z kompresji tekstur dostępnej tylko na PowerVR)).

      Dlaczego się inaczej skaluje i inaczej renderuje? Zapewne wiesz, że desktopowe GPU Intela, Nvidii czy AMD to już praktycznie rendering kafelkowy. Ot mobilki dziś mają takie same możliwości jak desktopowe karty (no poza PowerVR czy Mali, które są na poziomie DX9c/GL2.1/GL3.0) i w praktyce można je traktować jako takie low-endowe karty desktopowe (gdyby tylko Google dało dostęp do pełnego API, a nie okrojonej atrapy).

    • sprae

      Tegry się nie chcą sprzedawać. Nvidia postanowiła ograniczyć produkcję tylko do tabletów. Ludzie narzekali na ich rozwiązania. W tej chwili większość jej rynku to pewnie stare Nexusy 7 bazowanie na rozwiązaniach z GF7xxx.

      Intel uruchamia Androidowe gry przez emulator z poważnym ograniczeniem wydajności. Z reszta ktoś zrobił testy i wyszło, że Atom jest oszczędniejszy od ARM tylko w idle.

      Nowe PowerVR też mają całkiem fajne rozwiązania. Np sprzętowe analizowanie odbić promieni. Próżno szukać obsługi tego w OpenGL i DX.
      Pewnie za 10 lat się dowiemy, że to była przyszłość,, tak jak dziś renderowanie kafelkowe, zakrzyczane kiedyś przez Nvidię.

    • pijaczek

      Tegry nie chcą się sprzedawać, bo prawie cały rynek zagarnia Qualcomm z Adreno. Mali czy PowerVR też praktycznie z rynku znikneły.

      Androidowe gry są w większości natywne pod x86, a popularność x86 w mobilkach ostatnio nie jest najniższa (do tego trzeba też dodać Core iX w wypadku tabletów W8).

      PowerVR ma swoje Caustic Graphic od 5 lat i nikt tego nie chce (to rozwiązanie jak fixed pipeline przy konkurencyjnych rozwiązaniach GPGPU pozwalających na pełną programowalność przy podobnej wydajności). W grafice dominują renderery GPGPU (niezależnie czy CUDA czy OpenCL), a Caustic… no cóż po prostu istnieje i przez 5 lat nikt tego nie chciał.

      PowerVR postanowił zrobić mobilną serię Wizard z dodaną jednostką z Caustic (jeszcze ich nie ma na rynku i nie ma tych jednostek w serii Rogue (Wizard obsługuje teoretycznie OpenGL 3.2/DX10). Jest to podobnie jak samo Caustic ciekawostka, to ofc jest przyszłość, ale tylko jeśli jest połączona z dynamiczną wielowątkowością, bo jeśli nie (w Caustic i Wizard nie) to szybsze jest liczenie wszystkiego w shaderach. Rendering kafelkowy też miał duże wady (sam miałem Kyro i nie dało się tego programować, bo same artefakty były) – ogólnie rendering kafelkowy pomaga tylko przy słabo zoptymalizowanych scenach (dopiero od instancingu/indirect tak naprawdę kafelkowy rendering ma większy sens), ale powoduje duże problemy przy stosowaniu “discard” w shaderach czy przy alpha testach.

    • Jakub Konieczny

      Tak, kolejny język programowania to to, czego nam trzeba. Kolejny prywatny język przeznaczony dla jednego rezerwatu. Funkcjonalnością nie prześciga żadnego nowoczesnego obiektowo-funkcyjnego języka (patrz: Scala), kwestia tylko kompilacji żeby to działało płynnie. Aby tyle że ten język nie jest tak dziwny jak Objective-C (co tam do cholery C w nazwie robi to nie wiem) że z dnia na dzień tego języka nie da się ogarnąć, wybitnie mało intuicyjny dla programistów języków o składni C (to już Haskella szybciej zrozumiałem).

  • Pingback: OpenGL oczami deweloperów gier | OSWorld.pl()