GeForce 8800 som en vanlig CPU

[snorreh]

Det hjelper lite om man kan programmere GPU'en til å avlaste CPU'en så lenge man bare kan få resultatene ut på skjermen og ikke lagret på lokalt minne/disk.

 

Når det gjelder utviklingen videre med tanke på spesialiserte ko-prosessorer o.l. så tror jeg det vil foregå etappevis i denne rekkefølgen:

 

1. "General purpose"-kjerner med eksterne ko-prosessorer som benytter tradisjonell infrastruktur for interkommunikasjon (PCI-Express, etc) og eget API. F.eks. Ageias PhysX.

2. "General purpose"-kjerner med eksterne ko-prosessorer som benytter spesialtilpasset infrastruktur for interkommunikasjon (HyperTransport, etc) og eget API. F.eks. AMDs "Torrenza"-prosjekt.

3. Hybrid-design bestående av "general purpose"-kjerner og ko-prosessorer integrert på samme brikke koblet med et utvidet instruksjonssett istedet for API. F.eks. AMDs "Fusion"-prosjekt.

4. Multikjerne-design med ymse kombinasjoner av hybrid-design og tynnere spesialiserte kjerner på samme brikke som benytter seg av eksisterende instruksjonssett.

5. Osv.

Endret 21. februar 2007 av snorreh

[Del]

Kanskje du da kan dele hvilket nick du bruker der?

På comp.arch bruker man ikke nick, men fullt navn.

 

Men hvilken relevans har det?

Vel, du kunne ha deltatt på tilsvarende diskusjon med meg på rwt. Det er vel rimelig opplagt at det er greit å vite om man har med samme person å gjøre, spesielt med den tonen du la opp til.

 

Jeg er fortsatt interessert i hvilken bakgrunn du har, slik at jeg kan kommunisere bedre med deg.

Min CV legger jeg ikke ut her nå, om du gjør det er opp til deg, og provokativ oppførsel endrer ikke det. Ellers hadde jeg vel få problemer med å forstå deg, kom ikke det ganske klart frem i mitt første tilsvar?

 

Jeg bryr meg ikke om hvilke kallenavn du bruker andre steder, eller hva ditt fulle navn er.

Jeg bruker samme nick, men det visste du vel allerede kan jeg tenke meg, og siden du utnyttet det i forrige post brydde du deg vel også.

 

Ved å fremheve noen trender mens du ignorerer andre?

Kan du være litt mer konkret?

GPU og CPU har divergert lenge, og det er flere trender knyttet til det, minnet er en. Klokkehastighet en annen.

 

Cache er dyrt, og lite fleksibelt.

Det var jo et ganske kort svar som har liten relevans i forhold til det jeg skrev, så vidt jeg kan se, men kanskje du har et annet poeng?

 

Terje Mathisen skrev at "all programmering er en øvelse i caching". Du er tilsynelatende uenig. Hvorfor?

Tvert imot. Ikke at jeg skal legge ord i hans munn, men hadde cache vært veldig fleksibelt og billig, så hadde det vel neppe krevd så mye øvelse.

 

Å få den latency og båndbredde som en high end GPU nyttiggjør seg lokalt til en CPU vil være vanskelig å forene med modulært minne en god stund fremover.

Akkurat. Jeg kan ikke se at jeg har hevdet noe som går på tvers av dette.

Så hvordan ser du for deg at det skal løses, slik som på Cell?

 

Cell har klart sine arkitekturmessige utfordringer, men det er et klart eksempel på at man har tatt en generell prosessorarkitektur (PowerPC) og integrert med grafikkhåndtering på en og samme brikke. Problemet er "løst".

Har ikke PS3 egen GPU?

Jo, men en veldig stor del av jobben gjøres nå i Cell-prosessoren.

Dette er et punkt jeg mener du tar altfor lett på. Jeg tror det er langt fra trivielt å få Cell til å yte i nærheten av en high end GPU-løsning på grafikk, her får du det til å høres ut som om de allerede nesten har klart det.

 

Minnekonfigurasjon? Kan du være litt mer konkret?

Cell har 256MB punktum.

Din påstand er feil.

Takk for linken, jeg hadde helt glemt at de hadde doblet minnet på cluster løsningen, og hvilken relevans har det overhodet til poenget, løsningen mangler fleksibilitet, det er one-size-fits-all. Har de lagt inn kjapp DP nå da?

 

Edit: Jeg blir sprø av disse quotene, på tide kveruleringen stoppper.

Endret 21. februar 2007 av Del

[Reeve]

Littt OT, men hva er raskest til å regne ut PI av PiFast og QuickPi?

7984764[/snapback]

En jeg kjenner hevdet å ha testet ut et utall pi-programmer og fant ut at Pifast var raskest. Men det er godt mulig at QuickPi var med i utvalget av Pi-programmer. Det er bare å teste så finner man ut.

 

Det var da svært til interesse for pi her Hva med tallet e?

Det er jo også ganske spennende...

7985254[/snapback]

 

 

Man kan jo regne ut e med PiFast og

 

Litt OT: Hva er egentlig e? (ikke tallet, men hva brukes det til, som Pi brukes til sirkler osv.)

 

EDIT: De 500 første desimalene i e

 

E = 2.

7182818284 5904523536 0287471352 6624977572 4709369995 : 50

9574966967 6277240766 3035354759 4571382178 5251664274 : 100

2746639193 2003059921 8174135966 2904357290 0334295260 : 150

5956307381 3232862794 3490763233 8298807531 9525101901 : 200

1573834187 9307021540 8914993488 4167509244 7614606680 : 250

8226480016 8477411853 7423454424 3710753907 7744992069 : 300

5517027618 3860626133 1384583000 7520449338 2656029760 : 350

6737113200 7093287091 2744374704 7230696977 2093101416 : 400

9283681902 5515108657 4637721112 5238978442 5056953696 : 450

7707854499 6996794686 4454905987 9316368892 3009879312 : 500

Endret 21. februar 2007 av christopher909

[dios]

Vel, du kunne ha deltatt på tilsvarende diskusjon med meg på rwt.

Neppe. Jeg har ikke vært aktiv der på fire år, og har aldri sett nicket ditt før her på diskusjon.no (hvor jeg er ganske fersk).

 

Det er vel rimelig opplagt at det er greit å vite om man har med samme person å gjøre, spesielt med den tonen du la opp til.

Jeg skjønner at tonen har kommet helt ut å kjøre, spesielt med måten du tiltaler meg i resten av artikkelen; du virker mer interessert i å angripe meg enn i å diskutere sak, så da er det slutt for min del.

[Simen1]

christopher909: e er grunntallet for den naturlige logaritmen og har en rekke anvendelser. For ikke å spore fullstendig av gir jeg bare en lenke til mer info:

http://en.wikipedia.org/wiki/E_%28mathematical_constant%29

 

Angående minneproblemet på kombinerte CPU/GPU så ser jeg for meg at det kan løses ved å kombinere de eksisterende minneløsningene for CPU og GPU. Dvs. ett sett med modulært minne pluss et sett med dedikert minne. Man kan betrakte det som en et nytt minnenivå a la det L2 cache var for et tiår siden (egne moduler på hovedkortet, bare at jeg ser for meg det dedikerte minne enten på hovedkortet eller på en MCM CPU-modul). En annen måte å betrakte en sånn kombinasjon på er som en avansert form for flere minnekanaler per CPU. Nye instruksjonsutvidelser kan hjelpe til med å lette NUMA på en CPU/GPU. Altså at programvaren blir klar over hvor den kan finne de ulike typene minne slik at det kan prioritere hvilke data som skal ligge hvor.

 

Fast minne på f.eks en MCM trenger ikke å være kun en størrelse. Akkurat som CPU-produsentene i dag har et spekter av CPU'er med ulik mengde cache kan det i fremtiden bli MCM med et spekter av ulik mengde lokalt minne med høy båndbredde og lav latency. (256bit minnebuss tror jeg skal være overkommelig på en MCM). Fordelen med MCM fremfor dedikert minne på hovedkortet er at man sparer mange lag på PCBen (noe hovedkortprodusentene vil være glade for) og fordi man slipper å addere mange hundre pinner på CPUen.

[stoffix]

dette er et spørsmål både til dios og Del:

har dere begge glemt av DMA?

jeg kom nylig på dette, og jeg kan tenke meg at det kan nyttegjøres end del hvis man skal bruke GPGPU til noe arbeid. f.eks. så kan den jo da få lov til å skrive direkte til ram, eller harddisk, eller kanskje nettverskortet, eller lydkortet. det er mange muligheter.

poenget mitt med dette innlegget er, har dere husket på at skjermkortet ikke nødvendigvis trenger å sende behandlet data tilbake dit rådataene kom ifra?

[Del]

dette er et spørsmål både til dios og Del:

har dere begge glemt av DMA?

jeg kom nylig på dette, og jeg kan tenke meg at det kan nyttegjøres end del hvis man skal bruke GPGPU til noe arbeid. f.eks. så kan den jo da få lov til å skrive direkte til ram, eller harddisk, eller kanskje nettverskortet, eller lydkortet. det er mange muligheter.

poenget mitt med dette innlegget er, har dere husket på at skjermkortet ikke nødvendigvis trenger å sende behandlet data tilbake dit rådataene kom ifra?

7997059[/snapback]

Neida, har ikke glemt DMA. For all del, du kan sende dataene dit du vil. Problemet med dette er at GPU kun er egnet for enkelte oppgaver, mens den vil yte frytkelig dårlig på mange vanlige oppgaver. Et program er gjerne sammensatt av foskjellige rutiner, hvor noen egner seg for GPU og andre ikke. Hvis du da kan bytte eksekvering mellom GPU og CPU raskt, så er ikke dette et så stort problem, men det fordrer at du kan flytte data mellom GPU og CPU raskt. Dette var dios sitt hovedargument. Dette problemet kan ikke løses med ditt forslag såvidt jeg kan se. Mitt poeng er at du ved å integrere GPU i CPU (som vil løse akkurat det problemet) møter en hel rekke andre problemer som sannsynligvis vil kreve kompromisser. Disse kompromissene ser for meg ut til å medføre at du mister high-end grafikk, hvilket i såfall betyr at gutterommet vil trenge ekstra GPU likevel. For laptop hvor energibruk er et hovedpooneng, og hvor man uansett har delt minne mellom CPU og GPU ser jeg vel muligheter, og jeg tror det er dette segmentet AMD sin fusion er rettet mot. Samt at det vil gjøre budsjett PC'en billigere.

[stoffix]

ja, en GPU er kun egnet for enkelte oppgaver.

jeg nevner en GPGPU.

jeg er klar over at det er mange av de samme begrensningene der, men den kan jo da gjøre litt flere oppgaver enn en "vanlig" GPU.

 

et eksempel jeg kan se for meg er hvis du har et veldig stort bilde i Photoshop. du har brukt lang tid på dette, og har 400 lag.

du vil nå lagre dette på harddisk.

jeg kan da tenke meg at dette kan være et eksempel på et område det kan være ønskelig å flytte arbeidet over til GPGPU (eller GPU om den også er i stand til det) og så la GPGPU lagre bildet på harddisk etter prosssesering.

 

tanken min her er at skjermkortet prosseserer bildet mer effektivt før det skal lagres (bla.a. legge samme alle lagene i mitt tilfelle) og så sende det direkte til harddisken istedet for at det må tilbake via CPU og eller systemminne.

 

eller vil ikke dette lønne seg alikevel?

[Del]

Jeg skjønner at tonen har kommet helt ut å kjøre, spesielt med måten du tiltaler meg i resten av artikkelen; du virker mer interessert i å angripe meg enn i å diskutere sak, så da er det slutt for min del.

7996290[/snapback]

Vel, nei, jeg brukte faktisk resten av posten til å diskutere sak, så her tuller du. Hvis du tror at alt jeg skrev var for å angripe deg så tror jeg du har et seriøst problem.

 

Angående minneproblemet på kombinerte CPU/GPU så ser jeg for meg at det kan løses ved å kombinere de eksisterende minneløsningene for CPU og GPU. Dvs. ett sett med modulært minne pluss et sett med dedikert minne. Man kan betrakte det som en et nytt minnenivå a la det L2 cache var for et tiår siden (egne moduler på hovedkortet, bare at jeg ser for meg det dedikerte minne enten på hovedkortet eller på en MCM CPU-modul). En annen måte å betrakte en sånn kombinasjon på er som en avansert form for flere minnekanaler per CPU.

Kan godt tenkes. Allerede nå kan man jo utnytte HT teknologien til AMD for å få relativt god latency og båndbredde mellom CPU og GPU, mens GPU beholder sitt nåværende minne. Med små mikroarkitekturendringer burde det også være mulig å få til koherent minne med NUMA. Nå er jeg vel ikke helt overbevist om hvor gode noen av disse løsningene blir, men det burde ihvertfall gjøre GPGPU mer attraktivt for flere.

Fast minne på f.eks en MCM trenger ikke å være kun en størrelse. Akkurat som CPU-produsentene i dag har et spekter av CPU'er med ulik mengde cache kan det i fremtiden bli MCM med et spekter av ulik mengde lokalt minne med høy båndbredde og lav latency. (256bit minnebuss tror jeg skal være overkommelig på en MCM). Fordelen med MCM fremfor dedikert minne på hovedkortet er at man sparer mange lag på PCBen (noe hovedkortprodusentene vil være glade for) og fordi man slipper å addere mange hundre pinner på CPUen.

7996425[/snapback]

Dette er uansett mye mindre fleksibelt enn i dag , hvor du bare stapper ned noen ekstra minnebrikker, og vips har du fått noen GB til. For ikke å snakke om det kombinatorielle problemet med hvor mange løsninger som man skal produsere, dagens modulære oppbygning er en fin ting på mange måter.

 

ja, en GPU er kun egnet for enkelte oppgaver.

jeg nevner en GPGPU.

jeg er klar over at det er mange av de samme begrensningene der, men den kan jo da gjøre litt flere oppgaver enn en "vanlig" GPU.

GPGPU er et begrep, ikke en arkitektur, som referer til at man bruker en GPU til andre ting enn grafikk. Nå har du selvfølgelig likevel et godt poeng siden både nVidia og ATI jobber med å gjøre prosesseringsenhetene sine mer programmerbare. Et viktig spørsmål her er i hvor stor grad de vil være villige til å ofre grafikkytelse for å booste ytelse på andre ting. Jeg tror vel kanskje pipe-linen i f.eks. SPE'ene til Cell er mye bedre egnet enn pipe-linene i en GPU for de oppgavene du foreslår.

[stoffix]

jeg har aldri sagt at gpgpu er en arkitektur, men det er (som jeg antar du prøver å si) et begrep på en annerledes arkitektur.

 

såvidt jeg har forstått så vil en GPU av litt eldre standard ikke være i stand til masse av det en gpgpu er i stand til, uavhengig av bruk.

 

Hva SPE'ene til cell klarer har ingenting med saken her å gjøre, da det etter min viten enda ikke finnes en pc (ikke datamaskin, men pc) som bruker en cell prosessor som cpu. jeg er veldig usikker på dette, men jeg tror ikke cell støtter x86 instruksjonssettet heller.

 

meningen min med det inlegget, var om det ville være mer effektivt, tidsmessig, å gjøre det slik jeg sa i min forige post, enn at cpu gjør all jobben.

[Del]

jeg har aldri sagt at gpgpu er en arkitektur, men det er (som jeg antar du prøver å si) et begrep på en annerledes arkitektur.

http://en.wikipedia.org/wiki/GPGPU

Det er selve det å bruke GPU'en til annet enn grafikk, altså som et verb om du vil.

 

såvidt jeg har forstått så vil en GPU av litt eldre standard ikke være i stand til masse av det en gpgpu er i stand til, uavhengig av bruk.

Jo, det tror jeg nok, men det vil være rimelig tungt å programmere. Sintef/CMA har lagt ut et bibliotek for formålet her. Dette biblioteket kan brukes fra og med G6 serien til nVidia. Stanford har laget et tilsvarende bibliotek. Så dette er ikke noe som kom først med CUDA.

 

Hva SPE'ene til cell klarer har ingenting med saken her å gjøre, da det etter min viten enda ikke finnes en pc (ikke datamaskin, men pc) som bruker en cell prosessor som cpu. jeg er veldig usikker på dette, men jeg tror ikke cell støtter x86 instruksjonssettet heller.

 

meningen min med det inlegget, var om det ville være mer effektivt, tidsmessig, å gjøre det slik jeg sa i min forige post, enn at cpu gjør all jobben.

8002036[/snapback]

Du forespeilte en oppgave, som ikke står helt klart for meg hva innebærer. Mitt poeng der var at Cell er typisk laget for å være rå på flyttallsytelse på andre problemer enn grafikk, og det er akkurat hva typisk GPGPU innebærer (strengt tatt er det vel forhåpninger knyttet til GPGPU utover flyttallsytelse, men det er ikke poenget her).