Autor Wątek: AMD Kaveri  (Przeczytany 4408 razy)

Offline moonshield

  • Użytkownik
    • ::devBlog

# Styczeń 16, 2014, 23:51:46
http://www.technewsworld.com/story/79788.html

Pewnie słyszeliście o nowym APU od AMD - Kaveri. Nie było by to może nic nadzwyczajnego gdyby nie to, że dość mocno "spłaszczyli" architekturę. Z tego co zrozumiałem z dostępnych materiałów prasowych, do GPU będzie taki sam dostęp jak do CPU, z resztą ciekawy cytat:
Cytuj
"In addition, AMD and the HSA Foundation partners are working on the software tools to allow GPU programming using standard software languages like C++ and Java," he noted.

Pytanie jest zatem takie: jaka jest przyszłość dla takich języków jak OpenCL? Fakt faktem (z tego co mi się wydaje), dostęp do GPU z poziomu C/C++ pewnie będzie utrudniony lub związany z  jakimś narzutem, ale coś kobieca intuicja mi mówi, że Intel pracuje już nad podobnym APU i możliwe, że za kilka lat będzie to już w miarę powszechne i prostsze w użyciu (powiedzmy sobie szczerze - filozofia OCL'a nie jest specjalnie przejrzysta na samym początku).
W OpenCL / CUDA istnieje takie pojęcie jak host, który (w większości przypadków) jest po stronie procka, zaś AMD pokazało sprzęt który w zasadzie tego hosta nie będzie miał tak jasno sprecyzowanego.

Co sądzicie?

moonshield

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline rastabaddon

  • Użytkownik

# Styczeń 17, 2014, 20:56:24
Poczekamy zobaczymy.
Sama idea ciekawa, ale bez szczegółowej dokumentacji ciężko się na ten temat wypowiedzieć.

Pod względem sprzętowym prawdopodobnie wzrośnie wydajność, pod względem wygody programowania
prawdopodobnie również może być ciekawie o ile nie wyjdzie z tego jakiś potworek ;-)

Tak jak pisałem na początku, zbyt wcześnie na wyciąganie opinia na ten temat.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 18, 2014, 11:58:00
Cytuj
dostęp do GPU z poziomu C/C++ pewnie będzie utrudniony lub związany z  jakimś narzutem
Zależy jak to rozwiążą. Bardzo fajnie zrobił to MS w swoim C++ AMP - masz kilka templatowych kontenerów, jedno dodatkowe słówko kluczowe przed pętlą "for" i już magicznie pętla "for" odpala się równolegle na GPU, a całe tworzenie kontekstu DirectX, zrobienie shadera i zasobów zalatwia już framework.

Cytuj
Co sądzicie?
Że matematyki nie przeskoczysz. Sama matematyka w kanale SIMD jest relatywnie prosta w porównaniu z resztą procesora (pobieranie i dekodowanie instrukcji, scheduling, sprawdzanie zależności, hyperthreading, itp, itd). Możesz więc mieć teraflopy ze wspólną logiką instrukcji (SIMD), albo dużo niezależnych procesorów i relatywnie mało teraflopów. Tyle że w tym pierwszym przypadku wszystkie kanały SIMD muszą wykonywać dokładnie ten sam kod, a skoki warunkowe robić na predykatach (upraszczając, SIMD napotykając if/else musi zwykle przejść zarówno blok "if" jak i blok "else", tylko odpowiednio wyłacząjąc kanały).

Tak więc nawet jeżeli zrobią kompilator zwykłego C++ czy Javy na to coś, to nie należy liczyć na performance taki, jak przy klasyczym GPU, tylko bardziej w okolicach 1/16 dla operacji nie związanych mocno z pamięcią i jeszcze mniej dla operacji na pamięci. Ale co im z tego wyjdzie, to zobaczymy. :)

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Styczeń 18, 2014, 14:09:09
Faktycznie rozwój GPU idzie w stronę uproszczenia jego programowania, przynajmniej jak chodzi o dostęp do pamięci. Ale osobiście uważam, że języki specjalizowane do obliczeń na GPU takie jak OpenCL nie znikną, tak jakie zniknęła dotychczas potrzeba pisania kodu natywnego i ręcznego zarządzania pamięcią, bo tylko tak można uzyskać maksymalną wydajność. Java ani JavaScript nie załatwią wszystkiego. Poza tym informatyka wcale nie rozwija się tak szybko, jak to się nieraz mówi. Współcześnie nadal przecież są używane języki wynalezione całe dekady temu (np. C, PHP). Tak więc OpenCL, GLSL itp. języków warto się uczyć i używać, w ciągu najbliższych lat raczej nie wyjdą z użycia.

Offline maqel

  • Użytkownik

# Luty 04, 2014, 22:52:05
W kontekście intela mogę dodać że robi niezłe karty na nowe procki i ponadto posiada niezły zapas technologi np: Xeon Phi.
Patrząc na transfer z/do pamięci nowej generacji Knights Landing który (jest)będzie dużym zagrożeniem dla CUDA. W pewnym sensie jest realizacją APU od intela.
We wczesnych latach 90 wszystko liczyło się na CPU, potem przyszła rewolucja multimedialna i powstało GPU.
Obserwując od pewnego czasu zmiany technologiczne na przykład rzadkie tekstury i tym podobne rozwiązania dążenie do integracji CPU i GPU jest nieuchronne. Następuje zmiana paradygmatu. Przypomina to przejście z procesorów CISC na RISC.
Od strony programowej wszyscy na tej zmianie skorzystają. Obecnie prowadzi się prace mające na celu bezbolesne przenoszenie kodu między różnymi urządzeniami a OpenCL np: GPU Ocelot.

AMD Kaveri na tle doliny krzemowej jest produktem dobrze wpasowującym się w mainstream.
A Mantle jest tylko preludium pełzających zmian od strony oprogramowania.

Referencja do wspomnianego sprzętu:
http://www.hpcwire.com/2013/11/23/intel-brings-knights-roundtable-sc13/

// Netrix: Zwracaj uwagę na błędy ortograficzne, to razi
//do Netrix: dzięki za przypomnienie.
« Ostatnia zmiana: Luty 06, 2014, 14:03:17 wysłana przez maqel »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Luty 04, 2014, 23:04:36
Cytuj
Obserwując od pewnego czasu zmiany tehnologiczne na przykład rzadkie tekstury i tym podobne rozwiązania dąrzenie do integracji CPU i GPU jest nieuchronne.
Niby skąd takie wnioski?

Moje są wręcz przeciwne, co zresztą Larrabee swego czasu udowodniło. CPU i GPU mają bardzo dużo wspólnego, ale ich zastosowanie wymusza dołożenie do obu pewnych specyficznych funkcjonalności, które się ze sobą nie skleją tak łatwo. W przypadku CPU jest to optymalizacja na procku i out-of-order execution, żeby wykonywać efektywnie kod pojedynczych wątków. W przypadku GPU to są różne fixed function, których wydajność jko układu bramek przebija wszystko, co można by zaprogramować (patrz: rasteryzacja i tesselacja).

Myślę, że CPU i GPU można porównać trafnie do wozu i sań. Niby podobne, bo ma budę, konia i woźnicę, ale jedyna różnica, która mogła by wydawać się detalem, całkowicie determinuje ich obszar zastosowania.

Cytuj
Przypomina to przejście z procesorów CISC na RISC.
To jest zmiana raczej kosmetyczna. I jedno i drugie ma etap dekodowania rozkazów, tyle że CISC ma je nieco bardziej skompresowane. Co później nie ma znaczenia, bo po dekodowaniu na sygnały sterujące każdy rozkaz z automatu staje się VLIWem. ;)

Offline maqel

  • Użytkownik

# Luty 05, 2014, 01:34:22
Co do tego fixed pipeline to się zgadzam. Jedną z najbardziej zasobo żernych operacji jest texturowania i tam ASIC jest nie do pobicia jak w każdym innym zastosowaniu. Furtka pojawiła się wraz z tesselacją i geometry shader. Jeśli twórcy GPU będą dalej chcieli zwiększać jakość obrazu w stronę fotorealizmu dojdą w końcu do poziomu mikro poligonów a tam zaczyna się obecny pipeline sypać. Wyjściem z impasu morze stać się programowalna rasteryzacja albo jakieś inne nieznane podejście do problemu. Wraz z uproszczeniem bądź wyeliminowaniem tych elementów różnica stanie się mniej widoczna.

 Karta graficzna to taki bardziej przerośnięty SIMD z  CPU i tu twoje uwagi są słuszne. Zapewnienie nieprzerwanego strumienia danych i rozkazów jest inne jak w obecnych CPU.
Podział zadań jest implementowany najprawdopodobniej w całości albo przynajmniej w części sprzętowo.
Jest jednak jedno ale.
Obecna architektura x86 jest nafaszerowana kolejnymi instrukcjami pod SIMD (SSE AVX...). W Xeon Phi masz SIMD'y aż 512 bitowe czyli zmieści się tam kilka wektorów FP32 po 4 elementy każdy.
Ta tendencja zbliża CPU w stronę GPU. Nie chodzi przecież o przetrwanie jednego albo drugiego gatunku tylko o powstanie hybrydy. To samo wieszczy NV na przyszłej generacji Maxwell, niby po co miałby im być układ ARM w GPU - oni od jakiegoś czasu nosili się z tym zamiarem a teraz klepią K1 z rdzeniami Keplera i ARM jak SoC do zastosowań mobilnych.
W praktyce K1 to przedpole do przyszłego rozwoju.

Wracając do Kaveri - podstawowy problem GPU to tzw. Memory Wall.
Integrując menadżer pamięci (niezbędne do wydajnego stronicowania pamięci) rykoszetem dostajesz rzadkie tekstury.
Ponadto bliskość geometryczna oznacza mniejsze opóźnienia w transferze danych (i bilans energetyczny) co jest bardzo pożądane w grafice.
Bo tak czy inaczej musisz nakarmić danymi tego potwora jakim jest GPU. Z drugiej strony producenci procesorów zaczęli integrować eDRAM z procesorem (już występuje w zwykłych integrach intela). Jak do tego dołożysz dostęp GPU do pamięci podręcznej robi się ciekawie.

Największy problem z tymi nowymi hybrydami to jak pisali przedmówcy jest po stronie algorytmów i języków i programistów.
Intel poradził sobie z tym na swój sposób we wspomnianym układzie. Maja tam normalny C/C++/x11 na 50 niezależnych rdzeni oraz MPI wewnątrz i na zewnątrz procesora, dodatkowo OpenCL 2.0 które obsługuje model wątków C11.Na intelu sam wybierasz podejście SIMD czy MIMD.

Możemy mieć doczynienie  ze stanem w którym GPU stanie się koprocesorem dla CPU.
Swoistym rozszerzeniem x86 o rozkazy SIMD. Jak  koprocesor x87  w przeszłości.


« Ostatnia zmiana: Luty 06, 2014, 14:02:48 wysłana przez maqel »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Luty 05, 2014, 02:05:35
Cytuj
Jedną z najbardziej zasobo żernych operacji jest texturowania i tam ASIC jest nie do pobićia jak w każdym innm zastosowaniu.
Samplowanie to też dobry przykład. Żaden procesor ogólnego zastosowania nie będzie w stanie tak efektywnie wykonać roboty samplera, na którą składa się dekompresja tekseli, 2- lub 3-liniowe filtrowanie, konwersja formatów i jeszcze trochę heurystyk.

Cytuj
Furtka pojawiła się wraz z tesselacją i geometry shader. Jesli twórcy GPU bedą dalej chcieli zwiększać jakość obrazu w strone fotorealizmu dojdą w końcu do poziomu mikro polignów a tam zaczyna się obecny pipeline sypać.
Jak dojdzie do mikropoligonów, to rasteryzacja nadal będzie jak najbardziej na miejscu. Tylko po prostu rasteryzatory będą musiały być optymalizowane pod taką sytuację. Nawet w takim przypadku wyliczenie pikseli, coverage maski i barycentryków, a także depth testy (z kompresją Z-bufora), scoreboardy i tym podobne, będą szybsze sprzętowo niż programowo, tym bardziej że jeszcze bardziej powiększy się presja na wydajne działanie tej części systemu. Jedyne co będzie wymagało gruntownego przemyślenia, to sposób działania Pixel Shaderów, bo trzeba będzie zrezygnować z quadów 2x2 i odpalać je pojedynczo - czyli żadnych łatwych tex2D, tylko wszędzie tex2Dgrad z analitycznymi pochodnymi.

Cytuj
Wyjściem z impasu morze stać się programowalna rasteryzacja albo jakieś inne nieznane podejście do problemu. Wraz z uproszczeniem bądź wyeliminowaniem tych elemetów różnica stanie się mniej widoczna.
Z nieznanym podejściem do problemu jest ten problem, że jest nieznane. ;) W dodatku nie wyeliminuje to rasteryzacji, bo nadal będą stare workloady do utrzymania, a także pojawiały się nowe pisane na starą modłę.

Cytuj
Ta tendencja zbliża CPU w strone GPU.
Zbliża, ale asymptotycznie nie łączy. Podstawową różnicą jest to, że CPU ma maksymalizować wydajność aplikacji o 1-10 wątkach wykonujących kompletnie różny kod, a GPU ma maksymalizować wydajność działania kilku różnych programów, ale odpalanych w milionach prawie kompletnie niezależnych egzemplarzy z komunikacją i spawnowaniem przez ASIC.

Fakt, że CPU czasem trafiają się proste i możliwe do mocnego zrównoleglenia zadania (np. przeliczenie kilku setek macierzy), oraz że GPU czasem ma zadania jednowątkowe (np. ostatnie etapy uśredniania czegokolwiek) nawet ich do siebie nie zbliża, tylko raczej pochyla we wzajemnym kierunku.

Cytuj
Z drugiej strony producenći procesorów zaczeli integrować eDRAM z procesorem
Podobnie cache miałeś już w czasach wręcz antycznych.

Offline maqel

  • Użytkownik

# Luty 05, 2014, 02:19:45
Spójżmy na to tak....

CPU ~= arytmetyka + obsługa przerwań + i/o
GPU ~= arytmetyka + rasteryzacja +  troche inne i/o

APU ~= arytmetyka + obsługa przerawń  + rasteryzacja + i/o

Co do prawa Amdahla to dużo wody w Wiśle upłynie nim coś się zmieni.

Tradycyjny deep test nie jest już tak oczywisty i jasny zwłaszcza z uwzględnieniem możliwości rysowania transparentnych obiektów.( oczywiście że w krzemie będzie szybszy )

Gdzie jest układ  Kaveri tak w kontekście tej asymptotyczności ?

Układy dedykowane są produkowane dla redukcji kosztów i poboru energi i było tak od początku świata.
(w odniesieniu do rozwiązań programowych na bardziej ogólne układu)

Marketing i prawa przyrody dążą do jak najlepszego "dopasowania"  do sytuacji.
Ogólna zaletą programowalności jest zdolność dopasowania - przerzucenia mocy z jednego obszaru zadań na drugi w razie potrzeby. Mając dużą ilość flopów morze pan w zależności od potrzeb obsługiwać rożne zadania. Oczywiście układ dedykowany rozwiąże je szybciej. Obecny rozwój informatyki a zwłaszcza gpu daje nam niekiedy przerost czystej mocy ale przez niedopasowanie staje się ona bezużyteczna. Pytanie czy pozostawienie części dedykowanych umożliwi dalszy rozwój. Czy dojdziemy do etapu w którym nie będzie on dalej możliwy bez ogólniejszych struktur. Odnoszę wrażenie że dzieje się to na naszych oczach.

Zasadniczo cała grafika przetwarzana w GPU to czysta matematyka łącznie z filtrowaniem
 anizotropowym i resztą a wyłączając I/O.
Można ją bezproblemowo zredukować w obecnym stanie do ogólnych operacji matematycznych i bardzo okrojonego zestawu instrukcji dedykowanych. Taką analogie miałem na myśli zestawiając CISC i RiSC.




« Ostatnia zmiana: Luty 06, 2014, 13:58:09 wysłana przez maqel »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Luty 05, 2014, 11:32:55
Cytuj
Spójżmy na to tak....

CPU ~= arytmetyka + obsługa przerwań + i/o
GPU ~= arytmetyka + rasteryzacja +  troche inne i/o

APU ~= arytmetyka + obsługa przerawń  + rasteryzacja + i/o
Strasznie to uprościłeś. W szczególności kompletnie olałeś możliwości CPU poza "obsługą przerwań".


Wygląda to raczej tak:

CPU ~= SISD superscalar out-of-order execution + lekki hyperthreading (~2x) + ...
GPU ~= in-order execution + szeroki SIMD + masywny hyperthreading + ...

Resztę zastąpiłem kropkami, bo są to ASIC które można w razie potrzeby przepinać między jednym a drugim (rasteryzacja, samplery, kontrolery przerwań, wirtualizacja pamięci itp), więc mają tutaj drugorzędne znaczenie.

Jednak to, co zostało, to dość mocno różne podejście do budowy procesorów. Możesz dopiąć moduł SIMD do CPU, ale nie uzyskasz takiej gęstości FLOPsów na mm^2 powierzchni silikonu jak w GPU, bo masz skomplikowany kontroler out-of-order optymalizujący data flow jednowątkowego kodu w locie. Podobnie możesz dopiąć ARMa do GPU, nawet Cortex-A15 z out-of-order execution, ale niewiele to zmieni, bo 95% FLOPSów będziesz miał wciąż podpiętych do relatywnie prymitywnych kontrolerów in-order o drastycznie szerokim SIMD.


Podsumowując, możesz miksować jednostki superskalarne out-of-order (dające masywny boost aplikacji o kilku niezależnych wątkach) z jednostkami in-order SIMD (dające masywny boost aplikacji o tysiącach wątków robiących to samo), ale musisz wybrać jaką powierzchnię krzemu przeznaczasz na jedno, a ją na drugie. To nie jest żadne zbliżenie CPU do GPU. To zwykłe posadzenie CPU i GPU na tym samym krzemie i decyzja, ile miejsca poświęcić jednemu i drugiemu. Ale to nie jest żadnym znakiem, że CPU i GPU stają się tym samym. Wręcz przeciwnie - to znak, że potrzebne są oba i że taki podział chyba jeszcze długo nie zaniknie.

Offline maqel

  • Użytkownik

# Luty 05, 2014, 14:17:04
Cytuj
Strasznie to uprościłeś. W szczególności kompletnie olałeś możliwości CPU poza "obsługą przerwań".
Co do uproszczenia to przyznaje że było ono zbyt mało precyzyjne.

Dobrze to opisuje następująca myśl.
Cytuj
Resztę zastąpiłem kropkami, bo są to ASIC które można w razie potrzeby przepinać między jednym a drugim (rasteryzacja, samplery, kontrolery przerwań, wirtualizacja pamięci itp), więc mają tutaj drugorzędne znaczenie.

Wyparowanie dyskretnych GPU jest moim zdaniem możliwe.
Skończymy wtedy z szybkimi jednostkami do zadań szeregowych i pewną ilością jednostek do zadań równoległych.
Nie zapominając o szczypcie ASIC.

Ciekawi mnie jak odniesiesz się do tego ?

http://www.youtube.com/watch?v=TxtZwW2Lf-w
http://www.nvidia.com/content/PDF/kepler/NVIDIA-Kepler-GK110-Architecture-Whitepaper.pdf

Hipotetycznie..
Jeśli musimy narysować klatkę z dużą ilością różnych shaderów.
I obraz jest na poziomie mikro poligonów wtedy GPU z kilkoma wielkimi blokami SIMD może się zakrztusić.
Bardziej dopasowane do tej sytuacji jest MIMD.

Czy jest tak że "in-order" staje się wąskim gardłem obecnej architektury?

Cytuj
To nie jest żadne zbliżenie CPU do GPU. To zwykłe posadzenie CPU i GPU na tym samym krzemie i decyzja, ile miejsca poświęcić jednemu i drugiemu. Ale to nie jest żadnym znakiem, że CPU i GPU stają się tym samym. Wręcz przeciwnie - to znak, że potrzebne są oba i że taki podział chyba jeszcze długo nie zaniknie.

Od strony programowej kluczem jest wspólne ISA i bezbolesny dostęp do obu(wspólnej) pamięci.
AMD dąży do tego stanu poprzez HSA. Wtedy możemy bezboleśnie przenieść języki w stylu C++11.
Zbliżenie geometryczne układów na jak najbliższa odległość zniweluje barierę pamięci. Co daje ciekawe perspektywy.
A przecież sposób widzenia sprzętu ma dla programisty (duże) praktyczne znaczenie.
W ten sposób rozmyje się wirtualna granica.

Na podsumowanie:
Tak - podział ta szybko nie zniknie.
GPU i CPU nie staną się tym samym. To raczej będzie rekombinacja możliwości.






« Ostatnia zmiana: Luty 06, 2014, 13:55:21 wysłana przez maqel »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Luty 05, 2014, 15:03:12
Cytuj
Wyparowanie dyskretnych GPU jest moim zdaniem możliwe.
A to jak najbardziej już się dzieje w efekcie poczynań Intela - masz CPU i GPU na jednym chipie, ze wspólnym cache i pamięcią.

Cytuj
Ciekawi mnie jak odnieśiesz się do tego ?

http://www.youtube.com/watch?v=TxtZwW2Lf-w
http://www.nvidia.com/content/PDF/kepler/NVIDIA-Kepler-GK110-Architecture-Whitepaper.pdf
Odniosę się cytując z drugiego linka: "Threads / Warp   -   32". Czyli 32-kanałowy SIMD. W momencie gdy różne wątki w tym samym warpie rozeją się w różne branche/funkcje, to performance spadnie 32x.

A zadania typowo kilkuwątkowe nadal będzie lepiej wykonywało CPU, bo Kepler ma in-order execution.

Cytuj
Hipotetycznie..
Jeśli musimy narysować klatkę z dużą ilością różnych shaderów.
I obraz jest na poziomie mikro poligonów wtedy GPU z kilkoma wielkimi blokami SIMD może się zaksztuśić.
Aż tyle różnych shaderów bym się nie spodziewał, bo wąskim gardłem staje się tutaj robienie contentu. W szczególności przy micropoligonach nie spodziewam się, żeby wszystkie poligony w obrębie piksela zaraz zaczęły korzystać z kompletnie różnych shaderów. Problemem może być jedynie przesadny branching, tudzież rozleniwienie prograistów i pójście w nieSIMDowalne rozwiązania (klasy, funkcje wirtualne, itp) - ale to już problem z programistami, że nie potrafią pisać optymalnie pod daną architekturę i oczekują nie wiadomo czego. :)

Cytuj
Czy jest tak że "in-order" staje się wąskim gardłem obecnej architektury?
Zależy co masz na myśli. Podstawowym celem jest wykonać kod jak najszybciej i te cele realizuje się zupełnie różnie w zależności od workloadów.

Na CPU jest mało wątków, więc potrzeba relatywnie mało arytmetyki, ale z tego samego powodu robi się superskalarne designy out-of-order, żeby te pojedyncze wątki śmigały jak trzeba.

Na GPU masz wątków pod dostatkiem i w dodatku wszystkie robią dosłownie kilka różnych rzeczy. Nie ma zupełnej potrzeby więc robienia procesora out-of-order ponieważ wystarczy zrobić prostszy w wykonaniu, za to szeroki hyperthreading na kilka/kilkanaście zestawów SIMD i nawet jak jeden warp 32xSIMD się zatnie, to zwykle znajdzie się jakiś, który zacięty nie jest. A za zaoszczędzoną powierzchnię i waty można dołożyć arytmetyki, cache, czy rejestrów.

Cytuj
Od strony programowej kluczem jest wspólne ISA i bezbolesny dostęp do obu(wspólnej) pamięci.
Ze wspólnym ISA jest parę problemów - w szczególności w niektórych przypadkach wykonywane są operacje "poziome" na kanałach SIMD. W procesorze SISD oczywiście taki rozkaz nie zadziała, bo kanał jest tylko jeden.

Cytuj
Wtedy morzemy bezboleśnie przenieść języki w stylu C++11.
Wtedy dopiero zaczną się boleści. :)

Polecam doczytać jak zachowuje się SIMD w przypadku divergent control flow. A spodziewam się przy C++11 rzeszy wesołych programistów, którzy nie będą w ogóle się zastanawiali co się dzieje pod spodem, wesoło używali wskaźników, metod i branchingu i mocno dziwili, czemu wydajność GPU spadła na łeb na szyję.

Offline maqel

  • Użytkownik

# Luty 05, 2014, 18:35:09
Cytuj
Wtedy dopiero zaczną się boleści. :)
Wspólne ISA wprowadza ułatwienie tylko dla kompilatorów.

Cytuj
Polecam doczytać jak zachowuje się SIMD w przypadku divergent control flow.
Pisanie kodu powodującego dekoherencje wątków na SIMD w przypadku gdy istnieje
możliwość napisanie go inaczej jest problemem nierozgarniętych programistów.
Rozgałęzienia kodu nie są dobre nawet dla CPU. Długość potoku i cała optymalizacja x86 nie służą za dobrze rozgałęzieniom. Ale to jest temat na osobną dyskusję i nie zamierzam go tutaj rozwijać.
Należałoby tu wspomnieć o sprawie śledzenia promieni itp. która ostatnio przewija się w wielu tematach dotyczących GPU.
Ale to również temat rzeka.

Cytuj
Na GPU masz wątków pod dostatkiem i w dodatku wszystkie robią dosłownie kilka różnych rzeczy. Nie ma zupełnej potrzeby więc robienia procesora out-of-order ponieważ wystarczy zrobić prostszy w wykonaniu, za to szeroki hyperthreading na kilka/kilkanaście zestawów SIMD i nawet jak jeden warp 32xSIMD się zatnie, to zwykle znajdzie się jakiś, który zacięty nie jest. A za zaoszczędzoną powierzchnię i waty można dołożyć arytmetyki, cache, czy rejestrów.

Cały problem GPU to zapewnienie ciągłego przepływu danych i instrukcji.

Wzmiankę o Hyper-Q i dynamicznej równoległości podałem żeby ukazać potrzeb większego uMIMD'owienia GPU.
Pisałeś o możliwości wykonywania konkurencyjnego wieli kerneli na bloku SIMD. Jak pisałeś out of order nie jest tym czego dokładnie potrzebujemy. Sama konkurencyjność wprowadza coś podobnego ale innego.  W takim układzie znaczenia nabiera sposób zarzadzania tą całą maszynerią. Dodanie zintegrowanego rdzenia(rdzeni) wyspecjalizowanego w zdaniach szeregowych pozwala wydajnie zarządzać kolejkami instrukcji dla zintegrowanej matrycy SIMD.

Zobaczymy co przyniesie nam Maxwell oraz Project Denver i w jaką stronę ta cała historia integracji pójdzie.


Ale się nam wątek rozwlekł..... :D
« Ostatnia zmiana: Luty 06, 2014, 13:53:59 wysłana przez maqel »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Luty 05, 2014, 22:41:11
Cytuj
Wspólne ISA wprowadza ułatwienie tylko dla kompilatorów.
I to niewielkie, bo tylko na etapie code generatora.

Cytuj
Rozgałezienia kodu nie są dobre nawet dla CPU. Długość potoku i cała optymalizacja x86 nie słurzą za dobrze rozgałęzieniom.
Tak, ale CPU o niebo lepiej sobie radzi przez predykcję i spekulatywne wykonywanie kodu, więc jest to dla niego jedynie niewielką bolączką. W przypadku SIMD pozostaje tylko maskowanie i do 32x wolniejsze wykonanie, czyli w ogólności tragedia.

Cytuj
Wzmianke o Hyper-Q i dynamicznej równoległości podałem żeby ukazać potszebe większego uMIMD'owienia GPU.
GPU są jak najbardziej uMIMDowione. Tyle że na jedno I przypadają 32 D, żeby oszczędzić na sterowaniu.

Cytuj
W takim układzie znaczenia nabiera sposób zarzadzania tą całą maszynerią. Dodanie zintegrowanego rdzenia(rdzeni) wsypecjalizaowanego w zadniach szeregowych pozwala wydajnie zarządzać kolejkami instrukcji dla zintegrowanej matrycy SIMD.
Nie pozwala. Do wydajnego hyperthreadowania układów SIMD potrzebujesz ASIC, i to bardzo. Żeby sprawdzić, które instrukcje na wyjściach kolejek można w tej chwili odpalić musisz śledzić scoreboardy dependencji rejestrów i pewnie jeszcze trochę dodatkowych rzeczy, a następnie wybrać jedną z gotowych instrukcji. Co więcej, musisz to robić z prędkością jednej instrukcji na cykl (albo kilku, jeżeli architektura jest superskalarna - czego SIMD przecież nie wyklucza). Taki stan rzeczy po prostu implikuje ASIC.


btw. Polecam zaopatrzyć się w przeglądarkę z podkreślaniem błędów. Jest to nie tylko możliwość, ale również bardzo realna potrzeba. ;)

Offline maqel

  • Użytkownik

# Luty 06, 2014, 12:27:15
Nie maiłem na myśli HT tylko zarządzanie na nieco wyższym poziomie.

Cytuj
GPU są jak najbardziej uMIMDowione. Tyle że na jedno I przypadają 32 D, żeby oszczędzić na sterowaniu.
Zdaje sobie sprawę że GPU w obecnym stanie to jeden z najbardziej skomplikowanych kawałków krzemu.
Co do większego udziału MIMD w GPU mam inne zdanie. Nie chodzi mi przy tym o pozbycie się SIMD.
Słowo klucz to rekombinacja możliwości.

Myślę że każdy kto zaglądnie na ten wątek odniesie jakąś korzyść czytając posty.
Proponuje zawiesić naszą polemikę do czasu pojawienia się odpowiedzi na Kaveri od konkurencji.
« Ostatnia zmiana: Luty 06, 2014, 13:48:06 wysłana przez maqel »