DXR: Microsoft přináší do herní grafiky nad DirectX vykreslování ray tracingem

45
Project Pica Pica, demo DirectX Raytracingu od SEED

Už to budou tři roky od příchodu nízkoúrovňového API DirectX 12 a mezitím zde podobně velký evoluční krok v technologii herní grafiky nebyl. Chvíle na něj ale přichází nyní. Microsoft sice nemá žádné DirectX 13, ale přináší jinou novinku: technologii DirectX Raytracing, tedy příchod této dokonalejší technologie vykreslování obrazu do herní grafiky postavené na platformě DirectX. To může být jeden z nejdůležitějších vývojových obratů poslední doby.

 

Předchozí
Následující

Ray tracing: kvalitnější 3D grafika

DirectX Raytracing (DXR) není nějaký radikální převrat v tom smyslu, že by se opouštěla tradiční grafická „pipeline“ používaná dnes a založená na principu rasterizace. To se od přechodu k ray tracingu někdy předpokládalo (například Imagination Technologies měla několik speciálních architektur pro tento druh vykreslování, experimentálníchkomerčních). Microsoft místo toho zavádí ray tracing jako rozšíření možností současného přístupu ke grafice a jako techniku, která poběží v jejím rámci. DXR je proto API, které má být kompatibilní se současnými GPU a jejich možnostmi. A jako obvykle by úlohou tohoto API mělo být to, poskytnout vývojářům standardizované rozhraní, proti kterému budou moci psát kód.

Ray tracing je metoda vykreslování, jež je potenciálně kvalitnější než rasterizace. Spočívá ve výpočtu drah imaginárních paprsků probíhajících zpětně od oka pozorovatele ke všem různým objektům na scéně, přičemž se vypočítávají jejich odrazy a interakce až k světelným zdrojům, od nichž se světlo reálně dostává do oka. Tento přístup je velmi výpočetně náročný, proto také tato metoda pro zobrazení v reálném čase není používána. Naopak pro vykreslování statických obrazů nebo třeba filmů je standardem. Herní grafika proto používá méně kvalitní rasterizaci, jež je však jednodušší. V podstatě spočívá v geometrické transformaci promítající trojúhelníky polygonálních modelů s texturami do rastrové plochy a poté obraz vylepšuje pixel shadery.

Schéma fungování ray tracingu (Zdroj: Wikimedia Commons). Vykreslování funguje pomocí sledování dráhy paprsků ze zdroje světla a jejich odrazů či odstínění, až k oku pozorovatele
Schéma fungování ray tracingu (Zdroj: Wikimedia Commons). Vykreslování funguje pomocí sledování dráhy paprsků ze zdroje světla a jejich odrazů či odstínění, až k oku pozorovatele

Problém s výpočetní náročností u ray tracingu stále trvá. Microsoft ovšem s DXR nenavrhuje počítat celou scénu ve hrách, tedy alespoň dnes ne. Prvním krokem je integrace této metody jako pomocné techniky, doplňující a zkvalitňující obraz ve hrách. Ray tracing by měl obzvlášť dobře vykreslovat například stíny nebo odrazy a odlesky, a DXR bude umožňovat jím podobné efekty na GPU zpracovat. Vize tedy je, že ray tracing bude spolupracovat ve společném prostředí se standardní rasterizací, což umožňuje tuto metodu použít pro herní grafiku vykreslovanou v reálném čase. Postupem času se ale podíl ray tracingu a jeho vyšší kvality podle Microsoftu bude zvyšovat, z čehož by vyplývalo, že se na něj jednou ve vzdálenější budoucnosti může přejít jako na dominantní či rovnou jedinou metodu pro celé vykreslování.

Vykreslování se bude chovat jako výpočetní úloha

Toto je umožněno tím, že GPU poslední doby dosáhla skutečně vysokého stupně programovatelnosti a jejich výpočetní jednotky (stream procesory/„Cuda jádra“, postaru shadery) jsou natolik univerzální, že na nich lze provádět ray tracing stejně jako mnoho jiných výpočetních operací. API DXR ale poskytne standardizovaný způsob, jak toto dělat, místo aby si každý vývojář musel implementovat vlastní pomocí abstrakce založené třeba jen na OpenCL nebo DirectCompute. Díky této standardizaci by také měla být zajištěna široká kompatibilita s různými GPU.

Tento ray tracing v DirectX tedy nutně nespočívá v architektonické změně GPU nebo nějakém speciálním hardwaru, jako tomu bylo třeba u DirectX 11. Situace je spíše jako u DirectX 12, nad nímž je také DXR postaveno a které při příchodu také víceméně jen využívalo existující možnosti DX11 hardwaru. DXR nezavádí nějaký nový typ funkčních jednotek, zůstáváme stále jen u klasických fixních funkcí rasterizační pipeline a univerzálních programovatelných výpočetních jednotek. Právě na těch jsou implementovány funkce DXR, takže toto rozhraní zavádí různé nové HLSL shadery (ray-generation, closest-hit, any-hit, miss), které ale budou vypočítávány na stejných standardních stream procesorech. DXR je tak do značné míry vlastně softwarová „GPGPU“ aplikace.

Gilles Tran: Glasses. Příklad ray tracingového obrazu s realistickými lesky, osvětlením a stíny
Gilles Tran: Glasses. Příklad ray tracingového obrazu s realistickými lesky, osvětlením a stíny

Microsoft a výrobci GPU by ale zřejmě eventuálně měli přijít s nějakými novými rozšířeními GPU, které budou akcelerovat speciálně ray tracing a Nvidia již oznámila, že má nějaké takové speciality v GPU Volta. Nicméně základní úroveň DXR má onu „softwarovou“ povahu, která zároveň slouží jako záložní „fallback“ zajišťující kompatibilitu se staršími GPU. Tento fallback bude pracovat se všemi GPU podporujícími DirectX 12 a používá pro výpočty Compute Shadery. Vyšší úroveň s hardwarovou podporou by se ale pravděpodobně také měla točit hlavně okolo shaderů a programovatelných jednotek. Blogpost Microsoftu, který blíže popisuje koncepci DXR, píše, že budoucnost GPU vidí právě v rozvoji těchto univerzálních programovatelných jednotek, nikoliv v přidávání hardwaru s fixní funkcí.

Předchozí
Následující

45 KOMENTÁŘE

  1. Ten obrázek s popiskem „Příklad ray tracingového obrazu s realistickými lesky, osvětlením a stíny“ je přesně ukázkou, jak to realisticky nikdy nevypadá, protože aby to takhle vypadalo, musely by ty objekty být naprosto dokonale hladké, naprosto dokonale čisté a v prostředí by se nesměl vyskytovat žádný prach.
    Jinými slovy, „realistická“ scéna moc realisticky nevypadá.

      • Ale jo. To neměla být kritika článku. To bylo jen takové postesknutí, že aby tím ray tracingem něco vypadalo reálně, budou muset být i objekty upraveny do reálné podoby. Tedy povrch 3D objektu nebude smět být dokonale hladký a potažený texturou, ale bude muset mít reálně vytvarovaný povrch včetně nerovností a výrobních chybiček, jinak ta zcéna bude vypadat naprosto nereálně.

    • To ale není problém raytraycingu jako technologie, ale modelu objektů. Nicméně herní průmysl se tím zaobírat nebude, protože už na principu „lepší než život“ musí drtivá většina her na obrázku vypadat „lépe“ než scéna z reálného života. Samozřejmě narážíme tu na otázku subjektivního hodnocení, ale pokud vývojář dostane zpětnou vazbu že např. „ta barevnější scéna vypadá lépe“ nehledě na tom, že byla z pohledu reálného světa přesaturovaná, nezbývá mu nic jiného, než to tak udělat. Vývoj her není pohánený snahou o co nejrealističtější zážitek, ale korporátními rozhodnutími.

  2. Chybička v článku: rasterizacační

    Jinak super článek a jsem moc rád, že se už podnikají kroky k raytracingu. Jak je v článku psáno, je to budoucnost, na rasterizaci se bude hledět jako na historii. Toho jsem si vědom od okamžiku, kdy jsem se o raytracingu dozvěděl a věděl, že toto je cesta, jen nesmírně těžká na výkon, kdy obrázek se renderuje několik minut či hodin. A těch obrázku je potřeba mít během vteřiny alespoň 60 pro dobrý zážitek.

  3. Jako clanek skvely, spousta informaci, ale malinko nesourode napsanych.

    Jde o to, ze ray tracing = vypocetni GPU. A jak znamo, tak NVidiacke herni grafiky az po Pascal jsou skvele pro DX11 a nizsi, ale v DX12 uz maji drobne problemy s nekolika malo technikami, ktere jsou prave vypocetnim smerem a nikoliv zamerene na specializovane graficke shadery.
    Tohle ten problem jen prohloubi, ale samozrejme tou dobou, kdy s tim zacnou vyvhazet hry, bude venku nova grafika od NVidie, ktera to da s prstem v nose.
    Ovsem teda jestli to nebude podporovat ani Ampera, ktera vyjde v kvetnu, tak uz je to malinko blbe. V podstate je mozne, ze listopadovy Turing prinese nove v budoucnu dulezite technologie, ktere Ampera neda. Ach jo.

    Co se tyka AMD, tak teoreticky by po nastupu DXR mohly Vegy zrat jak vino, jak nam priznivci AMD neustale predhazuji, ale ja myslim, ze AMD spis typicky neda ovladace.

    • Nvidia grafiky nemaji s DX12 zadne problemy. Za prve, GeForce maji porad lepsi vykon, a to casto s mnohem mensim cipem, nez konkurence od AMD. Za druhe, naskok Nvidie proti AMD je v DX12 mensi, ale to neni zpusobeno horsi implementaci DX12, ale naopak tim, ze nektere technologie DX12 Nvidia interne v driverech pouzivala uz pro DX11 hry. Jinymi slovy Nvidia prechodem na DX12 uz tolik neziskala.

      Moc zeres ty stachovo a souckovo blbosti.

      • To určitě plyne z té situace, kdy před pár lety začaly všichni vytahovat async compute a místo titulku „GPU od AMD má podstatně sofistikovanější subsystém pro asynchronní výpočty“ to dostalo klasické „Nvidia má problém s DX12“, protože to je pro novináře skandálnější titulek (čti: víc penízků za reklamy, protože lidi dneska čtou akorát Blesk).

        • A blbe jsou obe varianty. Nvidia pouzivala variantu async compute uz pro DX11 hry. Takze to neni o kvalite async compute. Rozdil mezi DX11 a DX12 je u Nvidie mensi, protoze je technologie pouzivana u obou.

          Takze ani ze ma Nvidia problem s DX12, ani ze ma AMD sofistikovanejsi implementaci async compute. Pomer vykon/plocha cipu mluvi zcela jasne, ze I pres mensi posun u DX12 je implementace Nvidie celkove porad o dost efektivnejsi.

          • To vis zejo, proste plocha vs vykon a je to jasny 😉 NV zase vitezi 😀
            Nekdo ma ten zivot proste jednoduchy, ale zaver ma vzdy ten spravny 😀

          • Tady někdo očividně důvěrně studoval whitepapary AMD a Nvidie. Doporučím osvěžit pamět:
            http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Asynchronous-Shaders-White-Paper-FINAL.pdf
            http://international.download.nvidia.com/geforce-com/international/pdfs/GeForce_GTX_1080_Whitepaper_FINAL.pdf

            Je mi úplně fuk co bylo za éry DX11, to na to nemá absolutně vliv. Ještě Maxwell používal pouze statické rozdělování CU, což mohlo stačit pro účely GPGPU, ale rozhodně ne pro hry, kde délka výpočtu může dramaticky měnit prakticky každý snímek. Až Pascal začal vůbec nějak řešit stalling pomocí „Dynamic Load Balancing“, ale pořád to není na úrovni CGN. CGN má dedikovanou cache pro přepínání kontextu, kdežto i Pascal s tím musí do VRAM, což je řádově pomalejší. CGN taky umožňuje daleko větší granularitu až na úroveň 1CU díky ACE a rychlému přepínání kontextu. Tady zdůrazním, že se stále nejedná o situaci „AMD má větší výkon pro výpočty“, pouze o „v tomto konkrétním případě není architektura Nvidie dostatečně pružná a bude mít nevyhnutelně výkonové propady“.
            A jako jsem zmínil o kus níž, co se týče hrubého výkonu, tak Nvidia nemá konkurenci a v drtivé většině případů nemá s efektivitou problémy.

          • Architektura Nvidie je zamerena na buffering. A buffering, pokud bys vedel neco o programovani, je zaklad pro dosazeni dobreho throughput (propustnosti). Nevyhoda bufferingu muze byt delsi odezva dilcich operaci, takze je potreba odvest dobrou praci v driverech a scheduleru, aby to spravne fungovalo.

            AMD se nevybralo lepsi cestu, pouze jednodussi. Osobne si myslim, ze z duvodu nedostatku zdroju sli po jednodussi implementaci. Ale ve vysledku, diky dobre zvladnutym ovladacum a scheduleru Nvidie, je na tom Nvidia lip. A na vykonu je to videt.

            „Here is an old presentation about CUDA from 2008 that discusses asynch compute in depth – slide 52 goes more into parallelism: http://www.slideshare.net/angelamm2012/nvidia-cuda-tutorialnondaapr08 And that was ancient Fermi architecture.“

            „Async compute has been a feature of CUDA/nVidia GPUs since Fermi. https://www.pgroup.com/lit/articles/insider/v2n1a5.htm
            NVIDIA GPUs are programmed as a sequence of kernels. Typically, each kernel completes execution before the next kernel begins, with an implicit barrier synchronization between kernels. Kepler has support for multiple, independent kernels to execute simultaneously, but many kernels are large enough to fill the entire machine. As mentioned, the multiprocessors execute in parallel, asynchronously.
            That’s the very definition of async compute.“

            Takze Nvidia dela Async Compute od roku 2008 a architektury Fermi a to pro DX11 hry. (DX12 bylo predstaveno 2014 a uvedeno 2015).

            Zdroj: https://www.reddit.com/r/nvidia/comments/3j5e9b/analysis_async_compute_is_it_true_nvidia_cant_do/

            Jedna vec je citovat whitepapery, druha vec je jim rozumet.

          • „Jedna vec je citovat whitepapery, druha vec je jim rozumet.“ No právě :>

          • Ve zkratce (protože už mě to celkem rychle přestává bavit): CUDA je API čistě pro GPGPU výpočty a s DirectX nijak nesouvisí (narozdíl od DirectCompute), GraphicsCommandList se objevil poprvé až v DX12 (je úplně jedno, že to CUDA uměla už dřív, je to úplně odlišné API)
            Kdo má vůbec tu drzost porovnávat typické GPGPU úlohy s renderováním herní scény??? Bavíme se tu o řádu minut až hodin versus (typicky méně než) 16 milisekund. Když máš matici 1000000×1000000 a děláš nad ní nějakou operaci, tak si ji pochopitelně nabufferovat můžeš a pak ji vesele půl hodiny tlačit přes GPU. Co chceš asi bufferovat, když máš na výpočet v rámci snímku pár milisekund? To jsou dva úplně neporovnatelné koncepty. Dělal jsi vůbec někdy něco v DX nebo OGL nebo vůbec cokoliv co využívalo koncept asynchronních operací? Jestli ne, tak se mi tu nesnaž vnucovat nějaké irelevantní prezentace o CUDA API.

            Jedna věc je citovat zdroje, druhá věc je vůbec rozumět používaným pojmům.

          • To je jako se bavit s nahluchlym.

            Nejdriv si ujasnime rozdil mezi DX9/10/11 a DX12. Je totiz zcela zasadni:
            – u DX9/10/11 davas GPU high-level instrukce a pointry k datum a dal je ciste na driveru, jak a kdy (jestli vubec) dane instrukce provede
            – v DX12 davas GPU low-level prikazy, takze ty sam, jako programator, se musis starat o vyse zminene veci a navic napr. o spravu pameti

            Nvidia u DX11 titulu grafickou pipeline masivne upravuje (hlavne u AAA her), prave diky volnosti, kterou ji DX11 dava, a vyuziva tim asynchronni schopnosti hardwaru i u her, ktere tak nebyly napsane. To je zrejme i jeden z duvodu tak masivniho naskoku ve vykonu Nvidia grafik v DX11.

            Cpat sem faktorizaci matice 10Mx10M prvku je zcestne a smesne. Uplne je z toho videt na rychlo prectena stranka na wikipedii. Ale bohuzel, chce to vic. Async Compute se ve hrach vyuziva spis k simulacim fyziky, takze mluvime o daleko mensich maticich.

            A pro uplnost – Nvidia GPU Maxwell generace ma 32 warpu, coz je prave velikost bufferu. 32 operaci v ramci vypoctu jednoho snimku do nej natlacis velmi snadno, protoze jeden jediny snimek takovych operaci cita radove vic.

            Zasadni vec je, ze kernel je proste maticova/vektorova operace. Je uplne jedno, jestli je to graficky vypocet nebo GPGPU vypocet.

            A btw, ja delal s OpenGL uz od verze 1.2, cca rok 2000. Co ty? 😉

          • @janolsan Ten clovek ocividne nevi, o cem mluvi. Je to placani pateho pres devate, nesouvisejici veci .. no vsak si to muzes precist sam. I kdyz to je docela narocne cist ..

          • Nebyl jsem to já, kdo zcetstně vytáhl CUDA API a buffering (ať to v tom kontextu mělo znamenat cokoliv). Pokud to měl být příklad toho, že architektura Nvidie to umí už od Fermi, tak akorát ke zbytečnému zmatení, protože s tím obsahem předposledního komentáře nemám problém. Ač z hlavy nevím, od jaké verze CGN umí async compute, už tu s námi taky pěkných pár let je a Jestli toho využívali před DX12 bych taky jen spekuloval. Zpátky k ověřitelným faktům:
            Já se celou dobu snažím akorát vyjádřit (a je to tuším i v tom reddit postu co jsi poslal), že pokud ACE v GCN umí vyrobit asynchroních 8 tasků s max queue depth 8, + bez velké penalizace za context switching, je to obecně daleko pružnější koncept než 1 fronta s hloubkou 32. O nic víc mi tu celou dobu nešlo. Možná je to pro účely her zbytečně předimenzované, možná ne. To asi ukáže až čas. (spekulativní vsuvka: myslím si že paralelizace front u CGN by měla být logicky ku prospěchu věci)
            Navíc, do Pascalu byl scheduling asynchroních operací statický, což vedlo na zbytečné zdržení při synchronizaci -> snížení efektivity, což opět není nic co bych si vycucal z prstu, ale bylo to v tom whitepaperu GTX1080, je to krásně vidět v tom grafu souběžné Graphics a Compute operace.

    • Mě by zajímal zdroj těchto informací, protože až nápadně vypadají vycucané z prstu.
      Jediné co si vybavuji kvůli čemu všichni dělali takový poprask byl Asynchronous Compute, což nijak nesouvisí v hrubým výkonem GPU, ale lepší efektivitou (tj. vyšší průměrné využití bloků GPU kde je to možné).

      Pokud od spekulací a polopravd přesuneme k reálným číslům, tak na luxmarku (raytracing benchmark) jsem v single GPU konfiguraci neviděl AMD v prvních padesátce (viz: http://www.luxmark.info/top_results/Hotel/OpenCL/GPU/1 ). AMD potřebuje akorát GPU s podstatně vyšším hrubým výkonem, v podstatě nic jiného.

      Chtěl bych především upozornit na výsledek Volty. Úplně nevidím, kde má teda Nvidia problém.

  4. NVIDIA okrem RTX vydala aj novú verziu Flexu 1.2.0 s rôznymi vylepšeniami efektivity a dokonca podporou asynchrónnych výpočtov (táto knižnica má podporu DX12). To je myslím aj odpoveď pre ľudí, ktorí si myslia, že NV nepodporuje AS alebo iných nezmyslov okolo brzdeniu celého odvetvia. Viď:

    http://physxinfo.com/news/12866/nvidia-flex-1-2-0-is-released/

    Flex beží aj na grafikách od AMD a podporované sú aj integrované grafiky Intelu.

    • A čo s týka DX Raytracing, tak ho MS predstavil spolu s NV, kde vzájomne deklarovali spoluprácu na tomto API. Niekde sa spomína aj spolupráca s AMD, ale oficiálne s tým na GDC pokiaľ viem spomínaná táto firma nebola. Alebo sa mýlim (nemám podrobné informácie)?

      • No doufam jen, ze AMD zase neco nezaspalo. Akorat jsem ted na vazkach co delat, abych nekoupil Amperu v kvetnu a v listopadu ukaze NVidia Turing na DXR a pristi rok jsou na Raytracingu prvni hry a se starou grafikou se muzu jit klouzat. Je to fakt tezky.

        • Jo, len na začiatku bol výkon pre niečo také nepredstaviteľný a teraz na to stačia 3 Titany V. Sa to postupne rysuje. Možno ale budúce 2 generácie GPU prinesú také HW možnosti, že k ray-tracingu posunieme rýchlejšie.

          https://www.dsogaming.com/news/real-time-raytracing-is-a-next-next-gen-feature-seed-tech-demo-ran-on-three-nvidia-titan-v/

          Každopádne ja očakávam, že na predrenderované scény sa bude môcť využívať už teraz. Keď už existuje na to API a hlavne keď bude taká možnosť priamo v herných enginoch.

          • Ja myslim Marku, ze bude i zalezet nejen na budoucim vykonu (pripadne nejake dalsi HW podpore), ale i na tom, jestli se to oproti rasterizaci vyplati. Co tim myslim je, jestli vizualni efekt bude natolik lepsi, ze bude mit smysl, aby herni studia do toho investovala cas (prelozeno penize).

          • Vizuálny efekt ako prínos je v tomto prípade neoddiskutovateľný. Bol by som prekvapený, ak by sme sa s rasterizáciou niekedy vôbec priblížili k takej kvalite aká sa dá dosiahnuť cez raytracing. Raterizácia je dosť o príprave a fake-ovaní. Je to skôr aproximácia požadovaného herného sveta. Raytracing na rozdiel od toho všetko reálne „počíta“. Ja verím tomu, že toto je cesta dopredu a bude to výrazný krok vo vizuále hier. To ale bude chcieť čas. Musia sa dolatiť API ako je DXR a urobiť podpora v herných engine-och. Tieto experimenty čo teraz ohlásil Microsoft a ukázala NVIDIA k tomu pomôžu. Tak skoro to ale v hrách neuvidíme. V blízkej budúcnosti tak 2 generácií GPU to vidím tak, že sa bude používať iba čiastočne. Možno na rendering iba malej časti scény alebo iba niektorých vybraných objektov. Prípadne ako píšem vyššie na predrenderované scény. To by mohlo byť tak o 5 rokov. Sú to len moje odhady, môže to byť všetko inak, ale verím tomu čo píšem.

          • Tohle je vsechno hezky treba to tak i bude. Mne ale zajima opravdu spis realny prinos. Ted nemyslim kompletne renderovanou scenu, kterou muzu videt treba v „CB“ (pro amatera meho kalibru to pro predstavu staci 😉 ). Jde mi napr. o tom co pises, ze by existoval „castecny“ rendering sceny a jak by se tento odlisoval od ‚fakovani‘ rasterizace. Prakticky priklad, na kterem by se dal videt realny prinos a realna radove vyssi kvalita snimku.

          • ps: ocekavam neco jako rozdil „low“ vs „ultra“ settings. Jestli je to realne nevim. A nebo je to neco jako ve hrach obecne napr. rozdily mezi „medium/high“ a „ultra“, kde clovek casto rozdily musi hledat, protoze jinak je ani nezaznamena,

          • Určite to bude záležať aj od prostredia, ale hlavne aj od parametrov takého renderovania. Napr. koľko lúčov sa použije, aká bude hĺbka rekurzie (teda koľkokrát dovolíme lúču sa maximálne odraziť, kým vypočítame konečnú farbu na povrchu objektu) a pod. Zo začiatku to ani nebude možno nejak citeľne viditeľný rozdiel. Stále sme asi ďaleko od fotorealizmu. Kvalita by sa ale mala zlepšovať s pribúdajúcim výkonom. Inak ja v tomto tiež nie som špecialista. Mali sme raytracing na škole, ale osobne som ho nikdy neprogramoval. Takže sa môžem v odhadoch a predpokladoch mýliť, ale snažím sa udržať si v tomto nadhľad.

          • Inak tie obrázky v tebou uvedenom odkaze sú zavádzajúce. Nie tak v lepšej kvalite tieňov a osvetlenia, ale hlavne v odraze v zrkadlách. Odraz všetkých objektov sa dú urobiť aj rasterizáciou, ale je to dosť nákladné. Pre každé zrkadlo musíš vyrenderovať celú scénu zvlášť z jeho pohľadu a vyrenderovanú textúru na neho prilepiť. Takže keď sa to už niekde robí, tak s malým rozlíšením alebo tak, že tam nie sú všetky objekty. Ale to neznamená, že rasterizáciou nedosiahneš tak detailný odraz okolitého sveta v zrkadle, ako to môže z uvedeného zdroja vyplývať.

          • Jinak dobry postreh Marku, ohledne te rasterizace. V tom nemeckem textu k obrazku zaznelo neco podobneho. A sice, ze si nejsou jisti, jestli byla ‚rasterizace‘ vyuzita naplno, aby mohlo byt dosazeno lepsiho „woh“ efektu pro raytr. 🙂

        • Diky za upozorneni. Jinak, nebude to nahodou tak, ze pres DXR pojedou zezacatku jen nektere veci a s pribyvajicim vykonem jich bude pribyvat? Pokud ano, tak to samozrejme bude uzirat vykon a uz vidim jak bude v nekterych alejich nablito. Ale mozna ze ne, to pokud to pojede lepe na AMD, tak to bude najednou to pozirani vykonu naprosto v poradku. 🙂

          • NVIDIA na rozdiel od AMD aj niečo predviedla. V alejách o ktorých píšeš sa na to samozrejme ohľad neberie. Keby to bolo opačne, čítali by sme tam o koľko je AMD technologicky popredu. Tiež to vidím tak, že sa bude spočiatku používať málo a budeme mať k dispozícii hybridné renderer-y (rasterizácia + raytracing) s väčšou mierou využívania rasterízácie. Sa to postupne snáď preklenie s pribúdajúcim výkonom. V to dúfam.

    • Nie je to o tom, že AMD nič nerobí, ale v čase prvých príspevkov niečo ukázala iba NV. A to nielen oznam, ale aj reálny výsledok v podobe API v rámci Gameworks a ukážok na ktorých spolupracovali. Inak ale celkovo marketing funguje na oboch stranách. Keď vidím tie porovnávania „Rasterized Image“ vs „Ray-Tracing“, tak ten prvý je pekne podcenený nastavením. To sa netýka iba AMD, ale aj iných porovnaní napríklad od MS či v 3D Marku.