mboost-dp1
unknown
Interessant.. Måske skulle Sony og Ms have holdt sig lidt igen. Og måske satse lidt mere på deres hardware, end at der fandtes en multi-kerne cpu i deres konsoller.
Alligevel. Når det er første gang man (ret mig hvis jeg tager fejl) prøver sig frem med multi-kerne cpu'er i konsoller, så burde man måske have spurgt sig lidt til råds, omkring, for at høre om det var værd at satse på. :)
Især Sony er da gået helt amok mht. deres nye multi-kerne cpu. Lidt af et flop hvis man ikke rigtigt kan skrive ordentlige programmer til den, før konsollen er på vej ud af markedet. :D
Alligevel. Når det er første gang man (ret mig hvis jeg tager fejl) prøver sig frem med multi-kerne cpu'er i konsoller, så burde man måske have spurgt sig lidt til råds, omkring, for at høre om det var værd at satse på. :)
Især Sony er da gået helt amok mht. deres nye multi-kerne cpu. Lidt af et flop hvis man ikke rigtigt kan skrive ordentlige programmer til den, før konsollen er på vej ud af markedet. :D
Jeg fatter det ikke, men det er da muligvis mig der er dum;
Hvorfor er det sværer at skrive et multi-threded spil, end at skrive en multi-threded tekst-editor, eller MP3 afspiller?
Hvorfor er det sværer at skrive et multi-threded spil, end at skrive en multi-threded tekst-editor, eller MP3 afspiller?
BurningShadow det handler vel om at kunne udnytte alle threads fuldt ud samtidigt, så der ikke er nogle threads der er idle mens andre er 100% belastet (og derfor godt kunne bruge de sidste til hurtigere beregninger).
Hvordan kan man sørge for det?
Den problemstilling ser man ikke med en mp3 afspiller en tekst-editor.
Hvordan kan man sørge for det?
Den problemstilling ser man ikke med en mp3 afspiller en tekst-editor.
På en PC kan den ene kerne da fint tage sig af OS og alt der kører i baggrunden, mens den anden er dedikeret til spillet.
På konsollerne kunne det vel tænkes at arbejdsopgaverne kunne fordeles ud; AI, Relationer, Animationer, Fysik osv.
Det er vel ikke noget krav at alle kerne skal være lige belastet hele tiden - bare det ikke er helt vildt skævt...
På konsollerne kunne det vel tænkes at arbejdsopgaverne kunne fordeles ud; AI, Relationer, Animationer, Fysik osv.
Det er vel ikke noget krav at alle kerne skal være lige belastet hele tiden - bare det ikke er helt vildt skævt...
hvorfor ikke bare have det som nu, en kerne til spillet og en kerne til resten der køre i bagrunden, så virker konceptet med dual core nemlig... at man kan køre massere af lort på en gang uden det går totalt dødt, hvis nu ens spil IGEN vil til at sluge 100% af ens cpu mens man gamer det får man jo ingen chance for det man har til at køre i baggrunden køre fint, feks en video render etc.
#15 Pointen er jo netop, at Cell og de nye Power CPU'er skal sidde i Xbox og PS3 maskiner.
1) Hvor mange tror du der har tænke sig at køre en masse ting i baggrunden på deres spil-konsol? Ikke mange!
2) Nu har markedtingsskræfterne råbt "100 mio FIPS" i et stykke tid, men hvis spillet så langt fra kommer bare i nærheden af af kunne udnytte dette i praksis, så bliver tallet jo ret ligegyldigt.
Vi står simpelthen over for en ny generation af spil og programmering, der er det største skift i branchen siden 3D acceleratoren (3Dfx) blev introduceret.
1) Hvor mange tror du der har tænke sig at køre en masse ting i baggrunden på deres spil-konsol? Ikke mange!
2) Nu har markedtingsskræfterne råbt "100 mio FIPS" i et stykke tid, men hvis spillet så langt fra kommer bare i nærheden af af kunne udnytte dette i praksis, så bliver tallet jo ret ligegyldigt.
Vi står simpelthen over for en ny generation af spil og programmering, der er det største skift i branchen siden 3D acceleratoren (3Dfx) blev introduceret.
Fint så lad denne her generation få længere leve tid end sidste! vil ikke gøre mig noget! :)
desuden lader det til Nintendo´s fremgangs måde bliver bedre, ja deres maskine bliver ifølge rygtet også Multi core, men de går efter at lave en maskine der er let og billig at udvikle til, og få god ydelse. de har også hele tiden sagt at det ræs MS og Sony køre vil slå begge firmaér ihjel :) efter som mange udvikler er ved at være ret kritiske angående ps3 og xbox360 kunne det tyde på gode gamle nintendo har ret :)
17> Nej Unreal motoreren udnytter ikke SMP (har kun hørt den ikke gør), Quake 3 motoren gør dog ikke særlig effektivt.. (ved ikke om doom gør ?? ) men den nye unreal motor gør så sikkert :)
desuden lader det til Nintendo´s fremgangs måde bliver bedre, ja deres maskine bliver ifølge rygtet også Multi core, men de går efter at lave en maskine der er let og billig at udvikle til, og få god ydelse. de har også hele tiden sagt at det ræs MS og Sony køre vil slå begge firmaér ihjel :) efter som mange udvikler er ved at være ret kritiske angående ps3 og xbox360 kunne det tyde på gode gamle nintendo har ret :)
17> Nej Unreal motoreren udnytter ikke SMP (har kun hørt den ikke gør), Quake 3 motoren gør dog ikke særlig effektivt.. (ved ikke om doom gør ?? ) men den nye unreal motor gør så sikkert :)
for lige at uddybe det som pakster skriver ang. multithreading:
det er nemt nok at tildele forskellige processer hver deres CPU, da en proces altid har sin egen tråd. derfor kan den ene CPU de/encode MP3 mens den anden bruges til fx. teksbehandling - det kan OSet sørge for.
men i et spil vil man altid have én proces som tager langt mere end de andre (den som styrer grafikken). de data som behandles i en sådan proces er stærkt afhængige af de data som tidligere er udregnet, hvilket betyder at CPUerne er nødt til at benytte sig af hinandens udregninger konstant, og administrationen af dette er ikke let.
forestil jer at man har en bunke sedler med numre som skal sorteres. Hvis én person gør dette, er det ligetil. Hvis 2 personer gør dette, kan man ikke forvente at det tager den halve tid, da de er nødt til at sammenligne hinandens sedler og flette dem sammen osv.
når man taler om multi GPU rendering (og software baseret 3D rendering) er det noget lettere, da man kan lade flere tråde arbejde på hvert sit område af billedet (som det ses ved SLI hvor 2 kort laver hver sin del af billedet). Her er det dog også nødvendigt med noget foranalyse, så billedet deles op så renderingstiden bliver den samme for de 2 GPUer. da billedets kompleksistet ikke er ens over det hele, er man altså nødt til at undersøge dette først, og derfor vil en arealmæssigt mindre, men mere kompleks del blive renderet af det ene kort, og en større men simplere del, af det andet kort.
i dette tilfælde er det CPUen som fordeler arbejdet, og det er i sagens natur ikke nogen let opgave at undersøge kompleksiteten i et billede som endnu ikke er renderet, og derefter opdele dette så der er lige meget arbejde til alle - det er bl.a. derfor at vi med SLI endnu ikke se de rigtig store boosts - CPUerne er for langsomme til at fordele arbejdet og levere de rå data til GPUerne, så det er kun ved høje opløsninger (CPUens arbejde stort set er det samme uanset opløsning) at SLI viser sine fordele
det er nemt nok at tildele forskellige processer hver deres CPU, da en proces altid har sin egen tråd. derfor kan den ene CPU de/encode MP3 mens den anden bruges til fx. teksbehandling - det kan OSet sørge for.
men i et spil vil man altid have én proces som tager langt mere end de andre (den som styrer grafikken). de data som behandles i en sådan proces er stærkt afhængige af de data som tidligere er udregnet, hvilket betyder at CPUerne er nødt til at benytte sig af hinandens udregninger konstant, og administrationen af dette er ikke let.
forestil jer at man har en bunke sedler med numre som skal sorteres. Hvis én person gør dette, er det ligetil. Hvis 2 personer gør dette, kan man ikke forvente at det tager den halve tid, da de er nødt til at sammenligne hinandens sedler og flette dem sammen osv.
når man taler om multi GPU rendering (og software baseret 3D rendering) er det noget lettere, da man kan lade flere tråde arbejde på hvert sit område af billedet (som det ses ved SLI hvor 2 kort laver hver sin del af billedet). Her er det dog også nødvendigt med noget foranalyse, så billedet deles op så renderingstiden bliver den samme for de 2 GPUer. da billedets kompleksistet ikke er ens over det hele, er man altså nødt til at undersøge dette først, og derfor vil en arealmæssigt mindre, men mere kompleks del blive renderet af det ene kort, og en større men simplere del, af det andet kort.
i dette tilfælde er det CPUen som fordeler arbejdet, og det er i sagens natur ikke nogen let opgave at undersøge kompleksiteten i et billede som endnu ikke er renderet, og derefter opdele dette så der er lige meget arbejde til alle - det er bl.a. derfor at vi med SLI endnu ikke se de rigtig store boosts - CPUerne er for langsomme til at fordele arbejdet og levere de rå data til GPUerne, så det er kun ved høje opløsninger (CPUens arbejde stort set er det samme uanset opløsning) at SLI viser sine fordele
Det kan godt være dual core CPUer er forholdsvis nyt og ukendt. Men programmeringsmæssigt adskiller de sig stort set ikke fra dual CPU maskiner. Hvor længe er det man har kunnet købe dual CPU PC'er? Jeg tror det er ca. 10 år.
På UNI har vi længe haft nogle multi CPU monstermaskiner til grafik. Jeg tror vi fik den første omkring 98, og den havde 4 CPUer og 64 grafikchips. Så grafik på multi CPU maskiner er ikke noget nyt.
[url=#3]#3[/url] BurningShadow
Der er forskel på at kode multitrådet fordi det er praktisk og fordi det er den eneste måde man kan udnytte alt CPU kraften. MP3 afspilning kan med fordel gøres multitrådet, men ikke fordi man har brug for mere CPU kraft, allrede i 99 havde jeg en computer, der kunne afspille MP3 filer med kun 10% belastning af CPUen.
Grunden til at man laver MP3 afspilning multitrådet er, at så kan man f.eks. have en tråd til indlæsning en til dekodning og en til at sende lyd til lydkortet. Dermed går lyden ikke i stå hvis man på et tidspunkt skal vente på input fra disken. Man skal lige overveje hvor meget RAM man vil bruge på hhv. udekodet og dekodet lyd. Den dekodede lyd kan hurtigere sendes til lydkortet. Men hvis man skal vente på en disk, så rækker 1MB udekodet lyd længere end 1MB dekodet lyd. Hvis man beslutter sig for at man kan nøjes med den ene slags buffer, så kan man slå dekodningen sammen med en af I/O trådene og nøjes med en tråd. Den måde at afspille lyd på er også en fordel på maskiner med kun en CPU.
Tekstbehandling er en noget mere kompliceret opgave end lydafspilning. Men jeg vil tro det laves multitrådet af nogle af de samme grunde. Man ønsker ikke at alt skal gå i stå fordi den lige skal vente på en disk eller netværksfilsystem. CPU tunge opgaver er der nok ikke mange af i tekstbehandling, men de få steder hvor de er kan en multitrådet implementation hjælpe fordi man så stadigt godt kan lave noget mens en tråd arbejder i baggrunden. Men jeg tvivler på man kan nå at sætte programmet i gang med endnu en tung opgave før den første er færdig.
Med et spil er det anderledes. En lydafspiller kan sagtens indlæse noget lyd, der først skal afspilles om et minut. Men i et spil kan man altså ikke begynde på noget grafik, der først skal vises om et minut. Selv det der skal vises på skærmen om 30 millisekunder kan man ikke begynde på endnu, fordi det afhænger af brugerinputtet de næste 15 millisekunder. Et spil har heller ikke den slags opgaver man sætter i gang i baggrunden og hvor resultatet så kommer på et tidspunkt. Kunne man overhovedet se nogen fordel i at lave et multitrådet spil på en single CPU maskine, så ville det nok ende med at en tråd stod for tung grafikgenerering og tog hovedparten af CPU tiden. Dernæst komme fysiksimuleringer, men hvor meget CPU tid de tager ved jeg ikke.
Udfordringen nu er at udnytte CPU kraften så godt som muligt. Så giver det pludselig mening at dele grafikgenerering over flere tråde. Heldigvis er nogle slags grafikgenerering paralleliserbare. Med raytracing kan man f.eks. beregne samtlige pixels uafhængigt af hinanden, det er bare stadig for tungt til at gøre i realtime.
[url=#19]#19[/url] amokk
På UNI har vi længe haft nogle multi CPU monstermaskiner til grafik. Jeg tror vi fik den første omkring 98, og den havde 4 CPUer og 64 grafikchips. Så grafik på multi CPU maskiner er ikke noget nyt.
[url=#3]#3[/url] BurningShadow
Hvorfor er det sværer at skrive et multi-threded spil, end at skrive en multi-threded tekst-editor, eller MP3 afspiller?Jeg ved nu ikke om det er så meget mere besværligt. Men formålet med multitrådede applikationer er forskelligt i de tre tilfælde.
Der er forskel på at kode multitrådet fordi det er praktisk og fordi det er den eneste måde man kan udnytte alt CPU kraften. MP3 afspilning kan med fordel gøres multitrådet, men ikke fordi man har brug for mere CPU kraft, allrede i 99 havde jeg en computer, der kunne afspille MP3 filer med kun 10% belastning af CPUen.
Grunden til at man laver MP3 afspilning multitrådet er, at så kan man f.eks. have en tråd til indlæsning en til dekodning og en til at sende lyd til lydkortet. Dermed går lyden ikke i stå hvis man på et tidspunkt skal vente på input fra disken. Man skal lige overveje hvor meget RAM man vil bruge på hhv. udekodet og dekodet lyd. Den dekodede lyd kan hurtigere sendes til lydkortet. Men hvis man skal vente på en disk, så rækker 1MB udekodet lyd længere end 1MB dekodet lyd. Hvis man beslutter sig for at man kan nøjes med den ene slags buffer, så kan man slå dekodningen sammen med en af I/O trådene og nøjes med en tråd. Den måde at afspille lyd på er også en fordel på maskiner med kun en CPU.
Tekstbehandling er en noget mere kompliceret opgave end lydafspilning. Men jeg vil tro det laves multitrådet af nogle af de samme grunde. Man ønsker ikke at alt skal gå i stå fordi den lige skal vente på en disk eller netværksfilsystem. CPU tunge opgaver er der nok ikke mange af i tekstbehandling, men de få steder hvor de er kan en multitrådet implementation hjælpe fordi man så stadigt godt kan lave noget mens en tråd arbejder i baggrunden. Men jeg tvivler på man kan nå at sætte programmet i gang med endnu en tung opgave før den første er færdig.
Med et spil er det anderledes. En lydafspiller kan sagtens indlæse noget lyd, der først skal afspilles om et minut. Men i et spil kan man altså ikke begynde på noget grafik, der først skal vises om et minut. Selv det der skal vises på skærmen om 30 millisekunder kan man ikke begynde på endnu, fordi det afhænger af brugerinputtet de næste 15 millisekunder. Et spil har heller ikke den slags opgaver man sætter i gang i baggrunden og hvor resultatet så kommer på et tidspunkt. Kunne man overhovedet se nogen fordel i at lave et multitrådet spil på en single CPU maskine, så ville det nok ende med at en tråd stod for tung grafikgenerering og tog hovedparten af CPU tiden. Dernæst komme fysiksimuleringer, men hvor meget CPU tid de tager ved jeg ikke.
Udfordringen nu er at udnytte CPU kraften så godt som muligt. Så giver det pludselig mening at dele grafikgenerering over flere tråde. Heldigvis er nogle slags grafikgenerering paralleliserbare. Med raytracing kan man f.eks. beregne samtlige pixels uafhængigt af hinanden, det er bare stadig for tungt til at gøre i realtime.
[url=#19]#19[/url] amokk
Her er det dog også nødvendigt med noget foranalyse, så billedet deles op så renderingstiden bliver den samme for de 2 GPUer.Det kan godt være at det er nødvendigt da GPUer ikke er så fleksible. Men på en multi CPU maskine kan det godt gøres smartere. Man kan f.eks. dele billedet op i 16 og så lade hver CPU starter på en del af billedet, når den så er færdig tager den en del mere indtil der ikke er flere tilbage. Så har den anden CPU højst 1/16 del af billedet tilbage når den første ikke har mere at arbejde på. Antallet af dele afhænger af et kompromis mellem det overhead, der er ved at skifte mellem to dele og den tid man kommer til at vente i sidste ende når kun en CPU har noget tilbage at arbejde på. De 16 dele var bare et skud i tågen, det kan sagtens tænkes at det i praksis ville være bedre med flere. Man skal også overveje om man vil have en tråd per CPU, en tråd per billedafsnit eller måske noget derimellem.
Her er et interview med Tim Sweeny(unreal) der handler om det samme. De har allerede gjort deres næste engine mulithreaded, og han siger også at det tager 2 til 3 gange så lang tid.
http://www.anandtech.com/cpuchipsets/showdoc.aspx?...
http://www.anandtech.com/cpuchipsets/showdoc.aspx?...
#15: "hvorfor ikke bare have det som nu, en kerne til spillet og en kerne til resten der køre i bagrunden"
På en spilkonsol tror jeg ikke der kører særligt mange ting i baggrunden. Og selv under Windows (hvor der godt nok foregår mange sære ting bag ens ryg) ville det være ret meget spild kun at bruge den ene CPU.
På en spilkonsol tror jeg ikke der kører særligt mange ting i baggrunden. Og selv under Windows (hvor der godt nok foregår mange sære ting bag ens ryg) ville det være ret meget spild kun at bruge den ene CPU.
Et stort problem ved bare at sige "jamen, så tager vi een kerne til grafikken, een kerne til fysikken, een kerne til lyden, een kerne til kaffemaskinen, osv" er, at man meget hurtigt løber tør for sådanne arbejdsopgaver. Man vil sidde med en masse kerner tilovers, da det vist roligt kan antages at antallet af kerner i nye CPU'er vil stige hurtigere end antallet af store parallelle arbejdsopgaver i spil.
Ifølge den gode Tim Sweeny (ved ikke om det er det interview der linkes til tidligere, er for doven til at klikke på det), så fantaserer de i stedet om en løsning hvor de har en lang række "general purpose"-tråde der bare står og venter på at få smidt arbejdsopgaver i hovedet dynamisk. Hvordan dette skal fungere i praksis har jeg ikke hørt så meget om.
Det er nok noget med at man som spiludvikler fremover skal tænke i "bittesmå afgrænsede opgaver med veldefinerede input/output" i stedet for bare at sige "grafik" eller "fysik" - altså opgaver der højest tager et par millisekunder at udføre. Disse kan så være indbyrdes afhængige af hinanden, og kan smides i hovedet på en tilfældig kerne. Svært at forklare, og jeg aner ikke hvor stort et overhead der må være. Nogle burde sætte sig ned og designe et sprog der havde det her indbygget :)
Ifølge den gode Tim Sweeny (ved ikke om det er det interview der linkes til tidligere, er for doven til at klikke på det), så fantaserer de i stedet om en løsning hvor de har en lang række "general purpose"-tråde der bare står og venter på at få smidt arbejdsopgaver i hovedet dynamisk. Hvordan dette skal fungere i praksis har jeg ikke hørt så meget om.
Det er nok noget med at man som spiludvikler fremover skal tænke i "bittesmå afgrænsede opgaver med veldefinerede input/output" i stedet for bare at sige "grafik" eller "fysik" - altså opgaver der højest tager et par millisekunder at udføre. Disse kan så være indbyrdes afhængige af hinanden, og kan smides i hovedet på en tilfældig kerne. Svært at forklare, og jeg aner ikke hvor stort et overhead der må være. Nogle burde sætte sig ned og designe et sprog der havde det her indbygget :)
#24 Problemet for spil er i stor grad at der ikke er så mange "uafhængige opgaver". Du kan fx ikke begynde at instruere grafikkortet før du har beregnet hvor alt du vil vise befinder sig, og det afhænger i nogle spil bl.a. af hvad du får at vide over netværket, og hvad din ai beslutter de "enheder" den styre skal gøre. AI'en beslutninger kan så igen afhænge af hvad menneskelige spillere har gjort. Hidtil har en temmeligt standard løsning været at når en frame skal renderes så udfører man de opgaver i rækkefølge: finder ud af hvad andre spillere har gjort siden sidste frame og foretager evt. interpolation på nogle data, dernæst ser man på hvad ai'en så vil gøre ud fra den situation og så render man. Det kræver en helt ny måde at tænke på virkeligt at udnytte multi-cores.
En helt anden ting er jo at de spiludviklere der udvikler til pc, ikke har den fordel at kende antal kerner og ej hellere hastigheden på kernerne, båndbreden mellem dem osv. Opgaven bliver jo væsentligt sværere når de skal skrive spil der kan bruge fx enten 1, 2 eller 4 kerner, og hvor der er meget stor forskel på båndbreden mellem kernerne (som fx nuværende forskel på amd og intel)
En helt anden ting er jo at de spiludviklere der udvikler til pc, ikke har den fordel at kende antal kerner og ej hellere hastigheden på kernerne, båndbreden mellem dem osv. Opgaven bliver jo væsentligt sværere når de skal skrive spil der kan bruge fx enten 1, 2 eller 4 kerner, og hvor der er meget stor forskel på båndbreden mellem kernerne (som fx nuværende forskel på amd og intel)
#25
Det er også derfor jeg mener at man skal kigge på langt mindre bider af gangen. Hvis "alt" bliver delt op i små bider, så burde det være muligt at lave en form for dynamisk skedulering i spillet, og programmøren behøver ikke bekymre sig specielt meget over hvordan de enkelte konfigurationer ser ud. Ved udemærket godt at det ikke kan lade sig gøre i dag, men tror helt klart at det er fremtiden.
Men det bliver da godt nok et helvede at debugge medmindre man opfinder nogle nye smarte metoder.
Det er også derfor jeg mener at man skal kigge på langt mindre bider af gangen. Hvis "alt" bliver delt op i små bider, så burde det være muligt at lave en form for dynamisk skedulering i spillet, og programmøren behøver ikke bekymre sig specielt meget over hvordan de enkelte konfigurationer ser ud. Ved udemærket godt at det ikke kan lade sig gøre i dag, men tror helt klart at det er fremtiden.
Men det bliver da godt nok et helvede at debugge medmindre man opfinder nogle nye smarte metoder.
#26
Tja det ender jo med at vi om 10 år har maskiner med 16 CPUer hvor de 12 bruges til system-overhead, administrative opgaver og til at holde styr på alle de abstraktionslag som er nødvendige for at et mennesk kan kode til den... og de sidste 4 laver så noget reelt arbejde :-)
Tja det ender jo med at vi om 10 år har maskiner med 16 CPUer hvor de 12 bruges til system-overhead, administrative opgaver og til at holde styr på alle de abstraktionslag som er nødvendige for at et mennesk kan kode til den... og de sidste 4 laver så noget reelt arbejde :-)
#3, det er MEGET svært at skrive et multithreaded program, især til flere CPU'er.
Først med 1.5 er Javas memory model f.eks. blevet ændret til at håndtere nogle af problemerne (java.util.concurrent frameworket er resultatet). C++ der forhåbentlig får en ny standard i 2009 har ikke noget med threading og slet ikke til multikerne/multiprocessor systemer.
Så jo det ER svært. bare fordi du laver en lock på et eller andet, betyder det faktisk ikke at selve variablen ligger, der hvor du tror den gør (i hukommelsen). Compileren kan have optimeret koden sådan at en anden CPU ikke ville se din lock. Og så er der jo hele problemet med variable i de forskellige caches.
Så det er ret svært, men folk arbejder da på det (og har også gjort det lidt). Læs evt. JSR-133: Java Memory Model and Thread Specification eller Doug Leas dokument om util.concurrent frameworket.
Først med 1.5 er Javas memory model f.eks. blevet ændret til at håndtere nogle af problemerne (java.util.concurrent frameworket er resultatet). C++ der forhåbentlig får en ny standard i 2009 har ikke noget med threading og slet ikke til multikerne/multiprocessor systemer.
Så jo det ER svært. bare fordi du laver en lock på et eller andet, betyder det faktisk ikke at selve variablen ligger, der hvor du tror den gør (i hukommelsen). Compileren kan have optimeret koden sådan at en anden CPU ikke ville se din lock. Og så er der jo hele problemet med variable i de forskellige caches.
Så det er ret svært, men folk arbejder da på det (og har også gjort det lidt). Læs evt. JSR-133: Java Memory Model and Thread Specification eller Doug Leas dokument om util.concurrent frameworket.
#21
"Man kan f.eks. dele billedet op i 16 og så lade hver CPU starter på en del af billedet, når den så er færdig tager den en del mere indtil der ikke er flere tilbage. "
Nu er det næppe der man vil lægge krafterne længere, da GPU'en tager en stor del af byrden. Der er også det problem ved at opdele at man så for seksten områder skal vurdere hvilke objekter der er i dem. Hvis et objekt er på grænsen mellem fire områder, hvilket område vil du så tildele behandlingen? Hvis du vil dele opjektet op, så koster det en del tid. Man kan naturligvis vælge at lade området med laveste indeks tage fælles objekter og så have områder med forskellig belastning, men så er du stadig ude i at du skal bruge flere resourcer på at opdele opgaven.
Der skal ikke være nogen tvivl om at det er nemmere med een cpu så du ikke skal vride dit design for at fordele belastningen jævnt på flere.
Som du siger, så er der naturligvis områder hvor det er elementært at køre paralels. Eksempelvis raytracing, men polygonaliserede objektet der ikke tegnes som enkeltpixels... kan godt se problemerne.
Grafikken er endda kun et element. Dertil kommer fysikken og Ai'en som store tidsslugere.
"Man kan f.eks. dele billedet op i 16 og så lade hver CPU starter på en del af billedet, når den så er færdig tager den en del mere indtil der ikke er flere tilbage. "
Nu er det næppe der man vil lægge krafterne længere, da GPU'en tager en stor del af byrden. Der er også det problem ved at opdele at man så for seksten områder skal vurdere hvilke objekter der er i dem. Hvis et objekt er på grænsen mellem fire områder, hvilket område vil du så tildele behandlingen? Hvis du vil dele opjektet op, så koster det en del tid. Man kan naturligvis vælge at lade området med laveste indeks tage fælles objekter og så have områder med forskellig belastning, men så er du stadig ude i at du skal bruge flere resourcer på at opdele opgaven.
Der skal ikke være nogen tvivl om at det er nemmere med een cpu så du ikke skal vride dit design for at fordele belastningen jævnt på flere.
Som du siger, så er der naturligvis områder hvor det er elementært at køre paralels. Eksempelvis raytracing, men polygonaliserede objektet der ikke tegnes som enkeltpixels... kan godt se problemerne.
Grafikken er endda kun et element. Dertil kommer fysikken og Ai'en som store tidsslugere.
Hvis det er så svært kan man måske tjene penge som programmør igen ;)
http://www.phy.duke.edu/~rgb/Beowulf/c++_interview...
http://www.phy.duke.edu/~rgb/Beowulf/c++_interview...
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund