Raspberry Pi otrzymało obsługę w SDL 2

Najpierw aby był sens, Waylandowe kompozytory powinny usunąć wymaganie KMS/GEM, bo przy braku wsparcia dla OpenGL ES i EGL (a Raspberry PI ma sterowniki EGL i OpenGL ES 2 jednak binarne i nie korzystające z KMS), malinka nic na tym nie skorzysta – prędzej wsparcie dla MIRa, pod którym te sterowniki będą działać (podobnie jak pod Androidem).

Czytałem gdzieś, że Wayland jest realizowany softwareowo na Rabarbarze.

Skoro już jesteś to napisz o swoich zapatrywaniach na Mantle ;?

A jak ma być realizowany Wayland, hardwarowo? :) Przecież to oprogramowanie.
Wayland ma mieć tryb EGL, który ma działać na telefonach.

Ma być, ma mieć.
Pewnie jak Intel napisze obsługę sterowników Androida.

Niestety ma mieć o ile producent sprzętu będzie pisał specjalnie pod Waylanda i to z wykorzystaniem KMS. Wayland na R Pi i Weston działają z wyłączonym EGL i GLES jedynie na sterownikach 2D.

EGL ma, tylko problemem jest to, że wymaga on sterowników EGL i OpenGL ES korzystających z KMS/GEM.

Jeszcze niewiele wiadomo na temat AMD Mantle i co oferuje – jeśli będzie naprawdę niskopoziomowo to będzie fajnie… o ile Nvidia się przyłączy. Ciekawi mnie informacja na temat 9x więcej DrawCalli niż w DirectX… mniej więcej na tyle pozwala i Nvidia w OpenGL (sam pozwala na więcej DrawCalli, bo ma mniejszy narzut) dzięki rozszerzeniu Bindless Graphics (7x więcej DrawCalli według Nvidii). i Bindless Graphics teraz razem z OpenGL 4.4 stało się standardowym rozszerzeniem, które ma wspierać AMD. Inna sprawa, że Bindless Graphics to był najniższy poziom dostępny do tej pory z PC.
Ogólnie zobaczymy co dokładnie AMD pozwoli w tym API (jeśli bezpośredni dostęp do command buffora tak jak w konsolach (PS znowu nieszczęsny GEM który w otwartych sterownikach zarządza command bufforami powinien polecieć do kosza ;p – czytaj Mantle będzie wymagać aby sterowniki NIE korzystały z KMS i GEM ;p) to będzie super… ale jakoś wątpię, aby to przeszło na PC).

Dzięki, fajnie napisałeś i jeszcze z ciekawostkami.
Czytałem też, że na mobilnym sprzęcie DrawCall-e nie mają tak dużego wpływu na wydajność, bo pamięć jest współdzielona i zoptymalizowana pod tym kątem. Wiesz coś na ten temat?

Co do Nvidii to wydaje mi się, że by musieli napisać własne Mantle. Mają trochę inna architekturę. No chyba, że chodzi w tym tylko o własnoręczną optymalizację zmian stanu i transfery.

Co tu dużo mówić… ktoś Cie wprowadził w błąd. Na mobilnym sprzęcie DrawCalle są badziej ograniczone niż gdziekolwiek indziej. Współdzielona pamięć nie jest na wszystkich mobilkach, ale nawet przyjmując, że jest nigdzie nie jest chyba obsługiwana przez wskaźniki bezpośrednie, a kopiowana z pamięci CPU do pamięci GPU (nawet w obrębie tej samej pamięci).
Sama pamięć czy współdzielona czy też nie nie ma wielkiego znaczenia – kopiowanie danych (poza wirtualnymi teksturami (dalej rzadko stosowane) czy uniformami) odbywa się podczas ładowania sceny, a dalej jest już lokalnie na GPU. To nie jest problemem. Problemem jest to, że GPU nie wiedzą co gdzie jest i trzeba im wszystko ręcznie pokazać. Przykladowo chcesz użyć tekstury X.png no to podczas ładowania przesyłasz (tu czas nie jest istotny jeszcze), a później przy drawcallach musisz zbindować teksturę którą wysłałeś na ten i ten adres w pamięci (niezależnie czy współdzielona czy nie) podepnij (zbinduj) pod numerem 1, ten atrybut pod tym numerem, ten uniform pod numerem tym… to generuje straszny narzut – w konsolach jak PS3 rozwiązywało się to mając bezpośredni dostęp do command bufforów i cały się odpowiednio wcześniej budowało praktycznie na stałe i przesyłało hurtem dzięki czemu bindowanie nie było takie straszne (w OpenGL od wersji 4.4 mamy podobne rozwiązanie GL_ARB_multi_bind które pozwala na bindowanie całego setu za pomocą jednego Calla – gorsze niż Bindless od Nvidii, ale zadziała wszędzie niezależnie od sprzętu). Nvidia wymyśliła kilka lat temu Bindless Graphics czyli karta graficzna zapamiętuje sobie co gdzie i jak ma wysłane i nie trzeba jej nic bindować tylko z shadera bezpośrednio do odpowiedniej tekstury się odwołać (a gpu już będzie wiedziało gdzie jest), a od serii Kepler rozszerzyła Bindless Graphics o Bindless Textures. To rozszerzenie praktycznie eliminuje sensowność niskopoziomowych zabaw, bo jest po prostu lepsze… ale wymaga od strony sprzętu wsparcia, czyli pamiętania wskaźników na dane (do tego ARB_sparse_texture (przydatne przy PTex, Virtualnych Texturach itp) od AMD które razem z Bindless Graphics stało się oficjalnym rozszerzeniem i jest już wspierane w sterownikach Nvidii), ale im niżej tym fajniej. Jednak mobilne GPU tego nie potrafią i trzeba przy każdym drawcallu im wszystko bindować, a "dzięki" słabszym rdzeniom ograniczenie jest większe niż gdziekolwiek indziej.

Wszystko zależy od tego jak niskopoziomowe to będzie.

Wspaniale mi to wytłumaczyłeś. Nie pozostało mi nic innego niż wszystko przetestować. Szczególnie, że jestem w posiadaniu GPU od Nvidii.

Dzięki!

Przypomniałem sobie gdzie to o Draw na mobile widziałem: http://www.youtube.com/watch?feature=player_detai…

Tu koleś gada, że w Mali DrawCalle wcale się nie wykonują, tylko kolejkują do czasu wywołania Swap.

DrawCalle działają inaczej, ale dalej mają podobny wpływ na CPU. Mobilne GPU (poza Nvidią) nie są podobne do tych z PC czy konsol, a renderują kafelkowo (niejako naturalny dla nich jest Deferred Rendering), ale zobacz sobie co mówią na temat tego jak optymalizowac od 22:38 na powyższym filmiku – minimalizuj DrawCalle bo one nie są za darmo i jest to główna ograniczająca rzecz… druga rzecz jest w tym, żeby sortować rendering po materiałach i renderować w grupach (aby nie zmieniać stanów)… czyli właśnie aby nie przebindowywać shadera, tekstur, uniformów… na PC nie ma to tak dużego znaczenia ze względu na szybsze procesory niż na mobilkach (tam za to warto sortować po odległości od kamery i renderować najbliższe na początku co w renderingu kafelkowym nie jest potrzebne).

Ale w którym miejscu jest powiedziane, że jest wymagany KMS/GEM. Wydaje się mi, że jest wymagane EGL plus jedno rozszerzenie.

Wayland nie wymaga KMS/GEM… jednak pośrednio wymusza to na kompozytorach, dlatego wszystkie (Weston, KWin, Mutter/Clutter, Enlightenment…) wymagają KMS i GEM – dopiero jak będą zmiany w samym Waylandzie to i kompozytory w wersjach dla waylanda (i tylko tych) przestaną wymagać KMS.
Ofc te zmiany prawdopodobnie będą, bo MIR zrobił na tyle zamieszania, że Intel już chce zmienić model sterowników na niewymuszający konkretnego rozwiązania poza samym EGL (jak w Mir, X11 czy Android).

KMS rozumiem i tak binarne drivery to mają tylko z nieupublicznionym api. Ale po co GEM, tym bardziej Weston potrafi działać z bakendem softwarowym.

KMS binarne sterowniki nie mają (PS. KMS wymaga GEM), a mają własne wydajne implementacje specjalnie dla swoich GPU bez żadnego związku z KMS i GEM.
Weston potrafi działać softowo, ale tylko w 2D, bez wsparcia dla EGL i OpenGL/OpenGL ES. Kiedy tylko Weston chce kompozycje robić sprzętowo to wymaga KMS (przez co i GEM).

Czyli i tak implementują funkcjonalność KMS tylko w sposób naturalny dla danego sprzętu zamiast implementacji w jądrze.
Pytanie trochę zboku, co ma KMS do wydajności pomijając fakt, że podstawowa implementacja w Linuksie bazuje na GEM? Chyba, że pod pojęciem KMS kryje się trochę więcej niż sugeruje Wikipedia.

Nie. Kernel Mode Setting (KMS) to metoda ustawiania trybu wyświetlania: rozdzielczości ekranu, głębokości kolorów… w przestrzeni jądra, a nie w przestrzeni użytkownika – zamknięte sterowniki robią to w przestrzeni użytkownika i z KERNEL Mode Setting nie mają nic wspólnego. Samo KMS byłoby wykorzystywane przez zamknięte sterowniki, gdyby nie to, że z KMS wiąże się przymus wykorzystania GEM. I nie ma czegoś takiego jak podstawowa implementacja w Linuxie – KMS jest jeden w jądrze i wymaga GEM – inne to User-space Mode Setting (UMS, a nie KMS).

Do wydajności ma wszystko GEM – czyli zarządzanie pamięcią karty graficznej, zarządzanie kontekstem wykonywania itp. to co się kryje pod GEM to jest istota całej wydajności sterowników, a GEM jest tak uniwersalny, jak mało wydajny.

Z tego co pamiętam ktoś uruchamiał już raspbiana z wayland o tu jest opis pyk: http://wayland.freedesktop.org/raspberrypi.html