Daily Tech - AMD je na tiskovni konferenci v San Franciscu predstavil sistem, ki je sposoben izvesti bilijon operacij s plavajočo vejico na sekundo - 1 teraflops. V sistemu, ki se ponaša s približno 10-krat višjo zmogljivostjo kot trenutno najzmogljivejši strežniki in delovne postaje, se je potila naveza dvojedrnega Opterona in dveh R600 <i>stream</i> procesorjev (glej tudi GPGPU). Eno izmed prvih praktičnih uporab stream procesiranja je ATI demonstriral ( 1, 2) z uporabo Radeona X1900 pri obdelavi podatkov projekta Folding@Home.
Pri AMD menijo, da je predstavljen sistem pomembni mejnik na poti do radikalne pospešitve izvajanja specifičnih aplikacij, predvsem na področju poslovnih in znanstvenih analiz. Prav tako se lahko pospešitev, ki jih prinaša stream procesiranje, veselijo tudi zagrizeni igričarji, saj bi v multi-GPU sistemih ena od kartic lahko prevzela vlogo pospeševanja fizike v igrah.
Uradno poročilo na AMD.com in novica na Dailytech.
Novice » Procesorji » AMD predstavil "Teraflop-in-a-Box" sistem
Brane2 ::
Zanimivo je, da je AMDjev sistem "Close To The Metal" za programiranje GPUjev "kao" odprt, vendar ne najdem nič pametnega o njem niti z Googlom, nVidia-in "zaprt" sistem "Cuda" pa najdeš že na osnovni strani nVidie.
Mislim, mogoče je čas za AMD da "malo smanji" PR nabijanje in kaj pokaže. Njihov "developer portal" je tud ena živa žalost.
Propagirajo ene kao odprte sisteme a kadarkoli rabiš podatke o takem sistemu, so "classiifed".
Jebeš tako odprtost.
Odprti so ene toliko ko Teheran za prašičjerejo.
Mislim, mogoče je čas za AMD da "malo smanji" PR nabijanje in kaj pokaže. Njihov "developer portal" je tud ena živa žalost.
Propagirajo ene kao odprte sisteme a kadarkoli rabiš podatke o takem sistemu, so "classiifed".
Jebeš tako odprtost.
Odprti so ene toliko ko Teheran za prašičjerejo.
On the journey of life, I chose the psycho path.
Senitel ::
Med NV CUDA in AMD CTM je nekaj hudo velikih razlik. CTM, čeprav načeloma naj bi obstajal nek virtual machine vmes, je za vsak GPU drugačen (torej CTM za x1900 je drugačen kot ta za R600). CTM niti ne omogoča uporabe teksturirnega hardware-a na GPU-jih za dostop do pomnilnika. CUDA pa bo v zasnovi ostala enaka tudi v prihodnjih generacijah GPU-jev. Je pa stvar še vedno precej "work in progress". CTM pa vprašanje kolk bo sploh public v svoji sedanji obliki...
Brane2 ::
Saj to je lahko cool.
Če bo folk hotu vmesni layer, se bo že zmenu zanj. Sedaj, ko še vsi ne vedo točno kaj hočejo, je fajn, da ima folk dostop do registrov.
ČE ti kaj ni všeč, lahko vedno napišeš nek wrapper za tako stvar, ki bo določen del razlik skril pred userjem.
Če bo folk hotu vmesni layer, se bo že zmenu zanj. Sedaj, ko še vsi ne vedo točno kaj hočejo, je fajn, da ima folk dostop do registrov.
ČE ti kaj ni všeč, lahko vedno napišeš nek wrapper za tako stvar, ki bo določen del razlik skril pred userjem.
On the journey of life, I chose the psycho path.
Brane2 ::
je pa, kot sem videl na brzino Cuda precej nefleksibilen. Imaš rutine za to, kar si je tam nekdo mislil da rabiš, in to se vrti okrog premetavanja matric in Fourierja v glavnem. Če rabiš kaj drugega, you're screwed.
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- spremenil: Brane2 ()
Brane2 ::
Sem glihkar snel ATIjev "CTM guide". VERY interesting...
On the journey of life, I chose the psycho path.
Senitel ::
Cuda definitivno ne zna samo matrik premetavat in fourierja premlevat... CTM ne zna niti tega. 
Brane2 ::
Po moje računajo na to, da si bodo akademiki in ostali že sestavili sami rutine, ki jih rabijo in da bodo te knjižnice nekakšna odprta koda...
On the journey of life, I chose the psycho path.
Senitel ::
CTM je bolj "ASM", CUDA pa bolj "C"... Akademiki se po mojem nimajo časa ugotavljat kako najhitreje napisat množenje matrik najprej za X1900 potem pa še za R600. Po drugi strani je CTM zgolj okleščen del low level API-ja in ker "virtual machine" (driver) pri tem ne počne nič kaj pametnega, bo med današnjim CTM na X1900 in CTM na R600 velika razlika. Za CUDA pa ima G80 dejansko nek nivo strojne podpore (shared memory,...) in cel kup threadinga.
V bistvu je CTM zgolj Direct3D ali OpenGL okleščen vseh grafično specifičnih stvari, CUDA je pa dosti več.
V bistvu je CTM zgolj Direct3D ali OpenGL okleščen vseh grafično specifičnih stvari, CUDA je pa dosti več.
Brane2 ::
Sem prršu do ene pol specifikacij, pa se mi ne zdijo napačne. Že zdaj vidim 1001 način, kako bi to ponucal.
Če dobim dostop do SW, grem takoj po enga Radeona.
IMHO ni nič narobe z ASM pristopom in tisti ki res rabi performanse, bo že napisal/predelal/optimiziral SW. Saj stranke za Teraflop mašine najbrž ni folk, ki nima za sendvič...
Če dobim dostop do SW, grem takoj po enga Radeona.
IMHO ni nič narobe z ASM pristopom in tisti ki res rabi performanse, bo že napisal/predelal/optimiziral SW. Saj stranke za Teraflop mašine najbrž ni folk, ki nima za sendvič...
On the journey of life, I chose the psycho path.
Brane2 ::
Sploh pa, kar se wrapping asm-a v C tiče, ne vidim take izrazite prednosti Cuda. Je pa tudi res, da sem stvari samo na brzino pogledal in ne kaj dosti globoko dojel...
nekdo to mora narediti in ni veliko razlike o to delajo stranke in imajo neko OS osnovo ali pa to dela nVidia.
Vsak pristop ima prednosti in slabosti. nVidia ima dokaj dobro podprte grafične z driverji, a to tudi stvari za katere so bili drivberji dolgo časa slabi, vsaj na linuxu.
Recimo za nForce Pro čiperaj. Pa ni bili zanje zadosti podatkov za OS driver in stranke niso mogle kaj dosti.
Tu pa je problem obrnjen. Pač AMD/ATI ti daje osnovo a če hočeš kaj več, bo treba to ali razviti sam ali plačati.
Vprašanje samo, kaj ti bolj ustreza.
Saj tudi OS world ni brez optimiziranih driverjev. Recimo samo matematične rutine za fortran so en tak primer (wmp ?). Zoptimiziran do nezavesti in skrajno picajzlast okrog verzije Cja, pa še česa.
nekdo to mora narediti in ni veliko razlike o to delajo stranke in imajo neko OS osnovo ali pa to dela nVidia.
Vsak pristop ima prednosti in slabosti. nVidia ima dokaj dobro podprte grafične z driverji, a to tudi stvari za katere so bili drivberji dolgo časa slabi, vsaj na linuxu.
Recimo za nForce Pro čiperaj. Pa ni bili zanje zadosti podatkov za OS driver in stranke niso mogle kaj dosti.
Tu pa je problem obrnjen. Pač AMD/ATI ti daje osnovo a če hočeš kaj več, bo treba to ali razviti sam ali plačati.
Vprašanje samo, kaj ti bolj ustreza.
Saj tudi OS world ni brez optimiziranih driverjev. Recimo samo matematične rutine za fortran so en tak primer (wmp ?). Zoptimiziran do nezavesti in skrajno picajzlast okrog verzije Cja, pa še česa.
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- spremenil: Brane2 ()
Senitel ::
Se mi zdi, da se še vedno ne razumeva glih dobro... 
V CUDA lahko narediš vse kar lahko narediš v CTM, obenem pa ima zraven še hudo optimizirane algoritme za splošne probleme numerične matematike. Če si tolk brihtna glavca, da ti rata spisat algoritem, ki v O(n^2) zmnoži dve matriki lahko brez problema ta svoj algoritem uporabljaš namesto tistega, ki je že v CUDA (razreda BLAS3). Seveda če imaš neke specialne matrike boš verjetno izrabljal njene lastnosti in v tem primeru pač moraš napisat zadevo sam.
ASM in C sem dal v narekovaje z namenom. To niso niti približno CPU-ji, pa že pri CPU-jih ASM ni tolk "close to the metal" kot večina ljudi misli. Tako pri CTM kot CUDA so ti programčki v bistvu shaderji (od tod tudi omejitev 512 ukazov v trenutnem CTM) in če misliš, da hardware izvaja to tako kot mu ti ročno zabičaš ko mu daš ASM shader v D3D9, se hudo motiš. In tako pri CTM kot CUDA gredo ti programi čez driver, ki jih bo optimiziral kakor ve in zna. In kakor koli obrneš, ne moreš vedet več kot driver. Zato ker 1. je cel kup detajlov skritih in 2. ker marsikaj zavisi od samega "stanja" v katerem se GPU nahaja. Celo sami arhitekti teh GPU-jev zelo zelo težko posekajo te low level compilerje (iz "ASM" v samo mikrokodo) in še v tistih primerih, ko jih je pridobitev zelo minimalna (to je bistveno drugače kot pri CPU-jih).
Občasno naletiš kje na kak članek kako na kakšnem CPU-ju naredit nekaj hudo hitro v ASM, kjer je ročno napisna koda npr. bistvno hitrejša tudi od tiste, ki jo generira Intelov compiler. V svetu GPU-jev tega ne počne nihče več.
Vse hude pohitritve pridejo iz izboljšav zahtevnosti algoritmov samih in ne z low level optimizacijami.
P.S.: Možnosti za uporabo stream processinga je seveda ogromno... Priporočam da vseeno malo pobliže pogledaš CUDA, konec koncev imaš vse kar rabiš dostopno.
V CUDA lahko narediš vse kar lahko narediš v CTM, obenem pa ima zraven še hudo optimizirane algoritme za splošne probleme numerične matematike. Če si tolk brihtna glavca, da ti rata spisat algoritem, ki v O(n^2) zmnoži dve matriki lahko brez problema ta svoj algoritem uporabljaš namesto tistega, ki je že v CUDA (razreda BLAS3). Seveda če imaš neke specialne matrike boš verjetno izrabljal njene lastnosti in v tem primeru pač moraš napisat zadevo sam.
ASM in C sem dal v narekovaje z namenom. To niso niti približno CPU-ji, pa že pri CPU-jih ASM ni tolk "close to the metal" kot večina ljudi misli. Tako pri CTM kot CUDA so ti programčki v bistvu shaderji (od tod tudi omejitev 512 ukazov v trenutnem CTM) in če misliš, da hardware izvaja to tako kot mu ti ročno zabičaš ko mu daš ASM shader v D3D9, se hudo motiš.
In tako pri CTM kot CUDA gredo ti programi čez driver, ki jih bo optimiziral kakor ve in zna. In kakor koli obrneš, ne moreš vedet več kot driver. Zato ker 1. je cel kup detajlov skritih in 2. ker marsikaj zavisi od samega "stanja" v katerem se GPU nahaja. Celo sami arhitekti teh GPU-jev zelo zelo težko posekajo te low level compilerje (iz "ASM" v samo mikrokodo) in še v tistih primerih, ko jih je pridobitev zelo minimalna (to je bistveno drugače kot pri CPU-jih).Občasno naletiš kje na kak članek kako na kakšnem CPU-ju naredit nekaj hudo hitro v ASM, kjer je ročno napisna koda npr. bistvno hitrejša tudi od tiste, ki jo generira Intelov compiler. V svetu GPU-jev tega ne počne nihče več.
Vse hude pohitritve pridejo iz izboljšav zahtevnosti algoritmov samih in ne z low level optimizacijami.
P.S.: Možnosti za uporabo stream processinga je seveda ogromno... Priporočam da vseeno malo pobliže pogledaš CUDA, konec koncev imaš vse kar rabiš dostopno.
Zgodovina sprememb…
- spremenil: Senitel ()
Brane2 ::
Saj ga definitivno bom.
Sploh ker ni odvisen od blagoslova proizvajalca, ki mi bo ali pa ne bo omogočil dostop do "odprte" rešitve.
Sedaj si je Ati vzel tri dni za tuhtanje, a mi da dostop do podatkov ali mi ga ne da, prej sem pa moral dat svoje podatke in se spomnit neko štorijo za kaj to rabim...
Sploh ker ni odvisen od blagoslova proizvajalca, ki mi bo ali pa ne bo omogočil dostop do "odprte" rešitve.
Sedaj si je Ati vzel tri dni za tuhtanje, a mi da dostop do podatkov ali mi ga ne da, prej sem pa moral dat svoje podatke in se spomnit neko štorijo za kaj to rabim...
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- zavaroval slike: Brane2 ()
Brane2 ::
O.K.
Kaj v tej sliki CTM še manjka do popolne slike tega, kar je v bistvu dejanjsko na čipu ?
DPP uniti so torej pixel shaderji. Kaj je z vertex shaderji in zakaj jih v tej sliki ni recimo ?
Hudiča, jaz sem bolj "HW type of guy" ne me basat s shaderji itd, daj smi shemo ali vsaj grobo shemo strukture s podrobno shemo elementa in po parih dnevih in 2-4 litrih kave mi bo vse jasno. Ves ta matematični mumbo-jumbo mi gre na k*...
Kaj v tej sliki CTM še manjka do popolne slike tega, kar je v bistvu dejanjsko na čipu ?
DPP uniti so torej pixel shaderji. Kaj je z vertex shaderji in zakaj jih v tej sliki ni recimo ?
Hudiča, jaz sem bolj "HW type of guy" ne me basat s shaderji itd, daj smi shemo ali vsaj grobo shemo strukture s podrobno shemo elementa in po parih dnevih in 2-4 litrih kave mi bo vse jasno. Ves ta matematični mumbo-jumbo mi gre na k*...
On the journey of life, I chose the psycho path.
Senitel ::
Mnja... Jaz sem pa bolj "SW type of guy", pa še FMF-jevc za povrhu...
Vertex shaderjev v CTM ni, zato ker jih v dosedanjih čipih ne moreš prevezat na nivo pixel shaderjev. So logično povsem druga enota. Vertex shader ne more pisat po pomnilniku (ampak samo fila pixel shaderje).
Manjkajo pa tudi TMU-ji in tako po pomnilniku lahko šariš samo z "scatter read" (mimo vseh mehanizmov zaradi katerih so GPU-ji tako hitri kot so).
V bistvu imaš pri CTM kontrolo samo nad delčkom pixel shaderjev.
Na G80 so vse te enote hardwaresko identične in jih kontrolna logika dodeljuje logičnim taskom (vertex, geometry, pixel shaderji). Lahko pa G80 preklopi tudi v "CUDA mode" kjer je situacija še najbolj podobna klasičnemu multithreadingu.
Imaš kakšen primer te smi sheme?
Najprej treba najdit nekaj kar oba zastopiva. Če razložim pipeline v "multithreading way" bo kaj pomagal k razumevanju?
Vertex shaderjev v CTM ni, zato ker jih v dosedanjih čipih ne moreš prevezat na nivo pixel shaderjev. So logično povsem druga enota. Vertex shader ne more pisat po pomnilniku (ampak samo fila pixel shaderje).
Manjkajo pa tudi TMU-ji in tako po pomnilniku lahko šariš samo z "scatter read" (mimo vseh mehanizmov zaradi katerih so GPU-ji tako hitri kot so).
V bistvu imaš pri CTM kontrolo samo nad delčkom pixel shaderjev.
Na G80 so vse te enote hardwaresko identične in jih kontrolna logika dodeljuje logičnim taskom (vertex, geometry, pixel shaderji). Lahko pa G80 preklopi tudi v "CUDA mode" kjer je situacija še najbolj podobna klasičnemu multithreadingu.
Imaš kakšen primer te smi sheme?
Najprej treba najdit nekaj kar oba zastopiva. Če razložim pipeline v "multithreading way" bo kaj pomagal k razumevanju? Brane2 ::
Imaš kakšen primer te smi sheme?
Ja. To je "mi shema" ( iz "daj mi shemo" ) s tipkarsko napako...
Najprej treba najdit nekaj kar oba zastopiva. Če razložim pipeline v "multithreading way" bo kaj pomagal k razumevanju?
Počakaj najprej,d a preberem in poštekam prebrane materiale vsaj za silo...
Bom pol uprašu, kar me zanima...
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- spremenil: Brane2 ()
Brane2 ::
Hm. nVidijin Cuda je na verziji 0.8, ki naj bi bila samo za RedHat in samo za 32-bitne sisteme.
Je kaka verjetnost,d a se bo v kratkem dalo videti tudi 64-bitno verzijo ?
Je kaka verjetnost,d a se bo v kratkem dalo videti tudi 64-bitno verzijo ?
On the journey of life, I chose the psycho path.
SmeskoSnezak ::
Sam opomba: naša milijarda je ameriški bilion. Samo mi mamo tud bilijon, zatem pa še bilijardo. Kaj pa oni rečejo v tem primeru? Rajš na potence pište, se noben človek ne bo mogo zmotit. 
@ Pusti soncu v srce... @
gzibret ::
OK, ok... sedaj pa dost s temi ciframi 
Poglejte v SSKJ, če vam kaj ni jasno, tukaj pa dost debate o tem:
milijárda -e ž : tisoč milijonov
bilijón -a m : milijon milijonov
trilijón -a m : mat. tretja potenca milijona (milijon^3, op. gzibret)
kvadrilijón -a m : mat. četrta potenca milijona
Med bilijonom in trilijonom ni novega poimenovanja, ampak se zadevi reče tisoč bilijonov. Ekvivalentno je med trilijonom in kvadriljonom.
Da bo za nekaj let glede poimenovanja bitov dovolj
PS - billion (angl.) = milijarda (slov.)
edit - podčrtal prvi stavek.
Poglejte v SSKJ, če vam kaj ni jasno, tukaj pa dost debate o tem:milijárda -e ž : tisoč milijonov
bilijón -a m : milijon milijonov
trilijón -a m : mat. tretja potenca milijona (milijon^3, op. gzibret)
kvadrilijón -a m : mat. četrta potenca milijona
Med bilijonom in trilijonom ni novega poimenovanja, ampak se zadevi reče tisoč bilijonov. Ekvivalentno je med trilijonom in kvadriljonom.
Da bo za nekaj let glede poimenovanja bitov dovolj
PS - billion (angl.) = milijarda (slov.)
edit - podčrtal prvi stavek.
Vse je za neki dobr!
Zgodovina sprememb…
- spremenilo: gzibret ()
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Nove napovedi iz AMDja (strani: 1 2 )Oddelek: Novice / Grafične kartice | 9967 (7262) | RejZoR |
| » | Intel V8Oddelek: Novice / Grafične kartice | 2659 (1985) | SavoKovac |
| » | LCD televizor ogromne ločljivostiOddelek: Novice / Zasloni / projektorji / ... | 3791 (3169) | darkolord |
| » | AMD: pocenitev dvojedrnikov z 2x 1MB L2Oddelek: Novice / Procesorji | 4305 (2688) | OChack |
| » | AMD bo znižal ceneOddelek: Novice / Procesorji | 5370 (3775) | jest10 |