Új hozzászólás Aktív témák

• #62 ddekany veterán orbano #61

  Új Válasz 2008-12-03 19:35:04 #62

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz orbano #61 üzenetére

  "2.0-nál sem a win32-t implementálod"

  (Én arról beszéltem fentebb, hogy Win32 API-ra építve valósítod meg a .Net-et, tehát ha van Win32 API implementációd, akkor akár egy sima alkalmazások, a .Net is futhatna.)

  Amúgy ja, olyan ez is mint a Java... vagy gondolom még rosszabb is. Ott is elvileg bárki implementálhatná az egész platformot, és a VM még nem is lenne gáz, de a gigászi API... képtelenség, főleg mert a meglévő alkalmazások a Sun féle olyan viselkédési részletein függhetnek, amik nincsenek is kikötve a speckóban...

• #37 dezz nagyúr orbano #36

  Új Válasz 2008-11-30 01:31:37 #37

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dezz

  nagyúr

  válasz orbano #36 üzenetére

  Az lehet.

• #35 dezz nagyúr orbano #34

  Új Válasz 2008-11-29 22:00:31 #35

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dezz

  nagyúr

  válasz orbano #34 üzenetére

  Pedig az eltérő codepath-ek azt jelentik, hogy bizonyos dolgokat máshogy kell megoldani, shadereket máshogy kell megírni. Ez már kicsit túlmutat a sima optimizáción.

  Említettem a GS-t: az NV-n olyan lassú lenne, hogy inkább nem is foglalkoznak vele, mert a potenciális vásárlók fele kiesne.

  A Larrabee pl. procedurális dolgokban, esetleg ray-tracing effektekben lehet nagyon jó, mert a GPU-kkal szemben egy CPU-nak sokkal jobban fekszenek az ugrások, véletlenszerű memóriahozzáférések. (Pl. a Cell procin is 6x gyorsabb a ray-tracing, mint a 2x nagyobb peak GFLOPS-szal rendelkező G80-on.) Ugyanakkor a viszonylag egyszerűbb eljárások sokaságán jobban rágja át magát a nyers erejével a GPU.

  Ha lesz valamilyen jelentős terület, amiben a Larrabee sokkal jobb lesz, mint a megszokott GPU-k, és akár maguktól, akár az Intel rásegítésével elkezdik használni a játékfejlesztők, a többieknek, ill. leginkább az Nvidiának fájhat a feje.

• #33 dezz nagyúr orbano #32

  Új Válasz 2008-11-29 19:48:21 #33

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dezz

  nagyúr

  válasz orbano #32 üzenetére

  Ideális esetben így lenne, de a gyakorlatban ez már ott bukik, hogy nincs két egyforma GPU sem, a feladatok végrehajtásának hatékonyságát, sőt egyátalán a támogatott fícsörök terén... Eltérő hozzáállást kíván pl. a DX9 és DX10 -> eltérő code-path. R6xx/7xx vs. G8x/9X/GT2xx -> DX10.1 vs. DX10. A G8x/9x-esek még a DX10 egyes fícsörjeiben is használhatatlanul lassúak (pl. Geometry Shader). Ha más nem, a shaderprogramok számára nem igazán lesz mindegy, hogy egy sok számolóegységes GPU-n, vagy egy 16 magos CPU-félén (Larrabee) fut. Szerencsére az Intel is belátta, hogy nem bízhat mindent a CPU magokra, mert sok dologhoz 16-32 is kevés lenne: a Larrabee-ben is lesznek fix-funkciós (pl. textúrázó, stb.) egységek. De nyugodtan elképzelhető, hogy bizonyos megoldások nagyon, vagy éppen nagyon nem fognak neki feküdni. És ezek nem fognak feltétlenül egybeesni a megszokott GPU-k esetével.

Új hozzászólás Aktív témák