Deliver Us The Moon – ray tracing med Nvidia Geforce RTX Super

Permalänk
Medlem
Skrivet av Yoshman:

Finns det någon tillförlitlig information kring exakt hur mycket kretsyta RT-kärnorna och Tensor-kärnorna skulle ta? Jämförelser mellan 1600-serien och 2000-serien pekar ju på att det inte handlar om speciellt mycket yta.

Är ju några som gett sig på att försöka lura ut detta från die-shots, t.ex. denna. Om den stämmer tar ju RT-kärnor + tensor-kärnor ~10 % extra kretsyta, väsentligt mer av tillskottet kommer från (enligt dig själv) de mer användbara tensor-kärnorna.

Om man tittar vad RT-kärnorna faktiskt utför borde de ta väldigt lite kisel, det är en extremt specifik uppgift de har och för att få till hela ray tracing delen används en kombination av RT-kärnor och de vanliga CUDA-kärnorna. Det borde vara goda nyheter även för de som inte ser värdet i ray tracing, detta då Nvidia har ett väldigt starkt incitament att fortsätta öka kapaciteten för de "vanliga" CUDA-kärnorna även för att förbättra ray tracing stödet.

Jag baserar mig på vaga minnen av nånting jag såg i närheten av release, har tyvärr knappast någon länk tyvärr. Troligen adoredtv eller liknande.

Min bild av RT är att det är en helt annan form av beräkningar än en vanlig gpu och kan därför dela väldigt lite resurser med resterande gpu. Förenklat kan man säga att en vanlig gpu last kör samma program på varierad data (rotera alla punkter via en fast matris, men alla punkter kan vara olika) medan rt är helt annorlunda. Vanliga operationer i rt är att beräkna studsar av strålar och hitta objekt i närheten av dom, dessa operationer är extremt svåra att köra på en gpu eftersom varje stråle studsar (troligen) i en egen vinkel på en annan yta än alla andra, dessutom sprider sig alla strålar åt olika håll vilket gör att de är nära och interagerar med helt olika objekt. Enklaste sättet är att se rt som singeltrådat, därför räknade jag med att det var separat kisel som behövdes...

Något liknande denna bild:

Skickades från m.sweclockers.com

Permalänk
Medlem
Skrivet av Yoshman:

Finns det någon tillförlitlig information kring exakt hur mycket kretsyta RT-kärnorna och Tensor-kärnorna skulle ta? Jämförelser mellan 1600-serien och 2000-serien pekar ju på att det inte handlar om speciellt mycket yta.

Är ju några som gett sig på att försöka lura ut detta från die-shots, t.ex. denna. Om den stämmer tar ju RT-kärnor + tensor-kärnor ~10 % extra kretsyta, väsentligt mer av tillskottet kommer från (enligt dig själv) de mer användbara tensor-kärnorna.

Det är förmodligen korrekt. Tidigare forskning säger att 4 TUs kan gå för så lite som t.ex 6% av ALU area:n . Så att det blir 10% totalt är inte konstigt alls. Jag hade visserligen tyckt att det skulle vara fantastiskt om tensor cores kunde utnyttjas samtidigt* så hade det tagit DLSS från ganska bra till extremt bra!

*Visserligen kan de utföra FP16 samtidigt, men det hjälper inte denna versionen av DLSS....eller? Problemet med blackbox design är att man inte kan kolla upp vad som sker enkelt, men om någon kör spelet och kör en frame capture med nvidia inspector (om jag inte minns fel) med DLSS på kan man avgöra om det är för typ baserat på occupancy. Vem vet, kanske denna version körs asynkront?

Skrivet av Yoshman:

Om man tittar vad RT-kärnorna faktiskt utför borde de ta väldigt lite kisel, det är en extremt specifik uppgift de har och för att få till hela ray tracing delen används en kombination av RT-kärnor och de vanliga CUDA-kärnorna. Det borde vara goda nyheter även för de som inte ser värdet i ray tracing, detta då Nvidia har ett väldigt starkt incitament att fortsätta öka kapaciteten för de "vanliga" CUDA-kärnorna även för att förbättra ray tracing stödet.

Jag är inte helt säker på om de kommer att ha samma förhållande mellan CUDA-, RT- och tensor kärnorna. Om DLSS gör så att de kan köra i en lägre upplösning (vilket minskar trycket på CUDA-kärnorna) så kan de lägga mer area på t.ex tensor kärnorna. För det kan minska både tiden för denoising och uppskalning. Helt plötsligt har de en attraktivare produkt för ML och RT. Men risken finns att om de specialiserar sig för mycket så förlorar de någon marknad, medan dominerar andra. Och om de gör en för bred arkitektur finns risk att Intel och AMD kommer ikapp med specialisering. Men NVIDIA hanterar förmodligen det säkert bra.

Jag tror däremot att de kommer ha samma förhållande för att ha någonting för träningen... än så länge. I framtiden så kommer förmodligen en större del att tillägnas RT delen.

Permalänk
Medlem
Skrivet av Radolov:

Det är förmodligen korrekt. Tidigare forskning säger att 4 TUs kan gå för så lite som t.ex 6% av ALU area:n . Så att det blir 10% totalt är inte konstigt alls. Jag hade visserligen tyckt att det skulle vara fantastiskt om tensor cores kunde utnyttjas samtidigt* så hade det tagit DLSS från ganska bra till extremt bra!

*Visserligen kan de utföra FP16 samtidigt, men det hjälper inte denna versionen av DLSS....eller? Problemet med blackbox design är att man inte kan kolla upp vad som sker enkelt, men om någon kör spelet och kör en frame capture med nvidia inspector (om jag inte minns fel) med DLSS på kan man avgöra om det är för typ baserat på occupancy. Vem vet, kanske denna version körs asynkront?

Jag är inte helt säker på om de kommer att ha samma förhållande mellan CUDA-, RT- och tensor kärnorna. Om DLSS gör så att de kan köra i en lägre upplösning (vilket minskar trycket på CUDA-kärnorna) så kan de lägga mer area på t.ex tensor kärnorna. För det kan minska både tiden för denoising och uppskalning. Helt plötsligt har de en attraktivare produkt för ML och RT. Men risken finns att om de specialiserar sig för mycket så förlorar de någon marknad, medan dominerar andra. Och om de gör en för bred arkitektur finns risk att Intel och AMD kommer ikapp med specialisering. Men NVIDIA hanterar förmodligen det säkert bra.

Jag tror däremot att de kommer ha samma förhållande för att ha någonting för träningen... än så länge. I framtiden så kommer förmodligen en större del att tillägnas RT delen.

Enligt en reddit tråd på nvidias subreddit räknade dom fram 23% baserat på die shots och förändringar i beräkningskluster

Reddit

Skickades från m.sweclockers.com

Permalänk
Medlem
Skrivet av medbor:

Enligt en reddit tråd på nvidias subreddit räknade dom fram 23% baserat på die shots och förändringar i beräkningskluster

Reddit

Utgår man från denna verkar det bli 20% om man även drar av allting. Det verkar även vara det här som de använt genom att exkludera MIO? Utan MIO får jag det till 11,27mm^2 vs 9,29mm^2 (i andra källan så var det 10,89mm^2 vs 8,94mm^2, så väldigt snarlikt).

Men bara för att en SM är 20% större så betyder det inte att hela kretsen blir 20% större. Jag blir t.ex inte 20% längre om jag har 20% längre ben, även om det är det som bidrar mest till min längd. Det kan nog ligga någonstans mellan 10-16% totalt, men jag vet helt enkelt inte.

Permalänk
Datavetare
Skrivet av medbor:

Jag baserar mig på vaga minnen av nånting jag såg i närheten av release, har tyvärr knappast någon länk tyvärr. Troligen adoredtv eller liknande.

Min bild av RT är att det är en helt annan form av beräkningar än en vanlig gpu och kan därför dela väldigt lite resurser med resterande gpu. Förenklat kan man säga att en vanlig gpu last kör samma program på varierad data (rotera alla punkter via en fast matris, men alla punkter kan vara olika) medan rt är helt annorlunda. Vanliga operationer i rt är att beräkna studsar av strålar och hitta objekt i närheten av dom, dessa operationer är extremt svåra att köra på en gpu eftersom varje stråle studsar (troligen) i en egen vinkel på en annan yta än alla andra, dessutom sprider sig alla strålar åt olika håll vilket gör att de är nära och interagerar med helt olika objekt. Enklaste sättet är att se rt som singeltrådat, därför räknade jag med att det var separat kisel som behövdes...

Något liknande denna bild:
https://i.imgur.com/QUHzV0e.jpg

Skickades från m.sweclockers.com

Enklaste sättet för att förstå exakt vad RT-kärnorna är nog att läsa på lite om hur DXR fungerar.

RT-kärnorna gör exakt en enda sak: lurar ut vilket rätblock en stråle först passerar genom, om något rätblock träffas kollar RT-kärnorna vilken triangel inom rätblocket strålen först går igenom. Detta görs genom att gå igenom den struktur som kallas "acceleration structure"

Exakt hur strålen ska påverka utseendet på triangel, de gröna boxarna, körs däremot på de "vanliga" CUDA-kärnorna. Så RT-kärnorna är väldigt tight integrerade med CUDA-kärnorna sett till cache och liknande.

Skrivet av medbor:

Enligt en reddit tråd på nvidias subreddit räknade dom fram 23% baserat på die shots och förändringar i beräkningskluster

Reddit

Skickades från m.sweclockers.com

Väldigt svårt att få den beräkningen att gå ihop med att TU-116 (1660 kretsarna) har upp till 1536 CUDA-kärnor på 284 mm² medan TU-106 (2060, 2060S och 2070) har 2304 CUDA-kärnor på 445 mm², men det inkluderar också RT-kärnor och tensor-kärnor.

Nu är inte skalningen helt symmetrisk, är ju 50 % fler CUDA-kärnor men bara 33 % fler ROPs i TU-106. Ändå, yta per CUDA-kärna är endast 4-5 % mer i TU-106.

Skrivet av Radolov:

*Visserligen kan de utföra FP16 samtidigt, men det hjälper inte denna versionen av DLSS....eller? Problemet med blackbox design är att man inte kan kolla upp vad som sker enkelt, men om någon kör spelet och kör en frame capture med nvidia inspector (om jag inte minns fel) med DLSS på kan man avgöra om det är för typ baserat på occupancy. Vem vet, kanske denna version körs asynkront?

Tensor-kärnorna är inte FP16, de är en mix av FP16 och FP32 och resultatet blir allt en FP32.

Enligt Nvidia använder DLSS tensor-kärnorna

"We built DLSS to leverage the Turing architecture’s Tensor Cores and to provide the largest benefit when GPU load is high. "

Skrivet av Radolov:

Jag är inte helt säker på om de kommer att ha samma förhållande mellan CUDA-, RT- och tensor kärnorna. Om DLSS gör så att de kan köra i en lägre upplösning (vilket minskar trycket på CUDA-kärnorna) så kan de lägga mer area på t.ex tensor kärnorna. För det kan minska både tiden för denoising och uppskalning. Helt plötsligt har de en attraktivare produkt för ML och RT. Men risken finns att om de specialiserar sig för mycket så förlorar de någon marknad, medan dominerar andra. Och om de gör en för bred arkitektur finns risk att Intel och AMD kommer ikapp med specialisering. Men NVIDIA hanterar förmodligen det säkert bra.

Håller helt med, inte alls säkert att Nvidia behåller nuvarande förhållande mellan de olika delarna. Nästan osannolikt att de skulle fått till den perfekta mixen på första försöket, sedan kommer nog optimal mix förändras beroende på hur spel i praktiken kommer utnyttja tekniken.

Visa signatur

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

Permalänk
Medlem

Blir fint i framtiden när raytracing blir standard i spel om några år

Att konsolerna ska få någon typ av stöd för det tyder ju på att det nog kan gå rätt snabbt ändå. PC ensamt kommer ju liksom inte få igång det hela utan det krävs hjälp från konsolvärlden.

Sen kanske konsolerna inte erbjuder superb prestanda till en början. Men folk är ju vana vid 30FPS inom de kretsarna så ribban är ju satt lägre. Tror dessutom att under nästa generations livstid kommer uppgraderade konsoler likt Pro/X och där blir nog Raytracing fokus utöver allmänt ökad prestanda.

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
Medlem
Skrivet av EntropyQ3:

Ljussättning av scener är svårt. Det finns inget som säger att resultatet blir vare sig funktionellt bättre, eller vackrare för att du gör det med en metod som i princip är mer fysikaliskt korrekt.
Som vi ser i testet här betalar vi ett högt pris prestandamässigt för att byta metod för delar av ljussättningen, trots hårdvaruaccelerationen. Jag kan omöjligt se att det skulle vara värt det.

Den typ av ljussättning som använts de senaste 25 åren kräver en del av programmeraren om man vill ha ett bra resultat.
Fördelarna är primärt att användningen kostar relativt lite datorkraft (billig hårdvara för användaren) och programmeraren har full kontroll över att göra ljuset funktionellt.
Nackdelarna är att programmeringen tar tid och full realism är svårt/omöjligt att uppnå.

Realtids RT i dagsläget:
Är ett komplement till den vanliga ljussättningen.
Fördelen är att man (ur programmeringsperspektiv) enkelt kan öka realismen, särskilt gällande reflekterat ljus.
Nackdelarna är att hårdvaran belastas mycket mer och att det totala programmeringsarbetet blir mer omfattande, eftersom RT bara är ett tillägg.

Realtids RT i framtiden (spekulation på 10-20 års sikt):
Givet att hårdvara utvecklas till den grad att en normal iGPU kan köra 100% RT i lägre upplösning slopas kravet på den klassiska typen av ljussättning.
Fördelen är att om man bara använder RT blir programmering av ljussättning mycket enklare, men ställer lite högre krav för att få ljuset funktionellt. (Gäller att använda lämpliga ljuskällor på rätt plats.)
Nackdelen är förstås ett (ur dagens perspektiv) enormt krav på hårdvaran.

Permalänk
Medlem

@Olle P: Med raytracing så blir ju saker som transparens och reflektioner mer naturligt att få till än jämfört med raster.

Det kan vara sjukt mycket jobb med att få till det riktigt bra i dagsläget.

Jag ser fram emot när raytracing blir vanligare och billigare hårdvara klarar av att driva det just för att det kan inte bara se snyggt ut men även just vara lättare att jobba med vilket ger mer tid och resurser till andra bitar av spelet. 2-3 generationer av grafikkort och det kan nog närma sig standard.

Permalänk
Medlem
Skrivet av NorthLight:

Presis, vad ska AMD fanboysen kontra med nu. När DLSS dessutom gör bilden bättre. Helt insane detta och jag är så förbannat glad att nVidia drog igång RT tåget. Heliga gralen som vi vet

Bättre? Att skala upp en bild ocj gissa vad som skall vara mellan pixlar kommer alltid vara en suboptimal lösning som kan resultera i olika artefakter. Något som kommer av att man gissar, estimerar. DLSS gör dock vad den skall. Men det känns inte direkt magiskt. Renderar man i en lägre upplösning och skalar upp den så bör prestandan öka.

Om en, två generationer tror jag ray tracing kan börja bli intressant. Precis som i början av 3D-eran så är tekniken väldigt begränsad och i framtiden kommer man säkert lägga tio gånger mer prestanda på ray tracing utan att blinka.

Men som en liten förhandstitt på vad som kan tänkas komma har DXR än så länge funkat.

Visa signatur

Huvudriggen är en Gigabyte Aorus Xtreme | 128gb DDR5 6000 | Ryzen 7950X | 3080Ti
Utöver det är det för många datorer, boxar och servar för att lista :P

Permalänk
Medlem

Hade varit kul med ett pascal-kort att jämföra med också!

Permalänk
Hedersmedlem
Skrivet av Squallie:

Hade varit kul med ett pascal-kort att jämföra med också!

Funkar raytracing i den här titeln med Pascalkorten?

Visa signatur

🎮 → Node 304 • Ryzen 5 2600 + Nh-D14 • Gainward RTX 2070 • 32GB DDR4 • MSI B450I Gaming Plus AC
🖥️ → Acer Nitro XV273K Pbmiipphzx • 🥽 → VR: Samsung HMD Odyssey+
🎧 → Steelseries arctic 7 2019
🖱️ → Logitech g603 | ⌨️ → Logitech MX Keys
💻 → Lenovo Yoga slim 7 pro 14" Oled

Permalänk
Medlem
Skrivet av Söderbäck:

Funkar raytracing i den här titeln med Pascalkorten?

Jag trodde att allt funkar på pascal sen det lades in i drivrutinen?

Permalänk
Medlem
Skrivet av Yoshman:

Tensor-kärnorna är inte FP16, de är en mix av FP16 och FP32 och resultatet blir allt en FP32.

Resultatet är FP16 eller FP32. Inget hindrar en från att göra FP16 beräkningar på den. Faktum är att den gör så att de kan ha just 2x FP16.

Something that escaped my attention with the original TU102 GPU and the RTX 2080 Ti was that for Turing, NVIDIA changed how standard FP16 operations were handled. Rather than processing it through their FP32 CUDA cores, as was the case for GP100 Pascal and GV100 Volta, NVIDIA instead started routing FP16 operations through their tensor cores.
The tensor cores are of course FP16 specialists, and while sending standard (non-tensor) FP16 operations through them is major overkill, it’s certainly a valid route to take with the architecture. In the case of the Turing architecture, this route offers a very specific perk: it means that NVIDIA can dual-issue FP16 operations with either FP32 operations or INT32 operations, essentially giving the warp scheduler a third option for keeping the SM partition busy. Note that this doesn’t really do anything extra for FP16 performance – it’s still 2x FP32 performance – but it gives NVIDIA some additional flexibility.

Skrivet av Yoshman:

Enligt Nvidia använder DLSS tensor-kärnorna

"We built DLSS to leverage the Turing architecture’s Tensor Cores and to provide the largest benefit when GPU load is high. "

Sanning med en viss modifikation. Givet att vi vet att 2x FP16 sker på tensor cores, har vi således att alla versioner av DLSS körs på tensor cores. I control använder de en approximativ algoritm som använder sig av FP16 => utilization på tensor cores är låg, det var också fram tills nu den mest framgångsrika implementationen, även om de hade temporala artefakter.

En person visade en frame capture av utilization på olika delar mellan star wars demot och control (men har sedan dess tagit bort tweeten). Star wars hade hög utilization av tensor cores medan Control hade mycket lägre (kanske 25%).

Det är en black box som går att få en viss inblick i med rätt verktyg. Jag har inte dessa verktyg så jag får nöja mig med att gissa. Om NVIDIA hade varit mer öppen med saker hade nog en hel del inte gissat så mycket och även fattat vad de håller på med. ¯\_(ツ)_/¯

Permalänk
Medlem
Skrivet av psilobe:

@Olle P: Med raytracing så blir ju saker som transparens och reflektioner mer naturligt att få till än jämfört med raster.
Det kan vara sjukt mycket jobb med att få till det riktigt bra i dagsläget.

Jag ser fram emot när ... billigare hårdvara klarar av att driva det just för ... lättare att jobba med.

Ungefär som jag skrev, alltså.
Med rasterteknik ligger kostnaden på programmerarna. Med renodlad RT (utan rastrering) frigörs mycket programmeringsresurser.
"RT" i dag kräver i stället både och, eftersom man dels måste ha 100% stöd för rastrering och dels lägga in partiellt stöd för RT.

Permalänk
Medlem

Finns det något sätt att ändra till bredare FOV? Alldeles för smalt på en 16:9 skärm.

Permalänk
Medlem
Skrivet av EliteSweden:

Finns det något sätt att ändra till bredare FOV? Alldeles för smalt på en 16:9 skärm.

Beror helt på spelet tyvärr, q3 och minecraft brukade jag köra på över 100 grader, men som sagt varje spel måste ha en inställning

Skickades från m.sweclockers.com

Permalänk
Relik 📜
Skrivet av EliteSweden:

Finns det något sätt att ändra till bredare FOV? Alldeles för smalt på en 16:9 skärm.

Det ska gå att hacka FOV i configs, tydligen.
https://steamcommunity.com/app/428660/discussions/0/317552647...

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:

Yes, testade det för ett tag sedan men återgå till default titt som tätt.
Får väl hoppas dom löser det med en riktig patch framöver.

Permalänk
Relik 📜
Skrivet av EliteSweden:

Yes, testade det för ett tag sedan men återgå till default titt som tätt.
Får väl hoppas dom löser det med en riktig patch framöver.

Skulle väl inte hålla andan kanske, om de inte fixat under all tid med "återlansering".

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