Xbox Series X [XBSX] [Release November 10 2020]

[BRiT]

*ahem* This is the Xbox Series X thread, please don't pollute it with other stuff.

 

[Frenetic Pony]

Apparently Some possible XSX screen shots here running with photogrammetry things (probably) Quixel:

https://twitter.com/x/status/1251264079488077826

Regardless of direct veracity, this is indeed the sort of thing you'll be able to see. Stuff like this using UE4, a GTX 1080 or somesuch, and no regard for consoles has been around as artist "realtime" portfolio pieces on Artstation and similar for years. Tessellation and high res textures should be no problem, though the classic problem of "now get dynamic GI to work well" isn't going to be solved right off the bat.

 

[PSman1700]

MS really hit it out of the park with the XSX. They showed with the X1X that they were serious about the power crown from then out, and they have followed through with the XSX.
I also think MS isn't really getting the kudos they deserve for the customizations they have done either. Its more than just the Tflops. With the CPU they allowed devs to choose between having SMT enabled or not, and giving a speed boost if they chose not to enable it. Such a simple thing that will have a payoff, if even slight.
The customization to the GPU to allow Machine Learning. Wouldn't have cost much to do, they have the API to benefit from it, so why not? Again, an excellent decision.
Sampler Feedback Streaming, again another customization that will help with efficiencies.
VRS. MS has it's own patented version of VRS, which AMD has announced full support for with Direct X Ultimate. Haven't heard anything from Sony about this, and you would have expected then to have thrown those three letters into the mix when talking about Geometry Engine. They know people are asking about it, they know MS has been boasting about it, so there would be every reason for them to say "oh, and we have VRS as well".
The Velocity Architecture is again all about efficiencies and milking every bit of extra out of the console.
Mesh Shading will increase GPU and CPU performance. The demo showed off by MS gave an indication of how well it will work.
I expect Sony's Geometry Engine to be the same.
But all in all MS did pretty much all it could do.
I dont see Sony having anything that will out do what MS put together. Sony will sing about the areas they believe they have the advantage in, and they have been singing about the SSD and 3D Audio.
Now dont take this as Sony bashing, as I think the Developers will matter more than the hardware, and in this era of diminishing returns with graphics, I doubt anyone other than DF with all their tools will be able to pick out any differenews with them running side by side.
What this is about is seeing how MS has gone all out to put the best console they could have to the market.
Good on them, it has put Sony on the back foot, and this can only drive competition and innovation.

Yes agree with you, they build a system designed around the SSD, a considerable more powerfull GPU, faster CPU, and a bandwith advantage (which is also important to not bottleneck things). CPU/GPU aren't variable/boost either, they are always offering the given clocks.
The SSD drive itself might be slower, but they mititagate that by using bcpack/decoder hw. In the end they will achieve the same thing. By going wide and fast (1800+mhz ain't slow, but nothing crazy), they dont have their system running on it's toes.
Feature wise, ML, patented VRS, their velocity architecture, and their hardware 3d audio SPU, which according to articles is very advanced. They also have improved alot on the API side. I also like their memory-card-SSD solution, you never have to worry about buying the correct drive, they are small and easy to connect/disconnect.
So yes, i share the opinion the XSX is a well thought out, build around the SSD next generation console. With exclusives like HB2 they are able to show their 12+TF's of power also, what can be done.

 

[chris1515]

Yes agree with you, they build a system designed around the SSD, a considerable more powerfull GPU, faster CPU, and a bandwith advantage (which is also important to not bottleneck things). CPU/GPU aren't variable/boost either, they are always offering the given clocks.
The SSD drive itself might be slower, but they mititagate that by using bcpack/decoder hw. In the end they will achieve the same thing. By going wide and fast (1800+mhz ain't slow, but nothing crazy), they dont have their system running on it's toes.
Feature wise, ML, patented VRS, their velocity architecture, and their hardware 3d audio SPU, which according to articles is very advanced. They also have improved alot on the API side. I also like their memory-card-SSD solution, you never have to worry about buying the correct drive, they are small and easy to connect/disconnect.
So yes, i share the opinion the XSX is a well thought out, build around the SSD next generation console. With exclusives like HB2 they are able to show their 12+TF's of power also, what can be done.

They don't mitigate anything 4.8 GB/s compressed data* against 8/9 GB/s compressed data. This is slower, is it important? Time will tell.

* This is using zlib + bcpack

 

[Deleted member 11852]

With the CPU they allowed devs to choose between having SMT enabled or not, and giving a speed boost if they chose not to enable it. Such a simple thing that will have a payoff, if even slight.

As far as I know, disabling SMT is a standard feature across Zen2, not a Microsoft-specific customisation?

Kudos for crediting Microsoft with some smart work with Series X but giving devs an API to flip an AMD CPU switch is not customisation.

 

[fehu]

Is more kernel level work

 

[3dilettante]

As far as I know, disabling SMT is a standard feature across Zen2, not a Microsoft-specific customisation?

Kudos for crediting Microsoft with some smart work with Series X but giving devs an API to flip an AMD CPU switch is not customisation.

I don't think AMD formally modifies its base clocks based on SMT mode, although its desktop processors boost very far into the variable clock zone to the point that such a change might constrain the product versus the promised fixed clocks of the console.
That's something of a minor tweak, though I'm curious if Sony couldn't try something like that with a future firmware revision if it proved compelling.

 

[BRiT]

As far as I know, disabling SMT is a standard feature across Zen2, not a Microsoft-specific customisation?

That entirely depends on when AMD allows flipping the switch of SMT and how MS handles it. In the PC world can you turn off SMT and NOT require an entire system reboot for the changes to take affect? Even in other OS's like BSD or Linux or MacOS?

 

[Deleted member 11852]

That entirely depends on when AMD allows flipping the switch of SMT and how MS handles it. In the PC world can you turn off SMT and NOT require an entire system reboot for the changes to take affect?

No, because the OS would immediately crash having lost half the logical processors it was using. This is why this is usually a BIOS setting. There are other issues such as the cooling profiles being predicated on the CPU configuration which cannot change in most BIOS/OS's after boot. But from a purely hardware perspective, there is no reason a Zen2 CPU cannot hotflip SMT support. It just needs to be in an environment expecting that possibility - like a custom OS

 

[3dilettante]

I don't know if console developers can switch SMT on or off on demand. Developers can apparently choose the thread count, but it wasn't stated that they could modify the count while the game was running.
Cloud clients can purchase instances with a number of virtual cores that aren't necessarily mapping to that number on the host.

Microsoft's multi-OS model could be treating a game as a client instance being assigned resources by the hypervisor, and the client could request 8 or 16 (or 7/14?) threads at the time of launch.
If that's how it's implemented, it might be an obstacle if Sony's OS architecture doesn't have that level of separation.

 

[BRiT]

I don't know if console developers can switch SMT on or off on demand. Developers can apparently choose the thread count, but it wasn't stated that they could modify the count while the game was running.
Cloud clients can purchase instances with a number of virtual cores that aren't necessarily mapping to that number on the host.

Microsoft's multi-OS model could be treating a game as a client instance being assigned resources by the hypervisor, and the client could request 8 or 16 (or 7/14?) threads at the time of launch.
If that's how it's implemented, it might be an obstacle if Sony's OS architecture doesn't have that level of separation.

No, they can't modify the thread-count and cpu speed on the fly on Series X. But that is what happens whenever the game is loaded or resumed from a wider view. You can use instant-resume between at least 3 Series X games, each one having different setting for Thread-Count and CPU Speed. So we at least know the Series X software ecosystem has to handle that situation.

 

[3dilettante]

While I'm not familiar with how VM hosts are administered, if cloud services can host clients with varying resource demands on a physical host, then the Series X hypervisor could be treating each game like a separate client.

 

[MrFox]

The linux kernel can enable/disable SMT at runtime and shift the running threads at will. I think it can even split individual thread pairs on a core by core basis.

https://gist.github.com/samueljon/e7818edeb218f5e2f1e3e258949d04c8

 

[function]

The linux kernel can enable/disable SMT at runtime and shift the running threads at will. I think it can even split individual thread pairs on a core by core basis.

https://gist.github.com/samueljon/e7818edeb218f5e2f1e3e258949d04c8

Interesting!

It might be useful for the XSX to be able to run SMT on the OS reserved core, and run the other 7 as a block either single or dual threaded based on the games preference....

 

[MrFox]

Interesting!

It might be useful for the XSX to be able to run SMT on the OS reserved core, and run the other 7 as a block either single or dual threaded based on the games preference....

I would think that outside of BC where games were designed to run on 8-core jaguar, modern games are going to use the full advantage of SMT enabled.

 

[BRiT]

Thanks @MrFox. Good to confirm my suspicions where I wasn't absolutely certain in my reply.

When you say core-by-core basis, is that at the AMD CCX level (4 core/8Threads) or even lower with 1 Core/2Threads ?

 

[MrFox]

Thanks @MrFox. Good to confirm my suspicions where I wasn't absolutely certain in my reply.

When you say core-by-core basis, is that at the AMD CCX level (4 core/8Threads) or even lower with 1 Core/2Threads ?

Per individual thread, the kernel just sees a bunch of cpus along with the topology of which are in pairs (0-1, 2-3, 4-5....) It's basically enabling/disabling the cpus individually. So disabling 0, 2, 4, 6, means there's only 1 thread left per core.

It's probably much safer to do this when starting/resuming a container, RedHat recommends not re-enabling threads at runtime. I very much doubt games would be allowed to do this at runtime, the main OS would definitely do this at will when switching game resumes.

 

[PSman1700]

modern games are going to use the full advantage of SMT enabled.

Maybe high fps games want the higher 3.8ghz clock though. Can developers dynamicly enable/disable SMT during gameplay? If yes then i could see use for it for almost all games.

 

[BRiT]

Maybe high fps games want the higher 3.8ghz clock though. Can developers dynamicly enable/disable SMT during gameplay? If yes then i could see use for it for almost all games.

Not from what we've seen presented or mentioned.

 

[neckthrough]

Maybe high fps games want the higher 3.8ghz clock though. Can developers dynamicly enable/disable SMT during gameplay? If yes then i could see use for it for almost all games.

It's been a while since I read up on kernel internals but do modern OS kernels even comprehend the notion of hot-swapped CPU threads?