Hyperscheduler is probably four threaded, btw.
8 cores => 8 logical threads and up to 24 hyperscheduled threads.
It is most likely API-triggered SMT.
Single threaded(8 threads) -> game does blank -> SMT2(16 threads) -> game does blank1 -> SMT3(24 threads) -> game does blank2 -> SMT4(32 threads)
OS/Game Audio core => one os/game audio thread, hs mode0 => +one game os audio thread, hs mode1 => +two game os audio threads, hs mode2 => +three game os audio threads.
That was what the rumors I saw seemed to indicate (that it was based around some special API/software). No idea on your other thoughts.
I could be very wrong. I don't follow consoles much. Call it a gut feeling. It's not like when I say that Zen 3 will be SMT2 for sure which some people refuse to believe, if you know what I mean
.
Its not a big deal, but I believe Sony and Microsoft have outright said 8C/16T. I could see Microsoft trying to segment a lower priced console by limiting it to 8T, but I'd guess it would be a software lock and Microsoft might choose to unlock it depending on devs and consumers.
This is where I'm speculating, but I think this is how things have played out:
-Microsoft had a beast of a console planned. Talking 15TF.
-Along with a streaming console pushing 5-7.5TF that they cancelled after finding out that their hybrid streaming plan (i.e. mix of local and cloud processing) wasn't going to work well.
-They find out the base PS5 is going to be closer to 10TF, but the big advantage likely isn't going to benefit them much (as the PS5 is going to be the base target for games, I think its harder than ever to notice the differences in resolution and other quality settings and with new VRR capabilities, there's less times that it'll be leading to 30fps vs 60fps situations), so they rein things in a bit (lower their cost) and we'll be looking at something closer to 13TF.
-Sony also finds out about Microsoft's monster and thinks they need to do something to counter it so plan for a PS5 Pro, with higher clock speeds and probably fully enabled chips (GPU CU count namely), letting them get an extra 20-25% performance, getting to about 12.5TF
-Microsoft decides to revamp the streaming console, beefing it up to be close to the base PS5. They'll launch it the following year and undercut Sony in pricing. Might do something like ditch the optical drive as well to lower cost and make a smaller system.
They are not. There is no point in limiting the hardware threads, because if any game dev wants less jittery threads, they can just choose not to schedule more than one thread per core.
Absolutely nothing like this exists on the next-gen consoles. Where do you even get this horse****?
There is if they want to segment things artificially. Which I won't be surprised if they do, while keeping the hardware capability, giving them the option to enable the full threading ability later.
I can't speak to the specifics of what he's saying, but there were rumors that devs had Xbox dev kits that could do up to 3 threads per core. It suggested it was due to some special software environment. So this is one of the times that you really should cut Nosta some slack as he's basing it of off actual legitimate (well as legit as rumors go, but I think even Digital Foundry or someone credible backed up the claims that such dev kits existed but likely were nothing more than that meaning they were testing it but it wasn't likely to be in the final console hardware; it was purely experimental).
It was a reply to this:
darkswordsman17: " There was also a report that Microsoft had Xbox dev units that could do 3 threads per core via some special code path."
Which is a reference to the Hyperscheduler_mode=Enabled and SMT_mode=disabled.
Logical processors = 8
Hs_mode0 = 8(logical)+8(hyperscheduled threads)
Hs_mode1 = 8(logical)+16(hyperscheduled threads)
Hs_mode2 = 8(logical)+24(hyperscheduled threads)
A hyper scheduler is an architectural device that supposedly can accelerate context switching and better support concurrent contexts. In the context from the "leak", AMD/Microsoft was using this to improve consistency of multithreading performance.
Using Zen as an example:
SMT_mode = flat 96(T0) and 96(T1)
HS_mode0 = 192(T0) or 96(T0) and 96(T1) when SMT is needed.
HS_mode1 = " " " or 64(T0) and 64(T1) and 64(T2) when SMT3 is needed.
HS_mode2 = " " " " " or 48(T0) and 48(T1) and 48(T2) and 48(T3) when SMT4 is needed.
=> Fetch windows are tracked in a 64-entry (32 entries in SMT mode) FIFO from fetch until retirement.
=> In SMT mode each thread has 10 dedicated IBQ entries.
=> The op cache is organized as an associative cache with 32 sets and 8 ways. At each set-way intersection is an entry containing up to 8 instructions, so the maximum capacity of the op cache is then 2k instructions. The actual limit may be less due to efficiency considerations. Avoid hot code regions that approach this size for a single thread or half this size for two SMT threads.
=> The op cache is organized as an associative cache with 64 sets and 8 ways. At each set-way intersection is an entry containing up to 8 instructions, so the maximum capacity of the op cache is then 4K ops. The actual limit may be less due to efficiency considerations. Avoid hot code regions that approach this size for a single thread or half this size for two SMT threads.
=> The retire queue can hold up to 192 micro ops or 96 per thread in SMT mode.
=> The retire queue can hold up to 224 micro ops or 112 per thread in SMT mode.
=> It is expensive to transition between single-threaded (1T) mode and dual-threaded (2T) mode and vice versa, so software should restrict the number of transitions. If running in 2T mode, and one thread finishes execution, it may be beneficial to avoid transitioning to 1T mode if the second thread is also about to finish execution.
What are you basing these specifics on? My point being, given your history, its tough to discern what is literally made up stuff and what is based on legitimate stuff. That's why you get so much guff, but I think there are times when you provide more solid input but because of the other times, people respond negatively.
I don't predict it or expect it, but at the same time I wouldn't be surprised is what I meant. They'll likely be 8/16, but it wouldn't shock me if they were 8/8.
I'm going to go with not credible at all.
I think there was some credibility. But its possible it was a smokescreen to spook Sony or something. From what I gathered it was experimental stuff and I personally think is just them looking at future API (DirectX) revisions. The Xbox provides a great platform to trial that on, as its fixed hardware, and is a closed software environment, where it would be easiest to get the benefits. Heck I'm not sure if the kits were even for gaming, just that they were Xbox kits (but like I said, I think that might simply be due to the aspects of the platform that would make them good targets for trialing experimental stuff like that; it might also have been something to do with their asymetric streaming, where due to the latency of the network they realized there would be times when the local hardware might be waiting for data so they thought that if they could do more work locally - decompressing/compressing data for instance that it would be benficial).
Its pure speculation on my part but is based on rumors. I tried to make it clear that's all the more than SMT2 talk with Zen 3 was (so all the SMT4 stuff I think was baseless and was just people going "well if they're doing more threads then it'd have to be SMT4" when I these extra threading rumors seemed to indicate it was a software environment thing and not related to the hardware itself - from what I recall the rumors said it was normal Zen 2 cores and was just due to the software environment enabling the extra thread per core).
Not good enough. You take a firm stance now, and after launch, we'll fight to death over the interpretation!!!!!
Don't forget people citing it years later to trash you if you're wrong!
Look at the GPU forum where people are still complaining about people citing AMD (Raja) claiming there was going to be a big update that would "fully enable" Vega's hardware features and improve performance (and acting like that was people senselessly speculating). Meanwhile many of the people chastising others for that speculated rampantly about consumer Volta that literally never appeared (which almost no one called them out on, only reason I do is because they keep bringing up old stuff slamming people for it while ignoring all the times they themselves were just as if not more guilty of that behavior). Some of them I believe claimed it would be 100% better than Pascal and would basically put AMD out of business (think they claimed prices would be lower than Pascal which we see how all of that speculation turned out with Turing - 2 years later, 40% improvement at higher prices...). And then even sillier are people citing that drum ad that had "Poor Volta", when it ended up being true (the ad was targeted at gamers, which a LOT more people were gaming on Vega than on Volta seeing as gaming Volta didn't happen).
AMD are full paranoia mode now. Leaks will only happen when OEMs or reviewers gst the chips.
No more UserBenchmark results months in advance.
They're likely doing better with regards to Zen 3 leaks as I don't expect anything major that they need to let developers know (which is why I think a lot of the leaks happen so far in advance, they need to inform the dev community to get them ready for significant changes). Its why we saw the EPYC leaks as there is a bit there that they likely need to let known.
I just want to point out that AMD missed the mark with Zen2. Intel is still #1 in gaming but they wiped the floor in everything else. They were expecting better clocks and performance in Zen2. I think Zen3 will put any arguments to rest. The problem. The market is flat and because of AMD there was growth again. Now the market is saturated. Server side is a different story because Intel has been sticking it to big business for a very long time.
I think that Zen3 will be a bigger step forward than Zen2 was.
Did they? Because saying they missed the mark because they missed the rampant speculation that was based simply on what people wanted (5GHz!!!!!!!!! Which is they the AdoredTV stuff was so controversial as there were some people that legit expected that based on nothing but their own wants, but its why some people are so derisive as the people talking 5GHz were quite vocal and have been still because they didn't get their magic 5GHz) is kinda silly. There's been no indication to me that they missed what they were aiming for, and aside from the issue with the reporting of clock speed (which made people senselessly angry as they should be focused on the performance which seemed to be where it was stated, but again, many of those people were ones that seemed to be expecting 5GHz out of Zen 2 so they were mad when it appeared to not be doing the clockspeeds AMD claimed), the performance seems to be exactly where AMD said it would be.
Honestly you seem to be just pushing the hype train down the tracks. I'm not expecting a big improvement out of Zen 3, and from what I've gathered, efficiency seems to be the focus of it, so outside of perf/W, I'm expecting quite modest (but solid, like 10%) better performance out of Zen 3. Zen 2 was I think ~15% performance uptick, with perf/W being touted at like 40-75% over Zen 1. I think Zen 3 will be more like 20-33% efficiency over Zen 2 (think we could see the 65W stuff go to 45W since they'd be more efficiency focused, but 105W probably maybe only drops to say 90W since those are performance focused I think they'll be less aggressive about efficiency; I think it'll be mainly servers and laptops and OEM stuff that we'll see them push efficiency).
I think the similarities to Zen 2 but enough of a boost to perf/W will be significant enough that we might see a fairly quick console generation update. I could potentially see the Series S Xbox being Zen 3 based even (I expect it a year later in late 2021). But then they wait another year to update the Series X (possibly with a GPU bump at the same time).