AMD avtäcker Ryzen 7000X3D-trio – 144 MB 3D V-Cache och 16 kärnor

Och här är en till som köpte en 7700x som place holder. Trodde inte AMD skulle vara så snabba med x3d men jag tänker inte klaga

Intressant, det blir assymetriskt med L3 på 7900X3D och 7950X3D, eXtra 64MB läggs bara på ena CCD:n.
Kan tänka mig att det tar några månader innan Windows fattar vilka trådar som ska läggas på vilken CCD.
Hoppas AMD slipar till en passande sceduler till Linux i närtid.

Det blir att vänta på tester som vanligt.

Substantivet "budget" fungerar som du beskriver.
Adjektivet "budget" betyder billig.

Intressant, det blir assymetriskt med L3 på 7900X3D och 7950X3D, eXtra 64MB läggs bara på ena CCD:n.
Kan tänka mig att det tar några månader innan Windows fattar vilka trådar som ska läggas på vilken CCD.
Hoppas AMD slipar till en passande sceduler till Linux i närtid.

Det blir att vänta på tester som vanligt.

IHS som verkligen saboterar potentialen till en snabb sval processor som ändå finns i kislet. Grafikkorten levererar inte alls det AMD utlovat

Läste du inte artikeln? 128MB står det för dual-CCD dvs 2x64MB ....

Dessa nya har lägre TDP, något måste man väl ha gjort för att kunna sänka det i dessa 3D varianter?

Flera saker pekar faktiskt på att det handlar om en asymmetrisk design.

Först denna bild
https://images.anandtech.com/doci/18709/7000X3D-Render-1_crop_678x452.jpg
bara den vänstra CCD som är täckt med extra lager kisel.

Sedan är tydligen en utmaning med hur "3D-cachen" fäster till underliggande krets, enda som håller fast den är Van der Walls-krafter vilket ska vara orsaken till att man inte kan fläska på hur som helst med effekt, då kan 3D-cachen släppa.

7000-serien skruvade ju upp effekten rejält jämfört med 5000-serien. Vi ser ju också att 7800X3D har en större minskning i peak-frekvens mot 7700X, den senare har 8 % högre frekvens, mot 5800X3D vd 5800X där den senare bara har 4 % högre frekvens.

Finns inte jättemånga enkla förklaringen till varför man måste sänka peak-frekvens på 7800X3D medan man inte behöver göra det på 7900X3D/7950X3D mer än att de senare bara har den högre frekvensen på CCD utan 3D-cache.

Problemet här är: hur ska ett OS, eller ens konstruktören av program, veta om en viss tråd bäst kör med lite lägre frekvens och mer cache eller med högre frekvens?

Linux har inget som hanterar detta. Linux schemaläggare kommer explicit att sprida last jämnt mellan CCD:er, något som inte är optimalt för alla fall (spel är ett exempel där det ofta är bättre att hållas sig på en CCD) men det är typiskt optimalt för CPU-tunga fall.

Windows har ju haft svårt ens hantera "big/little", där finns ändå en rätt uppenbar optimal placering av trådar. Problemet både Windows och även Linux har är att det inte finns något superbra sätt för programmerare att ge "hints" om vilken typ av last en viss CPU-tråd har. Bara MacOS/iOS som har det av de "stora" OS:en (och haft det över ett decennium).

Men även utan detta finns en relativt enkel heuristik: använd "big/little" som en form av SMT. Lägg först last på ena tråden på "stora" kärnan, lägg sedan last på de "små" kärnorna, i sista hand lägger man last på "andra" tråden på "stora" kärnan. Efter lite pyssel är det exakt så Win11 fungerar.

Best-performance vs balanced-performance styr sedan om bakgrundlaster ska hanteras på samma sätt som förgrundslaster (best-performance) eller om bakgrundslaster i första hand skickas till de "små" kärnorna (balanced performance).

Men om nu 7900X3D/7950X3D är asymmetriska på det sätt som föreslås: finns ju ingen enkel rimlig automatisk uppdelning och är väldigt svårt att placera saker rätt ens om man explicit styr som programutvecklare!

Lite väl strypt turbofrekvens på 7800X3D när modellen under 7700X har högre.

Flera saker pekar faktiskt på att det handlar om en asymmetrisk design.

Först denna bild
https://images.anandtech.com/doci/18709/7000X3D-Render-1_crop_678x452.jpg
bara den vänstra CCD som är täckt med extra lager kisel.

Sedan är tydligen en utmaning med hur "3D-cachen" fäster till underliggande krets, enda som håller fast den är Van der Walls-krafter vilket ska vara orsaken till att man inte kan fläska på hur som helst med effekt, då kan 3D-cachen släppa.

7000-serien skruvade ju upp effekten rejält jämfört med 5000-serien. Vi ser ju också att 7800X3D har en större minskning i peak-frekvens mot 7700X, den senare har 8 % högre frekvens, mot 5800X3D vd 5800X där den senare bara har 4 % högre frekvens.

Finns inte jättemånga enkla förklaringen till varför man måste sänka peak-frekvens på 7800X3D medan man inte behöver göra det på 7900X3D/7950X3D mer än att de senare bara har den högre frekvensen på CCD utan 3D-cache.

Problemet här är: hur ska ett OS, eller ens konstruktören av program, veta om en viss tråd bäst kör med lite lägre frekvens och mer cache eller med högre frekvens?

Linux har inget som hanterar detta. Linux schemaläggare kommer explicit att sprida last jämnt mellan CCD:er, något som inte är optimalt för alla fall (spel är ett exempel där det ofta är bättre att hållas sig på en CCD) men det är typiskt optimalt för CPU-tunga fall.

Windows har ju haft svårt ens hantera "big/little", där finns ändå en rätt uppenbar optimal placering av trådar. Problemet både Windows och även Linux har är att det inte finns något superbra sätt för programmerare att ge "hints" om vilken typ av last en viss CPU-tråd har. Bara MacOS/iOS som har det av de "stora" OS:en (och haft det över ett decennium).

Men även utan detta finns en relativt enkel heuristik: använd "big/little" som en form av SMT. Lägg först last på ena tråden på "stora" kärnan, lägg sedan last på de "små" kärnorna, i sista hand lägger man last på "andra" tråden på "stora" kärnan. Efter lite pyssel är det exakt så Win11 fungerar.

Best-performance vs balanced-performance styr sedan om bakgrundlaster ska hanteras på samma sätt som förgrundslaster (best-performance) eller om bakgrundslaster i första hand skickas till de "små" kärnorna (balanced performance).

Men om nu 7900X3D/7950X3D är asymmetriska på det sätt som föreslås: finns ju ingen enkel rimlig automatisk uppdelning och är väldigt svårt att placera saker rätt ens om man explicit styr som programutvecklare!

Flera saker pekar faktiskt på att det handlar om en asymmetrisk design.

Först denna bild
https://images.anandtech.com/doci/18709/7000X3D-Render-1_crop_678x452.jpg
bara den vänstra CCD som är täckt med extra lager kisel.

Sedan är tydligen en utmaning med hur "3D-cachen" fäster till underliggande krets, enda som håller fast den är Van der Walls-krafter vilket ska vara orsaken till att man inte kan fläska på hur som helst med effekt, då kan 3D-cachen släppa.

7000-serien skruvade ju upp effekten rejält jämfört med 5000-serien. Vi ser ju också att 7800X3D har en större minskning i peak-frekvens mot 7700X, den senare har 8 % högre frekvens, mot 5800X3D vd 5800X där den senare bara har 4 % högre frekvens.

Finns inte jättemånga enkla förklaringen till varför man måste sänka peak-frekvens på 7800X3D medan man inte behöver göra det på 7900X3D/7950X3D mer än att de senare bara har den högre frekvensen på CCD utan 3D-cache.

Problemet här är: hur ska ett OS, eller ens konstruktören av program, veta om en viss tråd bäst kör med lite lägre frekvens och mer cache eller med högre frekvens?

Linux har inget som hanterar detta. Linux schemaläggare kommer explicit att sprida last jämnt mellan CCD:er, något som inte är optimalt för alla fall (spel är ett exempel där det ofta är bättre att hållas sig på en CCD) men det är typiskt optimalt för CPU-tunga fall.

Windows har ju haft svårt ens hantera "big/little", där finns ändå en rätt uppenbar optimal placering av trådar. Problemet både Windows och även Linux har är att det inte finns något superbra sätt för programmerare att ge "hints" om vilken typ av last en viss CPU-tråd har. Bara MacOS/iOS som har det av de "stora" OS:en (och haft det över ett decennium).

Men även utan detta finns en relativt enkel heuristik: använd "big/little" som en form av SMT. Lägg först last på ena tråden på "stora" kärnan, lägg sedan last på de "små" kärnorna, i sista hand lägger man last på "andra" tråden på "stora" kärnan. Efter lite pyssel är det exakt så Win11 fungerar.

Best-performance vs balanced-performance styr sedan om bakgrundlaster ska hanteras på samma sätt som förgrundslaster (best-performance) eller om bakgrundslaster i första hand skickas till de "små" kärnorna (balanced performance).

Men om nu 7900X3D/7950X3D är asymmetriska på det sätt som föreslås: finns ju ingen enkel rimlig automatisk uppdelning och är väldigt svårt att placera saker rätt ens om man explicit styr som programutvecklare!

Vi får förstås facit snart, men är det inte rimligt att tänka sig att prestandavinsterna i denna generation blir mindre än i första generationens X3D? Jag menar, nu har även en vanlig 7900X 64 MB L3, vilket inte är sååå långt från vad en 5800X3D har. Det är klart det blir bättre med 128 MB, men kanske inte chockerande mycket bättre. Jo jag vet vad AMD påstår men jag inväntar helst mer oberoende tester.

Det hindrar mig absolut inte från att vara svårt sugen, särskilt med tanke på hur bra 5800X3D tydligen presterar i MSFS.

Då det mest intressanta om asymmetrisk eller symmetrisk cache design redan tagits upp undrar jag egentligen bara varför 7800X3D har en så hög TDP. Om vi antar liknande max PPT (~1,35xTDP) i relation till 105W varianterna borde PPT hamna på typ 162W. Tvivlar på att en 7800X3D kommer upp i så hög effekt vid 5.0GHz, dock kanske i vissa fall om den faktiska max boosten ligger runt 5.1GHz på alla kärnor. Men med tanke på hur små dessa chiplets är där det nu också ligger ett extra cache-lager ovanpå så borde det vara helt omöjligt att kyla om 162W faktiskt kan nås.

120W TDP för 79XXX3D låter dock vettigt, 170W för non-X3D modellerna var redan för mycket.

Bl.a. hardware unboxed spekulerar i att det kan vara på det sättet. Vad jag vet har inte AMD sagt någon om det.

Men bilden jag postade ovan, att bara 7800X3D har en lägre peak-frekvens samt att totala mängden cache i 2 CCD-modellerna inte är den man förväntar sig om båda CCD har 3D-cache är väl det som pekar på att HUBs spekulation kanske inte är helt ute i spenaten.