However lockhart only needs very small GPU size (for example, 20CUs @ 1.55GHz), and the APU size is probably 200mm2 which is way cheaper than a 350mm2 APU.
I think the defected APU of XSX would be used in other place such as xcloud servers.
Next Generation Hardware Speculation with a Technical Spin [post E3 2019, pre GDC 2020] [XBSX, PS5]
- Thread starter DavidGraham
- Start date
-
- Tags
- john sell
- Status
However lockhart only needs very small GPU size (for example, 20CUs @ 1.55GHz), and the APU size is probably 200mm2 which is way cheaper than a 350mm2 APU.
I think the defected APU of XSX would be used in other place such as xcloud servers.
Yea I think I agree with this @RDGoodla.
Binning Anaconda is fine for the server environment. They only need to disable WGP that are actually defective.
But to bin the parts such that _all_ of the WGP are being reduced to 4TF might be very expensive relative to the wafer size.
If Lockhart is coming to console - I think it will be a different APU as per the size reduction for having a much smaller footprint.
If Lockhart is on the cloud; then I see this as a 4 TF reservation on binned Anaconda chips, the remaining GPU power being used as Azure compute.
Doing some quick math on a 300mm wafer.
A = pi*r^2
A = pi * (300/2)^2
A = 70684.335 mm2
so this will fit ~ 196 Anaconda Chips at 360mm2
or
353 Lockhart chips at 200mm2
almost 1/2 price per chip.
Though realistically, lets assume Lockhart is closer to One S in size at 240mm2
it would be ~294 chips per wafer.
I wouldn't bin if the sizes are like this.
Binning Anaconda is fine for the server environment. They only need to disable WGP that are actually defective.
But to bin the parts such that _all_ of the WGP are being reduced to 4TF might be very expensive relative to the wafer size.
If Lockhart is coming to console - I think it will be a different APU as per the size reduction for having a much smaller footprint.
If Lockhart is on the cloud; then I see this as a 4 TF reservation on binned Anaconda chips, the remaining GPU power being used as Azure compute.
Doing some quick math on a 300mm wafer.
A = pi*r^2
A = pi * (300/2)^2
A = 70684.335 mm2
so this will fit ~ 196 Anaconda Chips at 360mm2
or
353 Lockhart chips at 200mm2
almost 1/2 price per chip.
Though realistically, lets assume Lockhart is closer to One S in size at 240mm2
it would be ~294 chips per wafer.
I wouldn't bin if the sizes are like this.
Last edited:
Certainly.
What would be curious is socket compatibility. i.e. a cut-down big chip (non-compliant retail Anaconda) shouldn't be functionally different than the smaller chip from a certain point of view.
I'm not really arguing anything here.
---
Two designs make the most sense for economy of scale.
They won't have 100% yield on either.
They can try to claw black the 5-15% unacceptable big dies if they could reuse them in the lower end SKU. e.g. disabling enough of the units to bring the TDP/wattage under control and/or lol-defects.
All just hypothetical perspective.
What would be curious is socket compatibility. i.e. a cut-down big chip (non-compliant retail Anaconda) shouldn't be functionally different than the smaller chip from a certain point of view.
I'm not really arguing anything here.
---
Two designs make the most sense for economy of scale.
They won't have 100% yield on either.
They can try to claw black the 5-15% unacceptable big dies if they could reuse them in the lower end SKU. e.g. disabling enough of the units to bring the TDP/wattage under control and/or lol-defects.
All just hypothetical perspective.
Last edited:
Like trying to determine if they would need to make a new mono for hypothetical lockhart console?
Folks are heartily locked into thinking of either A) a single die with unusable ones feeding the affordable mass market solution, but that's a bit backwards and self-defeating, or B) simply two designs.
Given the higher cost per larger chip and knowing that there will be a non-insignificant percentage of non-compliant big-chips, there's a good chance those ones can simply be repurposed alongside a smaller chip as a supplement, so those unacceptable big ones aren't just a total loss.
edit:
That's assuming they make things pin-compatible etc.
Last edited:
hmm.
Then it's possible; but you're introducing more variation into patches/drivers/updates/OS etc. Much more difficult for someone to understand why Lockhart 1 person the game works fine, and Lockhart person 2 it does not (but they don't know which chip they have).
We sort of run into these types of issues already; and everyone has the same chip but sometimes it's manufactured at a different fab.
? The cut-down chips would just appear to be Lockhart spec on boot.
Just another caffeine-induced idea :V
Yea I see where you're going with this. Yea maybe. But why not just use them as server chips then? You don't need to artificially reduce redundancy CUs down to 4 TF. Just disable the bad WGP and host them in the cloud?
Idea is just to reuse them.Why is everyone thinking they would have cut down dies at all? If the theoretical lockhart die is half the size of the anaconda die, it makes no sense to use cut down dies because you'd have to fab way more silicon. You can throw away 20% of the dies and still be ahead if you assume a production of half and half for each console because you are basically throwing away half a wafer every time you fab a big die that only needs the performance of a smaller die. Realistically, it only makes sense if the cut is small and you don't want to deal with the fix cost of designing and producing 2 dies.
Consoles have always just locked down a small % of the chip to improved yields and will probably do it this time. 7nm+ will be very similar to 7nm and yields should be good. The processing of actually cutting down to salvage dies doesn't make sense economically if the difference between the 2 proposed dies is large and the volume expectations of the small die is high.
Also mixing the 2 types of dies, cut down anaconda and full lockhart, to use in lockhart consoles is going to be a nightmare for design and configurations for something as fixed as a console. I really doubt they would go through the trouble of this unless the yields of the big dies is abysmal, which would make the console prohibitively expensive anyways.
Consoles have always just locked down a small % of the chip to improved yields and will probably do it this time. 7nm+ will be very similar to 7nm and yields should be good. The processing of actually cutting down to salvage dies doesn't make sense economically if the difference between the 2 proposed dies is large and the volume expectations of the small die is high.
Also mixing the 2 types of dies, cut down anaconda and full lockhart, to use in lockhart consoles is going to be a nightmare for design and configurations for something as fixed as a console. I really doubt they would go through the trouble of this unless the yields of the big dies is abysmal, which would make the console prohibitively expensive anyways.
The idea partly depends on how far they want to push the large die requirements for retail.
I don't think designing an all-encompassing motherboard is too much to ask for if they're intending to go for dual-SKU in the first place. Depending on how the market splits 6 months down the road post-launch, they can then optimize costs for the little things in terms of supply needs, which is fairly normal.
I don't think designing an all-encompassing motherboard is too much to ask for if they're intending to go for dual-SKU in the first place. Depending on how the market splits 6 months down the road post-launch, they can then optimize costs for the little things in terms of supply needs, which is fairly normal.
How would the binned chips be any different to a smaller made chip, the die size will change but the actual chip could have the same socket.?
If disabling cu's causes a problem how do they manage for normal chips where any 2 out of 64 are dissabled, that's a lot of different configurations.
The assumption would be Lockhart is the exact same chip with less active cu's either by binning and or creating a smaller die.
Slim consoles are on a totally separate node and in the last gen case vary from initial spec. I am sure these take a little work but are ok.
It would only be visible to the hypervisor I would assume anyway and be know ahead of time so no nasty surprises, with Hobos method to make them sing at a minimum acceptible spec and voltage.
If disabling cu's causes a problem how do they manage for normal chips where any 2 out of 64 are dissabled, that's a lot of different configurations.
The assumption would be Lockhart is the exact same chip with less active cu's either by binning and or creating a smaller die.
Slim consoles are on a totally separate node and in the last gen case vary from initial spec. I am sure these take a little work but are ok.
It would only be visible to the hypervisor I would assume anyway and be know ahead of time so no nasty surprises, with Hobos method to make them sing at a minimum acceptible spec and voltage.
DavidGraham
Veteran
Before we say that, we need to put the two under the same workload and then test and see how far they are apart. As simply running a game on Xbox One X and measuring power draw is not enough. Games on consoles are locked to certain fps ceiling for consistency, and are also vsync'ed, they also drop fps regularly because they are CPU limited, all of these factors reduce power draw.
For example, DF measured a consumption of 128w running Gears 4 at 1080p60 mode, but measured 175w running the same game at 4K30. There is bound to be games/scenes that push the system even harder. You need to test the RX580 at the same workload (Gears 4, 1080p60/4K30) to see if it really draws much more power than the One X or not. Simply stating the RX580 draws more power than the entire console is not really logical.
Last edited:
Nevertheless, it's not a comparison of Apples to Apples, as RX580 is the GPU and board alone, while the console includes CPU, Optical Drive, Hard Drive, etc...
Metal_Spirit
Regular
One question for the more tech minded.
RDNA brings performance gains due to better internal efficiency.
Eurogamer made some tests using GPUs at with similar clock speeds and bandwidth, and saw Navi with gains in the order of 62% against Tahiti, and 28% against Polaris.
But those gains are calculated with basis on the PC. So here's my question!
Consoles have GPU usage very highly optimized. And also make heavy use of GPGPU when he is idle.
Efficiency gains are a good thing, but also mean the GPU is less time idle, and that means less GPGPU against older architectures. So the question is... realistically, what performance gains you guys belive RDNA will have on console against Xbox One Tahiti, and Xbox One X hybrid Polaris?
RDNA brings performance gains due to better internal efficiency.
Eurogamer made some tests using GPUs at with similar clock speeds and bandwidth, and saw Navi with gains in the order of 62% against Tahiti, and 28% against Polaris.
But those gains are calculated with basis on the PC. So here's my question!
Consoles have GPU usage very highly optimized. And also make heavy use of GPGPU when he is idle.
Efficiency gains are a good thing, but also mean the GPU is less time idle, and that means less GPGPU against older architectures. So the question is... realistically, what performance gains you guys belive RDNA will have on console against Xbox One Tahiti, and Xbox One X hybrid Polaris?
Going back to a leak from October 8th.
https://www.ptt.cc/bbs/PC_Shopping/M.1570476662.A.7A0.html
^^^ Sparkman is now confirmed to be Lockhart. OP seems to know something since he nailed Sparkman.
https://www.ptt.cc/bbs/PC_Shopping/M.1570476662.A.7A0.html
OP translated to english said:
^^^ Sparkman is now confirmed to be Lockhart. OP seems to know something since he nailed Sparkman.
OP in later part of the thread said:
Last edited:
anexanhume
Veteran
The problem is that none of those are consistent with performance numbers we’re given. PS5 is supposedly 10TF or greater, and XSX is over 10TF, possibly 12TF. They’re doing that in less area than Navi 10 + Zen 2, which still needs area for what the I/O die has as well.
Either one of the sources are wrong, or they’re using 7nm+. In PS5’s case, perhaps they’ve removed the GDDR6 controllers and are using HBM with the controller die in the stack. But that’s the only way the numbers seem to work without insane clocks, which we’re told is not the case on XSX at least.
Flute benchmarks suggest that L3 is quartered in the PS5. That's ~22mm2 freed up.
Also the OQA leak said 316mm2, and my measurement for Scalett was 360mm2 minimum. The 300/350 figures might be generous rounding to the nearest 50.
Just my 2 cents.
Btw, you already know that I am a 7nm+ non-believer.
Last edited:
How many CUs in that 360mm² APU at 7nm ?
- Status
Similar threads
- Locked
