DirectX på OSX???

Der er vist ikke meget mere overlap mellem DirectX (et sæt MS API'er til windows) og OSX (Apples OS) end X'et.

Så vidt jeg ved er 3D API'et man bruger til OSX det samme som det man bruger på alle andre OS'er: OpenGL.

Direct3D (en del af det man kalder for DirectX) er begrænset til windows.

Hvorfor 2 processorer?

Jeg er helt med på, hvorfor man historisk har opdelt grafik og øvrige applikationer på 2 processorer. Men nu kan man afvikle programmer på GPU'en og Intel vil integrere grafik på deres næste Atom processor.

Det virker som om de 2 processortyper nærmer sig hinanden, og derfor er $100.000 spørgsmålet, om det på sigt kan betale sig at have 2 forskellige processorer med al det besvær det trods alt også giver...

Nogen der har meninger om det?

Re: Hvorfor 2 processorer?

Jeg er helt med på, hvorfor man historisk har opdelt grafik og øvrige applikationer på 2 processorer. Men nu kan man afvikle programmer på GPU'en og Intel vil integrere grafik på deres næste Atom processor.

Den omtalte Atom processor får kun integreret grafik i den forstand, at grafikprocessoren bliver lagt på samme chip som Atom processoren. Det er stadig to separate processorer med hvert deres instruktionssæt.

Når man historisk har opdelt i to processorer, skyldes det i reglen, at "applikationsprocessoren" skal kunne køre gamle programmer. I Intels tilfælde specifikt MS Windows og programmer til Windows. Men grafik er ofte mere regulært end applikationer og kan bedre udnytte parallelisme. Derfor har grafikprocessorer ofte mange beregningsenheder, der dog oftest har været ret begrænsede i hvad, de kunne beregne. Der er dog sket et skift i det seneste årti, hvor grafikprocessorerne bliver mere og mere generelle, så man kan lægge generelle beregninger ud på dem. Det kræver dog stadig, at man programmerer specielt til den givne processor -- selv om man bruger et højniveausprog som C++ eller Python, kan man ikke bare genoversætte programmerne og regne med at udnytte parallelismen. Faktisk vil de færreste programmer i det hele taget kunne køre (selv uden parallelisme) på en grafikprocessor uden, at de skrives betragteligt om, for de enkelte processorelementer på en grafikprocessor har typisk meget lidt lager, så man løber hurtigt tør. Endvidere mangler grafikprocessorerne typisk ting, der er nødvendige for operativsystemer, såsom interrupts.

Derfor vil programmer, der bruger en grafikprocessor, typisk have et hovedprogram, der kører på applikationsprocessoren, mens særligt beregningskrævende (og let paralleliserbare) delberegninger udføres på grafikprocessoren.

Man kan godt forestille sig, at en grafikprocessor i stil med Nvidias nye udvides med de ting, der skal til for at køre operativsystemer, så man kan undvære en applikationsprocessor. Men så ma man opgive at køre gammel software og skrive både operativsystem og applikationer om fra bunden -- med eksplicit hensyn til parallelisme og de begrænsninger, de enkelte processorelementer har.

Re: Re: Hvorfor 2 processorer?

Intel havde vist idéer om at lave grafikprocessorer baseret på små X86 CPU'er der inkluderede en floating point processor. I så fald, er vi tæt på samme indstruktionssæt - eller type indstruktionssæt for hovedprocessor og grafik processor. Alligevel, vil deres konfiguration nok gøre, at der skal programmeres specielt til dem - men teoretisk kan de sikkert godt få nogle hundrede 386 eller 486 kerner, der kører ved stor hastighed, til at sidde i en matrix på en chip. Hvis Intel integrerer hundreder af processorer på en chip, er der muligvis dele der kan "genbruges", og som ikke behøver at sidde for hver CPU. Intel er for længst gået bort fra deres "tunge" indstruktionssæt, og har en indre RISC kerne i alle nyere pentium processorer. Det betyder, at koden der afvikles, først oversættes til et andet RISC sprog. Man kunne forestille sig, at denne oversætter, kunne være fælles, så de reelt har et stort antal små RISC processorer, hvor de har udviklet en oversætter til, som oversætter fra X86 til deres interne RISC sprog.

Hvilket kedeligt og

intetsigende billede. Sæt dog et rigtigt billede af en chip ind.

POV-RAY:
#include "colors.inc"
global_settings {
ambient_light color rgb 2
assumed_gamma 1.0
}
camera {
location <80.0, 35.5, -240.0>
direction 1.5*z
right x*image_width/image_height
look_at <80.0, 25.0, 0.0>
}
sky_sphere { pigment { color Black } }
light_source {
<80, 30, 10> // light's position (translated below)
color rgb <1, 1, 1> // light's color

spotlight
point_at <80,0,0>
radius 20
}
plane {
y, -4
pigment { color rgb Green }
finish { ambient 0 }
}
union
{
#local ii1 = 0;
#while (ii1<512)
#local px1 = mod(ii1,32)*4 div( mod(ii1,32),4);
#local py1 = div(ii1,32)*5 div(ii1,256)*4;
box { 0,2 translate <px1,py1,-10> }
#local ii1 = ii1 1;
#end // while
pigment
{
bozo
color_map
{
[ 0.0 color Green ]
[ 1.0 rgb <0.1,0.6,0.1> ]
}
scale 100
}
no_shadow
no_reflection
}

Tid til at programmere 10 min.
Rendertid: 2 sekunder
På en standard single-core cpu.

Re: Re: Hvorfor 2 processorer?

"Endvidere mangler grafikprocessorerne typisk ting, der er nødvendige for operativsystemer, såsom interrupts."

Det er nok mere manglende programforgreninger (spring), som gør det umuligt at afvikle almindelige programmer.

Re: Re: Re: Hvorfor 2 processorer?

Programforgreninger er intet problem på en moderne GPU'er, hvis du da mener betinget kode (if-statements) og løkker (do-while, while, for). For et par generationer tilbage, udførte GPU'erne begge grene af betinget kode og maskede den uønskede gren ud bagefter. Ligeledes blev løkker altid udrullet. Men på en moderne GPU sker dette nu ligesom mange man forventer på de fleste CPU'er - der bliver hoppet.

Med Fermi er cache og lager er snart oppe i størrelser som vi er vant til for CPU'er (henholdvis MB og GB). De har dog ikke som Torben nævner ikke interupts.

Desuden bruger CPU'er en frygtelig masse transistorer for at yde godt på enkelt-trådede programmer, hvor GPU'er derimod bruger deres transistorer på at yde godt for flere-trådede programmer. De er fundementalt set designet helt forskelligt, og derfor brillierer de på hvert deres område. Jeg tror godt vi kan forberede os på at PC'en skal have begge typer processorer i en del år fremover (det bliver ikke 486SX versus 486DX lige med det samme). De komplementerer hinanden.

Mht Mac OSX, Fermi og Windows 7

JEg tror det der er på spil er hhv. OpenCL, nVidia CUDA

Re: Mht Mac OSX, Fermi og Windows 7

Med Fermi er cache og lager er snart oppe i størrelser som vi er vant til for CPU'er (henholdvis MB og GB). De har dog ikke som Torben nævner ikke interupts.

Interrupts er også lidt ustrukturerede, og anvender ofte tid på at hente og gemme registre. Som navnet antyder "bryder de ind" i koden. Og det betragter jeg som ustruktureret. Jeg vil foretrække nogen, der opstartes som en process, og hvor der ikke skal gemmes/hentes data fra stak, men at interruptet har sin egen IP, status og arbejdsregister, hvis der er sådant, og fungerer som et task skift, fremfor at forstyre koden ved at den får et kald.