<davidlt[m]>
I am still looking at 7950X, but waiting a bit after all that stuff happened with motherboards feeding higher voltage then they should.
<davidlt[m]>
There should be a new AGESA later this month.
<davidlt[m]>
Guo Ren:
<davidlt[m]>
> I want to keep them in dts to be modified flexiable. This driver is
<davidlt[m]>
> not only for th1520, but for bunches of T-HEAD SoCs, th1520 is a
<davidlt[m]>
> sample/example for us.
<dtometzki>
What that means ?
<davidlt[m]>
That it's IP vendor product (test stuff) and there will be more SoCs designs.
<davidlt[m]>
They also probably don't have large enough market for these to make profit.
jcajka has joined #fedora-riscv
<davidlt[m]>
rwmjones: just in case you are thinking about new development machine with DDR5. I would suggest to avoid 4 DIMMs, basically you want to have 1 DIMM per channel.
<davidlt[m]>
So that limits you to 32GB, 64GB or 96GB of RAM.
<davidlt[m]>
Getting 4 DIMMs to work seems to be hard (especially on AM4 with 1st gen memory controllers).
<davidlt[m]>
Even if you get them running, the clocks might be extremely low. I think, for AM5 that's 3600MT/s.
<davidlt[m]>
Intel is on their 2nd gen memory controller and things are better there with clocks and support.
<davidlt[m]>
s/AM4/AM5/
<davidlt[m]>
At least on AMD side not running EXPO, XMP, etc. to hit that 6000MT/s (sweet spot) has a huge impact on gaming workloads.
<davidlt[m]>
It seems Intel will have a problem on a desktop side for some time, but AMD rumours for Zen 5 are nice.
<davidlt[m]>
Zen 5 should be a larger jump in perf.
jcajka has quit [Remote host closed the connection]
<davidlt[m]>
I bet Intel continues to have better software optimizations, but they have huge software teams.
<davidlt[m]>
CPUs, and iGPUs are exciting. GPUs are in a terrible spot.
<davidlt[m]>
Also ASRock has a few AM5 "server" motherboards on their website, that incl. AST2600 BMC IIRC.
<davidlt[m]>
They also support DDR5 ECC.
<davidlt[m]>
Computex is starting, so there might be more stuff coming out.
<davidlt[m]>
The only (and recent) problem with AM5 is that majority of motherboard vendors are pushing higher voltage for SoC compared to what AMD recommends.
<davidlt[m]>
Especially on EXPO settings + 3D that causes the chips to blow up.
<davidlt[m]>
Non 3D are also affected, but they aren't as sensitive as 3D cache chips to the voltage.
<rwmjones>
ok thx
<rwmjones>
hmm do all AMD's consumer CPUs top out at 16 cores?
<davidlt[m]>
Yes
<rwmjones>
& I bet threadripper is £££££s more
<davidlt[m]>
There are some rumours that Zen 5 might increase that, but most likely not.
<davidlt[m]>
Intel has HEDT products now.
<rwmjones>
wow the jump from TR 16 core to TR 24 core is £949 -> £2199
<rwmjones>
32core £2799!
<davidlt[m]>
Yeah
<rwmjones>
back to ryzen, do you know what the difference is between the X and X3D cores?
<davidlt[m]>
You will save on electricity bill, but that's pretty much it.
<davidlt[m]>
Some things might regress if task lands on a wrong chiplet.
<davidlt[m]>
Folks usually buy the 8-core variant (for gaming).
<davidlt[m]>
Because all cores are the same on that one.
<davidlt[m]>
Be beauty is 7900 (non X), that one has 65W TDP :)
<davidlt[m]>
X3D are up to 120W
<davidlt[m]>
and X are 170W
<davidlt[m]>
and 3D is almost 200 EUR more expensive than X
* rwmjones
wonders why the TDP of the 7950X is 170W vs 120W for the X3D
<davidlt[m]>
Because 3D stacked chip is very sensitive to voltage.
<davidlt[m]>
It has to run at lower voltage, and basically overclocking is disabled or limited.
<davidlt[m]>
This is way chips have been exploding recently as motherboard vendors pushed more voltage than allowed once EXPO is enabled.
<davidlt[m]>
EXPO doesn't set VSOC, but VDIMM IIRC. Vendors noticed that on higher freq memory you can more stable results if you increase VSOC too.
<davidlt[m]>
So some went with 1.4-1.5V on VSOC with EXPO enabled.
<davidlt[m]>
And that voltage you are degrading silicon way faster, and on 3D part even way more.
<rwmjones>
this makes it sound like X3D has a lot of downsides ...
<davidlt[m]>
Didn't last long until some 3D one blew.
<davidlt[m]>
For gaming is all good, just manually set VSOC or/and disable EXPO until there is a new AGESA version.
<rwmjones>
yeah I read about some chips blowing up
<davidlt[m]>
For gaming it's beautiful.
<davidlt[m]>
For servers it's good too.
<davidlt[m]>
All those severs chips don't run at high clocks.
<davidlt[m]>
So OK for gaming and server workloads, but not really that beneficial for professional users on a desktop.
<davidlt[m]>
Like Photoshop and similar love freq, not cache.
<rwmjones>
even the "small" cache is 32MB ..
<rwmjones>
(32768 times larger than the total RAM on my first computer)
<davidlt[m]>
The beauty for the servers is that majority of those chips run at 3D cache chip speeds.
<davidlt[m]>
So it's basically just more cache, clocks stay the same.
<davidlt[m]>
(Of course I didn't check all SKUs, etc.)
<davidlt[m]>
IIRC on 3D cache you loose 1GHz (or more) on boost.
<davidlt[m]>
The base is slightly lower and boost range is very minimal.
<davidlt[m]>
I found no benchmarks for QEMU :)
<davidlt[m]>
I don't know if QEMU prefers more cache or freq.
<davidlt[m]>
And for code compile 3D is like ~1% slower, almost identical.
<davidlt[m]>
Again, for desktop browsers are important. No gains here too.
<davidlt[m]>
Well compression is faster, HPC workloads (like simulations, etc.) are faster too (but not always).
<rwmjones>
I would imagine that TCG can benefit from the extra cache, since it could be used for caching the decoded ops
<davidlt[m]>
True, but you are also loosing the clock speed.
<davidlt[m]>
Extra cache, or extra ~1GHz on the clock.
<davidlt[m]>
On gaming side loosing a clock, and gaining cache typically speeds up gaming 15-30%, but more importantly raises 1% lows. Game is smoother. Frame time are more even.
<davidlt[m]>
I haven't seen HPC workloads to benefit always too, but I bet because a lot of those were optimized for cache sizes.
<davidlt[m]>
There are a lot of heuristics, checks, adjustments in algos.
<davidlt[m]>
I doubt games (or their engines) get that kind of attention.
jcajka has joined #fedora-riscv
jcajka has quit [Ping timeout: 264 seconds]
jcajka has joined #fedora-riscv
jcajka has quit [Ping timeout: 265 seconds]
somlo has quit [Quit: Leaving]
<thefossguy>
Would the extra cache help with emulation in QEMU?
<thefossguy>
All three of these screenshotted websites redirect to an ad network
<davidlt[m]>
But again, building JH7110 or TH1520 based board is way cheaper than any X3D chips :)
<thefossguy>
I don't understand the joke/reference
<davidlt[m]>
There is no point building an expensive machine for QEMU if you want to play with riscv64.
<davidlt[m]>
Just get a board, especially JH7110 or TH1520 (even better) and that will outperform that expensive PC.
<davidlt[m]>
I mean QEMU on that expensive PC.
<thefossguy>
Of course... emulation is, emulation :)
<thefossguy>
No such thing as bare metal, amirite?
<thefossguy>
:D
<thefossguy>
That's the primary reason why I got the VF2
<davidlt[m]>
There is another mess up noticed.
<davidlt[m]>
The DT than landed in U-Boot is not aligned to what's in Linux.
<thefossguy>
I have a 3900XT with 64GB/GiB (i can't recall which one is "correct") RAM. OpenBSD in a RISC-V VM (with QEMU ofc) took 30 minutes to install.
<davidlt[m]>
You cannot boot Linux with DTB from U-Boot.
<thefossguy>
That's why I got a VF2, now Arch only takes 1 minute to boot
<thefossguy>
davidlt[m]: Do you mean this for the VF2?
<davidlt[m]>
Yeah, VF2.
somlo has joined #fedora-riscv
<thefossguy>
I think they just sent in a patch only one or two weeks ago about handling the DT patching in u-boot at runtime itself. Hasn't been merged but if it works, fingers crossed
<thefossguy>
"works" as in merged
<davidlt[m]>
Nah, right now booting Linux with embedded U-Boot DTB doesn't work IIUC from discussions.
<thefossguy>
I have misaligned r/w when I'm sleepy lol
<davidlt[m]>
The values are wrong.
<thefossguy>
Ouch
<davidlt[m]>
The problem is that upstreaming happened in parallel.
<davidlt[m]>
U-Boot maintainer had to check/ask if Linux DT bindings, etc. got stable and merged before merging that in U-Boot.
<thefossguy>
I assume it should be merged in linux first and uboot should follow that?
<davidlt[m]>
Yes
<davidlt[m]>
It's basically copy & paste from Linux + separate dts overlay files for U-Boot to provide additional information.
<davidlt[m]>
It's not a problem if you load DTB from the kernel (/boot/dts-...).
<thefossguy>
Gotcha
<davidlt[m]>
But if you use DTB from the firmware (i.e. part of U-Boot ITB) that will hang the kernel IIRC.
<thefossguy>
Thanks David :)
<thefossguy>
davidlt[m]: ooooff
tg has joined #fedora-riscv
somlo has quit [Remote host closed the connection]
<dtometzki>
davidlt: or Pratham Patel do you know is the an upstram plan available for licheepi4a ?
<dtometzki>
s/the/there/, s/upstram/upstream/
<davidlt[m]>
I don't think the plan exist. I don't know what current folks that sent patches plan.