enchion schreef op zaterdag 21 november 2020 @ 16:28:
[...]
Precies wat is er te implementeren met raytracing, het is extreme gewone wiskunde alleen dan maal een miljoen+ keer.
Juist raytracing is ongeveer de oudste rendering logica, schilders net als Rembrandt en Vermeer gebruikten het ook. (beetje anders, maar het geometrische besef/kennis was er)
Je benadert het denk ik helemaal verkeerd.

Ray tracing mag dan oud zijn, maar dat maakt het niet extreem intensief voor juist de GPU's die we nu hebben. Moderne GPU's zijn de afgelopen twintig jaar ontwikkeld met de focus om relatief simpele en kleine instructies om te zetten in enorme databestanden in enkele milliseconden. GPU's zijn hier ook behoorlijk goed in geworden. Waar ze echt niet goed in zijn, is deze enorme hoeveelheden data weer terug naar de rekeneenheden krijgen voor extra berekeningen. Laat dat nu precies zijn wat hybrid rasterisation + RT om vraagt. Het is ook niet zo makkelijk om de GPU maar veel groter te maken om dit probleem op te lossen. Immers horen GPU's al tot de grootste processoren en zit er weinig rek meer in.
Tweede is de tijdsduur van de hybrid rasterisation + RT aanpak. Stel je hebt nu een game die op 100 fps loopt. In een seconde zitten 1000 milliseconden, dus 1000 : 100 = 10 milliseconden is nodig voor een frame. Nu wil je alleen ook RT toevoegen. We hebben inmiddels genoeg gezien dat een beetje RT, je framerate door de helft laat zakken. Nu kijk je dus naar 20 milliseconden en 50 fps. Dat komt omdat er over de berekende instructies, nu nogmaals andere instructies moeten worden uitgevoerd die zeer intensief zijn.
Je zal voor elk object dat mogelijkerwijs in aanraking komt met een ray, een BVH moeten berekenen. Dit dus:
Vervolgens moet je al deze data verzamelen, dan de "rays casten" en die checken vanuit een lichtbron. Meer dan een bounce zal niet gebeuren. dus alleen licht uit een lichtbron dat via een bounce naar de positie waar je het in de spelwereld kan zien, zal berekend worden.
Dat is wat AMD zegt met 4 ray/box intersections of 1 ray/triangle intersection. Ze doen maximaal vier checks per clock cycle tegen een object en als de BVH structuur fijnmazig genoeg is gemaakt, dan gaan ze bepaalde driehoeken checken. Dat gaat met een driehoek per clock cycle. Die kunnen ze nooit allemaal checken, dus doen ze er een aantal en passen ze vervolgens een denoising algoritme toe die aangrenzende driehoeken als het ware invult aan de hand van de informatie van die ene driehoek die wel gecheckt is.
En die data hiervoor zit in L3 cache. Wat ik vermoed dat ze willen bereiken is de data voor BVH checks en ray casting, gelaagd klaarzetten. Het meeste zit in L3 en zo te zien kan L2 elke 4 clock cycles vervangen worden met een nieuwe 4MB. Vanuit L2 zal de data verdeeld worden naar de CU eigen L0 cache of naar de Shader Array L1 cache gaan.
En dat is het probleem. Hoe zorg je ervoor dat het toepassen van RT bovenop de normale instructies, zo weinig mogelijk milliseconden extra kost. Als je namelijk door slim coderen van 20 naar bijvoorbeeld 17 milliseconden kan gaan, dan is dat van 50 fps naar 59 fps. Het echte probleem is alleen een manier vinden om terug te keren naar die 100 fps die je in het voorbeeld had, dus terug naar 10 milliseconden. Daarvoor zal je waarschijnlijk ook een flinke stap in shaders om hier een paar milliseconden te winnen en alsnog moet je maar een manier zien te vinden om die winst niet meteen te zien verdampen met RT. Dit zal dus ook veel, veel sneller moeten worden.
Omdat het winnen van een of twee milliseconden op een frame is al heel veel voor RT, kan je dus nu het gedoe gaan krijgen dat onder DXR, twee standaarden gaan ontstaan. Nvidia met RTX met haar eigen specifieke aanpassingen en verbeteringen en voor AMD dan Radeon Rays. Zowel AMD als Nvidia zullen hun een basale DXR compliant variant van hun implementatie hebben, maar het zal beter draaien op de meer geavanceerde implementaties die meer zaken aanpassen en hierdoor niet meer DXR compliant zijn en niet op elkaars hardware werken.
Daar zit dus de pijn want als de ontwikkelaar weer eens geen tijd heeft omdat de kwartaalcijfers van de uitgever belangrijker zijn, tja dan kan je dus krijgen dat het goed draait op de een en de ander even vergeten zal worden en alleen een generieke implementatie krijgt. Dat of beiden krijgen een generieke implementatie waardoor het slecht draait op alles. En dat is het scenario waar ik bang voor ben. Ik moet er niet aan denken dat je een loterij gaat krijgen bij elke game, welke videokaart je moet hebben.
Dit is ook een van de vele redenen waarom ik de boel rustig wil afwachten en eigenlijk liever wacht tot RDNA3. Ik heb eigenlijk geen zin om de "beta tester" te gaan spelen voor Radeon Rays en te hopen dat er nog games komen die er goed gebruik van zullen maken voordat RDNA3 komt. Ik heb ook gezien hoe dat met Turing ging. Ampere is het ook gewoon niet.
Komt nog eens bij dat ik vermoed dat RDNA haar RT implementatie op termijn wel eens de superieure kan blijken. Niet zozeer dat RDNA2, Ampere wel even van de mat gaat vegen over een paar maanden. Nee, de opzet en de diepe investering in architectuur die RDNA2 laat zien om datatoegang te faciliteren. RDNA2 is vanaf de grond af ontwikkeld voor de consoles en zowel Sony als Microsoft zullen om RT hebben gevraagd. Het zal vanaf het begin van die ontwikkelingscyclus, circa 2014-2015 erin hebben gezeten.
Dit terwijl Ampere nog steeds in heel wat zaken, "Maxwell" is. Ik kan gewoon niet de indruk afschudden dat RT in Turing en Ampere, niet goed geïntegreerd is in de architectuur en er meer bijzit als iets extra's dat veel ruimte inneemt en niet optimaal presteert. Alsof het halverwege de ontwikkeling van Turing is toegevoegd en Nvidia er nu aan vast zit.
Never argue with an idiot. He will drag you down to his own level and beat you with experience.