Rich Geldreich wytyka błędy w OpenGL

Lepiej mieć jedno kompatybilne, ślamazarne i skomplikowane niż 3 maksymalnie wydajne i proste w implementacji?

Mantle też może działać na nvidii. To, że użytkownicy geforce’ów nie mogą korzystać z tego api, zależy tylko od nvidii.

To dość problematyczne, bo zależy od możliwości MMU i CommandBuffera GPU Nvidii. A nie opłaca się robić workaroundów na takim poziomie dla kompatybilności.

A dlaczego nie 30?

Mantle powstało bo jest problem z DirectX 11 i ich CPU. No i trzeba było pokazać, że coś są w stanie nowego wymyślić, a nie tylko gonić konkurencję. Nie lepiej by było gdyby AMD tę kasę władowało w usprawnienie swoich sterowników OpenGL i w promowanie tego rozwiązania? Ostatnie ruchy nVidii pokazały, że i w obsłudze DirectX 11 dało się zminimalizować narzut sterownika na CPU. Gdy dodasz do tego, że DirectX 12 ma być bardziej zoptymalizowany, a OpenGL z wydania na wydanie jest coraz lepsze, to gdzie tu miejsce na kolejne API?

Od lat siedzę na sprzęcie od AMD, a to piszę z laptopa które ma APU i Dual Graphics. Jestem już rozczarowany ich sprzętem i wsparciem.

Osobiście mam nadzieje, że długoterminowo OpenGL zwycięży. A kolejne standardy i implementacje będą coraz lepsze.

Może być i 30. To całe Mantle jest prostsze niż glibc, a rożnych implementacji glib jest przynajmniej kilka.

OpenGL przypomina HTML w czasach IE6. Każdy producent musi napisać swoją implementację. Każdy ma swoje rozszerzenia i swój profil wydajności. Każdy ma w innym miejscu buga. Jak dodasz do tego OpenGL ES to jesteś w piekle.
Więc w twoim twierdzeniu jesteś jak politycy. Niby przestrzegają i chronią przed złem, a wychodzi na to, że sami budują to przed czym straszą.

To ja już wolę prostą implementację, na którą można łatwo napisać wrapery do renderera, niż wielkie zabugowane i powolne monstrum. Gdyby ono było takie wspaniałe, to ludzie od otwartych sterowników nie musieli by się tak z tym męczyć. Nawet oni są dalecy od wzorcowej implementacji.

Testy na Phoronix pokazują, że sterownik nVidii nieraz jest wydajniejszy na Linuksie niż na Windowsie. To, że AMD musi gonić od kilku lat konkurencje to ich własna wina. Inna rzecz, że na kernelu 3.13 i Mesie 10 mam mniej problemów na Ubuntu niż na Win 8.1 – laptop mniej się grzeje, rzadziej rozkręca wiatraki, etc. Jedyny problem jaki mam to brak akcleracji dla playerów html5, ale nie sprawdzałem czy da się to jakoś włączyć. Jestem bardziej zadowolony z otwartego sterownika w przypadku mojego kompa z AMD.

Z tego co czytałem to OpenGL zapewnia masę „darmowych” draw calli. Bawiłem się trochę Godotem, tam mają renderer gles2, jedno z demek ma parę tysięcy draw calli a działa na kilkuletnich telefonach.

Rozszerzenia można olać i pisać tylko dla core. Poza tym jak się komuś nie chce pierniczyć z czystym OpenGL, to ma wrappery w stylu Ogre3D, albo gotowe silniki w stylu Godota i wtedy deweloperów nie obchodzi sprzęt, system, etc. Bo za nich wszystko robi silnik. Trzeba tylko zadbać o skrypty, assety i pomysł.

nVidia zapewnia świetne sterowniki własnościowe. Jakie są te od AMD to nawet nie chce mi się pisać… Intel z tego co obserwuję robi się coraz lepszy, tylko brak mu odpowiedniego sprzętu i oddelegowali deweloperów do Mesy. Mesa z wydania na wydanie jest coraz lepsza i sporo nadgoniła.

Warto zauważyć, że po ogłoszeniu Steam na Linuksa, oczy wielu zostały zwrócone w stronę OpenGL. Jako, że coraz więcej ludzi korzysta z tego API, a wcześniej przez lata siedzieli na Win i DirectX, to zgłaszają braki w narzędziach i różne problemy. Bo przez dekadę DirectX był mocno faworyzowany (ile w tym błędów ludzi odpowiedzialnych za OpenGL to inny temat). Jestem przekonany, że idzie ku lepszemu i że tego nie zepsują tym razem. A myślę tak dzięki obecności Steam na Linuksie, bo popularyzacja otwartego oprogramowania wymusi na producentach lepsze sterowniki OpenGL.

Co do Mantle to nie krytykuję jego architektury, ale to, że jest to jeszcze niedokończony wynalazek jednego producenta, nie ma wersji na Linuksa i jako, że jest to pomysł AMD które nie ma środków i mocnej pozycji, to jakoś nie widzi mi się adaptacja Mantle na rynku. Potrzebne są otwarte standardy, by uniknąć czegoś w stylu kolejnego Flasha. Na prawdę muszę tłumaczyć dlaczego?

OpenGL ma znacznie niższy narzut niż DirectX i dobrze zastosowany sam Core OpenGL potrafi zawstydzić Mantle. Z dodatkowymi możliwościami w rozszerzeniach zdejmujących kompatybilność wsteczną z jaką uwiązane są dalej DirectX/Mantle, a mimo użycia tych rozszerzeń nie ma problemu z napisaniem paru linijek fallbacku dla starszych urządzeń (niewyobrażalne w wypadku Mantle gdzie dla GCN używasz mantle, ale jeśli chcesz aby działalo też na kartach wcale nie takich starych jako falback stosujesz… przepisanie wszystkiego do DirectX).

Mantle wcale takie proste nie jest, a jak wiesz jest wiele implementacji libc i żadna ze standardem nie jest w pełni zgodna i każda działa inaczej.

OpenGL przypomina kompilatory C++ (każdy inny, żaden zgodny ze standardem ;p) i jest tak z tych samych przyczyn – brak standardowego kompilatora (dla GLSL dopiero powstaje) jak i brak testów zgodności (właśnie dla OpenGL zaczynają być wdrażane). Mantle czy CUDA też jeśli ktokolwiek poza twórcami pokusi się o implementację (praktycznie nierealne), wspierają rozszerzenia dokładnie jak OpenGL – jedyny bezrozszerzeniowy standard to Dx.

Ludzie od otwartych sterowników są dalecy od wzorcowej implementacji, bo po prostu są to najgorsze istniejące sterowniki. Najbliżej wzorcowej implementacji jest Nvidia, której implementacja praktycznie bagów nie ma (ma kilka jednak zupełnie nieistotnych i nie stosowanych w praktyce). AMD goni mocno i ostatnio wszysko co ważne wspiera dobrze (ma problemy z mniej ważnymi i żadziej stosowanymi rzeczami). Otwarte sterowniki nic nowego i ważnego nawet nie wspierają, a to co wspierają robią źle… śmiesznie wygląda więc „Nawet oni są dalecy od wzorcowej implementacji.”, bo zdecydowanie oni są najdalej i są wrzodem na tyłku OpenGL, któremu psują reputację.

OpenGL nie jest ani wielki (pomijając wiele wersji tej samej funkcji (zależnie jakie argumenty przyjmuje)), nie jest też zbuggowany (samo API takie nie jest, ale sterowniki mesa są bardzo zbuggowane, jednak podobnie by wyglądało Mantle czy cokolwiek innego pisane przez twórców Mesa), a już zdecydowanie nie jest powolny (pozwala na wyższą wydajność niż Mantle). Główną wadą OpenGL jest to co było wadą OpenCL względem CUDA… czyli brak standardowej wersji pośredniej shaderów/kerneli. OpenCL ostatnio dostał SPIR, a nad OpenGLą standardową pośrednią reprezentacją trwaja prace… kiedy powstanie nie będzie żadnych problemów z implementacją kompilatorów GLSL, ani z ich wydajnością, bo będzie jeden standardowy kompilator (jak w Dx).

Hej! Z tym Twoim argumentem dotyczącym zgodności Mesy ze standardem, to się chyba nigdzie indziej nie spotkałem. Na ogół mówi się o tym, że za problemy z Mesą odpowiedzialny jest brak stosownej dokumentacji, brak pieniędzy i większej liczby deweloperów. Mógłbyś napisać dokładniej na ten temat? Albo zarzucić linkami?

Masz przykładowo tu http://www.g-truc.net/doc/OpenGL%20status%202014-05.pdf porównanie przechodzenia testów przez ważniejsze implementacje, a Mesę biją nawet implementacje Intela (binarna) i Apple, które wśród programistów OpenGL Mac/Win służą za przykład jak bardzo sterowniki mogą być złe i odbiegać od standardów. Nie czepiam się jakiś egzotycznych nieużywanych rzeczy i błędów tam, bo mało kogo one obchodzą, ale w Mesa nie działa nawet instancing (API które w Core jest od ponad 5 lat (OpenGL 3.1), a jako rozszerzenie od 2006 roku). Mesa zgłasza, że obsługuje instancing, ale co z tego jak nie działa i gra Ci się wysypie (i gra nie jest w stanie bez testów tego wykryć, więc albo trzeba wykryć, że to Mesa i tworzyć specjalne ścieżki obchodzenia problemów, albo po prostu wyświetlić informację ). Ogólnie jeśli szukasz złych sterowników OpenGL to Mesa są najgorszymi ze stawki pod każdym względem.

Widać, że Rich ma ostatnio złe dni, bo w niektórych aspektach trochę wyolbrzymia (a może inaczej – widzi problemy, których nie mają programiści OpenGL, a programiści debuggerów OpenGL jak on ;p). Bo napisał nowy post „prawda o jakości sterowników OpenGL”:

http://richg42.blogspot.co.uk/2014/05/the-truth-on-opengl-driver-quality.html

OFC Vendor A to Nvidia, Vendor B to AMD, Vendor C to Intel z Driver 1 to binarne Windows, i Driver 2 to Mesa + otwarty sterownik Intela… inne to inne Mesa + sterowniki otwarte dla kart Nvidii i AMD.

O Mesa + intel słowa „A complete disaster.” czy „Hey guys – this driver just doesn’t work” nie oddają w praktyce jak złe one są.

To żeś mnie zasmucił. W sumie na Mesie odpalałem jedynie pulpit, przeglądarkę, nic 3D. Ale muszę to w końcu zrobić i porównać w paru benchmarkach wydajność Linuksa z Windows 8.1 na moim laptopie.

To akurat widziałem, ale myślałem, że to co Mesa wspiera jest OK. Czym to może być spowodowane? To znaczy złe działanie już zaimplementowanych rzeczy? Przecież mają dokumentację, doświadczonych programistów, jakichś ludzi na etacie. Na dodatek naczytałem się wielu dobrych opinii, że jak zagadasz na IRCu to nieraz szybko naprawią bug.

To są właśnie zaszłości, które widać jak na dłoni teraz, kiedy Valve śmiało wkracza z grami. Teraz, kiedy jest ekspansja gier widać, które sterowniki i implementację są dobre, a co było robione zawsze po prostu po to, aby jakoś działało.

Dzięki za linka do statusu obsługi OGL w sterownikach. Dodałem w newsie :-)

Skoro ten link się spodobał to pewnie ten z tym co sterowniki deklarują, że działa (deklarowane, że programista może API używać, a niestety nie faktyczne wsparcie jak powinno działać według specyfikacji) pewnie też:
http://www.g-truc.net/doc/OpenGL%204%20Hardware%20Matrix%202014-05.pdf

Grafika AMD pod linuxem nigdy nie będzie działać dobrze. Ledwo sobie ze sterownikem pod Windows dają radę, mimo że przeznaczają na niego setki razy więcej środków. W tej sytacji na sterowniki Linuksowe nadziei niema.