Pierwsze spojrzenie na nową architekturę GPU firmy AMD

1. Zdaje się (autor: Aelavin | data: 17/06/11 | godz.: 15:43)
   że AMD mniejszym nakładem pracy (ale trochę bardziej rozłożonym w czasie) uda się zrobić to, co na początku chciała zrobi NVIDIA ze swoim Fermi.
   Jeśli ktoś nie czytał artykułu na stronie, który podał pomidor , to warto wspomnieć też o tym iż AMD jest w stanie bardzo szybko zmienić stosunek mocy obliczeniowej DP do SP. Ten stosunek 1:2 (DP:SP) ma być zarezerwowany dla FireStream, a mniejsze dla zwykłych Radeonów.
   
   No i pozostaje nam (albo programistom) poczekać na jakieś przyjmne narzędzie do wykorzystania tego dobrze zapowiadającego się potencjału obliczeniowego ;)
   
   BTW Niech redakcja poprawi parę literówek i braków w newsie
   
   
2. ...... (autor: Marek1981 | data: 17/06/11 | godz.: 15:45)
   Nikt nie czyta stron co podaje pomidor bo to morgopodobny.
   
   
3. @UP (autor: Aelavin | data: 17/06/11 | godz.: 15:49)
   No wiem, ale z ciekawości zajrzałem i w sumie ciekawy artykuł ;)
   
   
4. pomidor (autor: agnus | data: 17/06/11 | godz.: 15:59)
   jest jak Gollum. Prącie wie co za chwilę wymyśli. Czasami pisze do rzeczy, ale tylko czasami.
   
   
5. Zobaczymy (autor: Jarek84 | data: 17/06/11 | godz.: 16:26)
   Widać, że karty w głównej mierze są pochodną idei GPGPU jak i przede wszytkim APU, które dla AMD jest obecnie priorytetowym produktem.
   
   Zobaczymy, czu oprócz wspomnianej przebudowy CU w stosunku do poprzednich serii (wg mnie spełniały ich architektura SPU była i tak bardzo udana na tle NV) dodadzą też nowe bardziej rozrywkowe ficzery...
   
   Ciekawi mnie również ile zaszyją w przyszłych smokach teselatorów, SP, TMU i w jakiej konfiguracji - duży ? widnieje zarówno w przypadku przyszłych kart AMD i NV.
   
   Marzy mi się skok jak za czasów R300 czy G80 - czyli oblrzymi boost wydajności oparty na innowacyjnym pomyśle a nie na brute force.
   
   
6. @news (autor: Promilus | data: 17/06/11 | godz.: 17:00)
   Czyli co? Cayman z podsystemem pamięci Fermi oraz takim też stosunkiem SP:DP? :> Miło, tylko czemu tak późno ;) Oczywiście w bonusie dostęp do pełnej pamięci systemowej i utrzymanie spójności danych CPU oraz GPU w tej pamięci. VLIW porzucają na rzecz SIMD jak w SPE Cella, no no...
   
   
7. Slaydowe przyśpieszenie? (autor: insomnia | data: 17/06/11 | godz.: 18:31)
   Cieszy nas postęp. Jednak nie zapominajmy, że NVIDIA też nie śpi i z pewnością dotrzyma kroku lub da jeden do przód.
   
   
8. Teraz niech NV goni AMD :P (autor: Dather | data: 17/06/11 | godz.: 19:04)
   Bez wahania można rzec: AMD, dlaczego tak późno?!
   
   
9. haha, AMD 3 lata za nvidia (autor: pomidor | data: 17/06/11 | godz.: 21:21)
   u nvidia wsparcie dla C++, virtual memory itp są w fermi, a scalar shaders to nawet wcześniej. Zaś u AMD to będzie pod pod koniec 2012, a i tak nie wiadomo czy wszystko od razu. Jak za rok nvidia wypuści Denver, i pokaże nowe możliwości integracji CPU z GPU, dzięki czemu programowanie w CUDA 4 wejdzie na nowy niespotykany poziom, i tylko umocni swoją pozycję (wciąż nr 1 pomimo zapewnień konkurencji konkurencji). Trzeba będzie wydawać nowe wersje OpenCL, DirectCompute i innych, aby nvidii dotrzymać kroku. AMD będzie hamulcowym, bo skopiuje te rozwiązania po następnych 2-3 latach.
   
   
10. Czy autor wie o czym pisze? (autor: grab56 | data: 17/06/11 | godz.: 21:39)
    Z pierwszego zdania wynika, że architektura VLIW zostanie zamieniona na "całkiem nową architekturę (28nm)". Co ma VLIW do procesu technologicznego? Proszę tłumaczyć/przepisywać/pisać ze zrozumieniem!!!
    
    
11. @grab56 (autor: Wedelek | data: 17/06/11 | godz.: 21:54)
    nawiasy są nie bez kozery. 28nm jest tutaj tylko dodtakiem który ma informować że będzie to już produkowane w 28nm, a nawiasy są dodane dlatego, by zdanie miało sens. Gdyby ich nie było to faktycznie mogłoby to znaczyć tyle ile napisałeś. Ale są:)
    
    
12. ...@9 (autor: trepcia | data: 17/06/11 | godz.: 22:11)
    To jest jedna z tych wypowiedzi pomidołka, kiedy mu nasionka w głowce sfermentowały.
    
    
13. ... (autor: pawel.xxx | data: 17/06/11 | godz.: 22:13)
    Te nowe CU są mocno podobne do procesorów sprzed 15 lat. Można też napisać że te nowe rdzenie to cudacore nvidii wyposażone w jednostki SIMD.
    Całość w pewnych aspektach zaczyna przypominać to co intel chciał osiągnąć projektując larrabee.
    Pytanie tylko czy te jednostki skalarne będą w pełni uniwersalne? Jeśli będą to taka architektura pozwoli na masowe wykorzystanie mocy obliczeniowej GPU, i jeśli AMD uda się stworzyć jakiś rodzaj stabilnej w czasie listy instrukcji to mają wielkie szanse na sukces.
    Oczywiście będą też problemy. Po pierwsze rozrost CU - czyli będzie ich mniej w całym GPU. Stracą na wydajności przetwarzania w zastosowaniach rozrywkowych ale zwiększą wydajność i uniwersalność GPGPU.
    Sterowniki w ich przypadku powinny być mniejszym problemem bo największe zmiany będa dotyczyc schedulerów zadań.
    
    
14. @9. (autor: Mariosti | data: 18/06/11 | godz.: 06:18)
    Nvidia nie ma i nie miała wsparcia C++ w swoich gpu. Mają tylko wsparcie mocno okrojonego C, podobnie jak, zgadnij kto, AMD ze swoimi Radeonami.
    Co do "virtual memory" w kartach nvidii to bądź łaskaw na tyle aby rozwinąć nieco ten temat, bo przy tak lakonicznej wypowiedzi nie mogę od razu wytknąć tobie błędu który jest nieunikniony.
    Dlaje, scalar shaders - to jest największy problem nvidii bow gpgpu taki gtx580 ma wydajność na poziomie radeona 5770, właśnie z powodu niedoceniania jednostek wektorowych przez nvidię... Jeśli amd dalej będzie starało się wybalansować złożoność CU to będzie to tylko na korzyść nas, czyli klientów.
    
    
15. Czy oddzial AMD-emu ,ktory sie slejdami zajmuje dla konkurencji pracuje (autor: josefek | data: 18/06/11 | godz.: 08:03)
    Jeszcze nigdy cos takiego nie widzialem, aby ktos swoimi projektami publicznie sie dzielil zanim te projekty do konca doprowadzone sa, jak dobrze pamietam, zabojca AMD w netbookach sie nagle pojawil , apotem o nim slejdy pokazano....tymi slejdami kogo AMD chce przekonac---moze ma nadzieje ze na uniwersytetach zaczna o strukturach AMD wykladac, szkoda ze synowie juz studia skonczyli to bym sie zapytal...
    
    
16. up. (autor: Krax | data: 18/06/11 | godz.: 09:23)
    amd ma tak bardzo czesto>
    trzymam kciuki ...ale juz nie jedno zapowiadali....ale albo to niedzialalo tak jak nalezy albo konkurencja zrobila to co oni wymyslili znacznie szybciej.... jezeli amd wyda swoj nowy kontroler pamieci za trzy lata to wcale mnie nie zdziwi jak intel zrobi to za rok... intel ma znacznie wieksze srodki(fakt ze czesto w niezby uczciwy sposob zdobyte) ale jednak
    
    
17. jeszcze... (autor: Krax | data: 18/06/11 | godz.: 09:26)
    nie moge doczekac sie jak wprowadza swoje pelne wsparcie.... dla gpu....wyobrazcie sobie system operacyjny dzialajacy o gpgpu, wykorzystujacy pelna moc obliczeniowa apu:D
    pomarzyc zawsze mozna ... no nie?;)
    
    
18. @Mariosti (autor: Promilus | data: 18/06/11 | godz.: 10:03)
    Zasadniczo w GPU nie mają wsparcia żadnego języka oprócz wewnętrznego. Wsparcie dla C++ jest, a zarezerwowane dla Fermi bo nie chciało im się rozbudowywać kompilerów - ot Fermi ma ładny sprawny cache, a starsze serie mają znacznie mniej sprawny. Bez sprzętowego cache zapewniającego spójność danych między CU
    (L2) i w obrębie samego CU (L1) między różnymi SIMD/Scalar trzeba uciekać się do sztuczek w kompilerze. A po co? Żeby C++ działał gorzej niż C? Żeby programiści szarpali włosy? Nie. Lepiej zrobić od razu porządny model programowy niż potem łatać, poprawiać. AMD idzie śladami NV i to widać. Ale... idzie też swoją drogą bo nie porzucili wektorowych jednostek tylko zmienili VLIW5 na 1Scalar+1Vec4 zupełnie niezależne od siebie (we VLIW jednak wszystko było załatwiane 1 instrukcją więc czasem trudno było zapewnić owe 4D+1). Nowy model jest o tyle fajny, że może zapewnić jeszcze lepsze wykorzystanie ALU niż VLIW4 i do tego jeszcze prostszy jest kompiler. Nadal moc przeliczania wektorów będzie olbrzymia, poprawi się wydajność w przeliczaniu skalarów. Jak w SSE2 masz SIMD 128bit i przetwarzasz 4 FP32 lu 2FP64 tak u AMD będzie tak samo, zatem albo 4+1FP32 albo 2FP64+1FP32, szczytowa wydajność double precision wzrasta z 0,2 czy 0,25 do 0,4 z peak SP. Szkoda, że rozłożyli to na 3 lata, bo gdyby wydać wszystko naraz to Fermi wymięka.
    
    
19. ... (autor: pawel.xxx | data: 18/06/11 | godz.: 10:54)
    Na anadtech jest artykuł trochę dokładniej opisujący nową architekturę.
    Okazuje się że na jedną jednostkę scalar przypadają 4 SIMD 16 pozycyjne.
    Moim zdaniem taki stosunek scalar/simd jest zdecydowanie za mały.
    Przy takim stosunku wydajność w zastosowaniach graficznych nie zostanie mocno ograniczona.
    Jednak możliwości wykorzystania mocy gpu w zastosowaniach gpgu będą całkiem mocno ograniczone.
    Dziedziny GPGPU w których dotychczasowe architektury amd były mocne nadal pozostaną mocne, dojdą do tego te dziedziny w których potrzeba dużej mocy arytmetycznej ale w których nie da się z góry przewidzieć na jakich danych tę moc wykorzystać, czyli będzie lepiej działać niewielka część bardziej nieliniowych algorytmów.
    Natomiast w zastosowaniach bardziej uniwersalnych wydajność może nawet się obniżyć w stosunku do poprzedniej architektury. Czy i jak duży będzie to spadek zależy zależy od różnic w efektywności wykonania operacji skalarnych między vliw w scalar core. Być może amd chce te bardziej uniwersalne algorytmy wykonywać na części CPU APU.
    Przy takiej architekturze można zapomnieć o os działającym na gpu, bo by takie coś było możliwe to SIMD powinno być dodatkiem do jednostki skalarnej - czyli jednostka skalarna + SIMD 4-16 pozycyjny
    W planach amd wyglada natomiast to tak że to jednostka skalarna jets dodatkiem do SIMD
    
    
20. @pawel.xxx (autor: Promilus | data: 18/06/11 | godz.: 11:30)
    "Przy takiej architekturze można zapomnieć o os działającym na gpu, bo by takie coś było możliwe to SIMD powinno być dodatkiem do jednostki skalarnej - czyli jednostka skalarna + SIMD 4-16 pozycyjny "
    Też mi się tak zdaje... 1scalar+simd 4*32bit lub nawet 8*32bit to byłoby moim zdaniem optimum, w końcu mniej więcej tak wygląda to w CPU od ponad dekady.
    
    
21. @19. (autor: Mariosti | data: 18/06/11 | godz.: 12:24)
    GPU przetwarza zasadniczo tylko i wyłącznie problemy które można prosto zrównoleglić względem danych. To oznacza że nie ma sensu aby poszczególne grupy sp'ków były niezależnymi uniwersalnymi procesorami. Takie wymaganie mamy tylko względem całych CU których np w 6970 masz tylko 24 takowe (mówię o pojęciu CU zgodnym z modelem z OpenCL, zwanym też czasem Streaming Multiprocessor), GTX580 16 i to dopiero te grupy mogą pracować na różnych zestawach wątków i odwoływać się do pamięci karty graficznej (razem). Dlatego układ pojedynczego sp'ka nie ma aż takiego znaczenia bo obecnie we vliv4 nie ma dedykowanej jednostki skalarnej, tylko 4sp'ki mogące działać w trybie pojedynczej precyzji na 4x32bitach mogą działać w trybie podwójnej precyzji na 2x64bitach. Co tak właściwie oznacza że to:
    "na jedną jednostkę scalar przypadają 4 SIMD 16 pozycyjne" nie ma sensu i wynikać może tylko z błędnego uproszczenia tematu.
    
    @18.
    Fermi ma takie samo wsparcie dla C++ jak i dla javy i pythona... Czyli program host'a który przygotowuje dane i alokuje zasoby może być kompilowany tak po prostu w gcc i msvc (sprawdzałem), ale ten program odpala się na CPU. Na GPU chodzą dopiero kernele i te pisze się w CUDA C i OpenCL C, które to są podzbiorami C jak to już mówiłem (i z resztą piszę w tym na bieżąco).
    
    
22. @Mariosti (autor: Promilus | data: 18/06/11 | godz.: 13:28)
    No właśnie jest już subset C++ w CUDA, wymagania bodajże SDK 4.x i cuda capabilities 2.x (gf100 wzwyż).
    "*na jedną jednostkę scalar przypadają 4 SIMD 16 pozycyjne* nie ma sensu i wynikać może tylko z błędnego uproszczenia tematu"
    To akurat wynika ze slajdów. Patrz... masz 16 "lanes" VLIW4 w każdym SIMD Core, będziesz mieć 4SIMD 16x32b w każdym CU a do tego 1 scalar unit. Zatem 1 scalar unit + 4x 16 byte wide vector units per CU. Tyle i tylko tyle wynika ze slajdów. Dla mnie trochę dziwne, żeby nie powiedzieć bardzo dziwne. Rozumiem, że chcą nazbierać do jednej instrukcji aż 16 danych 24/32bit, a jak z mieszaniem? Tj. na przykład w jednym czasie liczenie mul na 8x32b i 4x64b? Właśnie... niewiadomo.
    
    
23. @Wedelk (post nr 11) (autor: grab56 | data: 18/06/11 | godz.: 13:42)
    Ale w takim razie co to za "całkiem nowa architektura"?
    Bo w tekście brak chociażby jej nazwy.
    
    
24. promilus (autor: Aamitoza | data: 18/06/11 | godz.: 14:09)
    http://cdnmo.coveritlive.com/...06/php0NkoTf08.jpg
    
    
25. Szykuje sie młot na Intela ;) (autor: Gigant | data: 18/06/11 | godz.: 14:21)
    Te CU to mi przypominają przypakowane rdzenie Larrabee...
    
    Larrabee core ma 512bit SIMD(vec16)
    Te CU to ma 4x512bit FPU. 4x więcej niż Larrabee i z obsługą OoO.
    
    
26. AMD może sobie rozbudowywać (autor: pomidor | data: 18/06/11 | godz.: 15:07)
    swoje APU, ale nie zmieni to faktu że GPGPU na desktopach nie istnieje. Dalej pokazują możliwości na przykładzie symulacji zderzania galaktyk, co jest bezsensownym i niepraktycznym przykładem. Każde APU skończy jako low-end 3d.
    
    
27. pomidor (autor: Gigant | data: 18/06/11 | godz.: 15:59)
    poto jest robione APU dla lowendu aby można było tanio kupić jeden element a nie CPU i GPU. Idea APU to właśnie integracja i nic więcej bo jak ktoś chce powera to kupuje oddzielne dedykowane karty i CPU...
    
    
28. @Gigant (autor: pomidor | data: 18/06/11 | godz.: 19:35)
    Widzę że nie do końca rozumiesz intencji swojej ulubionej firemki.
    
    Celem połączenia CPU + GPU jest:
    1. Stworzenie prostszego i tańszego tandemu CPU + grafika 3d.
    
    2. Użycie GPU do niegraficznych zadań. W tej roli GPU przyjmuje nazwę APU, i jest modyfikowany (jak podano w newsie), aby te zadania mogły być sprawnie realizowane. Ma to spowodować skrócenie czasu wykonywanie tych zadań oraz zmniejszenie ilości energii elektrycznej potrzebnej do ich wykonania.
    
    Mam nadzieję że Ci się rozjaśniło, bo prościej już się nie da.
    Ja twierdzę że GPU w roli APU będzie rzadko używany.
    
    
29. Dlaczego GPU ma być rzadko używane? (autor: Gigant | data: 18/06/11 | godz.: 20:25)
    Skoro AMD zrobiło z GPU normalne rdzenie CU to nic nie stoi na przeszkodzie aby w takim samym stopniu wykorzystywać rdzenie CPU jak i CU...
    
    
30. @Mariosti (autor: pawel.xxx | data: 18/06/11 | godz.: 20:31)
    W poście 21 opisujesz czym zajmuje się gpgpu w obecnej postaci. Nawet nie wnikając w szczegóły które podajesz można stwierdzić że błądzisz i przyjmujesz błędne założenia.
    Celem dla którego amd ma zamiar zmienić architekturę jest właśnie chęć wyjścia poza ograniczenia które narzucały dotychczasowe rozwiązania. Celem zmiany jest zwiększenie obszaru stosowalności gpgpu i dlatego pisanie do czego tylko i wyłącznie nadaje sie gpu jest błędem. Bo po to właśnie wprowadzają te zmiany by gpu nadawało sie do znacznie większego spektrum problemów.
    Opisujesz jak działają obecne gpu a amd jednocześnie stwierdza ze taki sposób działania to dla nich za mało, że ich zdaniem nie daje on perspektyw rozwoju i że zmieniaja architekturę po to by było lepiej.
    
    
31. @29. (autor: Mariosti | data: 18/06/11 | godz.: 20:33)
    Widzisz, pomidorek nie jest wstanie zrozumieć iż taki OpenCL jest dość nowym standardem i tym bardziej młode są jego implementacje, a co za tym idzie jest to zupełnie nowe pole dla programistów którzy po pierwsze niewiele wiedzą o takim stylu programowania, a po drugie niewiele jest firm które chcą ryzykować jakiekolwiek środki na budowanie od podstaw złożonych rozwiązań które wcale nie muszą się okazać hitami. Obecnie większość firm produkujących soft stawia na szybki developing i "języki" typu java i C#, podczas gdy porządne wykorzystanie GPU wiąże się z mimo wszystko dość niskopoziomowym programowaniem, bardzo dużą wiedzą na temat architektur GPU i ogromną wiedzą na temat zrównoleglania algorytmów pod takie procesory (podczas gdy taka wiedza jest dopiero tworzona, dzięki firmom/programistom którzy przecierają szlak bo nie mają po prostu wyboru). Takich programistów jest bardzo mało, większość to klepacze kodu niewiele różniący się od operatorów łopat ;]
    
    
32. @30. (autor: Mariosti | data: 18/06/11 | godz.: 20:42)
    CPU i GPU to dwa zupełnie różne typy procesorów. W CPU nacisk jest kładziony na potężne przetwarzanie sekwencyjne wspomagane względnie niewielkimi jednostkami równoległymi.
    
    Wiedząc to można łatwo się domyśleć że nie ma sensu aby ktokolwiek próbował zrobić z GPU CPU, bo powstanie po prostu wielordzeniowe CPU. Mam nadzieję że to wystarczająco jasne?
    
    No i teraz... skoro mamy CPU które świetnie radzi sobie z przetwarzaniem sekwencyjnym, to bardzo sensownym będzie uzupełnienie jego możliwości o procesor który jest stworzony specjalnie do przetwarzania równoległego, czyli GPU. I teraz odsłania się kolejna karta z odpowiedzią - nawet jeśli każdy z rdzeni GPU będzie w stanie wykonać każdą operację jaką chcielibyśmy od zwykłego procesora, to ma to tylko sens przy przetwarzaniu równoległym, bo w algorytmach sekwencyjnych najlepsze gpu świata będzie beznadziejnie wolniejsze nawet od takiego Atoma.
    
    To czego byś chciał to procesor który zmienia swoją architekturę dynamicznie zależnie od tego jakiego typu zadania wykonuje... póki co to tylko science fiction. To co amd chce zapewne osiągnąć z tą nową architekturą gpu to zmniejszenie liczby ograniczeń jakie są narzucone na równoległe algorytmy na nich wykonywane, co bynajmniej nie oznacza że nagle chcą zrobić z GPU CPU, bo to jest bez sensu.
    
    
33. @ad. (autor: Mariosti | data: 18/06/11 | godz.: 20:48)
    Właśnie idea larrabee jest zapewne tym do czego będzie powoli dążyło amd i nvidia ze swoimi przyszłymi architekturami GPU, co wciąż nic nie zmieni jeśli chodzi o główne zastosowania gpu, tylko najwyżej uprości wykorzystanie jego potencjału w przetwarzaniu równoległym z wykorzystaniem bardziej wyrafinowanych algorytmów które będą miały większą dowolność dzięki likwidacji obostrzeń obecnych architektur (np specyficzne schematy dostępu do pamięci operacyjnej gpu potrafią zwiększać jej przepustowość kilkadziesiąt razy, wiele sp'ków ma ograniczone zestawy wykonywanych instrukcji, poszczególne grupy sp'ków wewnątrz jednego cu nie mogą wykonywać różnych kerneli, ani pracować na różnych danych itd. te rzeczy są autentycznie wkurzające i powodują że dotychczasowa wiedza o zrównoleglaniu algorytmów w stylu wielordzeniowych CPU ma ograniczoną użyteczność przy tworzeniu kerneli na GPU).
    
    
34. ... (autor: pawel.xxx | data: 18/06/11 | godz.: 20:57)
    Moim zdaniem przyszłość gpu i gpgpu należy do architektur które będą zbliżone do architektury larrabee- czyli sieci kompletnych w sensie turinga rdzeni wspomaganych przez jednostki SIMD.
    Nie widzę innej możliwości by general purpose ze skrótu gpgpu mógł się stać rzeczywiście GP.
    
    
35. @Mariosti (autor: pomidor | data: 18/06/11 | godz.: 22:10)
    Myślę że nie bardzo trafiłeś z wyjaśnieniem problematyki przetwarzania równoległego.
    Główny problem wcale nie jest związany z tym, że CPU wielordzeniowe, GPU oraz API (OpenCL, CUDA itd) są nowością i z tego powodu są nieznane. Problem leży w samej naturze przetwarzania równoległego, a nie w implementacjach rozwiązań na których można dokonywać takiego przetwarzania. Im więcej zależności występuje w danych, tym trudniej rozdzielić przetwarzanie na niezależne zadania. Bardzo często zarówno dane jak i te zależności, posiadają nieregularną strukturę, co dodatkowo utrudnia zadanie. Te problemy powodują że trzeba wymyślać bardzo skomplikowane reguły działania programu, które zapewnią poprawne przetwarzanie oraz nie spowodują spadku wydajności. Już na tym etapie jest to koszmar dla programisty, a jeszcze nie było mowy o uwzględnieniu specyfiki procesora, API czy systemu operacyjnego. To wszystko sprawia że często program szeregowy, staje się horrorem w wersji równoległej.
    
    Generalnie problem przetwarzania równoległego jest rozwiązywany od kilkudziesięciu lat, i nie udałe się znaleźć złotego środka, czyli koncepcji przetwarzania która była by łatwo przyswajalna dla programistów i gwarantowała pracę rdzeni pełną parą. Na razie udało się tylko wymyślić synchronizację (czytaj: zatrzymywanie) wątków oraz koncepcję pamięci transakcyjnej. Ani jedno ani drugie nie jest dobrym rozwiązaniem, i ma więcej wad niż zalet.
    
    Rewolucja wielordzeniowa w CPU dobiega końca, a stosowanie trybów turbo i dalsze zwiększanie IPC są na to dowodem. W tej sytuacji jeszcze trudniej będzie znaleźć zajęcie dla setek rdzeni w APU/GPU.
    
    Dodawanie równoległości do programu jest dodatkową możliwością optymalizacji programów, i dla 90% aplikacji będzie niestety nieefektywna. W tym przypadku lepsze rezultaty będą osiągane poprzez zejście do niskopoziomowego języka czyli C lub asembler, lub optymalizację samego algorytmu.
    
    
36. @35. (autor: Mariosti | data: 18/06/11 | godz.: 23:46)
    Problemy o których piszesz rozwiązywane są przez CPU które są specjalnie do tego stworzone. Spopularyzowanie wykorzystywania GPU chociażby do wszelkich zastosowań związanych z przetwarzaniem multimediów (które to stanowią lwią część zastosowań komputerów, operują na coraz to bardziej potężnych ilościach danych i w większości naturalne jest ich przetwarzanie równolegle) jest głównym celem GPU w APU, a fakt iż niewiele softu z tego korzysta wynika dokładnie z tego co napisałem, właśnie dlatego że APU do ogólnego programowania GPU są nowe i sama idea jest też nowa dla większości programistów.
    
    "Rewolucja wielordzeniowa w CPU dobiega końca", i oczywiście planowane na przyszły rok 20rdzeniowce do serwerów są wg ciebie dowodem na to? Dużo łatwiej jest zwiększyć liczbę rdzeni chociażby z samego powodu zmniejszania się procesu technologicznego niż dalsze zwiększanie niebywale wyżyłowanego IPC, czy też taktowania przy obecnie wykorzystywanych materiałach. Dopóki nie będzie możliwości szybkiego zwiększenia taktowania tranzystorów 10-100x bez zwiększonego zużycia energii, dopóty CPU będą szły w liczbę rdzeni, zresztą to samo będą robiły GPU, przy czym w ich przypadku jest znacznie większe pole do popisu jeśli chodzi o wielość ścieżek rozwoju ich architektur.
    
    
37. @Mariosti (autor: Promilus | data: 19/06/11 | godz.: 08:49)
    Racja. Niektórzy sądzą, że z GPU zrobi się taki multicore pentium z konkretnym SIMD, będzie OS specjalnie przygotowany z myślą...itp; możliwe, że w końcu kiedyś tak będzie, ale do tego czasu CPU też ewoluują i nadal będą wymiatać w wielu zadaniach, których jak do tej pory nie udał się zrównoleglić. Symultaniczne wykonywanie różnych kerneli z wieloma wątkami na GPU to już Fermi pokazało, że jest to duży krok naprzód bo mimo niewielkiego wzrostu samej szczytowej mocy obliczeniowej wydajność w aplikacjach wzrosła znacząco. Koniec z dokładaniem procesorów strumieniowych "na pałę" czas na mądre rozwiązanią czyli mózg zamiast mięśni.
    "Dużo łatwiej jest zwiększyć liczbę rdzeni chociażby z samego powodu zmniejszania się procesu technologicznego niż dalsze zwiększanie niebywale wyżyłowanego IPC, czy też taktowania przy obecnie wykorzystywanych materiałach"
    Tak, ktoś powie, że GPU są setki razy szybsze od CPU. No to hop... Fermi, 512cuda cores, wydajność jak dobrze pamiętam 1.4TFLOPS, zużycie energii >200W, dziwne ECC (tj ECC L2, a mem na karcie zwykły... tyle, że część jej wydzielona do mechanizmu programowego ECC). Taki Magny Cours 12 rdzeni ~110GFLOPS przy zużyciu energii poniżej 125W. To widać, że różnica jest ledwie między 10 a 20x. W przypadku nowych SB EP pewnie mniejsza, ale rewolucji nie ma. Superkomputery oparte wyłącznie o CPU mają typową wydajność w okolicach 80-90% teoretycznej szczytowej, a oparte o CPU i GPU w okolicach 60-70%. Jasne, GPU dają kopa HPC, ale trzeba sobie zdać sprawę z tego, że wiele zadań które się na nie ładuje jest wykonywane bardzo nieefektywnie, mimo że kilka razy szybciej od CPU to duża część GPU jest niewykorzystana. W CPU dzięki wieeeelu latom doświadczeń udaje się nawet słabo zoptymalizowane appsy efektywnie wykonywać. I tego GPU nigdy nie przeskoczą.
    
    
38. Promilus (autor: Gigant | data: 19/06/11 | godz.: 17:10)
    A co jak te GPU jest zbudowane z rdzeni CPU? ;) AMD jak widać wywaliło sztywne VLIW i postawiło na SIMDy 512bit... Wystarczy teraz tylko zaimplementować OoO i adresowanie x86-64bit i z GPU robi się CPU...
    
    
39. Promilus (autor: Gigant | data: 19/06/11 | godz.: 17:25)
    Fermi ma 512 cudacznych rdzeni 64bit a nie 32bit wiec twoje wyliczenia są do bani stary ;) bo powinno być 2x więcej flopsów...
    Nie sądzisz chyba, że GTX580 z 1.58Tflops może być szybsza od Radzia z 2.7Tflops? ;)
    
    Radeon HD6970 = 1536SP*880MHz*2flops = 2.7Tflops
    GeForce GTX570 = 512SP *1544MHz*4flops = 3.16Tflops
    
    ;-)
    
    
40. ... (autor: Aamitoza | data: 19/06/11 | godz.: 17:50)
    Gigant młotku - fermi ma 32bitowe rdzenie. Widzę, że po raz kolejny będziesz zaprzeczał wszystkiemu co podają producenci. No oczywiście nvidia podawała by że mają 1,5Gflops w SP zamiast 2x tyle? No oczywiście po co się chwalić, że w DP mają 1,5Gflopsa a w SP 3Tflopsy, skoro mogą napisać, że jest 2x mniej.
    
    Co Ty sądzisz to zazwyczaj bzdury i największe idiotyzmy jakie padają an tym portalu, a rzeczywistość leci sobie w przeciwną stronę.
    
    http://www.nvidia.com/...chitecture_Whitepaper.pdf
    
    tabela strona 11. -
    
    Double Precision Floating Point Capability - 256 FMA ops /clock
    
    Single Precision Floating Point Capability - 512 FMA ops /clock
    
    Gdyby było tak jak piszesz w DP mieli byśmy 512FMA ops na takt. Czyli nie, po raz kolejny już z resztą nie masz racji.
    
    
41. ... (autor: Aamitoza | data: 19/06/11 | godz.: 18:00)
    Proponuję zauważyć kilka zależności - fermi ma 48ROP, Cayman tylko 32. Akurat jednostek teksturujących cayman ma sporo więcej, ale to nie ma aż takiego znaczenia w obecnych grach (no może poza crysisem). Kolejna sprawa, Wykorzystanie SPU w radeonie jest problematyczne, a gry i tak nie wykorzystują ich pełnego potencjału więc nie ma co patrzeć w ogóle na moc szczytową teoretyczną, tylko praktyczną.
    
    I widać tę różnicę we flopsach tylko w specyficznych zastosowaniach - gdzie nawet HD6850 potrafi zrównać się z fermim, ale sa i takie zastosowania, gdzie fermi wyprzedza mocno radeony mimo, że taki cayman w DP ma podobną moc obliczeniową, a w SP prawie 2x większą.
    
    
42. @Gigant (autor: Promilus | data: 19/06/11 | godz.: 18:08)
    Ale AMD to nie na rękę budować GPU z rdzeni CPU. Oni chcą sprzedawać i CPU, i GPU. Tak samo intel - chce sprzedawać i CPU (Xeony) i ...MIC (Knights Ferry). Tak samo NV z ARM+GF.
    Co do wyliczeń - udowodnij że jest inaczej a nie pierdziel znowu o 64bitowych cuda cores.
    "Nie sądzisz chyba, że GTX580 z 1.58Tflops może być szybsza od Radzia z 2.7Tflops"
    Ależ oczywiście, że sądzę. Tam gdzie jest dużo problemów skalarnych, skoków, gdzie dużo ogranicza dostęp do pamięci, wreszcie gdzie trzeba przetworzyć dużo wierzchołków - wszędzie Fermi ma wielką przewagę nad Cypressem i nawet Caymanem. Całe szczęście ogółem gry są bardziej zbalansowane zarówno jeśli chodzi o geometrię jak i oświetlenie więc architektura VLIW się dość dobrze sprawdza. Nawet shader postproces FXAA cz GPAA (techniki opracowane przez nv) działa bardzo dobrze na radeonach bo pasuje im VLIW i odnotowują mniejsze spadki po włączeniu niż na Fermi. Nie jest też niczym trudnym znalezienie zastosowań gdzie Cayman i Cypress są od Fermi wyraźnie szybsze (ogólnie pojęta kryptografia)
    Np.
    http://www.golubev.com/gpuest.htm
    Pasuje?
    
    
43. @Amitoza (autor: Promilus | data: 19/06/11 | godz.: 18:12)
    TMU w Fermi to bodajże 1TA i 3TF albo na odwrót, w przeciwieństwie do 1TA+1TF w radeonach więc akurat sama liczba nie nadaje się do bezp. porównania. Fermi ma 4GPC czyli 4 render engines (raster engines) i do 16 geometry engines. Jak to wygląda w Caymanie mającym odpowiednio mniej więcej 2 raster engines i 2 geometry engines? No własnie.
    
    
44. Aamitoza (autor: Gigant | data: 19/06/11 | godz.: 20:06)
    Tabela na stronie 11 pokazuje że:
    Load/Store Address Width to 64-bit
    
    Zatem Fermi ma 64bit adresowanie oraz obsługuje 64bit instruckje na swoich cuda corach. Z tego logicznie wynika, że te cudaczne core muszą mieć 64bit FPU inaczej nie dało by się na nich robić DP...
    
    Gadałem z Nvidią na tym slajdzie jest błąd bo powinno być 1024 FMA ops SP...
    
    To samo jest z Xenosem. Ten układ ma 12SP (48 ALU) a nie 48SP (192ALU)
    
    
45. Promilus (autor: Gigant | data: 19/06/11 | godz.: 20:11)
    Nie bądz śmieszny. Myślisz, że AMD jest tak głupie, że zrobiło architekture która jest 2x mniej efektywna od konkurencji? Nie ma takiego bata utylizacja vliw4 jest na poziomie ponad 3.4 więc ponad 85% a u Nvidi też nie ma 100% utylizacji, nvidia twierdzi że na poziomie około 80-90%...
    
    
46. @Gigant (autor: Promilus | data: 19/06/11 | godz.: 20:30)
    "Myślisz, że AMD jest tak głupie, że zrobiło architekture która jest 2x mniej efektywna od konkurencji"
    Oczywiście, bo ta architektura bywa nawet bardziej niż 2x mniej efektywna, zwróć uwagę na zaprezentowane slajdy :) 2 z 4 lub 2 z 5 (VLIW4 lub VLIW5) slotów zapełnione kontra 1 z 1 (scalar). Proste i jasne. Myślisz po co AMD aż 1600SP kontra 512 u NV? :>
    "vliw4 jest na poziomie ponad 3.4"
    Taa, a skąd ten numerek? Dobra, nie chcę wiedzieć bo kolacji nie zjem ^^
    "Gadałem z Nvidią na tym slajdzie jest błąd bo powinno być 1024 FMA ops SP"
    Jak nvidia to twój nowy piesek to się dużo nie dowiesz. Ja gadałem z samym Jenem ;)
    "Load/Store Address Width to 64-bi"
    To jest zupełnie co innego co SP. L/S wynika z faktu zastosowania takiej a nie innej struktury pamięci - po prostu najefektywniej jest ciągnąć po 64bity na cykl i tyle muszą mieć jednostki, i taki interfejs musi mieć cache (lub też wielokrotność kontroler pamięci).
    
    
47. @up (autor: Promilus | data: 19/06/11 | godz.: 20:40)
    A tak swoją drogą... K8 ma 64bitowe FPU a przetwarza 128bitowe dane w SSE2. Tak samo Bulldozer ma 128bitowe FMAC a przetwarza 256bitowe AVX. Nie ma co jak pisać pierdoły bez poparcia w faktach.
    
    
48. Promilus (autor: Gigant | data: 19/06/11 | godz.: 21:06)
    Liczba 3.4/4 to oficjalne stanowisko AMD więc nie wiem skąd wziołeś te 2/4, 2/5...
    
    Powiedz mi dlaczego AMD miało by niezapełniac wszystkich slotów skoro paczki VLIW operują na skalarach? Instrukcja VLIW może zawierać 5 instrukcji skalarnych. Nie ma problemu tytaj zawalić wszystkich slotów ;)
    
    K8 przetwarza 128bit dane na 64bit FPU bo może rozbić instrukcje SIMD 128bit na dwie 64bit. W przypadku Fermi żeby wykonać natywną 64bit instrukcje trzeba mieć 64bit FPU . Nie da rozbić 64bit instrukcji bo to nie SIMDowe paczki są ;)
    
    
49. ... (autor: Aamitoza | data: 19/06/11 | godz.: 21:32)
    Widzę, że nowe bajeczki - co ten poryty beret jest jeszcze w stanie stworzyć?. Jak jest błąd na oficjalnym papierku na stronie nvidia, to by go poprawili. Gigant Tak, K8 przetwarzało 128bit w 2 taktach, tak samo fermi przetwarza 64bit instrukcje.
    
    "up to 16 double precision
    fused multiply-add operations can be performed per SM, per clock, a dramatic improvement
    over the GT200 architecture."
    
    To wyjaśnij proszę, dlaczego można wykonać 32 operacje SinglePrecision na jednym SM, a w DP już tylko 16, skoro niby te rdzenie są 64bitowe i powinny robić 32 operacje?
    
    Kiedy w końcu gigant dostanie bana?
    
    
    A dlaczego amd nie miało by zapełniać wszystkich procesorów? Bo nikomu nie chce rzeźbić w kodzie i optymalizować aby na amd lepiej działało.
    
    http://images.anandtech.com/doci/4455/VLIW.png
    
    tak wygląda działanie VLIW. - w idealnej sytuacji gdy wavefronty nie są od siebie zależne może i da się wykorzystać wszystkie zasoby - wygląda to tak w kryptografii, ale w wielu zastosowaniach znajdzie się jakiś wavefront zależny od innego i wychodzi kicha. bo cayman działa na 1/4, 1/2 lub 3/4 mocy.
    
    
50. @Gigant (autor: Promilus | data: 19/06/11 | godz.: 21:36)
    "Instrukcja VLIW może zawierać 5 instrukcji skalarnych. Nie ma problemu tytaj zawalić wszystkich slotów ;)"
    To może weź sobie stream kernel analyzer zamiast pisać wyssane z palca bzdury nie wiadomo skąd.
    "Liczba 3.4/4 to oficjalne stanowisko AMD"
    Pokaż niby gdzie, skoro typowo było jakieś 2.5-3/5 w VLIW5...
    
    
51. Aamitoza (autor: Gigant | data: 19/06/11 | godz.: 22:19)
    Nie poprawili błędu no to powiedz im żeby poprawili bo w manualu jasno pisze, że cuda core może obsłużyć 64bit integery czy też przetwarzać 2x32bit instrukcje (dual issue).
    
    Myślisz, że Nvidia jest nieomylna? Buhahaha
    Już widze że jakieś tam korekty wprowadzali z wielkością register file ;)
    
    Ja nie twierdze, że cuda rdzenie są 64bit tylko, że jeden cuda core ma 2x32bit FMA. Żeby przetworzyć jedną instrukce 64bit FMA potrzeba użyć 2 cuda core...
    
    To jest działanie VLIW na kodzie seryjnym. U nvidii jak dasz taki kod to też nie wykorzystasz wszystkich 32 cuda core a jedynie 1/32 jak jest zależność ;)
    
    
52. Promilus (autor: Gigant | data: 19/06/11 | godz.: 22:29)
    http://www.anandtech.com/...-6970-radeon-hd-6950/4
    
    Tutaj piszą o 3.4/5 średnim wykorzytaniu slotów u Cypressa co daje 3.4/4 u Caymana...
    Cayman może mieć lepszą efektywność niż Fermi...
    
    
53. @Gigant (autor: Promilus | data: 19/06/11 | godz.: 22:36)
    Ok... whitepaper
    The first Fermi based GPU, implemented with 3.0 billion transistors, features up to 512 CUDA
    cores. A CUDA core executes a floating point or integer instruction per clock for a thread. The
    512 CUDA cores are organized in 16 SMs of 32 cores each.
    Do tej pory jasne? 1 int lub float w cuda core.
    Dalej...
    The Fermi architecture has been specifically
    designed to offer unprecedented performance in double precision; up to 16 double precision
    fused multiply-add operations can be performed per SM, per clock
    Aaa... a cuda cores jest 32 per SM ;) No tak :P
    16 instrukcji DP a 32 cuda cores w SM.
    A teraz odnośnie poprawek to skoro poprawili opis L2 i register file to nie poprawiliby tabelki? :> To może jeszcze raz policz wydajność DP dla fermi wg TWOJEGO widzimisię ;)
    
    
54. @Gigant (autor: Promilus | data: 19/06/11 | godz.: 22:37)
    "AMD’s own internal database of games tells them an interesting story: the average slot utilization is 3.4 – on average a 5th streaming processor is going unused in games"
    Ja pierdu... a czytać ze zrozumieniem potrafi? FOR GAMES!!!! A my tu chyba o GPGPU piszemy.
    
    
55. Promilus (autor: Gigant | data: 19/06/11 | godz.: 23:10)
    Puść kod szeregowy na jednym SM to zobaczysz, że utylizacja będzie na poziomie 1/32. Fermi ma taką samą utylizacje jak nie gorszą od Caymana...
    
    In Fermi, the newly
    designed integer ALU supports full 32-bit precision for all instructions, consistent with standard
    programming language requirements. The integer ALU is also optimized to efficiently support
    64-bit and extended precision operations.
    
    No jasne teraz wszystko? Obsługa 64bit instrukcji jak byk pisze...
    
    
56. ... (autor: Aamitoza | data: 19/06/11 | godz.: 23:16)
    A gdzie napisali że na jednym cuda core? Tak samo Athlon 64 wspierał SSE2.
    
    
57. Aamitoza (autor: Gigant | data: 19/06/11 | godz.: 23:28)
    Umiesz czytać ze zrozumieniem? Pisze, że integer ALU może obsłużyć 64bit operacje a nie, że 2 integer ALUs albo 2 cuda cores...
    
    W przypadku Athlona 64 to AMD jasno powiedziało że do obsługi 128bit potrzeba 2 instrukcji 64bit i nie ma natywnego wsparcia w jednym cyklu...
    
    
58. ... (autor: Aamitoza | data: 20/06/11 | godz.: 00:56)
    Tylko powiedź mi gdzie masz tam napisane, że w jednym takcie, albo, że robi to jeden cuda core? Nie ma. Za to jest napisane, że SM z 32rdzeniami może zrobić tylko 16operacji DP, jak i jest napisane, że cały fermi na takt potrafi zrobić 256 operacji DP. Do tego sama nvidia podaje, że moc fermiego to 1,5Gflops, a nie jak sugerujesz jakieś z sufitu wzięte 3Gflops.
    
    
    "Floating-point operations follow the IEEE 754-2008 floating-point standard.
    Each core can perform one single-precision fused multiply-add operation in each
    clock period and one double-precision FMA in two clock periods."
    
    proszę - z kolejnego papieru nvidia - widzisz? w 2 taktach robi DP.
    http://www.nvidia.com/...lete_GPU_Architecture.pdf
    
    strona 20.
    
    Więc skończ pierdzielić bo na siłę starasz się udowodnić, że masz rację.
    
    Więc skoro 1 cuda core robi to w 2 taktach (tak samo jak FPU athlona 64 SSE2) to na takt wychodzi 16 operacji.
    
    Co prowadzi do tego, że Cuda core są 32bitowe i robią DP w 2 taktach, tak jak FPU athlona 64 robiło 128bit w 2 taktach.
    
    
59. 1,5Tflops. (autor: Aamitoza | data: 20/06/11 | godz.: 00:57)
    poprawka.
    
    
60. Aamitoza (autor: Gigant | data: 20/06/11 | godz.: 01:28)
    Zacznijmy od tego, że Athlon 64 nie robi DP tylko SSE a to dwie różne rzeczy. SSE można wykonać w dwóch taktach bo to nic innego jak 2 paczki oddzielnych instrukcji. Natomiast DP to już potrzebuje 4 cykli...
    http://www.freepatentsonline.com/20110055308.pdf
    
    GTX580 ma 3.16Tflops SP i 790Gflops DP.
    Więc to ty skończ pierdzelić bo karta z 1.58 nie może być wydajniejsza od tej z 2.7Glops.
    Nvidia się jebneła w slajdach...
    
    
61. ... (autor: Aamitoza | data: 20/06/11 | godz.: 06:14)
    ehe, nvidia zaniża wydajnośc swojej tesli tak dla jaj ;)
    
    Szkoda tylko, że u nich wydajność DP do SP to 1/2, a nie 1/4. Więc pierdzielisz bez sensu. 1/4 to jest u AMD.
    
    
62. @Gigant (autor: Promilus | data: 20/06/11 | godz.: 07:16)
    Bzdura. Single Instruction Multiple Data. K8 ma 64 bitowe FPU zatem może 128bitowy SIMD oparty o paczkę 4*32b robić w 2 cyklach. Tak samo 128bit SIMD oparty o paczkę 2*64b, teraz policz ile jest danych w pierwszym przypadku, a ile w drugim przetwarzanych. W pierwszym 4 floaty, w drugim 2 double. Zatem masz 2 float/cykl albo 1 double/cykl. Jest stosunek 2:1? Jest. To czemu u nvidii miałby nie być? To w ilu krokach jest liczone DP nie oznacza, że w tylu cyklach musi być.
    
    
63. Promilus (autor: Aamitoza | data: 20/06/11 | godz.: 07:39)
    Floating-point operations follow the IEEE 754-2008 floating-point standard.
    Each core can perform one single-precision fused multiply-add operation in each
    clock period and one double-precision FMA in two clock periods."
    
    tyle wystarczy. Po prostu gigant jak nie ma racji, to stara się na siłę dopasować wszystko do swojej teorii. Ogólnie rzecz biorąc wie lepiej od producentów co oferują ;]
    
    
64. @Gigant & @Amitoza (autor: gregory07 | data: 20/06/11 | godz.: 10:52)
    Po co się kłócić. Wystarczy wejść na stronę nvidii i już macie odpowiedź http://www.nvidia.pl/...roduct-quadro-6000-pl.html http://www.nvidia.pl/object/product-quadro-5000-pl.html A te 3.16Tflops to nvidia może i ma ale w gtx590 z dwoma GPU.:)
    
    
65. gregory (autor: Aamitoza | data: 20/06/11 | godz.: 14:44)
    Ja to wiem, Ty to wiesz, ale gigant ma jak zawsze swoją "rację" ;] I nawet jak dasz mu 100 dowodów będzie trzymał się swojej wyimaginowanej teorii.
    
    
66. Aamitoza (autor: Gigant | data: 20/06/11 | godz.: 15:09)
    Czytałeś ten patent co ci dałem? Jak do cholery chcesz wykonać instrukcje mnożenia 64bit na jednostce 32bit jedynie w dwa cykle?
    Wytłumacz mi to bo nie kapuje...
    
    
67. Promilus (autor: Gigant | data: 20/06/11 | godz.: 15:22)
    To czemu u AMD nie ma stosunku 2:1 tylko jest 4:1? Wytłumacz mi to , bo skoro AMD i Nvidia mają jednostki 32bit FMA to powinno bezproblemu być 2:1 u obu firma a jednak u AMD nie jest...
    
    Daj przykałd utylizacji w Fermi i Caymanie bo SM też nie jest wykorzystywany w 100% jak masz zależności i kod szeregowy. Architektura Caymana może mieć nawet lepsze wykorzystanie jednostek niż u Fermi bo masz symetryczne skalarne jednostki 4way...
    
    
68. gregory07 (autor: Gigant | data: 20/06/11 | godz.: 15:29)
    Wystarczy wejść na strone Nvidii i łyknąć każdą bzdurę jaką tam napiszą bez namyślunku. Karta z 1.5TFlops pokonująca karte z 2.7TFlops to takie bajki to tylko w erze...
    
    
69. @Gigant (autor: Promilus | data: 20/06/11 | godz.: 15:40)
    A przyjrzałeś się kiedyś temu co robi gdzie i jak VLIW u AMD? No to tak:
    VLIW5 - 1FP MAD 32b zawsze (transcendental) i do tego 4FP MAD 32b lub 2FP ADD/MUL 64b lub 1FP MAD 64b. FPMAD ma 2op jak i FMA (tyle, że FMA nie obcina w międzyczasie wyniku więc jest dokładniejsze). Więc w 32b jest 5*2op=10op/cykl. Gdyby używać tylko dodawania w 64b jest 2op/cykl, tak samo z mnożeniem oraz dodawaniem i mnożeniem. Do dodawania/mnożenia wykorzystywane są naraz tylko 2ALU i przetwarzają 64b dane w 1 cyklu
    Teraz VLIW4
    Można zrobić 4*FMA32b albo 2*FP ADD 64b albo 4* FP ADD 32b, albo 1xFP MUL 64b albo 1xFMA 64b. I tak odpowiednio do 64bit dodawania są 2ALU (jak w vliw5), ale do mnożenia i mnożenia z dodawaniem już 4. Do funkcji specjalnych są 3 (zamiast owego 5 dedykowanego).
    Czemu zatem nie mogą zrobić FMA 64b w 2 cyklach na 1ALU? Pewnie to jest ograniczenie w połączeniach ALU struktury typu VLIW. Nowa generacja non-vliw właśnie z powodu owej rezygnacji ma mieć już 2:1 zamiast 4:1 więc właśnie chyba o to chodzi.
    
    
70. Promilus (autor: Gigant | data: 20/06/11 | godz.: 15:49)
    O jakim ograniczeniu struktury VLIW pierdzielisz? Masz pojęcie o czym bredzisz? Cayman VLIW ma 4 jednostki 32bit FMA oddzielne takie same jak u Fermi... Tutaj nie da się zrobić 2:1 stosunku bo to jest fizycznie niemożliwe...
    
    
71. VLIW4: (autor: Gigant | data: 20/06/11 | godz.: 15:54)
    4*MUL32b
    4*ADD32b
    4*FMA32b
    
    2*ADD64b
    1*MUL64b
    1*FMA64b
    
    Widzisz to? Nie da się zrobić MULa na jednostce 32bit w 2cykle i potrzeba 4. To samo jest u Fermi...
    
    
72. @Gigant (autor: Promilus | data: 20/06/11 | godz.: 16:11)
    Sam jesteś oddzielny... Wyraźnie masz w VLIW5 starszej generacji MUL 64bit na 2ALU! To, że teraz. Wszyscy łącznie z nvidią źle piszą tylko ty dobrze, kurna to trzeba mieć zryty beret żeby tak myśleć.
    
    
73. gigant (autor: Aamitoza | data: 20/06/11 | godz.: 16:14)
    jasne, kolejna teoria wzięta z dywanu. A nvidia na stronach pisze bzduty i te bzdury podaje deweloperom którzy chcą zakupić Fermi - lecz się, ale na nogi bo na głowę zdecydowanie za późno.
    
    Nvidia jak byk podaje, że po pierwsze - stosunek SP do DP to 2:1. Po 2 podaje, że do DP potrzeba 2 cykli. Po trzecie Podaje w każdej tabence, że fermi jest w stanie w jednym cyklu liczyć 521operacji SP i 256 operacji DP jak i podają, że jeden 32rdzeniowy SM może w jednym cyklu policzyć 16 instrukcji DP. Do tego podają w tabelach dokładną moc obliczeniową dla Quadro 6000 1Tflops dla SP i 500Gflops dla DP.
    
    No tak - same zbiegi okoliczności, że wszędzie się pomylili i podają gorszą specyfikację swojego produktu ;]
    
    PS. właśnie DP w 2 cyklach to największy ficzer w fermim, bo w GT200 odbywało się w 8 o ile dobrze pamiętam.
    
    
74. Aamitoza (autor: Gigant | data: 20/06/11 | godz.: 16:51)
    ficzer to ty masz w swoim zakutej pale... gt200 miał oddzielne jednostki 64bit do DP, nie robił tego na 32bit SP ;)
    
    a do zrobienie 64bit Mul na 32bit jednostce potrzeba 4 cykli tutaj nie da się zrobić tego w cykle bo trzeba pomnożyć 4 komponenty hi, low przez siebie ;)
    
    
75. Promilus (autor: Gigant | data: 20/06/11 | godz.: 16:54)
    Ale ty mi nie podawaj jak podaje Nvidia ile ma Fermi tylko udowodnij to że 64bit MUL da się wykonać w 2cykle na 32bit jednostce...
    
    
76. @all (autor: gregory07 | data: 20/06/11 | godz.: 17:44)
    Nie wiem jak wam ale mi wydaje się że gigant specjalnie tak rżnie głupa aby powkurzać innych. No chyba że nie :P
    
    
77. @Gigant (autor: Promilus | data: 20/06/11 | godz.: 17:48)
    Najpierw ty mi udowodnij, że Fermi ma 3TFLOPsy SP ;)
    
    "A Fermi multiprocessor double-pumps each group of 16 cores to execute one instruction for each of two warps in two clock cycles, for integer or single-precision floating point. For double-precision instructions, a Fermi multiprocessor combines the two groups of cores to look like a single 16-core double-precision multiprocessor; this means the peak double-precision throughput is 1/2 of the single-precision throughput." I dlatego dual thread nie działa w trybie DP ;)
    Teraz wracając do Cypressa - w trybie 64bit jest 2,5x mniej ADD czy MUL niż w trybie 32bit. 2,5 a nie 5. Stosunek 1:4 czy 1:5 wynika tylko z porównania FMA/FP MAD dla 32 i 64b.
    
    
78. gregory (autor: Aamitoza | data: 20/06/11 | godz.: 17:51)
    nie, on po prostu ma nasrane w bani ;) Wie wszystko lepiej od producentów i inżynierów ;)
    
    Giguś. a teraz poszukaj jeszcze patent na te 12 dekoderów w llano - bo skoro tam są to i patent powinien być ;]
    
    http://img0.pconline.com.cn/...655_apu03_thumb.jpg
    
    A tutaj masz slajd odnośnie zmian w llano "larger reorder and load/store buffers"
    
    I masz wyjaśnienie dla zmian w Load/Store, a nie jakieś bajeczki o 12 dekoderach.
    
    
79. ... (autor: Aamitoza | data: 20/06/11 | godz.: 17:53)
    A tak w ogóle to nowa architektura AMD teżma liczyć DP w 2 cyklach... a są tam przecież tylko 32bitowe procesory. No cholera co za kosmos, prawda? ;]
    
    
80. @Aamitoza & Promilus (autor: rainy | data: 20/06/11 | godz.: 18:02)
    Zgadzam się całkowicie z gregory07: odpuście sobie tę "dyskuję" bo widać, iż Gigant celowo was prowokuje (nie pierwszy raz zresztą).
    
    
81. Aamitoza (autor: Gigant | data: 20/06/11 | godz.: 19:16)
    czyli te niby 3 dekodery to są load store buffers? buhhahahaha Hans nierozróżnił dekoderów od buferów? buhahaha
    
    
82. Promilus (autor: Gigant | data: 20/06/11 | godz.: 19:22)
    Niezgrywaj debila. Powiedz mi dokładnie jak masz zamiar wykonać 64b MUL na jednostce 32bit FMA w 2 cykle bo o ile mi wiadomo potrzeba do tego aż 4 cykli:
    A*B= (A_lo+A_hi)*(B_lo+B_hi)= A_lo*B_lo+A_lo*B_hi+A_hi*B_lo+A_hi*B_hi
    
    ;-)
    
    
83. @Gigant (autor: Promilus | data: 20/06/11 | godz.: 19:31)
    Jakie lo, jakie hi? To nie integery kolo. Masz 52 bity mantysy, 1 znaku i 11 wykładnika. Jak ty to chcesz mnożyć? :> Po 32x32b?? :> Czyli znak, wykładnik i kilkanaście bitów pierwszego wyrażenia razy ostatnie 32bity mantysy drugiego? :P Wiesz w ogóle jak się mnoży i dodaje floaty?
    
    
84. Promilus (autor: Gigant | data: 20/06/11 | godz.: 19:38)
    To jest zaczerpnięte z patentu i tam piszą że to dotyczy zarówno integrów jak i floatów ;)
    Potrzeba 4 cykli na wykonanie jednego 64bit MULa. ;) Fermi tego nie da rady zrobić w 2 czy 1 cykle bo by musiał mieć 64bit jednostki...
    
    
85. Aamitoza (autor: Gigant | data: 20/06/11 | godz.: 19:46)
    Tłtumacz do czego służą te dodatkowe bufery i ten element przy FPU..
    
    
86. ... (autor: Aamitoza | data: 20/06/11 | godz.: 20:31)
    widzisz tam słowo "more"?
    Co do hansa, to on stwierdził, że llano być może będzie miał AVX - to było takie samo przypuszczenie co te pseudo dekodery.
    
    reorder buffor to jest to co masz tam na dole po lewej w sekcji wykonawczej, w tejże sekcji masz jeszcze dodaną sprzętową jednostkę do dzielenia jak i poszerzony sheduler, co zapewne miało wpłynąć na IPC.
    
    a tutaj wypowiedź hansa co do tych Twoich dekoderów:
    
    "2) Something what could be a new 3-way extra decoding stage in front of the FP units."
    
    Wiesz co oznacza could be? Jak nie, to się doucz. Hans tutaj zgadywał - nie wiediał jak w llano będzie wyglądać połączenie z GPU, a tak po prawdzie to praktycznie nie istnieje. - jedynie przez NB. Tak samo zgadywał, że llano może miec wsparcie dla AVX.
    
    
87. Aamitoza (autor: Gigant | data: 20/06/11 | godz.: 21:05)
    Nie wieże, że ktoś taki jak Hans który siedzi w projektowaniu chipów od lat nie potrafi rozróżnić dekoderów od buforów...
    
    Powiedz dokładnie do czego służą te bufery i ten link fusion compute bo widze że sam nic nie wiesz a cwelujesz...
    
    
88. heh (autor: Gigant | data: 20/06/11 | godz.: 21:12)
    Reorder bufer jest 2x większy, widać 3 dodatkowe dekodery, AMD coś pieprzy o fusion compute linku a ty nadal debila zgrywasz że llano nie będzie dopalany...
    
    
89. co jarasz? (autor: Aamitoza | data: 20/06/11 | godz.: 21:18)
    wybacz, nie mam siły na dyskusję z idiotami.
    
    
90. ... (autor: Aamitoza | data: 20/06/11 | godz.: 21:22)
    pogadaj sam do siebie najlepiej, bo widzę, że masz niezłą schize ;) jakiś czas temu potrafiłeś z dnia na dzień zmienić zdanie i raz pisałeś, że bulldozer to killer, innym razem, że to 2 bobcaty i robi 2 instruckje, a jeszcze dużo wczesniej napierdzielałeś jak katarynka, że bulldozer ma 8 instrukcji na takt.
    
    Więc serio proponuję udać się do szpitala, bo ta Twoja alternatywna rzeczywistość zaczyna ostro nawalać i fermi zaczyna w niej mieć 3Tflopsy mimo, że nvidia podaje inne dane ;] - no tak, ale co oni wiedzą - gigant wie lepiej ;]
    
    ps. reorder buffor nie jest 2x większy, tylko poszerzony z 3x24 do 3x36. - więc o połowę większy.
    
    
91. @Aamitoza (autor: Promilus | data: 20/06/11 | godz.: 21:24)
    Ja to mam nadzieję, że DYD w końcu pozbawi kolejnego trolla możliwości trollowania.
    
    
92. Aamitoza (autor: Gigant | data: 20/06/11 | godz.: 21:28)
    Ty masz shize pajacu...
    Udowodni, że te bufery to nie dekodery jak potrafisz...
    
    
93. Promilus (autor: Gigant | data: 20/06/11 | godz.: 21:29)
    Udowodnij że Fermi może wykonać operacje mnożenia 64bit w dwóch cyklach na jednostce 32bit...
    
    
94. Napisałem (autor: Gigant | data: 20/06/11 | godz.: 21:37)
    do Nvidii, zobaczycie trolle kto miał racje...
    
    
95. Gigantyczny Troll (autor: pomidor | data: 20/06/11 | godz.: 21:44)
    wymęczył swoich rozmówców. Właśnie widzicie jak działa rasowy trol. Wejście z nim w dyskusję to gwarancja nerwicy. Umiejętnie prowadzi pseudo-merytoryczną rozmowę, aby żerować na czyjejś dobrej woli w wyjaśnieniu tematu.
    Systemowe ignorowanie takich osobników, to najlepsze remedium.
    
    
96. @pomidor (autor: Promilus | data: 20/06/11 | godz.: 22:12)
    Gdybyż, och gdybyż TPC miało "ignore user" ;)
    
    
97. @dyskusja (autor: popierdulka1234 | data: 21/06/11 | godz.: 08:59)
    jak się omija co któryś komentarz to nawet da się ją przeczytać, choć wychodzi chaos, gigant ciszej,
    odpiszą ci to nas uświadomisz,
    podziękował