Szczegóły specyfikacji mobilnych Radeonów HD 7000

1. Wydaje mi się Chelsea (autor: El Vis | data: 31/12/10 | godz.: 12:29)
   To nie miasto, a dzielnica Londynu, miasta położonego w Wielkiej Brytanii ;-)
   
   
2. no i pierwsze karty AMD (autor: Jarek84 | data: 31/12/10 | godz.: 12:38)
   gdzie szyna jest różna od 2^n bitów - więc najprawdopodobniej i w HD79xx może być o jakieś 64bity będzie więcej.
   
   
3. hiehie (autor: morgi | data: 31/12/10 | godz.: 12:43)
   Jakie to szczegoly...ploty i smuty, a ogolem mozna zastrzelic jednym, czyli kolejna seria odgrzewania kiepskiej architektury.
   
   
4. @03 (autor: arco2006 | data: 31/12/10 | godz.: 13:21)
   nigdy nie mów chop jak nie przeskoczysz.
   
   
5. @arco2006 (autor: rainy | data: 31/12/10 | godz.: 13:29)
   Najlepsze, że pisze to troll, który w każdym newsie dotyczącym AMD, odgrzewa ten sam bełkot.
   
   
6. a tak na marginesie (autor: Jarek84 | data: 31/12/10 | godz.: 14:33)
   to Turksy, Caicosy i ich mobilne wersje wychodzą chyba w tym samym okresie co SB - czyli na CES.
   
   Mnie bardzo ciekawi co AMD zaprezentuje jako HD68xx, a przede wszystkim HD69xx M
   
   
7. Mam nadzieję, że to nie będą kolejne odgrzewane kotlety (autor: SweetDreams | data: 31/12/10 | godz.: 14:39)
   to, że AMD nie ma konkurencji w segmencie "mobilnym" nie znaczy, że mają olewać klientów...
   
   
8. 1234567 :D (autor: cyferluu | data: 31/12/10 | godz.: 14:53)
   8910 :D i co wtedy?
   
   
9. kotlety to nie będą z racji chociażby nowego procesu technologicznego. (autor: Qjanusz | data: 31/12/10 | godz.: 15:24)
   To będzie zupełnie inny układ GPU.
   
   Natomiast wróżenie o następcach układów, które jeszcze nie wyszły trąci trochę ironią.
   
   jednym słowem: plotki!
   
   
10. rainy (autor: morgi | data: 31/12/10 | godz.: 16:44)
    Prawda boli, wiem ze vliw to zla architektura na przyszlosc gpu, tylko do wyswietlania grafiki z problemami.
    
    
11. @morgi (autor: lamik91 | data: 31/12/10 | godz.: 17:05)
    Debil
    
    
12. morgi (autor: arco2006 | data: 31/12/10 | godz.: 17:06)
    architektura fermi też jest kiepska w GTX 480, ale nV pokazała że w GTX 580 nie jest tak źle, to nie pitol bo AMD też może pokazać coś takiego + jeszcze proces 28nm.
    Więc czekaj i nie otwieraj japki bo kluski ci wypadają.
    
    
13. morgi z łaski swojej (autor: cyferluu | data: 31/12/10 | godz.: 17:16)
    napisz mi co cie boli w architekturze amd... dla ciebie wyśle do nich list i przekaże ci ich odpowiedz... masz jakieś doświadczenie na tym polu kolego?
    
    ja nie mam... wiec nic nie pisze o tym... chociaż też czytam rożne artykuły.
    
    Ogólnikiem każdy rzucić może, zasłyszane nazwy na wiki sprawdzić... wiec się zapytam... co nie tak z architekturą radeonów? Moim zdaniem wszystko ok... a dowodem na to jest fakt, że maja pochlebne recenzje no i są jako produkt do kupienia...
    
    słuchaj. twoje wszelkie pretensje do AMD to zupełnie jak pretensję do mercedesa że własnie taki silkim mają... i ten wlasnie silnik ci sie nie podoba... ale pomijasz fakt,że to dobry silnik a auta sie sprzedają! działają!
    
    
14. cyferluu (autor: morgi | data: 31/12/10 | godz.: 17:32)
    Co boli, to ze wybrali sztywne vliw, prostsze w sprzecie trudniejsze w programowaniu, a ich sterowniki leza, optymalizacje to latanie baboli, dziur, potrafia wszystko zmascic, polecam test cataclymow dla profesjonalistow, karty za ciezkie pieniadze, a jaki kabaraton, marketing to obiecanki cacanki, wsparcie zenada, a wykonanie dobre dla dyletantow, szkoda czasu, pieniedzy i zdrowia
    http://www.phoronix.com/...repro_history&num=8
    'While we were pleased with the FirePro driver optimizations -- that were shared between both their Linux and Windows drivers -- when we benchmarked them upon their initial availability (the first and second times), it's unfortunate that these optimizations were largely not sustained and that the optimizations the second time around seemed to largely just restore the performance after the driver's regressed from the first set of optimizations. In some cases, these optimizations this year are only putting the FirePro V8700 back to where it was originally performing in the first half of 2009.'
    
    
15. @morgi (autor: Promilus | data: 31/12/10 | godz.: 17:55)
    Jesteś tępa pałka i tyle. Uzasadnienie VLIW5 oraz VLIW4 na anandzie do poczytania, ale tępota nie wybiera, padło na ciebie więc rzucasz się wszędzie gdzie padnie AMD albo Radeon nie mając jakichkolwiek podstaw do poparcia swoich śmiałych tez.
    
    
16. morgi (autor: Gigant | data: 31/12/10 | godz.: 19:34)
    Larrrrraaaabbbeeee!!!!!!!!!!!! ;)
    
    /troll mode off... ;)
    /system shut down... ;)
    
    
17. hehe (autor: morgi | data: 31/12/10 | godz.: 19:37)
    Ostatnim i jedynym argumentem jest bluzg, a dowody to moge wklejac i tak nic to nie zmieni, bo padnie bluzg. Zwyczajna oczywistosc, latanie cataclysmami i te procenty wydajnosci to zwyczajne latanie wlasnych bledow, gdzie jest konkurent do Tesli i CUDAcznosci, tylko kilka lat czekania, moze zmiana nazwy cos zmieni i zaproszenie do software party, bo na uzyteczne aplikacje i kity to mozna czekac i obiecywac gruszki z wierzba.
    Wbic sobie do glowy i tyle.
    'The two GPUs have similar raw performance, but the flexibility of Nvidi's architecture is likely to be higher performance. Modestly complicated workloads (regardless of precision) will also heavily favor Nvidia's architecture. For instance, the caches and scalar vector lanes in Fermi can more effectively tolerate complex memory access patterns or code with little ILP. Of course, the most complicated algorithms (e.g. lots of communication or highly irregular control flow) are still best suited to a CPU, rather than a GPU'
    
    
18. Knights Ferry (autor: Gigant | data: 31/12/10 | godz.: 19:40)
    to architektura VLIW tak jak u Radeonów!
    http://download.intel.com/...burg-KnightsFerry.jpg
    
    http://download.intel.com/...s/Aubrey_Isle_die.jpg
    
    
19. morgi (autor: Gigant | data: 31/12/10 | godz.: 19:56)
    proszę cię nieskreslaj przyszłości Intela ;)
    
    AMD i Intel wybrali architekture wektorową VLIW zamiast skalarnej to chyba lepiej wiedzą co jest lepsze. Pozatym ten test co dałeś to nie Cayman. Cayman miażdży fermiego w GPGPU ;)
    
    
20. @morgi (autor: Promilus | data: 31/12/10 | godz.: 20:02)
    Podaj mi ilościowy stosunek danych skalarnych do wektorowych 4 elementowych w generowaniu grafiki... no? Czekam. Nie znasz? Pixel shader - 4 elementy (RGBA), vertex shader 4 elementy (xyzw) ale taka pałka jak ty nie zrozumie tego dlaczego i po co. To zrozum to... radeony NADAL zajmują mniej miejsca przy porównywalnej wydajności. A to zasługa przede wszystkim VLIW. Tyle że troll taki jak ty nie zrozumie nawet takich banałów.
    
    
21. @up (autor: Promilus | data: 31/12/10 | godz.: 20:03)
    I nie pierdziel o bluzgach, bo to potrafisz TY, w KAŻDYM newsie dot. AMD i ATI.
    
    
22. morgi (autor: Gigant | data: 31/12/10 | godz.: 21:05)
    rzuć jeszcze jakieś argumenty na wyższość Nvidii nad Intelem ;)
    
    
23. @morgi (autor: lamik91 | data: 1/01/11 | godz.: 05:37)
    Ty i tak bzdury piszesz :D Debilem każdy Cię nazywa więc o co chodzi ? ;>
    Mamusia piła(chlała) Tata(stary to samo) czego się można po Tobie spodziewać ? jesteś dziwakiem :) nie znasz się to się nie wypowiadaj gówno wiesz gówno zjadłeś ! proste jesteś typowym trolem TPC ! dostajesz za to kasę i spoko ale możesz od czasu do czasu coś innego napisać bo aż szkoda mi wyzywać Twoich rodziców że są takimi patałachami :D pianie z Ciebie robi sobie każdy a nie daj Boże spotka Cię gdzieś kiedyś to wtedy tragedia dla Całej rodziny :D
    szkoda że jesteś pośmiewiskiem dla całego żałosnego TPC które Cię utrzymuje ^^ jak widać lubią wkładać w gówno kasę :) przecież to świadczy o nich a my się tylko śmiejemy ^^ fudzilla ponad milion wyświetleń dziennie ... a gdzie jest TPC ? w dupie ! haha :D pozdrów niedorobioną rodzinę MORGI !! xD
    
    
24. Promilus (autor: Gigant | data: 1/01/11 | godz.: 18:25)
    Akurat morgi w tym przypadku nie mówi o grafice 3D tylko o GPGPU.
    
    Do grafiki 3D architektura wektorowa jest lepsza od skalarnej bo np. Barts z o wiele mniejszymi rozmiarami chipa pokonuje chip Nvidii GF104 o większych rozmiarach. To świadczy, że architektura wektorowa VLIW sprawdza się lepiej w grach niż architektura skalarna Nvidii.
    
    Ale oczywiście morgi o tym nie wspomina, że do grafiki jest lepsza arch wektorowa bo to jest antyfanboy AMD.
    
    
    
    Co do GPGPU to Nvidia też dostanie tam baty bo AMD specjalnie robi do tego FUSION i Bulldozera. Fermi nie ma szans na pokonanie Bulldozera gdy kod generuje małe data parallelizm ;) AMD w zalezności od tego czy kod wymaga dużego DLP czy małego będzie sprytnie przełączać pomiędzy GPU i CPU i Fermi zostanie pokonany w każdym tasku. Heterogeniczna archtektura APU zawsze będzie miała większą elastyczność od homogenicznego Fermi.
    
    Ale oczywiście morgi o tym też nie napisał ;)
    
    
25. @Gigant (autor: Promilus | data: 1/01/11 | godz.: 18:31)
    A co to ma za znaczenie? Pokaż mi gdzie typowy użytkownik kart z rodziny GF i Radeon tego używa albo wymaga? Konwerter wideo? Ano jest w obu przypadkach na całkiem niezłym poziomie. DirectCompute - również. A skoro piszemy o kartach do grafiki to nie rozumiem sensu roztrząsania spraw zw. z obliczeniowymi możliwościami, skoro sama nvidia do tej właśnie dziedziny oddelegowała nie GeForce a Tesla.
    
    
26. morgi (autor: Gigant | data: 1/01/11 | godz.: 19:44)
    Geniuszu powiedź co takiego sztywnego jest w VLIW? Trudno ci się programuje na takiej architekturze? ;)
    
    Itanium to VLIW
    Knights Ferry to VLIW
    Cayman to VLIW
    
    Intel tony kasy ładuje w projekt Terra Scale aka Knight Ferry który jest oparty na VLIW a ty twierdzisz, że to nie ma sensu ;)
    
    Promilus ma racje, że jesteś największym pośmiewiskiem tego forum bo gówno wiesz o programowaniu a próbujesz zgrywać speca nie z tego świata.
    
    VLIW to nic innego jak architektura RISC taka sama jak ma Nvidia. Nie ma żadnej różnicy w programowaniu na oba procesory bo program użytkowy napisany w języku wysokiego poziomu jest translowany do postaci assemblerowej VLIW przez kompilator sterownika.
    
    
27. Promilus (autor: Gigant | data: 1/01/11 | godz.: 21:23)
    GPGPU to przyszłość. Narazie mało wykorzystywane ale jak ruszy promocja OpenCL przez takich gigantów jak Intel czy AMD to nie ma bata ale to będzie standard.
    
    Już pomijając te wykastrowane z GPGPU GeForce to architektura VLIW i tak jest lepsza od skalarnej w GPGPU dzięki właśnie mniejszym rozmiarom samych jednostek. Wystarczy spojrzeć na same flopsy. 2.7GFlops to ponand 2x więcej niż u Tesli. VLIW to architektura lepsza zarówno do 3D jak i do GPGPU.
    
    
28. @Gigant (autor: Promilus | data: 1/01/11 | godz.: 21:38)
    Ileż to takich technologii było "przyszłością" a stanowiły tylko kolejny ślepy zaułek? Patrz co się dzieje w procach... grafiki zwiększają możliwości przetwarzania danych, lepsza obsługa równolegle wykonywanych kerneli, lepszy cache i przewidywanie rozgałęzień. Proce to więcej rdzeni, szerszy SIMD... nie widzisz? Proce nabierają cech GPU, GPU nabierają cech procy. I przyszłość będzie taka, że to się wszystko zunifikuje. Cały czas do unifikacji się dąży.
    
    
29. @promilus (autor: trepcia | data: 1/01/11 | godz.: 21:45)
    A na końcu będzie Skynet ;-)
    
    
30. Promilus (autor: Gigant | data: 1/01/11 | godz.: 23:58)
    O jakiej unifikacji mówisz? Przyszłość to jest heterogeniczne APU które przełącza pomiędzy CPU a GPU w zależności od tego czy kod ma duże ILP czy nie.
    
    Kod szeregowy najlepiej będzie działać na CPU. Kod wysoko równoległy najlepiej będzie działać na GPU.
    
    Tutaj nie ma co unifikować całkowicie CPU z GPU bo architektura stanie się mało elastyczna. Jak coś jest do wszystkiego to jest do niczego.
    
    
31. @Gigant (autor: Promilus | data: 2/01/11 | godz.: 09:42)
    O tej którą widać gołym okiem. Jednowątkowe jednodrożne CISC CPU do tego fixed units w VPU...mija czas i mamy... wielowątkowe, wielordzeniowe, wielowątkowe potokowe CPU z szerokim SIMD... a w GPU wydajne, ale nieprogramowalne jednostki wzbogacono o cache, przewidywanie rozgałęzień, konkretny dispatcher. Larrabee czy Cell to właśnie dowód na to iż to jest właśnie koncepcja przyszłości. Twoje Fusion to wg AMD w przyszłości jeden chip, mnóstwo jednostek przetwarzających, interfejs do pamięci i parę bajerków z GPU. Brak podziału na rdzenie CPU i "SIMD Cores" GPU - całość leci na jednych i tych samych jednostkach dynamicznie przydzielanych do konkretnych zadań. Obecne GPGPU i Fusion to tylko pomost do tej przyszłości bo trzeba najpierw konkretnie rozwinąć ideę przetwarzania równoległego.
    
    
32. Promilus (autor: Markizy | data: 2/01/11 | godz.: 11:10)
    i przeszkolić setki informatyków którzy piszą różnego rodzaju aplikacje żeby zaczęli z tego korzystać, bo do dziś nie najlepiej jest z wykorzystaniem wielu rdzeniu, czy możliwości 64bitów. Jak narazie mocno trzyma świat się zgodności z 32bitami, wiec jeszcze trwać to będzie.
    
    
33. @Markizy (autor: Promilus | data: 2/01/11 | godz.: 11:45)
    Po to właśnie propagowanie GPGPU i OCL... żeby się w końcu nauczyli z tego korzystać. A jak zaczną to będzie łatwiej z wykorzystaniem np. 48 rdzeniowych układów z 512bit SIMD w przyszłości.
    
    
34. @promilus (autor: Arlic | data: 2/01/11 | godz.: 13:29)
    ma więcej racji, tak było z FPU i CPU, tak było z Vertex shader i pixel shader, tak będzie z CPU i GPU.
    
    
35. Promilus (autor: Gigant | data: 2/01/11 | godz.: 17:29)
    Dalej nie rozumiesz. Całkowita unifikacja CPU z GPU jest bez sensu! Przekonał się o tym Intel z projektem Larrabee który okazał się klapą i zonkiem bo ani to dobre do grafiki 3D ani do obliczeń szeregowych.
    
    Przyszłość to heterogeniczne APU złożone z oddzielnego CPU i GPU. CPU zawsze będzie najlepsze do szeregowych obliczeń a GPU do równoległych. Jak zuunifikujesz oba układy to stracisz na wydajności.
    
    
36. Gigant (autor: Markizy | data: 2/01/11 | godz.: 17:44)
    intel do tego tematu zle podszedł, bo należało przekształcać gpu do roli jak najbliższej CPU z zaletami GPU. Oni nie posiadali GPU wiec próbowali od drugiej strony i dlatego ten pomysł spalił na panewce, chociaż najbardziej przez to że takie duże opóźnienia miał.
    
    
37. @Gigant (autor: Promilus | data: 2/01/11 | godz.: 18:51)
    Nie bajeruj. Problemem LRB było to iż w 300W konkurencja miała lepsze KARTY, i większą szczytową moc obliczeniową. Tyle, że jeśli zobaczysz sobie testy superkomputerów CPU only kontra GPU accelerated to szybko okazuje się, że z samych CPU można osiągnąć ponad 80% mocy szczytowej, a korzystając z GPU już tylko 60% Nie rozumiesz problemu więc nie dziwię się, że patrzysz tylko w tak bliską przyszłość.
    "CPU zawsze będzie najlepsze do szeregowych obliczeń" To dlaczego się idzie w ilość rdzeni? Bulldozer będzie mieć nawet do 8 modułów tj. 16 rdzeni integer. I co nowa architektura wniesie do problemów które się zrównoleglić nie dadzą? Ano zupełnie nic! Ale nadal idzie się w ilość rdzeni i ilość wykonywanych w takcie instrukcji czy przetwarzanych danych. Zapaliła się już lampka? Toż to upodabnianie proca do GPU właśnie!
    
    
38. Promilus (autor: Gigant | data: 2/01/11 | godz.: 19:33)
    Dalej nie czaisz bazy. AMD idzie z CPU w ilość rdzeni ale są to wysokowydajne rdzenie 4 way OoO z mocnym single thread do szybkich obliczeń szeregowych czy multitaskingu. W GPU masz architekture procesorów in order. Wydajność jednego wątku jest tak marna, że GPU kompletnie się nie nadaje do obliczeń szeregowych i multitaskingu. Spekulatywne wykonywanie kodu to mocna strona CPU. GPU nie ma szans z tym.
    
    
39. @Gigant (autor: Promilus | data: 2/01/11 | godz.: 19:50)
    Nie... to ty nie czaisz. Najpierw twierdzisz, że CPU jest tylko do algorytmów szeregowych zaś GPU do równoległych i taka jest przyszłość, teraz zaś piszesz o "wielordzeniowych układach z silnym 1 wątkiem". No właśnie... do algorytmów szeregowych (silnie) nie ma większego znaczenia czy są 4 potoki wykonawcze, czy też 3, czy jest 1 rdzeń czy też 16. Ale AMD nie zatrzymało się na 4 rdzeniach twierdząc, że wszystko powyżej spadnie na barki GPU - bo to jeden wielki bullshit. Przyszłość to jest właśnie połączenie ALU x86 oraz bardzo rozbudowanego SIMD Core/Stream Multiprocessor jako jednostka SIMD i FPU.
    
    
40. Promilus (autor: Gigant | data: 2/01/11 | godz.: 20:03)
    Jesteś w błędzie. Przyszłość to heterogeniczne APU złożone z oddzielnego CPU i GPU do konkretnych zastosowań a nie CPU i GPU połączone w jeden. Intel się już przejechał na tym. Jak połączysz CPU z GPU to stracisz na elastyczności i wydajność. Do zadań równoległych najlepiej mieć proste procesory strumieniowe inorder a do zadań szeregowych wysokowydajne spekulatywne CPU i takie rozwiązanie jest najwydajniejsze.
    
    
41. @Gigant (autor: Promilus | data: 2/01/11 | godz.: 20:22)
    "Jak połączysz CPU z GPU to stracisz na elastyczności i wydajność"
    Bzdura. Knights Corner i Cell BE to dowód na to, że można zrobić wydajnie i elastycznie. Przejrzyj jeszcze raz dokumentację.
    "Do zadań równoległych najlepiej mieć proste procesory strumieniowe inorder"
    Bzdura. Rozejrzyj się po rynku HPC - nigdzie nie ma tak jak to przedstawiasz! Nadal najczęściej są xeonki i opteronki w dużej ilości, czasem wspierane przez Celle, czasem przez inne procki, coraz częściej przez GPU. Ale nadal kręgosłup to typowe CPU. GPU nadaje się ciągle jedynie do jednej jedynej rzeczy... przetwarzania dużej ilości DANYCH (data parallelism) co cechuje (uwaga uwaga) także jednostki SIMD (128 bit w obecnej generacji, 256bit w Sandy bridge i Bulldozer, 512 bit w Knights Corner). Naprawdę, weź się i zastanów! Pierwsze doniesienia o AMD Fusion to było DOKŁADNIE to co opisałem parę komentów wyżej tj. integracja SP z ALU! SP z GPU miało robić mielić dane robiąc za jednostki SIMD.
    
    
42. Promilus (autor: Gigant | data: 2/01/11 | godz.: 21:24)
    Nie masz racji. Weźmy dla przykładu Larrabee i Llano. Larrabee to twoje zunifikowane APU a Llano to moje heterogeniczne APU. I teraz w obliczeniach szeregowych i multitaskingu Larrabee dostaje w dupe od 4 rdzeni OoO K8 bo w Larrabee masz stare Pentiumy C54 inorder. W grafice układ Intela też dostaje w dupę bo ma brak dedykowanego sprzętu do rasteryzacji grafiki. Jak widzisz twoje zunifikowane APU jest gorsze od rozwiązania niezunifikowanego.
    
    
43. Promilus (autor: Gigant | data: 2/01/11 | godz.: 21:50)
    PowerXCell 8i to heterogeniczne rozwiązanie bo ma jeden główny rdzeń PPE oraz 8 rdzeni SIMD zwanych SPE. PPE to nic innego jak CPU Power5.
    
    
44. Gigant (autor: Markizy | data: 2/01/11 | godz.: 21:55)
    jak larrabee może dostać od czegoś jak nikt nigdy go nie testował, intel przepowiadał jego wydajność i coś prezentował ale nigdy nie było tak naprawdę konkretów w tej kwestii.
    
    Wiec nie można porównać jego wydajności z niczym, bo nikt nie wiedział jak ona była poza inżynierami i zarządem intela.
    
    
45. @Gigant (autor: Promilus | data: 2/01/11 | godz.: 22:50)
    Brak fixed function rasterizera to w przypadku LRB zaleta a nie wada, bo można zaadaptować do konkretnego zadania konkretny algorytm. W przypadku fixed function jak to pokazało AMD na slajdach np. sub pixel poly powoduje mega nieefektywność ROPów. I po to ich tyle potrzeba w nowych karcioszkach. Ale to dla ciebie chyba za dużo.
    "Pentiumy C54 inorder."
    P54C i do tego zmodyfikowane na 4 wątki per core z 512bit vector unit (simd) - co ty do jasnej cholery chcesz porównać? K8 z 1 wątkiem na rdzeń i 128bit simd? Może porównaj wydajność FP64 z najsilniejszą teslą... I jak wypada to całe GPGPU ? Niezbyt rewelacyjnie.
    "PowerXCell 8i to heterogeniczne rozwiązanie bo ma jeden główny rdzeń PPE oraz 8 rdzeni SIMD zwanych SPE. PPE to nic innego jak CPU Power5."
    Kolejny błąd. PPE wywodzi się z POWER4, a nie 5. Dodatkowo ma za zadanie jedynie robić za "pasterza" - czyt. rozdzielać zadania między poszczególne SPE, dopuszczać je do pamięci i kontrolować ogólny kod programu. SPE mają jedynie przetwarzać dane. SPE bazują na rozwinieciu jednostki AltiVec procesorów POWER i PowerPC (czyli odpowiednika SIMD). Jak dla mnie jest to tylko i wyłącznie kolejny dowód na poparcie tego o czym piszę.
    @Markizy - 1.2GHz, 48 rdzeni, 512bit SIMD - tyle zasadniczo potrzebujesz żeby wiedzieć ile GFLOPS lata...460 DP i 2x tyle SP. Może dorównać Tesli? Ależ proszę bardzo!
    
    
46. Promilus (autor: Gigant | data: 2/01/11 | godz.: 23:26)
    Brak sprzętowego rasteryzatora to ogromna wada a nie zaleta bo sprzęt dedykowany jest kilkakrotnie szybszy od niededykowanego.
    
    Druga sprawa Larrabee ma z 32 rdzenie ale o wydajności wątka na poziomie Atoma. Weź sobie teraz 16 rdzeniowego Bulldozera i porównaj.
    
    Larrabee= 32 rdzenie 1way inorder 1.5GHz.
    Bulldozer=16 rdzeni 4way outoforder 4GHz.
    
    Wydajność single thread Bulldozera to z 10x tego z Larrabee.
    
    Następnie do obliczeń równoległych albo 3D weź Caymana z 2.7Tflopami to zobaczysz gdzie ten Larrabee jest. Oddzielne CPU i GPU zawsze będzie wydajniejsze niż zunifikowane gówno.
    
    
47. Jak czytam (autor: AmigaPPC | data: 2/01/11 | godz.: 23:40)
    Wasze komentarze (Promilus i Gigant) to dopiero sobie uzmysławiam w jak głębokiej i ciemnej dupie jestem ze swoją wiedzą :)
    
    DO REDAKCJI:
    Wcale nie trzeba opłacać rożnych osobników żeby robili z siebie kretynów, wystarczy dać możliwość wypowiadania się bez udziału trolli (morginalni i przydupasy).
    Czy to aż tak trudno poziom portalu podnieść ponad poziom onetu (czytaj dno)?
    
    
48. @Gigant (autor: Promilus | data: 3/01/11 | godz.: 00:22)
    "Brak sprzętowego rasteryzatora to ogromna wada a nie zaleta bo sprzęt dedykowany jest kilkakrotnie szybszy od niededykowanego."
    Tak, szczególnie jak wykorzystanie z powodu zbyt gęsteś siatki po tesselacji nie przekracza 8% szczytowej... tiaa. Tak jak MLAA vs MSAA tak i techniki rasteryzacji nie muszą trzymać się ściśle upatrzonych wzorców zaszytych w krzemie gdy można zoptymalizować algorytm i puścić go programowo. Dla LRB Intel opracował MLAA i teraz go znajdziesz na kartach AMD Radeon HD6k co samo w sobie potwierdza, że da się inaczej niż zwykle i to mniejszym kosztem.
    "Druga sprawa Larrabee ma z 32 rdzenie ale o wydajności wątka na poziomie Atoma"
    Weź jeszcze uwzględnij 512 bitowy SIMD, bo widać ciągle o tym zapominasz. I to wydajność float ma obecnie duże znaczenie, czy to HPC, czy generowanie grafiki.
    "Następnie do obliczeń równoległych albo 3D weź Caymana z 2.7Tflopami to zobaczysz gdzie ten Larrabee jest"
    To weź fermi z 1.4TFLOPS i Caymana z 2.7TFLOPS i je porównaj w typowych zastosowaniach pod OpenCL... I zobaczysz co jest gównem. Tak samo Fermi z 1.4TFLOPS nie popisze się specjalnie względem Knights Ferry... no chyba że ktoś będzie chciał pokazać peak, a nie real.
    "ddzielne CPU i GPU zawsze będzie wydajniejsze niż zunifikowane gówno"
    Opamiętaj się. Nie bez powodu wprowadzono unifikację jednostek strumieniowych. Wyobraź sobie, że poprzez unifikację udało się zwiększyć szczytową moc obliczeniową oraz efektywność wykorzystania shaderów przy jednocześnie zminimalizowanym wzroście ilości tranzystorów. A dlaczego? bo nie było idiotycznego dublowania bloków robiących to samo tylko dla innych typów shaderów. To samo czeka CPU i GPU bo po prostu MUSI. Zamiast miliarda tranzystorów (cpu) wykorzystywanego w 30% przypadków i 3mld (gpu) wykorzystywanych w 70% przypadków będzie dajmy na to 3mld wykorzystywane w 90% przypadków. Wysil wyobraźnię. Dochodzimy do kresu możliwości krzemu, inne materiały są za drogie dla typowych użytkowników. Rozwiązanie które ja przedstawiłem na chwilę obecną jest jedynym sensownym. Zamiast kupować kolejną kartę z rop, tmu itp. dodasz moduł z ramem i kolejnymi rdzeniami obliczeniowymi, reszta będzie w procu albo na płycie - razem z interfejsem do wyjścia wideo.
    
    
49. Promilus (autor: Gigant | data: 3/01/11 | godz.: 18:49)
    MLAA strasznie zarzyna wydajność o wiele bardziej spada fps niż po włączeniu MSAA.
    Pozatym nie tylko wygładzanie krawędzi są wykonywane na szaderach u Larrabee. Cały potok graficzny jest przeniesiony na barki szaderów. Kolorowanie pikseli, Zculling, ukrywanie niewidocznych krawędzi, tesselacja etc. Brak sprzętowej obsługi DX11 dodatkowo pogrąża ten układ.
    
    Cayman ma wszystko dedykowane i taki Larrabee nie ma szans aby do niego się nawet zbliżyć. Larrabee by miał problemy konkurować wydajnościowo z kartami z lowendu typu HD5670 a co dopiero z highendem.
    
    Druga sprawa to wydajność w kodzie szeregowym czyli jednego wątka. To ten Larrabee by nie miał szans pokonać 4 drożne OoO rdzenie Bulldożera. W serwerach liczy się wydajność jednego wątka, multitasking. Ponad 90% aplikacji serwerowych to operacje integer , tam nie potrzeba ładować szerokich SIMD i architektura Intela by sromotnie przegrała ze 4 drożnymi rdzeniami BD zaprojektowanymi do spekulatywnym wykonywaniem kodu szeregowego.
    
    Unifikacja szaderów to kompletnie co innego niz unifikacja CPU i GPU. Szadery można zunifikować bo są to te same jednostki a CPU i GPU to kompletnie różne architektury do zupełnie odrębnych zadań. Nie da się tu ich zunifikować aby nie stracić na wydajności.
    
    Przyszłość to heterogeniczne dedykowane do konkretnego zastosowania platformy a nie zunifikowane gówno które nie jest dobre do niczego. Oddzielne CPU i GPU zawsze będzie szybsze od zunifikowanego. Intel skasował projekt Larrabee jako nieudany a ty nadal twierdzisz, że to przyszłość. LoL
    
    
50. @Gigant (autor: Promilus | data: 3/01/11 | godz.: 19:28)
    "MLAA strasznie zarzyna wydajność o wiele bardziej spada fps niż po włączeniu MSAA"
    Bzdura!
    "Cały potok graficzny jest przeniesiony na barki szaderów."
    Dzięki czemu można zaadaptować określony algorytm a nie trzymać się sztywno tego co daje krzem. Potrzeba więcej shaderów to idzie moc w shadery, więcej rop to idzie w ropy. W tradycyjnych rozwiązaniach zawsze jakaś część chipu leży odłogiem czekając na... coś innego. Nigdy nie ma tak, że każda aplikacja w jednakowym stopniu wykorzystuje ROP, TMU, SP... I tu LRB daje tą możliwość że się dostosuje, inne karty po prostu NIE MOGĄ. To jest postęp, a nie gówno jak to chciałbyś przedstawiać.
    "Brak sprzętowej obsługi DX11 dodatkowo pogrąża ten układ"
    A czym jest "sprzętowa" obsługa DX11? To wg ciebie instrukcja API leci bezp. do GPU który ją natywnie wykonuje? Nie rozśmieszaj mnie, to jest dokładnie to samo co implementacja OpenCL na danych karciochach... ot konkretnym funkcjom sprzętu przypisują przez driver konkretne funkcje softu.
    "To ten Larrabee by nie miał szans pokonać 4 drożne OoO rdzenie Bulldożera."
    To jeszcze raz zadam pytanie... czemu nie jak Cell 1-2 rdzenie do szeregowych algorytmów a do tego kilka-kilkanaście prostszych, ale konkret SIMD do algorytmów równoległych? Czy uważasz, że tam pracują idioci? Bulldozer do serwerów NIE posiada IGP. W zasadzie całe to Fusion to sprzęt z przeznaczeniem dla netbooków i notebooków. I gdzie ty chcesz do tego dokleić to heterogeniczne środowisko gdy IGP niczym szczególnym się na tle większych braci tego CPU wyróżniać nie będzie?
    "Ponad 90% aplikacji serwerowych to operacje integer "
    Nie rozróżniasz hpc od baz danych czy serwerów www, mnie to lotto.
    "Szadery można zunifikować bo są to te same jednostki"
    O RLY? Zerknij może na schematy R520 albo G71 zanim napiszesz podobne bzdury. To przed DX10 nigdy NIE były takie same jednostki.
    "Nie da się tu ich zunifikować aby nie stracić na wydajności"
    Tak się tylko tobie wydaje.
    "a nie zunifikowane gówno które nie jest dobre do niczego."
    Właśnie to jest przyszłość misiek, zestaw prostych narzędzi z których wedle uznania można poskładać to co jest akurat potrzebne. Dynamiczne zarządzanie zasobami oraz efektywne ich wykorzystanie.
    "Intel skasował projekt Larrabee jako nieudany"
    Przeczytałeś chociaż raz ich UZASADNIENIE czy dalej będziesz pierdzielił bez sensu, bez ładu i składu. Nawet NV i AMD zdają sobie sprawę, że obecne metody renderingu są już z leksza do dupy i cała przyszłość to nie sztywne algorytmy w krzemie a programowe implementacje. Właśnie po to by do różnych zastosowań móc się dostosować, a nie robić pięćdziesiąt układów każdy do czego innego.
    
    
51. Promilus (autor: Gigant | data: 5/01/11 | godz.: 03:17)
    Ale zrozum, że jak dasz szadery żeby obrabiały wszystko to co robią dedykowane jednostki ROP to takie rozwiązanie będzie o wiele wolniejsze. Nie można o tak poprostu zaimplementować tego efektywnie bo do tego są stworzone specjalne jednostki. Larrabbee to układ który nie wypalił , może byłby dobry ale do raytracingu ale do obcnych gier opartych na rasteryzacji to to jest lipa.
    
    Dodatkowo architektura x86 nie jest potrzebna w układzie GPU gdzie wszystko leci w RISC. Takie rozwiązanie by tylko prądu wiele pobierało i miejsca.
    
    Sprzętowa obsługa to właśnie na poziomie hardware zarządzanie całym potokiem a nie w sofcie. Softowe rozwiązanie będzie bardziej elastyczne ale wydajność na tym znacznie ucierpi. Nie można czegoś zrobić aby było elastyczne i wydajne. Albo coś robisz dedykowane do konkretnego zastosowanie albo robisz coś do wszystkiego czyli do niczego.
    
    Szadery pixel i vertex to te same jednostki jakbyś nie wiedział. Unifikacja ich jest możliwa bo tu nie ma co unifikować. One zawsze powinny być zunifikowane już od samego początku a że producenci trzymali je oddzielnie to był idiotyzm.
    
    AMD już dawno by zrobiło układ w pełni zunifikowany. Mieli na to aż 5 lat a jak widać Llano to odzielne CPU i GPU stąd wniosek jest jasny, że przyszłość to dedykowane szybkie heterogeniczne układy a nie zunifikowane gówna.
    
    
52. oj giganto (autor: Promilus | data: 5/01/11 | godz.: 09:51)
    "Ale zrozum, że jak dasz szadery żeby obrabiały wszystko to co robią dedykowane jednostki ROP A kto tu mówi o "wszystko"? Przecież w LRB TMU nadal były fixed units bo to było nierealne by programowo zrobić filtrowanie i teksturowanie na sprzęcie o takiej mocy. Ale ROP akurat nie jest taki "power hungry" a w każdym razie nie wszystko musi być absolutnie robione fixed units. Cały czas są do GPU implementowane różne algorytmy... a to wczesnego usuwania powierzchni niewidocznych (hyper-z) a to różne implementacje AF. Lekka elastyczność tu i ówdzie pozwoliłaby na poprawki w obrębie tych algorytmów bez potrzeby opracowania nowego rdzenia.
    "Larrabbee to układ który nie wypalił , może byłby dobry ale do raytracingu ale do obcnych gier opartych na rasteryzacji to to jest lipa"
    LRB nigdy nie tworzony z przeznaczeniem na rynek użytkowników domowych.
    "Dodatkowo architektura x86 nie jest potrzebna w układzie GPU gdzie wszystko leci w RISC"
    Nikt nie pisał, że jest inaczej.
    "Takie rozwiązanie by tylko prądu wiele pobierało i miejsca"
    Ale LRB na każdym rdzeniu mogło odpalić soft x86 którego jest mnóstwo, a GPU nie mogą.
    "Sprzętowa obsługa to właśnie na poziomie hardware zarządzanie całym potokiem a nie w sofcie.'
    Mylisz się. Masz karty które obsługują naraz DX6, 7, 8, 9, 10, 11 i wszelkie odmiany OpenGL. Czy potok tych wersji API jest taki sam? Czy zawsze nowsza wersja to dodanie tylko kilku stopni, funkcji, elementów? Nie. A jednak wszystko działa na jednym sprzęcie. To co widzisz na slajdach jako "potok renderingu DX11" nie ma bezpośredniego przełożenia na to co jest w środku GPU. Ma bezpośrednie przełożenie na to co oferuje sterownik. I właśnie dlatego taki Cypress w obecnej chwili oprócz obsługi OGL 4.1 oferuje jeszcze szereg rozwiązań, które MOŻE znajdą się w nowym DX, ale nawet jeśli to Cypress z nowym DX i tak nie będzie kompatybilny.
    "Albo coś robisz dedykowane do konkretnego zastosowanie albo robisz coś do wszystkiego czyli do niczego"
    Ależ już to masz w GPU od 4 lat! Te same ALU to liczenia pikseli, wierzchołków, odkształceń, AI, fizyki, filtrowania wideo itp. itd. I wiesz co? Nadal zwiększają ich liczbę :] Nadal zwiększają ich elastyczność. Kosztem (ogromnym) tranzystorów... a wydajność także rośnie. Jak i możliwości.
    "Szadery pixel i vertex to te same jednostki jakbyś nie wiedział"
    http://www.beyond3d.com/content/reviews/27/2
    Strona dalej jak wyglądał pixel shader. Dalej chcesz się kłócić? W Radku 8500 różnice były jeszcze większe. Ale co ci będę tłumaczył jak masz już swoją własną teorię to po co ci fakty.
    "AMD już dawno by zrobiło układ w pełni zunifikowany. Mieli na to aż 5 lat a jak widać Llano to odzielne CPU i GPU stąd wniosek jest jasny, że przyszłość to dedykowane szybkie heterogeniczne układy"
    Art. pclab 2008r bodajże, weź i poszukaj. Poszukaj i poczytaj.
    Kiedyś FPU x87 było odrębną częścią i najczęściej nikt go nie miał. Później stało się elementem CPU, ale... MA SWOJE ROZKAZY (i rejestry). W superkomputerach stosowano procki wektorowe a że był taki trend to intel i amd opracowały simd do x86 co daje znów KOLEJNE osobne rozkazy i OSOBNE rejestry. Nie rozumiesz, że obok jądra x86 to 2 zupełnie oddzielne elementy są w tych nowoczesnych procach? To już jest HETEROGENICZNE gdyby tak realnie spojrzeć. Teraz powolutku wprowadzają iGP i co powiesz gdy za jakiś czas STANDARDEM stanie się obecność interfejsu do grafiki + kilkudziesięciu/kilkuset ALU, a Intel i AMD dodadzą do tego kolejny zestaw instrukcji bazujący na wektorach dajmy na to 1024bit? AMD raz się udało zmodyfikować standard (x86-64), ale drugiej szansy nie dostało (SSE5) więc muszą się z intelem dogadywać w ramach rozwoju platformy. I dlatego AMD nie mogło ot tak zrobić przenikania jednostek IGP oraz x86 + nowych rozkazów bo by ich intel uwalił. Ale to nie znaczy, że takie coś się nie zdarzy wcale!