2. Fórumok
  3. Egyéb hardverek
  4. Mi áll a DirectX lassú fejlődésének hátterében?
Keresés

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

  • #40 Meteorhead aktív tag Raysen623 #33
    Új Válasz #40
    Ú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

    Meteorhead

    aktív tag

    válasz Raysen623 #33 üzenetére

    A számból vetted ki a szót!

    NV és Intel ott puskázza el közösen, hogy nem képesek közös nevezőre jutni. Amíg Intel kapacskodik a CPU teljesítményében és x86 alapon igyekszik grafikát is csinálni (de legalábbis masszív párhuzamosságot), addig NV az ARM-ot akarja majd lenyomni a játékpiac torkán, lettlégyen bármilyen a platform, amire rá tudja tenni a kezét (ARM PC, next-gen konzol, hand-held, telefon, ...). Mindkettőnek óriási szüksége lenne a másikra, de közös munka helyett arra pazarolják az erőforrásaikat, hogy boldoguljanak a másik nélkül. (Abu már kifejtette, hogy a két cég CEO-ja miért nem tud közös nevezőre jutni a cégek fúzióját tekintve.)

    Amíg pöcsölnek, addig AMD meg leköröz mindenkit. A DirectX nagyon jó volt grafikára, de látszik hogy a fejlesztők ma már olyan engine-t akarnak írni, ahol nem csak szerves részét képezi a rajzolás a színtér léptetésének, hanem nincs elválasztva a kettő egymástól. OIT és hasonló megoldásokra nem lenne compute intenzív szükség, ha az motor a színtér léptetésével egyidőben sorba tudná rendezni az elemeket kameratávolság szerint vagy IGP (parallel-sort), vagy a dGPU-val, azért mert eleve ott fut az egész motor. Ehhez persze az szükséges, hogy a párhuzamosan futó motor hatékonyan tudjon saját magának allokálni erőforrásokat, amit jelenleg azért nem lehet, mert ezt csak a CPU tudja elvégezni. OpenCL 2.0, Mantle alól (HSA a háttérben) triviális a dolog, az IGP/GPU ha rájön, hogy erőforrásra van szükség, gyorsan tud indtani egy CPU folyamatot, ami aztán visszaadja a "vezérlést" a GPU-nak. Minden részfeladatot ott kellene elvégezni, ahol rendelkezésre áll minden információ a hatékony számoláshoz. Grafikus API-ban sorbarendezni már túl késő (mert már elveszett a többletinformáció, ami még host oldalon megvolt).

    Az efféle játék engine-eket jelenleg csakig compute API-kban és nyelvekben lehet megfogalmazni, és lassan tényleg ott tartunk, hogy kisebb fáradtság egy compute nyelven megírni egy hatékony leképezőt, mint a Direct3D/OpenGL baromságait kerülgetve próbálni hatékony közreműködést implementálni a grafika és a motor között.

    Én személy szerint az egyetlen járható útként azt látom, hogy valamilyen compute nyelven szabványosítják a grafikában (és video en-,de-,trans-kódolásban, meg minden ilyesmiben) használt fix funkciós egységek interfészeit (mert az közös), és implementálják a gyártók. OpenCL 2.1-ben lehetne built-in function a raster egységnek, a tessalatornak, és társai. A Mantle egy jó lépés, de NV és Intel sosem fog felszállni erre a vonatra. OpenCL van AMP lehetne az az arany középút, ami azért nagyon low-level, megenged útválasztani HW alapján (ha valaki nagyon specifikus kódot akar írni, akkor megteheti), de létezne generikus elérés overhead nélkül.

    Amúgy nem hiszem, hogy ezt google translate-tel érdemes volna bárkinek is elküldeni, ami egy magyar fórumon folyik. Tökéletesen tisztában vannak ezzel, csak ahogy Raysen kolléga is mondta, dilettánsok gyülekezete általában a vezetőség, és szerintem NV és Intel is túl sokat volt vezető pozícióban ahhoz, hogy újra fel tudják venni azt a ritmust, ami a kapaszkodáshoz kell (ahol helyenként kompromisszumokat kell kötni, lásd AMD-ATi fúzió, ahol AMD-nek ki kellett szerveznie a gyár részlegét, mert elfogyott a tőkéje, hogy fedezni tudja a gyártórészleg átmeneti veszteségét).

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