Nvidia zapowiada własne procesory oparte na architekturze ARM
Jeszcze nie ochłonelismy po informacji że Windows 8 oficjalnie zagości na architekturze ARM. Teraz to architektura zdobywa kolejnego wielkiego gracza – Nvidię która zapowiada produkować CPU w tej architekturze.
Obecnie oprócz gorących zapowiedzi szefowstwa wiadomo bardzo niewiele. Pewne jest to że Nvidia w pełni je zintegruje z chipsetami Tegra. Sam procesor będzie opierał się na licencji procesora Cortex™-A15 i ma trafić na różne gałęzie rynku od SoC po HPC, co niemal na pewno odbije się zwiększonym zestawem instrukcji.
Warto też wspomnieć że ujawnienie planów Nvidii zbiegło się z zapowiedziami głównych graczy na rynku x86. Sandy Bridge od Intela, Fusion APU od AMD które to mają wsparcie dla renderowania grafiki, w praktyce oznacza to możliwość przejęcia przez CPU większości zadań GPU i wyparcie mniej wydajnych kart graficznych przez procesory centralne.
Również Via najmniejszy gracz na rynku x86 zapowiedział nową serię energooszczędnych procesorów.
Albo uzywaja ARMv7-A (jak napisales w newsie) albo tworza "cala nowa" architekture, zdecyduj sie.
Piszesz jakby to bylo cos nowego u nVidii, a wyglada na to, ze jedynie przejda w Tegrach na rdzenie Cortex A15 (ktore i tak dalej sa ta sama architektura co A9) i stworza jakies dedykowane wersje ukladow do urzadzen innych niz multimedialne.
Cortex A15 mają wykorzystać w tegrach, w zapowiadanych prockach dla Desktop/Serwer nie wiadomo czego użyją (możliwe, ze sami zaprojektują CPU… ale równie dobrze mogą wykorzystać np. 8x A15 i do tego w SoC dowalić swoje GPU). Jednak nawet jak sami zaprojektują układ od zera to dalej będzie to ta sama architektura ARMv7 (podobnie jak amd robi x86 projektując wszystko sama).
News strasznie słabo napisany, bo te procesory nowe nie mają być zintegrowane z tegrą… zapowiedzieli nowe procki dla serwerów i desktopów na arm, a przy okazji powiedzieli, ze kupili licencje na A15 dla nowej serii tegry dla smartfonów i tabletów (te informacje się nie łączą – przynajmniej oficjalnie).
ale byly dodatkowe instrukcje jak MMX, obecnie w zintegrowanych CPU z GPU niema osobnej kosci jednego i drugiego w układzie, też niema podziału – wiec sytuacja jak w przypadku dodatkowych instr.
Nie jest ponieważ wszystkie MMX-y, SEE, 3DNow! i inne podobne wynalazki są rozszerzeniem listy rozkazów x86 i są ze sobą razem do kupy w jednym kawałku kodu, współdzieląc tą samą przestrzeń adresową.
Natomiast APU ma zupełnie osobny chip, z własnym niekompatybilnym kodem i własną przestrzenią adresową, który jest z punku widzenia CPU urządzeniem peryferyjnym co jest to diametralną różnicą i zupełnie innym podejściem do implementacji kodu (tak historycznie x87 tez było osobnym chipem, ale nie było nigdy traktowane jako urządzenie peryferyjne a instrukcje x86 i x87 współegzystowały razem).
O innej unifikacji póki co nie ma mowy, być może w przyszłości dojdzie do ujednolicenia przestrzeni adresowej i jakichś rozszerzeń listy rozkazów x86, które bezpośrednio będą sterować jednostkami GPU.
Póki co APU jest tą samą ideą, która przyświecała twórcom Cell-a, i będzie sprawiać zapewne podobne problemy implementacyjne na początku, ale dzięki OpenCL, raczej będą one dużo prostsze i szybsze do pokonania, niż w przypadku pierwowzoru, który notabene też już w/g IBM powinien być programowany z głównie z wykorzystaniem OpenCL-a.
GPU zintegrowane w CPU x86 (czy to intel sb, czy amd fusion), są bardzo słabe, a w dodatku kopią po tyłku x86, bo programiści są aż zmuszani do programowania w OpenCL (mimo, że te GPU w APU są słabe, to mają znacznie większą moc obliczeniową niż sam procek), więc zamiast SSE/AVX będzie się pisało w OpenCL, co prowadzi do tego, że procesory będzie się kupować jak najtańsze, GPU jak najszybsze, aby wydajność obliczeń była większa, a sama arch x86 straci znaczenie do tego stopnia, że program bez przeszkód będzie działał na arm/ppc/sparc i innych.
APU w x86 to sygnał dla programistów, że jeśli potrzebują wydajność trzeba olać CPU i pisać w OpenCL, a będzie działać wszędzie wydajnie (najwydajniej jak kupisz wydajne GPU).
PS od dawna nvidia starała się o taki rozwój sytuacji, żeby OpenCL był standardem i żeby x86 dzięki temu tracił na sile.
dodaj tylko że niektóre rodzaje algorytmów kładą gpu na łopatki jak pamiętam im więcej if tym gorzej dla gpu dla którego fakt przemnożenie ogromnych macierzy to nie problem ale co innego już tak.
Nie tyle kładą co większość procków nie działa – ale nie zapominaj, że np. GF580 w najgorszym wypadku będzie miał dalej 32 procki sprawne – czyli zamiast mocy prawie 1600 GFLOPS, będzie 100 GFLOPS co też nie jest słabym osiągnięciem w porównaniu do CPU – jednak aż tak pesymistyczny wypadek jest wprost nieprawdopodobny i wydajność powinna być średnio powyżej 800 GFLOPS.
Problemem nie są tu IF, a jednowątkowe programy (ale tu kto zdrowy na umyśle pisałby je w OpenCL? ;p)
krzabr
Zauważcie że obecnie do zadań specjalistycznych wykorzystuje się wyspecjalizowane układy, gdyby tak nie było lyrics semicond i chaologix nie prezentowały by nowych rodzajów procków :>
arme
Wręcz przeciwnie. Eliminując z rynku masowego nadmiernie wydajne układy eliminują sens stosowania opencl. Nie policzyłeś wydajności najnowszych cpu i nie bardzo wiesz o jakiej skali piszesz.
możesz napisać w którym miejscu eliminują "nadmiernie wydajne układy"? Te integry są zamiennikiem tanich kart, które miały podobną wydajność… tylko teraz takie bardzo wydajne rozszerzenia procesora (dużo wydajniejsze niż SSE/AVX z którymi musisz się bawić w ASM) są wszędzie (a jak nie to OpenCL też działa na x86, a intel implementuje za pomocą SSE4/AVX i nie trzeba nic pisać w asm, aby jednostki wektorowe procka się tym zajęły (po prostu użyć wektorowego typu jak float4), a kompilator zamieni to w zależności na jakim program/użytkownik będzie chciał obliczać, na kod optymalny dla platformy).
Wiem o jakiej skali piszę – niewiele ponad 100 GFLOPS miałyby 4x core Sandy Bridge z zegarem 3.8GHz (najszybszy SB w trybie TURBO) nawet jeśli ten program wykonywałby się na AVX (bo w tak pesymistycznym wypadku o jakim mowa w wypadku GF580 i 100GFLOPS AVX nie dałoby żadnego zysku wydajnościowego do CPU – w wypadku optymalnym wydajność byłaby 4x większa, ale wtedy na nVidii byłaby 16x większa ;p
krzabr
Czyli odpowiedni sprzętowy translator na instrukcje i jazda 😉
kocio
Tak a propos SoC Tegra 2 – jest zaprojektowany pod Androida, bo Microsoft ich olał:
"Nevertheless, Tegra 2 has been designed with Android in mind, not Windows. There are a couple of reasons for this. The main one is that Android has all the momentum in the market; but apart from that, Microsoft partnered with Qualcomm for Windows Phone 7, which runs on Snapdragon, shutting out NVIDIA at the initial launch. NVIDIA is a long-term Microsoft partner and the shift from Windows Mobile to Android has apparently cost NVIDIA a lot of time. The shift took place around 18 months ago, when NVIDIA saw how the market was moving. That shift “cost us a year to a year and a half of products to market”, I was told – a delay which must include changes at every level from hardware optimisation, to designing the kind of package that suits the devices Android vendors want to build, to building up knowledge of Android in order to market effectively to hardware vendors."
Nvidia się miota bo coraz bardziej jest eliminowana z masowej części x86, a wszystko wskazuje że z hpc również…
Niestety wątpię w sukces koncepcji nvidii i spodziewam się raczej, że arm osiądzie w swoim ogródku, tym bardziej że intell i amd nie próżnują. Myślę, że nv przegapiła swój moment i na razie jest na równi pochyłej, z drobnymi ostatnimi podrygami.
Mam rozumieć, że już niedługo będziemy kupować potwory – 10 różnych procesorów w jednym? I na co to komu – na pewno będą jakieś procesory leżeć odłogiem.
Nie.
Raczej bym obstawiał, że niedługo nie będziesz pamiętał co to nvidia.
W obliczu gwałtownych ruchów cen akcji (wręcz spekulacyjnych) po informacji o planach nv można wnioskować że… Nvidia panicznie szuka funduszy nie przebierając w środkach. Inne czasy, inne firmy ale to już było tylko o tych firmach już nikt nie pamięta…
Podejrzewam właśnie że będą różne procesory w jednym układzie (cpu,arm,gpu,probabilistic,lyrics), zresztą MS w tym celu prowadzi projekty barrelfish i helios.
Raczej dodatkowe specjalizowane jednostki wykonawcze w ramach rdzenia x86 i zestaw dodatkowych instrukcji. x86 jest bardzo elastyczne w tym względzie odkąd rozdzielono sposób przetwarzania od samych instrukcji (przejście na risc)
Tutaj można sobie więcej poczytać o tym chipie: http://www.anandtech.com/show/4098/nvidias-tegra-…
Co ciekawe, Tegra 2 niekoniecznie musi być najlepszą platformą do gier spośród dostępnych rozwiązań, ponieważ nie implementuje zestawu instrukcji NEON, które są zaimplementowane we wszystkich rdzeniach Cortex-A8 oraz w Cortex-A9 TI czyli serii OMAP4xxx, a które są bezkonkurencyjne względem zwykłego VFP.
Po części może to tłumaczyć dlaczego Sony wybrało Qualcomma, dla swojego wciąż jeszcze nieoficjalnego następcy PSP a nie Nvidię. Co do GPU to Adreno 205, choć w ogólnych testach wypada póki co gorzej od SGX 540 i ULP GeForce w syntetycznych bije na głowę tego pierwszego, co oznacza prawdopodobnie, że czysta wydajność shaderów Qualcomma jest dużo większa niż PowerVR, natomiast ten drugi nadrabia architekturą i inteligentną eliminacją zbędnych obliczeń.
Zapowiada się w każdym razie dość ostra rywalizacja, kto wie czy nie rośnie nam realny następca x86. Choć brzmi to póki co dość groteskowo, informacja, że Windows 8 będzie wspierał architekturę ARM może być pierwszą oznaką tego, że także Microsoft bierze taką ewentualność pod uwagę.
I tylko dziwi postawa AMD, który jakby nie było od dłuższego czasu bardziej liczy się z performance/watt niż czystym performance, wprowadza 9-cio watowe Fusion i… olewa rynek mobilny ciepłym moczem…
Może też coś po cichu knują, żeby zaatakować znienacka jak mają to w zwyczaju od pewnego czasu?
Nie o Tym chipie (bo tu mowa o nowych Tegra 3 i Desktopowych/Serwerowych wydaniach).
Tegra 2 jest w tej chwili najlepszą opcją do gier. Neon to fajna sprawa, ale ani programy (dalvik nie optymalizuje programów z użyciem NEON – a jeśli tak to automat może to robić maksymalnie tak jak kompilatory x86 dla SSE (czyli żałośnie, praktycznie bez zysków wydajności – tylko ręczna optymalizacja coś daje)). W grach procek ma najwięcej roboty z fizyką – na arm popularne są dwa silniki fizyki – Bullet (nie korzystający z Neon), oraz nVidia PhysX, który też raczej go nie wykorzystuje, bo nVidia by dała neona do swojego procka… więc mimo, że neon jest bardzo fajny to nic nie daje, ani w grach, ani w programach i jest tylko marnotrawstwem… dlatego nvidia wolała dodać drugie GPU dlatego wydajność jest dużo wyższa niż innych procków.
Co do wydajności GPU to Adreno 205 bardzo szybko przetwarza wierzchołki (szybciej niż SGX540, a porównywalnie z Tegra2), ale traci sporo w wydajności przy renderingu fragmentów gdzie jest sporo słabszy od SGX540 i Tegra2 (te są tu porównywalnie wydajne). Adreno 205 może powalczyć w benchmarkach na telefonach gdzie jest dużo więcej geometrii niż w grach, a małe rozdzielczości, ale w grach już nie może powalczyć, a na tabletach wydajność w większej rozdzielczości niż na telefonach będzie daleko za Tegra 2 i SGX540.
Ciekawie za to zapowiada się Adreno 220, ale ten będzie walczył z serią SGXMP i Tegra 3.
Nie słyszałem póki co o PhysX na ARM i szczerze mówiąc nie wiem gdzie mógłby być użyty, ale chętnie się dowiem, jeśli masz jakiś link. Póki co gry na smartfony są jeszcze bardzo ubogie w fizykę i osobiście nie spotkałem się z jakimś większym jej użyciem. Natomiast co do Bulleta to na dobrą sprawę kwestia kompilacji z odpowiednimi flagami i tyle. NDK r4b i r5 udostępniają taką możliwość dla targetu ARMv7A.
Co do kwesti wydajności Adreno 205 vs SGX 540 to tutaj są szegółowe syntetyczne wyniki: http://www.mobiletechworld.com/2010/12/18/opengl-…
Widać wyraźnie, że zarówno vertex jak i fragment shadery na Adreno działają zdecydowanie szybciej, natomiast siła SGX 540 tkwi w renderingu kafelkowym, którego podstawową cechą jest eliminacja zbędnych i nakładających się powierzchni (overdraw) na wczesnym etapie i liczenie fragment shaderów tylko na widocznych płaszczyznach. Potrafi to czasem zmniejszyć ilość obliczeń fragmentów nawet o 2/3 (zależy oczywiście od sceny)!
Sprawdzałem osobiście na moim Galaxy S i zabawa w proste GPGPU (dwa trójkąty rozciągnięte na całą szerokość ekranu, i liczenie na nich fragment shadera) wypada na SGX 540 bardzo blado. Ten GPU się do tego nie nadaje.
Co do PhysX to nVidia na początku 2009 informowała o pełnej implementacji PhysX na iPhone, a także pisze na stronie o firmie
[quote]PhysX – silnik graficzny naśladujący w czasie rzeczywistym dynamikę sił natury – takich jak grawitacja czy ruch – które działają na obiekty fizyczne. Jest on dostępny na wszystkich platformach dla graczy, włączając komputery PC, konsole, a nawet iPhone.[/quote] http://www.nvidia.pl/page/companyinfo.html
Ta implementacja PhysX jest z tego co wiem jest dostępna dla firm które mają komercyjną licencje na PhysX (widzą aktualne źródła) więc dla reszty jest dostępna w gotowych silnikach jak Unity, UE3 czy UDK i wiele gier na iPhone go wykorzystuje (proste gry – dema były już prawie 2 lata temu http://www.pcworld.pl/news/342504/Pierwsze.gry.zg… ).
Wygląda na to, że mają też wersję na Androida (główny target ich SoC), ze względu na pojawianie się gier na UE3 korzystającego z PhysX jak Dungeon Defenders.
Nie musi być jakieś większe użycie fizyki, żeby użyć physx/bullet – samo wykrywanie kolizji postaci ze ścianami warto zwalić na silnik, bo zawsze to mniej czasu na silnikologie, a więcej na gry ;p.
Tak można ustawić target na ARMv7A, ale daje to tyle co ustawienie flagi sse (dokładnie taki sam) na x86 (czyli tyle co nic – jak chcesz wykorzystać moc sse/neon, a nie tylko udawać to musisz zrobić to w ręcznie w kodzie)
Co do tego testu i wydajności Adreno 205 to dziwne wyniki tych testów syntetycznych – tak jak dziwne były te artefakty i znikające poly o których mowa na końcu… co mogło też się dziać w testach syntetycznych (przez co wyszły błędne wyniki).
Niestety nie mam Adreno 205 (mam 200 – strasznie wolny ;p), aby napisać własny benchmark i sprawdzić faktyczną jego wydajność (oraz poprawność obliczeń).
To prawda, że ręczny tuning jest niezastąpiony, ale nie jest tak jak piszesz, że kompilator sam z siebie nic nie może.
Tutaj przyjrzano się konkretnie GCC 4.4.1 na ARM http://ctuning.org/dissemination/grow10-03.pdf i wnioski w zakresie autowektoryzacji są dość ciekawe, otóż okazuje się, że głównym winowajcą słabej optymalizacji dla NEON-a jest zwykły bug a nie potencjalne możliwości kompilatora. Po jego poprawieniu były fragmenty, których wydajność zwiększyła się nawet o 171%!
pijaczek
Na małym idealnym dla optymalizacji kawałku kodu tak… ale na całości silnika zyski z tego to będzie w porywach kilka % (a zyski z drugiego rdzenia to prawie 100% więcej) – zyski są dokładnie takie jak na x86 (gcc optymalizuje i wektoryzuje kod niezależnie od platformy – dopiero na końcu zamienia to na instrukcje danego proca i optymalizacje w wektoryzacji powinny być tak samo mało widoczne). Dodatkowo nie należy zapominać, że ten test GCC był robiony na A8 – wydajność tych samych instrukcji bez optymalizacji wektorowych jest ponad 100% większa (ponad połowę mniej cykli potrzebują na wykonanie), więc Tegra 2 z 2x core A9, nie powinien mieć mniejszej wydajności niż A8 z NEON (chyba, że idealnie pasujący dla wektorów program, gdzie optymalizacje są pisane ręcznie w asm – praktycznie jednak Tegra 2 będzie po prostu sporo wydajniejszy).
wojtekm
Mylisz się. Nvidia zrezygnowała z NOEN-a tylko ze względu na redukcję powierzchni chipa o 30%, co wpływa też na energooszczędność. VFP w Cortex-A9 nie ma startu do NOEN-a, z tego względu, że większość operacji z wyjątkiem zaawansowanego dzielenia i pierwastowania jest wykonywanan w 1 cyklu procesora, podczas gdy VFP potrzebuje conajmniej 4 a w przypadku mnożenia 5 albo 8.
Stąd nawet niewektorowy kod zniennoprzecinkowy wykonuje się około 4 razy szybciej na instrukcjach NEON niż VFP.
Mówimy oczywiście o projekcie Cortex-A9 ARM, którego implementacją jest Tegra 2. Qualcomm np. ma własną implementację ARMv7A i tam VFP jest ok 4 razy szybsze zegar w zegar od wersji ARM (tak w każdym razie wynika z testu linpack sportowanego na Androida).
pijaczek
Tak – ze względu na redukcje powierzchni, energooszczędność które przeważyły, z niewielkimi.
Cortex A9 nie potrzebuje na dodanie 4 cyklów – potrzebuje jednego (tyle co NEON dla jednej liczby)… zdaje się, że mówisz o tym wykresie na anandtech (który przedstawia wartości dla takiej samej liczby działań czyli dla wektora z 4x elementami (i A9 potrzebuje 4 cykli, żeby je przetworzyć, a Neon jeden bo robi wszystkie na raz)).
wojtekm
Nie masz racji.
VFP zajmuje jeden cykl tylko jeśli jest "emulowane" w NEON MPE (czyli musi do być wersja Cortex-A9 z NEON-em): http://infocenter.arm.com/help/topic/com.arm.doc….
Zwykłe FP w Cortex-A9 bez NEON-a wygląda tak (sekcją 2.3 Instruction throughput and latency): http://infocenter.arm.com/help/topic/com.arm.doc….
Posiada conajmniej 4 cykle opóźnienia, choć to się nie przekłada w prosty sposób na 4-krotne mniejszą wydajność dzięki pipelininingowi w Cortex-A9.
Dr.Who
Bez NEON-a, LEON-a czy innego dobrodziejstwa – who cares? Liczy się wydajność.
handcrafted
Ja zawsze byłem fanem ATI, Nvidia jest o trudny okres doganiania
Dodaj komentarz