Inlägg

Det här är fantastiskt roligt och intressant att läsa/titta på! Om du har tid och möjlighet får du gärna berätta om hur mycket arbete det varit med att få in VRS-stöd i titlar utan det, hur stabilt stödet är och dina planer om projektet. Grymt kul, kan bli så att vi lyfter in en av dina videos i vår artikel om ämnet

Spännande! Dock inget som lär fungera med 1080Ti förmodar jag.

Extremt bra jobbat! Hade jag bara kunnat använda det i PUBG rakt upp och ner? Måste man starta binären från ditt program eller hookar den på automagiskt på något sätt?

Ser ju riktigt lovande ut! Duktigt jobbat!

Har du någon forskning på om det även går att nyttja på Linux-baserade OS via ex. Vulkan API?
Det vore rätt intressant att få någon indikation på det just p.g.a. hur dåligt optimerade spel kan vara för just den plattformen.

Gissar på att tekniken i DX12 som du refererar till motsvarar denna funktionalitet hos Vulkan:

https://www.khronos.org/registry/vulkan/specs/1.2-extensions/...

Ser ju väldigt bra ut i videon. Skulle man kunna använda det för att nå ett frametime-mål?
Tex "sänk kvalitet tills frametime <= 8.55ms"? för att exempelvis försöka hålla 117 fps alltid i 4k.

Går det att köra det här fritt.
Eller måste utvecklarna implementera det i spelet?

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.

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.

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.

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

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.

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

Skickades från m.sweclockers.com

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.

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å.