Crytek förklarar ray tracing-demo – 1080p i 30 fps på Radeon RX Vega 56

När man jämför med de tidiga "icke optimerade" RTX värdena får man anse 1080 30fps inte är så illa med tanke på att RTX kort klarade knappt 30 fps i tidiga nivåer.
https://www.sweclockers.com/test/26605-ray-tracing-i-battlefi...

Optimering är nyckeln här.
RTX har ju helt klart optimerats mer, och det låter lovande att denna teknik kan det med. Att utnyttja allt kraft man annars lämnar orörd är ju kanon. Tittar man på RTX korten lämnar de ofta mycket av vanliga kärnan orörd också när RT blir flaskhalsen. Om även denna kan dynamiskt balanseras får man ju mycket bättre övergång där också.

Ray Traceing är inget negativt. Men att låsa den till bara ett chip, och en speciell typ, är.

En öppen API lösning, som kan använda korten dynamiskt låter helt klart bättre.

Crysis 4 och RT, vore ballt.

Mja, är rätt missvisande att jämföra ett väldigt begränsat teknikdemo med förinspelad slinga jämfört med ett fullskaligt öppet spel med AI, fysik etc.

@Paddanx: Tror du förenklar problemet lite här, att ha en speciel del av kortet som uteslutande jobbar med rtx är nog ett måste ett tag till innan beräkningskraften är tillräcklig. Och innan högafflarna börjar vina över mitt huvud med kommentarer om att de visst går osv så har ni min fulla vällsingnelse å tro något annat. Men innan vi når ok fps med dedikerad hårdvara så kan man nog inte vänta sig under utan de, 30 fps är inte ok och de är inte 60 heller in min bubbla i alla fall.

Självklart är det alltid bättre om det är tekniskt möjlig att öka den generella prestandan i stället för att accelerera specifika funktioner ur ett rent filosofiskt perspektiv. Ändå väljer man rätt ofta att dedicera kisel till vissa väldigt specifika funktioner, varför då?

De här två meningarna borde belysa det hela rätt väl

"At the moment on GTX 1080, we usually compute reflections and refractions at half-screen resolution. RTX will probably allow full-screen 4k resolution."

Man får utgå från att det är RTX 2080Ti som refereras här. Kretsen i RTX 2080Ti har ~2,5 gånger så många transistorer som kretsen i GTX 1080.

Att lösa specifika saker i kisel brukar få ungefär en tiopotens bättre prestanda per transistor jämfört med att lösa samma problem med programvara körandes i på generella beräkningsenheter. RT-kärnorna verkar inte på något sätt vara ett undantag. 2,5 gånger så många transistorer ger även i detta fall ~16 gånger högre prestanda för just ray-tracing (från full-HD med ray-tracing i halv upplösning till 4k mer ray-tracing i full upplösning).

Sedan får man inte glömma att RTX 2080Ti är 50-75 % snabbare (lite beroende på vad flaskhalsen är) även i fall som helt saknar ray-tracing.

I slutändan handlar det om få till den optimala mixen av kisel med fasta funktioner och generellt kisel. Moderna smarta mobiler är ett exempel på enheter som enbart är möjligt då de har kisel dedicerat för alla de vanligt förekommande beräkningstunga funktionerna. En tiopotens högre prestanda mer transistor betyder ungefär en tiopotens högre prestanda/W mot en generell lösning!

Sedan är Crytek sätt att närma sig detta problem ett bra exempel på hur saker bör gå till. I både BFV och Shadow of the Tomb Raider verkar man gått från andra hållet, slå på ray-tracing på i princip allt för att sedan lura ut vad man kan ta bort utan att det påverkar slutresultatet speciellt mycket.

Crytek kolla i stället var man måste använda ray-tracing, men kör rastrering som standardval. Nämns ju i bloginlägget att det fanns flertalet artefakter i demo då man varit lite för aggressiv i sin optimering. Vad Crytek gör är rätt mycket hur man verkar närma sig problem i Unreal Engine 4, ray-tracing introducerades där väldigt nyligen

Det UE 4.22 gör så rätt är att man jobbat stenhårt på att göra ray-tracing till något som enkelt kan slås av/på ända ner på enskilda objekt. Blir då enklast möjliga för spelutvecklare att enbart använda tekniken där den verkligen ger en synbar påverkan!

Håller 100 % med om det du skriver här. Enda jag undrar är, detta är väl ändå bara att slå in öppna dörrar? För så vitt jag känner till finns det exakt noll APIer tänkt för ray-tracing i spel där man låst något till speciella HW. Vilket även medför att det noll av de spel som släppts med ray-tracing senaste tiden är låst till speciellt HW.

DXR samt Vulkan RT är specifikt designade så de i teorin skulle kunna implementeras på precis alla GPUer som är kapabla till att köra DX12. Att t.ex. BFV och Metro Exodus fram till för ett par veckor sedan bara fungerade på RTX korten var till 100 % en konsekvens av bristande stöd i drivrutiner hos Nvidias icke RTX GPUer samt AMDs GPUer.

Trevliga är att detta verkar vara en trend, DirectML är definierat än mer abstrakt just för att man ska ha rejäl frihet i hur saker implementeras, dedicerat kisel, generellt kisel + programvara och/eller programvara på en vanlig CPU.

Sen är det frågan hur praktisk möjligt det kommer bli att implementera ray-tracing i spel på de GPUer som saknar dedicerat kisel för det. Är precis samma historia som att t.ex. "anisotropic filtering" var något folk behövde ta ställning till för 15 år sedan, men som de flesta nog knappt hört talas om idag för det är en självklarhet att använda då alla GPUer hanterar det lysande.

Är ju uppenbart att man i de första RTX titlarna bara vill få ut något fort, man slog på ray-tracing rakt av och hoppades på det bästa (vilket rent krasst räckte för att kunna visa upp lite reklam/previews i alla fall).

En modern spelmotor är otroligt komplicerad och skulle man väntat till allt hade en optimeringsnivå som är mer normalt hade vi fortfarande väntat på första spelet. Se videon ovan för UE 4.22, mindre än två månader sedan vettig stöd för ray-tracing kommit in en spelmotor (är fortfarande i beta för t.ex. Unity). Nu ska någon bara göra ett spel på UE 4.22 eller senare också...

I UE 4.22, likt som verkar vara fallet även för Cryengine, har har man jobbat väldigt hårt på att spelkonstruktören ska kunna välja exakt vilka delar som använder sig av ray-tracing. I den bästa fall kan detta ge oss speltitlar som faktiskt kan köra ray-tracing (via DXR vilket är vad UE använder) även på icke RTX kort!

För folk såg "Vega56 4k 30FPS ray tracing. Släng er i väggen nvidioter. Ray tracing funkar lika bra utan RT cores LOL".
Men sen så såg de att de enbart körde på 1080p men publicerat en video i 4k.
Helt plötsligt är det inte så intressant längre när det krävs ~4x prestandan för att nå de förväntade värdena. 8x om man tar hänsyn till half resolution.

4k motsvarar 4*1080p. Halv upplösning motsvarar 0,5 resolution scale. Det betyder att antalet pixlar totalt sett har halverats. Så det är inte 16x mer prestanda som krävs utan 4/0,5=8 ggr mer. Sedan så vet jag inte vad vitsen är att utgå från en spekulation från deras sida.

Turing är ca 2ggr snabbare sett till samma prestandaklass utan RT cores i DXR.

För voxels är det lite svårare att utgå från. Det finns ett paper från NVIDIA som handlar om just det där de jämför GTX 1080 och Titan V för flera olika metoder. För de nyare metoderna verkar upp till 4x snabbare gälla (utan RT cores), beror förstås lite på vad man kollar på. Men man kan aldrig veta förrän man testat. I BF V var 2080ti ungefär 40% snabbare än Titan V med DXR vad jag minns. Säger dock inte allting om RT prestanda då skillnaden är mycket högre än FPS skillnaden för hela framen. Det är dock utgångsvärden som visar att RT acceleratorer är mycket, mycket viktigt.

Angående artefakterna så har de fortfarande inte kommenterat artefakterna när speglarna rör på sig, samt att en reflektion verkar ha gått igenom en vägg. Och då man måste göra om vissa små föremål till dynamiska föremål så får man ändå ge DXR föredelen att "everything just works". Det verkar även vara ett av de stora problemen som de som implementerat DXR stött på, att omstrukturering tar lång tid med många dynamiska föremål. Svårt att avgöra hur det just skalar i det fallet som de visade med 1(!!!) rörligt föremål.

Med DXR så känns det som ett intressant projekt, men i realiteten så kommer de specialanpassade lösningarna i DXR och DirectML förmodligen att vara bättre helt enkelt (Vulkan RT har definitionen VK_NV_ray_tracing sedan 1.1 , vilket betyder att det bara Nvidias hårdvara som kan använda det... För att ta ett exempel, VK_AMD_gpu_shader_int16 används enbart av AMD, men har tagits bort i förmån för VK_KHR_shader_float16_int8 som fungerar för alla . Kan dock befodras till VK_KHR om AMD och Intel också vill vara med) . Har dock inget emot om de skulle möjliggöra access till specifika hårdvaruenheter att experimentera med andra metoder.

Jag ser ingen framtid utan att grafikkort använder RT acceleratorer i hårdvara. Med RT i PS5 och nästa xbox kommer det gå snabbt och det skulle inte förvåna mig att om ~3-5 år så kommer de korten utan acceleratorer att i stort sett glömmas bort.

Nu kan inte jag säga hur fallet är i Cryengine då jag inte har något av de spelen. Så det du skriver kan mycket väl stämma, men är i så fall en väldigt udda definition av "resolution scale".

Om en karta är skala 1:2 (50 %) är det ju längden inte arean som är halv på kartan.

Unreal Engine kör med den vettiga definitionen, d.v.s. 1920x1080 med 50 % resolution scale renderar världen i den förväntande upplösningen 960x540

Gjorde ett snabbskott i COD:Black ops 4. FPS droppar nästan en faktor fyra om man går från 100 % resolution scale till 200 %, vilket rätt mycket pekar på att man har samma definition av "resolution scale" som UE och världen i stort.

Cryengine kan som sagt köra en annan definition, men den uppskattade prestandaskillnaden mellan ett GTX1080 och vad som borde vara ett RTX-2080Ti låter rätt mycket som man kör med samma definition som de andra. Men skulle kunna vara ett RTX2060/2070 man menade, då stämmer skalning med antal renderade pixlar rätt OK (men varför skulle man jämföra med de korten när man pratar 4k?).

Fast där mäter man inte hur mycket det skiljer i ray-trace prestanda. Flaskhalsen kommer vara en blandning mellan det man gör för ray-tracing och rastrering. Grafen du länkar till är ju för något som både utför ray-tracing och rastering.

Så vinsten med RT-kärnor i fallet att man använder så mycket ray-tracing att det är primärflaskhals, vilket vad det jag avsåg, går inte att utläsa från de graferna. Enda man kan säga är att det är minst så mycket som visas där då det är samma flaskhals vid ren rastrering.

Tidiga versioner av Otoy Octane renderer visade på x2,5 till x5 boost (varierar beroende på exakt vad som är största flaskhals i sccenen) från RT-kärnorna. D.v.s. man jämför samma RTX-kort när den använder respektive inte använder RT-kärnorna.

I så fall har inte Khronos kommer längre än vad de kommit i höstas med detta arbete. Men man lär landa på rätt mycket vad VK_NV_ray_tracing är då det är väldigt nära identiskt med hur DXR fungerar.

Oavsett ändrar det inte hur många spel som använder ett icke-standard API för ray-tracing, för så här långt är det noll spel som använder något annat än DXR.

Är nog tyvärr rätt sannolikt att ray-tracing i spel utan dedicerat kisel inte kommer vara värt det. Är nog snarare att man får ställa frågan hur pass mycket nytta man kommer få av RT-kärnorna i dagens RTX-kort (i spel, renderar man på sin dator är RT-kärnorna redan ett rejält fall framåt).

Det som ändå talar för att RTX-korten kommer få lite vettig användning av RT-kärnorna innan de blir obsolete är just hur UE, Unity och möjligen även Cryengine introducerar tekniken (vilket skiljer sig rätt mycket från hur man stoppade in ray-tracing som quick-patches i spel som var på väg ut på marknaden i samband med RTX-lanseringen)!

Ja det hade varit najs med ett instickskort för Raytracing, med olika antal RT kärnor beroende på prislapp.

Det var ju pga att Nvidia köpte upp dem.