1. Welkom op het Hardware.Info Forum

    Hier kun je terecht met al je vragen over computerhardware en consumentenelektronica. Wil je zelf een vraag stellen of deelnemen aan discussies, dan moet je je registreren of inloggen met je Google of Facebook account. Veel plezier op het Hardware.Info Forum!

    Notificatie sluiten

CPU Benchmarking m.b.t. Games onderzocht, deel 1.

Discussie in 'CPU's, moederborden en geheugen' gestart door DatAccountz, 22 mei 2018.

  1. DatAccountz

    DatAccountz Senior Member

    Sinds:
    13 nov 2012
    Berichten:
    9.620
    Inhoudsopgave

    BBcode voor jump/anchor lijkt momenteel broken voor forum, inhoudsopgave werkt nog niet.

    Voorwoord
    Deel 1: Introductie
    Deel 1: Graphics Pipeline
    Deel 1: LOD
    Deel 2: Korte uitleg game-engines, waar liggen de problemen bij het testen van processoren?
    Deel 2: “Canned” Benchmarking en resultaten
    Deel 2: Testresultaten ter ondersteuning
    Deel 3: Aanbevelingen testsuites en testmethodologie


    Voorwoord.

    Dit was eigenlijk oorspronkelijk bedoeld als semi-korte post, maar hoe meer je onderzoekt, des te meer je ontdekt en hoe dieper je weer moet zoeken om het volledige verhaal te geven. Het is simpelweg teveel geworden om het in één keer te posten dus ik zal deze thread aanvullen met meer delen. Ik wil hiermee ook niemand specifiek onder de bus gooien bij kritiekpunten, ik heb Hardware.info van tevoren aangegeven dat ik dit ging maken en het was verder allemaal prima.

    Je kunt deze analyze tevens ook goed gebruiken als je game slecht draait en je afvraagt welke knopjes je terug moet draaien op basis van de gegevens die je ziet bij afterburner.

    Introductie

    Zoals jullie weten testen ze hier bij hardware.info, net als andere hardware reviewsites, regelmatig processoren in hun testlab. Een belangrijk onderdeel van deze tests zijn natuurlijk voor velen de gaming benchmarks. Natuurlijk proberen deze websites waar mogelijk meerdere games in meerdere scenario’s te testen, maar zijn ze allemaal evenwaardig. En is de ene test objectief beter dan de andere om te testen? De reden welke voor het testen op hoge resoluties wordt gegeven is vaak dat dit een zgn. ‘real-world scenario’ is, met andere woorden waar de meeste gamers op zullen spelen. Tevens geldt dit ook voor een G4560 testen op een 1080TI. Het andere spectrum beargumenteerd dat zodra GPU’s sneller worden, en historisch gezien verloopt dat sneller dan CPU’s, zal de CPU relatief gezien dezelfde snelle GPU hebben maar dan in het middensegment. Dus het testen op 720p of met een high-end GPU is niet zo vergezocht. Voor beide argumenten valt wat te zeggen. Historisch gezien leunde ik zelf meer naar testen op lage settings, lage resoluties en high-end GPU’s om zoveel mogelijk de GPU uit de vergelijking te halen, en ik ben het nog steeds niet eens met GPU-bottlenecked 1440p/4K CPU benchmarks. Maar ik ben inmiddels wel wat van standpunt veranderd. Dat leg ik in deze post uit.

    Wellicht hebben jullie deze video van Digital Foundry voorbij zien komen.

    Dit is iets waar ik ook al geruime tijd zelf tegenaan loop. Een ware ‘disconnect’ tussen wat ik in de reviewresultaten tegenkom, en mijn eigen ervaringen met mijn inmiddels gedateerde quadcore daadwerkelijk in-game. Ik had al eerder een post geschreven in het Engels hierover:

    https://linustechtips.com/main/topi...nough-bottlenecking-explained-with-an-rx-480/

    Ik vond alleen de video van digitalfoundry niet echt toereikend genoeg, en mijn eigen post niet technisch genoeg om aanbevelingen te doen. Tevens heb ik inmiddels vanwege een aardigheidje van EVGA een GTX 1080 en is dit fenomeen twee maal zo erg geworden. Waarom kunnen testresultaten zo verschillen tussen websites en hoe kun je dit proces verbeteren. Op eigen houtje ging ik dit onderzoeken door te kijken naar de volgende aspecten.
    • Deel 1, Graphics Pipelines en LOD
    • Deel 2, Korte uitleg game-engines, waar liggen de problemen bij het testen van processoren, canned benchmarking en de resultaten wat ik kreeg met verklaring uit frame analyzes.
    • Deel 3, Aanbevelingen testsuites en testmethodologie.
    Even van tevoren wil ik wel graag opmerken dat ik geen game-engine expert ben of game ontwerper, ik heb mijn achtergrond in mechatronica. Dit betreft eigen onderzoek in praatgroepen, forums, en veel pluizen in frame analyzes. Zeker het gedeelte over de game engine, graphics pipeline en threadverdelingen was vrij lastig om binnen korte tijd te begrijpen. Ik heb mijn best gedaan, maar mocht je verbeterpunten hebben laat ze gerust achter.

    Graphics Pipeline

    Zodra je begrijpt hoe het proces verloopt, kun je begrijpen waarom een bepaalde game slecht loopt, welke settings je gaan helpen een betere framerate te krijgen, etc. Dit is zeer complexe stof en ik ga er echt in vogelvlucht overheen, gaandeweg zal ik hier en daar dieper ingaan. Het moeilijke bij het zoeken van deze informatie vanuit het perspectief van een leek is dat de technieken zich steeds meer naar de GPU verplaatsen in de tijd. Dus wat je leest op een 2009 blogpost als CPU taak klopt in 2011 wellicht niet meer.

    Moderne games werken met zogenaamde shaders, vroeger nog opgedeeld in pixel/vertex shaders, maar nu simpelweg unified shaders (of “cores”) in een videokaart omdat deze steeds beter te programmeren zijn. In tegenstelling tot de oudere games worden tegenwoordig veel CPU taken overgenomen, met voorbeelden als geometry shaders. Het stappenplan (simpele versie) is als volgt:
    • De CPU stuurt de instructies (drawcalls) en geometrie (coordinaten van objecten in de wereld) informatie naar de GPU.
    • Binnen de vertex shader wordt de geometrie getransformeerd
    • De berekende geometrie wordt opgedeeld in driehoeken (primitieven).
    • Deze driehoeken worden in buffers geplaatst, bewerkt door verschillende shaders tot een uiteindelijke render van de image (denk aan belichting, tesselation, shadows, normalmaps, etc). Moderne engines maken gebruik van MRT en kunnen dezelfde meshes gebruiken voor verschillende shaders, zodat ze niet voor elke berekening weer een drawcall moeten sturen voor geometrie. Via deferred rendering kunnen ze geometrie ook opdelen in batches.
    • De laatste stap neemt de volledige render (nadat deze is uitgeknipt (clipped) van de image en plaatst deze over een raster welke de individuele pixels moeten voorstellen en bepaald welke punt/lijn/primitief bij welke pixel hoort. Deze wordt daarna weggeschreven in de ‘large pixel matrix’ or "frame buffer" waarna hij door je monitor kan worden gescanned.
    • Eigenlijk zijn heel veel stappen tegenwoordig naar de GPU verplaatst. Enkel de game logic, audio en drawcalls vallen nog onder de CPU. De complexiteit van de geometrie, shadows, lighting passes hebben allemaal invloed in de totale hoeveelheid draw calls voor de CPU.
    rasterization2.png
    Rasterization

    Level of Detail

    De complexiteit van de omgeving, afhankelijk van de positie van de speler in de gamewereld, wordt gedefinieerd door de zogenaamde Level Of Detail (LOD). Maar LOD kan ook toegepast worden om de GPU te ontlasten (pixel shader passes). Het idee erachter is om de kwaliteit van de geometrie, textures en shaders te verlagen om de belasting te verlagen ten kosste van renderkwaliteit. Geometrie kun je vervangen door modellen met minder primitieven (polygonen) (foto's verderop), textures kun je filteren door middel van o.a.technieken als ‘mipmapping’, een techniek waarbij je steeds lagere resolutie textures gebruikt (foto links hieronder) en pixelshaders kun je bijvoorbeeld op 75% of 50% resolutie uitvoeren. Ook kan de developer bepaalde objecten simpelweg verwijderen uit de scene en zo ook besparen op drawcalls en geometrie (culling). Dit noemt men de fulstrum, en het is min of meer de FOV (field of view) van de speler. FOV kan dus ook een invloed hebben op je performance.

    mipmapping.png 800px-DiscreteLodAndCullExampleRanges.MaxDZ8.svg.png

    Zie het als een serie cirkels (foto rechts hierboven) met de speler in het midden, waar elke cirkel een LOD afstandsschaal is. Op basis van de afstand tot te speler kan de programmeur bepalen welke kwalteit textures en geometrie wordt ingeladen, Veraf is het detail zo klein dat je zelfs met hele lage kwaliteit textures en low-poly objecten kunt wegkomen, soms zelfs met sprites of normalmaps. Tevens kun je het cameraperspectief gebruiken om alles buiten zicht niet mee te nemen in de final render.

    Een recente bug in PUBG op de XBOX waarbij de high-poly geometry pas heel laat werd ingeladen geeft een mooi inzicht hierop wat zich afspeelt normaal in de verte.

    object detail_3_LOD.png

    Hier kun je zien dat de deur welke normaal een vierkant is, vanwege de lagere polygonen nu oogt als een driehoek. Zo geldt dat voor meerdere objecten. De speler blijft te allen tijde dezelfde LOD behouden, polygon counts van player models in deze games zitten zo rond de 10k-15k.

    Of dit voorbeeld van Metal Gear Solid 5, welke bekend stond om op zelfs hoge instellingen op simpele machines goed draaide en weinig CPU belasting had. Nou, dat had een reden, de meshes van de objecten waren low-poly. Kijk maar naar de wielen van deze APC, echt mooi rond zijn ze niet. Dit is in de nightvision zoals hier goed zichtbaar, maar het is in de game dusdanig laag dat het je zelfs opvalt met textures. Had wel iets beter gemogen.

    object detail_2.jpg

    Overigens hoeven niet alle technieken gebruikt te worden. Zeker als het gaat om polygonen gaat moeten bij elke reductie nieuwe meshes gemaakt worden, omdat elke reductie handmatig moet worden gedaan door de developer om te zien of alles nog op elkaar aansluit en goed uitziet. Dit kost natuurlijk veel extra werk, geheugen en daarom doen ze dit niet allemaal. Om dezelfde reden schaalt niet elke game evengoed van low naar High, of enkel op de GPU.

    LOD bekeken in games.

    Om twee van deze gevallen te vergelijken pak ik Prey en Tomb Raider erbij, tevens vallen deze onder de benchmarksuite hier en is het wellicht interessant om te zien welke game beter schaalt.

    LOW_MID_HIGH1.gif

    In Tomb Raider wordt een combinatie gebruikt. Niet bij alle objecten zijn meerdere meshes van beschikbaar, maar van een groot deel van de scenery en objects wel. Van Low naar medium kun je zien dat een gedeelte van de objecten en geometrie culled wordt (toren verliest koepel), deze komen weer tevoorschijn zodra je dichtbij komt, dus de LOD wordt gewoon iets aggressiever gezet. Maar je ziet ook in de muren, bijvoorbeeld boven de kisten met potten erop, dat de vorm van de muren simpeler wordt gemaakt om de hoeveelheid polygonen nodig om de scene te renderen afneemt. In elke preset, van low tot very high, zie je een reductie plaatsvinden in de geometrie of de hoeveelheid culling welke er plaatsvinden op basis van de LOD. Overigens zijn niet alle verbeteringen in complexiteit daadwerkelijk geometrie, er zijn ook plekken waar gewoon hogere textures gebruikt worden. Wellicht beter te zien in de volgende vergelijk vanuit een andere hoek.

    LOW_MID_HIGH2.gif

    Hier zie je bijvoorbeeld bij de brug en de spijlers dat alleen de textures beter worden. Maar bij de stenen muur ernaast zie je tussen medium en very high de complexiteit van de geometrie wel weer toenemen. Gezien het feit dat de geometrie aardig tussen de presets veranderd, is het niet vreemd dat zelfs onder een CPU bottleneck de fps van 120 naar 80fps schaalt. Ik heb overigens geverifiëerd dat het daadwerkelijk om simpelere geometrie gaat en niet het toepassen van Tessellation. Het kostte even wat tijd om deze software onder de knie te krijgen maar ik heb zelfs gebruikt gemaakt van frame analyzes om te zien wat er precies gebeurd tussen de presets. Hier kun je bijvoorbeeld bij Tomb Raider de twee verschillende hairmeshes van een NPC zien. De links is low, de rechts is very high.

    [​IMG] [​IMG]

    Tevens kun je in deze programma’s ook kijken hoeveel drawcalls waarop gespendeerd zijn, en hoe de hele scene is opgebouwd. Bijvoorbeeld ook de hoeveelheid primitieven (driehoeken) en vertexen. Meestal is het hoeveelheid primitieven een derde van de vertexen, immers driehoek heeft 3 vertexen. Hier zie je dat tussen Low en Very High bij Tomb Raider de hoeveelheid primitieven afneemt met een factor 3x.

    [​IMG]

    Bij prey zijn de verschillen significant minder en daardoor zie je op CPU gebied ook minder schalen. Tussen low en very high zat 31.7% bij Prey, tussen low en very high in Tomb Raider zat 43.5%. Tevens kwam dit vooral in de eerste paar seconden van de test waar ik begon in een tunnel. Hier liepen vooral de maximum framerates ver uiteen (180 v. high tot 290 low), de engine heel goed in het cullen van de spelwereld wat niet in het zicht van de speler is. Je ziet de drawcalls van 2.5k-3k teruglopen naar enkele honderden drawcalls zodra je in een gesloten ruimte staat. Neem je die eerste paar seconden weg valt het naar ~22.3%. Dit kan ik straks ook weer aantonen met de frame analyze.

    LOW_MID_HIGH1.gif

    De het enige verschil tussen Low, Medium en High zijn twee objecten welke worden weggehaald. Eerst wordt het krukje bij de omgevallen tafel dichterbij weggehaald, bij low ook het schaakbord iets verderop. Dit is een typisch gevalletje waarin de LOD gewoon korter gezet wordt en er in de buitenschalen aggressiever culling plaatsvind, maar het zijn voornamelijk GPU features welke verlaagd worden hier. De culling zie je wellicht beter in de volgende serie plaatjes van iets verder van de speler.

    LOW_MID_HIGH2.gif

    Hier zie je duidelijk dat in de verte naar mate de grafische preset verlaagd wordt steeds meer objecten verwijderd worden. Je ziet bijvoorbeeld dat er een aantal boompjes, struiken en lichtbakken bij komen. Dit heeft natuurlijk een effect op de rendertijd voor de GPU, maar het betekend ook een afname in vertexes voor de scene. Het verlagen van de settings heeft dus ook een effect op de CPU belasting. De hoeveelheid schaling in deze game is wel een stuk lager en ook de maximale hoeveelheid drawcalls in deze game wordt nooit echt hoog. 2.5k is waar deze game zo’n beetje ophoudt, terwijl Tomb Raider makkelijk het dubbele haalt. Dit zie je bij Prey ook terug in de frame analyze. Tussen Very High en Low scheelt het aantal primitieven nauwelijks in de door hwi geteste helicopterscene.

    [​IMG]

    In de Arboretum test welke ik verderop wil gaan aanraden, mocht deze game wel in de testsuite moeten blijven, is het verschil iets beter. Daarom zie ik ook, later in de resultaten, enige schaling tussen deze resultaten (van low tot very high). Waar ik dit totaal niet zie voor de helicopterscene. De framerates daar lopen zo hoog op dat je eigenlijk alleen op de driver zit te wachten. Meer daarover in deel 2.

    [​IMG]

    Later in de week zal ik de andere delen posten, waar ik inga op hoe deze verschillen zich vertalen naar CPU belasting, threads en waarom sommige games slechter zijn om te testen dan anderen. Stay tuned.
     

    Bijgevoegde bestanden:

    Laatst bewerkt: 25 mei 2018
    Nozem 24/7, Supreme-1985, Maulwurfje en 5 anderen vinden dit nuttig.
  2. DatAccountz

    DatAccountz Senior Member

    Sinds:
    13 nov 2012
    Berichten:
    9.620
    Korte uitleg game-engines, waar liggen de problemen bij he testen van processoren?

    Ik heb een uitleg gegeven over de graphics pipeline, hoe dit zich vertaald in threads voor de CPU is waar zich het hekelpunt ligt van testen op Medium of zelfs lagere settings. De grote bottleneck van multhreading bij game-engines als is de zogenaamde renderthread, niet te vergissen met de mainthread, welke een verzameling is van de game logica, phsyics, AI en player interaction. Deze renderthread is sequentiëel van aard omdat de schakels hiervan van elkaar afhankelijk zijn, zie de graphics pipeline. Je kunt wel via technieken als deferred context en Multi-Render Target (MRT) extra threads parallel aanmaken maar alles wordt wel op een gegeven moment samengevoegd in de renderthread.

    dx11overhead.png

    In de meeste games heb je met een moderne 6C/6T al de limiet bereikt waarin deze games niet beter kunnen batchen en het toevoegen van extra threads met afnemende meeropbrengsten werkt. Houdt er rekening mee dat dit ook afhankelijk is deels van de Driverlayer van de videokaart. Nvidia en AMD verschillen hier vooral in bij directX12. Hardware.info heeft hier recentelijk een artikel van uitgebracht, dit heeft voornamelijk te maken met software vs. Hardware scheduling. Zie mijn post onder dat artikel mbt mijn mening over de test.

    Zoals gezegd dus, batch, batch, batch! Als je alles sequentiëel gaat uitvoeren is de renderthread alleen maar bezig met simpele drawcalls aan het sturen naar de GPU en staat die 95% van de tijd te wachten op de CPU. De GPU is een collectie van hele kleine processoren (shader units) welke je allemaal aan het werk wilt zetten. Hoe meer polygonen op het scherm, des te langer duurt het voor de GPU geometry shaders om alles te berekenen en de taken verdeeld moeten worden. Met een concept genaamt “deferred rendering/shading” is het sinds DirectX11 mogelijk om complexe taken (o.a. geometrie) op te delen in render targets terwijl de gamelogica kan doorlopen. Overigens maakt de geometrie maar een gedeelte op van de complete framerender. Ik heb met Intel Frame Analyzer een trace en framegrab gemaakt om voor zover mogelijk te analyzeren.

    Tomb_raider_very_High_trace.png Tomb_raider_very_High_60fps_Frame_Analysis.png
    Denk dat het even handig is als je deze even opent in nieuw tabblad.

    En ja dit is hele complexe materie, ook voor mij. Ik zal het daarom beknopt besrpeken. De eerste foto is de frametrace, deze geeft precies aan waar de processor mee bezig was en op welke timings. Dit is precies één frame, wat je ziet aan beide VBLANK instructies welke precies 16.65ms (60hz) uit elkaar zitten. Programma’s worden in moderne Operating systems in stukjes verdeeld worden om optimaal gebruik te maken van de resources in cache/geheugen, in zogenaamde slices, ondanks dat je er gebruik van maakt in real-time. Onderaan in de trace kun je de “context thread”, dit is de renderthread en ik heb deze even gemakshalve gelabelled. Als eerste wordt de geometrie berekend door de CPU, deze kan batched worden en daarom zie je dus ook parallel extra threads onstaan. Op low zijn dit er drie keer zo weinig (drie keer zo weinig primitieven zoals ik al had aangegeven in de pipeline) Het is de geometrie in de verschillende render targets aan het plaatsen. Deze worden (geen aangegeven) dispatched naar de GPU. Vergelijk je deze met de framegrab, waar ik het heb opgedeeld in zogenaamde render targets, zie je het concept van MRT. In deze targets, met hun specifieke assets, vindt er door de GPU pixel rendering plaats. De belichting, tessellation, shaduwen, textures worden in al de rendertargets voorzien.

    Wellicht zie je nu waar het zich gaat fuiken als je de scene te simpel gaat maken met lagere settings en bovendien op hoge framerates (>100fps). De belasting verschuift zich steeds meer naar de renderthread, er worden minder simultane deferred context threads aangemaakt en de hele game engine gaat stallen op een drawcall limiet. Een drawcall van de CPU moet via de API naar de driver gestuurd worden. Zeker in de DirectX11 API (Application programming interface) overhead vrij groot (zie foto met de threads eerder, de kernel en userdrivermode zijn twee grote chunks van je renderthread) en bij een zekere hoeveelheid drawcalls (vermenigvuldigd ook nog eens door de framerate) is de renderthread eigenlijk alleen maar aan het wachten op de CPU terwijl het door de applicatielagen aan het gaan is. DirectX12 zou dit deels moeten oplossen door minder applicatielagen te hebben tussen de CPU en de GPU, maar dit verhoogt eigenlijk alleen het punt waar de CPU tegen hetzelfde probleem aanloopt (max. hoeveelheid drawcalls). Je zult in je game engine toch beter de taken moeten batchen om gebruik te maken van de additionele threads. Moraal is dus: Niet testen met medium of low settings als het doel is CPU performance in z’n algemeenheid te testen. Houd de framerates binnen perken. Ga je met je benchmark over de 150-200 fps, moet je wellicht een andere scene of game in de suite stoppen omdat je zeker op DirectX11 gewoon teveel de driver overhead aan het testen bent op een enkele core.

    Tenzij het een specifiek doel heeft zoals “kan het game X op medium spelen”, dan is het een ander verhaal. Maar als maatstaf voor toekomstige prestaties is dit niet toereikend. Omdat de complexiteit van games in de toekomst niet alleen in de hoeveelheid drawcalls schaalt. De geometrie schaalt mee, shader pixels zullen hogere resoluties gaan gebruiken, AI wordt complexer, engine-physics, afmeting spelwereld, etc. Als je dan afgaat op hoe snel je nu de DX11 game renderthread kunt afwerken met simpele geometrieen, zit je in een game als Kingdome Come mooi met 35fps te kijken. En heb je de behoefte een boze reactie te typen in de steamreviews over "crappy optimization", dan is dit niet de schuld van de developer maar van dit soort benchmarkresultaten. Wellicht ligt hier dan voor de reviewer ook de taak om iets meer informatie te geven over de specifieke belasting op de CPU in plaats van corescaling alleen.

    “Canned” Benchmarking en testopstelling.

    Wat me op een volgend hekelpunt brengt en eigenlijk de reden waarom ik deze hele lap tekst heb geschreven. Het is iets wat heel veel websites en youtube kanalen, en zonder HWI onder de bus te willen gooien, ze hier ook "schuldig" aan zijn. Canned benchmarks, de roepterm voor het type benchmarks welke standaard in games zitten en geautomatiseerde tests zijn. Natuurlijk makkelijk voor de tester, druk op een knop en er rolt een score uit. Echter met het idee van LOD in ons achterhoofd, zodra je dus als developer weet hoe de camera zich gaat bewegen en niet hoeft te anticiperen op een spelerinteractie, kun je stoeien met je LOD. Je kunt nu niet alleen objecten niet meenemen in de final render, maar ze ook simpelweg niet inladen. Dit is veel moeilijker te voorspellen als je niet kunt anticiperen (real-time) welke assets je moet inladen bij het bewegen van de camera. Bij een camera op rails weet je precies welke assets je moet streamen en wanneer, bij een speler weet je niet welke kant hij op gaat draaien. Het resultaat hiervan is dat de systeembelasting niet representatief is vaak met de daadwerkelijke prestaties welke je krijgt ingame zodra deze aggressieve LOD niet gebruikt wordt. Om dit aan te tonen kunnen we een bekende benchmark pakken welke hardware.info vaak zelf gebruiken, namelijk Rise of the Tomb Raider. Tevens gebruik ik ook het gedeelte in Prey waar ze op testen, de intro helicopterrit. Niet bepaald een ingebouwde benchmark, maar ook deze is een sectie op rails waar heel weinig aan de gang is.

    canned benchmark.png

    Deze Tomb Raider benchmark loopt een aantal scenes door welke je in de game tegenkomt. Namelijk de intro mountain peaks, de eerste tomb in syrië en de geothermal valley. Ik haal met mijn 4670K (net als hardware.info) rond de 170+ fps average in deze benchmark op medium. Als lezer denk je dan: deze game is niet processor intensief en als ik deze game wil spelen op 60 fps ga ik geen problemen ondervinden met mijn i5 of zelfs i3. Ga je echter rondrennen in Geothermal Valley or Soviet installation met je i3 of i5 kom je van een koude kermis thuis. Nu gaat de game anticiperen op de speler en veel minder conservatief zijn met het inladen van assets, geometry, objects, NPC's, etc. Dit zijn allemaal taken voor de CPU. Met al deze complexe geometrie in beeld worden er veel meer subthreads gemaakt en wordt in mijn geval de i5 volledig verzadigd. Het doel van dit hoofdstuk is om te kijken hoe effectief de benchmarks zijn ten opzichtte van gameplay. Bij Tomb Raider heb ik de resultaten van Geothermal Valley uit de benchmark resultaten gehaald. Dus deze kun je niet geheel vergelijken met de resultaten van Hardware.info, welke de volledige resultaten van alle drie gebieden gebruiken. Tevens heb ik in alle instellingen volledig door het leven heen gerend om te kijken hoe deze vergelijken.

    canned benchmark2.png

    De benchmark van Prey omvat het gedeelte wat ze hier testen, vlak na de intro moet je in een helicopter gaan zitten en deze ‘vliegt’ dan naar een ander dak nadat het over een stad heeft gevlogen. De scéne is 60% skybox, hele simpele geometrie als je een beetje erop gaat letten en omdat de game gebouwd is op kleinere gebieden zie je hier heel veel asset pop-in. Omdat dit niet officiëel een canned benchmark is, maar een on-rails gedeelte heb ik zelf een wat grote open ruimte verder in de game gepakt, de arboretum als meer "realistisch" scenario. Ik kan niet zoals bij Tomb Raider dezelfde scene in-game vergelijken. Dit gebied bevat een heleboel NPC’s, objecten en particle effects (later in de game).

    Mijn testsysteem kun je vinden in mijn profiel. Kort samengevat:

    Core i5-4670K op 4.3ghz
    16GB Corsair Vengeance DDR3-2400 CL11
    EVGA GTX 1080 FTW
    Windows 10 Pro laatste build.
    Geforce Driver: 391.24

    Morgen zal ik de resultaten posten hiervan, ik was er nog niet helemaal klaar mee om ze meteen hierachter te plakken. Stay tuned.
     
    Laatst bewerkt: 27 mei 2018
    eismc2, Nozem 24/7, Supreme-1985 en 2 anderen vinden dit nuttig.
  3. DatAccountz

    DatAccountz Senior Member

    Sinds:
    13 nov 2012
    Berichten:
    9.620
    Testresultaten ter ondersteuning

    Na al die tekst verdien je wel wat bar-charts. Even voor de goede orde, dit is dus niet de complete score voor de benchmark maar de Geothermal Valley subsectie. Dit omdat ik dan in de geothermal valley de test kan nabootsen.

    Canned_benchmark_DX12.png

    Dit is de DX12 versie van de benchmarkruns die ik heb gedaan. Ik heb het meerdere keren geverifiëerd, maar als je de beelden van deze benchmark bekijkt is het ook vrij logisch. Het duurt even in de scene voordat alle assets ingeladen zijn, er is daarom weinig geometrie aanwezig en daarom ook weinig drawcalls. De framerate kan dan zeer hoog oplopen (hoe lager de setting, des te hoger hij raakt). Daarna laden de assets in, maar de LOD is zeer aggressief, je ziet veel meer pop-in in de verte dan je ingame ziet. Zeker kan ik niet zijn, maar op DX12 gaat er iets niet goed met de streaming van assets. De processor staat in ieder geval in elk van de benchmark runs op 100% gedurende deze test, maar de uitkomst is hetzelfde. Het is geen game engine hardcap, omdat de maximale framerate wel kan oplopen. Maar die average en minimum framerate welke hetzelfde zijn behalve één resultaat, very high, lijkt me geen toeval. Ik heb ze daarom ook maar even in DX11 getest en daar leek het in eerste instantie beter te gaan.

    Canned_benchmark_DX11.png

    Maar ook bij very low loop ik tegen hetzelfde probleem aan, consistent (5+ keer getest) laden de assets gewoon niet in. Er gaat in ieder geval op mijn CPU iets mis als hij te hoge framerates haalt in die engine waardoor hij simpelweg niet de tijd krijgt om de assets te streamen. Ik heb in DX11 wel kunnen vastleggen hoe dit eruit ziet.

    canned.png ingame.png

    Links is de bug in de benchmark, rechts is dezelfde scene ingame. Je ziet aan de hoeveelheid primitives dat maar één derde van de geometrie ingeladen is. De hoeveelheid drawcalls is terug gevallen naar één vierde

    Feitelijk draaien alle tests in DX12 voor geothermal valley zonder het overgrote gedeelte van de assets ingeladen en dit zie je dan ook terug aan de resultaten. Vergelijk ik dit namelijk met de resultaten van Geothermal valley ingame op DX12 krijg je een ander beeld.

    Ingame_DX12.png

    Zoals ik eerder liet zien, bij het LOD verhaal, schaalt Tomb Raider ingame wel tussen alle presets. En ondanks dat mijn CPU ook hier weer bij elke instelling op 100% over alle cores stond, schaalde deze zag ik in dit geval wel prima schaling in min/max en average. Ook laat dit zien dat zelfs bij very low deze CPU niet, ondanks wat de benchmark laat zien, boven de 60fps blijft. En je ziet ook dat very low de enige is wat in de buurt komt van de benchmark resultaten. Nu ren ik in deze eigen ingame benchmark, in tegenstelling tot de canned benchmark, ook de laatste 10 seconden het drukke dorpje in. Dit verklaard de lagere absolute resultaten. Ik kan bij deze game geen afterburner grafieken erbij pakken omdat ik zo weinig CPU cycles overhield dat de pollingrate van Afterburner te laag was. Maar er valt ook weinig te zien want het was gewoon 100% CPU load. Tomb raider is dus wel een goede CPU test, maar enkel als je het test buiten de benchmark.

    Want zelfs als de benchmark de assets op tijd inlaad op very high DX11, als je deze vergelijkt met de frame in-game zie je dat de developers de engine flink knijpen in de benchmark modus. Ook hier heb ik de twee frames kunnen vastleggen en kunnen vergelijken.

    canned.png ingame.png

    Links is de canned benchmark, rechts is dezelfde scene (voor zover mogelijk) in de game zelf. Aan de rechterkant kun je de full-frame statistics bekijken. Om te beginnen is de hoeveelheid geometrie in de scene 15,4% hoger in-game, dit valt wellicht te verklaren omdat Lara zelf niet in de scene is geplaatst. De character is behoorlijk high poly, dus dat kan het verschil verklaren. Wat niet verklaarbaar is, buiten een moedwillige keuze om de resultaten beter te laten lijken, is de drievoudig hogere HS invocations bij de in-game resultaten ten opzichte van de benchmark resultaten. Dit zijn zogeheten Hull Shader Invocations. Deze shaders worden gebruikt voor tessellation en zijn zeer geometry-heavy en een zware last op je systeem. De hoeveelheid drawcalls is ook vanwege de lagere geometrie 16.2% lager. Ondanks dat Nvidia beter om kan gaan met tessellation raken deze settings Nvidia meer. Omdat, in tegenstelling tot AMD, Nvidia de hoeveelheid tessellation niet begrenst in de drivers. Het is aan de lezer om dit te interpreteren, ik ga hierover niet speculeren. But there it is.

    Hetzelfde gebeurd eigenlijk ook bij Prey, alleen daar raak ik in de door HWI geteste sectie een API overhead bottleneck. En hierbij zijn de Afterburner resultaten ook interessant. De eerder genoemde helicopter scene, een testgebied wat door meerdere sites gebruikt wordt, schaalt. Het lijkt een stukje wat je makkelijk kunt reperteren, maar zie de resultaten:

    Helicopter_resultaten.png

    Alleen bij High en Very high is er een moment dat de GPU iets meer belast wordt en de mimimum framerate iets verder dipped. Het overgrote gedeelte zie je duidelijk dat zowel de GPU als CPU niet maximaal belast worden en de enig verklaarbare bottleneck kan hier een API overhead probleem zijn. Ik heb wel een verklaring ervoor maar dit omvat een spoiler alert:
    De hele helicopter scene is nep en je zit eigenlijk in een bewegende romp met een scene wat om je heen afspeelt. Als je saved voor de rit en laad na de rit is er ook geen laadtijd. De props die je meeneemt liggen ook op de grond. Ik vermoed dat je gedurende de hele scene naar een filmpje in een cockpit zit te kijken. Vandaar dat eigenlijk ook alle resultaten hetzelfde zijn.
    Nemen we bij deze titel de Afterburner charts erbij zie je ook wat er gebeurd. Hier zal ik voor het doel van deze test me beperken tot very high vs. Medium.

    Very High
    Very_High_CPU_load.png

    Medium
    Medium_CPU_load.png

    Je ziet feitelijk geen substantiële toename in overal CPU load. Alle kernen blijven eigenlijk hangen rond de 60% en geen piekt uit. Dat komt omdat vanwege het feit dat één thread gewoon de bottleneck is, deze thread vanwege time slicing niet constant op dezelfde core blijft lopen. Daarom kun je ook nooit de opmerking maken: "geen van mijn cores staat op 100%, het kan geen CPU bottleneck zijn".
     
    Laatst bewerkt: 27 mei 2018
    eismc2 en Nozem 24/7 vinden dit nuttig.
  4. DatAccountz

    DatAccountz Senior Member

    Sinds:
    13 nov 2012
    Berichten:
    9.620
    Test resultaten ter ondersteuning continued (10 image limit bereikt, hwi pls):

    Omdat ik gewoon geen schalig zag ben ik een andere plek in de game gaan opzoeken. Zoals ik in deel1 zei had ik het Arboretum gedeelte genomen. Dit is een grote open plek met, voor deze game, relatief veel geometrie en enemies wat rondlopen.

    ingame_results.png

    De schaling is nog niet geweldig en de framerates zijn behoorlijk hoog. Maar Ook hier heb ik de CPU load grafiekjes erbij kunnen opnemen.

    Very High

    veryhigh.png

    Op very high krijg ik bijna volledige verzadiging over alle cores. Stukken beter al dan de API overhead wat ik kreeg bij de helikopter. Echter is dit een i5 van 2013, als ik al plekken moet gaan zoeken om deze CPU te verzadigen is het niet bepaald een goede test voor snellere modellen.

    Medium

    Medium.png

    Op medium loop ik ook zelfs in deze zwaardere scenario tegen een API overhead aan en krijg ik niet alle cores verzadigd continue, maar over het algemeen is de core belasting veel zwaarder zoals je ook in de resultaten kunt zien. Het hardware labs level heeft nog iets meer drawcalls en is wellicht een betere test. Maar omdat dit hele verhaal al zo lang is en ik nog aanbevelingen moet doen heb ik deze weggelaten.

    Wat we van dit gedeelte kunnen wegnemen is: canned benchmarks zijn niet representatief voor in-game resultaten en ze gaan heel anders om met hun Level of Detail. Hoge framerates zorgen al vrij snel voor API overheads en het is belangrijk voor de reviewer om te kijken of wat ze testen wel interessante resultaten geeft en wellicht op basis daarvan een betere plek zoeken om te testen. Of in het geval dat deze niet bestaat, de test gewoon uit de suite werpen.

    Keuze games-suite bij het testen van processoren en het zoeken van een representatieve scene om te testen.

    Wat beveel ik dan wel aan? Een belangrijk aspect is het kiezen van een game welke interessante resultaten genereerd, niet zo zeer welke populair is. Je kunt als tester natuurlijk nooit zeker weten wat de toekomst gaan brengen, maar games gebruiken die nu hoog aimen is een begin. Denk aan hoe ambitieus Crytek was met Crysis, die game is nu nog lastig te draaien op moderne hardware. Bekijk de game in frame capture software en beoordeel de drawcall counts, assets. Kijk hoe de game is opgebouwd, complexe phsyics engines, degelijke LOD (liefst instelbaar), AI die niet tegen de boom staat te rennen, etc. Niet elke developer kiest ervoor om een gecompliceerde engine te gebruiken en niet elke game is dus geschikt om de prestaties van de CPU op te testen. Tevens zijn de consolegames momenteel behoorlijk simpel aan het worden vanwege de Jaguar cores. Willen ze grafisch omhoog moeten en CPU cycles worden weggenomen bij andere zaken (zoals AI, collision, phsyics).
    Wat je eigenlijk wilt zien is een schaling zowel in de hoogte (IPC) als in de breedte (cores) als het op processorprestaties aankomt. Natuurlijk zul je verwijten krijgen mbt de relevantie als je een game uit 2013 gaat testen, maar eveneens kun je deze zelfde vraag stellen als je een titel als GTA 5 of Starcraft 2 erbij doet. Beide populaire titels, maar GTA 5 houdt op met schalen vanaf vier threads en Starcraft houdt al op bij twee. Tevens heeft GTA 5 het probleem dat de processoren nu zo snel zijn geworden sinds de game in 2013 uitkwam (de game zelf), dat de engine begint te falen boven 160fps met quadcores. GamersNexus heeft hier toen een video over gedaan, meer bewijs dat het op hoge framerates testen van games allerlei problemen met zich meedraagt, alleen in dit geval werd het opgemerkt.





    Een aantal games welke niet extreem oud zijn, maar welke zowel in de hoogte als in de breedte schalen zijn titels als Assassin’s Creed Origins, Watch Dogs 2, For Honor en ook Rise of the Tomb Raider als je hem correct test. Een oude favoriet van mij is Crysis 3, welke prima doorschaalt tot 8 threads, zeker in levels als “Welcome to the Jungle”. De game waar de 8350 zelfs de 3770K nog in het stof laat.

    Deze games hebben ook in-game benchmarks, maar dit is dus precies wat je wilt vermijden zoals ik heb aangetoond. Waar je naar moet zoeken is een gedeelte in de game waar de CPU een hoop NPC’s, objecten en dergelijken moet inladen en de engine van alle kanten belast wordt. Je wilt niet in een bunker tegen de muur staan kijken, 250fps trekken en de renderthread cappen. Tevens wil je dus zo hoog mogelijke settings gebruiken om de hoeveelheid drawcalls (object detail, shaders, phsyics, draw distance, LOD, AI) te maximaliseren. De invloed van de GPU kun je beïnvloeden door de MSAA te verlagen (of uit te zetten), of de resolutie te verlagen. Zolang de GPU niet voorbij de 80-90% belasting gaat is de CPU de gemeenschappelijke deler in de prestaties. Voorbeelden zijn bij Tomb Raider de Geothermal Valley of Soviet Installation. Bij Crysis 3 is dit Welcome to the Jungle, Watch Dogs 2 kun je een rondje door de stad rijden. For Honor heb ik persoonlijk niet. Een nieuwe populaire titel is Far Cry 5, ik ben niet zo kapot van de corescaling bij die game.

    Tevens, zoals ik al eerder heb aangegeven, is een deel van de overhead afhankelijk van de Graphics Driver. Zowel Nvidia als AMD hebben een andere strategie als het aankomt op dispatch ops en scheduling en dit kan voor de combinatie met een CPU verschillende gevolgen hebben. Zeker op het gebied van DX12 doet Nvidia het simpelweg niet goed met hun single-threaded software scheduler en zie je Ryzen chips significant beter scoren met VEGA Graphics. Belangrijk is dus om je, indien mogelijk, niet te beperken tot één grafische driver.

    Ik heb nog wat resultaten van de voorgestelde games, betreffende de corescaling van de games. Dit zijn daarom ook tevens de games die ik aanbeveel. Far Cry 5 staat er ook bij, al ben ik daar niet volledig van overtuigd.

    core_scaling_crysis3.png core_scaling_dogs.png core_scaling_farcry5.png core_scaling_honor.png core_scaling_origins.png core_scaling_rise.png

    Bedankt voor het lezen, als je vragen hebt stel ze gerust. Ik begrijp dat het complexe stof is en veel leesmateriaal maar er komt nu eenmaal veel bij kijken.
     
    Laatst bewerkt: 26 mei 2018
    ErikdR, eismc2, David van Dantzig en 4 anderen vinden dit nuttig.
  5. Maulwurfje

    Maulwurfje Senior Member

    Sinds:
    8 okt 2009
    Berichten:
    827
    DatAccountz complimenten voor de grondige aanpak. Het is duidelijk dat je een rabbithole bent ingestapt en deze diep aan het uitpluizen bent.

    Hoe verhoudt dit verhaal zich met frametimes? Ik vind het nog even iets te lastig om helemaal te begrijpen wat er op zo'n moment gebeurt. Waarom wordt het aantal drawcalls verhoogt als je de settings oplaag brengt? Is het aantal drawcalls niet per frame voor de laagste settings het laagst van allemaal?

    Maar als de hoofd renderthread overspoelt wordt met drawcalls, wat doet dit dan met de frametimings? Gaan deze meer van elkaar verschillen, waardoor je dus misschien hogere framerate hebt maar minder soepele ervaring.

    Ik vind dat nog al een uitspraak. Daar kan best een kern van waarheid inzitten. Ben jij mogelijk bekend met tools die de kloksnelheid van je processor per thread sneller kunnen vastleggen? Want die 100% processor belasting valt nu weg uit de grafiek door de pollingrate van afterburner en middeling.
     
  6. DatAccountz

    DatAccountz Senior Member

    Sinds:
    13 nov 2012
    Berichten:
    9.620
    Bedankt, het was gewoon iets wat me stoorde maar ik wilde geen half uitgewerkte kritiek erop geven. Hier kunnen ze wellicht iets mee bij de selectie van nieuwe games. Het is echter niet uit te houden in mijn kamer (>30graden, zon kant huis) dus de conclusie met aanbevelingen komen vanavond ergens.

    Ja, zodra bepaalde threads niet meer op tempo kunnen werken gaat je engine stallen. Daarom zie je ook altijd de meeste stuttering bij een CPU bottleneck. Je kunt 45 fps halen en prima spelen wanneer de videokaart op 100% staat. Maar haal je 45fps onder een CPU bottleneck gaan je frametime variaties er helemaal aan. Ik kan dit zien in de grafieken, maar zonder een FCAT test kan ik daar niets objectiefs over zeggen. Ik kan wellicht eens een presentmon testje doen bij Tomb Raider.

    Nee, plus het probleem wat je gaat krijgen met hele hoge pollingrates is dat je CPU interrupts allemaal gebruikt worden voor de monitorings software. Ik heb Afterburner ook voor de meeste tests uitgezet omdat het een behoorlijke hoeveelheid interrupts wegneemt. Als je in een game moeite hebt met CPU utilization moet je die monitoringssoftware als eerste uitzetten.

    En de uitspraak doe ik op basis van wat ik zie. Prey is duidelijk in de helicoptersectie CPU bottlenecked, zeker op low, maar ik krijg gewoon geen core op 100%. Kijk anders maar eens naar dit plaatje uit deel 2.

    https://nl.hardware.info/forum/attachments/tomb_raider_very_high_trace-png.36363/
     
  7. 5erveD

    5erveD Senior Member

    Sinds:
    3 mrt 2014
    Berichten:
    1.076
    Petje af voor het werk.

    LOD staat bij mij vaak voor hogere scores ;-)
     
  8. DatAccountz

    DatAccountz Senior Member

    Sinds:
    13 nov 2012
    Berichten:
    9.620
    Thanks.

    Staat vaak, laag of af? Volgens mij woordje weg gevallen daar ;)
     
  9. 5erveD

    5erveD Senior Member

    Sinds:
    3 mrt 2014
    Berichten:
    1.076
    Ja, het staat er een beetje raar. ;-)

    Wat ik bedoel is dat het instellen van de LOD in de driver zorgt voor een hogere score in bepaalde benches.
    En een lichte verhoging kan al het verschil maken indien toegestaan vwb de benchmark.
     
  10. Maulwurfje

    Maulwurfje Senior Member

    Sinds:
    8 okt 2009
    Berichten:
    827
    Wat jij terecht vaststelt vraagt nog al wat specialistisch werk en vreet tijd. Of het voor sites zoals HWI en tweakers iets is betwijfel ik. Meer voor de (specialistische) youtubers zie ik hierin een unieke kans om betere benchmarks suits te maken (die HWI e.d. dan weer kunnen overnemen).

    Games in je benchmark suits zullen voor de CPU en GPU ook moeten verschillen. Populaire games mogen van mij wel mee worden genomen worden in de GPU benchmarks. Je wilt gewoon weten of een game lekker draait op je videokaart (die ik de regel bottleneck is).

    Vraag met iets andere insteek. Dit lijstje aan 'dingen' die allemaal berekend moeten worden, hoe verhouden die zich met elkaar?

    Wordt op 250fps (of op 60 wat dan ook) het bovenstaande allemaal met dezelfde interval geupdate (dus alles elke frame)? En dan ga ik er nietvanuit dat de main renderthread overspoelt is. Of zijn er zaken die bijv. elke 16ms worden geupdate zoals phsyics of AI of object detail. Want zolang het plaatje voor de gebruiker maar klopt lijkt mij het bijv. onnodig als een AI-karakter elke seconde 120x om input wordt gevraagd ipv 60x. Dit zal voor de speler toch niet een merkbaar ander resultaat opleveren.

    edit: Level1Techs kwam er ook achter tijdens hun Ryzen 2700X review dat de GTAV engine kapot gaat bij framerates hoger dan ~160/170 beelden.
     
    Laatst bewerkt: 27 mei 2018
  11. DatAccountz

    DatAccountz Senior Member

    Sinds:
    13 nov 2012
    Berichten:
    9.620
    Dat hangt een beetje van de keuze van de developer af of ze de animatie/collision updates elke frame doen of niet. Vaak gebeurd dat soort set-animation-updates alleen als je weet wat de framerate gaat zijn. Bij unlocked framerates ga je dat meteen zien. Dus nee, zodra de framerate unlocked is heb je meestal gewoon updates per frame. Daarom breken sommige games ook als je de framerate unlocked. Sowieso wordt alle geometry elke frame geupdate. De CPU berekend alle nieuwe coordinaten en stuurt deze vertexen door, per frame.
     
  12. Hennes

    Hennes Senior Member

    Sinds:
    26 feb 2007
    Berichten:
    380
    Mooi stukje werk van je, het is nu wat aan de late kant maar ik ga het helemaal lezen, zou het zonde vinden van zoveel werk dat je er in hebt gestoken .
     
  13. DatAccountz

    DatAccountz Senior Member

    Sinds:
    13 nov 2012
    Berichten:
    9.620
    Bedankt, heel tijdsgebonden is het niet dus "te laat" zou ik nooit zeggen.
     
  14. 129401

    129401 Geband

    Sinds:
    2 apr 2018
    Berichten:
    225
    Knap staaltje werk !

    Ik heb het in 1x doorgelezen ,wat voor mij echter niet toereikend is ,daarom zal ik dit nog veel vaker lezen om het goed tot mij door te laten dringen .
     
  15. TJM de Groot

    TJM de Groot Senior Member

    Sinds:
    26 dec 2009
    Berichten:
    694
    Interessant leesvoer Kudos voor het vele werk, al moest ik sommige delen 2x lezen om het enigszins te begrijpen my bad :oops:
     
  16. DatAccountz

    DatAccountz Senior Member

    Sinds:
    13 nov 2012
    Berichten:
    9.620
    Taalkundig of technisch?
     
  17. TJM de Groot

    TJM de Groot Senior Member

    Sinds:
    26 dec 2009
    Berichten:
    694
    Technisch ben er nog duizelig van :p
     
    LaCrimosa vindt dit nuttig.
  18. JMM

    JMM Senior Member

    Sinds:
    8 aug 2006
    Berichten:
    1.338
    Dit is veel te technisch voor mij maar ik lijk te verstaan dat je o.a. onderbouwd wilt bewijzen dat de huidige 2000 serie van AMD niet onder hoeft te doen voor Intel, ook niet in gaming.
    Klopt het enigszins wat ik denk, ook al snap ik vrij weinig van de technische uiteenzetting?