DXR i Battlefield V, varför/därför så krävande? Undersökning med Triangelplockaren!

Permalänk
Medlem

DXR i Battlefield V, varför/därför så krävande? Undersökning med Triangelplockaren!

För knappt ett år sedan presenterades D3D12-strålspårning (ray tracing) som något nytt och tänkbart revolutionerande.

Jag har knåpat ihop ett verktyg för att visualisera hur och vad spel låter grafikkortet arbeta med.

Körning i Battlefield V (rastrering uppe, DXR nere):

Körning med endast DXR:

Uppe till vänster i spelfönstret visas hur lång tid GPUn arbetar med de olika strålspårningsstegen.
Se tiderna som riktvärden, verktyget har troligen en indirekt negativ påverkan.
Inom "bottom level"-tiden sker uppdatering av separata 3D-modeller (karaktär, sten, ...).
Inom "top level"-tiden uppdateras/skapas hela scenkompositionen, se det som en sammansättning av ett eller flera "bottom level"-objekt (karaktären placeras på stenen).

För mer info, se https://devblogs.nvidia.com/introduction-nvidia-rtx-directx-r...

Fönstret till höger visar de "top level"-datainstanser som kan ligga till grund för reflektionsberäkningar i spelet. Det är alltså trianglar som används för enbart strålspårning.

Om tonvikten i mätvärdena stämmer, är uppdatering av geometrin dyrare än strålspårningen i sig. Kan vara så att DXR-geometrin är baserad på/densamma som geometrin i rastreringsstegen (får undersöka). Det vore en kostnadseffektiv lösning i dagsläget då endast de med nyare grafikkort kan spela med DXR påslaget.

Frågor att diskutera:
- Varför denna omfattande och triangeltäta scenkomposition?
- Skulle likvärdiga reflektioner kunna strålspårberäknas med betydligt färre trianglar i scenkompositionen?

Detta är mitt första inlägg. Om tråden ligger i fel forumdel ber jag om ursäkt.

Visa signatur

Lärare i spelutveckling (BTH) som tycker om att tugga trianglar

Permalänk
Medlem

Mycket intressant verktyg du gjort - Bra namn också.

En viktig grafikoptimering är just frustum culling som plockar bort trianglar som inte kommer synas på skärmen - typ det som visualiseras i översta fönstret i första klippet. För att raytracing skall kunna få bra reflektioner så måste man ju rendrera otroligt mycket extra trianglar. Är det just detta du visar med ditt verktyg?

Permalänk
Medlem
Skrivet av dblade:

Mycket intressant verktyg du gjort - Bra namn också.

En viktig grafikoptimering är just frustum culling som plockar bort trianglar som inte kommer synas på skärmen - typ det som visualiseras i översta fönstret i första klippet. För att raytracing skall kunna få bra reflektioner så måste man ju rendrera otroligt mycket extra trianglar. Är det just detta du visar med ditt verktyg?

Tack och tack

Det stämmer, frustum culling är effektivt för att klippa i och inför rasterpipen. Dock är det, precis som du skriver, svårt att applicera i raytracing-kontext pga strålarna kan studsa runt lite varstans. Effektiv raytracing uppnås i DXR med förberäknad data (det som visas i verktyget). Mitt huvudbry är varför triangeldensiteten är så pass hög i Battlefield. Raytracing används, mig veterligen, endast för reflektionerna och att de skulle kräva denna triangelmängd är något svårsmält. Mängden verkar inte påverkas av DXR-inställningen heller (får dubbelkolla senare).

Jag är kodare och förhoppningsvis kommer alla knivskarpa grafiker och technical artists hit och lär mig ett och annat om hur DXR-grytan ska beredas.

Visa signatur

Lärare i spelutveckling (BTH) som tycker om att tugga trianglar

Permalänk
Medlem
Skrivet av swecoder:

Tack och tack

Det stämmer, frustum culling är effektivt för att klippa i och inför rasterpipen. Dock är det, precis som du skriver, svårt att applicera i raytracing-kontext pga strålarna kan studsa runt lite varstans. Effektiv raytracing uppnås i DXR med förberäknad data (det som visas i verktyget). Mitt huvudbry är varför triangeldensiteten är så pass hög i Battlefield. Raytracing används, mig veterligen, endast för reflektionerna och att de skulle kräva denna triangelmängd är något svårsmält. Mängden verkar inte påverkas av DXR-inställningen heller (får dubbelkolla senare).

Jag är kodare och förhoppningsvis kommer alla knivskarpa grafiker och technical artists hit och lär mig ett och annat om hur DXR-grytan ska beredas.

Trodde först du var anställd av Dice. Men du kanske borde hjälpa dom med lite optimering ? Vad är triangel-skillnaden mellan DXR av/på?

Permalänk
Medlem
Skrivet av dblade:

Trodde först du var anställd av Dice. Men du kanske borde hjälpa dom med lite optimering ? Vad är triangel-skillnaden mellan DXR av/på?

Nja, tror nog att de är mer kompetenta kring detta

I filmklippet ser du triangelantalet som finns i enbart DXT-datan. Så ca ~1,6 miljoner i enbart DXR-underlaget.

Visa signatur

Lärare i spelutveckling (BTH) som tycker om att tugga trianglar

Permalänk
Relik 📜

Spännande!

Det kryllar ju inte av RTX-titlar just nu, men bara antar du kan köra samma verktyg på till exempel Metro eller Tomb Raider (vilket år som helst..)?

Visa signatur

För övrigt anser jag att Karthago bör förstöras.
▪ Nöje #1 -> i5-11400F - B560M-ITX/ac - RTX 3070 - 16 GB DDR4
▪ Nöje #2 -> R5 5600 - Prime B450-Plus - RX 6750 XT - 16 GB DDR4
▪ Mobilt -> HP Pavilion Aero - R5 5625U - 16 GB DDR4
▪ Konsol -> Steam Deck, Xbox Series S

Permalänk
Medlem
Skrivet av emilakered:

Spännande!

Det kryllar ju inte av RTX-titlar just nu, men bara antar du kan köra samma verktyg på till exempel Metro eller Tomb Raider (vilket år som helst..)?

Det stämmer, min förhoppning är att kunna köra verktyget på Metro, Anthem (i morgon?) och Tomb Raider (patch när?), mfl så snart de kommer.

Visa signatur

Lärare i spelutveckling (BTH) som tycker om att tugga trianglar

Permalänk
Medlem

Är det lätt eller svårt för speltillverkare att "bara" slänga på denna tekniken i efterhand i form av en pimp-patch speciellt på spel som nu är väldigt lättdrivna som det är men kanske skulle må bra visuellt av denna nya teknik?
Dem behöver väl inte skriva om hela spelet? finns det hopp att tro att få se andra titlar få detta som inte var skriva för det från start efter som detta är nytt?
Har inbillat mig att Nvidia säger, it just works and it is easy.. hmm..

Permalänk
Medlem

Välkommen till Sweclockers! Trevlig första tråd.

Skrivet av swecoder:

Frågor att diskutera:
- Varför denna omfattande och triangeltäta scenkomposition?
- Skulle likvärdiga reflektioner kunna strålspårberäknas med betydligt färre trianglar i scenkompositionen?

Ej programmerare men av vad jag har förstått både av de jag har läst och de programmerare jag har pratat med så spelar antalet trianglar i princip ingen roll för prestandan, däremot är upplösningen av en stor betydelse.

Därför så kan det vara bra att trycka på med trianglar av denna anledning, minimal prestandapåverkan samtidigt högre detaljer i scenen.

edit: men eftersom detta är en hybrid-renderare så bör trianglar spela roll och belasta rastererar-delen, såvida dessa olika "renderare-delar" inte skulle ha separate LOD parametrar eller något liknande.

Permalänk
Medlem

Pga eftersläpet i effekten, så skulle jag gissa att den helt enkelt använder existerande data för att beräkna effekten till nästa frame. är dock inte så insatt i detta så ta min gissning med en nypa salt.

Permalänk
Medlem

8:25 i första videon. Soldat klarar inte av att leva ett liv utan ray tracing - färgsatt.
Nästa gång Jen Hsun Huang går upp på scen kommer han ha bytt mantra från "It just works" till "Rasterisation leads to castration". Omedelbart så får 140% av alla spel RTX och världsfred uppnås.

Skämt åsido, riktigt bra jobbat. Ska bottom-level hierarkin verkligen ta så lång tid? På trudelur scenen så kunde den ju uppgå upp mot 18ms , medan ray dispatch och top-level build var mer eller mindre försumbara. Noterade även att trudelur scenen hade långt färre trianglar i top-level hierarkin än norge scenen och gick avsevärt långsammare.
Enligt denna gamla rapport (som för övrigt AMD använder i sin Radeonrays kernel) så kunde en GTX 280 kunna återbygga en turbin som sprängdes i 1,78 miljoner delar på ~65ms. Jag vet inte vad du har för grafikkort, men jag har en känsla av att det nästan skulle gå lika snabbt att bygga upp allting från grunden just i det fallet i stället för refitting som nämns i deras turing whitepaper s.71.

Skrivet av swecoder:

Om tonvikten i mätvärdena stämmer, är uppdatering av geometrin dyrare än strålspårningen i sig. Kan vara så att DXR-geometrin är baserad på/densamma som geometrin i rastreringsstegen (får undersöka). Det vore en kostnadseffektiv lösning i dagsläget då endast de med nyare grafikkort kan spela med DXR påslaget.

Frågor att diskutera:
- Varför denna omfattande och triangeltäta scenkomposition?
- Skulle likvärdiga reflektioner kunna strålspårberäknas med betydligt färre trianglar i scenkompositionen?

Om vi antar att det är ett binärträd så sorterar vi bort ~hälften av alla trianglar för varje intersection test. Då spelar antalet trianglar inte så stor roll. T.ex log (1,8m) = 20,78 medan log(900k)= 19,78 alltså relativt försumbart. De nämner även att antalet trianglar inte spelade så stor roll, men antalet instanser gjorde det. Sedan så kan möjligtvis en lägre detaljerad struktur påverka åt vilket håll strålarna färdas, vilket kommer påverka noggrannheten. Till vilken grad är jag inte helt säker på.

Det är även en del av specifikationen att all geometri skall vara tillgänglig. " Rays can go anywhere so all geometry and shaders must be simultaneously available" .

Permalänk
Medlem
Skrivet av HappyPie:

Välkommen till Sweclockers! Trevlig första tråd.

Ej programmerare men av vad jag har förstått både av de jag har läst och de programmerare jag har pratat med så spelar antalet trianglar i princip ingen roll för prestandan, däremot är upplösningen av en stor betydelse.

Därför så kan det vara bra att trycka på med trianglar av denna anledning, minimal prestandapåverkan samtidigt högre detaljer i scenen.

edit: men eftersom detta är en hybrid-renderare så bör trianglar spela roll och belasta rastererar-delen, såvida dessa olika "renderare-delar" inte skulle ha separate LOD parametrar eller något liknande.

Tack. Antalet trianglar spelar roll då de måste uppdateras (animationer, etc.). När de väl är uppdaterade och indelade i trädstrukturen spelar antalet en mindre roll.

Skrivet av Radolov:

Skämt åsido, riktigt bra jobbat. Ska bottom-level hierarkin verkligen ta så lång tid? På trudelur scenen så kunde den ju uppgå upp mot 18ms , medan ray dispatch och top-level build var mer eller mindre försumbara. Noterade även att trudelur scenen hade långt färre trianglar i top-level hierarkin än norge scenen och gick avsevärt långsammare.
Enligt denna gamla rapport (som för övrigt AMD använder i sin Radeonrays kernel) så kunde en GTX 280 kunna återbygga en turbin som sprängdes i 1,78 miljoner delar på ~65ms. Jag vet inte vad du har för grafikkort, men jag har en känsla av att det nästan skulle gå lika snabbt att bygga upp allting från grunden just i det fallet i stället för refitting som nämns i deras turing whitepaper s.71.

Om vi antar att det är ett binärträd så sorterar vi bort ~hälften av alla trianglar för varje intersection test. Då spelar antalet trianglar inte så stor roll. T.ex log (1,8m) = 20,78 medan log(900k)= 19,78 alltså relativt försumbart. De nämner även att antalet trianglar inte spelade så stor roll, men antalet instanser gjorde det. Sedan så kan möjligtvis en lägre detaljerad struktur påverka åt vilket håll strålarna färdas, vilket kommer påverka noggrannheten. Till vilken grad är jag inte helt säker på.

Lite samma svar som ovan. Binärträdsresonemanget stämmer först då geometrin finns tillgänglig. All bottom-level-tid (som mycket väl kan vara felaktig i videon) är i stort uppdatering av geometri. Det finns någon underliggande trädstruktur och intersektionstesterna sker i "dispatch ray"-tiden.

Visa signatur

Lärare i spelutveckling (BTH) som tycker om att tugga trianglar

Permalänk
Medlem

Var en fin igenom gång då kan jag sitta lungt med mitt GTX1080ti 😀

Visa signatur

Låda thermaltake view 91 M-kort ASUS X399 ROG Zenith Extreme CPU AMD Ryzen Threadripper 1920X 3.5 GHz Kylning Hemma byggd vattenkylning 2 x 480mm + 1 x 420mm radiatorer Minne 8 X 16Gb DDR4 HD SSD 240GB OCZ Trion 100 Grafik Gigabyte Geforce RTX 3080 10GB GAMING OC WATERFORCE WB AGG Corsair RM 1000w 80+ Gold Skärm ASUS 43" ROG Strix XG438QR 4K VA HDR 120 Hz

Permalänk
Medlem

Då samtliga mätvärden, på olika sätt, påverkas av verktyget kommer här en filmsekvens där endast mätvärden presenteras. All "triangelplockning" är inaktiverad.

Notera! Verktyget är fortfarande aktivt. Verktyget ändrar spelets exekveringsbeteende. Dvs, verktyget kan alltid ha indirekt negativ påverkan och mätvärden ska därför aldrig ses som "sanningar".

En intressant iakttagelse kan ses vid 2:23-2:30. Vanligtvis i datorspel ökar prestandan då man tittar upp i luften eller ner i marken, detta pga "frustum culling" (objekt utanför kameran behöver inte ritas). Här ser vi det motsatta, fler objekt uppdateras just då man tittar upp och ner. Kan vara en tillfällighet på just den platsen, men lite intressant oavsett.

Visa signatur

Lärare i spelutveckling (BTH) som tycker om att tugga trianglar

Permalänk
Medlem
Skrivet av swecoder:

Då samtliga mätvärden, på olika sätt, påverkas av verktyget kommer här en filmsekvens där endast mätvärden presenteras. All "triangelplockning" är inaktiverad.

Notera! Verktyget är fortfarande aktivt. Verktyget ändrar spelets exekveringsbeteende. Dvs, verktyget kan alltid ha indirekt negativ påverkan och mätvärden ska därför aldrig ses som "sanningar".

En intressant iakttagelse kan ses vid 2:23-2:30. Vanligtvis i datorspel ökar prestandan då man tittar upp i luften eller ner i marken, detta pga "frustum culling" (objekt utanför kameran behöver inte ritas). Här ser vi det motsatta, fler objekt uppdateras just då man tittar upp och ner. Kan vara en tillfällighet på just den platsen, men lite intressant oavsett.

Den verkar bestämma sig att göra massiva uppdateringar vid ett visst tillfälle och återskapa i stort sett allting. I videon ser man även att antalet bottom-level instanser är det som dikterar prestandan, inte antalet trianglar (som man såg i förra videon var lägre för trudelur där den rätt så ofta hade ~2/3 - 3/4 av trianglarna, men långt många fler instanser).

Det finns en hyfsat stor intervju med en utvecklare där du kanske får några svar på dina frågor. Den har två månader på nacken så många ändringar där är redan implementerade. Ahhh...vänta ett tag. Jag har en möjlig förklaring till varför det blir fler objekt när du ser ner i marken. De har implementerat screen-space reflektioner och då kanske de tar bort de objekt i strukturen som är på skärmen? Tänk omvänd frustum culling . Det blev faktiskt sämre kvalité när de införde detta som kan ses här , men bättre prestanda.

Går det att markera alla bottom-level strukturer i triangelplockaren? Då kanske det blir lättare att resonera.

Om du vill ha en typ av sanity check, så ska antalet rays skala linjärt mot antalet pixlar (från samma kameravinkel/position). Så om du jämför 1080p med 4k så ska resultatet för ray tracing tiden vara ~4x så stor, medan tiderna för BVH:n bör vara opåverkad. Kan ju förstås vara så att vissa resurser blir upptagna när upplösningen ökar, men det är bara att testa på och se vad som händer.

Permalänk
Hjälpsam

Härlig tråd, känns nästan som att man är på forumet på Beoynd 3D, när det är som bäst.
Vi som förstår mindre än hälften, får sätta oss i passagerarsätet, njuta av åkturen och förhoppningsvis snappa upp lite kunskap på vägen.

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Medlem

Är spännande teknologi detta med raytracing.

Lär ju dock inte bli standard innan konsolerna anammar det. Så näst-nästa generation kanske man vågar hoppas på? Sex till sju år bort kanske?

Känns ju inte helt orimligt iaf. Då finns klart maffigare hårdvara tillgänglig osv. 2080ti nivå (på raytracing dvs) kanske går in i en konsol rätt billigt tex. Men den som lever får se

Tills dess får PC-spelare agera försökskaniner och hjälpa det hela mogna. Dock tror jag få med pengarna att investera i hårdvaran lider av att vara försökskaniner så att säga

Skickades från m.sweclockers.com

Visa signatur

| AMD Ryzen 7 5800X3D | Noctua NH-U12A | Gigabyte X570 Aorus Pro | Powercolor Radeon RX 6900XT Red Devil | 16GB G.Skill Trident Z@3600 CL15 | Gigabyte Aorus 2TB M.2 NVMe SSD | Fractal Design Ion+ Platinum 860W | Fractal Design Meshify S2 Blackout | Corsair K70 | Logitech G502 | Alienware AW3423DWF |

Permalänk
Avstängd
Skrivet av Zemlan:

Är spännande teknologi detta med raytracing.

Lär ju dock inte bli standard innan konsolerna anammar det. Så näst-nästa generation kanske man vågar hoppas på? Sex till sju år bort kanske?

Känns ju inte helt orimligt iaf. Då finns klart maffigare hårdvara tillgänglig osv. 2080ti nivå (på raytracing dvs) kanske går in i en konsol rätt billigt tex. Men den som lever får se

Tills dess får PC-spelare agera försökskaniner och hjälpa det hela mogna. Dock tror jag få med pengarna att investera i hårdvaran lider av att vara försökskaniner så att säga

Skickades från m.sweclockers.com

När kort med säg 4 dubbla strålspårnings prestanda hittar ut blir det pirrigt i penningspungen. Som foto och video intresserad ser spel förjävliga ut med ljussätningen i dagsläget. Dessutom äter den prestanda så tusan. Hoppas dom kan fixa så att strålspårning äter mindre 😁

Gillar Nvidias nya kort men inte bered på prispålägget. Skulle gärna köpa ett separat kort med strålspårning om det fanns, varför inte ett med AI också? Eller integrerat med chiplet design som AMD gör för att minska på priset? Då kunde folk välja. Gigantiska monolitiska kretsar känns lite omodernt. AMDs infinityfabric 2.0 ska ju ge upp till 1228 GB/s bandbredd, lär ju räcka för dessa ändamål. Åtminstone 2-3 år frammåt. Och endast 10-20 nanosekunder latens 😯

Visa signatur

2600x||16GB @3000Mhz 14-14-10-14-32-46||Vega 64||1TB SSD||HX1000 plat||FD R6 TG vit||CH VII||H100i V2||SST-ARM22SC||SG 32" QHD 144 Hz VA|| https://folding.extremeoverclocking.com/team_summary.php?s=&t...

Permalänk
Medlem

hmm, 3D Mark ska ju inkludera Port Royal , deras raytracing benchmark. Vore intressant att se om/vad du kan få ut för info med den.

Permalänk
Medlem

Ville bara nämna det för alla här men jag kör Battlefield V i 3820x2160p (Ultra) med Raytracing på medium. Inga problem att hålla över 60fps och de fåtal ggr man kommer under 60 så märks det inte på grund av Nvidia's FreeSync. Vissa miljöer i Battlefield är för snygga för att kunna fokusera på kriget. Ett 2080 Ti krävs för att uppnå detta.

Permalänk
Medlem

Jag har skrivit raytracing program i universitetet tidigare och satt och funderade på olika optimeringar som finns att göra.

För det första så använder ju närliggande pixlar oftast väldigt liknande data om inte identiska i många fall. Jag skulle kunna tänka mig att de compute-blocken (som i sin tur innehåller trådar) samarbetar väldigt mycket inom blocket med hjälp av delat minne för att snabbt hitta vart ungefär i hierarkin av geometri som strålarna träffar. Iaf för första träffen. Detta gör såklart att tillsammans med väl ordnade söklistor så kommer mängden trianglar spela väldigt liten roll. Alltså förmodligen så skalar raytracingen i sig nästintill oberoende av geometri som många vart inne på här.

Men uppdateringen av geometri i sig kommer ju ALLTID skala linjärt med antalat geometrier, givet att alla geometrier ska uppdateras. Man kommer ju aldrig komma ifrån detta tyvärr.

Jag spekulerar endast här vill jag tillägga. Tänkte jag skulle försöka titta mer på detta intressanta verktyg senare ikväll!

Skickades från m.sweclockers.com

Permalänk
Hjälpsam
Skrivet av dblade:

Ville bara nämna det för alla här men jag kör Battlefield V i 3820x2160p (Ultra) med Raytracing på medium. Inga problem att hålla över 60fps och de fåtal ggr man kommer under 60 så märks det inte på grund av Nvidia's FreeSync. Vissa miljöer i Battlefield är för snygga för att kunna fokusera på kriget. Ett 2080 Ti krävs för att uppnå detta.

Ganska realistiskt egentligen, soldater som stod och beundrade utsikten, strök nog med oftare än de som koncentrerade sig på att överleva.

Sorry för Off Topic.

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Medlem
Skrivet av Ratatosk:

Ganska realistiskt egentligen, soldater som stod och beundrade utsikten, strök nog med oftare än de som koncentrerade sig på att överleva.

Sorry för Off Topic.

Haha. Naturens lag tar ut sin rätt och i slutet på alla krig där det förmodligen bara finns överlevare kvar, så finns det inga som är intresserade av utsikten.

Själv vill jag mest gå runt och titta på reflektioner i bilar, fönsterglas och vattenpölar. Helt magiskt snyggt spel. Skulle man inte kunna ha testservers för de som inte är intresserade av att döda?

Permalänk
Medlem
Skrivet av HappyPie:

... vad jag har förstått både av de jag har läst och de programmerare jag har pratat med så spelar antalet trianglar i princip ingen roll för prestandan, ...

I så fall skulle det inte vara någon vits med tesselering, som ju minskar antalet trianglar med avståndet till objektet.

Permalänk
Datavetare
Skrivet av swecoder:

Frågor att diskutera:
- Varför denna omfattande och triangeltäta scenkomposition?
- Skulle likvärdiga reflektioner kunna strålspårberäknas med betydligt färre trianglar i scenkompositionen?

Detta är mitt första inlägg. Om tråden ligger i fel forumdel ber jag om ursäkt.

Episk förstapost

Först en disclamer: även om jag är programmerare så är det över ett decennium sedan det blev några större mängder 3D-programmering. Har sedan länge gått över till att jobba med OS-kärnor. Så har ingen superkoll på helheten i DX12 och kan inte påstå att jag har superkoll på speciellt många detaljer heller. Men har av intresse ändå läst på en del om just DXR.

Några saker som skulle kunna göra en diskussion lite enklare är om man förstod lite mer i detalj exakt vad det är för saker ditt verktyg kikar på.

Får jag gissa handlar det om någon form av proxy-implementation av DX12 dll:en, d.v.s. du har skrivit en komponent som exporterar DX12 interfacen och den proxyn gör den loggning som är intressant och skickar sedan vidare data till en verkliga DX12 dll:en.

Om så är fallet, vilka är metoderna som instrumenteras? Egentligen avsett hur programmet fungerar är detta viktigt att vara på det klara med.

Ett potentiellt problem för mätvärdena är att DX12 tillåter anrop från flera trådar samtidigt och biblioteket sköter erforderlig synkronisering. Finns då en möjlighet att t.ex. uppdatering av Bottom-Level Acceleration Structure (BLAS) råkar spendera relativt mycket tid för synkronisering mot andra trådar, så en mätning av det anropet tar även med tid när tråden egentligen inte gör något alls (den kanske inte är är schemalagd på en CPU-tråd under hela förloppet).

Det som klart talar för att stora kostnaden ligger i uppdatering av BLAS är att dokumentationen nämner att man bör minimera antalet uppdateringar till den strukturen då den är relativt dyr.
Känns ändå konstigt då BLAS i teorin bara behöver uppdateras om geometrin förändras. Man ser ju i första/andra videon att majoriteten av all geometri är statisk, förändring av kameran ändrar bara transformationsmatrisen och men inte värdet på vertexes hos geometri.

Det som ändras mellan varje scen är relativt enkla och stora fyrkanter (två trianglar) som används för att simulera drivande snö. Frågan är hur relevant denna geometri är för raytracing resultatet, var inte en av de riktigt stora optimeringarna att man uteslöt geometri för träd och löv ("foliage")?

Skrivet av swecoder:

Tack. Antalet trianglar spelar roll då de måste uppdateras (animationer, etc.). När de väl är uppdaterade och indelade i trädstrukturen spelar antalet en mindre roll.

Lite samma svar som ovan. Binärträdsresonemanget stämmer först då geometrin finns tillgänglig. All bottom-level-tid (som mycket väl kan vara felaktig i videon) är i stort uppdatering av geometri. Det finns någon underliggande trädstruktur och intersektionstesterna sker i "dispatch ray"-tiden.

Optimeringsguider pekar på att i den bästa av världar (sett ur DXR prestanda) skulle man bara ha två BLAS. En för statisk geometri som egentligen aldrig behöver uppdateras, samt en för dynamisk geometri som förhoppningsvis inte är lika stor. Statistiken från ditt program ger en vink om att princip alla BLAS strukturer uppdateras varje scen.

Om det stämmer, varför gör man så? Optimeringstipsen jag sett här säger att det är bättre att dels separera BLAS i statiskta resp. dynamiska delar. Vidare kan man m.h.a. top-level AS (TLAS) utföra vissa typer av animationer (rigid-body), TLAS är mycket billigare att uppdatera.

DXR verkar ju lämna rätt mycket frihet till underliggande implementation för representation av data. Enda man vet med säkerhet är att RT-kärnorna använder sig av "bounding volume hierarchies" (BVH), men har då inte hittat någon information kring hur olika BVH-boxar ordas sinsemellan samt hur man matchar alla trianglar inom matchande BVH (Microsoft skriver bara att det finns en väldigt effektiv any-hit-shader integrerad i DXR för trianglar).

Angående mätning av sista steget, d.v.s. TraceRay() jobbet. Är det verkligen tiden till att all ray-tracing är klar som mäts här eller mäts bara tiden för att kicka igång alla strålar? Själva jobbet utförs ju rätt mycket asynkront m.a.p. CPU-tråden när det väl startats (men finns självklart sätt att säga åt DX12, jag vill blocka till dess att en visst uppgift är klar på GPU-sidan).

Skrivet av Jackbob:

Jag har skrivit raytracing program i universitetet tidigare och satt och funderade på olika optimeringar som finns att göra.

För det första så använder ju närliggande pixlar oftast väldigt liknande data om inte identiska i många fall. Jag skulle kunna tänka mig att de compute-blocken (som i sin tur innehåller trådar) samarbetar väldigt mycket inom blocket med hjälp av delat minne för att snabbt hitta vart ungefär i hierarkin av geometri som strålarna träffar. Iaf för första träffen. Detta gör såklart att tillsammans med väl ordnade söklistor så kommer mängden trianglar spela väldigt liten roll. Alltså förmodligen så skalar raytracingen i sig nästintill oberoende av geometri som många vart inne på här.

Men uppdateringen av geometri i sig kommer ju ALLTID skala linjärt med antalat geometrier, givet att alla geometrier ska uppdateras. Man kommer ju aldrig komma ifrån detta tyvärr.

Jag spekulerar endast här vill jag tillägga. Tänkte jag skulle försöka titta mer på detta intressanta verktyg senare ikväll!

Som jag skrev ovan har ju DXR rätt få krav på exakt hur en implementation lagrar data, men gissar att uppdatering tyvärr är dyrare än linjärt. Gissningsvis skapas någon form av sökträd i BLAS, att uppdatera blir då typ O(N*log(N)). Fördelen är att varje stråle då kan söka på O(log(N)) i stället för O(N).

Men vet inte om RTX satsat på gungor eller karuseller här
Kan därför vara så att uppdateringar är linjära i kostnad m.a.p. storlek på geometri.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Skrivet av swecoder:

För knappt ett år sedan presenterades D3D12-strålspårning (ray tracing) som något nytt och tänkbart revolutionerande.

Jag har knåpat ihop ett verktyg för att visualisera hur och vad spel låter grafikkortet arbeta med.

Körning i Battlefield V (rastrering uppe, DXR nere):
https://www.youtube.com/watch?v=0uSVRLi02-c

Körning med endast DXR: https://youtu.be/Diqqs7XSWoo

Uppe till vänster i spelfönstret visas hur lång tid GPUn arbetar med de olika strålspårningsstegen.
Se tiderna som riktvärden, verktyget har troligen en indirekt negativ påverkan.
Inom "bottom level"-tiden sker uppdatering av separata 3D-modeller (karaktär, sten, ...).
Inom "top level"-tiden uppdateras/skapas hela scenkompositionen, se det som en sammansättning av ett eller flera "bottom level"-objekt (karaktären placeras på stenen).

För mer info, se https://devblogs.nvidia.com/introduction-nvidia-rtx-directx-r...

Fönstret till höger visar de "top level"-datainstanser som kan ligga till grund för reflektionsberäkningar i spelet. Det är alltså trianglar som används för enbart strålspårning.

Om tonvikten i mätvärdena stämmer, är uppdatering av geometrin dyrare än strålspårningen i sig. Kan vara så att DXR-geometrin är baserad på/densamma som geometrin i rastreringsstegen (får undersöka). Det vore en kostnadseffektiv lösning i dagsläget då endast de med nyare grafikkort kan spela med DXR påslaget.

Frågor att diskutera:
- Varför denna omfattande och triangeltäta scenkomposition?
- Skulle likvärdiga reflektioner kunna strålspårberäknas med betydligt färre trianglar i scenkompositionen?

Detta är mitt första inlägg. Om tråden ligger i fel forumdel ber jag om ursäkt.

OffT: Jag sa ju att du skulle få bättre respons här än FZ!

Skickades från m.sweclockers.com

Visa signatur

Citera för svar!

Permalänk
Hedersmedlem

*Inlägg raderade*

Citat:

§1.6 Meningslösa inlägg som inte för diskussionen framåt är förbjudna. Detta omfattar inlägg som utan vidare motivering uttrycker medhåll eller missnöje. [..]

Visa signatur

Danskjävel så krattar som en skrivare...

Permalänk
Medlem
Skrivet av Radolov:

Den verkar bestämma sig att göra massiva uppdateringar vid ett visst tillfälle och återskapa i stort sett allting. I videon ser man även att antalet bottom-level instanser är det som dikterar prestandan, inte antalet trianglar (som man såg i förra videon var lägre för trudelur där den rätt så ofta hade ~2/3 - 3/4 av trianglarna, men långt många fler instanser).

Det finns en hyfsat stor intervju med en utvecklare där du kanske får några svar på dina frågor. Den har två månader på nacken så många ändringar där är redan implementerade. Ahhh...vänta ett tag. Jag har en möjlig förklaring till varför det blir fler objekt när du ser ner i marken. De har implementerat screen-space reflektioner och då kanske de tar bort de objekt i strukturen som är på skärmen? Tänk omvänd frustum culling . Det blev faktiskt sämre kvalité när de införde detta som kan ses här , men bättre prestanda.

Går det att markera alla bottom-level strukturer i triangelplockaren? Då kanske det blir lättare att resonera.

Om du vill ha en typ av sanity check, så ska antalet rays skala linjärt mot antalet pixlar (från samma kameravinkel/position). Så om du jämför 1080p med 4k så ska resultatet för ray tracing tiden vara ~4x så stor, medan tiderna för BVH:n bör vara opåverkad. Kan ju förstås vara så att vissa resurser blir upptagna när upplösningen ökar, men det är bara att testa på och se vad som händer.

Det kan vara som du skriver att antalet instanser spelar större roll än antalet trianglar. Om vi ser både bottom- och top level-strukturerna som sökträd, bör antalet trianglar påverka generering av bottom-level-träden. Ska testa variera antalet trianglar som används i bottom level-strukturen.

Håller på och uppdaterar så att separata instanser kan markeras i plockaren. Ska även lägga in stöd för att "följa en specifik modell", kan vara intressant att låsa kameran på ex spelaren.

Tackar för ditt svar och förhoppningsvis har vi mer data att resonera kring framöver.

Skrivet av Lordsqueak:

hmm, 3D Mark ska ju inkludera Port Royal , deras raytracing benchmark. Vore intressant att se om/vad du kan få ut för info med den.

Tack för info! Får införskaffa programmet och testa.

Skrivet av Olle P:

I så fall skulle det inte vara någon vits med tesselering, som ju minskar antalet trianglar med avståndet till objektet.

Nja, tessellering "minskar inte antalet trianglar". Det som sker är att antalet trianglar, relativt ursprungsmodellen, dynamiskt ökar ju närmare kameran (eller annat villkor) de befinner sig.

Skrivet av Yoshman:

Episk förstapost

Först en disclamer: även om jag är programmerare så är det över ett decennium sedan det blev några större mängder 3D-programmering. Har sedan länge gått över till att jobba med OS-kärnor. Så har ingen superkoll på helheten i DX12 och kan inte påstå att jag har superkoll på speciellt många detaljer heller. Men har av intresse ändå läst på en del om just DXR.

Några saker som skulle kunna göra en diskussion lite enklare är om man förstod lite mer i detalj exakt vad det är för saker ditt verktyg kikar på.

Får jag gissa handlar det om någon form av proxy-implementation av DX12 dll:en, d.v.s. du har skrivit en komponent som exporterar DX12 interfacen och den proxyn gör den loggning som är intressant och skickar sedan vidare data till en verkliga DX12 dll:en.

Om så är fallet, vilka är metoderna som instrumenteras? Egentligen avsett hur programmet fungerar är detta viktigt att vara på det klara med.

Ett potentiellt problem för mätvärdena är att DX12 tillåter anrop från flera trådar samtidigt och biblioteket sköter erforderlig synkronisering. Finns då en möjlighet att t.ex. uppdatering av Bottom-Level Acceleration Structure (BLAS) råkar spendera relativt mycket tid för synkronisering mot andra trådar, så en mätning av det anropet tar även med tid när tråden egentligen inte gör något alls (den kanske inte är är schemalagd på en CPU-tråd under hela förloppet).

Det som klart talar för att stora kostnaden ligger i uppdatering av BLAS är att dokumentationen nämner att man bör minimera antalet uppdateringar till den strukturen då den är relativt dyr.
Känns ändå konstigt då BLAS i teorin bara behöver uppdateras om geometrin förändras. Man ser ju i första/andra videon att majoriteten av all geometri är statisk, förändring av kameran ändrar bara transformationsmatrisen och men inte värdet på vertexes hos geometri.

Det som ändras mellan varje scen är relativt enkla och stora fyrkanter (två trianglar) som används för att simulera drivande snö. Frågan är hur relevant denna geometri är för raytracing resultatet, var inte en av de riktigt stora optimeringarna att man uteslöt geometri för träd och löv ("foliage")?

Optimeringsguider pekar på att i den bästa av världar (sett ur DXR prestanda) skulle man bara ha två BLAS. En för statisk geometri som egentligen aldrig behöver uppdateras, samt en för dynamisk geometri som förhoppningsvis inte är lika stor. Statistiken från ditt program ger en vink om att princip alla BLAS strukturer uppdateras varje scen.

Om det stämmer, varför gör man så? Optimeringstipsen jag sett här säger att det är bättre att dels separera BLAS i statiskta resp. dynamiska delar. Vidare kan man m.h.a. top-level AS (TLAS) utföra vissa typer av animationer (rigid-body), TLAS är mycket billigare att uppdatera.

DXR verkar ju lämna rätt mycket frihet till underliggande implementation för representation av data. Enda man vet med säkerhet är att RT-kärnorna använder sig av "bounding volume hierarchies" (BVH), men har då inte hittat någon information kring hur olika BVH-boxar ordas sinsemellan samt hur man matchar alla trianglar inom matchande BVH (Microsoft skriver bara att det finns en väldigt effektiv any-hit-shader integrerad i DXR för trianglar).

Angående mätning av sista steget, d.v.s. TraceRay() jobbet. Är det verkligen tiden till att all ray-tracing är klar som mäts här eller mäts bara tiden för att kicka igång alla strålar? Själva jobbet utförs ju rätt mycket asynkront m.a.p. CPU-tråden när det väl startats (men finns självklart sätt att säga åt DX12, jag vill blocka till dess att en visst uppgift är klar på GPU-sidan).

Som jag skrev ovan har ju DXR rätt få krav på exakt hur en implementation lagrar data, men gissar att uppdatering tyvärr är dyrare än linjärt. Gissningsvis skapas någon form av sökträd i BLAS, att uppdatera blir då typ O(N*log(N)). Fördelen är att varje stråle då kan söka på O(log(N)) i stället för O(N).

Men vet inte om RTX satsat på gungor eller karuseller här
Kan därför vara så att uppdateringar är linjära i kostnad m.a.p. storlek på geometri.

Tack!

Du gissar helt korrekt, verktyget bygger på proxy-implementationer av samtliga gränssnitt i D3D12. Det innebär att mätningar kan ske lite där vi vill ha dem. Samtliga mätvärden i filmklippen sker utan några direkta låsmekanismer från min sida. Uppdateringar av trädstrukturer sker på GPUn och mäts mha mätpunkter (D3D12_QUERY_TYPE_TIMESTAMP). Exempel:

MätpunktPåGPUStart();
DispatchRays();
MätpunktPåGPUEnd();

När mätpunkter för hel frame finns i RAM (jag låser inte och väntar på att de finns tillgängliga) beräknas tiden enligt: time = (end - start) * gpu_frequency_to_ms;

Tiden som mäts blir då den faktiska tid GPUn spenderat på anropen mellan start() och end().

I Battlefield appliceras ingen transformation på bottom level-geometrin. All uppdartering är ren överskrivning av befintlig triangeldata. Endast top level-instanser transformeras med matris.

Varför många BLAS uppdateras vet jag inte, kanske är det så att objekten faktiskt är animerade och behöver uppdateras. Hur interna strukturen är vet vi inte, vi vet bara att DXR har full frihet att omtolka ingående data, ref D3D12_RAYTRACING_ACCELERATION_STRUCTURE_COPY_MODE_VISUALIZATION_DECODE_FOR_TOOLS här https://docs.microsoft.com/sv-se/windows/desktop/api/d3d12/ne....

Ska försöka göra lite fler undersökningar där antalet trianglar som skickas för BLAS ändras. Ex, spelet skapar BLAS med 100 trianglar men jag omskalar antalet olika mycket; 100 * 0.25, 100 * 0.3, osv...

Skrivet av Megagurra:

OffT: Jag sa ju att du skulle få bättre respons här än FZ!

Skickades från m.sweclockers.com

Tack, mycket bra förslag

Visa signatur

Lärare i spelutveckling (BTH) som tycker om att tugga trianglar

Permalänk
Medlem
Skrivet av swecoder:

Nja, tessellering "minskar inte antalet trianglar". Det som sker är att antalet trianglar, relativt ursprungsmodellen, dynamiskt ökar ju närmare kameran (eller annat villkor) de befinner sig.

Exakt vad jag skrev: Mindre antal trianglar på föremål längre bort jämfört med samma föremål nära.
Alternativet är ju att ha exakt lika många trianglar oavsett om föremålet, exempelvis ett ansikte på en NPC, befinner sig en halvmeter eller en kilometer bort.

Permalänk
Medlem
Skrivet av Olle P:

Exakt vad jag skrev: Mindre antal trianglar på föremål längre bort jämfört med samma föremål nära.
Alternativet är ju att ha exakt lika många trianglar oavsett om föremålet, exempelvis ett ansikte på en NPC, befinner sig en halvmeter eller en kilometer bort.

Ber om ursäkt om jag feltolkat dig. I din ursprungstext kan budskapet tolkas som att tekniken "tesselering" minskar antalet trianglar. Det stämmer inte, tesselering på grafikkortet kan endast öka antalet trianglar.

"I så fall skulle det inte vara någon vits med tesselering, som ju minskar antalet trianglar med avståndet till objektet."

Visa signatur

Lärare i spelutveckling (BTH) som tycker om att tugga trianglar