Next Generation Hardware Speculation with a Technical Spin [2018]

[Tkumpathenurple]

EU power regulations say no. The home user could opt-in FaH-style, but that removes the cheekiness,no? Besides, there's no need for hardware parity to make this work. Any connected console with compute resources could be used this way with the proper software running.

Oh, right, I didn't realise the EU had yet another law that would stymie this. Silly me, thinking an anti-democratic, totalitarian regime wouldn't

Anyway, FaH style would be best and, as you said, not cheeky. Maybe they could even give people incentive to partake e.g. set a FaH type thing going, and for every hour, you get £1 worth of points in your wallet (if points are still how MS's store works).

As for hardware parity, I was thinking more along the lines of the same architecture, but at different scales, so the same algorithm can run on the servers or the consoles, but at different speeds. Not parity as such, just designed around ease of deployment of code.

 

[Shifty Geezer]

Anyone thinking this shows less commitment to console gaming, just refuses to see the benefits of spreading the costs, especially when you consider everyone else will be doing streaming also.

I think that's missing the argument. Rather than designing a console SOC to be the perfect device for a console, the suggestion here is the SOC has been designed to be the perfect cloud-server device used for MS's cloud compute services for industry etc. What's good for global compute may not be what's best for local console gaming.

I'm not saying that's what's happening, but it is a legitimate concern and not a blind refusal to acknowledge the truth. The counter point, say Sony's PR, would be, "we've designed our silicon only for our console, no compromises, to deliver the best possible gaming experience for our gamers without diluting the interests across broader markets."

As ever, there are pros and cons and no one, true way.

 

[AlNom]

I think that's missing the argument. Rather than designing a console SOC to be the perfect device for a console, the suggestion here is the SOC has been designed to be the perfect cloud-server device used for MS's cloud compute services for industry etc. What's good for global compute may not be what's best for local console gaming.

Couple questions (idk):

What is an ideal cloud-server design? Power efficient, high throughput. Clockspeeds work against power consumption as you go higher, but you can go wider too. You can go higher clocked when the process/nodes are mature though or if you bin them.

Does the spreading of cost over cloud ultimately afford them a bigger budget per local unit?

hm...

(not sure where I'm going with this. Just random threads )

 

[iroboto]

I think that's missing the argument. Rather than designing a console SOC to be the perfect device for a console, the suggestion here is the SOC has been designed to be the perfect cloud-server device used for MS's cloud compute services for industry etc. What's good for global compute may not be what's best for local console gaming.

I'm not saying that's what's happening, but it is a legitimate concern and not a blind refusal to acknowledge the truth. The counter point, say Sony's PR, would be, "we've designed our silicon only for our console, no compromises, to deliver the best possible gaming experience for our gamers without diluting the interests across broader markets."

As ever, there are pros and cons and no one, true way.

Yea, but the goal here is whether there will be cost advantages in favour here for such a thing. We linked earlier to the costs to producing a console and if the numbers are going to be massive, then we may be able to see a less efficient design (lets say vs curated specially only for the home console) at a cost point it shouldn't be at.

The marketing point for MS at this point in time should be, your games anywhere anytime. And if this is what enables someone to play in their living room and continue in their bathroom and then on their commute to work. Yes, I think the trade off for silicon that supports such a service is perhaps something they can leverage to their advantage.

No one is going to care about compromises if the competition has a better product overall at the same price points.

 

[iroboto]

Couple questions (idk):

What is an ideal cloud-server design? Power efficient, high throughput. Clockspeeds work against power consumption as you go higher, but you can go wider too. You can go higher clocked when the process/nodes are mature though or if you bin them.

Does the spreading of cost over cloud ultimately afford them a bigger budget per local unit?

hm...

It should, I don't see why it wouldn't. You can immediately order up massive production amounts because you need to fill your data centres and your consumer side. If your consumer side is lower on demand, you fulfill your data centres. If your consumer side is high on demand you fulfill your consumers. This helps them get around seasonality, in which hardware sales tend to be much lower after the christmas break.

 

[AlNom]

It should, I don't see why it wouldn't. You can immediately order up massive production amounts because you need to fill your data centres and your consumer side. If your consumer side is lower on demand, you fulfill your data centres. If your consumer side is high on demand you fulfill your consumers. This helps them get around seasonality, in which hardware sales tend to be much lower after the christmas break.

Quite. So what then?

Go on.

 

[iroboto]

Quite. So what then?

Go on.

i don't know
so.. lets just say the biggest applications right now are supporting ML at the edge. And MS, Google, Amazon, FB and others are fiercely trying to get into the last mile loop everywhere to deploy their hardware to support real time self driving and other applications like that. MS has some plans with spectrum, and the goals here are to get everything ready by the time 5G rolls around. Everyone has to be thinking the same thing as well. The end game is going to be wireless, and I'm not sure everyone understands the types of speeds we can get to rural by the time we hit 2021. The only issue is capital and getting the infrastructure setup before we start to push the hardware out to support it. It's a massive undertaking and a great deal of many companies will be pushing on the telcos to support their services and platforms.

If that hardware is going to be used, for everything, the Xbox, the industries etc. Then your'e looking at massive large scale deployment, massive capital costs, massive ordering numbers. You're looking into the quite a lot of blades, memory, etc to support so much across the _WORLD_, and I'd be super fucking shocked if AMD secured such a massive deal.

Maybe I should buy some stock just in case.

 

[Jay]

I think that's missing the argument. Rather than designing a console SOC to be the perfect device for a console, the suggestion here is the SOC has been designed to be the perfect cloud-server device used for MS's cloud compute services for industry etc. What's good for global compute may not be what's best for local console gaming.

I'm not saying that's what's happening, but it is a legitimate concern and not a blind refusal to acknowledge the truth. The counter point, say Sony's PR, would be, "we've designed our silicon only for our console, no compromises, to deliver the best possible gaming experience for our gamers without diluting the interests across broader markets."

As ever, there are pros and cons and no one, true way.

That could be true, but starting from a base design and then optimising for the target platform could yield big benefits.
Optimising is where i see things like mcm coming into play, although we have no idea about that yet.
It will be harder if it's a big monolythic chip though.

But, I still don't think you can say it's MS not showing commitment/focus to consoles.
Recognising that gpu's are huge compute devices and not to make other use of them would be a huge waste in the cloud where the "console" gpu will also be located .

 

[mrcorbo]

I think that's missing the argument. Rather than designing a console SOC to be the perfect device for a console, the suggestion here is the SOC has been designed to be the perfect cloud-server device used for MS's cloud compute services for industry etc. What's good for global compute may not be what's best for local console gaming.

I'm not saying that's what's happening, but it is a legitimate concern and not a blind refusal to acknowledge the truth. The counter point, say Sony's PR, would be, "we've designed our silicon only for our console, no compromises, to deliver the best possible gaming experience for our gamers without diluting the interests across broader markets."

As ever, there are pros and cons and no one, true way.

The success of the whole endeavor is dependent on the quality and quantity of games available on the platforms and no matter how much MS invests in studios this cannot be determined by exclusives alone. Not designing around an SoC that will produce the best gaming experience possible first and foremost runs counter to this.

Azure doesn't need propping up, it's doing spectacularly well. So, it's unlikely MS are designing this so gamers will help foot the bill for an Azure server expansion.

And aren't power and thermal demands as much a limitation of a SoC destined to live inside a games console, which has to be reasonably small and quiet to sell, as they are for SoCs destined to live inside a server rack where noise, at least, is not a concern and you can move a lot more air?

Sharing a SoC design between the server and console doesn't have to result in a compromised experience on console. Is there any reason someone can come up with that makes it more likely than not that it will? Or is it enough reason for concern that this is a possible outcome, whatever the likelihood of it coming to pass?

 

[Shifty Geezer]

Yea, but the goal here is whether there will be cost advantages in favour here for such a thing. We linked earlier to the costs to producing a console and if the numbers are going to be massive, then we may be able to see a less efficient design (lets say vs curated specially only for the home console) at a cost point it shouldn't be at.

The marketing point for MS at this point in time should be, your games anywhere anytime. And if this is what enables someone to play in their living room and continue in their bathroom and then on their commute to work. Yes, I think the trade off for silicon that supports such a service is perhaps something they can leverage to their advantage.

No one is going to care about compromises if the competition has a better product overall at the same price points.

I agree, potentially the economic advantages are cramming more, less refined silicon in a console. It can still be argued in such cases that MS aren't that interested in console gaming, and are just leveraging their other strengths to pander to this small, gaming market. Of course, that in itself may not be a bad thing. Kinda like epic Hollywood studios churning out big budget movies for the sake of money versus tiny art-house film makers doing it for the purity of the art on a shoe-string budget - the massive, soulless corporation still produces stuff people actually want and enjoy.

 

[iroboto]

And aren't power and thermal demands as much a limitation of a SoC destined to live inside a games console, which has to be reasonably small and quiet to sell, as they are for SoCs destined to live inside a server rack where noise, at least, is not a concern and you can move a lot more air?

Sharing a SoC design between the server and console doesn't have to result in a compromised experience on console. Is there any reason someone can come up with that makes it more likely than not that it will? Or is it enough reason for concern that this is a possible outcome, whatever the likelihood of it coming to pass?

They share similar requirements.
Power is the largest monthly operating expense (possibly at times competing for realestate costs, I guess this is dependent on size) for all data centres. More power means less chips per cabinet because there are cooling thresholds that will be reached faster, also means less chips per data center where realestate is limited if you are attempting to get ML to the edge.

And if the chip is being deployed for enterprise ML and compute usage. You're looking at massive quantities where binning the lower end chips for data centres will make more sense and selling the higher clocked chips as consoles.

You've effectively circumvented the need for redundant CUs as a cost cutting measure. You just put the lower grade silicon in data centers where individuality makes no difference. Sell the high grade chips as console stuff and you don't need the bin the prices higher either. A long time ago they cited 3 xboxes in the cloud for each xbox console there is.
So you could skim the upper 25% of SoC as your baseline target for the console, and the remaining 75% can go into the data centers.

Everyone wins, consumer gets the best possible performance, servers get their cooler running chips.

 

[eastmen]

https://en.m.wikipedia.org/wiki/Sega_Net_Link

I think the Daytona netlink release is one of the top collectors items for the Saturn.

that was great , I have sega rally and love it. I got my ass beat one day for having a $100 phone bill lol. My parents quickly switched to just a regular phone line in the den

 

[Tkumpathenurple]

You've effectively circumvented the need for redundant CUs as a cost cutting measure. You just put the lower grade silicon in data centers where individuality makes no difference. Sell the high grade chips as console stuff and you don't need the bin the prices higher either.

I agree with what you're saying, but wouldn't it be the other way around: higher grade chips in data centres? I've long been under the impression that's standard practice - with CPU's, anyway.

- If a chip can clock higher than its lower binned variant, it can, instead, run at the same clockspeed as said lower binned variant, but do so at a lower temperature.

- A little bit more horsepower on the server end could help produce a more stable stream.

- Let's assume the following, for argument's sake: the home consoles use 18 CU's per chiplet, the streaming servers use all 20. If just one CU fails for the home user, they need to buy a new console. If just one CU fails in a data centre, they don't have to replace anything, just step it down to run code at the same speed as the home console.

Chiplets or not, binning seems like a good idea. Binning and multi tiered consoles are the way forward IMO. Best hardware in servers, that just below it for a flagship console, the lion's share for a mainstream console, and the stuff that's just limping along to throw in a little streaming box, which can emulate this generation's base console. Boom! Most of a wafer used, even the bits that'd be barely worth pissing on if they were on fire.

 

[Tkumpathenurple]

Here's the graph I had in mind. The clockspeeds for sorted chips fall within a bell curve. I don't know if this is widely the case or not, can anyone help clear that up for me please?

If true, and using it as a flawed example, they could bin:

- 2.7+GHz for the servers. Approximately 40 per wafer. Maybe stick two in each "server console", making it, effectively 20 per wafer.

- 2.5 and 2.6 for the flagship console. Approximately 60 per wafer. As above, effectively, 30 per wafer.

- 2.3 and 2.4 for the mainstream console. Approximately 60 per wafer.

- 2.2GHz and below for the streaming console. Approximately 40 per wafer.

It would all need to be weighted differently, in accordance with sales projections - given that we know the Pro sells about 20% as many consoles as the base unit - but it's about time the console manufacturers took advantage of a technique that's been used in the semiconductor industry for donkey's years.

 

[iroboto]

I agree with what you're saying, but wouldn't it be the other way around: higher grade chips in data centres? I've long been under the impression that's standard practice - with CPU's, anyway.

You're thinking about up-time running 100% all the time at nearly 100% or you're just thinking server grade hardware is very expensive?

Desktop components run significantly higher clockspeeds than server chips as you're looking for superior single threaded performance for local applications and you want to run cooler in the datacenter as operating costs are super high for cooling. Online you're supporting everything, so going wide matters much more, feature-sets matter more, server CPUs tend to have a great deal of many more cores than desktop components.

The traditional approach is to run server grade hardware, but they also don't run integrated GPUs in the traditional approach either. This would be a custom SoC to support MS enterprise stack. Your applications you're trying to support the resolution is lower for streaming, you don't need 4K60 streaming. So...

 

[BRiT]

You want high performance with low power usage in the data centers, which means not chasing the GHz.

 

[Jay]

When you bin for server your looking for lowest voltage supporting chips.

Another thing that would probably be bit more pushing boat out in terms of ideas is, if something is borderline into being worthy of going into a console may make it due to being there for the server part, example a tensor type core/accelerators.

 

[iroboto]

When you bin for server your looking for lowest voltage supporting chips.

Another thing that would probably be bit more pushing boat out in terms of ideas is, if something is borderline into being worthy of going into a console may make it due to being there for the server part, example a tensor type core/accelerators.

tensor flow is very specific to NN type work, outside of 16-bit computation, you're going to have a pretty useless card. And this is where I don't know necessarily if this is a good fit for large global deployment if you're looking to maximize the usage of the hardware, you want to support as many applications as possible.

 

[Jay]

tensor flow is very specific to NN type work, outside of 16-bit computation, you're going to have a pretty useless card. And this is where I don't know necessarily if this is a good fit for large global deployment if you're looking to maximize the usage of the hardware, you want to support as many applications as possible.

Tensor was something that popped into head as example. Possibly bad one.
It's about the concept that an accelerator may make it into the console because they've added it onto the server part.

 

[mrcorbo]

The potential for modular design with chiplets really expands if you have the ability to validate and bin the chiplets prior to them being assembled onto a package. That's where having the same basic building blocks across multiple products allows for the most salvage of produced dies and the most aggressive clocks for the semi-custom designs where, once assembled, the product is only good for few or one application(s). Removing the limitation of how many completed packages you would have to throw away from the calculation of how many functional units you can support and what clockspeeds you can target for your design and only being limited by how many chiplets that meet those targets can be produced allows you to aim higher on the bell curve than you can with current methods. Any chiplets that don't meet those targets can still be used for a lower spec SKU from anywhere in AMDs product stack.

I don't know if this is possible, but it has huge implications if it is.