Praktycznie każdy producent SoC (Nvidia, Samsung, Qualcomm, TI...) udostępniają płytki dla programistów - wystarczy wejść na stronę producenta SoC.
Przykładowo Snapdragon swoje płytki (w tym 800) ma wypisane i podane linki gdzie kupić tu https://developer.qualcomm.com/mobile-development...

Nvidia płytki swoich partnerów ma wypisane pod https://developer.nvidia.com/tegra-hardware-sales...
Samsung ma swoje http://www.samsung.com/global/business/semiconduc...
...

Co do przykładu takiego GC to jest Boehm GC który jest najpopularniejszym GC dla C/C++ (dla C ma własne funkcje jak GC_MALLOC..., a dla C++ przeciąża operatory new/delete dla kontenerów STL i typów wbudowanych, a jeśli chce się, aby zarządzał twoimi klasami to wystarczy, aby klasa dziedziczyła po klasie gc i już jej odśmiecaniem zajmuje się GC) i jest włączony jako część GCC (wykorzystywany jest przez przykładowo Mozillę... ale też kompilator Javy do natywnego kodu (GCJ) czy implementacje .NET czyli Mono/Portable.NET). Jest to GC bardzo konserwatywny... i bardzo powolne (wolniejsze niż w Javie czy NET). Problemem Boehm GC jest to, że nie zabiera więcej pamięci niż potrzebuje... czytaj nie prealokuje sobie miejsca na dane wcześniej, a po prostu na żądanie alokuje (co jest tragiczne w skutkach, bo jedna duża alokacja danych jest robiona szybko, a wiele małych alokacji jest zabójcze dla wydajności).
Inna sprawa jest taka, że każdy dosyć rozgarnięty programista w C++ zrobi sobie manager pamięci prealokujący pamięć na program (o ile jest potrzebny, bo dużo się alokuje w programie małych rzeczy), oraz GC oparty na zliczaniu referencji i mądrych wskaźnikach... takie rozwiązanie nie tylko będzie bardzo szybkie (narzut jest minimalny), ale też będzie bardzo szybko reagować i zwalniać pamięć (czy to fizycznie dealokować, czy tylko zwalniać miejsce zaalokowane w managerze które będzie mogło być wykorzystane przez przyszłe żądania alokacji przez program (gdzie zamiast tracić czas na alokowanie dostanie po prostu wskaźnik na już wcześniej zaalokowaną pamięć)).

Jednak to nie w GC upatrywałbym problemów (tzn wymagania specyfikacji javy od GC są takie, że szybkie zliczanie referencji nie wchodzi w grę, i GC ma w konkretnych implementacjach istniejących bardzo duży narzut, ale to jeszcze mały pikuś). Problemem jest raczej w tym, że Java jako język został zaprojektowany jako język kompilowany do bytecodu (jeśli dobrze pamiętam to implementacje natywne naciągają to co jest w specyfikacji Javy...), a to niesie ze sobą słabszą optymalizacje kodu (niezależnie czy stosują JIT czy AOT, dalej nie uzyskają tego co kompilacja offline, gdzie optymalizacja kodu może trwać dłużej), a i to, że jest to język zarządzany odpalany w środowisku natywnym mu nie pomaga, bo komunikacja kodu zarządzanego z kodem natywnym (niezależnie czy to JNI z javy czy CLI z .NET ma olbrzymi narzut).

Canvas nie ma żadnych wymagań sprzętowych - Canvas w HTML5 to po prostu API i od przeglądarki zależy czy zaimplementuje to na CPU (jak Qt, GTK i inne biblioteki widgetów, które Canvas robią na CPU) czy przerzuci obliczenia na GPU. Co do WebGL to wymaganie jest dosyć proste - OpenGL ES 2.0 czyli najpopularniejsza wersja OpenGL do urządzeń wbudowanych, które znajdziesz na każdym nawet słabym smartphonie. Problem w tym, że OpenGL ES 2.0 to api zupełnie różne od OpenGL i mimo, że opiera się na wersji 2.0 OpenGL, bliżej mu do 3.1, a w niektórych aspektach (jak ARB_get_program_binary) 4.1... nie bez przyczyny na desktopowych wersjach OpenGL kompatybilność z OpenGL ES 2.0 (ARB_ES2_compatibility) zapewnia dopiero OpenGL 4.1 (z OpenGLES 3.0 kompatybilny jest OpenGL 4.3).

Przeglądarki, aby nie mieć tak dużych wymagań próbują napisać zgodną z OpenGL ES 2.0 implementację za pomocą innych API - w Windowsie za pomocą DirectX ( http://code.google.com/p/angleproject/ ), a pod MacOS i Linux w OpenGL 2.0 + rozszerzenia... jednak trzeba wkładać podobną pracę jak w wersji DirectX... czytaj GLSL ES trzeba tłumaczyć na desktopowe GLSL (w DirectX na HLSL), trzeba uwzględniać inne zachowanie niektórych rzeczy w tych API...
Najgorsze w tym wszystkim jest to, że otwarte sterowniki korzystające z Mesa mają duże problemy ze zgodnością z OpenGL nawet w wersji 2.0 przez co są bardzo problematyczne dla twórców przeglądarek i zazwyczaj WebGL (a pełna błędów implementacja OpenGL Apple dla MacOS nie pomaga). Dlatego praktycznie jeśli chcesz WebGL to korzystaj z zamkniętych sterowników.
Jest szansa, że w przyszłości przeglądarki pod Linuksem będą po prostu robić kontekst OpenGL ES 2 (otwarte sterowniki go wspierają i o dziwo są dosyć dobre), ale obecnie... zamknięte sterowniki go nie wspierają (AMD ma tylko EGL dla deweloperów, a Nvidia testowe EGL dla 32bitowych x86)... wtedy powinno być po wszelkich problemach z emulowaniem GLES w GL, bo będzie działało bezpośrednio w GLES (czytaj całe problemy z implementacją WebGL będą przerzucone z twórców przeglądarek na twórców sterowników).

PS. Co do syfiarskiego flasha to ma on język ActionScript... który jest skompilowany (i optymalizowany) do kodu pośredniego i jego działaniem zarządza ActionScript Virtual Machine... nic dziwnego, że jest to wydajniejsze rozwiązanie niż język skryptowy przekazywanie w tekście jak JavaScript. Flash ma dosyć dobre wsparcie dla sprzętu i wiele rzeczy robi na GPU, więc to wcale nie dziwi.

Na podobną wydajność jak we Flashu nie licz... dopiero jak W3C ustali standardowy bytecode i kod JS (lub innych języków) będzie mógł być kompilowany i optymalizowany już przed dostarczeniem do klienta, będziesz mógł myśleć o podobnej wydajności.

Fermi i SandyBridge

Nie rozumiem w którym miejscu bujam w obłokach z DirectX. Taka jest po prostu prawda, że OpenGL jest obecnie lepszym API (nie w kontekscie Linuksa, a ogólnie... zresztą z powodu braków możliwości DirectX, Carmack zdecydował wbrew wcześniejszym zapowiedziom, wydać Rage dla Windowsa w wersji OpenGL (chodziło o bindless graphics (za kilka lat może będą w DX) i sparse texture (jest w DX od 11.2... z tym, że w OpenGL te możliwości mają wszystkie karty od GeForce 400 i Radeon HD7000, a nie dopiero przyszłe karty))).

Co do linuksa i do tej pory była to nisza dla Indie i za mało było osób zainteresowanych tą platformą. Teraz się jednak to zmieniło za sprawą Steam gry AAA wychodzą na tą platformę, a najwięksi producenci gier (w tym twórcy Batlefield 4) widzą w tej platformie duże możliwości (za sprawą Steam, SteamOS i Steamboxów).

Demoscena na linuksie prawie nie istnieje. Po prostu nikomu nie chce się pisać narzędzi dla scenowców (nie istnieją tak dobre narzędzia do kompresji kodu, aby plik mieścił się w 1k/4k, przez co takie same objętościowo dema sa gorsze, bo mniej kodu można pomieścić). Po prostu Windows jest już okopaną twierdzą demoscenowców i tylko nagły upadek platformy by ich stamtąd ruszył. Swoją drogą mimo, że popełniłem kilka demek (większość dla Windowsa, bo w wersjach Linuksowych nie mogłem wycisnąć tak małego rozmiaru), to nie do końca rozumiem po co wrzuciłeś hobbystyczne, bezproduktywne programy do rozmowy.

Domeną gier linuksowych były i dalej są gry Indie... jednak pojawiają się już gry AAA, dużo gier AAA jest już zapowiedzianych dla Linuksa, a inne czekają na to, aż silniki zostaną przeportowane (nad portami Linuksowymi silników mocno pracuje Crytek, Epic).

"Wygląd nie liczy się tylko wtedy, kiedy wartość działania aplikacji przewyższa estetykę pracy."
Tak tylko estetyka jest porównywalna. Hator zdaje się mówić o tym, że ładniejszym wyglądem przeciągnie osoby, które oleją używane przez nich aplikacje z Windowsa (co jest bzdurą), a użytkowników internetu ładny wygląd okienek nie zainteresuje... bardziej to, że pod linuksem działa im wszystko wydajniej i nie potrzeba się bawić o antiwirusy (wygląd ma znaczenie jedynie wtedy, kiedy wszystkie inne możliwości się równoważą i wybierasz ładniejsze - ja jednak nie znam zastosowania w którym się równoważą).

No popatrz nie tylko pod Windowsem i Androidem, ale i pod moim Linuksem http://oi40.tinypic.com/2i263hx.jpg

Nie wiedzą, co to jest SMP, ale wiedzą, że chcą czegoś co działa wydajniej, a testy pokazują, że linux (nie muszą wiedzieć, że odpowiedzialna jest implementacja SMP czy schedulera, aby chcieć wyższej wydajności). Co to DirectX wiedzą chyba wszyscy... z silverlight wręcz przeciwnie - niszowe rozwiązanie z którego mało kto korzysta.
Pod Windowsem, że większość zwraca uwagę na zagrożenia ze strony wirusów bo są one powszechne. Pod linuksem praktycznie brak takich zagrożeń, więc mało kto zwraca na nie uwagę (i właśnie dlatego sporo osób korzystających z internetu głównie myśli lub przeszła na linuksa, aby te zagrożenia nie zawracały głowy).

Wygląd nie ma nic do rzeczy. Nie znam osoby, która zmieniłaby system dla wyglądu (i przyznasz, że to idiotyczny powód), znam za to sporo osób, które przeszło na Linuksa ze względu na możliwości, wydajność, brak wirusów czy po prostu większą elastyczność.

Odnośnie blendera to jest on na Windowsa, ale działa on tam zdecydowanie gorzej (nie ze względu na blendera, a na Windowsa i zastosowanie kompilatora Microsoftu zamiast GCC). Co do tych innych programów to akurat o lepsze ciężko (są inne, równorzędne, ale niekoniecznie lepsze), ale zastanawiam się o jakie Ci chodzi... Maya? Jest wersja Linuksowa i też popularna i wydajniejsza niż Windowsowa, Softimage? Tak samo... może Houdini, 3D-Coat, Mudbox, Modo... kurde jak na złość wszystkie mają wersję Linuksową i wszystkie na Linuksie działają lepiej.
Z ważnych programów, które nie mają wersji dla Linuksa to 3ds Max (od lat odchodzi rynek od tego programu i dużo większą popularnością cieszy się inny produkt tej firmy czyli Maya), LightWave 3D (przepisywany do Qt i planowana wersja Linuksowa) i Zbrash (tego trochę brakuje, ale jego konkurencja czyli 3D-Coat, Mudbox są). Może Ci chodziło o renderery? Eeee raczej nie, bo tu prędzej nie będzie wsparcia dla Windowsa niż Linuksa. Akurat branża 3D jest bardzo związana z Linuksem (myślisz, że czego używa Disney Pixar, Sony czy Dreamworks... Linux + Maya (Pixar z tego co pamiętam z Windowsów zrezygnował nawet w 2D i robi tak jak Adobe proponuje - Photoshop przez wine)).

Ogólnie to trafiłeś kulą w płot z blenderem, bo ani on gorszy od konkurencji, ani konkurencji pod Linuksem mu nie brakuje.

Na wygląd prawie nikt nie spogląda... co ładnie pokazywała przez lata dominacja XP (który obiektywnie rzecz biorąc był po prostu brzydki w stosunku do KDE/Gnome/MacOS), a obecnie pokazuje to Windows 8. To co ludzi przyciąga do Linuxa to wydajniejsze działanie (lepsza implementacja SMP, lepszy scheduler, lepsze zarządzanie pamięcią), brak wirusów (chociaż nie oszukujmy się jest to podyktowane właśnie tym, że Linux jest małopopularny)... czyli nie dość, że większe bezpieczeństwo to wyższa wydajność (cykle procesora nie są zżerane przez rezydujący antywirus) - ta zaleta jest szczególnie ważna i zauważają ją wszyscy użytkownicy internetu, którzy słyszeli o Linuksie. Osobiście nie znam osoby, która zmieniłaby system operacyjny na inny dla wyglądu (najmniej sensowny powód jaki można mieć).
Do Windowsa przyciąga DirectX (mimo, że obecnie jest on gorszy niż OpenGL to markę swoją ma) i ilość gier.
Nie do końca rozumiem co miałeś na myśli podając blendera, inkscape czy scribus... wszystkie te programy są w wersjach dla Windowsa i są tam popularne... jedyną rzeczą jaką tu widzę wspólną z tematem, jest to, że użytkownicy blendera czy inkscape potrafią zmienić system operacyjny ze względu na SMP i scheduler z jądra Linuksa (przez co programy działają kilkadziesiąt % wydajniej, a to w takich programach przyrost nie do przecenienia).

Niestety - testy własne (kiedyś pisałem w GTK (od 1.x), później w Wx (zmieniłem w czasach GTK2.x), a od przejścia Qt na LGPL w Qt) i robiłem własne benchmarki... jednak jest to łatwe do zauważenia w programach z UI w 2ch wersjach (przykładowo PCManFM po porcie do Qt zmniejszył zapotrzebowanie na cykle proceosra)... a spór pomiędzy twórcami GTK i Qt jest od lat taki sam "Qt jest wydajniejsze!" a druga strona "GTK potrzebuje mniej pamięci!" i nie było tu wielkich zmian według testów, które przeprowadzałem.

Qt ma dużo większe możliwości, jest łatwiejszy w użyciu, a wymaga mniejszej mocy obliczeniowej (dopiero KDELibs niezależne od Qt wymagają większej mocy).

GTK2 opiera się w całości o GObject i nie masz możliwości iść inną drogą niż obiektową.
"Kompilacja" metaobiektów ciężko nazwać kompilacją (prędzej preprocesorem tekstu), bo jest to po prostu przetwarzanie tekstu na tekst. Język C i C++ nie mają czegoś takiego jak sloty i sygnały, a pisanie tego ręcznie przez programistę nie jest zbyt wygodne, dlatego programista pisze w rozszerzonej składni C++ o nie, a moc przetwarza łatwy do pisania kod, na kod C++ (pisze kod slotów i sygnałów za programistę... i w gruncie rzeczy jest to kod C (wykorzystywana jest tylko biblioteka standardowa języka C, ale pakuje to do metod (nie wirtualnych, więc po kompilacji wygląda to po prostu jak zwykła funkcja języka C))) i piecze dwie pieczenie na jednym ogniu. Łatwy do pisania kod i wydajna dobra implementacja. GTK niestety robi coś zupełnie odwrotnego, bo sygnały z GObject są zaimplementowane strasznie powoli, a korzystanie z nich to przeżycie traumatyczne.