57
-
who am I 7 #1 dez ébresztő!!!!izgatottan várjuk a teszteredményeket! ne aludj LOL 
-
Rolesz #2 
-
dez #3 Hát te teljesen kész vagy. 
Kicsit több értelme lett volna, ha leírod, hogy kedvenc Inteled is hasonlón dolgozik, a Nehalem kapcsán. (Ha nem is elsők az innovációban, legalább felismerik mások jó ötleteit.
)
Cikkhez: "A GPGPU, vagyis az általános célú grafikus vezérlő" - Ebből most biztos mindenki pontosan megértette. :) Kicsit "rávezetőbb" lett volna így fogalmazni: grafikai feldolgozó egység. De amúgy sem ártott volna 1-2 szóban leírni a "most bekapcsolódoknak", tulajdonképpen miről is van szó, mert így kcsit semmitmondó. Tehát hogy a GPU-k bizonyos műveletekben sokkal hatékonyabbak, mint a CPU-k, és ezt nem csak grafikai műveletekben lehet kihasználni. És ezen alkalmazások számára optimálisabb, ha a CPU és a GPU közelebbi viszonyba kerül, mint eddig volt. És hogy mik ezek az alkalmazások: sokféle jól párhuzamosítható, nagy számítási kapacitást igénylő művelet, pl. video- és hangfeldolgozás, különféle tudományos számítások, stb. -
dez #4 Ja, egyébként meg a GPGPU annyit tesz: a GPU általános célokra való felhasználása. -
BlueGold #5 Ez tényleg tök jó újitás 
lenne, ha az Intel nem probálkozott volna már ilyennel a Pentium III.-as korszakban ( emlékeim szerint "Timma v. Tinma" volt a cucc fejlesztési kódneve). De akkor valamiért törölték a projecet, ha az AMD most feléleszti akkor gondolom rendelkezik a hozzá való licenszekkel.
-
#6
Nem is próbálkozott. Az egy egy összeépített cpu és gpu lett volna, amelyek külön külön dolgoznak, egyik sem segít be a másiknak. Szal egy cpu és egy gpu egy chipen, röviden egy nagy semmi. -
dez #7 Akkoriban kb. semmi hasznát nem vette volna egy nem-grafikai program egy GPU-nak, mivel azok akkoriban nem, vagy nagyon egyszerűcske, grafika-célorientált programokat (shadereket) voltak képesek futtatni. Szóval nem hinném, hogy ilyen célzatú volt a dolog... Itt egy kissé másról van szó. -
dez #8 Egyébként Timna volt a neve, és feljesztési nehézségek miatt törölték. link Nem csak grafikus vezérlőt, hanem memória-kontollert, és egyéb eszközöket is integráltak volna, egy un. system-on-a-chip chipet létrehozva. Amik egyébként léteznek más platformokon.
A Fusionnak egyébként nem kell feltétlenül egychipesnek lennie. Először két tokos rendszer lesz, majd egy tokban két lapkás, és csak még később egy chipre integrált. Szal nem ez a lényeg benne, hanem a CPU és a GPU szorosabb, és nem csak grafikai célzatú összedolgozásra "szoktatása". -
T0nk #9 "egyfajta speciális CrossFire technológia" = HypertTransport?
Ennek lenne értelme. Megvan minden technológiájuk hozzá.
Meglátásom szerint még mindig az lenne szép, ha egy többfoglalatos alaplapra lehetne pakolni különböző procikat, az alaplapon meg ott lenne egy buta framebuffer memória, meg egy DVI kimenet. -
haxy27 #10 A licenszük is megvan hozzá mivel megvete az ATI Radaont -
L3zl13 #11 Több foglalat nagyon sok helyet foglal.
-
L3zl13 #12 A hírhez kapcsolódóan. Ott látok buktatót, hogy ha jól vettem ki máshogy kell rá programokat fejleszteni/optimalizálni. Saját fejlesztőplatform meg hasonlók.
Ez célfelhasználásnál nem gond (talán csak fordító kérdése), de általános PC programoknál (pl játékok) lehet, hogy nem foglalkoznak vele a fejlesztők, és mehet az egész a kukába. -
Abu85 #13 Nem veszed figyelembe, hogy nincs más lehetőség.
A teljesítmény növelésére a legkézenfekvőbb az órajel emelése, csak annak is megvannak a határai. Az IPC növelése is csak időlegesen járható, sok függőség esetén nem lehet túl nagy. Innentől kezdve kilőttük a legjobb lehetőségeket, így érdemes kutatni a kevésbé jók után. Több magos CPU-k bevezetése, életképes ötlet, de mivan akkor ha nincs két szálnál több a programban, akkor hiába van 8 magos procink. Meg ugye ezt sem könnyű programozni, így logikus lépés a célprocesszorok integárlása. Ez remélhetőleg kitart addig amíg valamelyik fejlettebb architektúra képes lesz az x86 emulálására. -
wOlFbYTe #14 Fordítóról van szó, tehát az ártalad tetszőleges nyelvben legyártott programkód architektúrára való illesztését elvégző eljárásról.
Egyszerűen fogalmazva:
Te továbbra is ugyanúgy fejlesztesz - külön CPU- és GPU-specifikus kódrészleteket írhatsz, ahogy eddig. De maga a fordító ebből olyan alkalmazást épít fel gépi kóddal, amely ezeket a rutinokat a megfelelő feldolgozó egységen futtatja, hatékonyabban managelve az erőforrásokat. -
wOlFbYTe #15 *általad -
L3zl13 #16 Már többször láthattuk, hogy egy elvileg jobb technológia elbukott a rosszabbal szemben, mert a piac nem ált mellé.
Attól tartok, ha az intel nem ilyen megoldást választ, vagy éppen ilyet választ, de nem lesz kompatibilis, akkor az AMD ötlete bukni fog, mert a fejlesztők a nagyobb piaci részesedésre mennek rá.
Nem fogják a programokat külön AMD-s és Inteles változatban is kiadni. Vagy hanyagolják az egész optimalizációt, és így a platform rendszer nem hoz semmi sebességbeli előnyt, vagy az Intel megoldására optimalizálnak. -
L3zl13 #17 Igen, és ugye tudjuk mennyire hívei a cégek a nyilt forrásnak, hogy mindenki lefordíthassa a saját platformjára a programot.
Tehát továbbra is érvényesek a #16-ban elmondott dolgok. -
#18
Lehetek egy kicsit skeptikus? Kibirja az AMD 2010-ig?? -
L3zl13 #19 Tőlem akár szeptikus is lehetsz. Kibírja.
Sokkal rosszabbul is állt már ennél. -
Su0my #20 Mindenesetre végre egy előre mutató fejlesztés! Hajrá AMD (még ha inkább inteles is vagyok :) ). Mondjuk kicsit érdekes lesz, hogy 10 GB-os gépek lesznek: 8 a 'CPU'-nak, 2 a 'GPU'-nak:). Meg kíváncsi vagyok egy hibrid megoldás árban hova lesz pozícionálva (GPGPU, tehát lényegében egy videókari+proci szintjére? nyilván kivéve videokarinál a kártya és a RAM költségét -> ami meg alap áránál viszajöhet :D)
L3zl13: érdekes lenne a helyzet, ha az intel mondjuk jó háromnegyed, vagy akár egy év csúszással hozná kis a saját hasonló technológiájú megoldását->ha az AMDnek sikerül egy kis előnyre szert tennie, borulhatnak ám a papírformák!
Szerintem a végső megoldás vagy az említett fordító lesz(külön AMD/intel), vagy egy közös megállapodás és egy szabvány bevezetése (utóbbi hát nem is tudom-valószínűbb-főleg, ha az intel csúszik).
Szabvány azért is kérdéses, mert ha az intel nem vásárolja fel, vagy köt egy szorosabb együttműködési szerződést az nVIDIA-val: kérdés: AMD gyárt-e intelnek ATI GPU-t, amit ők is tudnak integrálni? Egyáltalán: az nV gyárt-e majd az AMDnek? Kíváncsi vagyok, mit hoz a jövő, addig is MacBook Pro xD -
Su0my #21 már csak azért is kibírja, mert a notebook (esetleg aztali gép) gyártók szeretnek olcsóbb AMDs megoldásokat csinálni (amit aztán a vevők szeretnek megvenni:D). Meg van az AMD-nek is egy nem elhanyagolható tábora. Nem rossz procik az AMD-k, egyetlen bajuk, hogy professzionális felhasználásra NEM alkalmasak (valaki majd fogja írni, hogy amikor gyorsabbak voltak, akkor is ezt mondták: nem ettől függ). -
Abu85 #22 Az Intel az új ütemtervében már hasonló elképzeléseket láthatunk, csúnyán fogalmazva, lemásolta a Fusiont.
A keresztlicensz szerződés pont a kompatibilítás megörzése miatt jött létre, "ami az enyé az a tied is, és fordítva".
A piac választása erősen függ a Microsoft-tól jelenleg, márpedig az AMD-vel az utóbbi időben eléggé puszipajtások lettek a Redmondiak. -
Abu85 #23 A GPGPU az általános feldolgozóként használt GPU. Lényegében a shader nyelv használható bármilyen adat számítására. Speciel az R600 számítási teljesítmény 475GFLOPS, ami a mai 20-30GFLOPS-os CPU teljesítmény többszöröse. Erősen párhuzamosítot számításokra ideális a rendszer, persze előbb meg kell írni az R600-hoz megfelelő fordítókat. Egyelőre CTM felület van az R580-R600 féle GPGPU fejlesztésekre, ami nem túl egyszerű.
A GPGPU borzasztó fontos üzleti szempont lesz, mert a GPU-k gyártása és fejlesztése nem olyan jövedelmező, mint kellene. -
Abu85 #24 Itt főleg azt kellene részletezni mit értesz professzionális felhasználás alatt. Pusztán maradva az IBM PC szerver piacán, látható, hogy igen erős az AMD Opteron. Ezt főleg a kiváló Unix-os fejlesztési dokumentációinak köszönheti. A munkaállomás réteg komolyabb rendszereket igényel a megfelelő hardverek kiválasztásában nagyon sok tényező játszik szerepet. Például nyilván nem mindegy, hogy egy szerverparknak mennyi a fogyasztása, mert a villanyszámla igencsak megdobhatja a cégek költségeit.
Természetesen el is távolodhatunk az IBM PC platformtól. Láthatjuk, hogy a Sun UltraSPARC-jai, az IBM PowerPC-jei, és az Intel Itanium-jai is elterjedtek, de ezek már tényleg nagyon professzionális eszközök. Amit fontos megjegyezni, hogy a fenti három platform küzöl egyik sem tartozik az IBM PC x86 családjába, tehát nem közvetlen ellenségei az Opteron-oknak és a Xeon-oknak. -
L3zl13 #25 "érdekes lenne a helyzet, ha az intel mondjuk jó háromnegyed, vagy akár egy év csúszással hozná kis a saját hasonló technológiájú megoldását->ha az AMDnek sikerül egy kis előnyre szert tennie, borulhatnak ám a papírformák!"
Hallottál már az 3DNow!-ról? Nem lepődnék meg ha nem. Előbb jött ki, mint az SSE, sokak szerint jobb is volt, aztán kutya sem használta.
64bites kiterjesztés majdnem ugyanez. Előbb jött ki, jobb volt mint az Intel első hasonló megoldása (P4-ben lévő) mégsem játszott túl nagy szerepet a Athlon64 piacszerzésében, mert a piaci részesedés nélkül nem fejlesztenek rá -> a sebességnövelő hatása sem érvényesül.
Ugyanettől félek ennél a cuccnál is, ha nem dolgoznak össze az Intellel, és nem lesz kompatibilis a megoldásuk.
nVidia viszont kapásból beperli őket ez esetben szerintem, mert számára ez a halált jelentené. -
Abu85 #26 A legtöbb fejlesztő azt használja ami mindkét rendszerben elérhető. AZ AMD inkább az Intel magatartása miatt nem szerzett nagyobb piaci részesedést.
A 64bit-es címzést azért kellett bevezetni, mert a 32bit-es címzés nem képes 4GB-nál több fizikai memóriát kezelni. Az Intel lényegében az AMD 64bit-es megoldását használja, a keresztlicensz szerződé értelmében jogot formált rá.
AZ nV szerepe egyelőre kétes, de van egy szép Via nevű cég akinek megvannak a megfelelő licensszei, így még az is lehet, hogy egy bevásárlással az nV is elkezd valami fusion féle rendszert fejleszteni. Bár nagyobb esély van rá, hogy teljesen áttérnek a chipset fejlesztésre, legalábbis jelenleg nagy erőltetik ezt a területet.
Őszintén szólva én nagyon örülnék egy szép kis háromszereplős piacnak. -
shabba #27 Az Intel szerintem teljesen más irányba indult el GPGPU terén, inkább a Cell-hez jobban hasonlító irányba indult el a számítási teljesítmény növelése érdekében. Azok a fejlesztések meg már jó pár éve folynak, jóval az előtt hogy az AMD és az ATI egyesült volna.
Az Intel Larrabee-járól túl sokat nem tudni, de állítólag 2009 elejére már kész termék lesz 24/32 maggal, 2010-től 48 maggal és Teraflops feletti teljesítménnyel. Mivel 2008 végén kijövő új architektúrás Nahalem natív 4 magosát az Intel erősen úgy csinálja hogy modulárisan jól összekapcsolható legyen dolgokkal. Egy lapkára integrálva mellé grafikus egység biztos lesz, de talán még egy Larrabee-t is mellé rakhatnak és máris lesz egy Cell-hez erősen hasonlító egységük. Az Intel a demonstrációi alapján grafika terén inkább a ray-trace felé kacsingat, legalábbis emlékem szerint volt valami Quake4 féle ray-trace demonstráció a tavaszi IDF-en.
Az Intel másik multi-core fejlesztése a TeraScale ami szintén több éve zajlik, hisz lassan egy éve már működő példány demonstráltak 1 teraflops teljesítménnyel, amit azóta már 2 TF-ra emeltek. Ez a jól ismert 80 magos CPU-juk. Ebből viszont az Intel elmondása szerint nem lesz később konkrét piaci termék, inkább csak fejlesztési projectnek szánják, amolyan CPU-k Forma 1-je, ahol jővőbeli technológiákat tesztegetnek, amit majd később piaci termékekbe emelnek át. Szóval a Larrabee-t követően 2010 után talán már a TeraScale fejlesztésekből is jelenik meg az azt követő generációkban.
A Larrabbe kvázi egyszerűsített x86 magokból áll, jó sokból akár 24-48-ból, a TeraScale meg VLIW magokból ami inkább az Itanumhoz köti jobban. -
eax #28 Igazabol az x86, mint architektura nem alkalmas "professzionalis felhasznalasra". -
dez #29 " "egyfajta speciális CrossFire technológia" = HypertTransport?
Ennek lenne értelme. Megvan minden technológiájuk hozzá."
Hát ja, HT, meg ugye a Torrenza platform. A nyilatkozó egyébként konkrétan CrossFire összeköttetésről beszélt (CPU és GPU között, szal nem több GPU-ról volt szó), de bizonyára valójában a HT-re gondolt. (A felsővezetők néha kicsit keverik a dolgokat. :D) (Máshol én is írtam, de itt már nem akartam túl sokat "okoskodni".)
"Meglátásom szerint még mindig az lenne szép, ha egy többfoglalatos alaplapra lehetne pakolni különböző procikat, az alaplapon meg ott lenne egy buta framebuffer memória, meg egy DVI kimenet."
A 4x4 (Quad FX) rendszer kapásból használható lenne erre, a Torrenza keretein belül. Csak le kell majd cserélni a PCIe interfészt HT-re az ide illő GPU-kon. És lőn, éppen ezt csinálják. Viszont, mivel ez elsősorban GPGPU alkalmazás célzatú lesz, nem kell külön vram, meg képkimenet sem.
Kicsit más az olcsóbb kategóriás laptopok, és talán irodai célra gyártott asztali változat. Ott továbbra is a képmegjelenítés minnél gazdaságosabb megoldása lesz a cél. (Esetleg egy high-end laptopban mindkettőre használják majd.) -
dez #30 Ezt PC-n először valószínű nem is játékok terén fogják használni, hanem ott, ahol a GPGPU alkalmazás már elindult: video- és hangfeldolgozás, (kisebb költségvetésű) tudományos célzatú számítások. Lásd gpgpu.org. Ez azt teszi optimálisabbá a CPU és a GPU közelebbi kapcsolatba hozásával, mert a PCIe buszon keresztül nem az igazi, ha sokat kell adatot cserélni. (Márpedig kell, mert a GPU csak bizonyos részfeladatokat tud igazán gyorsítani, a többi a CPU dolga továbbra is.)
Tehát, ha úgy tetszik, ez a dolog már most "támogatva van". Csak így még jobb lesz. -
dez #31 Az AMD64-nél sem úgy történt... Azt is az Intel volt kénytelen átvenni (pedig előtte szídta, mint a bokrot, mert ők az Itaniumot nyomták volna, mint új 64 bites platform az x86 helyett - kár, hogy az sem volt éppen az igazi). Igaz legtöbben ma is 32 bites Windowsokat futtatnak, azért koránt sem mindenki. -
dez #32 Azt nem igazán tudjuk, mit tervez az AMD hosszabb távon, de az első lépések igencsak hasonlítanak a két cég között. Magyarán, elsőször az Intel is valószínűleg 1db GPU-t fog a Nehalem mellé tenni, egy a HyperTransportra hajazó buszon (CSI, Common System Interface). Ez azért még elég messze áll a Cell belső architektúrájától, pl. a belső sokbites ring busztól. -
dez #33 Hát, ha az anyagiak kisebb szerepet játszanak, akkor jöhet a Power, a Niagara, és a többiek... -
saba30 #34 Aki emlékszik rá az MS Vista fejlesztése úgy indult, hogy C#- ben lesz megírva, tehát futásidőben fordul a kód az éppen aktuális harveren, az éppen aktuális verziószámú Micrsoft .NET framework-ön (ála JAVA). Aztán ment a levesbe az egész, mert nem volt vas amin elfutott volna megfelelő teljesítménnyel. Igaz itt csak maga az op.rendszer kódja fordult, és futott volna valós időben, a külsős alkalmazásoké nem.
Figyeljétek meg az MS meg fogja csinálni valamilyen szinten, implementálja a directX-et is (anno A JAVA-ba az openGL-t akarták) , rápirít a hardvegyártókra, a megfelelő C# driver-ekért és kész.
Mondjuk kicsit szkeptikus vagyok a szoftveres megoldásokkal kapcsolatban, pl.: 15 évig ment, hogy milyen jó a szoftveres multitasking, aztán mégis kellett a több mag, és meg is látszik a különbség.
-
shabba #35 Pedig a Larrabee-nek is úgy tűnik ring busza lesz, és szerintem igen sok a hasonlósága a Cellhez. lásd:
Clearing up the confusion over Intel's Larrabee
Clearing up the confusion over Intel's Larrabee, part II -
L3zl13 #36 GPGPU már játékoknál is elindult. Lásd GPU-val történő fizika számítás/gyorsítás.
Az otthoni hang és videó feldolgozás meg jóformán hasonló kategória.
Bármilyen kis költségvetésűek is, a tudományos számítási feladatok megengedhetnek maguknak egy szervert amelyben viszont már nincs sok értelme egybe épített CPU/GPU-t használni, ugyanis ott már nyugodtan lehet több különálló processzort használni. És az AMD architektúrája már most is lehetővé is teszi, hogy célprocesszorokat kössenek össze hagyományos CPU-kkal Hypertranszporton keresztül. -
shabba #37 Intel Larrabee roadmap -- who says there ain't no Santa Cores? -
L3zl13 #38 Az x64-et az intel kénytelen volt átvenni, de a lényeg, hogy egy fél-egy éves késéstől az intel részéről egy vadiúj technológiánál, ami még szoftvertámogatást, és a fejlesztők aktív közreműködését is igényli nem fog felborulni a piac. -
dez #39 Oké, de én nem is azt mondtam, hogy a Larrabee nem ringbuszos lesz, hanem azt, hogy az első lépés Intelnél is a Nehalem + CSI + 1 GPU lesz, márpedig a CSI nem egy sokbites ringbusz. :) -
dez #40 Azért tegyük hozzá, hogy a Javánál van egy előfordított, un. bytecode, amit már jóval könnyebb továbbfordítani a kérdéses platformra. Nem tudom, ilyen van-e, lesz-e C#-nél.
Multitasking: not azért a Windowsos megvalósítás nem éppen az számtech csúcsa...