mboost-dp1
unknown
Det hedder Pixel Pipelines og ikke Pixel Processorer.
Linket til artiklen er i øvrigt nede for opgraderinger :-(
Men godt man har sin Xbox 360 og ikke skal kyle penge efter den slags opgraderinger længere! ;-)
Linket til artiklen er i øvrigt nede for opgraderinger :-(
Men godt man har sin Xbox 360 og ikke skal kyle penge efter den slags opgraderinger længere! ;-)
#1
Surt at du ikke kan få så meget eye candy som man kan med dette nye kort :p
(Selvom det sikkert koster det dobbelte af en xbox 360..)
"Pixel Shader Processors":
ATI Radeon X1900 XT 512MB 48
NVIDIA GeForce
7800 GTX 512MB 24
Såå nej. Det hedder pixel processors (eller pixel shaders).
Det er heftigt nok at den kan bruge 175 watts. For mig virker det som om grafikkort altid er et trin efter CPU producenterne.
- De kører mhz race i øjeblikket
- De bruger en arkitektur der er et trin større (90 nm vs 65 nm)
- De går stadig efter ydelse på bekostning af varme / strøm
Men det er måske bare mig der ikke ved en bjælde om noget?
Surt at du ikke kan få så meget eye candy som man kan med dette nye kort :p
(Selvom det sikkert koster det dobbelte af en xbox 360..)
Det hedder Pixel Pipelines og ikke Pixel Processorer.
"Pixel Shader Processors":
ATI Radeon X1900 XT 512MB 48
NVIDIA GeForce
7800 GTX 512MB 24
Såå nej. Det hedder pixel processors (eller pixel shaders).
Det er heftigt nok at den kan bruge 175 watts. For mig virker det som om grafikkort altid er et trin efter CPU producenterne.
- De kører mhz race i øjeblikket
- De bruger en arkitektur der er et trin større (90 nm vs 65 nm)
- De går stadig efter ydelse på bekostning af varme / strøm
Men det er måske bare mig der ikke ved en bjælde om noget?
Der er ikke tale om 48 rigtige pipelines, kun 48 pixel shaders hvilket vil sige den kan shade 48 pixels per clock cycle! Men hvor er det voldsomt at bruge 175W og så endda være baseret på en 90nm process, den kræver i så fald væsentlig mere køling end selv en Pentium Extreme Edition 840.
#6
Den kan udføre, i teorien, 3 gange så mange pixel shader operationer per clock cycle i forhold til R520. Dette kommer dog kun til sin ret ved nye spil der bruger pixel shadere meget. I fremtiden hvor spil vil blive endnu mere afhængige af pixel shadere til at levere deres effekter, vil R580 stå endnu stærkere. Det er dette ATI satser på, om det kommer til at holde vand vil tiden vise.
Den kan udføre, i teorien, 3 gange så mange pixel shader operationer per clock cycle i forhold til R520. Dette kommer dog kun til sin ret ved nye spil der bruger pixel shadere meget. I fremtiden hvor spil vil blive endnu mere afhængige af pixel shadere til at levere deres effekter, vil R580 stå endnu stærkere. Det er dette ATI satser på, om det kommer til at holde vand vil tiden vise.
#7
Jeg kunne godt selv regne ud at den har 3 gange så mange Pixel Shader Processors :o)
Men det svarer ikke på mit ? om hvad det så er den kan gøre 3 gange så hurtigt??
Kan den behandle 3 gange så mange vertex (tror ikke det er det). 3 gange så mange pixels (kunne gode være det, man hvad hjælper det, når det samme antal vertex først skal beklædes med billerder og bumps inden de bliver til pixels). Eller er det noget helt andet???
Jeg kunne godt selv regne ud at den har 3 gange så mange Pixel Shader Processors :o)
Men det svarer ikke på mit ? om hvad det så er den kan gøre 3 gange så hurtigt??
Kan den behandle 3 gange så mange vertex (tror ikke det er det). 3 gange så mange pixels (kunne gode være det, man hvad hjælper det, når det samme antal vertex først skal beklædes med billerder og bumps inden de bliver til pixels). Eller er det noget helt andet???
#9 Tænk på en pipeline som flyder med færdigbehandlede pixels, i dette tilfælde 16. Forholdet 3:1 dækker over pixel info behandling vs. texture/rendering behandling (i den færdige pipeline). Xbox360's GPU har også 48 shadere og det forventes at Nvidia's G71 vil få det samme.
Synes godt nok det er underligt, de ikke brúger et større system. Tror heller ikke helt man kan regnede med resultatet, da de jo kørte testen med Catalyst 5.13, som i bund og grund ikke understøtter X1900, så mon ikke vi ser en større forskel når de tester med en som understøtter det.
#9
For lige hurtigt at opridse.
En vertex shader kan manipulere vertex data. Det betyder at den modtager vertex data fra et tidligere skridt i pipelinen, som den så kan få til at ændre sig.
Det kunne f.eks være at grafikkortet har renderet nogle græsstrå som du gerne vil have til at blafre i vinden. Du kan så skrive et vertex program der tager det "færdige" græsstrå (i form af en bunke vertices) og manipulere fysikken i det således at det står og svejer.
En pixel shader kan foretage manipulationer på pixels. Eller... inde i grafikkortet kaldes det fragmenter. Så hvis du hører om en fragment shader er det det samme som en pixel shader.
Anyways. Pixelshaderen ligger længere henne i pipelinen end vertexshaderen, og den modtager data om en pixels. Det kan som ved vertex shaderen være en "færdig" pixel(fragment). Som er sampled, positioneret og farvet. Hele molivitten. Pixelshaderen har nu mulighed for (ligesom ved vertex shaderen) at manimupere denne data. Kunne f.eks være at græstrået fra før pludselig er vådt. Du kan så skrive et pixel program der kan ændre hvordan de her pixels nu ser ud. Kunne være der var reflektioner eller lysefekter du gerne ville "lægge ned" over græs strået.
Med 48 Pixel kerner kan du afvikle sådan et program ca. 3 gange hurtigere ened med 16.
Her er et link til en noget gammel, men ret god artikel omkring shadere. Det er IKKE en pixie bog at læse.
Hver pixel kerne i ATIs kort består af en Vector MADD ALU, en Vector ADD ALU og en Branch Execution Unit.
Se beyond3d's review for detaljer.
For lige hurtigt at opridse.
En vertex shader kan manipulere vertex data. Det betyder at den modtager vertex data fra et tidligere skridt i pipelinen, som den så kan få til at ændre sig.
Det kunne f.eks være at grafikkortet har renderet nogle græsstrå som du gerne vil have til at blafre i vinden. Du kan så skrive et vertex program der tager det "færdige" græsstrå (i form af en bunke vertices) og manipulere fysikken i det således at det står og svejer.
En pixel shader kan foretage manipulationer på pixels. Eller... inde i grafikkortet kaldes det fragmenter. Så hvis du hører om en fragment shader er det det samme som en pixel shader.
Anyways. Pixelshaderen ligger længere henne i pipelinen end vertexshaderen, og den modtager data om en pixels. Det kan som ved vertex shaderen være en "færdig" pixel(fragment). Som er sampled, positioneret og farvet. Hele molivitten. Pixelshaderen har nu mulighed for (ligesom ved vertex shaderen) at manimupere denne data. Kunne f.eks være at græstrået fra før pludselig er vådt. Du kan så skrive et pixel program der kan ændre hvordan de her pixels nu ser ud. Kunne være der var reflektioner eller lysefekter du gerne ville "lægge ned" over græs strået.
Med 48 Pixel kerner kan du afvikle sådan et program ca. 3 gange hurtigere ened med 16.
Her er et link til en noget gammel, men ret god artikel omkring shadere. Det er IKKE en pixie bog at læse.
Hver pixel kerne i ATIs kort består af en Vector MADD ALU, en Vector ADD ALU og en Branch Execution Unit.
Se beyond3d's review for detaljer.
Sørgeligt at både nVidia og ATI fuldstændigt blindt fortsætter med at forøge hastigheden på deres kort, i dette tilfælde antallet af pixel shaders, uden at skænke de direkte omkostninger for strømforbruget/varmeudledelsen en tanke. I sig selv finder jeg det overdrevent at man nu er nødt til at have en seperat 12v tilslutning i sit GFX kort, bare for at holde det kørende. Man oplever præcis samme problemer med varmen som ved processoren, det er for høj varmeudvikling på kortet, dette kræver større køleprofil/mere effektiv køling, der i sidste ende relsuterer i et monster af en gfx køler der står og pumper varm luft ud af kabi+larmer som en jetjager ;) Mener bestemt ikke den nuværende løsning ifht. strømforbruget og varmeudledelsen er holdbar og derfor ville det være ønskeligt om de to GFX producenter lagde lidt mindre kræfter i konstant forøgelse af hastigheden på deres kort og i stedet brugte lidt tid på at finde nogle mere holdbare/effektive køleløsninger samt en nedsættelse af strømforbruget.
@ondepik
Jeg har tænkt lidt over situationen mht. gpu/cpu udviklingen, og det lader til at du er ret langt inde i gpu-afdelingen, så det kan være du kan give mig lidt input til mine betragtninger.
Som jeg forstår det, så er udviklingen generelt, og også den her release, imod længere pipelines med flere funktioner, og altså flere levels af logik. Dog er der jo her tale om større reel regnekapacitet (flere ALU'er) men er de fordelt over eksisterende pipelines (der så bliver længere), eller udgør de nye pipelines tilsvarende de tidligere?
Det vi ser nu i forhold til længere pipelines og mere funktionalitet i hardwaren, ligner jo til forveksling hvad vi har set med cpu'er. Men trenden er skiftende. de første x86'ere var store og tunge (logisk set) og i pentiumerne kom der flere og flere lange pipelines og en allerhelvedes masse microcode ind. I løbet af sluthalvfemserne begyndte intel især at kigge nærmere på nogle af fordelene ved RISC-arkitekturen, og det satte i høj grad krigen på hastighed ind, med mindre logik kan man køre hurtigere (færre lag af logik). problemet er nu at halvleder-teknologien ikke fulgte med, og pludselig begynder vi at kunne se grænsen for hvor hurtigt vi kan få vores transistorer til at arbejde. i starten af det nye årtusind er AMD ved at sætte trenden med mere arbejde per cycle, og antallet og længden af pipes vokser støt, samtidig med at hastigheden ikke gør samme fremskridt som før.
mere logik per chipareal = større varmeudledning.
Som jeg ser det har gpu'erne ikke været igennem den her "RISC-fase", hvor man barberer ned på microcoden og arbejder på at få rigtig stor hastighed. fordelen rammer ofte i form af lavere effektforbrug ved reducering af antallet af transistorer.
Er det en trend vi kommer til at se på gpu'er, eller er egner koncepterne sig simpelthen ikke til denne form for databehandling?
Jeg har tænkt lidt over situationen mht. gpu/cpu udviklingen, og det lader til at du er ret langt inde i gpu-afdelingen, så det kan være du kan give mig lidt input til mine betragtninger.
Som jeg forstår det, så er udviklingen generelt, og også den her release, imod længere pipelines med flere funktioner, og altså flere levels af logik. Dog er der jo her tale om større reel regnekapacitet (flere ALU'er) men er de fordelt over eksisterende pipelines (der så bliver længere), eller udgør de nye pipelines tilsvarende de tidligere?
Det vi ser nu i forhold til længere pipelines og mere funktionalitet i hardwaren, ligner jo til forveksling hvad vi har set med cpu'er. Men trenden er skiftende. de første x86'ere var store og tunge (logisk set) og i pentiumerne kom der flere og flere lange pipelines og en allerhelvedes masse microcode ind. I løbet af sluthalvfemserne begyndte intel især at kigge nærmere på nogle af fordelene ved RISC-arkitekturen, og det satte i høj grad krigen på hastighed ind, med mindre logik kan man køre hurtigere (færre lag af logik). problemet er nu at halvleder-teknologien ikke fulgte med, og pludselig begynder vi at kunne se grænsen for hvor hurtigt vi kan få vores transistorer til at arbejde. i starten af det nye årtusind er AMD ved at sætte trenden med mere arbejde per cycle, og antallet og længden af pipes vokser støt, samtidig med at hastigheden ikke gør samme fremskridt som før.
mere logik per chipareal = større varmeudledning.
Som jeg ser det har gpu'erne ikke været igennem den her "RISC-fase", hvor man barberer ned på microcoden og arbejder på at få rigtig stor hastighed. fordelen rammer ofte i form af lavere effektforbrug ved reducering af antallet af transistorer.
Er det en trend vi kommer til at se på gpu'er, eller er egner koncepterne sig simpelthen ikke til denne form for databehandling?
#19 Selv om du adresserer ondepik vil jeg alligevel tillade mig at skrive mine 2 cents.
Man kan slet og ret ikke sammenligne CPU'er og GPU'er, da de arbejder ud fra vidt forskellige præmisser. Mens en CPU's arbejdsopgaver er enormt uforudsigende, går utrolig meget ud på at forsøge at forudsige og optimere den ene (sommetider 2) pipeline. Vi snakker her teknologier som L1 og L2 cache, HyperThreading og branch prediction - alle med til at søge for at pipelinen udnyttes bedst muligt. Intel's pipeline har i mange år nu været utrolig lange, hvilket kan være en bekostelig affære for en CPU men som har sin styrke ved forudseende kode som f.eks. komprimering mens AMD's korte pipeline glimrer i spil, netop fordi det er en ret uforudsigelig opgave.
GPU'er har ikke helt samme problem. 3D bearbejdning består i hovedtræk af at beregne relaterede punkter (ofte danner 3 punkter/vertices en 3-kant) som derefter skal påklædes en texture. En GPU pipeline er delt op i Vertex shader og Pixel shader for at løse denne opgave, der er altså ingen umiddelbar mulighed for at "noget går galt" midt i denne bearbejdning. Fordi der er millioner af pixels der skal beregnes op til 100 gange i sekundet, egner dette problem sig simpelthen bedre til parallelisering (16 pipes) og/eller et komplekst CISC design.
Derudover, husk på at mens en CPU skal køre mange vidt forskellige processer "samtidigt" (via context switching), har en GPU den fordel, at der (som regel) er én skærm og én process den skal arbejde på.
Man kan slet og ret ikke sammenligne CPU'er og GPU'er, da de arbejder ud fra vidt forskellige præmisser. Mens en CPU's arbejdsopgaver er enormt uforudsigende, går utrolig meget ud på at forsøge at forudsige og optimere den ene (sommetider 2) pipeline. Vi snakker her teknologier som L1 og L2 cache, HyperThreading og branch prediction - alle med til at søge for at pipelinen udnyttes bedst muligt. Intel's pipeline har i mange år nu været utrolig lange, hvilket kan være en bekostelig affære for en CPU men som har sin styrke ved forudseende kode som f.eks. komprimering mens AMD's korte pipeline glimrer i spil, netop fordi det er en ret uforudsigelig opgave.
GPU'er har ikke helt samme problem. 3D bearbejdning består i hovedtræk af at beregne relaterede punkter (ofte danner 3 punkter/vertices en 3-kant) som derefter skal påklædes en texture. En GPU pipeline er delt op i Vertex shader og Pixel shader for at løse denne opgave, der er altså ingen umiddelbar mulighed for at "noget går galt" midt i denne bearbejdning. Fordi der er millioner af pixels der skal beregnes op til 100 gange i sekundet, egner dette problem sig simpelthen bedre til parallelisering (16 pipes) og/eller et komplekst CISC design.
Derudover, husk på at mens en CPU skal køre mange vidt forskellige processer "samtidigt" (via context switching), har en GPU den fordel, at der (som regel) er én skærm og én process den skal arbejde på.
->#17 du kan jo bare underclocke dit videokort hvis du vil have bedre køling. Da nvidia gik fra 6800 til 7800 sænkede de faktisk strømforbruget en lille smule samtidigt med at ydelsen steg, så det er rent BS at de ikke tænker på strømforbruget, især fordi de godt ved at med lavere strømforbrug kan de øge hastigheden på GPU'erne hvilket 99% af brugerne foretrækker. De resterende 1% kan så købe et grafikkort de yder mindre men også bruger mindre strøm. Hvis du har en GPU der giver god ydelse ved fx 300Mhz og næsten ingen støm bruger og ingen varme udvilker, så vil den GPU sikkert også kunne køre ved 600Mhz, og bruge mere strøm og udvikle en masse varme. Men så vil de fleste alligevel vælge at køre den ved 600Mhz.
Samtidigt er der både 2D og 3D frekvenshastigheder hvilket gør at når du ikke spiller så mindskes strømforbruget.
Samtidigt er der både 2D og 3D frekvenshastigheder hvilket gør at når du ikke spiller så mindskes strømforbruget.
#20
Det er en god betragtning. Som udgangspunkt (hvis vi ignorer muligheden for tearing og kun arbejder i hele frames), så har vi altid en fyldt og forudsigelig buffer at arbejde med.
En anden pointe jeg er kommet i tanke om relaterer også til hastigheden. GPU'en skal kunne spytte data ud i en fast rate (60-100 MHz), og der er faktisk ikke behov for at lige netop den båndbredde ændres. Derfor gælder det naturligvis om at have en process der lige netop er så lang at dette kan nåes, og så ellers bearbejde dataene så meget som muligt fra de lander i en buffer/drawliste/whatever til de skal vises på skærmen.
RISC-konceptet går på mange måder også ud på at forhøje den eksterne båndbredde til chippen.
Det er en god betragtning. Som udgangspunkt (hvis vi ignorer muligheden for tearing og kun arbejder i hele frames), så har vi altid en fyldt og forudsigelig buffer at arbejde med.
En anden pointe jeg er kommet i tanke om relaterer også til hastigheden. GPU'en skal kunne spytte data ud i en fast rate (60-100 MHz), og der er faktisk ikke behov for at lige netop den båndbredde ændres. Derfor gælder det naturligvis om at have en process der lige netop er så lang at dette kan nåes, og så ellers bearbejde dataene så meget som muligt fra de lander i en buffer/drawliste/whatever til de skal vises på skærmen.
RISC-konceptet går på mange måder også ud på at forhøje den eksterne båndbredde til chippen.
de nye dual gf kort fra nvidia bruger faktist en ekstern strømforsyning da psu'en ikk kan klare den mængde strøm der skal til for at få fut i det... syntes det er langt ude men hvad gør de ikke for at være det mest hardcore gfx kort der ude? det næste er vel at de bliver nødt til at opfinde kold fussion for at få det til køre
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