AMD: "Vi arbetar aktivt med utveckling av ray tracing"

Det säger mer om hur överprisade Nvidias kort är än något annat. Men håller med i sak att det måste vara ”tråkigt” att jobba i kölvattnet och bara anamma tekniker istället för att skapa/leda dom. Nu tänker jag mer på dom som jobbar där än aktieägarna.

Skickades från m.sweclockers.com

"Troligt är att AMD väntar med tekniken till kommande Navi som planeras släppas någon gång under 2019."

Själv tror jag inte alls Navi kommer vara något svar på Nvidias RTX. Betänk att Navis arkitektur gissningsvis togs fram för minst 2-3 år sedan. Tänk också på att Nvidia släppte Turing i samma veva som de första testexemplaren av Navi kom till AMD (september 2018) Det skulle i så fall innebära att man då bestämde sig för att skrota Navi och göra om arkitekturen med hårdvaru-accelererad ray tracing? Känns inte som en ekonomiskt hållbar strategi?

Å andra sidan... kanske är det därför vi inte fick höra ett knyst om Navi på CES?
Istället fick vi rebrands med nyare processteknik (590 i november och nu Radeon7)

Själv tror jag att raytracing är framtiden, men att det kommer ta ett antal generationer innan det blir kommersiellt gångbart för spel-PC:s. Tekniken kräver, hur än man lyckas trixa med smarta algoritmer och hårdvaruaccelerering extremt mycket mer beräkningskraft för att det ska konkurrera med traditionell rastrering vad gäller råprestanda.

Om en teknik är fördelaktig för en marknad. Varför utveckla egna tekniker då? Är väl bättre att båda aktörer går på samma teknik istället för att man får femtioelva olika tekniker varav hälften inte ens är implementerade i mjukvaror för att utvecklare inte haft tid..

Som svar på din fråga kring AMD så är deras överlevnad pga. att de just fokuserat på en marknad som för tillfället varit stark hos dem. Tidigare var det grafikkort och nu på senare tid CPU:er. Orsaken är för att AMD alltid valt den mer kostnadseffektiva vägen att tillgå något. I Ryzen är det frångång från monolitiska CPU:er som varit deras framgång. På GPU sidan var det tidigare mindre GPU:er.

Snarare att Sony garanterat inte kommer klara RT (edit, menar dedikerad RT hårdvara liknande RT cores). Varför ödsla massor kretsyta på det när man istället kan få högre konventionell prestanda eller lägre pris?

Paradnummer har Sony ändå. 4K (Pro var en uttalad fejk-4K konsol) och HFR.

Och fler 60 fps spel.

Tror faktiskt att de kan ha det.

Tensor cores ersättas av en FPGA gjord av Sony (liknande uppskalning som till deras TV apparater). Så att rendera i lägre upplösning för att nå de framerates som behövs är en möjlighet med raytracing.

AMDs planer på "RT cores" är egentligen en expansion/omstrukturering av deras nuvarande GPU. Från en tidigare undersökning (2014) så kunde de spendera 4-8% av ALU arean till att accelerera en 290X på 5.6Tflop FP32 till 3,4 Gigarays i pathtracing. Då skulle t.ex en Radeon VII ha ~8 Gigarays (om de bibehöll samma skalning), vilket är samma storleksordning som RTX2080. RTX2080 har dock 35% av arean dedikerad till Tensor- och RT cores . En långt större siffra.

Frågan som behövs besvaras är nog "Är GPU:n som sitter i PS5 en super-simd GPU?". ¯\_(ツ)_/¯

Ja ser AMDs RT-lösning helt annorlunda ut än nvidias så är det förstås möjligt. Men då behöver den nog vara "nästan gratis".

Skickades från m.sweclockers.com

Håller med om att Sony förmodligen hellre satsar på lågt pris och/eller högre prestanda men skulle däremot förvåna mig om dom använde den prestandan till 60fps istället för högre upplösning/snyggare grafik.

Skickades från m.sweclockers.com

Det är iofs i första hand en fråga för mjukvaru-utvecklarna men den här gången har de med största säkerhet en bättre balans mellan CPU och GPU prestanda att jobba mot; så indirekt ger Sonys hårdvaruteam iaf bättre förutsättningar för 60 fps (eller mer).

Absolut men Sonys "egna" spel är nästan alltid max 30fps.

Skickades från m.sweclockers.com

Jag förväntar mig dock att Nvidia kläcker ur sig att de "uppfann ray tracing"

För att??

Intel har jobbat med ray tracing i olika former VÄLDIGT länge. Konceptet är gammalt och har länge varit ansedd som datorgrafikens heliga gral.

Att konceptet är gammalt är jag väl medveten om med Compleat Angler 1979 tex. Men menar arbeta på att få det vi idag kallar ray tracing i spel att funka. Det är ju egentligen inte ray tracing utan partiell ray tracing på någon enstaka effekt. Men blir det lite konkurrens här så kanske vi kommer igång.

I början skulle jag nog faktiskt gärna se separata kort som skötte detta man kunde kompletera med om man ville istället för att direkt baka in det i GPU:erna och dra upp priserna på något gemene man kanske har svårt att tycka är värt det och sammtidigt påverka den generella prestandan då en del hårdvara måste tillägnas ray tracing.

@Patan77: Thank you Patan77 , very cool!

Bara några kommentarer:

När Intel säger att de renderar från en laptop så är det egentligen gjort på 4 servrar och skickas sedan till laptopen . Bara så att alla andra vet varför videon har så många dislikes.

Om man läser de papers och patent som AMD släppt så känns det rätt så troligt att de kommer göra om b.la. ALU delen lite så att de kan hantera pathtracing i realtid. För mer info läs "Reduced Precision for Hardware Ray Tracing in GPUs" och "Super-simd" verkar vara ett sätt att implementera det. Jag hittade det gamla artikeln för bara någon dag sedan och kunde snabbt se likheterna med det nya. Raytracing på GPU verkar mer vara ett schemaläggningsproblem än något annat. Om någon skulle bygga ett accelereringskort har jag en känsla av att det faktiskt blir Intel som gör det med foveros.

Om din pathtracer
Väldigt coolt, inspirerande och intressant.

Har du något paper på vad du implementerat? Det låter nästan för bra för att vara sant. Såg en grafikingenjör för bara några veckor sedan som sa att det var omöjligt, att köra Gran Turismo med 2308 ljuskällor samtidigt med raytracing i realtid med dagens hårdvara. (Här är presentationen som refererades).

Programmet terminerade, alltså har det inte ett oändligt antal reflektioner. Tror du menar "obegränsat" här . Och för Turings skull, ha en begränsning på hur många gånger det får reflektera. Det existerar inget realtidsprogram som kan hantera det. Tänk dig ett rum som man råkar gå förbi i ett spel, sedan så fryser det i all oändlighet. Om ditt mål var realtid så har det redan brutits p.g.a det villkoret.

Också, all lycka med att göra dina egna representationer. Men det känns dock knepigt med tanke på att grafikhårdvara har utvecklats för att användas på ett specifikt sätt. T.ex så finns det olika topologier som kan användas av grafikpipelinen (trianglar, punkter, linjer osv osv.). Hur omvandlar du din representation till dessa? Eller utgår du enbart från compute pipelinen?

Min nuvarande version av renderings motorn är baserad på unbiased path tracing (UPT) fast är mina egna algoritmer, i det flesta fallen när nån nämner ray tracing i spel pratar dom egentligen oftast specifik om "recursive ray tracing" (det som bl.a nvidia demos visar med RTX) där man skjuter en ljusstråle som sen träffar ett objekt och sen från plasten där strålen träffade skjuter man flera nya olika strålar bl.a en eller flera "shadow rays" till varje ljuskälla i scenen och kollar ifall nått objekt blockerar vägen/strålen mellan ljus källan och platsen där original strålen träffade och om nått blockerar så är det skugga annars är det ljus, med den metoden så ju flera ljuskällor man har i scenen ju flera "shadow rays" måste man räkna ut för vara "main ray" som studsar vilket gör att det eventuellt finns en begränsning på hur många ljuskällor man kan ha ifall man vill kunna köra realtime, men att säga ett en viss specifik mängd ljus källor är omöjligt är lite konstigt eftersom beror mycket på olika variabler tex om man vill ha soft shadows samt vilken kvalitet man har , GI, caustics, glossy material, SSS, etc. I Gran Turismo videon säger han att det är full "path tracing(PT)" a.k.a inte "recursive ray tracing(RRT)", PT är den metod av raytracing som närmst simulerar hur ljus fungerar i verkligheten, där man skjuter en stråle som sen när den träffar ett objekt studsar och nya riktningen är baserat på geometrin samt materialet, sen följer man den strålen när den studsar runt mellan olika objekt i scenen och sen mäter man energi värdet på strålen, man skjuter inga shadow rays som med RRT vilket gör att man inte påverkas av antalet ljuskällor på samma sätt, dock om man kör "biased path tracing (BPT)" så kan man göra så att när stålen studsar "söker" den sig mot ljuskällorna för att ha större sannolikhet att träffa en ljuskälla men i det fallet så påverkas renderings tiden av antalet ljus källor.

Sättet jag har programmerat min renderings motor är att den egentligen inte har några separata ljuskällor utan har bara en "code path" och jag har bara en sorts material fast materialet har olika parametrar(p) en parameter är för "ljus energi" t.ex en 50% grå vägg har reflektion p: 0.5 har ljus energi p: 0.0 medans en lampa kan ha ljus energi p: 1.0 så om en inkommande ljusstråle har energivärdet 0.8 och sen träffar en grå vägg multipliceras energi värdet med reflekterande parametern sen adderar energi värdet (0.8*0.5+0.0 = 0.4) så nu är stålens energi 0.4 om den träffat ett objekt med material som har t.ex reflektion p: 0.5 men ljus energi p: 1.0 så blir det (0.8*0.5+1.0 = 1.4) så från renderings motorns perspektiv är det identiskt att träffa en "ljuskälla" eller vilket annat material som helst, för uträkningen är samma, är bara summan som blir annorlunda och varje triangel i scenen har ett material associerat med sig så effektivt sätt är alla trianglar alltid en ljuskälla bara vissa trianglar har 0 "ljus energi" medans andra har mer, det är därför det spelar inte nån roll hur många ljus källor eller hur komplexa ljus källor jag har. Det som spelar roll med UPT är hur stor total yta alla ljus källor har sammanlagt för det ökar chansen att en stråle träffar en ljuskälla vilket gör att uppfattnings vis renderas bilden snabbar ju flera eller ju större ljus källor man har.

Traditionellt så har en ray tracer ett max antal gånger en stråle får studsa (max depth), låt oss säga att man har max depth satt till 8 så om man skjuter en stråle som sen träffar ett objekt (depth 0) sen låter man den studsa en gång (depth 1) o.s.v tills man når max depth terminerar den path:en i det här fallet efter att ha studsat 8 gånger.

Min renderings motor använder en teknik som kallas "russian roulette termination" en enkel beskrivning av det är: om man skjuter en stråle som sen träffart ett objekt "singlar man slant" om stålen ska få fortsätta studsa, "krona" (sida 0) "klave" (sida 1) så är 50/50% chans om den får fortsätta sen nästa depth/studs gör man samma sak så 50/50 igen om den får fortsätta men sannolikheten att man får två av samma sida i rad är 25% sen tre i rad 12.5% etc men i teorin och matematiskt sätt så kan man få samma sida oändligt många gånger i rad men sannolikheten för det är oändligt liten vilket gör att man behöver oändligt många försök för att det ska inträffa, vilket betyder att med renderings motorn om man låter den rendera oändligt länge så kommer strålarna studsa oändligt många gånger. Skillnaden jämfört med att sätta max depth till "obegränsat" är att i det fallet skulle den aldrig terminera men med den här metoden kan den terminera men fortfarande ha potentialen att studsa oändligt mycket och om man sätter max depth förlorar man en viss energi i bilden medans med russian roulette multiplicerar man energi värdet med sannolikheten att stålen skulle terminera vid det depth:et, så även om med max depth stålen studsar 8 gånger och med russian roulette också studsar 8 gånger får man olika energi värden. Med russian roulette är totala energin i bilden samma som om den får rendera oändligt länge fast ju kortare man renderar ju mer "variance" (noise) är det i bilden vilket inte är sant när man har ett max värde. Så matematiskt sätt är det som att den kan studsa oändligt många gånger.

Sen dessutom effektivt sätt så finns det en max pixel storlek och max color depth, en vanlig display 8 bit (8 bpc) vilket gör efter en viss tid är renderingens "variance:en" mindre än vad skärmen kan visa vilket gör att även om man låter bilden fortsätta rendera oändligt länge så kommer den se identiskt ut, och man kan sätta en "threshold" som terminerar renderingen när den nått den punkten då kommer bilden effektivt se identisk ut som om den har renderat oändligt länge.

Allt det här är baserat på statistik och "monte carlo integration" monte carlo metoden utvecklades under WWII för Manhattan projektet (utvecklingen av första atom bomben) för att räkna ut energin av en atom bombs explosion.

Just nu kommer jag huvudsakligen använda compute (gpgpu, cuda ) men visst dagens grafik kort är optimerat för trianglar och rastrerad grafik men om det visar sig att min volymetrisk representation är betydligt bättre än dagens metod av raytracing så kommer garanterat framtida hårdvara optimeras för att kunna köra det, men som sagt är alldeles för tidigt för att säga hur pass bra det kommer fungera.

Om man är intresserad av rendering och raytracing/path tracing kan jag rekommendera det här resurserna:
Video:
Disney's Practical Guide to Path Tracing
RAY TRACING and other RENDERING METHODS
TU Wien Rendering / Ray Tracing Course
Hemsida:
Pixar in a Box Khan Academy.
https://www.scratchapixel.com
Papper
Pixar The Path to Path-Traced Movies