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

Thought the whole point of them rolling their own solution was because there is no GDDR6 EEC? So I expect it will be on the soc.

The ECC work is one of the things included that wouldn't have otherwise been included, and in this case had no benefit to the console. Reduced precision is another, but could find use in the console.
The benefits are ordering more chips, and the money from the azure workloads, these could directly feed into cost of xsx or ballance sheet of Xbox division giving them more spending power.

I had a few features in my head, and being able to use a single xsx as 2 XO consoles was one of them.
Could even play 2 different games, with one of them being streamed to a device. Could have a few nice options, and marketing options 2 consoles for the price of 1.

 

Windows has the ability to stream the desktop to any other Windows computer (IT admins in corporate environments can restrict this), but it's currently not performant enough for action games.

I wonder if MS is working on a more performant version of that streaming capability. It would certainly be interesting if you could stream from your XBSX to any Windows device or TV (with appropriate app installed on the TV). In this case, the XBSX would theoretically be capable of streaming more than 1 BC game to more than 1 device, dependent on how robust your network is.

Would be neat.

Regards,
SB

 

lol. aahh man. lol you just love that shit.

 

Can already stream from XO.
Can only get better with the uograded encoder block

 

"the Series X processor is actually capable of running four Xbox One S game sessions simultaneously on the same chip, and contains an new internal video encoder that is six times as fast as the more latent, external encoder used on current xCloud servers."
https://www.eurogamer.net/articles/digitalfoundry-2020-inside-xbox-series-x-full-specs

 

Yeah the xsx apu may be capable of it, but i expect the xsx xcloud to have more memory thereby supporting that many.
On the console maybe it could be 2 XO games or 1XO and 2 x360, basically mix and match dependent on memory.

Think for console, 2 games running would end up with a few interesting possibilities though.
Sure it wouldn't be for next gen games, but none the less.

 

20x 2GB GDDR6 chips in clamshell mode can cover 4 XOs with another 8GB left for the host OS. There were smart in using a wider memory bus. They could even mix capacities since you only need 20GB+cache for the game VMs.

edit: if clamshell isn't viable, they could start with 2 VMs per SoC and then ramp up to 4 once 4GB GDDR6 is available.

 

Without the OS reserved portion of the XBO RAM, they only need a bit over 20GB to run 4 instances. Likely less if they are using virtual memory caching that is invisible to the game. Very likely there won't need to be 40GB of ram into those servers. I'm guessing even the 16GB default is enough with virtual memory handling the rest.

 

https://www.windowscentral.com/xbox-series-x-what-do-game-devs-think?amp&__twitter_impression=true

Impression of devs about the Xbox Series X

 

I don't know how there wouldn't be at least some overhead for having ECC. The memory modules wouldn't have extra storage set aside for the extra bits, and there wouldn't be extra channels set aside to access them.
Versus the full storage and bandwidth being given dedicated to data with no extra encoding, an ECC solution that matches the standard definition would be losing something to overhead.
Perhaps some of the motivation for the uncommon bus width has to do with bandwidth being set aside for ECC. The non-ECC game console could instead use that bandwidth for game purposes.
Not sure how that's without performance penalty, though.

 

In xbox one all data is encrypted on external devices such as memory. There is an on apu processor that deals with it.

Could they roll their own parity and encryption / decryption solution into the apu that's transparent to the cpu / gpu to achieve the same?

 

Encryption uses a key value or set of key values to convert values in memory into different values. The hardware that performs the conversion at speed can hold those keys internally and can reverse the process when reading.
An alteration to an encrypted location is virtually guaranteed to produce data that is garbage upon decryption, but the hardware wouldn't have the necessary context to know that an error occurred or have the information necessary to pinpoint or correct it.
Error correction uses extra memory associated with the data to monitor for values modified by errors, and can detect errors to a certain number of bit flips and possibly correct some errors based on choice of the encoding and amount of ECC data. ECC data has a certain amount of bits per chunk of data, and it costs that extra amount of bandwidth as well. CPUs increase the width of their 64-bit memory channels to 72 bits to include ECC, and that includes a matching increase in chip count to hold the extra storage. The CPU loads ECC data at the same time, and doesn't see the extra bandwidth or capacity as being usable for other purposes.

GPUs that implement ECC when the memory modules don't support it natively have set aside space in memory to hold the data, and perform additional memory accesses to get the ECC data. I'm not sure how that requirement can be made zero-cost.

 

How did I miss this doozy in the DF article.

Hmm, even more additional customization around executeIndirect?
Yes please!

Well I guess given the audience these small details were unlikely to be announced yet, or that Richard is being asked to release more details on it at a later time.

 

So are haircuts.

 

Zero cost to who is the question.

Zero cost to the code running on the GPU I suspect is what the quote infers , not Zero cost to the silicon budget.

 

I am pretty sure I referenced it to you in one of our conversations in this thread when you talked about MS work on X1 and X1X command processor and if they will continue down that part on the XSX.

 

I just want separate audio in splitscreen while using headsets.

 

Reading too fast LOL

 

The cost referenced is cost in performance. The GPU would be able to detect a drop in available bandwidth.

 

What makes you think that's not a standard feature of RDNA2?