AMD Ryzen, current software/firmware issues

File: ted-cruz-weird-face.png (390KB, 640x400px) Image search: [Google]

390KB, 640x400px

>yfw Ryzen is turning out to be a bigger shitshow than TLB-bugged Phenoms

I expect fixes in the coming months, accompanied by significant performance gains.

>>59321545
losses*

File: Screenshot_20170309_210012.png (112KB, 644x854px) Image search: [Google]

112KB, 644x854px

>>59321484
>tl;dr shit's bugged yo, probably more than x99 at launch.

It's not that bad, it took like 3 months to fix this shit.

>>59321544
None of this really needs a new stepping, nor does it need a recall like the FDIV bug.

File: e9vdxtsb4bky.jpg (55KB, 616x370px) Image search: [Google]

55KB, 616x370px

>>59321484
>*Windows 10 RTC disliking 0.25x multipliers, causing timing issues,
MS software fix, alternatively don't use .25x multis, you can deal with a 25MHz lower OC.
> *Software not reading L3 properly (thinking each core has 8MB of L3, rather than 2MB/core),
Windows issue again, MS get to work.
> *Latency within a CCX being regular, but across CCX boundaries having limited bandwidth,
This is designed, the only thing that can be done is to limit most thread work to one CCX.
> *Static partitioning methods being used shows performance gains when SMT is disabled,
If Windows fixed Intel's SMT it can fix AMD's SMT
> *Ryzen showing performance gains with faster memory, more so than expected,
Northbridge, infinity fabric run on the memory clock, the latter directly increases CCX <-> CCX performance.
> *Gaming Performance, particularly towards 240 Hz gaming, is being questioned,
>>>>240Hz gaming
> *Microsoft’s scheduler not understanding the different CCX core-to-core latencies,
<- Working on it
> *Windows not scheduling threads within a CCX before moving onto the next CCX,
See #3
> *Some motherboards having difficulty with DRAM compatibility,
firmware and BIOS updates still needed.
> *Performance related EFIs being highly regularly near weekly since two weeks before launch.
ASUS mainly, most people reported notably better performance with gigabyte boards.
But all of them still need BIOS fixes, I think a good deal of out of stock motherboards is because vendors are readying v1.1 and v1.2 motherboards.

File: 46-1.jpg (137KB, 561x421px) Image search: [Google]

137KB, 561x421px

>>59321709
>high-end

>>59321484
How much performance is expected from fixes?

>>59321740

0/10

>>59321806
Considering early ASUS boards have shown 21% less performance than some ASROCK/Gigabyte boards, you'll have to be a bit more specific.

From non-BIOS/EFI updates I expect some 5% tops for MT but anywhere from 0-15% ST performance, really depends on how much the scheduler is shuffling around.
One thread is still doable since it's kept to a single CCX, but it gets worse when 2 thread loads are included, since they run at both lower clocks and there's a much higher chance you'll see it either ending up on another CCX, killing cache, or ending up on SMT(logical) thread, neutering performance.

>>59321860
This is probably the biggest issue at the moment, the scheduler thinks there's 16 physical threads, not 8, so even when a core is free for something else, the scheduler can end up throwing a thread on a logical thread, which are far slower than physical ones.

So why the fuck would they release it now if all can be fixed with software updates in a months or two?
I guarantee you holding back the release and getting actually good reviews upon launch would be more profitable than the shitshow it is now

>>59322141
Because demand is still high, as evidenced by motherboards constantly being sold out.
People literally have no place to put their CPUs in.

It'll get fixed, news will be updated and people will find out, this isn't a vacuum like 2000 was, and people buying $500 CPUs don't buy them impulsively, most of the time.

>>59322141
They've released them mostly for debugging/verification, the dies used in these chips go into server ones in Q2, so getting some extra debugging done on them will help immensely.