Hirdetés

Hirdetés

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

  • Abu85

    HÁZIGAZDA

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

    Nem. Ahogy a DXR 1.0, úgy a DXR 1.1 is megengedi azt, hogy a nem támogatott funkciókat compute shaderrel helyettesítsd. Akár az egész futószalag használhat compute shadert. Tehát mindenre lehet DXR 1.1-hez támogatást írni, ahogy a Pascalra is lehetett DXR 1.0-hoz. Az alapvető követelmény pusztán egy olyan hardver, ami compute shadert támogat, illetve egy olyan meghajtó, amelynek a fordítója DXIL IR-t elfogad.
    Ugyanakkor maga az inline raytracing egészen máshogy működik, mint a dynamic shader raytracing, így olyan követelményei vannak, amik új tervezésű hardvereket igényelnek.

    A Microsoft elmondása szerint két alapvető fontosságú igény lesz az inline raytracinggel az architektúrák felé, ha a futószalag minden gyorsítást támogató lépcsőjét fixfunkciós hardverrel szeretné kezelni a rendszer. Egyrészt tudni kell a hardver ütemezőjének kezelni azt a kontextusstruktúrát, amivel egy shaderben leírható, hogy hit esetén térjen vissza az eredménnyel, és annak megfelelően a kontextusstruktúra minden szükséges adattal rendelkezzen. Az adatmozgatást tehát az inline raytracingnél gyakorlatilag fű alatt csinálja a rendszer, nem kell foglalkoznia a programozóknak azzal a problémával, hogy melyik shadernek milyen adatokat biztosítsanak, mert maga a hardver gondoskodni fog arról, hogy minden ott legyen egy helyen. Ennek ugye az a rákfenéje, hogy eléggé bonyolult ütemezést igényel, mert gyakorlatilag a teljesen végig kell követni egy sugár útját, nincs lehetőség arra, hogy külön shader gondoskodjon a sugár indításáról, nem lesz egy bekötési tábla a memóriában, amibe lehet írni a részadatokat, nem fog külön shader futni a hitre és a missre, stb., tehát programozói szempontból a probléma jelentősen egyszerűsödik, de sokkal combosabb hardver is kell, ami egyben meg tudja oldani azt, amire eddig külön a program oldaláról kellett apránként utasítani a hardvereket. A másik igény ebből a változásból ered. Mivel eddig a részfeladatok egymás után sorban lettek végrehajtva, így nem volt követelmény az, hogy mindegyik futószalaglépcső ugyanahhoz a hardverállapothoz kötődjön. Az inline raytracing esetében ez az, hiszen egyetlen egy compute shaderre le lehet szűkíteni a problémát, tehát okvetlenül fontos, hogy a fixfunkciós egységek elérhetők legyenek ugyanabban a hardverállapotban, mint amiben a compute shader. Sőt, a DXR 1.1 további változásai mellett, például, hogy akármilyen shader lépcsőből elérhető az inline raytracing, az a legjobb a hardver tekintetében, ha a compute shader, illetve a gyorsítást végző fixfunkciós egységes stateless módban működnek. Ezt persze rohadt nehéz megcsinálni, könnyű ilyet mondani, csak ugye a gyakorlat... :) Nem véletlen, hogy a GCN-en és az RDNA-n kívül nincs olyan hardver a piacon, ami a compute shadert stateless futtatja. Túl nagy tranzisztorbüdzséből oldható csak meg, és a valós előnye kimerül az aszinkron compute-nál, ami a mai játékokban úgyis döntő részben pixel shaderekkel fut párhuzamosan, tehát egyszerűbb az a megoldás, amit az NV csinál a Turingnál, hogy a compute és a pixel shader hardverállapota azonos. A valós programokban mutatott gyakorlati eredmény ugyanaz, miközben sokkal kevesebb tranzisztort kellett a megvalósításhoz elhasználni. A DXR 1.1 már egy kicsit keményebb duó, így át kell értékelni a hardvertervezést, mert szar dolog lesz sűrűn állapotot váltani, az azért durva lassulással jár. Tehát itt már a stateless mód erőltetése több hardveres részegységre, illetve feldolgozási formára valóban kézzel fogható előnyöket hoz, nem csak elméletit. Plusz az is számít, hogy az új generációs hardvereket már új node-okon tervezik, tehát tranzisztorbüdzsé is van a változtatásokra.

    [ 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