Ryzen Owners Zen Garden

[Belfaborac]

Are those timings set by EXPO/XMP? They seems awfully loose, more so than anything I think I've seen. Not saying it matters given they're the same between tests, just wondering.

 

[AusWolf]

Fclk: 2133 = 118.5 ns (Memory read and write tanked massively here)
Fclk: 2066 = 72.9 ns
Fclk: 2033 = 71.8 ns
Fclk: 2000 = 72 ns
Fclk: 1800 =72.7 ns

Call me blind, but apart from 2133 (which is weird), these all seem to be within margin of error to me.

I'm only talking about turning things down to stay within your refresh rate, 60Hz users wont have to do anything here, but 144 and up definitely will, no matter the harwdare.

My refresh rate range is 48-144 Hz thanks to VRR, any FPS within this is fine to me.

Edit: Even a lower FPS is doable thanks to the monitor's LFC (low framerate compensation). I don't play competitively, so as long as my gameplay is smooth, I don't care how smooth.

 

[Mussels]

TL;DR: Synced M/U/F values are critical below 2000, but the values are off above 2000. Those values are possibly inaccurate.
I'll test if this is related to Uclk being halved or not, at some point.


Unrelated: My notes had a lot of "FU" and "MF" in there, and as shorthand for swearing I laughed at my notes a lot.
In none of this testing did the motherboard take more than 20 seconds to POST and reach windows. None. The only slow boots were failed ones that reset to JEDEC.

Uclock is halved, so it's running
3600/xxxx/1800

1800: 66.2ns
2000: 67.2ns
2033: 67.7ns
2066: 65.8ns Suddenly faster
2100: 66.6ns (Almost back to 1800 speeds)
2133: 86.7ns
2166: failed to load windows
2200: Needed CMOS cleared


Due to this RAM matching up to 1800, we've got a 200MHz chunk we can't test.
2033 isn't the magic value here, unlike with DDR5 6000 testing.

If only we had values between 1800 and 2000, I believe this is why people have conflicting results - change the RAM speed even slightly, and you need a different Fclk value that may not even be user accessible. 1800x3 is 5400, the stock maximum for these CPUs with 6000 being the sweet spot and nothing in between - leaving a 600MT/s gap that may always be out of sync.

6200 would want 3100/2066/2066

7000MT/s = 3500/1750/1750, lower than the stock 1800MHz IF
7200MT/s = 3600/1800/1800
7400MT/s = 3700/ 1850/1850 *BUH-BOH* - there is no 1850 option!
7600MT/s = 3800/1900/1900 - Maybe 2000 is close enough to be low latency
7800MT/s = 3900/1950/1950 -

All the way to 8000 where its back in sync again. It makes sense 7600-7800 works with a tiny latency hit, but those missing values between 1800 and 2000 screw with us in that speed range.

Following this theory, I tested DDR5 7000 since it has a 'perfect' 1750MHz option available to sync U and F.


DDR5 7000 testing:
3500/2000/1750: 70.5ns (-3.3ns vs 7200)
3500/1800/1750: Failed to post. This may be important, if 'memory holes' exist for Infinity fabric.
3500/1760/1750: 71.4 ns
3500/1750/1750: 68ns - this matches what you'd expect from dropping 100 MHz / 200 MT/s off the ram.
3500/1733/1750: 71.5ns

Even 16MHz below or 10Mhz above has a loss. The 2000+ values are the only exception to the sync rules, which makes me wonder if the values are even accurate after 1800.

IF frequency observations: Typed them all out for you. This was annoying, there is no logic to these values.

100, 200, 400, 500, 800, 933
1100, 1120, 1143, 1200, 1250, 1257, 1280
1300 - 1320 -1333 -1371 - 1400 -1440 -1467 -1485
1500 -1560 - 1600 - 1650 - 1680 - 1733 - 1750 - 1760 - 1800
2000, 2033, 2066, 2100, 2133, 2167, 2200, 2233

After 1800 they lose many of the unusual values, but that doesnt mean internally they're exactly what we see, either.
I see no obvious patterns to this with multipliers and dividers but there has to be some meaning to it all, or why would AMD even include options as low as 100MHz?



I copy pasted the fastest results from each set to look for a mathematical link

Ram speed in MT/s divided by IF, gives the following

3600/1800/1800: 66.2ns (2x)
3600/2000/1800: 67.2ns (3.6x)
3600/2033/1800: 67.7ns (3.54x)
3600/2066/1800: 65.8ns Suddenly faster 3.48x
3600/2100/1800: 66.6ns (3.42x)


Note how 3.48x is faster than 3.54x
That small difference from the perfect divider is enough to throw the results out.

Interestingly 5600MT/s does NOT math neatly here, explaining why 6000 with sub-optimal choices can still outperform it.
5600MT/s aka 2800MHz

/2 is 1400
/1.75 is 1600
/ 1.5 is 1866
/1.25 = 2240
This explains why 1800 and 2000 are fairly similar, since the stock ratio does not fit 5600.

Starting with what I've theorised:
5600MT/s (2800MHz) divided by 3.5x would be 1600
Starting with a bad value of 2000

Same ram at CL34, fairly poor timings for these speeds hence the poopy values.

2800/2000/2800: 76ns
2800/2000/1400: 79.6ns
a ~4ns loss from halving uclk is worth knowing, it's not worth halving it for a small gain in ram speed - but a few hundred MHz would be.


2800/1400/2800: 81.7ns (2ns slower, from a 600MHz drop? Yeah, being in sync matters)
2800/1600/2800: 76.6ns (Very very close to the 2000MHz IF above)

 

[AusWolf]

TL;DR: Synced M/U/F values are critical below 2000, but the values are off above 2000. Those values are possibly inaccurate.
I'll test if this is related to Uclk being halved or not, at some point.


Unrelated: My notes had a lot of "FU" and "MF" in there, and as shorthand for swearing I laughed at my notes a lot.
In none of this testing did the motherboard take more than 20 seconds to POST and reach windows. None. The only slow boots were failed ones that reset to JEDEC.

Uclock is halved, so it's running
3600/xxxx/1800

1800: 66.2ns
2000: 67.2ns
2033: 67.7ns
2066: 65.8ns Suddenly faster
2100: 66.6ns (Almost back to 1800 speeds)
2133: 86.7ns
2166: failed to load windows
2200: Needed CMOS cleared


Due to this RAM matching up to 1800, we've got a 200MHz chunk we can't test.
2033 isn't the magic value here, unlike with DDR5 6000 testing.


View attachment 319459View attachment 319460
View attachment 319461
View attachment 319462View attachment 319463


If only we had values between 1800 and 2000, I believe this is why people have conflicting results - change the RAM speed even slightly, and you need a different Fclk value that may not even be user accessible. 1800x3 is 5400, the stock maximum for these CPUs with 6000 being the sweet spot and nothing in between - leaving a 600MT/s gap that may always be out of sync.

6200 would want 3100/2066/2066


View attachment 319464View attachment 319465


7000MT/s = 3500/1750/1750, lower than the stock 1800MHz IF
7200MT/s = 3600/1800/1800
7400MT/s = 3700/ 1850/1850 *BUH-BOH* - there is no 1850 option!
7600MT/s = 3800/1900/1900 - Maybe 2000 is close enough to be low latency
7800MT/s = 3900/1950/1950 -

All the way to 8000 where its back in sync again. It makes sense 7600-7800 works with a tiny latency hit, but those missing values between 1800 and 2000 screw with us in that speed range.

Following this theory, I tested DDR5 7000 since it has a 'perfect' 1750MHz option available to sync U and F.


DDR5 7000 testing:
3500/2000/1750: 70.5ns (-3.3ns vs 7200)
3500/1800/1750: Failed to post. This may be important, if 'memory holes' exist for Infinity fabric.
3500/1760/1750: 71.4 ns
3500/1750/1750: 68ns - this matches what you'd expect from dropping 100 MHz / 200 MT/s off the ram.
3500/1733/1750: 71.5ns

Even 16MHz below or 10Mhz above has a loss. The 2000+ values are the only exception to the sync rules, which makes me wonder if the values are even accurate after 1800.
View attachment 319466View attachment 319467View attachment 319468View attachment 319469



IF frequency observations: Typed them all out for you. This was annoying, there is no logic to these values.

100, 200, 400, 500, 800, 933
1100, 1120, 1143, 1200, 1250, 1257, 1280
1300 - 1320 -1333 -1371 - 1400 -1440 -1467 -1485
1500 -1560 - 1600 - 1650 - 1680 - 1733 - 1750 - 1760 - 1800
2000, 2033, 2066, 2100, 2133, 2167, 2200, 2233

After 1800 they lose many of the unusual values, but that doesnt mean internally they're exactly what we see, either.
I see no obvious patterns to this with multipliers and dividers but there has to be some meaning to it all, or why would AMD even include options as low as 100MHz?



I copy pasted the fastest results from each set to look for a mathematical link

Ram speed in MT/s divided by IF, gives the following

3600/1800/1800: 66.2ns (2x)
3600/2000/1800: 67.2ns (3.6x)
3600/2033/1800: 67.7ns (3.54x)
3600/2066/1800: 65.8ns Suddenly faster 3.48x
3600/2100/1800: 66.6ns (3.42x)


Note how 3.48x is faster than 3.54x
That small difference from the perfect divider is enough to throw the results out.

Interestingly 5600MT/s does NOT math neatly here, explaining why 6000 with sub-optimal choices can still outperform it.
5600MT/s aka 2800MHz

/2 is 1400
/1.75 is 1600
/ 1.5 is 1866
/1.25 = 2240
This explains why 1800 and 2000 are fairly similar, since the stock ratio does not fit 5600.

Starting with what I've theorised:
5600MT/s (2800MHz) divided by 3.5x would be 1600
Starting with a bad value of 2000

Same ram at CL34, fairly poor timings for these speeds hence the poopy values.

2800/2000/2800: 76ns
2800/2000/1400: 79.6ns
a ~4ns loss from halving uclk is worth knowing, it's not worth halving it for a small gain in ram speed - but a few hundred MHz would be.


2800/1400/2800: 81.7ns (2ns slower, from a 600MHz drop? Yeah, being in sync matters)
2800/1600/2800: 76.6ns (Very very close to the 2000MHz IF above)

The values that didn't error out still seem to be mostly within margin of error to me.

It's an incredible amount of testing, though, so cheers for that!

 

[Mussels]

Call me blind, but apart from 2133 (which is weird), these all seem to be within margin of error to me.


My refresh rate range is 48-144 Hz thanks to VRR, any FPS within this is fine to me.

Edit: Even a lower FPS is doable thanks to the monitor's LFC (low framerate compensation). I don't play competitively, so as long as my gameplay is smooth, I don't care how smooth.

LFC has issues depending on the display
VA panels flicker, and you get doubled (or worse) input latency depending on the method used. My 165Hz VA panel here is atrocious when LFC kicks in under 48FPS, like playing in mud. Above 48, things are entirely different.
That's pretty much the origin of the "fake frames" in the new DLSS tech, just DLSS smearing those fake and real frames together.
48FPS would be doubled with fake frames at the monitor level, while 49 would run within the V-blanking limits of the full refresh rate (lower input latency since its polled a full render cycle later)

All those samsung 240Hz displays? All VA with massive flicker issues and latency problems, Rtings has some information on this yet somehow loves them and praises them anyway.
They (and not just samsung, many brands) have low latency with the LFC/VRR tech off but with tearing and smearing - but fix the quality and you get those back. Fast or quality - They can do both, but not at the same time and that's sadly common for a LOT of expensive displays these days since they pass reviews under the guise of 'let the user pick the one they want'


As for the margin of error: Yes, many are similar.
Post 2 was proving how that applies to various speeds to prove its reproducible.

There is one sweet spot (the mathematically perfect 0.25x values) and 'close enough' values that are definitely close enough.
Then you can go 33Mhz too far and things go to utter shit, and thats why knowing the right value to aim for is important.



Oh and i'm quite sure the reason some of the higher end values don't math perfectly is spread spectrum mixed with the values being rounded up/down. (266.66 recurring could be shown as 266 or 267, etc)
When 10Mhz can make such a big difference, I can totally see 2MHz being the difference between 2033 or 2066 being the ideal value, if the hardware actually wanted 2050 as the sweet spot.



Edit: This is going to be my "TL;DR" on the subject
Higher can be better, but it can also be so much worse. Get the highest value you can in the happy range.


Do not blindly max out infinity fabric.
2000 may be within margin of error of lower speeds, without needing high SoC voltages and without slow-boot issues on weaker boards/CPUs.

When 1800 is faster than 2067 and 2133 - and my god was 2133 extremely bad, pushing people for 2000 is not necessary.
1800 doesn't have the slow boot issues, we need to stop the narrative that maxing out IF (FCLK) is the best choice

 

[AusWolf]

LFC has issues depending on the display
VA panels flicker, and you get doubled (or worse) input latency depending on the method used. My 165Hz VA panel here is atrocious when LFC kicks in under 48FPS, like playing in mud. Above 48, things are entirely different.
That's pretty much the origin of the "fake frames" in the new DLSS tech, just DLSS smearing those fake and real frames together.
48FPS would be doubled with fake frames at the monitor level, while 49 would run within the V-blanking limits of the full refresh rate (lower input latency since its polled a full render cycle later)

Good point, LFC isn't ideal in many cases. Another option is disabling VRR for games that bounce above and below the LFC limit, or changing graphics settings a bit.

My point is that having a constant 144 FPS isn't a must, at least for me. I'm currently playing Kingdom Come: Deliverance which runs at around 60-100 FPS depending on the area, and it feels totally fine to me.

All those samsung 240Hz displays? All VA with massive flicker issues and latency problems, Rtings has some information on this yet somehow loves them and praises them anyway.
They (and not just samsung, many brands) have low latency with the LFC/VRR tech off but with tearing and smearing - but fix the quality and you get those back. Fast or quality - They can do both, but not at the same time and that's sadly common for a LOT of expensive displays these days since they pass reviews under the guise of 'let the user pick the one they want'

Reviews don't even mention LFC flicker for some reason. I didn't even know it existed until I saw it on my Dell. If I did know about it, I'm not sure I would have still bought it, but now that I did, I'll just try to minimise it. The monitor is too good otherwise to send it back.

As for the margin of error: Yes, many are similar.
Post 2 was proving how that applies to various speeds to prove its reproducible.

There is one sweet spot (the mathematically perfect 0.25x values) and 'close enough' values that are definitely close enough.
Then you can go 33Mhz too far and things go to utter shit, and thats why knowing the right value to aim for is important.



Oh and i'm quite sure the reason some of the higher end values don't math perfectly is spread spectrum mixed with the values being rounded up/down. (266.66 recurring could be shown as 266 or 267, etc)
When 10Mhz can make such a big difference, I can totally see 2MHz being the difference between 2033 or 2066 being the ideal value, if the hardware actually wanted 2050 as the sweet spot.



Edit: This is going to be my "TL;DR" on the subject
Higher can be better, but it can also be so much worse. Get the highest value you can in the happy range.

My TL,DR is that it's not worth tinkering with something that gives results within margin of error. It's still interesting to see it in action, so thanks for that!

 

[Mussels]

Are those timings set by EXPO/XMP? They seems awfully loose, more so than anything I think I've seen. Not saying it matters given they're the same between tests, just wondering.

They're XMP for 7200
I kept them the same for every test so we'd know if something unexpected happened

My TL,DR is that it's not worth tinkering with something that gives results within margin of error. It's still interesting to see it in action, so thanks for that!

If you had the 100ns+ result out of the box on a kit of DDR5 5600, you'd care. Same if you had the extremely long boot times those same users have.
Checking a few threads here and on reddit, the issues i've seen in a quick skim do actually tend to fit in that range of unhappy ratios - as RAM speeds have gone up, 6000 and above are cheaper and we're heading away from users thinking 5600 is easier to run than 6000

I totally agree that's a quirk and problem of AM5, but it's also something that needs to be known about.

60-100 FPS depending on the area, and it feels totally fine to me.

I use the same range, but some modern titles can't hit even 60FPS on a 4090 with maxed out settings, I think i'm just comparing a wider range of games - including the shitty badly optimised ones

For BG3 i cap to 72FPS so i get the 144Hz blanking rate out of the display, for example. It cant do high FPS everywhere, so i get the best consistent result i can.

 

[Mussels]

Tested some more things with the RAM today
5600 is just bad for ryzen, don't do it.


AM5 in general:
Any major changes to RAM speeds resulted in two 'boots'

Boot 1: roughly 20 seconds of code 15 (memory training)
Boot 2: normal 20 second boot, loading the trained settings. All following power ons should take this long.


5600 should math out well with some IF ratios
2x (1400) (Low latency, had slow boot issues on every boot)
1.75x (1600)

Both have low latency and perform very similar, but the default 1800/2000 seen on boards simply booted slow every attempt, like manual 1400 did.
Unless people are manually setting the IF, 5600 isn't going to behave well on auto.

Going to test a cleared CMOS and see what the IF runs out without EXPO/XMP, and see if that's why some users have better luck than others via that method.


Googling it, I found examples of different boards from different brands where half the users said 5200 was their limit, while those with DDR5 6000 said everything worked fine.

This thread is a great example
B650 tomahawk ddr5 5600 long POST times : MSI_Gaming (reddit.com)

Problem users are all 5600 (many saying they're stuck at 5200)

And the people with no issues at 6000 are baffled, because their RAM matches nicely with the default IF clock

Current theory? DDR5 5600 just isn't good on AM5 with automatic settings, since they all love to default to 2000 IF now, which benefits DDR5 6000 but breaks 5600.




Oh this one stood out as interesting, as this user mentioned he has a GTX 1080.
Worthy troubleshooting step.

Interestingly 4800 seems to have no latency issues with the stock 2000IF, despite not mathing out well. I wonder if theres an internal fix for that, or theres more to this situation - like a RAM speed that the issues only appear when running above it.

 

[TheLostSwede]

It appears I'd missed to enabled the low latency and XMP/EXPO high bandwidth support settings
They did make a huge difference in terms of write speed and an improved latency a touch.

 

[thesmokingman]

Me neither. But cueing up YouTube, partaking in Cannabis consumption, and just generally taking my time.. yes I could have done it in half the time because I am fairly good at what I do.

Lmao, passing the Dutchie to the left hand side is the one thing I cannot do whilst trying to work on my rig. There's just too many shiny things to get distracted on with razor focus that I forget wtf I was trying to do in the first place.

 

[Mussels]

Playing with DDR5 on intel systems, they have a DDR5 base clock option of 100 or 133.
That makes sense with the RAM speed combinations having some issues on AM5 - anything divisible by 0.25 would math with a 100 base clock number.

I'm just not sure if AM5 ever switches to a 133 base clock for the DDR5, when it does is when the IF clocks would need to change or go wildly out of sync

100x60 = 6000
133x45 = 5985

sometimes they math out so close it's easy to see how it can happen if we're forced to an 'auto' value

 

[Durhamranger]

TL;DR: Synced M/U/F values are critical below 2000, but the values are off above 2000. Those values are possibly inaccurate.
I'll test if this is related to Uclk being halved or not, at some point.


Unrelated: My notes had a lot of "FU" and "MF" in there, and as shorthand for swearing I laughed at my notes a lot.
In none of this testing did the motherboard take more than 20 seconds to POST and reach windows. None. The only slow boots were failed ones that reset to JEDEC.

Uclock is halved, so it's running
3600/xxxx/1800

1800: 66.2ns
2000: 67.2ns
2033: 67.7ns
2066: 65.8ns Suddenly faster
2100: 66.6ns (Almost back to 1800 speeds)
2133: 86.7ns
2166: failed to load windows
2200: Needed CMOS cleared


Due to this RAM matching up to 1800, we've got a 200MHz chunk we can't test.
2033 isn't the magic value here, unlike with DDR5 6000 testing.


View attachment 319459View attachment 319460
View attachment 319461
View attachment 319462View attachment 319463


If only we had values between 1800 and 2000, I believe this is why people have conflicting results - change the RAM speed even slightly, and you need a different Fclk value that may not even be user accessible. 1800x3 is 5400, the stock maximum for these CPUs with 6000 being the sweet spot and nothing in between - leaving a 600MT/s gap that may always be out of sync.

6200 would want 3100/2066/2066


View attachment 319464View attachment 319465


7000MT/s = 3500/1750/1750, lower than the stock 1800MHz IF
7200MT/s = 3600/1800/1800
7400MT/s = 3700/ 1850/1850 *BUH-BOH* - there is no 1850 option!
7600MT/s = 3800/1900/1900 - Maybe 2000 is close enough to be low latency
7800MT/s = 3900/1950/1950 -

All the way to 8000 where its back in sync again. It makes sense 7600-7800 works with a tiny latency hit, but those missing values between 1800 and 2000 screw with us in that speed range.

Following this theory, I tested DDR5 7000 since it has a 'perfect' 1750MHz option available to sync U and F.


DDR5 7000 testing:
3500/2000/1750: 70.5ns (-3.3ns vs 7200)
3500/1800/1750: Failed to post. This may be important, if 'memory holes' exist for Infinity fabric.
3500/1760/1750: 71.4 ns
3500/1750/1750: 68ns - this matches what you'd expect from dropping 100 MHz / 200 MT/s off the ram.
3500/1733/1750: 71.5ns

Even 16MHz below or 10Mhz above has a loss. The 2000+ values are the only exception to the sync rules, which makes me wonder if the values are even accurate after 1800.
View attachment 319466View attachment 319467View attachment 319468View attachment 319469



IF frequency observations: Typed them all out for you. This was annoying, there is no logic to these values.

100, 200, 400, 500, 800, 933
1100, 1120, 1143, 1200, 1250, 1257, 1280
1300 - 1320 -1333 -1371 - 1400 -1440 -1467 -1485
1500 -1560 - 1600 - 1650 - 1680 - 1733 - 1750 - 1760 - 1800
2000, 2033, 2066, 2100, 2133, 2167, 2200, 2233

After 1800 they lose many of the unusual values, but that doesnt mean internally they're exactly what we see, either.
I see no obvious patterns to this with multipliers and dividers but there has to be some meaning to it all, or why would AMD even include options as low as 100MHz?



I copy pasted the fastest results from each set to look for a mathematical link

Ram speed in MT/s divided by IF, gives the following

3600/1800/1800: 66.2ns (2x)
3600/2000/1800: 67.2ns (3.6x)
3600/2033/1800: 67.7ns (3.54x)
3600/2066/1800: 65.8ns Suddenly faster 3.48x
3600/2100/1800: 66.6ns (3.42x)


Note how 3.48x is faster than 3.54x
That small difference from the perfect divider is enough to throw the results out.

Interestingly 5600MT/s does NOT math neatly here, explaining why 6000 with sub-optimal choices can still outperform it.
5600MT/s aka 2800MHz

/2 is 1400
/1.75 is 1600
/ 1.5 is 1866
/1.25 = 2240
This explains why 1800 and 2000 are fairly similar, since the stock ratio does not fit 5600.

Starting with what I've theorised:
5600MT/s (2800MHz) divided by 3.5x would be 1600
Starting with a bad value of 2000

Same ram at CL34, fairly poor timings for these speeds hence the poopy values.

2800/2000/2800: 76ns
2800/2000/1400: 79.6ns
a ~4ns loss from halving uclk is worth knowing, it's not worth halving it for a small gain in ram speed - but a few hundred MHz would be.


2800/1400/2800: 81.7ns (2ns slower, from a 600MHz drop? Yeah, being in sync matters)
2800/1600/2800: 76.6ns (Very very close to the 2000MHz IF above)

There is no magical formula, never has been, never will be, Aida64 is not a reliable way to measure, look at all your cpu clocks, notice the problem ?

 

[Mussels]

There is no magical formula, never has been, never will be, Aida64 is not a reliable way to measure, look at all your cpu clocks, notice the problem ?

There is something behind it, i didnt post those dozens of screenshots to be told you know better, but have no evidence of it either

The CPU clocks are exactly the same in every test - stock.

 

[Durhamranger]

There is something behind it, i didnt post those dozens of screenshots to be told you know better, but have no evidence of it either

The CPU clocks are exactly the same in every test - stock.

but the CPU speed is not the same in all tests, it fluctuates 5350mhz vs 5500mhz, posted 2 screen shots the other day with the very same thing 5500 vs 5550, now can you see the problem with aida64, it can be very inaccurate

if you use aida64 and run it 5 times you will get different scores each time depending on what your system is currently doing, the higher the cpu speed the higher the bandwith

see here.....

Ryzen 7000 / AM5 Memory guide (DDR5 6000+ stability, slow boots, memory training etc)

This ones going to be short and sweet, fortunately. I've done a LOT of repetitive testing with a 7900x here to replicate why some users have slow boot issues of what they mistakenly call 'memory training', and i did not want this lost hundreds of pages into the Zen Garden clubhouse thread where...

www.techpowerup.com

test in safe mode and if you post the results, and if there's any difference then I'll say your on to something.....

 

[P4-630]

Just leave this here:

Gear Up for the AM5 Next Gen. APU with GIGABYTE Latest BIOS update | News - GIGABYTE Global

November 10, 2023 –GIGABYTE TECHNOLOGY Co. Ltd, a leading manufacturer of motherboards, graphics cards, and hardware solutions, released the latest AGESA 1....

www.gigabyte.com

 

[Mussels]

test in safe mode

Most benchmarks and drivers dont work in safe mode.


I'm testing with the same OS and settings that w1zzard uses for his reviews
(60) Windows 11 Tweaks for GPU Benchmark | TechPowerUp Forums

Safe mode could triple performance in every test and still be worthless, because no one can use the OS for anything in safe mode...

Just leave this here:

View attachment 321291

View attachment 321292

Gear Up for the AM5 Next Gen. APU with GIGABYTE Latest BIOS update | News - GIGABYTE Global

November 10, 2023 –GIGABYTE TECHNOLOGY Co. Ltd, a leading manufacturer of motherboards, graphics cards, and hardware solutions, released the latest AGESA 1....

www.gigabyte.com

That 8300G is a weird design
A single CCX with the full cache i understand, but a single core in a CCX?

They took this far further than anyone speculated
The reverse could work here with larger L1/L2 caches as well on specific core numbers, if they benefit from this like the 3D chips did with the larger L3.

 

[Count von Schwalbe]

That 8300G is a weird design
A single CCX with the full cache i understand, but a single core in a CCX?

They took this far further than anyone speculated
The reverse could work here with larger L1/L2 caches as well on specific core numbers, if they benefit from this like the 3D chips did with the larger L3.

Are the mobile/monolithic parts broken up into CCX's? I would have thought that would defeat the point of the compact design of Zen4c.

Also, I would LOVE to see Cinebench scaling comparisons of the 8500G and 8600G by power envelope. At what point does efficiency reign over power?

 

[tabascosauz]

Just leave this here:

View attachment 321291

View attachment 321292

Gear Up for the AM5 Next Gen. APU with GIGABYTE Latest BIOS update | News - GIGABYTE Global

November 10, 2023 –GIGABYTE TECHNOLOGY Co. Ltd, a leading manufacturer of motherboards, graphics cards, and hardware solutions, released the latest AGESA 1....

www.gigabyte.com

6-core should be an 8CU part. That's an improvement that Phoenix brought to the table - 8CU actually does some decent work with the right memory bandwidth. 12CU needs the power and mem bandwidth to sustain so in practice 8CU is actually reasonably close. 6CU like Rembrandt generation is not enough and is barely better than Vega 8.

Most benchmarks and drivers dont work in safe mode.

That 8300G is a weird design
A single CCX with the full cache i understand, but a single core in a CCX?

They took this far further than anyone speculated
The reverse could work here with larger L1/L2 caches as well on specific core numbers, if they benefit from this like the 3D chips did with the larger L3.

AIDA works fine in safemode. You won't get a proper CPU clock readout when in safemode, but it's preferred for consistency and performance. Not that AIDA was known for its consistency to begin with.

Regardless of how the Phoenix-2 parts are setup, they are really low on the perf stack with their 4CU floorplan. APUs are always half cache anyway.

Are the mobile/monolithic parts broken up into CCX's? I would have thought that would defeat the point of the compact design of Zen4c.

Also, I would LOVE to see Cinebench scaling comparisons of the 8500G and 8600G by power envelope. At what point does efficiency reign over power?

I doubt it, wouldn't make any sense to performance to separate L3 between Zen 4 and Zen 4c. CCX is still up to 8 cores but it hasn't been as relevant for 3 years. There aren't nearly as many 4c cores as in Bergamo. Like all previous APU generations (and the way it's also set up in a CCD), the cores should be clustered around the L3.

Phoenix-2 4c was advertised as being more efficient at low power/clocks. Something that's not relevant in desktop since Zen 4 is more than efficient enough.

Zen 4c sucks for freq so you already know the 8500G won't be going far. As for the actual Phoenix parts 8600G and 8700G, they do like more power, but that'll be interesting to see as no other AMD consumer products share their node right now (N4). But they are still half cache, so expect a slight Cinebench hit clock for clock compared to Raphael.

 

[Count von Schwalbe]

Zen 4c sucks for freq so you already know the 8500G won't be going far. As for the actual Phoenix parts 8600G and 8700G, they do like more power, but that'll be interesting to see as no other AMD consumer products share their node right now (N4).

I just want to see the power scaling. Nothing else.

I am using Cinebench as a "real world" example of how the frequency scaling by power envelope could affect performance. I strongly suspect that the part with Zen 4c cores will actually get an advantage somewhere around 15w, maybe less.

But they are still half cache, so expect a slight Cinebench hit clock for clock compared to Raphael.

APUs are always half cache anyway.

Literal no difference in capabilities, besides clock speed, between Zen 4 and Zen 4c, on an APU.

 

[tabascosauz]

I just want to see the power scaling. Nothing else.

I am using Cinebench as a "real world" example of how the frequency scaling by power envelope could affect performance. I strongly suspect that the part with Zen 4c cores will actually get an advantage somewhere around 15w, maybe less.


Literal no difference in capabilities, besides clock speed, between Zen 4 and Zen 4c, on an APU.

My guy, APUs are always half cache compared to a CCD. 16MB L3 total for 6- and 8-core (2x4MB for Renoir). There is a difference in performance, even outside games. Unless N4 magically enables Phoenix to scale well past what Raphael can do (which does not seem to be the case), you're barking up the wrong tree.

15W of what? Only full L3 cores in a CCD are hitting 15W per-core. In terms of total 15W package power, higher DDR5 and Fabric speeds will eat well into that package power number.

 

[Count von Schwalbe]

My guy, APUs are always half cache compared to a CCD. 16MB L3 total for 6- and 8-core (2x4MB for Renoir). There is a difference in performance, even outside games. Unless N4 magically enables Phoenix to scale well past what Raphael can do (which does not seem to be the case), you're barking up the wrong tree.

Indeed. I was not comparing to Raphael.

I was just hoping to simulate a mobile part, where the package power is dramatically limited. My personal suspicion is that the serious power limitation would allow the more power efficient Zen 4c to actually clock higher than Zen 4.

 

[tabascosauz]

Indeed. I was not comparing to Raphael.

I was just hoping to simulate a mobile part, where the package power is dramatically limited. My personal suspicion is that the serious power limitation would allow the more power efficient Zen 4c to actually clock higher than Zen 4.

The data has already been out for Phoenix-2 mobile for a while. It's great for mobile day-to-day, but efficiency in the 1.5-2.0GHz is not a very relevant frequency range for desktop. For stuff that isn't a handheld, real advantage remains in area efficiency, like E-cores. Outside of that freq envelope, any efficiency difference to Zen 4 is either negligible or in favour of Zen 4.

Just like I initially suspected at Bergamo launch, Zen 4c is still Zen 4c; Phoenix-2 might be taking that design for a different role on a 2023 mainstream node, but at the end of the day it still reflects the server priorities - lots of cores at around 2.0GHz.

Taking the same silicon and putting it in the AM5 package will take away a lot of the power efficiency and optimizations. Desktops do not usually have always-dynamic UCLK and Fabric like laptops do, no efficient-to-run LPDDR5x, much higher DDR5 UMC speeds, your package power floor will be much higher. Hard to draw any reliable conclusions about mobile Phoenix by testing on desktop Phoenix.

AMD Ryzen Z1 (7540U/Phoenix2) 简单测试

2023年11月更新：由于AMD更改了命名规则，本文中所有7540U实际均为7545U。 名字少一个 Extreme，到底少了什么？2023年发售的Ryzen Z1或者说Ryzen 5 7540U虽然表面上不起眼，但它其实是非常不同寻常的一个SoC： AMD…

zhuanlan.zhihu.com

 

[Durhamranger]

Most benchmarks and drivers dont work in safe mode.


I'm testing with the same OS and settings that w1zzard uses for his reviews
(60) Windows 11 Tweaks for GPU Benchmark | TechPowerUp Forums

Safe mode could triple performance in every test and still be worthless, because no one can use the OS for anything in safe mode...


That 8300G is a weird design
A single CCX with the full cache i understand, but a single core in a CCX?

They took this far further than anyone speculated
The reverse could work here with larger L1/L2 caches as well on specific core numbers, if they benefit from this like the 3D chips did with the larger L3.

Sorry for been a bit arsey, my ocd got the better of me, I get what your saying, but for Aida64 it offers the most consistency when its run in safe mode, yes granted you cant run things like
zentimings, 1st screenshot 2167fclk, 2nd screenshot 2133fclk.....

 

[AusWolf]

Yeah, CPU performance is fine, Zen 4c smaller cache, blah-blah, but what about the iGPU? Will it get all the video decode features that big RDNA 3 has? What about the pricing? It's a HTPC chip after all.

I'd also be interested to see cheap m-ITX A620 boards for a truly current-gen HTPC build, but so far, I found none. All the B650 ones are super gamery and cost over 200 quid, which is sad. This is the same thing that gets in the way of doing the same on Intel. The CPUs are there, Celerons and Pentiums all have their big brothers' iGPU for video decode, but motherboards are super expensive for some reason.

 

[tabascosauz]

Yeah, CPU performance is fine, Zen 4c smaller cache, blah-blah, but what about the iGPU? Will it get all the video decode features that big RDNA 3 has? What about the pricing? It's a HTPC chip after all.

I'd also be interested to see cheap m-ITX A620 boards for a truly current-gen HTPC build, but so far, I found none. All the B650 ones are super gamery and cost over 200 quid, which is sad. This is the same thing that gets in the way of doing the same on Intel. The CPUs are there, Celerons and Pentiums all have their big brothers' iGPU for video decode, but motherboards are super expensive for some reason.

Phoenix-2's 4CU RDNA3 is not meaningfully different from any other Phoenix iGPU in terms of features. I don't see why it would be a problem just because it has 1/3 the CUs.