Inlägg

Köpte för många år sedan ett nytt Nvidia-kort till min PC. Före det hade jag haft ett Radeon (ATI) kort. Tyckte att Nvidia gav en markant sämre skärpa och även detaljer i spel. Försökte ställa om inställningarna men fick ändå samma resultat. Har läst att andra även haft samma erfarenheter. Vet inte hur det är med dagens Nvidia-kort, men jag har hållit mig fast vid Radeon

Väntar på de bärbara varianterna för att se de i en minipc, skippa stationärt helt och hållet är målet. 😋

Nu tycker jag du skapar förvirring här. Aleshis ursprungliga inlägg svarade på någon som inte förstod hur parallellisering hade med IPC att göra. Aleshi förklarade detta och du svarade med "högre IPC är alltid bättre". Tror inte att Aleshi hävdat något annat, utan förklarar bara varför det är komplext att öka IPC på ett sätt som ger praktisk nytta.

Som en extra nitos från mig: ökad IPC leder till större kretsar, vilket leder till mer strömförbrukning. Designar du en CPU med jättehög teoretisk IPC som i praktiken inte går att amvända så är det enda du har gjort att försämra energieffektiviteten. Så det är inte riktigt så enkelt som att högre teoretisk IPC alltid är bättre.

Ursäkta, men du bemöter inte något jag säger. Du har inte förstått något alls. Om du inte förstått att en kärna har ett flertal beräkningsenheter och att det finns parallelliseringsproblem där så är du inte i en position att kritisera något jag skrivit.
Hade du förstått vad jag skrivit så hade du inte trott att jag inte vetat vad IPC är, Du hade förstått att det finns ett parallelliseringsproblem även inom en tråd i en kärna, och du hade inte försökt förklara att IPC gäller på "EN kärna".

Hög IPC är självklart bra, jag har inte sagt något annat. Det jag pratar om är hur du får en processorkärna att ha hög IPC, och varför det blir svårare och svårare att öka IPC. I en modern X86-processor delas kod upp i µOPs som kan fördelas på flera ALU:er. En del kod kan du lätt dela upp i flera µOPs och fördela på fler ALU:er och du kan hålla dem matade lättare. En del kod kan lättare köras Out-of-Order vilket underlättar mycket också. Medan annan kod är väldigt enkelspårig och behöver resultatet från en tidigare beräkning innan du kan göra nästa beräkning, och du kan svårligen parallellisera upp det till att utnyttja en kärna som är 10 issue wide. Detta är alltså hur parallelliserbar du kan göra en tråd i en kärna.
Detta är alltså inte samma sak som när man pratar antal trådar och antal kärnor. Sedan kan du såklart utnyttja en kärna bättre med fler trådar, allra helst om de har flertrådsteknik som tillåter att du exekverar två trådar samma klockcykel.

<Uppladdad bildlänk>

nja @aleshi har rätt här. IPC på en modern x86 arkitektur innebär att du måste kunna mata alla ALU:s i en kärna med jobb den cyceln för att du ska komma upp i de siffror som presenteras. På simplare CPU:er som 6502 som har en enda ALU så är högre IPC alltid bättre för singeltrådade laster men på moderna arkitekturer är det inte så enkelt längre eftersom en kärna numera innehåller flera exekveringsenheter (ALU:er för heltal).

Zen5 t.ex har 6 ALU:er per kärna mot 4 på Zen4 så om schedulern kan fylla alla 6 med jobb i en cykel så kommer du upp i den IPC som AMD specar, men som någon i tråden redan anmärkte på så finns det gott om laster där man inte ens kan fylla alla 4 i Zen4 (och att så är fallet är ju det som hela biten med HT handlar om eftersom man då kan köra andra trådar i de ALU:s som blir över).

40% finns ju redan, titta på apple och senaste ARM-chippen. Så på en rent teoretisk nivå kanske det kan gå?

I praktiken är det nog snarare specifika tester, någon speciell algoritm med fokus på någon speciell krets som förbättrats, kanske NPU?

Skulle vara kul om det blir något, kanske något för SD2? Zen5 & RDNA5, varför inte?

Delar med lite var jag har snappat upp och tolkat.

Det var tidigt tänkt och planerat att RDNA4 skulle ha mer fokus på chiplets arkitektur, alltså en ännu mer uppdelat variant än den arkitektur vi finner hos RDNA3; Men AMD märkte tidigt att de inte skulle hinna med detta så de senarelade just denna variant till RDNA5 och istället planerade in en RDNA3 liknande variant till RDNA4.
Detta är var jag har snappat upp de senaste 6+ månaderna från diverse ryktesvägar.

En av AMDs ingenjörer nämnde tidigt att de stannade vid runt 80 CU för RDNA2 då det inte kunde skala effektivt till 120 eller 100 för raster-beräkningar.
Vid ett senare tillfälle nämnde en annan ingenjör (eller liknande) att RDNA3 hade tekniskt sätt möjlighet till att gå mycket högre men de stannade vid 96 för de ville hålla sig runt $1000 prisklassen.

Så för RDNA2 var det en tekniskt begränsning att nå högre prestanda medans RDNA3 en ekonomisk begränsning.

Med tanke på rådande kretsbrist, eller kanske rättare sagt rådande "prioritering för AI produktion", så är det klokt att RDNA4 fokuseras på att tillverkas på små kretsytor och med ett liknande paketeringssätt som RDNA3 chiplet arkitektur, där det paketeras flera minnesmoduler (MCD) med en beräkningsmodul (GCD), i olika nod-storlekar.
Detta för att AMD ska kunna få upp antalet kort till marknaden i stort, och främst till den större skaran som är egentligen mer intresserad att handla i mellanklassen, och antar att det skulle hjälpa för att inte tappa kunder till Battle Mage.

Gällande RDNA5, från diverse snack från AMD intervjuer kring arkitekturer på CPU, GPU och AI sidan, samt rykten kring RDNA5 så tolkar jag att utmaningen för den planerade arkitektur som skulle ha varit RDNA4 (som senarelades till RDNA5) har varit att dela upp GCD/beräkningsdelen i ännu fler och mindre moduler.
Anledningen till den stora utmaningen, jämfört med CPU chiplets, så har GPU chiplets stora behov av att överföra stor mängd data på väldigt kort tid, om man vill "chipletifiera" raster.
Det hade krävts enorma mängder "wires", alltså kopplingar, som skulle ta allt för stor plats.

Vad deras lösning för detta skulle vara, den som verkar ta lite extra lång tid, vet jag inte än... men är nyfiken så om någon vet, dela!
Vet i.a.f. på lång sikt att photonics är en potentiell lösning för dataöverföring men idag verkar dessa bara finnas lösningar mellan chips men ej mellan chiplets i respektive chip.

En lösning, gissning från min sida, är att AMD skulle kunna bara skita i att chipletifiera raster och dela upp GCD chipleten (Graphics Compute Die) i princip till 1 fullständig Raster del och ha flera RT delar. RT beräkningar är relativt enkelt att skala med nära 100% effektivitet.
Kanske skulle kunna även plocka ut "Media engine" delen och annat smått från GCD.

Hade dock varit intressant om vi fick se någon eller några extra "AI" chiplets (inference/träning) för att agera som instegskort till deras professionella MI300 serie samt få en större community kring ROCm (AMDs motsvarighet till CUDA).

Själv tycker jag tvärtom att moderna LGA-socklar tål klart mer stryk än vad de äldre socklarna gjorde. Har till och med provat för att de hur mycket stryk de tål och både Intels och AMD:s moderna diton kan hantera mycket innan piggarna böjs.

Jag är väl medveten om att det stavas Thrash, men det står Trash lite överallt i artikeln

Trash? För att det är skräpmat?

Jag tvivlar inte att denna lösning är enkel. Men den lösningen som fanns innan detta var också superenkel (via kabel). Jag testade för några månader sedan med min Google Pixel 7A. Allt jag behövde köra var att koppla telefonen till datorn via USB och sedan välja "Use phone as Webcam" (eller liknande) när prompten dök upp i min telefon. Sedan var det klart (telefonen dyker upp och klassificeras som en webbkamera i device manager som vilken annan webbkamera som helst).