Intel wyśle do końca 2011 roku układy MIC 100 placówkom

1. zanim (autor: Kris1st | data: 14/04/11 | godz.: 19:26)
   intel się rozbuja to czerwoni i zieloni go zniszczą
   
   
2. @Wedelek (autor: Jarek84 | data: 14/04/11 | godz.: 19:36)
   FirePro to trochę inne zastosowania (vide Quadro), dla Tesli i Knights Ferry zestawić trzeb FireStreama - ostatni bodajże 'cyprysowaty' 9370 :]
   
   
3. Intel (autor: bumblebee | data: 14/04/11 | godz.: 19:36)
   "GPGPU zagraża rozwojowi wydajnych procesorów ogólnego zastosowania"
   APU zagraża Atomkowi, a właściwie miażdży go
   Llano zagrazi Celeronom i śmiesznym, na siłę wprowadzanym pentiumikom
   Buldożer uderzy w Sandy Bridge
   Do tego jeszcze ARMy w natarciu
   
   Intel zaczyna mieć ciepło.
   
   
4. @Jarek84 (autor: Wedelek | data: 14/04/11 | godz.: 19:43)
   Już poprawiłem to przejęzyczenie:)
   
   
5. Good (autor: morgi | data: 14/04/11 | godz.: 20:21)
   dobre wspomaganie Xeonow, ktore wraz z Itanium wspieraja rynek wart 34B$, to 2x tyle co reszta maruderow risc i x86.
   
   
6. he...he... (autor: Sandacz | data: 14/04/11 | godz.: 20:31)
   "dobre wspomaganie Xeonow" - to nie tyle dobre wspomaganie co tonący brzytwy się chwyta - wiedza ze masowe obliczenia już teraz należą do GPU więc chociaż ducha po larabee chcą do tego zaprząc... Intel jest jakieś na oko 5 lat za AMD i NV w tym temacie i stąd ta gorączka.
   
   
7. Sandacz (autor: morgi | data: 14/04/11 | godz.: 20:44)
   O Nvidii cos mozna w hpc powiedziec, bo podmontowali do Xeonow, natomiast innych gpu nie ma jak narazie.
   
   
8. to braki w wiedzy a nie przejezyczenia :D (autor: Giray | data: 14/04/11 | godz.: 20:45)
   @Wedelek
   
   
9. @Sandacz (autor: Giray | data: 14/04/11 | godz.: 20:48)
   potraktuj to jako pewien substytut renderfarmy, taka jej "domowa" wersje. Ma to duzo wieksze szanse powodzenia nic GPU, gdyz te ma sporo ograniczen i tyle tylko ze sie gubimy w marketingowym belgocie producentow tego typu rozwiazan
   
   
10. @Giray (autor: Wedelek | data: 14/04/11 | godz.: 20:59)
    A to ciekawe że wiesz lepiej niż ja:P Fakt faktem, że w pośpiechu zrobiłem błąd, który wynika z prostego faktu - o FirePro częściej słyszę/piszę. Dobrze że to wychwyciłeś, ale nie każdy błąd jest związany z niewiedzą.
    
    
11. a ja myślę że to (autor: popierdulka1234 | data: 14/04/11 | godz.: 21:08)
    może namieszać na rynku, jeśli o mnie chodzi ekstra bo wtedy walka będzie między trzema a nie dwoma producentami, jeszcze do kompletu brakuje ARMów jako energooszczędnych serwerów i była by bitwa kto więcej może jakiej dota nie widzieliśmy, dla nas lepiej bo CENA to jest to co społeczeństwo konsumcyjne lubi najbardziej
    
    
12. @Wedelek (autor: Giray | data: 14/04/11 | godz.: 21:16)
    to nie pierwszy raz :D
    
    
13. @ morgi (autor: Sandacz | data: 14/04/11 | godz.: 21:21)
    http://www.top500.org/system/10591
    
    
14. GPGPU nie zagraża CPU (autor: pomidor | data: 14/04/11 | godz.: 21:40)
    AMD rozsiewa swoje marzenia z APU, a Intel w to wierzy :) Także NV z CUDA to mały margines względem CPU. GPGPU to może 1% całego rynku i tak pozostanie.
    
    
15. hmm (autor: Alonzo Vega | data: 14/04/11 | godz.: 22:12)
    ciekawe to stwierdzenie z ostatniego zdania.. W jakim sensie oferuje wydajnośc 90% superkomputerów z listy TOP500? :D
    
    
16. Sandacz (autor: morgi | data: 14/04/11 | godz.: 22:27)
    hehe, tianhe-1 jest tez w statach, ale nie znaczy to ze liczyl, bo hd4k i hd5k do tego nie nadaja sie, moze hd6k, ktore ma niezbedne dodatki, ktore sa u Fermi, ale z tego jeszcze nie zmontowali liczydla.
    
    
17. @morgi (autor: trepcia | data: 15/04/11 | godz.: 00:27)
    Do tego, co liczy tianhe-1 akurat radki starej generacji nadają się wyśmienicie. Nie wiesz - nie pisz. Chociaż i tak jesteś idiotą i nic tego nie zmieni.
    
    
18. pomidor (autor: Gigant | data: 15/04/11 | godz.: 00:54)
    Niezagraża? to czemu Intel tak pośpiesznie robi swojego Fusiona?
    
    
19. @up (autor: rookie | data: 15/04/11 | godz.: 08:38)
    Jak ma zrobić fusiona? Z GMA? To śmieszne...
    
    
20. trepcia (autor: morgi | data: 15/04/11 | godz.: 09:44)
    Jaaasne, dlatego jest tianhe-1a wymienione radeonki na Fermi.
    http://www.top500.org/system/10587
    
    
21. @20. (autor: Mariosti | data: 15/04/11 | godz.: 12:54)
    Widać chińczycy też dali się nabrać na mit o "wyspecjalizowaniu fermi w gpgpu"... Prawda jest taka że w tej chwili radeony mają w podwójnej precyzji taką moc obliczeniową jak fermi w pojedynczej. To jest po prostu rzeź owiec.
    
    
22. @morgi (autor: Promilus | data: 15/04/11 | godz.: 13:00)
    Taaa... ktoś musiał podratować nvidię w tych ciężkich chwilach gdy Fermi najzwyczajniej się źle produkowało :P Żeby było śmieszniej Radeon HD6970 jest z 2x wydajniejszy w DP i ponad 2x w SP od tych nvidiowych wynalazków w postaci mocno krojonego GF100. Ten LOEWE jest oddany w 2010 do użytku i nikt tam nie planuje zmiany na gejforsy, bo i po co? Żeby przy okazji zmieniać zasilacze, wentyle w szafach i bezpieczniki na mocniejsze z jednoczesną regresją wydajności? :> Może morgulcu niedouczony napiszesz czemu w Tianhe-1 w ogóle pojawiły się radeony (4870X2) skoro to taki badziew, a przecież równolegle miała miejsce premiera super duper GT200 :P
    
    
23. Promilus (autor: Gigant | data: 15/04/11 | godz.: 15:59)
    GT200 w porównaniu z RV770 nie miał natywnej obsługi dual precision przez szadery. Musieli dodatkowe jednostki 64bit wstawiać do tego układu aby było DP. Stąd oczywiste, że chinole wybrali 4870 bo GT200 to była porażka... Teraz gdy się pojawił Fermi to Nvidia nadrobiła straty i zaimplementowała jednotki CUDA cores z obsługą DP stosunek 4:1 SP/SP. Zrównali się z Radeonem w DP zatem chinole podczepili się pod Fermi...
    
    
24. AMD trochę się spóźniło bo (autor: Gigant | data: 15/04/11 | godz.: 16:16)
    powinni wyskoczyć odrazu z architekrurą Caymana VLIW4 (512DP z ECC) na miejsce Cypressa i chinole by olali Nvidie...
    
    
25. @Gigant (autor: Promilus | data: 15/04/11 | godz.: 16:56)
    Miał... tyle, że przez SFU których było w GT200 niewiele (bo chyba 30). Teraz w Fermi dalej nie ma "natywnej" obsługi FP64, tak jak i u AMD. Nie ma dedykowanej 64bitowej jednostki. AMD składa 4SP w 1 64bit FMAC, nvidia przerabia FP64 w dwóch cyklach (2-4?), ale za to full speed jest jedynie w Tesli. W Quadro jest bodajże 1/4, w GF od 1/8 do 1/12 (zależnie jaki model karty). Chinole chyba się skusiły na pseudo ECC w Tesli bo nic innego tam ciekawego nie ma. Wydajność DP gorsza od radeona za 300$.
    
    
26. Promilus (autor: Gigant | data: 15/04/11 | godz.: 18:16)
    Fermi ma natywne 64bit jednostki FMAC bo niby jakim cudem ma stosunek 2:1 SP do DP?
    Jakby nie miał 64bit ALU to by musiał składać 4 32bit FMAC żeby zrobić jedno 64bit FMAC.
    
    Fermi ma też SFU które używa dla interpolacji i intrtukcji specjalnych. Cayman ma chyba usunięte jednostki SFU i wszystko na szaderach przerabia...
    
    Fermi wspiera też 32bit integer oraz ma ECC, cache L2 , wpsracie C++.
    
    
27. hmmm... (autor: Sandacz | data: 15/04/11 | godz.: 18:44)
    Morgi zamilkł... CUDA się kończą, żeby było śmieszniej to AMD w każdej chwili może powołać do życia podobny wynalazek co x86 MIC Intela bo ma licencję x86, lepsze niż intel doświadczenie nad wielordzeniowością, wymyśloną do takich celów magistralę HT, i doświadczenie przy macierzach obliczeniowych jakimi są GPU.
    
    
28. gigant (autor: morgi | data: 15/04/11 | godz.: 18:45)
    Przeciez oni nie maja platformy, to tzw. zastosowania to eksperymenty, Fermi juz jest normalnym produktem do kupienia na hpc, natomiast inne gpu poza Nvidia, musza zmienic architekture na uzywalna do obliczen, co ma sie stac w przyszlosci.
    
    
29. @Gigant (autor: Promilus | data: 15/04/11 | godz.: 18:46)
    "wpsracie C++." Blabla, tyle razy to już czytałem a nigdzie tego nie widać. To nadal jest C for CUDA tylko wzbogacone, ale pełne C++ z całą pewnością nie - tzn. nadal trzeba korzystać z konstrukcji specyficznych do GPU i wszystkich ograniczeń. Poza tym to kwestia środowiska programistycznego, a nie układu samego w sobie.
    "ma ECC" ecc-like. Z całej pamięci 1/9 bierze na ECC, żadnej dodatkowej logiki w pamięciach nie ma - to są zwykłe GDDRy. Logika jest w GPU i ma za zadanie udawać ECC na tej wydzielonej pamięci (za to L1 i L2 jest ECC jak w CPU desktopowych). W rzeczywistości nie jest to na nawet wystarczająco blisko prawdziwego ECC.
    "Fermi ma natywne 64bit jednostki FMAC bo niby jakim cudem ma stosunek 2:1 SP do DP?" Takim samym jak 128bit SSE w 64bit FPU K8 kolego. Pisałem wyraźnie - przetwarzanie w 2 cyklach. AMD grupuje 2ALU na ADD/MUL, albo 4ALU na FPMADD 64bit. U nvidii obliczenia FP64 zajmują dwa cykle.
    http://www.anandtech.com/show/2849/4
    i wszystko jasne.
    "Jakby nie miał 64bit ALU to by musiał składać 4 32bit FMAC żeby zrobić jedno 64bit FMAC"
    Bzdura. Tak by było gdyby miał liczyć 64bit inty, a nie floaty (patrz 256bit AVX w Bulldozer na 2x128bit FMAC)
    "Fermi wspiera też 32bit integer"
    No niesamowite, czyli to co AMD od HD2k? :> Chyba, że chodzi ci o coś szczególnego... np. mnożenie bez obcinania do 32bit? No to chyba Cayman też ma :) Dual DMA engine też ma... tego cache mu brakuje, ale z drugiej strony ten cache jest w grach praktycznie zbędny. A nie zapominajmy, że AMD nie zrobiło ani 1 modelu kart przeznaczonego specyficznie tylko do obliczeń.
    
    
30. Sandacz (autor: morgi | data: 15/04/11 | godz.: 18:49)
    Nic z tych rzeczy, malo tego apu nie nadaje sie do obliczen, serwerow to zwykla tania zlepka bylejakosci.
    
    
31. rookie (autor: Gigant | data: 15/04/11 | godz.: 19:06)
    No właśnie z GMA Intel robi Fusiona. Podobno GPU w IvyBridge ma mieć wsparcie OpenCL.
    Kopiują wszystkie pomysły od AMD/Nvidia.
    
    
32. Promilus (autor: Gigant | data: 15/04/11 | godz.: 23:35)
    Cayman ma wsparcie dla 64bit integer MUL?
    Jakoś nie widać tego na tym zdjęciu:
    http://www.maximumpc.com/...8/cayman_core_full.jpg
    
    Skąd masz info że Caman nie ma obsługi ECC bo czytałem, że ma wsparcie full ECC GDDR5 tak jak Fermi?
    
    O jakich dwóch cyklach FP64 mówisz? Fermi musi mieć jednostki 64bit inaczej nie darady wykonać 64bit FMAC w dóch cyklach tylko potrzebne będą czterwy tak jak w Caymani.
    
    
33. BTW (autor: Gigant | data: 15/04/11 | godz.: 23:51)
    Dlaczego AMD nie udostępnia zdjęć skanów Cypressa i Caymana tak jak to zrobili z rv770. Ukrywają coś? Cały czas mam wrażenie, że w Caymanie siedzi więcej SP...
    Dodać pół miliarda tranzystorów i cofnąć się z liczbą SP? No nie ma szans...
    
    
34. he..he.. (autor: Sandacz | data: 16/04/11 | godz.: 07:43)
    "malo tego apu nie nadaje sie do obliczen' - tak do obliczeń nadaje się tylko atom - dzięki niemu potrafimy obliczyć pozornie nieskończony poziom cierpliwości jego użytkowników, AMD APU zjada większość obecnych wynalazków intela jeśli zaprząc je do DC, za to gpu z najwydajniejszych niby CPU intela ma problem z doliczniem do 24 (słownie dwadzieścia cztery) - zaiste potężne narzędzie obliczeniowe... Śmiech na sali Morgi...
    
    
35. Intel znów pzrez AMD nie ma wyboru... (autor: Sandacz | data: 16/04/11 | godz.: 07:45)
    http://www.benchmark.pl/...zemy_USB_3.0-34425.html
    
    
36. tutaj jest najlepszy news o technologii Intela (autor: Sandacz | data: 16/04/11 | godz.: 07:52)
    http://www.frazpc.pl/...tegi-dotyczc-Androida.html
    
    i cytat: "Intel planuje wprowadzenie wsparcia dla Androida 3.0 w układach x86. Co więcej, Intel będzie płacił producentom sprzętu 10 dolarów, gdy tylko zdecydują się zastosować intelowski układ w swoim nowym tablecie. Jak widać firma jest bardzo zdeterminowana, chce w ten sposób zachęcić partnerów do wyboru własnych rozwiązań (a nie konkurencji spod znaku ARM)." - tak to oto widać co musi robić Intel aby jego technologia nie wypadła z rynku. Kolejny raz inżynierom muszą pomagać księgowi...
    
    
37. @Gigant (autor: Promilus | data: 16/04/11 | godz.: 09:32)
    A gdzie ja pisałem o 64bit MUL int? Aaa, nigdzie... pisałem o 32bx32b=64b gdzie zazwyczaj wynik jest skracany do 32bit.
    Teraz dalej... wyraźnie napisałem na przykładzie AVX oraz SSE2 w K8, że to się robi albo przez zebranie 2 jednostek i wykonaniu na nich połowy roboty, albo poprzez jedną jednostkę w 2 cyklach. W 2 a nie 4. U AMD jest podobnie. 2 proste FP32bit ALU robią FP64bit ADD albo MUL (kaigai_11.pdf) albo wszystkie 4 robią FP MADD (a teraz i FMA) FP64. Jednostki w Fermi już na poziomie FP32 obsługują FMA więc przejście na 64bit to tylko podwojenie pracy. 2 cykle. Czy do mnożenia, czy dodawania, czy mnożenia z dodawaniem.
    "Dodać pół miliarda tranzystorów i cofnąć się z liczbą SP"
    prawdziwy podwójny rasterizer, buforowanie danych do teselatora, podwójny teselator, EQAA w ROPach oraz dual DMA engine.
    
    
38. dot linka z 36 a info dla JOSEFEK (autor: popierdulka1234 | data: 16/04/11 | godz.: 13:30)
    jakby ci się nie chciało tam zaglądnąć to masz
    
    """Dodatkowo Intel chce reaktywować netbooki, wprowadzając na rynki wschodzące (Europa Wschodnia, Ameryka Łacińska, Bliski Wschód) sprzęt oparty na systemie MeeGo. Takie komputerki trafią na rynek w drugiej połowie 2011 roku. Będą to produkty takich firm jak Asus oraz Acer. Cena netbooka ma wynosić 199 dolarów. W przypadku bogatszych rynków do sklepów trafią modele oparte na platformie Cedar Trail, z WiDi oraz Wireless Music. Najtańsze będą kosztowały $299, najdroższe aż $599. Na marginesie, ciekawe w której grupie znajdzie się nasz kraj?"""
    
    wyłuszczę ci najistotniejsze """""Intel chce reaktywować netbooki"""""
    
    czyli wprowadził ale wydajność była goooowniana więć, sprzedaż padła na ryj, a dzięki brazosowi masz nową rewizję i starania producenta a dodatkowo znowu będzie fundował datki tyle że tym razem oficjalnie """""""Intel planuje wprowadzenie wsparcia dla Androida 3.0 w układach x86. Co więcej, Intel będzie płacił producentom sprzętu 10 dolarów, gdy tylko zdecydują się zastosować intelowski układ w swoim nowym tablecie. Jak widać firma jest bardzo zdeterminowana, chce w ten sposób zachęcić partnerów do wyboru własnych rozwiązań (a nie konkurencji spod znaku ARM)."""""""
    
    to tyle odnośnie kultury wobec klienta, spod znaku intela.
    
    jasno można odczytać - LUDZIE DO ŻŁOBA, UISZCZAĆ FRYCOWE
    
    
39. he..he... (autor: Sandacz | data: 16/04/11 | godz.: 20:20)
    Znów Morgi zamilkł... fakty ewidentnie zjadły mu premie...
    
    
40. Promilus (autor: Gigant | data: 16/04/11 | godz.: 21:28)
    Bullshit! Jeżeli Cayman ma współczynnik 4:1 SP do DP i ma jednostki 32bit FMA czyli jedna taka jednostka potrzebuje 4 cykli aby wykonać 64bit FMA to jakim cudem Fermi który też ma jednostki 32bit FMA potrzebuje ich o połowe mniej? A CPU K8 to co innego bo tam nie ma jednostek 32bitFMA tylko są odzielne jednostki 64bitADD i 64bitMUL zatem można mieć stosunek 2:1 SP/DP.
    Fermi musi mieć natywne 64bit jednostki FMA bo by nie dał rady złożyć 64bit FMA w 2cykle...
    
    
    "prawdziwy podwójny rasterizer"
    To ile to zajmuje tranzystorów z 10mln?
    
    "podwójny teselator"
    Ta jasne. Cypress już ma 2 tesselatory co dobrze widać w tessmarku gdzie jest na równi z Caymanem...
    
    "EQAA w ROPach"
    EQAA to implementacja softwerowa czyli to nic innego jak zwykłe dodanie algorytmu do sterów ;)
    
    "dual DMA engine"
    To też raptem z kilka miln tranzorków.
    Sorry ale ja tego 0.5mld nigdzie nie widze...
    
    http://www.cdrinfo.com/...D%206900_early_specs.jpg
    AMD nie zdecydowane co do ilości SIMD jakie mają załaczyć w HD6970?
    
    http://www.bjorn3d.com/...o/Sapphire_HD6950/01.jpg
    
    Dokładnie ten samo zdjęcie chipa pokazywali przy premierze Cypressa. Wygląda jak fothoshop Barcelony z nałożonym klastrami SIMD.
    
    
41. @Gigant (autor: Promilus | data: 16/04/11 | godz.: 22:16)
    Bullshit to masz w klozecie jak zjesz porządny obiad ;)
    Cypress ma podwójny układ do skanowania a nie pełen rasteryzator. Poczytaj. A wyniki w Tessmarku już dawno udowodniłem że to kwestia tylko i wyłącznie sterownika OpenGL4, bo tak samo w Unigine pod OGL różnic brak, a w DX11 są i to znaczące.
    "EQAA to implementacja softwerowa"
    Bullshit ;) Ty chłopcze sam nie wiesz o czym gadasz. EQAA to jest nic innego jak CSAA nvidii tylko działa w szerszej gamie gier. A skoro Fermi ma 32x CSAA czyli 2x tyle co wcześniejsze chipy to nie ma możliwości by to było "w sterownikach". To jest misiu pysiu mechanizm zaszyty w krzemie konfigurowalny (jak i teselator) z poziomu aplikacji i sterowników.
    "Jeżeli Cayman ma współczynnik 4:1 SP do DP i ma jednostki 32bit FMA czyli jedna taka jednostka potrzebuje 4 cykli aby wykonać 64bit FMA"
    Te jednostki nie robią FP64 w kilku cyklach tylko jak i w poprzednich konstrukcjach (albo Bulldozer) są składane do FP64. A najwidoczniej obcięli możliwości razem z ALU.T po to żeby się łatwiej projektowało (bo jak inaczej wytłumaczyć, że można zrobić 4ADD/MUL/FMA w 32 bitach a w 64 2ADD, 1 MUL albo 1FMA?
    "Fermi musi mieć natywne 64bit jednostki FMA"
    Nie ma. Dedykowane 64bitowe jednostki na każde 8SP miało GT200.
    "All of the pipelines in Cayman and Cypress (XYZW and T) can execute 24-bit multiply-add and 32-bit add operations. However, the entire VLIW can only execute a single 32-bit integer multiply, multiply-add, or a 64-bit integer operation" Czyli zagadka rozwiązana... konstrukcyjnie widać nie można przeskoczyć ilości różnych operacji w VLIW, natomiast same ALU dają radę tak jak napisałem wcześniej.
    "The newer VLIW4 has identical performance to the older VLIW5 - despite losing the T-unit. Both can execute 2 double precision adds, 1 MUL or 1 FMA"... dość jasne. Tyle VLIW potrafi(łby) zrobić. W RV770 np. ADD+MUL naraz (DP). A teraz techreport...
    "And each floating-point unit is now capable of producing IEEE 754-2008-compliant double-precision FP results in two clock cycles, or half the performance of single-precision math. That's a huge step up from the GT200's lone DP unit per SM—hence our estimate of a ten-fold increase in DP performance. "
    Dobrze pisałem? Dobrze.
    Aaa, EQAA nie ma Cypress, CSAA32x nie ma GT200... więc to tylko potwierdza, że to nie jest żadna implementacja programowa w sterach. MLAA tak, EQAA/CSAA nie.
    
    
42. Promilus (autor: Gigant | data: 18/04/11 | godz.: 02:53)
    Chcesz mi powiedzieć, że AMD ma zwalone sterowniki OpenGL do tessmarka i jeszcze tego nie naprawiło?
    Co takiego wymaga w krzemie EQAA, że nie da się go w sterach zaimplementować? Mów dokładnie a nie strzelasz...
    
    O jakim składaniu jednostek bredzisz? To się tylko tak mówi, że one są niby składane a tak naprawdę intrukckcja 64bit jest wykonywana przez jedną jednostkę tylko w kilku cyklach. Np. jak masz 32bit ALU FMA to żeby wykonać na niej instrukcje 64bit FMA to potrzeba 4 cykli zegara. Czyli najpierw w 2 cykle jest wykonywane dodawanie 32bitx32bit a potem w następne 2 cykle jest to mnożone przez 32bitx32bit.
    
    A Fermiego CUDA core ma 64bit jednostkę FPU inaczej nie dałby rady przeliczyć instrukcji FP64 FMA w 2 cykle i mieć stosunek 2:1 SP/DP
    
    http://www.nvidia.com/...chitecture_Whitepaper.pdf
    Tutaj to dobrze jest udokumentowane. W jednym CUDA Core masz dwie jednostki 32bit czyli jeden CUDA core może zdekodować 2 instrukcje na cykl i ma dwa porty.
    
    
43. ... (autor: pawel.xxx | data: 18/04/11 | godz.: 04:59)
    W sumie to ten układ to larrabee pozbawione funkcji graficznych. W związku z czym zmienił sie target i teraz jest to HPC i ten potencjał nie będzie dostępny dla typowego power usera.
    
    @Promilus
    W jednym z postów porównałeś wydajność fermi i układów nvidii do układów AMD. Wartości które podałeś były jak najbardziej poprawne tyle że były to wartości peek performance tych układów.
    Gdyby jednak zastanowić sie nad tym jaka jest typical performance owych układów to sytuacja nie jest juz tak jednoznaczna.
    W przypadku nvidii z jej skalarną architekturą typical = peek . Natomiast w przypadku AMD typical mieści się w zakresie 0.25-peek dla hd6xxx i
    0.2-peek dla wcześniejszych wersji.
    
    
44. @Gigant (autor: Promilus | data: 18/04/11 | godz.: 10:04)
    Dobra, dobra... to jak chcesz w 3mld (vs 1.4mld) zmieścić ponad 2x więcej SP, teselatory, multi rasteryzatory (per GPC), cache L2 (5mln+) i do tego jeszcze z 64bit FPU? cuda core clock GTX580 to 1544MHz. FMA32bit (2ops) * 512 * 1.544e+9 = 1581056, 1.5GFLOPS; dla samego dodawania jest to połowa. Dla FP64 FMA jest to połowa. Dla dodawania jest to 1/4. Zatem nie ma mowy o wykonywaniu na 1 FPU 2 instrukcji naraz. To do czego się odnosisz to pewnie równoległe wykonywanie int i float. Ale nijak nie ma się to do wydajności zmiennoprzecinkowej. Inna sprawa, w trybie FP64 nie ma dual issue warps (czyli 2 warpy nie mogą wziąć po 16cuda cores jak to ma miejsce w FP32 i int) w związku z tym raczej odpada teza jakoby co drugi cuda core miał być wyposażony w 64bit FPU. A możliwość że KAŻDY cuda core jest wyposażony w 64bit FPU to już praktycznie od początku była spalona. Jak zatem nvidia osiąga wydajność DP na poziomie połowy SP (jak w x86 simd, POWER VMX itp.) - nie mam pojęcia. Jeśli nie przez dual cycle execution (jak w K8) ani nie przez natywne jednostki, ani nie przez łączenie jednostek - to możemy wymyślać różne teorie i wszystkie będą równie (nie)prawdopodobne.
    
    @pawel.xxx - w przypadku DP VLIW jest wykorzystany w 80-100% (dla FP MADD/FMA) więc akurat porównywanie peak performance dla tego trybu jest reprezentatywne. Po prostu w realnych obliczeniach z wykorzystaniem FP64 VLIW4/5 nie może być "gorzej" wykorzystany. Co najwyżej cały SIMD może być gorzej wykorzystany, ale to odnosi się też do SM.
    "W przypadku nvidii z jej skalarną architekturą typical = peek"
    Nie jest to prawda. Peak dla FMA podałem, ale dla add już nie jest realne osiągnięcie takiej wydajności u NV. U AMD jest bo może wykonać 2DP ADD w cyklu na jednym VLIW. Zatem wcale aż tak różowo nv nie ma, o czym świadczą choćby wyniki w SHA-1 czy innych kryptograficznych zastosowaniach (z tym, że tutaj głównie inty). Z drugiej strony aż tak bardzo w takim luxmarku AMD nie odstaje, a jak odstaje to przez brak L2 r/w - jest tylko LDS, GDS scratchpad, L1 r/w L2Tex read only. W Fermi jest znacznie lepiej. Pod kątem podsystemu pamięci Cypress i Cayman ledwie dorównują G92 albo GT200.
    
    @Gigant - chcesz coś się dowiedzieć to poczytaj o CSAA bo to jest ta sama technika co EQAA. Można oczywiście to zrobić w shaderach, tylko po co skoro na przykładzie R600 widać, że takie rozwiązanie jest beznadziejnie wolne. Dlatego algorytmy i obsługa takich technik jak SSAA/MSAA/CSAA muszą być zaszyte w ROP, bo tylko ROP mogą to z rozsądną prędkością zrobić (w końcu do tego są przystosowane). Filtry postprocesowe typu MLAA/SRAA/FXAA/GPAA bazują na uproszczonej metodzie szukania krawędzi (albo czegoś co przypomina krawędzie) w już gotowej scenie więc obliczeniowo są mniej wymagające, a przy pomyślnych wiatrach dają zbliżone efekty do MSAA. Przy mniej pomyślnych pojawia się rozmycie lub brzydkie artefakty (SRAA whitepaper, zobacz jak wygląda siatka ogrodzeniowa ...)
    
    
45. Promilus (autor: Gigant | data: 20/04/11 | godz.: 20:03)
    To jak jest w końcu z tym Cudacznym CUDA core? Ma 64bit FPU czy nie? Jeżeli nie ma tam 64bit FPU to core ten musi mieć dwa oddzielne potoki 32bitADD i 32bitMUL czyli przerabia 2 instrukcje 32bit na cykl wtedy dało by się zrobić 2:1 SP/DP.
    
    A u Caymana jakie jest wykorzystanie VLIW4 w grach? Te 25% to bzdura bo AMD by się nie bawiło w robienie wektorowych jednostek jakby mieli skalarną utylizacje...