AMD udostępnia Khronos dokumentację Mantle

AMD udostępnia Khronos dokumentację Mantle

przez -
44 699
AMD
Kilka dni temu Khronos Group zapowiedziało następną generację OpenGL. Nowe API miałoby zostać napisane całkowicie od zera i posiadać najlepsze cechy AMD Mantle, Microsoft DirectX 12 oraz Apple Metal API, a jednocześnie pozostać w pełni wolnym oprogramowaniem. AMD postanowiło pójść o krok dalej i udostępniło Khronos pełny wgląd do dokumentacji ich własnego API – Mantle.

Richard Huddy na konferencji SIGGRAPH wypowiedział te oto słowa:

This is how we do it. If you want to take the same approach, go ahead.

czyli po polsku: Używajcie dowolnie i włączajcie tyle specyfikacji, ile chcecie. Dodatkowo AMD nie będzie pobierało żadnych dodatkowych opłat za licencje oraz nie będzie nakładało jakichkolwiek restrykcji.

  • o_O

    OpenGL nie jest wolnym oprogramowaniem. Nie jest w ogóle oprogramowaniem.
    Tylko OTWARTĄ SPECYFIKACJĄ, której implementacje są często zamknięte (choćby te zawarte w zamkniętych sterownikach). Choć są też otwarte implementacje: MESA.

    • Roman

      Problem w tym, że MESA nie jest implementacją OpenGL ;-)

    • W sumie to coraz zabawniejsza schizofrenia – po tym jak Intel certyfikuje mesowy OpenGL ES, a Brian Paul (twórca Mesy) tworzy rozszerzenia OpenGL4.5;)

      “Brian Paul, VMware, Mesa3D”
      https://www.opengl.org/registry/specs/ARB/clip_control.txt
      https://www.opengl.org/registry/specs/ARB/cull_distance.txt

    • pijaczek

      Intel certyfikuje OpenGL ES Mesowy, bo z OpenGL ES to zupelnie jest z jakością krucho. Jakbyś siedział w temacie to wiedziałbyć, że nie istnieją dobre sterowniki OpenGL ES (poza Tegra K1, ale to jest nowość i rzadkość). Żadne nie są zgodne, a większość działa wbrew specyfikacji. Testy zgodności przechodzą jednak wszystkie (ba przeglądarki z WebGL też, mimo, że też daleko im do zgodności).
      Testy certyfikacyjne GLES to dziurawe sito (w praktyce średnio kilkanaście % specyfikacji jest niewspierane lub działa źle – w najlepszych sterownikach nie działą około 8% OpenGLES) i przejdzie przez nie każde g… Mesie trzeba oddać jedynie to, że jest jedną z najlepszych implementacji OpenGL ES (dalej do dupy, ale są gorsze).

      Jednak w świecie OpenGL gdzie Nvidia ma implementację wręcz wzorcową, AMD niewiele już jest miejsc gdzie jest niezgodna ze specyfikacją… a Mesa jest bardzo, bardzo daleko za nimi będąc bardzo niezgodna z OpenGL i w OpenGL nie ma gorszych sterowników (są w GLES, ale to inne API).

      Nie rozumiem co niby chcesz przekazać, przez to, że brali udział w ustalaniu specyfikacji? VMware płaci skłądki do Khronos, więc mają wkład i pracują w workgrupie. Zauważ jednak, że to, że brali udział przy ustalaniu specyfikacji nie oznacza jeszcze implementacji. Nie rozpoczeły się jeszcze w Mesie pracę nad żadnym z wymienionych przez Ciebie rozszerzeń, a kiedy już powstaną nie wiadomo, czy będzie zgodne ze specyfikacją czy nie. Nvidia za to już zaimplementowała wszystkie 12 nowych rozszerzeń.

    • o_O

      I tak wiemy, że jest :)

      No bo tak to właśnie z tą niby otwartością specyfikacji OpenGL jest, że muszą się ukrywać i zakłamywać rzeczywistość…

  • o_O

    AMD niech się wali. Niech zaproszą nVidię, bo to jedyny poważny producent GPU.

    • TheBlackMan_dq

      Wiesz, że samoplusowanie swoich komentarzy to jak lizanie się po jajkach ? Chyba masz bardzo giętki kręgosłup.

      I nawet nie próbuj się wypierać, obserwuję cię od dawna.

    • M.C.

      Ja dałem “o_O” plusa bo się zgadzam z jego zdaniem, ale tobie też dałem plusa bo masz niezłą ripostę xD
      W ogóle to podobają mi się komentarze na tym portalu ponieważ piszą tu sami specjaliści i można się więcej ciekawych rzeczy dowiedzieć niż z samego newsa ;D

    • TheBlackMan_dq

      Nie chodzi o Ciebie, ten gość ma (na tyle ile go sprawdziłem) pemanentnie zaplusowane praktycznie WSZYSTKIE możliwe komentarze praktycznie WSZĘDZIE, niezależnie od ich treści.

      Troszkę podejrzane, nie uważasz ?

    • ehh

      Raczej ci goscie. Moze kiedys pod nickiem “o_O” trollowala, siala fud i flame jedna osoba, a teraz inni podlapali i uzywaja tego nicku by robic to samo i czesto bardziej zalosnie niz we wczesniejszym wykonaniu mialo to miejsce. Nie zmienia to jednak faktu, ze wszystkie komentarze tego nicku to zwykla prowokacja.

    • pijaczek

      Wypadku sterowników OpenGL to Nvidia ma najwydajniejsze i najbardziej zgodne ze standardem i tu ma rację. Inna sprawa jest taka, że AMD mocno pracuje i już prawie dogania Nvidię w swoich zamkniętych sterownikach OpenGL.

      Ogólnie o_O ma często rację (obiektywnie Qt jest najlepszym z dostępnych API widgetów, obiektywnie Nvidia robi najlepsze najlepsze sterowniki OpenGL i technicznie ma najlepsze GPU), ale sposób pisania, próby dewaluacji konkurencji (są gorsze, ale nie aż tak jak sugeruje) jest mocno wyolbrzymiony i przesadnie kontrastowy (jakby komentował formułę jeden i na metcie po 65 okrążeniach różnica na mecie wyniosłą 0.1s to ten pierwszy to mistrz, a ten drugi to dno, lepiej niech się do łopaty weźmie bo jeździć nie umie – taki styl komentowania wielu w tym mnie nie odpowiada).

    • o_O

      O ile wiem tylko ja “trolluję” pod tym nickiem. Jeśli ktoś się podszywa, to sam sobie wystawia świadectwo, ale nie zaobserwowałem ostatnio tego niegodnego zjawiska.

    • TheBlackMan_dq

      Mlask mlask mlask… Smakowało ?

    • o_O

      Nie chcę kontynuować bzdurnych wątków, ale… o czym ty w ogóle mówisz?

    • TheBlackMan_dq

      Przestań lizać własne klejnoty, bo najwyraźniej przeszkadza Ci to w czytaniu całego wątku ze zrozumieniem.

    • o_O

      Poziom komentarzy jest tu żenujący. I, wbrew opinii niektórych, wcale nie przeze mnie…

    • TheBlackMan_dq

      Na pewno samopodbijanie swoich własnych komentarzy poprzez wykorzystywanie luki w Disqus bardziej podnosi poziom, och Ty mój elokwentny, oczytany inteligencie pokradkiem liżący jajka swe ochoczo.

    • o_O to kretyn

      Więc po cholerę tu wchodzisz?

    • pijaczek

      Khronos to grupa firm, której członkiem jest Nvidia, więc ciężko sam siebie zapraszać (tym bardziej, że prezesem Khronos i szefem workgrupy pracującej nad OpenGL… jest wiceprezes Nvidii).
      AMD ma duże szanse przepchnąć Mantle – tak jak Apple zrobiło ze swoim OpenCL. API jest dosyć dobre, ma większość nowoczesnych możliwości (bindlessy wymyślone przez Nvidię itp) – wystarczy oszlifować wspólnie i stworzyć z tego standard dla wszystkich.

    • o_O

      Tak, źle to ująłem. Może bardziej: poprosiliby nVidię o zaproponowanie porządnego standardu.
      AMD niech lepiej nic swojego nie przepycha. A przynajmniej bez zgody i merytorycznego wkładu nVidii.

    • tomangelo

      Ale jak mają sami siebie zapraszać?
      Poza tym AMD udostępniło wszystko, ale nie nakazuje im wykorzystania wszystkiego. Co zechcą to zaimplementują.

    • o_O

      Pijaczek przyczepił się słusznie, ale ty już robisz z siebie idiotę. 1) Poprosić, nie zapraszać. 2) Jak spotkasz się z kolegami to też możecie razem poprosić jednego z was o coś, prawda? Teraz idź to przemyśleć.

      > Co zechcą to zaimplementują.
      Więc oby nic nie zechcieli. Albo chociaż żeby nVidia wcześniej to przejrzała i naniosła własne poprawki oparte na swoim doświadczeniu a nie produkowaniu nieużywalnych bubli jak AMD.

    • pijaczek

      AMD proponuje swoje API, a akurat API często bardzo fajne robią (MultiDrawIndirect czy Sparse Texture/Buffer jest od AMD i są to jednea z najlepszych rzeczy w OpenGL (inna sprawa, że lepiej działają w implementacji Nvidii)).
      W dodatku API zawiera wpływy Nvidii na technologię (m.in. Bindlessy).
      OFC Khronos może przystać na propozycję AMD aby przygarnąć całość lub część Mantle i rozwijać już w workgrupie. Jest to bardzo dobre rozwiązanie IMO, bo pozwoli na oparcie prac o gotową bazę i da więcej czasu na doszlifowanie detali (przez pracowników Nvidii, Intela i innych – czyli zabrać to co z Mantle dobre, a poprawić w grupie Khronos wspolnie to co jest zle lub nieoptymalne).

  • gość

    Może coś poprawią, bo OpenGL jest strasznie niekompatybilny pod względem kolejnych wersji. Próbowałem się uczyć OpenGL’a, każdy przykład wywala segfault przy inicjalizacji. Dlaczego? Nie wiadomo. Na innej karcie nie wywala (próbowałem na mającym niezłe wsparcie pod Linuksem Intelu). Po rzucaniu w kartę graficzną PORT’ami (karta Intela, więc jest dokumentacja jak ją programować) program mający te 90kB wyświetlił mi rotującą kostkę, ale GL nie działa. Aplikacje z repo – oczywiście w pełni działają. I tak wygląda sprawa OpenGL’a. Spójność by się przydała.

    • o_O

      OpenGL się nie segfaultuje, co najwyżej jego implementacje.
      A co bardziej prawdopodobne wrappery na nie (pewnie jakiegoś GLUTa używasz).
      A co najbardziej prawdopodobne, to twój program powoduje segfault bo robisz coś źle.
      Naucz się czegoś używać, a dopiero potem oskarżaj kogoś o błędy w jego kodzie.

      Intel nie ma dobrej implementacji pod Linuksem. Tylko zamknięte sterowniki nVidii są dobre.

    • pijaczek

      Wadą OpenGL jest to, że jest strasznie KOMPATYBILNY względem poprzednich wersji (właśnie to terach chcą zmienić i zerwać z kompatybilnością ;p).
      Piszę w OpenGL od lat i segfault to tylko i wyłącznie błąd w twoim kodzie, a nie w OpenGL. Najprawdopodobniej używasz jakiegoś narzędzia do pobierania rozszerzeń (GLEW? GLEE?) i próbujesz coś z OpenGL robić, zanim jeszcze stworzysz kontekst (możliwe też, że kod zupełnie niezwiązany z OpenGL wywala Ci ten błąd segmentacji).

      PS. mam nadzieje, że wiesz, ale sterowniki Intela pod Linuksem to najgorsza z możliwych implementacji OpenGL ;p – gorszej nie znajdziesz.

    • gość

      Żeby nie marnować miejsca na rekordy w bazie :) odpowiadam na oba w jednym:
      Do o_O:

      – Tak, wywala się wrapper.
      – Nie, nie mieszam w kodzie, odpalam wprost z tutoriala. Potem chciałbym sobie to przejść debuggerem w sposób “co jest w środku – do oporu”, moim zdaniem to najlepsza metoda jak się chce nauczyć jakiejś biblioteki.

      Do Pijaczka:
      No właśnie nie jest – te tutoriale wykładały się z powodu niekompatybilności – karta z 2010 leżała, a wszystko działało na karcie z 2012. Ten sam Debian.

      Niewiele pamiętam, ale to ogólnie wyglądało to tak, że szło polecenie do inicjalizacji czegoś (bufora?), ono szło “na Berdyczów” bo właśnie nie było kompatybilne z OpenGL’em w karcie, a segfault wypadał później, gdy próbowano działać na niezainicjalizowanych obiektach.

    • Jakub Konieczny

      Daj linka do tego tutoriala. Jakieś pół roku temu pisałem prosty engine na zaliczenia na studia, ale na wersję 2.0, bo mój laptop nowszego nie zna i też miałem wiele takich momentów że myślałem że ten kod nie ma prawa nie działać, a jednak błąd okazywał się być w kodzie. Ale fakt faktem że debugowanie tego metodami standardowymi (w sensie printy i rtyb debugowania) jest nieprzydatne.

    • pijaczek

      No pewnie, że printy nie mają sensu jak i debuger na CPU. Sens ma debugger na GPU (jak gDEBugger), glGetError lub rozszerzenia *debug* z nowszych wersji OpenGL. Instrukcje OpenGL wykonywane są asynchronicznie i printf pojawi Ci się w zupelnie innym miejscu niż postawiłeś (instrukcje OpenGL dodają je do kolejki, a wykonują później – błąd nastąpić może na długo po instrukcji w kodzie i debugger czy printf nie wie gdzie i kiedy (w wątku sterownika, a nie programu)).

    • pijaczek

      Tutoriale często są błędne i niezgodne ze specyfikacją (znajdziesz takie, które w shaderach GLSL wykorzystują funkcję…HLSL/Cg (bo przez pewien czas Nvidia pozwalała na swoich sterownikach więcej niż pozwalała specyfikacja – w tym używanie nieistniejących w OpenGL funkcji (sam nieźle się zdziwiłem gdy portowałem z Cg do GLSL lata temu shadery i działały mimo, że specyfikacja mówiła, że nie powinny – okazało się wtedy, że działa tylko na Nvidii (bo używali kompilatora języka Nvidia Cg również do kompilowania GLSL ;p)))).

      Co do inicjacji czegoś to ofc sprawdziłeś czy OpenGL zainicjował i nie zwrócił błędów (brak pamięci, niezgodna ze specyfikacją składnia… jakikolwiek z wielu możliwych błędów jak niekompletność tekstury/framebuffora… (co oznacza nie mniej nie więcej jak, że zapomniałeś o czymś do czego zmusza specyfikacja))? W tutorialu zapewne tego nie zrobili.

      Najlepiej powiedz jakie karty i podaj ten tutorial. Wykorzystuje OpenGL od 1999 i z doświadczenia wiem, że segfault to na 99.9% błąd programisty aplikacji, a nie sterowników (nie 100%, bo sterowniki jeszcze za czasów ATI przy teselacji potrafiły tak się wywalić).

    • rkowal

      Nigdy nie mogłem pojąć dlaczego starsze nie są implementowane za pomocą nowszej przy zerwanej kompatybilności (skoro DX jest implementowany w wine za pomocą GL to powinno się dać), i tak starsze funkcje są tak implementowane tylko już na poziomie driverów.

    • pijaczek

      Tylko kto by pisał te wrappery co wersję? Teraz dokładnie tak jest tylko za wrapper odpowiada twórca sterowników. Przykładowo Fixed Pipeline nie ma już nigdzie w sprzęcie. Użycie tak starego API (a jest go pełno – przykładowo Blender) sprawia, że trzeba by wydawać albo kilka sterownikow OpenGL każdy inny (jak to jest w DX, gdzie jednak to działa trochę inaczej, bo za implementację API odpowiada Microsoft w ich bibliotekach, a sterowniki to tylko backend), albo przerzucić na kogoś pisanie wrapperów. Jedno i drugie wyjście jest złe. W OpenGL do tej pory robiono to tak, że stare funkcje jak fixed pipeline miały wrapper w sterownikach (coś ala Wine) i “emulowano”/implementowano zachowanie tamtych funkcji w shaderach.
      Ogólnie rozwiązanie było dobre, bo i stare programy działały (jak blender z archaicznym wsparciem dla OpenGL) i API mogłobyć mimo to nowoczesne.

      Podsumowując jednak – właśnie tak jest robione – starsze rzeczy są implementowane za pomocą nowych… problem w tym, że zabiera to wiele czasu programistom sterowników (którzy w OpenGL są odpowiedzialni również za implementację OpenGL).

      Jednak przez ponad 20 lat wiele się zmieniło i o ile nie przeszkadza rozwijać API tak, aby wspierało dobrze nowoczesny sprzęt, to problemem jest to, że producenci sprzętu mają problem z pisaniem sterowników, które muszą zawierać ponad dwie dekady rozwoju OpenGL. Obecnie nadarzyła się okazja, aby zerwać wsteczną kompatybilność i sprawić, że sterowniki OpenGL zostają, a powstanie nowy standard (który znowu będzie wstecz kompatybilny pewnie przez najbliższe kilkanaście lat, ale już nie będzie ciągnął ogona z czasów gdy grafikę renderował CPU na początku lat 90tych).

    • rkowal

      I wchodzi na to, że implementacja bibliotek OpenGL na nowym api powinna być bardziej ekonomiczna (zrobiona raz) niż ciągnięcie dwóch sterowników, a przy ciągłym wzroście mocy kart graficznych powinna być wystarczająca wydajnościowo . Oczywiście ma to sens dla nowego sprzętu który powstanie.

    • pijaczek

      Nie. Implementacja starego OpenGL w Nowym to duża strata wydajności (duży narzut). I bardzo nieekonomiczna – sterowniki OpenGL istnieją… po co niby pisać nowe od zera z dodatkową warstwą pośrednią? Bezsensowne odkładanie pracy. Jak wyjdzie OpenGL Next to sterowniki OpenGL po prostu pozostaną takie jak są. Dopisany będzie po prostu mały zgrabny nowy sterownik (bez kompatybilności bo będzie nowym minimalistycznym Api, bez kompilatora shaderow, bo będą już skompilowane do IR…). Wszystko wskazuje na to że OpenGL Next nawet otwarte sterowniki będą dobrze wspierać (małe nowe Api w którym nawet kompilatora zepsuć nie można).

    • rkowal

      Miałem na myśli bardziej aspekt finansowy mówiąc o ekonomiczności. Narzut to jakieś 10-20% (tak jest wypadku dx w wine i raczej nie powinno być większe), oczywiście w niektórych sytuacjach 10% może być nieopłacalne. Dla takiej nvidii, przy ich driverach to nie ma sensu (wiele lat po ustaleniu nowego api nie będzie), ale jeśli pomyślimy o sprzęcie wywodzącym się z świata mobilnego (a tutaj dużo się dzieje) to jestem pewien, że nie będą pisać podwójnych driverów. I jeszcze jeden argument taka implementacja może być znacznie lepsza (jakościowo ale niekiedy wydajnościowo) niż bezpośrednie otwarte drivery.

    • pijaczek

      Narzut będzie większy niż w wypadku Dx… po prostu Dx pod Windowsem ma gigantyczny narzut i implementacja w OpenGL w wielu aspektach jest szybsza od Dx pod Windowsem. Dla Nvidii nie ma sensu, dla AMD nie ma sensu… dla Mesy też nie ma sensu (nie potrafią napisać dobrych sterowników OpenGL więc też nie liczyłbym na dobrą implementację z użyciem innego API (tym bardziej, że musieliby też je dobrze napisać)).
      Sprzęt wywodzący się ze świata mobilnego? Ten implementacji OpenGL nigdy potrzebować nie będzie (dziś nie obsługuje i nie ma takich programów dla których potrzebowałby wsparcia), a od razu wejdzie w OpenGL Next i też sensu nie widzę w tym aby wrapper taki robić.

    • o_O

      A czy obecny sprzęt będzie kompatybilny z OpenGL Next? To będzie tylko kwestia zmian w sterownikach, czy konieczność modyfikacji samego sprzętu by dostosować go do nowego projektu API?
      A jeśli to drugie, to czy postaną w początkowym okresie sterowniki emulujące OpenGL Next na starszym sprzęcie za pomocą dostępnych w nim funkcji?

    • pijaczek

      Najprawdopodobniej tak. Tzn spodziewam się od Kepler i GCN (chodzi o obsługę bindlessów, które Nvidia wprowadziła w pełni w Keplerze (w ograniczonej formie od Fermi), a AMD wprowadziło w arch GCN (i wspiera rozszerzenie Nvidii w OpenGL oraz jest to jedna z najważniejszych aspektów w Mantle (przez to też działa on tylko na GCN, a nie na starszych))).
      Intel zapowiedział, że kolejna generacja też będzie sprzętowo wspierać bindless, więc mamy komplet. Nie ma możliwości.