Jeroenneman schreef op vrijdag 22 juli 2016 @ 19:01:
AC voegt niks toe qua beeldkwaliteit, en is puur bedoeld om een minder groot deel van de GPU idle te laten zijn. Maar wat heeft Nvidia daaraan? Nvidia's GPU's draaien al nauwelijks idle, omdat alle compute eruit gesloopt is, omdat het voor gamen weinig toevoegt.
Uh, nee. Jij focust veel te veel op het woord "compute" - AC slaat niet per se op GPGPU.
AC is niet bedoeld om GPU's beter te benutten. AC is bedoeld om taken die náást je render taken lopen ook daadwerkelijk naast je render taken kúnnen lopen. Je kunt een GPU best "100%" benutten met alleen render werk, doen genoeg engines. Dat die "100%" niet echt 100% is, is weer een ander verhaal (het is vrijwel onmogelijk om met render werk daadwerkelijke elke ALU aan het werk te krijgen en houden; laat staan de TMU's, ROP's). Met AC blijft dat gewoon "100%", echter kun jij bijvoorbeeld textures laden in een aparte queue terwijl je hoofd queue gewoon volgestouwd blijft worden met render werk. Memory copies vallen ook onder AC. In beide gevallen geen GPGPU. En het kan inderdaad wel zo zijn dat een GPU beter benut wordt, maar dat hoeft niet. En dat is ook niet waarom AMD zo'n winsten krijgt met bijvoorbeeld Vulkan, dat komt vooral doordat hun driver overhead daar niet aanwezig is.
Het probleem bij Nvidia is dat zij die queues niet asynchroon kunnen verwerken. Daarom winnen ze er niets bij. Met Pascal leggen ze A heel even stil om B te doen, waardoor het half asynchroon wordt maar je wel een beetje tijd verliest. Met dat beetje AC van Time Spy maakt dat dus niet uit. Maar je kunt zelf ook wel uitvogelen dat als jij dit met 16 queues ofzo doet dat al die context switches pijn gaan doen.
Hun overhead was belabberd. Door de lagere overhead winnen ze het grootste deel. AC is hooguit verantwoordelijk voor 5-10% van de winst, want zo veel doet DOOM niet.
Nee, het heeft niet met het aantal FLOPS te maken. Het heeft er mee te maken dat AMD meer kleine clusters heeft, die afzonderlijk van elkaar ingezet kunnen worden.
Nogmaals, het is niet zo dat met AC 1 CU ineens tegelijk graphics en compute doet. Een CU is nog steeds altijd slechts met 1 van de 2 bezig. Echter, als jij als developer 10 queues gebruikt, kán dat op AMD in theorie. Komt dat veel voor? In sommige genres wel, ja. Een RTS heeft veel kleine render taken waar vaak ook wat compute spul bij hoort. Een open world game moet vaak meer textures heen en weer gooien. Over het algemeen geen gigantische dingen, maar als je 2ms wint door die minder belangrijke dingen gewoon ergens in een kleine queue naast de rest te laten lopen omdat je niet eerst moet wachten tot de hele GPU zo'n beetje stil komt te liggen, dan is dat toch weer 2ms die je kunt besteden aan misschien een extra pass ergens voor je lighting.
TomasH schreef op vrijdag 22 juli 2016 @ 22:47:
Futuremark probeert natuurlijk net als wij een inschatting te maken van hoe PC-games er de komende jaren technisch uit gaan zien. Het doel van 3DMark is immers om game-workloads te simuleren. Ik denk dat het naïef is om ervan uit te gaan dat de doorsnee game van volgend jaar het volle potentieel van asynchronous compute benut, al is het maar omdat het behoorlijk wat werk kan zijn om dat goed te doen. Daarnaast moet het type game zich ervoor lenen, je hebt niets aan het parallel uitvoeren van berekeningen als je voor berekening B het resultaat van berekening A nodig hebt.
Ik vermoed dat Futuremark met deze denkwijze op een 'gulden middenweg' is uitgekomen, waarbij er beperkte mate van asynchronous compute is toegepast. Natuurlijk zou het ideaal zijn als alle games vanaf nu super-efficiënt geprogrammeerd zijn en zo slim mogelijk met async omgaan, maar ik vrees dat het beeld dat Time Spy neerzet voor de komende tijd nog realistischer is dan het beeld van DirectX 12-showcases als Ashes of the Singularity.
Het lijkt me zeer onwaarschijnlijk dat deze 3DMark met opzet zo is geworden om Nvidia in het voordeel te laten zijn (of minder in het nadeel). Om relevant te blijven moet het immers ver weg blijven van de schijn van afhankelijkheid van één van de betrokken partijen.
Het grootste probleem van Time Spy ligt niet bij hun gebruik van AC. Dat ligt in het feit dat hun hele workload seriëel is. Daarmee doel ik niet op AC, maar op al die fences. Zie ook
Werelds in "CJ's AMD Radeon Info & Nieuwsdiscussietopic - Deel 137"
Het probleem is dat dat niet de DX12 manier is. Dat is DX11 simuleren in DX12. En dat is niet wat de meeste developers gaan doen, want dan winnen ze niets met DX12. Je wint in DX12 JUIST doordat je geen onnodige fences hebt, zoals DX11 er die tussen ramt.
En of het met opzet is? Zijn we Vantage alweer vergeten?
Voordeel van de twijfel natuurlijk, maar het is niet alsof FutureMark altijd...slim te werk is gegaan.
-The_Mask- schreef op vrijdag 22 juli 2016 @ 22:07:
Rond 43:55 wordt echter gezegd dat nVidia met Pascal twee threads tegelijkertijd door de GPU kan laten uitvoeren. Maar dit klopt volgens mij niet, zelfs nVidia heeft dit nooit aangegeven. Die hadden het namelijk over stoppen van de ene thread, snel kunnen wisselen en dan weer verder met de eerste als ik mij goed herinner. Dat is nieuw in Pascal, maar zijn dus niet twee threads tegelijkertijd, één wordt even gestopt en geeft een andere voorrang. Dat is niet parallel maar gewoon serieel.
Precies.
Dit heeft Nvidia heel duidelijk uitgelegd, echter staart iedereen zich blind op die afbeelding van Dynamic Load Balancing waar het vierkantje ineens heel wordt. Lees je dan echter verder, leggen ze duidelijk uit dat de clusters hun state opslaan, context switchen als het nodig is, de andere taken uitvoeren en weer terug naar hun oude context en state gaan. Pre-emption is in dit geval dat men vooruit kijkt in de taken en dus vooraf bepaalt wanneer alles even stil komt te liggen om wat aankomende taken voorrang te geven.
Overigens een frappant detail, AMD kan ook gewoon aan pre-emption doen. Zit ook in GCN

Daarna zeggen ze dat AMD implementatie beter is en daar lijkt mij ook weinig discussie over mogelijk dat is gewoon een feit. AMD kan namelijk met Ellesmere (Polaris 10) zelfs vier threads tegelijkertijd door de pipeline laten lopen. Iets wat dus niet mogelijk is bij nVidia.
4? 4 ACE's, maar elk heeft 8 queues, dus 32 "threads" in feite. Tenzij ik iets gemist heb en de ACE's nu kleiner zijn.