Zvlastni roadmapa resp. jeji vysvetleni, presunem GPU k CPU se vyroby CHS timto stejne nezbavi a pokud CPU propojite s GPU misto po vnejsi sbernici po vnitrni sbernici zadny vykonovy narust tim de-facto neziskate a predevsim by takovyto navrh melo hotovo nekolik vyvojaru do mesice. Takze si to shrnem, CPU+GPU v jednom pouzdre = zadny vykonostni narust(neni k nemu duvod, PCiEx16 neni brzdou), zadna tepelna uspora, naopak bude nutna zmena patice, zmena CHS, etc. Pokud GPU neni navrhovano jako programovatelny koprocesor, jak jinak si vysvetlit tak dlouhy vyvoj projectu Fusion ktery uz nyni by neznamenal zadny prinos ve srovnani s 4850e(resp. jeho alternativa v mobilnim segmentu)+780G na kterem uz vydelavaji...?;)

To: heleme, MadMaxII  Ono to prave vypada, ze se s tim piplaji takovou dobu prave proto, aby upravili jednotky v procesoru pro prime vyuzivani jadra GPU. Tj. aby z toho nemely uzitek jen 3D hry, vyhlazování videa & spol. Ale aby se daly jednotky GPU vyuzivat podobne jako napriklad SSE jednotky v procesoru... Mohlo byt prave hned neco po SSE5.
Samozrejme tohle nezvladaji nejak skokove, ale mela by to byt postupna integrace od soucasneho stavu. Tim je CPU + GPU v PCIE slotu jako Stream procesor. A hadam ze urcite jedny z nejvetsich orisku, ktere jim to protahuji, je vyuzivani nejake spolecne cache a upraveni stavajicich jednotek CPU (Fetch, Branch Prediction, Scan/Aling, Microkernel Engine) tak, aby umely obslouzit i data pro GPU.
Dokud nebude vykonavani CPU instrukci nejak interne v procesoru castecne delegovano i na jednotky z GPU, pak se neda nejaky masovy uzitek z tehle integrace ocekavat. Kdyz tohle zvladnou, pak budou mit dobrou konkurencni vyhodu. Protoze soucasny stav, kdy jsou specialni aplikace psany samostatne jen jako GPU klienty.. Tak by se asi nikdy plosne uspesnym toto reseni nestalo.
V podstate uz tohle musi AMD zvladnout, protoze nema prostor selhat v tomhle (velkem souste)... Kdyz by z toho byl uzitek mizivy, uz jde AMD o kejhak... Pak by AMD nemusel ani pripadny balik penez ze soudniho vyrovnani s Intelem stacit na nejake dalsi pokusy sestrojit neco konkurenceschopneho...
Ale hadam ze orisek to musi byt vazne slusny, protoze by to melo byt vymysleno tak, aby si to poradilo s promennym poctem stream procesoru. Protoze i grafika bude neco potrebovat, nekdy malo nekdy hodne a pokud to ma byt efektivni, tak se to musi prerozdelovat temer porad...
Stejne se to musi casem dopracovat ke stavu, kdy procesor sam o sobe se bude virtualizovany a sve vlastni jednotky z jader CPU i GPU bude pridelovat podle pravidel definovanych v microcodu. A kdyz bude nejake vlakno potrebovat velky vykon treba pro FPU, tak se mu prideli maximum volnych FPU jednotek... Tj. ze vypocetni síla jednotlivych jader bude promenliva.
No trosku vic jsem se zasnil, no ale co jineho AMD zbude:-) Ve vyrobni techlologi ma Intel naskok a penez na jeho udrzovani ma dost... Tak AMD nezbyva nez se snazit mit chytreji navrzene procesory...

v2> prave to,ze je Intel na nizsej technologii je nevyhoda

totiz teoreticke minimum kremika je 22nm(rad je 65,45,32,22 nm)
a potom treba uvazovat nad tym co dalej

45 nm system ma u intelu vrstvu izolantu o hrubke 5 molekul SIO2 a dlzke 200 molekul SIO2. AMD robi o nieco kratsie hradla jejm 65 nm ma dlzku 220 molekul a 45 nm by mala mat asi 180 molekul SIO2

techologia je vzdialenost stredov hradiel

2mike>

Presne o tom to je...

ono to speje k integracii JAVA jadra do CPU, XML parsera do CPU, GPU do CPU
http://www.tomshardware.com/picturestory/20-4-amd-fusion-processor.html

resp toto
http://www.tomshardware.com/picturestory/20-5-amd-fusion-processor.html

Ja by som tipoval, ze SWIFT pojde takto
http://www.tomshardware.com/picturestory/20-2-amd-fusion-processor.html

lebo toto je opisane ako zastarene riesenie
http://www.tomshardware.com/picturestory/20-3-amd-fusion-processor.html

>>2mike:
 
V podstate jsou dve cesty a jejich mozne kombinace, budto CPU bude mit v sobe velmi slozitou a narocnou predikci na to aby dokazal dopredu urcit co bude nasledovat a podle toho si prednastavil GPU na dane vypocty nebo v AMD/Ati maknou SW vyvojari a udelaji patche pro kompilatory vyvojovych prostredi. Ja osobne bych spise zacal druhou cestou a az postupem casu vylepsoval prerozdelovaci a predprogramovaci mechanizmy vedouci k optimalnimu vyuziti na HW vrstve(v CPU). Mimochodem pokud se koncept navrhne tak ze jednotlive casti budou samostatne muze se obejit navaznost zpracovani dat programu cyklickym zpracovanim, tj. zacne se vykonavat kod, cast kodu bude pouzitelna ke zpracovani v programovatelnem koprocesoru(GPU) skladajiciho se z mnoha samostatnych casti/jednotek a ta cast se muze dat zpracovavat nezavisle na kodu(a jeho cekani na data) a bude se v samostatne casti zpracovavat stale cyklicky, kod dojde do stavu kdy pozada o vysledek(do samostatne casti se zapise flag ze je pozadovan vysledek) a kod pokracuje dal a pozada o dalsi vysledek a zase ho dostane od dalsi cyklicky zpracovane casti(cim vice cyklickych casti/jednotek v GPU tim lepe).... Dulezite je ze to "plneni" samostatnych jednotek se odbyde na zacatku paralelne za startu/behu kodu a kod pak nebude nicim zdrzovan a jen bude prijmat vysledky s okamzitou odezvou(v nejhorsim pripade s mensi prodlevou nez dnes)...