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

• #248 kvp777 tag

  Új Válasz 2007-11-16 15:10:48 #248

  Ú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

  

  kvp777

  tag

  Megneztem a dx10.1 uj feature-jeit es azt, hogy mennyiben tamogathatoak gf8800-asakon:
  -cube map array: gyakorlatilag egy 6 dimenzios texturatombrol van szo, amibol 2 dimenziot kell filterezni: ezt minden gond nelkul kezeli az nvidia is, csak driver kerdese
  -kulon keveresi minta mrt bufferenkent: multipass-esen megoldhato
  -16 helyett 32 vertex i/o pont: a gf8800-asokban erre boven van memoria
  -gather4x4: jelenleg is tamogatott, bar csak cuda-ban es lassu
  -lod instruction: jelenleg is tamogatott a 3d-s textura interface-en at
  -multisample buffer: tamogatott
  -pixel coverage masks: diszkret utasitasokra bonthato, bar ettol lassabb lesz a vegrehajtas
  -programmable aa: a fenti muvelet erre vezetheto vissza

  Akarhogy nezem, a cube map array-s global illumination-t mar most is meg lehet csinalni, csak nem automatikusan, hanem shader-bol. (de mar voodoo 2-re is volt ra demo kod) Az mrt kezeles szamitana, de mivel a gf8800-asok mar most is shader-bol kezelik a legtobb esetet, ezert ennel mar nem lehetnek lassabbak. A 32 vertex i/o pont nagyjabol ki is meriti a gf8800-asok lokalis memoriateret, ezert ha legkozelebb megnovelik, akkor a tobbit mar globalis memoriaba kell rakni. (ami 16-szor lassabb) A gather 4x4 egy ati feature, ami az atlagoloegyseg kikapcsolasaval jon letre. Ezt a cuda most is tamogatja, bar mivel shader-bol kezeli ezert 4-ed akkora teljesitmennyel. A programozhato aa tenyleg hianyzik, de ha szukseges, akkor az aa modokat egy postprocessing filter-rel lehet felvaltani. (szoftveres aa pixel shader-bol, hdr-nel a bloom-ot is igy szokas kezelni)

  Ahogy nezem, ezek a feature-ok nem sokat ernek, az egyetlen kivetel az i/o parameterek szama, de az jobb apiknal inkabb van a 64K-s tartomanyban mint 100 alatt, es a shader compiler dinamikusan generalja az allokaciot es a load/store kodot. Szerintem hanyagolni kellene a jelenlegi fixed pipeline-okat, mint amilyen a dx10 is. Egy cuda fele altalanos rendszer sokkal jobban es konnyebben programozhato. Ha bevezetnek akkor lehetoseg lenne az egesz grafikai motort unified shader-bol megirni, es a hardverbol el lehetne hagyni a textura kezelo es raszter muvelet egysegeket is. Eleg lenne par control unit, sok alu, es egy dispatch queue rendszer. (viszont a jelenlegi shader-ek kezelesere szukseg lenne egy shader-kent futo vezerloszoftverre is, amit hivhatnank akar gpu kernel-nek is) A megoldas hatranya, hogy a jelenlegi muveletekre is shader-t kellene irni. Peldaul a textura fetch-ek jelenlegi huzalozott egysegeit egy par szaz utasitasos shader kod tudna potolni, aminek a futtatasahoz megtobb altalanos alu kell. (kb. a duplaja a jelenleginek) Cserebe egy sima c++ fordito is kepes lenne gpu-ra kodot generalni. (mmu nelkuli smt-s vliw cpu-kkent latva oket) Ilyen mmu nelkuli rendszer volt annak idejen a M68k is, a maga 16 (8+8) lokalis regiszterevel es korlatozott vliw kepesseggel. /alu+mem muveletek, pl. *(p++) /

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