Het is de feature die je "controlled", meer staat er niet. NVAPI is niet enkel controle over/toegang tot (I2C zit er ook in weet ik uit ervaring

) hardware, ook software. Stereoscopic rendering is bijvoorbeeld geen speciale hardware voor, quadro-sync is een geheel aparte AIC. En je hebt ook dingen rondom displays of licenties in NVAPI zitten
Nvidia doet qua scheduling relatief weinig in hardware; hun compiler en driver doen het grootste deel van het werk. Dat is waarom hun "game ready" drivers vaak zo veel meer effect hebben dan die van AMD, Nvidia is veel afhankelijker van hun driver. Dat is met DX12/Vulkan minder, maar nog steeds heel erg aanwezig.
Shader Execution Reordering (SER) is a new scheduling system that reorders shading work on-the-fly for better execution and data locality. Years of research and development have been invested in SER in order to minimize overheads and maximize its effectiveness. The Ada hardware architecture was designed with SER in mind and includes optimizations to the SM and memory system specifically targeted at efficient thread reordering.
SER is fully controlled by the application through a small API, allowing developers to easily apply reordering where their workload benefits most. The API additionally introduces new flexibility around the invocation of ray tracing shaders to the programming model, enabling more streamlined ways to structure renderer implementations while taking advantage of reordering. Furthermore, we are adding new features to the NSight Graphics shader profiler to help developers optimize their applications for SER. Developers can initially use NVIDIA-specific NVAPI extensions to implement SER in their code. [i]We are also working with Microsoft and others to extend the standard graphics APIs with SER.[/i]
Er zijn al meerdere scheduling methodes, deze komt gewoon in die lijst er bij. Ada is verder "ontworpen met SER in gedachten" - met andere woorden, als er een specifiek hardware blok verantwoordelijk voor zou zijn, zouden ze dat echt wel gemeld hebben. Net zoals ze dat doen voor de twee blokjes in de RT core. Het is wel Nvidia waar we het over hebben
Als laatste gaan ze het in DX12 proberen te krijgen, wat ook weer een teken is dat het vooral om het vooraf groeperen van shaders gaat zodat de schedulers, compilers en drivers minder moeite daarvoor hoeven te doen.
Shader divergence is ook niet een Nvidia iets en heeft niet direct met het geheugen te maken maar met het feit dat de cores op de gpu in groepen verdeeld worden en binnen een groep de cores allemaal hetzelfde instructie moeten uitvoeren (maar dan op andere data). Alle GPU's hebben er last van en ray tracing maakt het probleem groter. Men heeft bij ray tracing (niet voor games maar pakketten als vray en mental ray en zo) een tijd geleden ontdekt dat als je een extra stap midden in zet voor ray of material packing en reordering. Dat dit performancewinst kan opleveren. Dit is counter intuïtief aangezien je eigenlijk extra berekeningen aan het doen bent en ook tussentijds data op moet slaan. Je kan hier er meer over lezen:
https://jacco.ompf2.com/2019/07/18/wavefront-path-tracing/
Tot nu toe werd deze stap altijd in software gedaan in een compute shader. Als nvidia er een hardwareuit voor heeft kan ik dat alleen maar toejuichen. Het heeft niet alleen voor games nut maar ook software als vray zou er van profiteren.
Je hoeft me niet uit te leggen dat GPU's met warps/waves werken of dat divergence/branching pijn doet
Dit is ook een onderwerp waar we het onlangs in één van de twee topics over gehad hebben.
In Nvidia's geval zit het probleem dat ze hier op proberen te lossen echter wel grotendeels in hun geheugen systeem. Ze hebben er geen melding van gemaakt, dus Ada kan nog steeds niets rechtstreeks delen tussen SM's zonder L2 (wat Hopper wel kan, tot op zekere hoogte). Wat betekent dat elke partitie (en RT core) nog steeds toegang heeft tot 128 KB aan L1 binnen die SM; maar in de praktijk is dat heel specifiek opgedeeld. De exacte verdeling weet ik niet uit m'n hoofd; iets van 64 KB graphics, 16 KB voor scalars, enzovoort. Het is in elk geval niet de volle 128 KB. De L2 moet dus heel regelmatig aangesproken worden en die zit vrij ver weg. Het lijkt er niet op dat ze dat met Ada verbeterd hebben (nogmaals, daar zouden ze wel expliciet melding van hebben gemaakt, want dat zou een heel ingrijpende verandering zijn en latencies geweldig verminderen). Gevolg is dat Nvidia's SM's veel memory latency stalls hebben en hun bezetting dus vrij ruk is. Zodra je boven die 64-128 KB gaat heb je al bijna even veel latency als je bij AMD hebt als je naar de IC/L3 (!) moet. Dat is hoe ver weg die L2 zit.
Wat SER voor hen dus op lost, is dat shaders beter gegroepeerd worden, wat zal zorgen voor minder stalls. Blijkbaar zijn workgroups daar niet genoeg voor. Met CUDA hebben ze dat probleem niet omdat alles dan al veel beter gegroepeerd zit. Sterker nog, hun aanpak is juist waarom CUDA zo verdomd effectief is.
AMD heeft dat probleem uiteraard ook (in de zin dat je shaders bij elkaar wil laten draaien om zo optimaal gebruik te maken van caches), echter is AMD's geheugen systeem veel robuuster. Hun L1 is 128 KB , volledig toegewijd aan graphics data én gedeeld tussen meerdere WGP's. Binnen WGP's zijn er ook meer manieren om data te delen tussen de 4 SIMD's. Tussen Nvidia en AMD is L1 latency grofweg gelijk, met als groot verschil dus dat dat bij Nvidia per SM (4 partities, 192/"128" ALU's) geldt, terwijl dat voor AMD voor een hele shader array is (8 of 10 WGP's, afhankelijk van de chip; 1024 of 1280 ALU's). En hun L2 zit veel dichterbij.
Het gevolg is dat Nvidia moeite heeft met hun SM's actief te houden - ze lopen tegen te veel stalls aan. Dat is deels waarom ze met zo veel meer ALU's en theoretische performance AMD toch niet geweldig veel voor kunnen blijven (het andere deel zijn die 64 extra FP32 ALU's die maar een deel van de tijd gebruikt kunnen worden). En nu Ada zo veel groter en breder is geworden, wordt dat probleem alleen maar erger. Enkel een grotere L2 lost dat niet op als de latency zo hoog is. Ze verminderen wel de druk op het geheugen, maar veel meer dan dat niet.
Wat overigens de hardware schedulers betreft, ook daar doen de twee het geheel anders. Geheel ander onderwerp, maar de korte versie is dat Nvidia een enkele, heel brede scheduler (los van de warp schedulers in SM's) heeft die gericht is op het efficiënt verdelen van de binnenkomende groepen maar er verder niet veel werk van maakt om die te splitsen, dat is al vooraf gebeurd. AMD daarentegen heeft tegenwoordig 3 schedulers (wederom, los van de wave schedulers in WGP's), elk met hun eigen verantwoordelijkheden en zij splitsen juist veel op hardware niveau. Wat beide in hardware doen, is uitbreidingen binnen de pipeline door-schedulen. Nvidia kan dus veel meer analyse doen in hun driver (en dat doen ze ook), terwijl AMD veel meer leunt op een "one size fits all" aanpak. Nvidia's aanpak zou niet werken met hun architecturen.
Nu ik er over na denk...Nvidia was er rond de tijd van Volta mee bezig om die (de GigaThread Engine) om te gooien naar RISC-V, ik moet eigenlijk eens op zoeken wat daar van gekomen is.