Jeśli chodzi o ścisłość to nie około 2.45 mld tranzystorów, a prawie 2.6 mld (2.154 * 24 / 20 = 2.5848), a IMO nie jest wykluczone, że jak w wypadku Barts będzie tak na prawdę więcej SIMD tylko jeśli ma osiągać wydajność zbliżoną do tego co mówią to myślę, że może mieć nawet więcej SIMD.


Wywalenie 4 alu ofc będą mniej niż 5 (ale przy tej samej ilości ALU będzie potrzeba więcej tranzystorów na więcej elementów zawierających ALU (bo jeden element będzie zawierał ich mniej i trzeba będzie większą ilość dać))

Ale RBE czy też kontroler pamięci nie wchodzą w skład bloku SIMD. W skład jednego SIMD wchodzi 16SPU i 4TMU, a RBE jest tu oddzielną bajką. Ja wyliczyłem to biorąc pod uwagę to, że cypress i barts różnią się w zasadzie głównie ilością SIMD w liczbie 6, co stanowiło 450Mln tranzystorów. na 4SIMD ~300mln.

@skoti - niby tak, ale chyba użycie w 5D vliw wszystkich 5 jednostek naraz było praktycznie nieosiągalne w grach, a w gpgpu to chyba jedynie collatz. ALU.Trans nie brał wcale udziału przy FP64. Zatem AMD poszło po rozum do głowy i stworzyło wygodniejszą i efektywniejszą architekturę. Nie dość że podwojono przetwarzanie bardziej zaawansowanych instrukcji (trans/sfu) to rzeczywista moc (obliczeniowa) dostępna dla typowych aplikacji wcale nie powinna spaść (zbyt wiele). Jak dla mnie konkretny progres
EDIT - może inaczej. Peak GFLOPS spadnie, ale dla takiej samej wartości szczytowej nowa architektura osiągnie więcej użytecznej mocy niż stara.

Ale nie jest tez tak ze te 4 beda rownie dobre jak stare 5. Owszem to DOBRA zmiana - i tu nie dyskutuje i ogolnym rozrachunku oplacalna, ale nie jest to proste +25% wydajnosci.

Kolejny dla mnie argument to kwestia marketingowa. Jakby Cayman 'miazdzyl' GTXa to by go juz wypuscili. Niewazne ze uzysk slaby, ze nie ma fizycznie kart. Paredziesiat by sie znalazlo - w sam raz zeby dac redakcjom. Troche inaczej brzmi 'nie kupujcie Nvidii, czekajcie na nasz top produkt ktory wedlug nas bedzie super', niz '13 grudnia wypuszczamy produkt ktory juz teraz NIEZALEZNE testy klasyfikuja znacznie wyzej'. Jak sie nie wyrobili na sezon gwiazdkowy, to chociaz mogliby troche klientow zachowac.

Ale coz, moze nie mam racji, poczekamy zobaczymy. Jak Cayman bedzie taki super to sie przesiade (nie czuje przywiazania do marek). Jak na razie wyglada dla mnie ze nvidia jest nieco gora na topie (bo tez im wyzej tym wazniejszy robi sie taki np Physx czy 3dvision - szczerze mowiac na gtx SLI czy xfire 6970 wszystko i tak bedzie smigalo, wiec wazne staja sie dodatki ktore na nizszym poziomie sprzetu sa malo istotne).

A co do Antillesa czy 5970. Duzo juz bylo powiedziane na temat dual GPU etc. Nie bede tego powtarzal. Ale z mojego punktu widzenia np gtx miazdzy 5970 , i to miazdzy absolutnie. Czemu? Bo mam 580 SLI, a 5970 owszem moglbym dac w crossfire, ale 4GPU to juz nawet nie ma co mowic o skalowaniu sie. Moze i 5970>GTX580, ale 2x5970 przegrywa o kilometr z 2xGTX.

jeden i drugi tak samo łatwo zaprojektować , zalezy co się koło czego znajdzie .

AI korzysta w 100% tach z wiedzy AMD na ten temat i zdolności pakowania .

nvidia jest z tym do tyłu , ale z drugiej strony Nvidia to 2x bardziej zaawansowany chip , więc o czym tu dyskutować .

Dlaczego niby nie było osiągalne? Jak najbardziej było to osiągalne. Co do tego, że nie brał udziału w FP64 to kogo to obchodzi? FP64 mało kto wykorzysta i mało który program go potrzebuje/używa... do tego stopnia, że AMD wycięło przecież FP64 z części swoich kart całkowicie (czego jednak nie jestem 'fanem".
Zgadzam się, że przyniesie to korzyść, ale nic za darmo (koszty to tranzystory dodatkowe).


3D Vision nie jest już atutem, bo sterowniki AMD też obsługują już stereoskopię i trzeba po prostu kupić jak w wypadku 3d Vision monitor 120Hz i okulary. Co do PhysX to tak może być on kartą przetargową jeśli w grze w którą zamierza klient zagrać jest akceleracja fizyki, tym bardziej, że nie ma szans na szybkie wydanie Bullet w wersji OpenCL (na marzec ma być dopiero wersja poglądowa), a gry to myślę go wykorzystujące to myślę, że nie wcześniej niż rok po tym (czyli Q2 2012)... a i tak w Bullet wydajniejsze powinny być karty nVidii którym bardzo pasują takie obliczenia... więc tu jak najbardziej nVidia ma plus, a z wyjściem gier Bullet powinna mieć jeszcze większego (karty nVidii w testach 1:1 (fizyka włączona na karcie niezależnie od firmy) po prostu będą miały przewagę wydajności).

Jeśli nie skalarne to 4x1 albo 4x4 zatem nigdzie ta piąta jednostka nie miała większego wykorzystania w tym samym czasie co pozostałe 4.

Jeśli w kodzie masz np. przemnożenie wektora 4x1 przez coś i później niezależne mnożenie innej zmiennej której wartość jest niezależna od tego mnożenia to może na raz mnożyć we wszystkich pięciu rdzeniach (to samo z każdymi innymi działaniami, a takie sytuacje w shaderach to norma, a to czy wykorzystywane są zależy od kompilatora i optymalizacji przez niego robionych w sterowniku).

//edit:
dodam, że jeśli ati nie robiła optymalizacji to wkładanie tam tego skalarnego procka to byłby skrajny idiotyzm powtarzany przez lata (a o to ich nie podejrzewam), bo tylko marnowali kasę, prąd i ciepło, a wydajność byłaby taka jak by nie było go (bo jak skalarny nie działa razem z wektorowymi to równie dobrze można skalarne obliczenia robić jakby były wektorem (S, 0, 0, 0) gdzie S to skalar).

Skoro, wg ciebie, wykorzystanie pięciodrożnej jednostki to pikuś to czemu tak ciężko zbliżyć się do teoretycznej wydajności FLOPS? Radeony mają 2x wyższą wydajność teoretyczną, a jakoś to się nie przekłada w całości na wydajność.

Odpowiedź jest prosta: nigdy nie optymalizowałeś kodu pod jednostki superskalarne, a potem pleciesz bzdury.


'dodam, że jeśli ati nie robiła optymalizacji to wkładanie tam tego skalarnego procka to byłby skrajny idiotyzm powtarzany przez lata (a o to ich nie podejrzewam), bo tylko marnowali kasę, prąd i ciepło, a wydajność byłaby taka jak by nie było go (bo jak skalarny nie działa razem z wektorowymi to równie dobrze można skalarne obliczenia robić jakby były wektorem (S, 0, 0, 0) gdzie S to skalar).'

Procesory x86 też są superskalarne i sporo jednostek przez większość czasu się opier*ala. Czy to też nazwiesz skrajną głupotą?

Ale, przecież banalnie łatwo osiągnąć teoretyczną wydajność (w OpenCL programik miałby ~4 linie kodu), problem nie jest na tym poziomie, a SIMD, a w wypadku nowej arch przyspieszy wydajność w obliczeniach.


Procesory wykonują zazwyczaj zadania które się bardzo słabo skalują (w przeciwieństwie do grafiki (shaderów) czy obliczeń które są przenoszone na GPGPU). Do tego nie wykorzystywanie pełnej mocy procesorów (i ich SIMD (SSE i inne rozszerzenia)) często nie są wykorzystywane ze względu na kompatybilność (co z tego, że ktoś wykorzysta SSE4.1 jak program nie zadziała nawet na Core 2 Duo 65nm które dalej jest popularne). Do tego na takie optymalizacje mieli co najmniej cztery lata - w praktyce dużo więcej bo podobne rozwiązanie było już w x1k, jak nie wcześniej (a bez nich to dodawanie jednostki skalarnej to głupota, bo to, żaden wzrost wydajności, a jedynie wzrost kosztów, zarówno po stronie klienta, jak i ati).

No i w krótkich głupawych programikach Radeony pokazują swoją wyższość. Ale mi chodziło o coś co wymaga przynajmniej odrobiny myślenia. Prawda jest taka, że na Radeony optymalizuje się dużo trudniej, ale jeśli włoży się odpowiednio dużo wysiłku intelektualnego i ma się talent do optymalizacji pod VLIW to GeForce chowa się w krzakach.

Wadą AMD jest to, że udostępnia bardzo mało tutoriali o tym jak optymalizować programy pod ich architekturę (tzn Radeony). nVidia ma całe morze przykładów, technik, etc a AMD oczekuje chyba, że programiści będą ich wielbić i dla nich wielkodusznie optymalizować algorytmy za darmo.

Nie prawda - nie wszystko da się zrobić liniowo (w większości zastosowań nie ma takiej możliwości, a VLIW nie ma tu nic do gadania. Wadą kart AMD jest zastosowana architektura i wiele rdzeni w SIMD, przez co wystarczy, że jest mała instrukcja warunkowa, a większość rdzeni robi pusty przebieg (i tu nie jest ważne, czy w SIMD jest 80 procków po jednym rdzeniu, czy 16 procków po 5 rdzeni). W większości zastosowań jakbyś się nie wysilał, to Radeon będzie się chował po krzakach (w Caymanie będzie poprawa bo SIMD będzie więcej i będą miały po mniej procków (64 zamiast 80), ale to i tak daleko do nVidii).


Oj nie przesadzałbym, bo Amd ostro pracuje tu i publikuje dużo filmików i papierków na temat OpenCL i ich kart (a nawet wzorem papierków nVidii 'jak portować z Cuda do OpenCL", jak również rozwija narzędzia przydatne programistom... więc nie jest tak jak mówisz (daleko do wsparcia CUDA przez nVidię, ale nie tak znowu daleko od wsparcia dla OpenCL przez nVidię...) i nie tu jest problem, lecz w architekturze karty.

Dokładnie. Dodając do tego fakt że flow jest ustalany na 4 cykle, mamy 80*4=320. Tak więc na poziomie SIMT mamy architekturę 320d (AMD) vs 32d (NVidia).

Wielkość SIMDa ma niewielkie znaczenie jeśli chodzi o instrukcje warunkowe. Bardziej chodzi o strukturę pamięci podręcznej. Jakiekolwiek większe instrukcje warunkowe powodują, że zalety GPU nad CPU zanikają. Chyba tylko skończony idiota wykonywałby na GPU kod, który korzysta tylko z jednej jednostki z SIMDa.

Filmików i paierków od AMD jest jak na lekarstwo. Robię magisterkę z wykorzystaniem OpenCLa i chyba więcej się nauczę o programowaniu pod GeForcy mimo że mam Radeona. OpenCL'owy RadixSort z Stream SDK od AMD to po prostu kpina w żywe oczy. Wykonuje się szybciej na CPU niż na GPU, nawet korzystając z ich tego nieudolnego kompilatora. Przez to muszę się uczyć o sortowaniu pod GeForce, a potem jakoś tą wiedzę przenieść na Radeona i zoptymalizować pod te jego VLIWy.

Megabyte:
GF110 ma 16 SIMDów po 32 jednostki w SIMDzie.
Cypress ma 20 SIMDów po 16 5-drożnych jednostek w SIMDzie.

Oj jak najbardziej wielkość SIMD ma znaczenie przy instrukcjach sterujących (if to tylko przykład, ale mowa o wszystkich instrukcjach sterujących gdzie są wykonywane skoki z pętlami na czele). Idiotą nie jest ktoś kto nie wie z ilu jednostek w SIMD będzie można korzystać, bo to jest sterowane przez dane wejściowe - dajmy tu przykład wykrywania kolizji - podczas projektowania silnika nie wiesz czy, gdzie i jakie dane dostaniesz do obliczeń i to jak będzie działać będzie wynikać z danych wejściowych, np. masz kilka tysięcy ruchomych obiektów i masz ich wektory przesunięcia, to po prostu musisz sprawdzić czy przecina się z czymś i jeśli tak to nastąpiła kolizja i musisz coś zrobić - nie wiesz dla ilu nastąpi kolizja i jak się ułożą, dlatego czasami wydajność będzie super, czasami do d... bo wszystkie rdzenie w SIMD, będą robić coś co potrzebne jest jednemu (ofc stosuje w tym przykładzie uproszczenie bo w takich zadaniach dla przyspieszenia obliczeń (czy nastąpiła kolizja stosuje się struktur drzew jak QBVH, które jeszcze bardziej rozgałęziają kod)). Wielkość SIMD ma znaczenie, bo im większy tym więcej się może marnować jednostek.



Z dokumentacji nVidii do samego OpenCL przydatne są tylko 'OpenCL Programming Guide' i 'OpenCL Best Practices Guide' ('ATI Stream SDK OpenCL Programming Guide' zajmuje ~40% więcej stron, a o samej optymalizacji jest 50 stron), wiedza w formie Wideo nie wiele ustępuje, bo nVidia niewiele filmików dotyczących OpenCL ma na swoich stronach, a AMD ma całą serię treningu wideo, filmiki dotyczące narzędzi do OpenCL, oraz strony z listami papierków i tutoriali nie tylko pochodzących od AMD, ale też innych... zdecydowanie nie jest to mało wiedzy... ale odnoszę wrażenie, że nie o wiedzę tu chodzi, a gotowe przykłady... tu masz rację nVidia ma ich więcej.

@skoti - nie wiem czy słusznie, ale zasugerowałem się
4.7.8 z R700 ISA

Piszesz oczywistą rzecz a to znaczy że nie zrozumiałeś co napisałem. Ok, postaram się to napisać prościej:
Cypress ma 20 SIMDów i każdy z nich ma jeden scheduler/dispatcher. Żeby jednak uprościć jego budowę scheduler grupuje wątki w grupy po 64. Cytuje: 'Wavefronts and groups are two concepts relating to compute kernels that provide
data-parallel granularity. Wavefronts execute N number of work-items in parallel,
where N is specific to the hardware chip (for the ATI Radeon HD 5870 series, it
is 64). A single instruction is executed over all work-items in a wavefront in
parallel. It is the lowest level that flow control can affect. This means that if two
work-items inside of a wavefront go divergent paths of flow control, all work-items
in the wavefront go to both paths of flow control.' zródło http://developer.amd.com/gpu/ATIStreamSDK/...ming_Guide.pdf. Żeby było jasne to 64 odnosi się do wątków czyli do całych SP a nie SPu. Tak więc 64x5d to 320d. Lub tłumacząc inaczej. Jeśli masz taki kod:
if (id_watku < 32)
{ kod1 }
else
{ kod2 }
To SIMD Engine najpierw zapuści pierwszą instrukcję z kod1 na pierwszych 16 wątkach (bo tyle mamy jednostek w SIMD). Później zapuści kolejną grupę 16 wątków. Teraz wydawać by się mogło że powinniśmy przejść do kolejnej instrukcji ale w efekcie SIMD Engine zawiesi się na dwa cykle wykonując wątki od 33 do 64 mimo że one nic nie robią.

U NVidii jak na razie zawsze jest to 32x1d (G80,GT200,GF100,GF104,GF110).

Podsumowując szerokość wektora != ilość SP w SIMD Engine/multiprocesorze.

Czy instrukcje warunkowe są przerabiane przez procesorki strumieniowe? czy 'ich zarządce' - thread dispach procesor lub coś podobnego, lub nawet samo cpu (pytam bo nie wiem moge jedynie zgadywać?) wydawało mi się że to zadanie nie jest wykonywane na prostych jednostkach wykonawczych, podobnie jak przewidywanie skoków, pobrań wyprzedzających itd itp. i jest bardzo ograniczone lub wcale nie istnieje w gpu, a jest sprytnie ukryte przez kompilator który tak uklada kolejność że proste instrukcje są paczkami wysyłane do jednostek. (dlatego w tym wypadku nieważne ile jest jednostek ważne ile zarządców)

Dobrze napisany kod powinien tego unikać(instrukcji warunkowych) szczególnie jesli operuje się na gpu(chociaż w cpu również)..wiem że to jest możliwe napisać ten sam algorytm inaczej, bo sam na takie przypadki natrafiłem - sortowanie np. w algorytmie bwt jest kluczowe
Napewno quicksort na karcie graficznej musiałoby zmienić nazwe na veryslowsort - ciekawy motyw na magisterke.

-> http://www.gpgpu.org/forums/viewtopic.php?t=4529z tego co wygooglowałem wyciągam wniosek na szybko(jako laik) że w przypadku tam opisywanym nie ważne ile jednostek, ważne ile bloków.

A jesli chodzi o architekture 4D zamiast 4+1, trzeba by być programistą DX,OGL żeby wiedzieć jakie obliczenia są najczęściej potrzebne, widocznie byl jakiś powód do obrania takiej a nie innej architektury gdzie ta jedna mała jednostka okazała się potrzebna, a teraz z punktu widzenia opłacalności(powierzhni, energii i wykorzystania przy innych proporcjach jednostek teksturujących, opóźnieniach pamięci itd.) przestała być sensowna.

Widziałem niedawno opracowanie nt. optymalnej długości potoku wykonawczego w cpu(temat sprzed kilku lat skupiajacy się na pentium 4) gały mi wyszły jak to matematycznie zostało wyliczone, jak wyliczono optymalne jej rozmiary na podstawie różych czynników takich jak opóźnienia dostępu do pamięci itd. trzeba mieć naprawde głowe na karku i metody statystyczne w małm paluszku. My możemy najwyżej gdybać i widzimisieć na oko.

Megabyte - dobrze wyjaśnione!
Chociaż sie na tym nie znam kompletnie i improwizuje..intuicja nie zawodzi

@Stan - jest branch unit obok ALU. Mnie nawet nie chodziło o równoczesne wykonywanie instrukcji na wszystkich 5 jednostkach (jako możliwości sprzętowej), a o to jak często tak się dzieje. Do tej pory myślałem, że 'read slots' jest mniej niż jednostek i nie zawsze jest możliwość w tym samym cyklu zapełnienia obliczeniami i scalar i vector units.