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

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.

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.

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).

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.

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.

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).

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ą?

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).

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.

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).

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ć .

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.

@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 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.

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ć))

@skoti - cypress 5ALU/SP, 20SIMD*80ALU/16SP, cayman prawdopodobnie 24SIMD*64ALU/16SP. Rozumiem, że trans. alu które to o 1 będzie więcej na SP to niby dodatkowe tranzystory, ale przez wywalenie piątego ALU wiele się nie zmienia, a myślę że 2ALU+2ALU trans mogą kosztować mniej niż 4ALU+1ALU trans.

ale przecież przybliżyłem to liczbowo. Układ z 24SIMD w starej architekturze miał by około 2,45Mld tranzystorów. A skoro kajman ma mieć 24SIMD w nowej architekturze to wyniknąć może jedynie z tego to, że taki układ będzie miał mniej tranzystorów, jednak nie będzie to taka ilość jak w przypadku cypressa. I jak widać w tym porównaniu nie ma żadnych dodatkowych SIMD, tylko mniej shaderów.

Ale ja nie mówiłem o SIMD, a o procesorach, ale skoro już powiedziałeś o SIMD to jak dobrze zauważyłeś jest w nich mniej o 1/5 rdzeni - przez co przy takiej samej ilości rdzeni w karcie muszą być dodatkowe SIMD (które kosztują dodatkowe tranzystory), a w nim dodatkowe SM (które też swoje tranzystory zabierają), dlatego właśnie taki przedział jak podałem przy podobnej ilości rdzeni... a ma być bardzo podobna liczba (~4% różnicy).

Tak już się stało , a ty masz chyba rozdwojenie jaźni skoro piszesz taki tekst