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

• #516 gbors nagyúr Abu85 #515

  Új Válasz 2013-07-01 16:15:03 #516

  Ú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

  

  gbors

  nagyúr

  LOGOUT blog

  válasz Abu85 #515 üzenetére

  már kik kezdtek el ilyen motort írni?

• #514 gbors nagyúr Abu85 #512

  Új Válasz 2013-07-01 15:35:17 #514

  Ú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

  

  gbors

  nagyúr

  LOGOUT blog

  válasz Abu85 #512 üzenetére

  hát ez aztán nem nehéz kérdés. ilyen motort lényegesen nagyobb költség írni, mint egy "hagyományosat" - időben is tovább tart, jobban képzett programozók kellenek hozzá, és komplikáltabb a tesztelése. az, hogy ezért cserébe azonos hardveren duplaanyi fps-t produkálna, pont senkit nem érdekel, mert attól egy darabbal sem adnak el többet - sőt, akár kevesebbet, mert a mindenféle tesztekben való feltűnés is generál sales-t, és ha egy 7790-en vagy egy gtx 650 ti-n 100 fps-sel megy valami, akkor azt ugyan melyik hardveroldal fogja tesztelni?

• #373 gbors nagyúr Abu85 #368

  Új Válasz 2013-06-26 00:55:03 #373

  Ú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

  

  gbors

  nagyúr

  LOGOUT blog

  válasz Abu85 #368 üzenetére

  az előbb azt írtad, hogy a PCI-E busz túl lassú, arra válaszoltam - az a része pont olyan egyszerű.
  GP API-nak meg ott az OpenCL. nem mondhatni, hogy szárnyal a népszerűsége, de erre pont jó lenne.

• #261 gbors nagyúr agressiv #253

  Új Válasz 2013-06-24 23:35:34 #261

  Ú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

  

  gbors

  nagyúr

  LOGOUT blog

  válasz agressiv #253 üzenetére

  feladat-offload-ról volt szó, amihez forrásadatokat kell felküldeni, aztán az eredményt fogadni. szilárdtest-szimuláció esetén ez lehet mondjuk egy vertex-lista, ami nagyságrendileg több 10 (vagy akár több 100) kbyte - szóval a késleltetés nem faktor.

• #252 gbors nagyúr Abu85 #246

  Új Válasz 2013-06-24 22:52:42 #252

  Ú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

  

  gbors

  nagyúr

  LOGOUT blog

  válasz Abu85 #246 üzenetére

  8 GB/sec a 2.0-s busz 16 sávon - ez majdnem annyi, mint az 1066-os DDR2/DDR3 RAM. realtime adatmanipulációhoz nyilván nem elég, de az adatcsomagok cseréjéhez bőven, ha okosan van kitalálva a dispatch.

• #220 gbors nagyúr Abu85 #199

  Új Válasz 2013-06-24 21:31:17 #220

  Ú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

  

  gbors

  nagyúr

  LOGOUT blog

  válasz Abu85 #199 üzenetére

  hogy most hogy fut, és hogy mit lehet, az nem éppen ugyanaz gondolom, most semmit nem offloadolnak, ami a scene előkészítésében szerepet játszik - nem akarnak úgy járni, mint a tesszelált lépcsőkkel. de ettől még lehet a scene fázisnak és GPU által támogatott része, csak nem a (jelenlegi) DX-en keresztül.

• #196 gbors nagyúr

  Új Válasz 2013-06-24 20:09:43 #196

  Ú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

  

  gbors

  nagyúr

  LOGOUT blog

  jó kis írás lett

  a lehetséges irányok közül egyet hiányolok - lesznek olyan fejlesztők, akik ésszel fognak közelíteni a kérdéshez, és külön-külön megoldásokat fognak az egyes problémákra hozni, nem egyben kezelni őket "mély integráció hiánya" címszó alatt (csak egy példa - a fizikai szimulációt simán lehet offloadolni a GPU-ra, mert nem igényel óriási mennyiségű adatcserét). sajnos valószínű, hogy nem sok ilyen lesz, mert az okos fejlesztő az drága...

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