AMD Kaveri får minneskontroller för GDDR5

Låter som en trevlig produkt!

Låter som vänlig typ

De märks att AMD ändrat sin strategi. Istället för att försöka konkurrera med bäst prestanda siktar dem in sig på en kostnadseffektiv men kapabel helhetslösning.

en laptop med delat gddr5 vore ju faktiskt trevligt, då gör det ju inte så mycket om processorn är fastlödd. kanske att man får avstå från ram-uppgraderingar dock... men med tanke på vilka prestandavinster trinity gav med snabbare minne så är jag positiv länk för er som inte kommer ihåg

Allting pekar på att det går mot en minneskontroller istället för två.

Det gäller att hålla isär lite av varje här, det finns flera olika sätt att dela på minnet.

En traditionell lösning är att grafikkortet mappar upp en del av ramminnet och processorn en annan. mig veterlligen är det så här intels nuvarande lösning ser ut.

Vad AMD jobbat på under en lång tid är att grafikkortet ska kunna dela minnesrymd med processorn, man blir alltså av med problem som att en bit av minnet är låst. Man ger också möjlighet för grafikdelen att kunna jobba mot samma minnesrymd som processorn i GPGPU-applikationer.
Tidigare har processorn fått mata grafikkortet med minne i GPGPU-applikationer, något som varit väldigt långsamt. Jag tror också de satsar på att få cachen delad mellan GPU och CPU.

Trinity och framåt har också en smart minneskontroller, den fugerar som en router och har prioriteringsfunktionalitet. Exempelvis kan den begära att minne till grafikberäkningar får högre prioritet än minne till CPU-beräkningar, detta för att få upp framerate i 3D-spel.

Med tanke på allt AMD gör känns ytterligare en minneskontroller inte särskilt troligt. De jobbar hårt för att öka prestandan i kombinerade lösningar, både i effektivitet och bandbredd.

Det sitter en helt annan minneskontroller i GTX Titan än i AMDs processor, så begränsningen skulle kunna ligga där. Begränsningen kan också vara i chipstorlek på minnena, i så fall kan man se att AMD har 128bitar och Titan har 384bitar. Med andra ord borde Titan kunna ansluta 3x fler minnen av maxstorlek om det vore fallet.

Fast att de delar adressrymd löser inte det stora problemet som är relaterat till bandbredd. Det är ju det som sätter käppar i hjulet för prestandan. Att man låser minne är ju mer ett irritationsmoment som inte har samma prestandaproblem. Så visst blir livet lättare med delat adressutrymme men det gör ju inte att bandbreddsbegränsningen försvinner tyvärr. Så det krävs att de jobbar med hastigheten också. Fast det kanske löser sig självt när DDR4 kommer då jag vill minnas att det skulle ge en dubbling i hastighet mot DDR3 ungefär. Det i kombination med en större cache som minskar behovet av att läsa från det sammanhanget långsamma RAM kan också få lite fart på grejerna. Har ett svagt minne av att Intel tänkte slänga in 32 MB på grafikdelen.

Ja AMDs dröm är att lägga in CPU och GPU under samma L3 eller L2. Då blir det intressant och vi får en APU på riktigt. Tänk vilken prestanda man kan få ut av en sådan enhet med rätt skriven kod och en bra scheduler. Det är väl ungefär där som konceptet med kärnor kommer suddas ut helt då AMD antagligen kommer slänga in en enda stor gröt av heltalskluster, FPU och streamprocessorer.

I alla lösningar som har "delat minne" kan CPUn direkt komma åt allt RAM, däremot är (alltid?) bara delar av RAM åtkomligt för GPUn. Detta gäller både AMDs nuvarande APUer och Intels HD-serie. Men till skillnad mot AMD så kan HD2000 och senare använda CPUns L3-cache som cache även för GPUn, problemet är väl att 3MB-8MB (som är storleken på Corei3 till Corei7) inte är speciellt mycket + att GPUn konkurrerar med CPUn om L3-cachen. En av de rykten jag sett kring framtida APUer är att de också kommer kunna använda L3-cachen som GPU-cache, L1/L2 cachen är en integrerad del av CPU-kärnan både på Bulldozer och senare samt på Nehalem och senare så den lär aldrig delas med GPUn.

Som redan länkats ovan så är det ju uppenbart att GPU-delen i AMDs APUer kraftigt begränsas av bandbredd mot RAM, så det är den flaskhals man måste lösa. Att använda GDDR5 är definitivt en lösning som kommer ge en rejäl knuff för GPUn, frågan är bara hur negativt det blir för CPU-delen då GDDR5 har mycket högre latens jämfört med DDR3. För många applikationer (typ spel) kommer det antagligen inte vara något problem då "working-set" är relativt litet i spel + att man av prestandahänseende optimerar sin kod att så långt som möjligt köras ur CPU-cache (som inte påverkas negativt på något sätt av GDDR5).

Intel har ju också börjat få bandbreddsproblem i.o.m att HD4000 har rätt OK prestanda och L3-cachen kommer man inte långt med. Deras lösning för Haswell verkar bli att den snabbaste versionen, GT3, kommer ha "embedded DRAM" (ryktena säger någonstans mellan 64M till 256M, 256M låter mycket då eDRAM tar massor med transistorer). Nackdelen är uppenbar: man kan inte ha speciellt mycket eDRAM, fördelen är att bandbredden på eDRAM enkelt kan överstiga även den i de snabbaste diskreta GPUerna som använder GDDR5 RAM. Att FSAA är nära nog "gratis" på Xbox360 beror just på att den har 10MB eDRAM så operationer som helt kan utföras i eDRAM blir extremt snabba.

Vad det gäller prioritering på minnesbussen så har AMD mycket riktigt prioritet GPUn över CPUn, fördelen är ju uppenbar: mer bandbredd till GPUn. Nackdelen är att CPU-prestanda sjunker om GPUn har mycket att göra. Intel har också prioritering, men den är att varje "del" får lika stor access till den ring-buffer som kopplar ihop L3-cache, RAM, CPU-kärnorna och GPUn. Så effekten blir i praktiken att CPU-delen har högre prio än GPUn då det är 2 eller 4 CPU-kärnor där varje har en egen ingång till ringen och GPUn har också en ingång.

Lite OT kring HSA.

Har bara hört talas om HSA från marknadsmaterial och liknande så hade bara en väldigt översiktligt bild kring vad det innebär, men hittade detta dokument hos AMD som ganska detaljerat beskriver vad HSA innebär. Kräver att man förstår en del kring hur MMU (Memory Management Unit), cache-consistency, problemen kring atomära operationer och hur moderna OS skyddar program från varandra för att man ska greppa allt, men det var en väldigt bra beskrivning.

Ska man göra en enormt förenklad beskrivning av den stora skillnaden mellan vad vi har idag och vad HSA kommer erbjuda så kan man nämna att idag krävs det att alla beräkningar som ska läggas ut på GPUn och att alla resultat som kommer från GPUn går via OS-kärnan då det minne som GPUn använder endera är dedikerat GPU-minne eller delas med CPUn fast det som GPUn har skrivit hamnar i RAM och CPUn kan ha den regionen i cache vilket betyder innehåll i CPU-cache != RAM -> blir fel om inte någon (OS:et i dag) ser till att CPUn slänger bort sitt cachade värde och läser från RAM igen.

Idag har GPUn i de flesta fall inte en egen MMU (IOMMU), något som är krav i HSA. Utan IOMMU kan man inte på något säkert sätt göra GPUn direkt åtkomlig för program, något som leder till att det krävs OS-anrop för att göra något överhuvudtaget mot GPUn. Med en IOMMU kan man göra specifika delar av GPUn åtkommlig för specifika program, vilket leder till att man kan skicka och ta-emot information från GPUn utan att gå via OS-kärnan -> mycket mindre latens för att skicka / ta-emot data till/från GPUn från/till CPUn.

Så visst kommer HSA att öka mängden saker som är rimliga att lägga ut på GPUn.

Men... Hittade en sak som kan sätta rejäla käppar i hjulet för HSA.

Från AMDs dokument om HSA
3.3.3. Memory Consistency across Multiple Work-Items
The consistency model across work-items in the same work-group, or work-items across work-groups,
follows a “relaxed consistency model”: from the viewpoint of the threads running on different compute
units, memory operations can be reordered.
• Loads can be reordered after loads.
• Loads can be reordered after stores.
• Stores can be reordered after stores.
• Stores can be reordered after loads.
• Atomics can be reordered with loads.
• Atomics can be reordered with stores

De som känner till vad "memory consistency modell" är (gissar att rätt få känner till det, det är ett relativt avancerat begrepp som även de flesta programmerare inte känner till) borde rätt snabbt inse att detta inte är bra. Detta är vad Herb Sutter, ordförande för ISO-kommittén för C++ och tekniskt ansvarig för Microsoft C++ kompilator tycker om "relaxed consistency model" (vilket är det som relaxed atomics ger)

The unspeakables: I'll grudgingly and reluctantly talk about the Thing I Said I'd Never Teach That Programmers Should Never Need To Now: relaxed atomics. Don't use them! If you can avoid it. But here's what you need to know, even though it would be nice if you didn't need to know it.

Anledningen till att han stark avråder från att någonsin använda "relaxed consistency model" är att parallell-programmering är svårt nog i s.k. "sequentual constency model" (det normal i C++ och Java) och går man till "relaxed consistency model" är det i praktiken helt omöjligt att formellt bevisa att programmet är korrekt. Varför skulle folk vilja programmera i en modell som ger snabba program, men där man inte kan garantera (rent formellt) att resultatet är rätt?

Är problemet helt separat och s.k. "embarrassingly parallel" (vilket grafikrenderering är och vilket är orsaken till att designerna av HSA inser att prestanda blir uselt om man kräver "sequentual constency model") så blir det korrekt då man inte kan göra fel. Men poängen med HSA är att även kunna göra saker som inte är "embarrassingly parallel".

Well, wall-of-text. Men undrar hur väl HSA kommer lyckas. nVidia och Intel verkar ju inte med på tåget och det förvårar ju ytterligare.

Har en känsla att framtida spel kommer bli riktigt bra optimerade för samtliga platformar nu när det skiljer mindre.