Keresés

Hirdetés

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

  • Abu85

    HÁZIGAZDA

    válasz helkis #2 üzenetére

    Azok a funkciók, amiket nem támogatnak, lényegében extra sebességet jelentenek. A GeForce ettől elesik. Ennyit jelent az egész.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Jack@l #18 üzenetére

    A Microsoftnak van mérése erről. A TIR funkcióval 151-523%-kal gyorsabb feldolgozás lehetséges.

    Az UAV-k esetében bonyolultabb a helyzet. Alapvetően pufferről van szó, ami lehetővé teszi, hogy a GPU adatot olvasson vagy írjon akárhova (itt inkább az írás a kulcs, mert az olvasás az SRV-n keresztül eddig is meg volt). Korábban ez előre definiált volt. Gyakorlatilag a programozónak biztosít egy komolyabb flexibilitást. Ha úgy vesszük, akkor scatter/gather operációkról van szó. Az egész a DX11-ben mutatkozott be és a pixel/compute shaderhez volt használható. A pixel shader lépcsőn való támogatás azt is lehetővé tette, hogy a programon belül az adatok könnyen megoszthatók legyenek a compute és a render futószalag között. Ezzel számos effekt sokkal hatékonyabban volt leprogramozható. A DX11.1 gyakorlatilag ezt annyival egészíti ki, hogy az UAV elérhető az összes programozható lépcsőn.
    Hogy példát is mondjak. A vertex shader esetében hasznos funkció lehet, ha LOD információkat akarsz nyerni a következő képkockára. UAV-t bevetve megoldható, hogy az előző képkockáról származó információk alapján határozd meg az új képkockán a mesh LOD szintjét. Gyakorlatilag az előző képkocka kimentett információiról azonnali LOD szintet lehet beállítani bármire. A hull shader esetében sok hasznos dolgot nem tudok elképzelni, és hasonló a helyzet a domain shader esetében. A geometry shader érdekesebb. Itt lehet talán a legtöbbet ezzel nyerni. Az UAV-vel például eléggé olcsón megoldható az alliassing jelenségtől mentes shadow mapping. Utóbbira számtalan megoldás született már, de eddig egyiket sem vetették be, mert a sebesség az nagyon gyenge. A DX11.1 gyakorlatilag értékelhető sebesség mellett teszi lehetővé az alkalmazását. Itt tényleg sokszoros sebességkülönbségről lehet szó.
    Az UAV-k kezelésének kiterjesztése még arra is jó, hogy bonyolultabb grafikai megoldásokban gondolkodj, több helyen vesd be a compute shadert, amivel a teljes feldolgozás felgyorsítható.

    (#53) tome.jr: A DX11-ben is félreértik az emberek az extra sebességet. Tényleg jó példa a DiRT Showdown. Ha DX9-ben írnád meg ugyanazt a grafikai minőséget, amit felmutat a program DX11-ben, akkor nem lenne VGA, amin 2-5 fps-nél gyorsabban futna. Az olcsóbb vagy régebbi VGA-k egy másodpercen belül nem számolnának egyetlen képkockát sem. Természetesen meg lehet kérni a fejlesztőket, hogy ugyan oldják már meg azokat a DX11-ben elérhető effekteket DX9-ben is. Nincs technikai akadálya, de tényleg óriási kérdés, hogy megéri? Dolgoznál vele hónapokat azért, hogy egyetlen VGA-n se fusson pár fps-nél többel. Ha te fejlesztő lennél megcsinálnád?

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Flashback #73 üzenetére

    Hát kb. ezt csinálják. De nem hivatalosan kommunikálják a DX11.1-et. Hivatalosan ők is csak DX11-et jelölnek meg.
    Természetesen a hardverben kell módosítás.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Attix82 #78 üzenetére

    Az AC3-ban rengeteg olyan dolog van, ami compute shaderrel gyorsítható mindegyik terméken. Ehhez képest nem is tartalmaz CS kódot. Ez teljesen érthetetlen, és a sebességre is nagyon rányomja a bélyeget, mert a grafika az nem annyira komplex. Alapvetően nincs rosszul optimalizálva, csak valamiért nagyon ragaszkodtak a régi dogmákhoz. De amúgy ezzel nincs gond. Ők így döntöttek. Amit ebből ki lehet hozni, azt kihozták.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz adamssss #81 üzenetére

    Inkább ingadozó. Van ahol gyors, és vannak részek, ahol nagyon nem az. Lehet, hogy van egy kis problémája az erőforrás kihasználással is.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz Flashback #90 üzenetére

    Nem teljesen értem a kérdést. Illetve azt, hogy mi megy más irányba. Arra gondolsz, hogy az új DX11-es játékok közül már számos program erősebb compute terhelést fejt ki? Mert, ha igen, akkor ez igazából normális. Amikor egy effektet compute shaderben írnak, akkor a fejlesztő nem azt nézi, hogy a Radeonok el fognak húzni a GeForce-októl, hanem azt, hogy a compute shader kód a GeForce-on is gyorsít. Az lehet, hogy az NVIDIA-nak ez kellemetlen a benchmarkokban, amikor a hardvereket összehasonlítják, de neked, mint felhasználó, még GeForce mellett is az az érdeked, hogy amit lehet írjanak meg compute shaderben, mert egyszerűen gyorsabb, mintha nem használnák. Aztán a gyorsulás mértéke már függ az architektúrától, illetve attól, hogy milyen bonyolult az effekt, de a program sebessége szempontjából a compute shaderrel mindenképpen jól jársz. Ne úgy fogd fel, hogy a fejlesztők most ki akarnak cseszni az NV-vel és erős compute terhelést csinálnak, ami általánosan kedvez a GCN architektúrának. A fő cél itt az, hogy a program gyorsabban fusson mindenkinél. Az NV persze lobbizhat, hogy erre nincs szükség, de akkor a saját felhasználóitól is elveszi azt az extra sebességet, amit a compute shader jelent. Persze nekik ez valahol megéri, mert a GCN ebből az irányból sokkal többet nyer, mint a Kepler.
    Ha a DX11.1-re gondolsz, akkor azt tudom írni, amit a hírben. Számítanak azok a funkciók, amiket a Kepler nem támogat, nem mondhatjuk azt, hogy jelentéktelenek, mert nem azok. Abban viszont nem vagyok biztos, hogy mikor lesznek kihasználva egy játékban. Ha csak a fejlesztőkön múlna, akkor nagyon kis esélyt adnék rá, hogy fél éven belül lesz DX11.1-es játék. Viszont az AMD manapság talicskával tolja a pénzt a játékfejlesztésekbe, és így a Gaming Evolved partnerprogramon belül már kérhetnek olyat, illetve fejleszthetnek olyan irányba, amilyet a normál fejlődés mellett a fejlesztők amúgy nem használnának ki (idén ezt már több játéknál megtették). Ez egy bizonytalansági faktor, amivel nagyon nehéz számolni.

    (#104) TTomax: Tudom milyen az AC3. Írtam is, hogy van problémája az erőforrás kihasználásával. Azért valamennyi mindig van a driverekben. Persze valószínű, hogy pár százaléknál nem több, de mindenképpen megéri beprofilozni a játékot. A patch az igazából mindig opció. Bármit lehet javítani, csak a kérdés, hogy megéri-e ezzel foglalkozni. Ha egy kiadó elzárja a pénzcsapot a további optimalizálás elől, akkor nyilván ez a fejlesztési irány lezárult. Az AC3 sebességet a leggyorsabban compute shaderrel lehetne nyerni, de ezt teljesen mellőzték a fejlesztők.
    Szerintem a PC-s portokhoz rosszul állnak a kiadók. A fejlesztőnek tartani kell a dátumokat, és ennek jellemzően a PC-s optimalizálás issza meg a levét, mert annak van a legalacsonyabb priorítása. Ilyen szempontból most már én is belátom, hogy a Square Enix csinálja jól. Fenntartanak egy stúdiót csak a PC-s portokra, és eddig működik ez a koncepció. Amilyen rossz ötletnek tűnt pár éve annyira bevált, így talán másnak is meg kellene ezt az irányt fontolni.

    (#114) Jack@l: Miért lenne fura? Az előző képkocka alapján már tudod, hogy melyik meshez milyen LOD tartozik. Ha közelítesz, akkor azt tudni fogja a rendszer, csak nem az aktuális jelenetről, hanem az előző frame számításai alapján. Minden frame számítása során ki kell menteni egy struktúrát, ami alapján ez meghatározásra kerülhet egy compute shaderben. A megadott állandók alapján így is mindig meghatározható a LOD. A különbség annyi, hogy előre meghatározod.

    A TIR százalékos adat a Microsoft hivatalos mérése. [link]

    (#115) Jack@l: Remélem nem azt akarod mondani, hogy eddig azt hitted, hogy D3D-re vonatkozik. Benne van a hírben, hogy 2D-s grafika esetén. Legalább azt olvasd el, mert ha nem teszed, akkor feleslegesen magyarázom.

    (#85) nbg: Az ATI(AMD)-nak volt egyszer egy nézeteltérése a Microsofttal a shader modell 3.0 esetén. A Radeon X1000 sorozat nem támogatta a Vertex Texture Fetch-et. Erre a Microsoft nem akarta megadni így a shader modell 3.0-s minősítést, de végül megadták, mert az ATI azt hozta fel, hogy ők az R2VB-t implementálták. A probléma az volt, hogy utólag a Microsoft is elismerte, hogy semmilyen formátumot nem írtak elő kötelezően a vertex textúrázás támogatására, így a dokumentáció szerint jó az R2VB és a VTF is. Ezért lett a Radeon X1000 sorozat shader modell 3.0-s végül. A Microsoft a DirectX 10 API esetében már pontosan specifikálták a vertex textúrázás formátumát.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz ETOM #189 üzenetére

    Ettől nem. A 16xMSAA támogatásától szebbek lesznek (ami szintén DX11.1-hez van kötve), de a TIR csak a sebességet növeli.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

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