Hirdetés

Hirdetés

!!! SZERVERLEÁLLÁS, ADATVESZTÉS INFORMÁCIÓK !!!
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!

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

  • Abu85

    HÁZIGAZDA

    válasz Dyingsoul #26604 üzenetére

    Azt mondjuk hozzá kell tenni, hogy a DXR 1.0 eléggé fos megvalósítást alkalmaz RT-re. Nem véletlen, hogy a CryEngine célhardvereket nem is használó megoldása agyonveri. Egyszerűen maga a szoftveres háttér fos az aktuális DirectX-ben, ami olyan elképesztően rossz hatékonyságra kényszeríti a hardvert a shaderek soros végrehajtásával, hogy roppant gyenge lesz a sebesség.
    Tehát lehet mondani, hogy most nem éri meg a felárat az RT, mert ez abszolút igaz, de maga a DirectX Raytracing aktuális verziója nem működik úgy, hogy gyors lehessen a feldolgozás. A hardver ehhez keveset tud hozzá tenni, elfogadja, hogy szép sorban kell feldolgoznia a shadereket, még ha lesz vele egy rakás üres ciklusa is.

    Nem véletlen, hogy a Microsoft a DXR 1.1-ben pont ezen változtat, és behozza azt a feldolgozási formát, aminél egyetlen egy shaderből is megoldható maga a feladat, így ugyanazt a munkát nagyságrendekkel hatékonyabban tudja elvégezni a hardver. Szóval amit most látsz az valóban rendkívül gyenge, de a DXR 1.1 pusztán a specifikációban végzett módosítások miatt lényegesen többet fog kínálni, és eközben lényegesen kevésbé fogja zabálni a sebességet.

    Eredetileg egyébként a DirectX Raytracing a DirectX 12 Ultimate-tel érkezett volna, csak az NV ragaszkodott egy nulladik generációs verzióhoz, viszont azt a fenti limitációkkal kellett megírni, és emiatt sajnos külön shader felel magának a sugárnak az indításáért, külön shader fut hit vagy miss esetén, és ezektől függően külön shader indul a bejárás eredményére építve. Ez mind azért probléma, mert minden egyes shader csak egymás után futhat le, ugyanis egymás eredményére várnak, és meg kell oldani az adatok megosztását is, hiszen effektíve egymás eredményeivel számolnak tovább. Már ez a futószalag nagyon rossz hatékonysággal működteti a hardvereket, mert egyrészt a függőség akadályozza az optimális, adatpárhuzamos végrehajtást, másrészt, ha nincs valami trükkös módra lehetőség az adatok átadása szempontjából, akkor minden shader kiírja a memóriába, majd a következő shader beolvassa, vagyis egy rakás üresjárat lesz a hardveren, amíg az adatok beérkeznek.

    Az inline raytracing lett volna a kezdeti modell, ami elég komoly ütemezőt igényel a hardverben, illetve meg kell oldani, hogy az egész munkamenet, amivel a sugárkövetés jár, egy hardverállapotból legyen elvégezhető. A legjobb egy stateless megoldás, vagyis az, ha a hardver a compute shader futtatására, illetve a bejárási feladatokra nem is igényel speciális hardverállapotot. A Turing nem ilyen hardver, tehát az inline raytracinget nem tudták PC-re az elején bevezetni, de a következő GeForce architektúra már ilyen hardver lesz, meg a konzolok is, illetve az RDNA2 is. Az inline raytracing pedig ugyanúgy emulálható a compute shadert támogató hardvereken, tehát a Turingra lehet írni szoftveres támogatást rá, a Pascalra is, akármire, ami compute shadert támogat.

    Tehát az ne vegye el senkinek a kedvét, hogy most nem látja, hogy működik-e az RT, mert nem látványos a változás. Ez azért van, mert már maga a szoftveres háttér rosszul van kidolgozva, és az egész programfuttatás egy rendkívül limitált hardveres működésre van kényszerítve, de a következő kör az jó lesz, mert a DXR 1.1 pont a hibákra reflektál. Szép új hardvereket is kap, ami drámai mértékben javít a feldolgozás hatékonyságán.

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