DaniëlWW2 schreef op donderdag 13 april 2017 @ 11:25:
Tomb Raider loopt ook wel te veel uit de pas om te negeren denk ik.
Bij de 1080 valt Ryzen weg qua prestaties, terwijl het een paar procent zou moeten zijn. Ik vermoed toch dat het iets dieper zit dan enkele games, maar daar kom je niet zo makkelijk achter, tenzij je een hele stapel aan hardware hebt liggen.
In het geval van RotTR kijk ik eerder naar het spel zelf. Daar schort van alles aan, dat spel heeft vanaf dag 1 problemen met allerlei hardware. Ik beschouw die game dan ook niet als een betrouwbare benchmark voor zowel GPU's als CPU's, ongeacht welke API het op draait.
Wat ik mij eigenlijk afvraag is of de Nvidia scheduler in staat is om bijvoorbeeld 6 cores te voorzien van instructies bij een DX12 titel? Bij AMD gaat dat zoals je zelf al zegt bijna automatisch en dat levert resultaten op. Dit is alleen ook een beetje offtopic.

Mwah, het is nog wel deels on-topic, vooral met de huidige stand van zaken met 3D API's
Maar nee, dat is niet helemaal hoe het werkt. Aan de ene kant heb je de game/engine zelf die gewoon multithreaded kan zijn. Een thread voor de AI, geluid, game logic, rendering enzovoort. Dat laatste kan echter ook nog multithreaded door verschillende technieken in de API's. Ik zal er niet te diep op in gaan, als je meer wil weten zijn "command list" en "command queue" handige termen
Door rendering ook nog eens te multithreaded kun je meerdere CPU cores gebruiken om de GPU aan te sturen, terwijl dit anders door een enkele core gebeurt. En dat is precies wat Nvidia's driver tot op zekere hoogte probeert voor DX9/DX11ST games. Ze nemen de instructies en proberen die zo veel mogelijk in meerdere command lists te splitsen. Zouden ze dan aan 6 threads kunnen komen? Ja, maar omdat het een best-effort verhaal is waar ze voorzichtig moeten zijn en niet te veel cycles kunnen verspillen omdat het anders performance gaat kosten zal dat in veel gevallen niet zo ver komen.
DX12/Vulkan is dan weer een heel ander verhaal, dat eigenlijk precies andersom zit. Daar móet je als dev bijna wel meerdere queues gebruiken en zit je dus inherent op meerdere threads. Voor RTG is het lekker makkelijk, die hebben 64 queues in hardware tot hun beschikking, dus die kunnen eigenlijk alle threads die ze tot hun beschikking hebben gebruiken om die queues naar de GPU te sturen en de GPU dan lekker zelf de queues op de CU's in laten delen. Bij Nvidia is het ingewikkelder, die hebben dat niet in de hardware. Ze kunnen wel de GPC's, TPC's en SM's partitioneren, maar dat is niet zo vrij als het in GCN is. Belangrijker is nog dat ze die indeling moeten maken vóór het naar de GPU gestuurd wordt en dat is dus wat de driver nog moet doen. Het lijkt erg op wat ze doen voor DX9/DX11ST, maar dat splitsen van taken hoeven ze niet meer te doen. Eerder het tegenover gestelde, ze zullen soms queues samen moeten voegen om te zorgen dat een partitie niet onnodig stil komt te liggen. Bij Nvidia heb je dus kans dat een game minder schaalt met meer cores - hoeft niet en zal ook niet veel voor komen (als het dat al doet), maar de kans bestaat wel. Sowieso is een hogere kloksnelheid voor hen nog steeds belangrijk omdat die scheduler dan sneller klaar is. Voor RTG is dat iets minder van belang, hogere kloksnelheid betekent vooral dat instructies net iets rapper naar de GPU gestuurd kunnen worden, verdere voordelen hebben ze niet echt
Verhaal is nog iets langer geworden dan ik wilde, ik moet echt eens ergens links gaan bewaren over dit soort onderwerpen
En voordat er iemand klaag dat ik het te simpel stel: yep. Dit is echter meer een software verhaal dat specifiek over rendering gaat. Dit is geen dev forum en deze thread gaat over AMD's hardware en nieuws daarover 
Een zwaar getesseleerde zee onder een gamemap aanbrengen ofzo?

Nee, dat is weer een ander verhaal; dat overigens ook bij de waardeloze dev studio lag
Nee, ik heb het dan over engine-specifieke optimalisaties. Elke engine doet dingen op z'n eigen manier en vaak is dat niet 100% geoptimaliseerd voor elke architectuur. Wat de drivers in die gevallen doen is bepaalde instructies dan deels "herschrijven". Zo kunnen ze met geometry shaders soms dingen sneller dan met de gewone SP's. Dan schrappen ze een hoop instructies en vervangen ze door een sneller pad. Dat zou eigenlijk bij de devs moeten liggen, maar dit is inmiddels zo ingebakken in de cultuur dat het nog wel even duurt voordat we er echt van af zijn. Je ziet wel dat er steeds meer devs zijn die hier wel echt veel aandacht aan besteden. DICE doet dit bijvoorbeeld al jaren, het is alleen jammer dat de devs die hun engine gebruiken dan weer minder zijn. Ook UE3.5 en UE4 is niets mis mee als ze goed gebruiken worden, maar veel devs kijken niet veel verder dan hun neus lang is omdat de engine al zo veel out-of-the-box doet.
Dat staat dan weer los van IQ optimalisaties die ze doorvoeren. Soms gaat dat mis waardoor ze een paar procent performance winnen met verlies van IQ (Nvidia's mipmap bias in Trackmania, AMD's AF in Crysis), maar over het algemeen merken wij daar niets van. Dat wil niet zeggen dat ze dat altijd doen, AMD is bijvoorbeeld vrij conservatief met het beperken van tessellation samples. Ze kunnen dat probleemloos doen, maar ze laten dit in de meeste gevallen over aan de developer (CDPR heeft bijvoorbeeld het aantal samples verlaagd met Hairworks) of aan de gebruiker (kun je in CCC gewoon een limiet aan stellen; of dat tegenwoordig in Crimson nog kan weet ik niet aangezien ik al jaren op Nvidia zit, maar ik neem aan van wel). Veel van dit soort dingen kun je ook zelf forceren via de driver CP's of via dingen als Nvidia Inspector.
En weer los daarvan heb je de SLI/CFX profielen. Ook dat is weer vooral gericht op hoe engines werken en draait vooral om hoe de workload gesplitst wordt. Ook dat kun je via dingen als Inspector zelf regelen in veel gevallen, door games op het profiel van een andere game te laten draaien.