Tror ikke på GPGPU

[Simen1]

Blir spennende å se om OpenCL kan bidra til å forene kreftene

Jeg skulle akkurat til å si at vi mangler standardisering på programmeringsspråk til GPU, helt til du presenterer en åpenbar løsning på det problemet. : Vi får bare håpe at OpenCL blir standarden på det området og etter hvert skviser ut både CUDA, CTM og x86-rettede språk.

[Theo343]

Man kan håpe, men man ser jo hvordan OpenGL sliter i dag så vi får se.

[Sam_Oslo]

Blir spennende å se om OpenCL kan bidra til å forene kreftene

Jeg skulle akkurat til å si at vi mangler standardisering på programmeringsspråk til GPU, helt til du presenterer en åpenbar løsning på det problemet. : Vi får bare håpe at OpenCL blir standarden på det området og etter hvert skviser ut både CUDA, CTM og x86-rettede språk.

 

Jeg vet at 'Simen1' liker ikke å høre dette, men jeg tror at mangel på standardiseringen skyldes at Microsoft har vært fraværende fra spilleutvikling prosessen. Industrien trenger en mektig leder for å kunne få styring på dette rotet som du nevner. Hvem skal ta denne oppgaven?

[leifeinar]

er egentlig veldig spennende dette med GPGPU, et system med quad, og 2 stk 4870 har man faktisk en aldri så liten superdatamskin i huset. gjelder jo bare og få utnyttet det.

 

er bare og se hva de har klart med CELL, så skjønner man også at det er potensiale andre plasser også

[Anders Jensen]

Patrick P. Gelsinger, Senior Vice President i Intel forteller at grunnen til at Intel ikke tror på GPGPU er behovet for spesiell programvare. Det hjelper pent lite med en god ide rent maskinmessig hvis man ikke har programvare som utnytter plattformen.

Merkelig uttalelse av IA64-forkjemperen Gelsinger. (IA64 krever spesiell programvare for å fungere)

Gelsinger er ingen IA64 forkjemper dessverre. Han har aldri sagt en eneste positiv ting om IA64 uten at Intel satte pistol mot hodet hans. Han måtte vel ved en anledning nærmest gå kanossagang etter å ha antydet at IA64 ikke hadde noen fremtid. Vi snakker her om en person som hardnakket forsvarer x86 sine _tekniske_ fordeler og han har hele tiden hevdet at x86 er like bra som RISC fra et teknisk ståsted, og selvfølgelig med kompatibilitet som et ess i ermet. Ikke en gang hans tidligere proffessor John Hennessey (et av de tyngste navnene innen datamaskin arkitektur) klarte å få han på rett kjøl.

 

Forøvrig vil jeg si at det er feil å si at IA64 krever spesiell programmvare. Ja du må kompilere koden for IA64 isteden for x86, men du behøver som regel ikke skrive den om. For GPGPU må du skrive om koden din. Det er litt mer arbeid enn å sitte 20 min å vente på en kompilator. Videre må du typisk reoptimalisere koden din når et nytt GPU produkt er ute. Dette er svært dyrt og tidkrevende hvis du har en del kode som skal kjøres.

 

Når vi først er inne på kvalitetsprodukter... Power 7 kommer med 32 DP GFLOPS per kjerne og Itanium kommer sannsynligvis med vesentlig mer i Poulson versjonen. I det hele tatt er throughput på CPU i ferd med å eksplodere og jeg tror derfor GPGPU skal få det veldig vanskelig med å finne nisjer hvor den kan klore seg fast fordi investeringen i koden ikke kan forsvares.

 

Intel virker mer interessert i å gå den andre veien, nemlig å putte x86-kjerner inn i skjermkortene. Dette har selvfølgelig Intel allerede startet med, i form av sin Larrabee-løsning.

Dette er en rimelig meningsløs satsing da x86 slett ikke er bygget eller egnet for svært dataparallelle oppgaver. Går de denne veien må utvide x86 med et nytt instruksjonssett, som igjen krever spesiell programvare.

 

Helt klart enig. x86 blir kraftig endret for å håndtere dette og det betyr i praksis at en må rekompilere om en skal få utnyttet noe mer enn 10% av ytelsen. Jeg kan heller ikke forstå hvorfor noen skulle ønske å lage et slikt makkverk av et lappeteppe når målet er optimalisert regnekraft. Dette er "Scrapheap challenge: sports car". Gelsinger i et nøtteskall med andre ord.

 

Å spre slik negativitet om GPGPU er bare et tegn på at de prøver å jekke ned utviklingstakten fordi de ligger etter på den fronten selv. Larrabee virker interessant nok, men slik som det er beskrevet her så tror jeg både AMD CTM og Nvidia CUDA har langt bedre potensiale og ikke minst: Har det tilgjengelig lenge før intel.

Ja de henger definitivt langt etter men det har de gjort på andre områder også. Dette er ikke en business hvor historiske bragder har særlig med fremtidig verdi fordi teknologien endrer seg så fort og drastisk at selv den ubestridte leder kan være på konkursens rand neste dag. Det eneste som betyr noe er å ha de beste fabrikkene og den største posen med penger. Ingeniører er på billigsalg og det kommer stadig til nye genier så å få designet noe er trivielt så lenge du har pengene.

 

GPU bransjen er kanskje et av de bedre eksemplene innen CMOS verdenen på at veien fra toppen til bunnen kan bli veldig bratt.

Endret 15. juli 2008 av Anders Jensen

[Simen1]

Blir spennende å se om OpenCL kan bidra til å forene kreftene

Jeg skulle akkurat til å si at vi mangler standardisering på programmeringsspråk til GPU, helt til du presenterer en åpenbar løsning på det problemet. : Vi får bare håpe at OpenCL blir standarden på det området og etter hvert skviser ut både CUDA, CTM og x86-rettede språk.

Jeg vet at 'Simen1' liker ikke å høre dette, men jeg tror at mangel på standardiseringen skyldes at Microsoft har vært fraværende fra spilleutvikling prosessen. Industrien trenger en mektig leder for å kunne få styring på dette rotet som du nevner. Hvem skal ta denne oppgaven?

Åpen kildekode-miljøet med f.eks Sun Microsystems som store investeringspartnere. Hadde Microsoft sluppet til ville vi aldri fått noen åpen standard, men bare en de facto proprietær Microsoft-variant som kun kan brukes med Microsoft-produkter. Omtrent som å la Sony "standardisere" bærbare musikkspillere til sitt filformat (som ikke er kompatibelt med andre spillere), sitt format for tilkobling av hodesett (som ikke er kompatibelt med andre spillere), sin batteritype (som ikke er kompatibelt med andre spillere) osv. (Det med Sony er et hypotetisk eksempel så ikke ta det for bokstavelig)

[saivert]

Nå syntes jeg det ble tull å dra inn Microsoft og spillindustrien her. Dette her ikke noe med spill å gjøre. Dette handler om å bruke GPU til å beregne mer seriøse ting enn å rendre polygoner og teksturer i spill.

 

La oss holde oss til saken her:

OpenCL er veldig interessant, men NVIDIA og ATI er for interesserte i sin egen proprietære API til at dette vil bli en virkelighet. Sun må gjerne sponse dette prosjektet men de kan ikke forvente at AMD og NVIDIA kaster seg med på lasset. Et API er viktig for å låse kunder til produktet sitt.

 

Ageia forsøkte seg med et eget kort for fysikkberegninger. Dette minnet mye om GPU fordi det har mange paralelle kjerner, men instruksjonssettet var annerledes og det krevde at du benyttet Ageia sitt eget rammeverk eller motor for fysikk. Det var ikke stort salg av disse kortene og når NVIDIA kjøpte opp Ageia så gikk det ikke lang tid før de ga ut en Ageia motor som bruker CUDA for de underliggende beregningene. Hva forteller dette oss? Jo jeg tror det forteller oss at skjermkortet er i ferd med å bli til et ekstra prosessorkort. Dette har vi sett før i eldre datamaskiner (Amiga fikk et ekstra kort med en PowerPC prosessor i tillegg til Motorola 68000 CPU som allerede er montert). Men vi vil nok kalle det for skjermkort enn så lenge siden DVI/HDMI/DisplayPort sitter på det.

 

 

PS: Vil helst slippe å se folk kommentere dette ut fra eget ståsted som privatpersoner. GPGPU er ikke bare for kalkulasjoner av fysikk i spill, men også generelle kalkulasjoner i forksningsprosjekter og ikke bare folding@home eller SETI@home (som var det første prosjektet som benyttet seg av stor-skala distribuert regnekraft). Åpne horisonten litt og se at alle ikke har samme behov som deg selv.

Endret 15. juli 2008 av saivert

[Theo343]

Jeg hadde 50MHz co-proc kortet til Amiga1200, fine saker. Jeg er enig i at vi kan se på GPU som en co-prosessor for spesifike egnede oppgaver.

 

Det er jo også forsøkt lignende prosjekter med lydkort APUer.

[Anders Jensen]

Kan definitivt se på GPU som en co-prosessor og det går vel med den som alle andre co-prosessorer med noe suksess; de blir integrert på CPU chipen og senere tett integrert i selve CPU pipelinen. Dette fordi salgsvolum er det som teller mest på CMOS og det selges alltid mye CPU fordi alle trenger minst en. Den neste generasjon CPU arkitekturer (IBM power 7, Intel Poulson og Sandy bridge, SUN Rock, AMD Bulldoser) er rettet mot veldig høy throughput. De begynner egentlig å få mange av de samme egenskapene som en GPU har så en kan egentlig si at integreringen av GPU inn i CPU pipelinen så smått er i gang. Sannsynligvis vil GPU i fremtiden gjøre en mindre del av renderingsjobben enn den gjør i dag, også på spill. Tipper det blir mest post prosessering, AA osv.

Endret 16. juli 2008 av Anders Jensen

[Simen1]

Jeg lurer på hvordan de kan takle utfordringen med minnebåndbredde når GPU blir integrert på CPU. For det er jo ikke tvil om at vanlige DDR3 minnekanaler blir svært begrenset for en god GPU. Problemet ligger i både kompatibilitet med mange moduler, samt at minnet ikke et loddet rett på hovedkortet.

 

Kan det tenkes at vi får to minnenivåer? Ett med f.eks GDDR5 på hovedkortet eller på prosessormodulen (MCM), mens det andre nivået er mer likt det vi har i dag?

 

Kanskje prosessormodulen ser slik ut om noen år?

Med f.eks 1-2 GB raskt GDDR5-minne på modulen, og ellers vanlig DDR3-minne et annet sted på hovedkortet. Kanskje de døper minnet om til L4 cache?

[Anders Jensen]

Jeg lurer på hvordan de kan takle utfordringen med minnebåndbredde når GPU blir integrert på CPU.

De vil stable DRAM på toppen av CPU brikkene. Det gir 10x bedre båndbredde med tilsvarende teknologi i forhold til hva GPU har i dag, men legger også større begrensning på kapasitet, så en må være selektiv med hva som ligger der og fortsatt ha stor båndbredde til et høyere kapasitet RAM lager.

 

Kan det tenkes at vi får to minnenivåer?

Ja vi får definitivt mange minnenivåer. Cell har f.eks ett separat lager per SPE. Tenk noe i den retning. nvidia GPUer har også et lite minneområde per multiprocessor. Det er nok litt mer programmerer vennlig.

 

 

Kanskje prosessormodulen ser slik ut om noen år?

Med f.eks 1-2 GB raskt GDDR5-minne på modulen, og ellers vanlig DDR3-minne et annet sted på hovedkortet.

Ikke umulig, men mer radikale metoder har blitt foreslått. dvs. 3D stacking samt SUN sin proximity link som gjør det mulig for to brikker som ligger rett ved siden av hverandre å kommunisere direkte uten å gå via PCB. 3D stacking har selvfølgelig bedre ytelse, men også større kapasitetsbegrensning. Kombinasjon av de to er jo også mulig.

Kanskje de døper minnet om til L4 cache?

Nei, cache impliserer en helt annen funksjonell måte for minnenivået. Cache er egentlig veldig tregt i forhold til et direkte adressert RAM lager av samme størrelse fordi en må drive å søke etter adressene før en kan begynne å hente de data en vil ha. Det fungerer raskt bare hvis cachen er veldig liten, fysisk nær CPU og implementert i en veldig dyr CMOS teknikk, dvs 6T SRAM. Veldig liten betyr i dag rundt 10MB og det vil ikke skalere godt til mange GB selv med fremtidige prosessteknologier. Har leste en rapport om det der for noen år siden. Cache kommer ikke til å fortsette kapasitetskaleringen særlig mye. Historisk sett har vi fått et nytt cache nivå ca hvert tiende år og det er vel nå ca 10 år siden vi fikk L4 cache. Jeg tror ikke vi noen gang vil få L5 selv om det historisk sett skulle kommet ca nå. Det er stadig mindre å hente for hvert nivå og om du ser på faktiske implementasjoner så ser du at hvert nivå har stoppet sin kapasitetskalering. L1 har f.eks stoppet i underkant av 100kB og faktisk hatt tendens til å krympe ned mot 10kB. L2 er i ferd med å krympe fra noen få MB og ned mot 100kB etter som L3 blir mer vanlig. En del systemer, f.eks Itanium, er i ferd med å krympe sin L3 på neste gen. toppmodeller (12MB til 6MB). Gevinsten er at de kan bli raskere og mer energieffektive og selvfølgelig billigere.

 

Antagelig vil det bli flere parallelle nivåer heller enn flere vertikale nivåer. Dette er spekulasjoner basert på tilgjengelig informasjon om fremtidige Intel baserte massivt parallelle prosessorsystemer samt dagens GPU systemer. Minne vil bli delt i mange adresseområder for å utnytte lokalitet og parallellitet (de to viktigste nøklene til ytelse) og det vil bli flyttet fysisk nærmere for å håndtere de økte båndbreddekravene uten å svi av umulige mengder effekt.

Endret 16. juli 2008 av Anders Jensen

[Theo343]

Hmm nesten litt tilbake til "videominne" på hovedkort dagene med Amiga1200. Men akkurat det gjelder jo de fleste integrerte GPU'er i lang tid nå.

 

Men det blir spennende med disse "Fusion" prosjektene og spesielt når man tenker på "Hybrid" SLI/CF som har kommet. Da vil CPUen kunne utnytte den integrerte GPU biten til egnede oppgaver utenfor spill, mens den i spill kan eks. utføre fysikk eller parres mot skjermkort med "hybrid" CF/SLI.

 

Det blir interresant og vil skape ennå flere CPU klasser og produkter siden man da også tar med i beregningen hvor kraftig GPU løsning man får integrert i CPUen.

Endret 16. juli 2008 av Theo343