josse

kom på en ting. hvorfor brukes ikke disse maskinene til rendring (eller gjør de). de kunne jo ha leid ut super dataen til firmaer for å rendre ting. hadde vel ikke tatt så mange timene å rendre en film...

De fleste renderoperasjon er "embarassingly parallell", noe som betyr at det behøves svært lite kommunikasjon mellom de forskjellige nodene i clusteret når man først har startet.

De fleste vitenskapelige simuleringer derimot, er svært avhengige av kommunikasjon mellom nodene underveis.

Mye av styrken til high-end maskinene fra IBM, SGI, Cray etc. er at de har svært god intra-maskin kommunikasjon. Dette tar de seg naturligvis godt betalt for, men til rendering er nok pengene bedre brukt andre steder.

Det skal dog bemerkes at grensene selvsagt er flytende.

Om "Moores lov" av typen dobbel ytelse hver 24 måned fortsetter inntil dette inntreffer så er x = 28 år.

Moores lov sier ikke noe om ytelsen på maskinen, mer derimot om transistortettheten. Videre sier det at denne vil dobles omtrent hver 18. måned.

"Tidligere" (pre-2004) brukte man riktignok (mye av) den økende transistortettheten til å kunne klokke høyere, (fra .13-0.9 micron), men nå om dagen bruker man den økende tettheten i større grad til å øke cachemengden på CPU'en. Dette gir også en ytelsesgevinst, men den dobles definitvt ikke hver 18. måned.

Takker, Simen1!

 

Forresten kan man jo lure på hvorfor ikke skjermkortprodusentene selv ser markedet her, og med noen forandringer på skjermkortene og driverne kan lansere CPU-avlastning/booster-kort som knuser alle andre løsninger innenfor prisnivået... Er de for spesifikt oppbygde?

Skjermkortprodusentene vet utmerket godt hvilket potensiellt marked som er der, og bidrar til utviklingen av teknologien. Nvidia bidro f.eks. på et seminar i forbindelse med Siggraph 2004, og de har ansatt flere personer som har forsket på GPGPU teknikker.

Det som er svært viktig å ha klart for seg er at det kun er enkelte typer algoritmer som er velegnet for beregning på GPU'en; nemlig de beregningene hvor mye data skal prosesseres på samme måte.

Det er derfor man har opptil 16 pipelines på et skjermkort idag, mens en moderne CPU bare har noen få.

Veldig god løsning...f.eks 1 pipeline bruker til lydkort, 12 pipelines til grafikk, resten til I/O porter, og nettverskort...en meget bra løsning 

Dette vil nok dessverre ikke fungere. En GPU er designet slik at den kjørere samme program (shader) på forskjellige data i alle pipene.

Oki. Beklager at jeg ikke så signaturen din før nå..

 

Da kan jeg fyre løs allerede nå :

* Når tror du vi får se den første GPU-optimaliserte ikke-grafikk-programvaren for vanlige brukere?

* Hvilken type programvare tror du dette kommer til å være?

* Kan du tippe på hvor stor ytelsen blir på denne programvaren i forhold til kjente CPU'er?

Når vi diskuterer dette er det viktig å være oppmerksom på at grensen mellom klassisk Transform and Lighting og GPGPU-bruk av skjermkortet er flytende.

For å svare på spørsmålene dine.

1) Jeg tror vi vil få se slike programmer allerede i høst. Vanlige brukere er jo et ganske vidt begrep.

2) Jeg tror de første typene slike programmer vil være lyd, bilde og filmredigeringsprogrammer. Jeg vil tro at typiske 1. generasjons applikasjoner vil være plugins til Photoshop og liknende programmer. Kort oppsummert vil alle applikasjoner som drar nytte av SSE{2,3} være godt egnet for videre optimalisering på GPUen.

Det ville heller ikke forundre meg om denne bruken av grafikkortet dukker opp i spill, til å direkte simulere skyer, bølger etc. Den viktigste bruken av denne teknikken vil nettopp være å kjøre simuleringer (som regel i form av en numerisk løsning til en partiell differensiallikning) på GPUen for deretter å direkte visualisere resultatet.

3) Når man diskuterer ytelse må man her skille mellom programytelse og algoritmeytelse. For enkelte algoritmer kan man idag observere økning på rundt 10x mot en klassisk CPU implementasjon. Dersom CPU implementasjonen bruker SSE er det mindre å hente.

Dette gjelder et typisk high-end kort (GeForce 6800, Radeon X800) mot tilsvarende high-end CPU'er (3++GhZ).

Det har nettopp blitt startet et prosjekt av SINTEF, med titlen Graphics Hardware as a High End Computational Resource som skal forske på, og formidle mulighetene, som ligger i denne teknologien.

Jøss, jeg visste ikke at vi hadde noe norsk ekspertise på området.

 

Jeg har nå sendt mail til den ansvarlige i SINTEF og spurt om han har noen kommentar til denne artikkelen. Håper han svarer her i tråden. Det ville vært interresant å fått en skikkelig ekspertuttalelese.

Jeg er del av dette prosjektet selv, og har nettopp påbegynt en doktorgrad om emnet. Dersom noen har spørsmål er det bare å fyre løs.

Det at GPU'er har en ekstrem ytelse på enkelte oppgaver er egentlig noe som har vært kjent veldig lenge så jeg vet ikke hvorfor det ikke er bedre utnyttet i noen programvare ennå.

Grunnen til at det ikke er tatt særlig bruk enda skyldes flere årsaker.

• Vanskelig å programmere, da grafikkortene enn så lenge programmeres gjennom grafikk APIer. Generell programkode som er skrevet for skjermkort er også vanskeligere å debugge og vedlikeholde enn vanlig kildekode. (Det finnes bibliotekere som Sh og Brook som gjør dette lettere.)
  
• Ukjent teknologi - det er forsatt få som vet om disse mulighetene, enda færre har kunnskaper til å bruke dem.
  
• Umoden teknologi. I den forstand at hva som er støttet i hardware (og drivere) fra de forskjellige produsentene stadig endrer seg.
  

Det har nettopp blitt startet et prosjekt av SINTEF, med titlen Graphics Hardware as a High End Computational Resource som skal forske på, og formidle mulighetene, som ligger i denne teknologien.

Dette er et aktivt forskningsområde også internasjonalt, og mye av det som skjer blir referert på GPGPU.ORG.

Men nå vil jeg ha deres meninger da

Hva dere her på hardware forumet tror om neste generasjons skjermkort, ikke hva store sider/selskaper som du ga meg linker til nå

 

Edit: er altid en så må lage en post å hakke på han som lagde topicen, det er altid en bitte liten feil :-s

skjønner meg ikke på det.

Svar på det som står i topicen eller hver stille mener jeg.

Så du ønsker altså folks synsing rundt hva de tror fremtidens grafikkort skal bringe? Selv har jeg nylig påbegynt en doktorgrad om å bruke skjermkort til generelle beregniner, ofte kalt

GPGPU. Denne doktorgraden har et tidsrom på 3-4, slik at det faktisk er nødvendig å vite hva slags hardware som er tilgjengelig. Jeg har derfor brukt de siste ukene på å gjøre en ganske så systematisk gjennomgang av hva vi vet om hva hva som kommer til å skje på GPU fronten de neste årene. De beste oppsummeringen av dette var jeg gav deg linker til over.

Jeg skjønner nå at dette ikke var det du var ute etter, og skal holde kjeft fra nå av. Å få informasjon fra et norsk miljø som faktisk gjør seriøs, vitenskapelig forskning på GPU'er er tydeligvis ikke det du var ute etter.

Fikk lyst til å lage en topicen om neste generasjons skjermkort, vet ikke om det er lagd noe post om dette før, orker ikke å søke etter det heller

 

Men hva tror dere vil komme fra Nvidia og Ati i fremtiden?

Og tror dere det vil komme flere store grafikk produsenter?

Fortell litt hva du tror om fremtiden til grafikk kort.

Hadde du orket å søke litt hadde du funnet flere interessante artikler:

The near and nearest future of graphics hardware acceleration.

GDC 2004: DirectX Graphics Future (Denne ville jeg tatt med en klype salt. Render to Vertex buffer som står oppgitt til 2006 er allerede på plass i NV4x)

DirectX Next: Early preview

Jeg var på et seminar holdt av Randi Rost fra 3DLabs (om OpenGL Shading Language), der han også snakket om muligheten for flere tråder på grafikkortet og virtuelt minne. Foilene fra dette foredraget finnes også på nett.

Når får man altså plutselig en prosessor med både HyperThreading, XD/NX-bit, 64-bit og kanskje snart Cool'n'Quiet/AAC-technology.

(Intel: NX og "Cool'n'Quiet" til høsten)

Plutselig er det Intel som har den mest oppdaterete teknologien, og det til en hyggelig pris.

Morsomt å vite, men siden når begynte hw.no å melde om enhver ny server som koster en middels årslønn? Oh, jeg vet, siden AMD Opteron! 

Husk også at hw.no ikke bare leses av hjemmebrukere/entusiaster, men også av folk som jobber profesjonellt med IKT. For oss er det interessant å lese om maskiner som koster noen måndedslønner. For mange firmaer i Norge er det høyst reellt å kjøpe slike maskiner.

Skal hw.no ha et tilbud også til den professjonelle delen av markedet er dette mye mer relevant enn tester av overklokkingsvennlig minne.

Men jeg skjønner IKKE hvorfor de skal bruke "XT". Dette er jo allerede i bruk for lenge siden innen sykkelbransjen (Shimano XT).

Og før det igjen var det i bruk av IBM på modellen IBM XT, maskinen som kom etter IBM PC og var en 80086 CPU på 4.77MhZ og hele 10MB HD.

--

josse

Se A Mathematical Theory of Communication av Claude E. Shannon.

Latensen er uavhengig av båndbredden.

Spør han om P == NP.

Dersom han skjønner hva spørsmålet går ut på har han en basal forståelse for teoretisk databehandling. Dersom han har et svar fortjener han en Turing award.

For en innføring i problemet se http://www.claymath.org/Millennium_Prize_P...oblems/P_vs_NP/

Jeg kjører en Sapphire 9700Pro med ZM80CHP og har ingen problemer med det ved vanlig hastighet. Har to kabinettvifter, men tror de ikke er nødvendige for å holde ting stabilt.

Sapphire selger selv en versjon av 9700Pro med en liknende heatpipe.

Hei, jeg planlegger å bygge meg en HTPC basert på et SkyHawk IPRO-1203 kabinett og et MSI K7N2GM-IL (mATX) hovedkort. Prosessor skal være en gammel 1.4GhZ Athlon TBird som jeg har liggende.

Dette kabinettet er forholdsvis lavt og det ikke plass til noen høy stillegående vifte (omtrent 70mm høyde fra hovedkortet og opp), lurte derfor på om noen har erfaring med om det er mulig å kjøre (eventuellt underklokket) Athlon vifteløst, kun med en stor kobberkjøler (type Zalman 6000-serien uten viften eller liknende).

Et det eventuellt andre mATX kabinetter noen har erfaring med?

Finnes det no software som gjør at jeg kan mappe opp ett 'network drive' igjennom SSH mot Linux ?? Slik at jeg f.eks kan få opp en bokstav X: som er koblet mot et Linux område igjennom SSH ??

http:// lufs.sf.net

men hva er egentlig fordelen med 64-bits prossessering?

Jeg gav dette svaret på samme spørsmål 11. april i en annen tråd:

Med en 64-bits CPU mener man vanligvis at registrene i prosessoren kan holde 64-bits verdier. Disse registrene brukes til å holde heltalsverdier og minneaddresser. For lagring av flyttall brukes andre registre (ofte på 80 bit).

En 64 bits verdi er et binært tall bestående av 64 felter som kan holde verdiene 1 eller 0. Dette gir muligheten til å representere alle tall mellom 0 og 2^64.

For AMD Hammer, eller X86-64 er instruksjonslengden også 64 bit.

Det er primært to fordeler med 64-bits arkitekturer:

1) Man kan behandle heltall opptil 2^64 direkte. Man kan f.eks. addere to 64-bits ved å legge sammen registrene de er i direkte, fremfor å gå veien om å gjøre addisjonen i software.

2) Den store fordelen er at det åpner for å addressere et større minneområde direkte. På en 32-bits maskin med 32-bits minneaddresser kan man maksimalt addressere 4GB med minne. Innenfor vitenskapelige simuleringer og visualiseringer er ikke dette spesiellt stort.

Det skal sies at allerde idag støtter Intel Xeon (som har 32-bits registre) opp til 36-bits indirekte minneaddressering. Men det er forsatt ikke mulig å bruke mer en 4GB minne pr. applikasjon, og dette er et hack som krever endel ekstra jobbing av OSet.

Den jevne desktop bruker/gamer har idag ikke bruk for noen av disse egenskapene. Det er veldig sjelden en desktop applikasjon eller et spill regner med større heltall en 2^32, ei heller jobber de fleste desktopbruker med datasett som er i nærheten av 4GB. Ukomprimert digital video er et mulig bruksområde.

De som først vil ha glede av 64-bit er de som kjører store databaser, og ikke har råd til dagens 64-bits maskiner, eller folk som kjører store simuleringer og heller ikke har råd til dagens 64-bits maskiner.

Man får ikke noen direkte ytelsesøkning i gå fra 32 til 64-bit, men ved å lage en ny arkitektur kan man fort bli kvitt endel gammelt "rusk", og dermed få bedre ytelse.

Myten om at ting går dobbelt så fort er nettopp det, en myte.

Jeg lurte på om redhat 9 var noe bra?

For nybegynnere: Ja

En liten kommentar til dette.

Jeg har brukt Linux siden høst 1994. (Slackware 2.0, med kjerne 1.0.9) Har siden dengang brukt Slackware, RedHat, Mandrake, Progeny (nå konkurs) og Debian. Har nå (på hjemmeboksen) brukt RedHat det siste året, etter å ha kjørt Debian unstable de to foregående årene. Jeg har utviklet og driftet bedriftskritiske systemer for en online akjsemegler på Linux. Har også brukt Linux som primær desktop platform siden dengang, skrevet et hovedfag i informatikk (hvor jeg brukte Linux/G++ til programmering og LaTeX til oppgaven.) Har også brukt uttallige timer på å sitte å dille med Linux, og føler derfor jeg har litt grunnlag for å utale meg om de forskjellige distribusjonene.

Debian (og da spesiellt unstable, som jeg de fleste ihuga Debian fantaster bruker) er fint dersom man ønsker å være "bleeding-edge" og hele tiden få siste utgave av softwaren. Til å være en unstable versjon er den overraskende stabil, men den brekker på nye og spennende måter hver dag. Dersom man er i stand til å fikse ting selv, og godtar å bruke en times tid hver gang man har dist-upgradet på å fikse småfeil er Debian en flott distribusjon. Mye software er tilgjengeg i blodfersk utgave. Dersom man ønsker et stabilt arbeidsmiljø, og faktisk bruker maskinen til noe annet enn å dille, må la være å dist-upgrade i hytt og pine.

Dersom man holder seg til stable utgavene av RedHat gir de et mye mer polert inntrykk en Debian, og det er lettere å sette opp. (Ja, det at jeg _KAN_ patche kjernen selv, for å støtte hardware XYZ, behøvr ikke bety at jeg _MÅ_ gjøre det. Det er fint dersom noen har gjort det for meg.) RedHat har også vært gode med å adoptere ny teknologi (slik som det nye C++ ABIet, Gnome 2 etc.) relativt tidlig, så man ligger ikke veldig langt bak Debian på den fronten. Enkelte applikasjoner kompilerer jeg dog opp selv, dersom de har nye features jeg gjerne vil ha. I bedriftskritiske systemer er det også bra å vite at andre (RedHat corp.) har testet kjernen mye bedre enn det jeg selv har ressurser til, og at de ikke sender ut nye utgaver som brekker bakoverkompabilitet.

Et vanlig argument for Debian er apt, men dette har vært tilgjengelig på RedHat/Mandrake i flere år nå, og er ikke lenger en grunn for å velge Debian. Jeg innrømmer at apt er dte første jeg installerer på alle RedHat bokser som jeg bruker.

Hvilken distribusjon man velger har derfor ikke noe med om man er nybegynner å gjøre eller ei. Hvis man til enhver tid ønsker siste utgaven av software, velg Debian. Skal man ha noe man kan stole på, som er et verktøy til å gjøre andre ting er mitt valg RedHat.

Installerer man Linux for første gang, uten Unix erfaring vil jeg anbefale RedHat eller Mandrake, man blir ikke noe mer "elite" av å kjøre en Debian man ikke klarer å konfigurere selv.

Med en 64-bits CPU mener man vanligvis at registrene i prosessoren kan holde 64-bits verdier. Disse registrene brukes til å holde heltalsverdier og minneaddresser. For lagring av flyttall brukes andre registre (ofte på 80 bit).

En 64 bits verdi er et binært tall bestående av 64 felter som kan holde verdiene 1 eller 0. Dette gir muligheten til å representere alle tall mellom 0 og 2^64.

For AMD Hammer, eller X86-64 er instruksjonslengden også 64 bit.

Det er primært to fordeler med 64-bits arkitekturer:

1) Man kan behandle heltall opptil 2^64 direkte. Man kan f.eks. addere to 64-bits ved å legge sammen registrene de er i direkte, fremfor å gå veien om å gjøre addisjonen i software.

2) Den store fordelen er at det åpner for å addressere et større minneområde direkte. På en 32-bits maskin med 32-bits minneaddresser kan man maksimalt addressere 4GB med minne. Innenfor vitenskapelige simuleringer og visualiseringer er ikke dette spesiellt stort.

Det skal sies at allerde idag støtter Intel Xeon (som har 32-bits registre) opp til 36-bits indirekte minneaddressering. Men det er forsatt ikke mulig å bruke mer en 4GB minne pr. applikasjon, og dette er et hack som krever endel ekstra jobbing av OSet.

Den jevne desktop bruker/gamer har idag ikke bruk for noen av disse egenskapene. Det er veldig sjelden en desktop applikasjon eller et spill regner med større heltall en 2^32, ei heller jobber de fleste desktopbruker med datasett som er i nærheten av 4GB. Ukomprimert digital video er et mulig bruksområde.

De som først vil ha glede av 64-bit er de som kjører store databaser, og ikke har råd til dagens 64-bits maskiner, eller folk som kjører store simuleringer og heller ikke har råd til dagens 64-bits maskiner.

Man får ikke noen direkte ytelsesøkning i gå fra 32 til 64-bit, men ved å lage en ny arkitektur kan man fort bli kvitt endel gammelt "rusk", og dermed få bedre ytelse.

Myten om at ting går dobbelt så fort er nettopp det, en myte.

Eller uendelig 1000Mbit-kort. Skal vi si oss ferdige?

Nei!

Bare for å være ekstra vrang og vanskelig kan jeg opplyse om at det finnes tall som er større enn uendelig.

Det mest kjente og minste tallet som er større enn uendelig kalles for Aleph_0. Dette tallet er definert som kardinaliteten til mengden av de naturlige (og dermed de rasjonale) tall.

(Aleph er forøvrig første bokstav i det hebraiske alfabetet.)

Aleph_0 1000MBit-kort bør dermed være enda raskere enn uendelig mange.

Andre kan fable videre på om det finnes nok informasjon i universet (som jo er endelig) til å overføre over så mye båndbredde.

Mer realistisk kan man begynne å regne på hva som gir størst båndbredde av en jumbojet full av taper og en (saklig) bundling av raske NICer.

Rykter fra theinquirer sier så:

http://www.theinquirer.net/?article=6661

Det er ingen her som oppgir hverken oppløsning eller hvor mye antialiasing og antisotropisk filtering som er på.

Dette vil ha mye å si for ytelsen i 3DMark.

Hvis du er på f.eks

http://www.tomshardware.com/graphic/02q4/0...o-cards-19.html

ser du at selv R300 får under 10K 3D Marks i 1600x1200