Anslut till Senaste Tekniska Nyheter, Bloggar, Recensioner

Välja en spel-CPU: Single + Multi-GPU vid 1440p, april 2013

En fråga när man bygger eller uppgraderar ett spelsystem är vilken CPU man ska välja – spelar det någon roll om jag har en quad core från Intel, eller en quad-modul från AMD? Kanske något enklare kommer att göra susen, och jag kan spendera skillnaden på GPU:n. Vad händer om du kör en multi-GPU-installation, har processorn en större effekt? Det här var frågan jag ställde upp för att hjälpa mig att besvara.

Några saker innan vi börjar:

Denna uppsättning resultat är inte på något sätt omfattande eller uttömmande. För ändamålsenlighetens skull kunde jag inte välja 10 olika speltitlar över en mängd olika motorer och sedan testa dem i sju eller fler olika konfigurationer per spel och per CPU, och jag kunde inte heller testa varenda processor som tillverkades. Som ett resultat, på spelsidan, begränsade jag mig till en upplösning, en uppsättning inställningar och fyra mycket regelbundna testtitlar som erbjuder tidsdemos: Metro 2033, DiRT 3, Civilization V och Sleeping Dogs. Detta är uppenbarligen inte Skyrim, Battlefield 3, Crysis 3 eller Far Cry 3, som kan vara mer relevanta i din uppsättning.

Argumenten för och emot tidsdemotestning såväl som argumenten för att ta FRAPs värden för sekvenser är väldokumenterade (tidsdemos kanske inte är representativa jämfört med konsekvens och realism av FRAPs en upprepad körning över ett fält), men alla våra tester kan köras på hemmasystem för att få en känsla för hur ett system fungerar. Nedan är en diskussion om AI, en av de vanligaste användningsområdena för en CPU i ett spel, och hur det påverkar systemet. Av våra riktmärken spelar DiRT 3 ett spel, inklusive AI i resultatet, och den turbaserade Civilization V bryr sig inte om direkt AI förutom tiden mellan varven.

Allt detta kombineras med min unika position som moderkortsredaktör här på AnandTech – tjänsten ger mig tillgång till ett brett utbud av moderkortskretsuppsättningar, lane-allokeringar och ett ganska stort antal processorer. GPU:er finns inte nödvändigtvis i ett stort utbud i min sida av granskningsområdet, men både ASUS och ECS har försett mina testbäddar med HD7970s respektive GTX580s, så att de har varit avgörande för att vara en del av min testbädd i 12 och 21 månader . Uppgiften framför mig i den här recensionen skulle nästan vara en karriär i sig om vi skulle expandera till fler GPU:er och fler multi-GPU-uppsättningar. Att testa upp till 4x 7970 och upp till 2x GTX 580 är därför ett mer än rimligt ställe att börja.

Där allt började

Den viktigaste punkten att notera är hur denna uppsättning resultat kom till. För flera månader sedan stötte jag på några uppsättningar tester från andra recensionswebbplatser som gjorde mig sämre – enkla CPU-jämförelsetester för spel som spred sig som en löpeld bland forumen, och vissa resultat motsäger den allmänna rådande åsikten om ämnet. Dessa resultat drog ut alla möjliga lurande forumanvändare ur träverket för att ha en åsikt, och eftersom jag är den välanpassade vetenskapsman jag är, satte jag fram för att bekräfta att resultaten åtminstone delvis var giltiga.

Vad som kom därefter var en chock – vissa hade ingen riktig förklaring av hårdvaruinställningarna. Medan den grundläggande översikten av hårdvara tillhandahölls, fanns det ingen nedgång av inställningar som användes, och inga försök att motivera fynden som uppenbarligen hade orsakat en hel del uppståndelse. Det behöver inte sägas att jag kände mig chockad över att bristen på utförliga tester, såväl som både resultaten och mycket av samtalet, särskilt från ivriga fans av Team Blue och Team Red, som följde. Jag planerade att rätta till detta fel på bästa sätt jag vet – med vetenskap!

Den andra anledningen till att sammanställa resultaten i den här artikeln är kanske den jag ursprungligen började med – behovet av att uppdatera drivrutiner då och då. Sedan Ivy Bridge släpptes har jag använt Catalyst 12.3 och GeForce 296.10 WHQL på mina testbäddar. Detta orsakar problem – äldre drivrutiner är inte optimerade, läsare klagar ibland om äldre drivrutiner används och nya spel kan inte läggas till i testbädden eftersom de kanske inte skalas korrekt på grund av de äldre drivrutinerna. Så även om det finns några recensioner på internet som uppdaterar drivrutiner mellan testerna och behåller de gamla siffrorna (vilket leder till skeva resultat), är det faktiskt ett stort åtagande att ta tid för att testa om ett antal plattformar för fler datapunkter enbart på de nya drivrutinerna .

Att till exempel testa nya drivrutiner över sex plattformar (CPU/moderkortskombinationer) skulle innebära: sex plattformar, fyra spel, sju olika GPU-konfigurationer, ~10 minuter per test plus 2+ timmar för att ställa in varje plattform och installera ett nytt operativsystem/drivrutiner /ställ in riktmärken. Det gör mer än 40 timmar av stabila tester (om allt går utan att en sekund förloras här eller där), eller drygt en hel arbetsvecka – mer om jag också testar CPU-prestandan för en beräkningsriktmärkeuppdatering, eller exponentiellt mer om jag inkluderar flera upplösningar och inställningsalternativ.

Om det är allt som jobbas med den veckan betyder det inget nytt innehåll – så det händer sällan, kanske en gång om året eller före en stor lansering. Den här tiden var nu, och när jag började testa, flyttade jag till Catalyst 13.1 och GeForce 310.90, som när den här recensionen går live redan kommer att ha ersatts! I verkligheten har jag långsamt arbetat med denna datamängd under den bästa delen av 10 veckor samtidigt som jag har granskat annan hårdvara (men behållit dessa recensioner med konsekventa drivrutinsjämförelser). Totalt kapslar denna recension in 24 olika CPU-inställningar, med upp till 6 olika GPU-konfigurationer, vilket innebär 430 datapunkter, 1375 benchmark-loopar och över 51 timmar i bara GPU-riktmärken, utan att ta hänsyn till installationstid eller drivrutinsproblem.

Vad gör CPU:n i ett spel?

Många spelutvecklare använder anpassade versioner av spelmotorer, som EGO-motorn för körspel eller Unreal-motorn. Motorn tillhandahåller grunden för mycket av koden och optimeringarna däri. Motorn bestämmer också vad i spelet som laddas av på GPU:n.

Föreställ dig koden som utgör spelet som ett linjärt händelseförlopp. För att gå igenom spelet snabbt behöver vi den snabbaste enkärniga processorn som finns. Naturligtvis är spel inte så här – mycket av spelet kan parallelliseras, till exempel vektorberäkningar för grafik. Dessa var naturligtvis de första som flyttades från CPU till GPU. Med tiden har fler delar av koden tagit steget – fysik och datorer har varit huvudfunktionerna under de senaste månaderna och åren.

GPU:n är bra på oberoende, enkla uppgifter – att beräkna vilken färg som finns i vilken pixel är ett exempel på detta, tillsammans med tilläggsbearbetnings- och efterbearbetningsfunktioner (FXAA och så vidare). Om en uppgift är linjär lever den på CPU:n, som att ladda texturer i minnet eller förhandla om vilken data som ska överföras mellan minnet och GPU:erna. CPU:n tar också kontroll över oberoende komplexa uppgifter, eftersom CPU:n är den som kan göra komplicerad logikanalys.

Mycket få delar av ett spel faller under rubriken “oberoende men ändå komplex”. Allt som är lämpligt för GPU:n men inte porterat kommer att finnas här, och det stora som vanligtvis citeras är artificiell intelligens. Att bestämma var en NPC ska springa, skjuta eller flyga kan betraktas som en mycket komplex uppsättning beräkningar, idealisk för snabba processorer. Motargumentet är att spel har haft komplex AI i flera år – antalet gånger jag personligen förstördes av en Dark Sim på Perfect Dark på N64 är ett bevis på antingen min värdelöshet eller det faktum att komplex AI kan konfigureras med inte mycket CPU kraft. AI kommer sannolikt inte att vara en begränsande faktor i bildhastigheter på grund av CPU-användning.

Det som med största sannolikhet kommer att vara den begränsande faktorn är hur processorn kan hantera data. När motorer utvecklas försöker de använda data mellan CPU, minne och GPU mindre – om texturer kan behållas på GPU:n kommer de att stanna där. Men vissa motorer är inte så perfekta som vi skulle vilja att de ska vara, vilket resulterar i att processorn är den begränsande faktorn. När CPU-prestandan ökar och de som skriver motorerna i vilka spel görs förstår ekosystemet, borde CPU-prestanda vara mindre problem över tiden. Alla vägar pekar förstås mot PS4, och dess 8-kärniga Jaguar-processor. Är detta allt som behövs för en enda GPU, om än i en HSA-miljö?

Multi-GPU-testning

En annan vinkel jag ville testa utöver de flesta andra webbplatser är multi-GPU. Det finns innehåll online som mest handlar om enstaka GPU-inställningar, med några för dubbla GPU. Även om antalet multi-GPU-användare faktiskt är ganska litet globalt, är entusiastmarknaderna helt klart inriktade på det. Vi får moderkort med stöd för fyra GPU-kort; vi har fodral som kommer att stödja ett dubbelprocessorkort samt fyra dubbelhöjda GPU:er. Sedan finns det GPU:er som släpps med två uppsättningar kisel på ett kretskort, insvept i en kylare med dubbel eller trippel bredd.

Oftare än inte på ett forum kommer folk att fråga “vilken GPU för $xxx” och några av förslagen kommer att vara två GPU:er till halva budgeten, eftersom det vanligtvis erbjuder mer prestanda än en enda GPU om spelet och drivrutinerna alla fungera smidigt (på bekostnad av ström, värme och dåliga förarscenarier). Ekosystemet stöder multi-GPU-inställningar, så jag kände att det var rätt att testa minst en fyrvägsinstallation. Även om med stor kraft följer ett stort ansvar – det var ingen idé att testa 4-vägs 7970s på 1080p.

Vanligtvis i denna prisklass kommer användarna att välja inställningar för flera bildskärmar, i linje med 5760×1080, eller stora skärminställningar som 1440p, 1600p, eller så kan de megarika prova 4K. I slutändan kommer high end-entusiasten, med pengar att bränna, att dras mot 4K, och jag kan inte vänta tills det blir verklighet. Så för en medianpunkt i allt detta testar vi vid 1440p och maximala inställningar. Detta kommer att belasta våra Core 2 Duo- och Celeron G465-prover, men bör vara lätta att välja för vår multi-processor, multi-GPU best av en maskin.

Ett mindre problem med att tolka resultat

Under hela testningen för den här recensionen skulle det helt klart finnas några frågor att ta hänsyn till. Den främsta av dessa är frågan om konsekvens och i synnerhet om något som Metro 2033 bestämmer sig för att ha en “enkel” körning som rapporterar +3% högre än normalt. För det specifika exemplet kommer vi runt detta genom att dubbeltesta, eftersom den lätta körningen vanligtvis visas i den första satsen – så vi kör två eller tre satser om fyra och bortser från den första satsen.

Den andra, kanske större, frågan är att tolka resultaten. Om jag får 40,0 FPS på en Phenom II X4-960T, 40,1 FPS på en i5-2500K och sedan 40,2 FPS på en Phenom II X2-555 BE, gör det resultatet ogiltiga? De viktiga punkterna att känna igen här är statistik och systemtillstånd.

Systemtillstånd: Vi har alla haft tillfällen att starta upp en dator när den känns trög, men detta tröga beteende försvinner vid omstart. Samma sak kan inträffa med testning, och händer vanligtvis som ett resultat av dålig initiering eller en dålig rutin för cacheoptimering vid uppstart. Som ett resultat försöker vi upptäcka dessa omständigheter och köra igen. Med mer tid skulle vi ta 100 olika mätningar av varje benchmark, med omstarter, och stryka ut extremvärdena. Tidsbrist utanför akademin ger oss tyvärr inte denna möjlighet.

Statistik: Bortsett från systemtillstånd kommer värden för bildhastighet ofta att variera runt ett genomsnitt. Detta kommer att innebära (beroende på riktmärket) att resultatet kan bli +/- några procentenheter på varje körning. Så vad händer om du har en körning av fyra tidsdemos, och var och en av dem är +2% över den “genomsnittliga” FPS? Från utsidan, eftersom du inte kommer att veta det verkliga genomsnittet, kan du inte säga om det är giltigt eftersom datamängden är extremt liten. Om vi ​​tar fler körningar kan vi hitta variansen (den tekniska versionen av termen), standardavvikelsen och kanske representera medelvärdet, medianen och moden för en uppsättning resultat.

Som alltid är den huvudsakliga begränsningen i artiklar som dessa tid – ju snabbare att publicera, desto mindre testning, desto större felstaplar och desto större sannolikhet för att vissa resultat kommer att bli sneda eftersom det bara råkade vara bra/dåligt. benchmarkkörning. Så exemplet ovan på att X2-555 får ett bättre resultat beror på tolkning – varje resultat kan vara +/- 0,5 FPS i genomsnitt, och eftersom de alla är ganska lika är vi faktiskt mer GPU-begränsade. Så det är mer om GPU:n har en bra/dålig körning i denna omständighet.

För det här exemplet batchade jag 100 körningar av mitt vanliga WinRAR-test i moderkortstestning, på en i5-2500K CPU med en Maximus V Formula. Resultaten varierade mellan 71 sekunder och 74 sekunder, med en stor gravitation mot den nedre änden. För att representera detta statistiskt använder vi normalt ett histogram, som separerar resultaten i “bins” (t.ex. 71,00 sekunder till 71,25 sekunder) för hur exakt det slutliga resultatet måste vara. Här är en initial representation av data (tid vs. körningsnummer), och några histogram av dessa data, med en lagerstorlek på 1,00 s, 0,75 s, 0,5 s, 0,33 s, 0,25 s och 0,1 s.

När vi kommer ner till de lägre fackstorlekarna finns det ett par stora grupperingar av resultat mellan ~71 sekunder och ~72 sekunder. Det totala genomsnittet/medelvärdet av data är 71,88 på grund av extremvärdena runt 74 sekunder, med medianen på 72,04 sekunder och standardavvikelsen på 0,660. Vad är rätt värde att rapportera? Generellt medelvärde? Topp? Genomsnittlig +/- standardavvikelse? Med resultaten väldigt skeva kring två värden, vad händer om jag kör 1-3 körningar och får ~71 sekunder och ingen runt ~72 sekunder?

Statistik är helt klart ett stort fält, och utan en stor urvalsstorlek kan de flesta siffror vara engångsresultat som inte riktigt reflekterar data. Det är viktigt att fråga dig själv varje gång du läser en recension med ett resultat – hur många datapunkter gick in i det slutliga värdet och vilken analys gjordes?

För den här recensionen tar vi vanligtvis fyra körningar av våra GPU-tester var, förutom Civilization V som är extremt konsekvent +/- 0,1 FPS. Resultatet som rapporteras är genomsnittet av dessa fyra värden, minus eventuella resultat som vi anser är inkonsekventa. Ibland har körningar upprepats för att bekräfta värdet, men detta kommer inte att noteras i resultaten.

Bulldozer Challenge

Ett annat syfte med den här artikeln var att ta itu med problemet kring Bulldozer och dess derivat, såsom Piledriver och därmed alla Trinity APU:er. Arkitekturen är sådan att Windows 7, som standard, inte korrekt tilldelar nya trådar till nya moduler – den “nyinstallerade” hållningen är att dubbla upp trådarna per modul innan du går vidare till nästa. Genom att installera ett par Windows-uppdateringar (som inte visas i Windows Update automatiskt) får vi en effekt som kallas ‘core parking’, som tilldelar den första serien av trådar var och en till sin egen modul, vilket ger den tillgång till ett par INT och en FP-enhet, snarare än att ha par av trådar som konkurrerar om priset. Detta påverkar variabelt gängad belastning mest, särskilt från 2 till 2N-2 trådar där N är antalet moduler i CPU:n (alltså 2 till 6 trådar i en FX-8150). Det borde inte komma som någon överraskning att spel hamnar i denna kategori, så vi vill testa med och utan hela kärnparkeringsfunktionerna i våra benchmarks.

Hinder med NVIDIA och 3-Way SLI på Ivy Bridge

Användare som har hållit sig uppdaterade med moderkortsalternativ på Z77 kommer att förstå att det finns flera sätt att sätta tre PCIe-platser på ett moderkort. Majoriteten av moderkort under $250 kommer att använda tre PCIe-platser i ett PCIe 3.0 x8/x8 + PCIe 2.0 x4-arrangemang (vilket betyder x8/x8 från CPU och x4 från chipset), vilket tillåter antingen tvåvägs SLI eller trevägs Crossfire . Vissa moderkort kommer att använda ett annat Ivy Bridge-filallokeringsalternativ så att vi har en PCIe 3.0 x8/x4/x4-layout, vilket ger trevägs Crossfire men bara tvåvägs SLI. Faktum är att i det här arrangemanget inaktiveras tvåvägs-SLI helt och hållet genom att utrusta den sista x4:an med ett ljud/raid-kort.

Detta beror på ett inte allmänt publicerat krav på SLI – det behöver minst en x8-filallokering för att fungera (antingen PCIe 2.0 eller 3.0). Allt mindre än detta på någon GPU och du kommer att nekas i programvaran. Så att lägga i det tredje kortet kommer att få den andra filen att sjunka till x4, vilket inaktiverar tvåvägs SLI. Det finns moderkort som har en switch för att ändra till x8/x8 + x4 i det här scenariot, men vi är fortfarande begränsade till tvåvägs SLI.

Det enda sättet att gå till 3-vägs eller 4-vägs SLI är via ett PLX 8747-aktiverat moderkort, vilket avsevärt ökar kostnaden för ett moderkortsbygge. Detta bör man ha i åtanke när man hanterar slutresultatet.

Elanvändning

Det har kommit till min kännedom att även om resultaten skulle komma ut X > Y, kan vissa användare säga att den bättre processorn drar mer ström, vilket i slutändan kostar mer pengar om man räknar ihop det över ett år . När det gäller den här recensionen är vi av åsikten att om du spelar på en budget så kommer avancerade GPU:er som de som används här inte att ligga inom din prisklass.

Enkelt roligt spel kan göras på ett system med låg upplösning och begränsad detalj för inte mycket pengar – till exempel på ett nyligen LAN som jag besökte njöt jag av 3-4 timmars TF2-kul på min AMD netbook med integrerad HD3210-grafik, även om jag hade för att installera texturpaketet med ultralåg upplösning och mods för att få 30+ FPS. Men jag hade en fantastisk tid, och därför är skönheten i högupplöst grafik i de större systemen kanske inte oroande så länge bildhastigheterna är bra.

Men vill du ha det bästa så betalar du för det bästa, även om det kommer till elkostnaden. Budgetspel är bra, men den här recensionen är utformad för att fokusera på 1440p med maximala inställningar, vilket inte är ett budgetspelscenario.

Format för denna artikel

På de kommande sidorna kommer jag att gå igenom vår hårdvara i detalj för denna recension, inklusive processorer, moderkort, GPU:er och minne. Sedan kommer vi att gå till de faktiska hårdvaruinställningarna, med CPU-hastigheter och minnestider (med moderkort som faktiskt möjliggör XMP) detaljerade. Viktigt att notera är också moderkorten som används – för fullständighetens skull har jag testat flera processorer i två olika moderkort på grund av GPU-filen.

Vi lever i en tid där PCIe-switchar och ytterligare chips används för att utöka GPU-fillayouter, så mycket att det finns upp till 20 olika konfigurationer för enbart Z77-moderkort. Ibland gör körfältsallokeringen skillnad, och det kan göra stor skillnad med tre eller fler GPU:er (x8/x4/x4 vs. x16/x8/x8 med PLX), även med den extra latens som ibland är förknippad med PCIe-switchar. Våra tester över tid kommer att inkludera majoriteten av PCIe-filallokeringarna på moderna inställningar, men för vår första artikel tittar vi på de viktigaste som vi sannolikt kommer att stöta på.

Resultatsidorna börjar med en grundläggande CPU-analys som går igenom mina vanliga moderkortstester på CPU:n. Detta borde ge oss en känsla för hur mycket kraft varje CPU har när det gäller att hantera matematik och tester i verkligheten, både för heltalsoperationer (viktigt på Bulldozer/Piledriver/Radeon) och flyttalsoperationer (där Intel/NVIDIA verkar prestera bäst).

Vi kommer sedan att gå till var och en av våra fyra speltitlar i tur och ordning, i våra sex olika GPU-konfigurationer. Som nämnts ovan kan det i GPU-begränsade scenarier tyckas konstigt om en CPU under $100 är högre än en norr om $300, men vi hoppas kunna förklara resultatströmmen när vi går.

Jag hoppas att detta kommer att vara ett pågående projekt här på AnandTech, och med tiden kan vi lägga till fler processorer, 4K-testning, kanske till och med visa fyrvägs Titan om det skulle vara tillgängligt för oss. Den enda faran är att vid en förare eller ett spelbyte tar det ytterligare en bit av tid att få data! Alla förslag är naturligtvis mycket uppskattade – skicka ett e-postmeddelande till mig på ian@anandtech.com. Vår nästa anlöpshamn blir med största sannolikhet Haswell, som jag ser mycket fram emot att testa.