Hey you like those!!
Xbox One (Durango) Technical hardware investigation
- Thread starter Love_In_Rio
- Start date
- Status
I agree that 16 cores would be real overkill but why should they be relevant in the scenario? Even 8 is already overinflated so why would they all needed to be available for the game? They could be disabled or used for the OS.
There has already been speculation here about forward compatibility and a fast HW update strategy. What would be a difference here between 2 SKUs where one has just the dual GPU setup? Using 2 smaller chips just for yield reasons doesn't sound that pie in the sky to me. But whatever, it's all speculation anyway.
If they were going with 2 APU's what says both need 8 Jaguar cores?
I'd thinking adding a 2nd APU with 2 jag cores and maybe 6cu's would close the performance gap. The 2 cores could power the OS functions and the CU's run as compute unit. It doesn't solve interconnect issues, but avoids having 600mm of silicon in the box.
/devils advocate.
I'd thinking adding a 2nd APU with 2 jag cores and maybe 6cu's would close the performance gap. The 2 cores could power the OS functions and the CU's run as compute unit. It doesn't solve interconnect issues, but avoids having 600mm of silicon in the box.
/devils advocate.
Two separate GPUs is an awfully big risk to the overall platform. GPUs have never found a universally satisfactory, reliable, or consistent implementation of multi-GPU rendering, and their implementations have always had it as an afterthought.
Perhaps Microsoft invested serious money into making that not a problem, but there are obvious demands for inter-APU communication, GPU coordination, and serious questions as to how reliable such a setup would be. It might be a matter of saving a few pennies after all the packaging and board routing complexity is taken into account, but making the 720 wildly inconsistent or faulty in return.
Perhaps Microsoft invested serious money into making that not a problem, but there are obvious demands for inter-APU communication, GPU coordination, and serious questions as to how reliable such a setup would be. It might be a matter of saving a few pennies after all the packaging and board routing complexity is taken into account, but making the 720 wildly inconsistent or faulty in return.
Paul Thurrot of win supersite stated that there will be multiple Xbox's announced this year. It was from 2 weeks ago on all about windows from the twit network.
What the Xbox's will be who knows
At the same time multi gpu set ups are really only found in pc's and not closed box platforms.
A console with two gpu's could get high levels of synergy by coding for what does work with 2 gpus well and avoiding what doesn't.
I'm also not sure why the 720 would be inconsistent and faulty . If anything the rumor would be to have 2 smaller chips than the ps3. Which would mean more chips per wafer and lower power / heat per chip. Instead of one huge chip that is more power hungry and produces more heat.
As others have said 8 core jaguar + 12 cu gpu and then a second 2 or 4 core jaguar with 12cu gpu.
This would fit into Paul Thurrot saying there will be multiple Xbox's this year. Dual APU for high end , single APU for low end.
Replace the 360 with a BC 8core/12 cu apu and now you got a $150 console that doesn't use to much more power than the current 360 and can play next gen games at 720p. At the high end of $400 you have the xbox next that can play the same games with better graphics at 1080p .
As time goes on you phase out the single APU unit and perhaps your able to combine the Dual APU unit into a single one.
Its the only way the dual APU would make sense and it would fit with the multiple xbox rumor from an actual insider .
How much would a single APU + 8 gigs of ram cost ms ? Could it be slotted in at current xbox 360 prices ?
What $30 or so for the ram $70 or so for the APU . So $100 for the main components , maybe another $100 for the rest of the system ? Boom you got a replacement xbox 360.
IMG does fine with multi-GPU rendering. They're on the same chip but that doesn't necessarily matter.
Not having to communicate over PCIe probably helps. Durango wouldn't need to have this problem. If there are multiple SoCs they may be on an MCM and afforded some advantage in interconnect.
There's a need for high-bandwidth communication between the APUs. The need for coordination between two separate graphics systems is going to add complexity, and latencies at the level of workflow control are harder to hide.
The same reason why one game might scale 70% with an SLI rig while the next has zero scaling, or why there are multiple game patches or driver releases for stability problems.
Cheaper silicon doesn't save money if it adds uncertainty as to whether the system will or will not lock up.
Multi-GPU functionality does not have a history of robust implementation, and the GPUs themselves are not currently structured to take it seriously. The rumors concerning Durango haven't made the case that they've significantly changed that.
In the absence of interposer integration, and even then, it is not more power-efficient to pass scads of data over external wires. Some of that data is going to be command processor or front-end communication between GPUs, which is data traffic that does not exist in a unified design. Or there is minimal coordination, and the platform is inconsistent or unreliable.
Only if the dual GPUs are abstracted away. If the state and command systems of the graphics chips are exposed to software, it will be a source of trouble for existing code if you suddenly take half of it away.
Wrong three-letter named GPU provider, unfortunately.
In fixed target software you're trying to eke the absolute maximum from the hardware, the original XBox was doing things an equivalent PIII + GPU could never have done because of the 'to the tin' coding. If I have n cores that change I'm restricted in what I can do because I can't assume there presence. Unlike say mip-mapping or MSAA the availability of more cores does not allow you to scale in a straight forward manner. Having variable compute resources depending on SKU would make s/w development a nightmare.
A small ARM core for the O/S could make sense as they could return some resources to devs but would also involve re-engineering from what has been revealed by multiple sources (discounting 1 post accounts and such). A second APU would be grossly expensive just for the O/S and wouldn't help b/c at all.
B/C is dead and gone 400 low power x86 cores couldn't emulate a triple core PPC design let alone one that runs at twice the clock rate of the x86 cores. Either MS puts an entire 360 SoC on the board or they do it via the cloud, with the transition to x86 there just is no other way. Ars Technica had a great article about emulating early 8-bit systems that highlights the real technical challenges that come with emulating h/w in s/w. Especially as we're talking about s/w that was designed for the ground up to drive the h/w at 100. In particular I don't believe emulating the EDRAM is possible at all. Please feel free to contradict me forum goers if you know any different.
http://arstechnica.com/gaming/2011/...-3ghz-quest-to-build-a-perfect-snes-emulator/
Here's an article discussing the challenges of emulation using the SNES 25Mhz cpu that requires a 3.0Ghz x86 core to emulate correctly. And correct emulation matters for game code, I suspect if they do Classics releases this gen the code will be based off the PC builds (if they exist) rather than attempting to emulate PPC
Here's an article discussing the challenges of emulation using the SNES 25Mhz cpu that requires a 3.0Ghz x86 core to emulate correctly. And correct emulation matters for game code, I suspect if they do Classics releases this gen the code will be based off the PC builds (if they exist) rather than attempting to emulate PPC
SenjutsuSage
Newcomer
Hmm, I suppose there could be a way they could build on extra GCN compute units, but as apart of a separate, much less powerful APU? When I think about it like this, it doesn't sound that crazy. If people are expecting dual APUs that are each sporting their own 8 core jaguar processor, as well as their own 12 CU GCN GPU, then that's probably way too out there and just won't happen, but perhaps the only thing that makes this seem insane is the fact that people are overlooking the strong possibility of making a notably weaker APU.
Much weaker cpu and an equivalent or lesser GPU compared to the stronger APU doesn't seem all that far fetched, and I think there's more than enough expertise involved on Microsoft and AMD's end, particularly with those IBM people involved, to make it happen. That doesn't mean it will, but I think they have the skill and expertise to pull it off. They would just have to come up with a way to make that weaker APU fit in and work seamlessly with the stronger APU, not necessarily every part of the weaker APU, but perhaps just some of the lesser APU's gpu resources?
Maybe this is where that Oban information from IBM comes in. Maybe Oban is simply a way to make this possible. Developers already know how to develop on an SLI style system, I don't see how this would be all that drastically different, even if you couldn't extract the full performance of both gpus simultaneously for double the performance, which whenever dual gpu in a console comes up, seems to be the unfair hurdle that must be cleared in order for it to become practical.
You're still more or less assured to get the full performance of one in addition to some of the extra resources from the secondary gpu. They would just have to make sure that the stronger APU's gpu is the boss in the entire equation. How the two gpus work together could more or less be hidden from developers, so they wouldn't need to worry about micro-managing it all.
They simply just develop their games, they see what is possible performance wise with the added benefits of the extra gpu resources, and then they more or less plan from there based on what they think they can achieve. This rumor may not be true, but what's being suggested, when you look at it the right way, isn't entirely impossible. To say that it is, we'd be turning a blind eye to all that we know exists and is possible on the pc side. Is it truly impossible to bring a dual gpu setup of some kind to a console?
2 separate, weaker apus might require less power and produce less heat than one monster apu.
Much weaker cpu and an equivalent or lesser GPU compared to the stronger APU doesn't seem all that far fetched, and I think there's more than enough expertise involved on Microsoft and AMD's end, particularly with those IBM people involved, to make it happen. That doesn't mean it will, but I think they have the skill and expertise to pull it off. They would just have to come up with a way to make that weaker APU fit in and work seamlessly with the stronger APU, not necessarily every part of the weaker APU, but perhaps just some of the lesser APU's gpu resources?
Maybe this is where that Oban information from IBM comes in. Maybe Oban is simply a way to make this possible. Developers already know how to develop on an SLI style system, I don't see how this would be all that drastically different, even if you couldn't extract the full performance of both gpus simultaneously for double the performance, which whenever dual gpu in a console comes up, seems to be the unfair hurdle that must be cleared in order for it to become practical.
You're still more or less assured to get the full performance of one in addition to some of the extra resources from the secondary gpu. They would just have to make sure that the stronger APU's gpu is the boss in the entire equation. How the two gpus work together could more or less be hidden from developers, so they wouldn't need to worry about micro-managing it all.
They simply just develop their games, they see what is possible performance wise with the added benefits of the extra gpu resources, and then they more or less plan from there based on what they think they can achieve. This rumor may not be true, but what's being suggested, when you look at it the right way, isn't entirely impossible. To say that it is, we'd be turning a blind eye to all that we know exists and is possible on the pc side. Is it truly impossible to bring a dual gpu setup of some kind to a console?
2 separate, weaker apus might require less power and produce less heat than one monster apu.
The problem with dual anything being 'transparent' to deveopers is that has two outcomes it's either a) variable benefits (witness SLI and the unending wait for profiles every time a title launches) or b) no benefit. It's not possible to create a compiler that can statically analyse a body of code and decide 'OK these functions are fine for the slow CPU the rest goes on the daddy'. If there are multiple chips then developers have to be expose to that explicitly so they can exploit the benefits. Part of the problem with Cell was that simply setting the output flag for your compiler to PS3 produced awful unoptimised results. It was only when developers specifically started to code their hardware for the odd heterogenous PPC + SPE architecture that PS3 started to look good in comparisons.
If MS have a compiler that can allow developers to exploit unannounced hardware by 'auto-magically' re-aligning code then they are wasting this technology on game code
If MS have a compiler that can allow developers to exploit unannounced hardware by 'auto-magically' re-aligning code then they are wasting this technology on game code
The point I'm trying to make is that custom solutions that don't need to rely on standard PCI-E interconnects and conventional APIs could have an easier time dealing with it. It can't be totally ruled out.
Lalaland said:
That level of accuracy is not needed for commercially viable backwards compatibility. It isn't even needed for the majority of SNES games; what you get in Virtual Console is surely nowhere close to this. And bsnes isn't really pushing performance optimization techniques to the max, even for its extreme level of accuracy.
If the tradeoff is < 5% of games not working properly (and perhaps detected and flagged up front) vs no BC a tall they'll gladly accept it.
But I don't think 8x 1.6GHz Jaguars will be able to handle Xenon either, even with a very optimized emulator, unless real world utilization was very poor.
SenjutsuSage
Newcomer
What I'm thinking is why would developers even need to bother making their games any differently? Isn't there a strong possibility that the only reason sli issues exist on the pc is because not every single game is designed for sli in the first place, and even if they were, there's still no guarantee that someone has the exact same sli or crossfire setup?
This wouldn't be much of an issue on a closed box where you know exactly what every user will have inside their system.
If Microsoft and AMD with the support of those IBM people can find a way to boost game performance to a reasonable degree through the help of a secondary, weaker apu's gpu without developers having to strictly code for that secondary apu's gpu in order to still notice performance benefits from it, then, and this hypothetical, would Microsoft necessarily have to tell developers about this? I think it would wholly inconsequential to the development of quality, early release titles. A lot of developers not knowing that the PS4 had an extra 4GB of GDDR5 coming won't prevent them from making great games.
The extra 4GB just falls into place, devs don't necessarily have to change what they're doing and how they're doing it if they don't want to, do they? I've seen a lot of sli/crossfire setups on the pc 'just work' providing the extra performance benefit without too much hassle.
If there are any inconsistencies observed in the relative performance gain, can't that simply just be boiled down to pc developers not having any sort of guarantee that everybody will be running the same hardware?
People on the pc right now can take their sli setup and play all kinds of games and see meaningful performance improvements, can't they? I still highly doubt this is true, but I just don't see why this is viewed as impossible or way too complex for developers to manage. Would this be anywhere close to the complexity of a cell processor?
A second GPU only would not be anything like two cpu complexity but it comes back to what I referred to as scenario A, the results are too inconsistent. Developers couldn't code to the metal for SLI (e.g. splitting the rendering of objects and terrain and then compositing later) because they couldn't be sure it would be available on any given users system. More likely they would focus on delivering the best experience possible for the singe card scenario and leave the gains from SLI to driver/system updates much the same way PC developers leave that to AMD/Nvidia. Anything more complex from a design perspective comes back to the problem of spending resources for only a subset of your userbase that could deliver a better overall result if focused on things that benefit both groups of users.
Extra RAM is a much simpler thing to exploit as it just lets you do 'more', so if your engine loads 50 km2 of terrain with 4GB maybe it can load 100-110 with 8GB. It doesn't alter your code much beyond that, any extra functional hardware such as CPU or GPU resources have to be specifically coded for. The exception is clockspeed that really does just go faster without any extra work involved unless you've coded up something that exploits timing tricks based on the slower clockspeed.
I don't know enough to say whether a second smaller, slower GPU could really benefit a larger, faster GPU. In the PC space the only benefit I've seen is using an old card as a PhysX device, the attempts to SLI different cards or to SLI an APU + discrete GPU have never really seemed to deliver (I'm thinking of VirtX, was it?, that m/b chip). The disparity between dissimlar architectures and clockspeeds really hurts any attempt to use the same code for both so we're back then to having to consciously exploit it making the system more complex. If it was in every box and MS had a great API that could exploit it 'automagically' then it would be quite cool but from what little I learnt about compilers it just sounds far fetched to me.
Extra RAM is a much simpler thing to exploit as it just lets you do 'more', so if your engine loads 50 km2 of terrain with 4GB maybe it can load 100-110 with 8GB. It doesn't alter your code much beyond that, any extra functional hardware such as CPU or GPU resources have to be specifically coded for. The exception is clockspeed that really does just go faster without any extra work involved unless you've coded up something that exploits timing tricks based on the slower clockspeed.
I don't know enough to say whether a second smaller, slower GPU could really benefit a larger, faster GPU. In the PC space the only benefit I've seen is using an old card as a PhysX device, the attempts to SLI different cards or to SLI an APU + discrete GPU have never really seemed to deliver (I'm thinking of VirtX, was it?, that m/b chip). The disparity between dissimlar architectures and clockspeeds really hurts any attempt to use the same code for both so we're back then to having to consciously exploit it making the system more complex. If it was in every box and MS had a great API that could exploit it 'automagically' then it would be quite cool but from what little I learnt about compilers it just sounds far fetched to me.
SenjutsuSage
Newcomer
This is all I'm saying. They would optimize to their heart's content on the main apu gpu, and then leave the rest of the gains, gains that they would be able to ascertain for themselves without ever shipping their game, up to the secondary gpu much like they do in pc game development.
That's all I'm saying. So this makes it very possible for console game development without the need for extra complexity.
There is at least some precedent for having a high-powered Application APU and a lower powered System APU (the yukon leak), but really none for having two high powered APUs in "Crossfire" mode. So as cool as the idea of Durango being twice as powerful as imagined, i just don't see it.
What really are the issues with an OS APU and Application one? If the display planes composite the two outputs together and they have their own DDR3 memory is there really that much crosstalk needed between the two?
What really are the issues with an OS APU and Application one? If the display planes composite the two outputs together and they have their own DDR3 memory is there really that much crosstalk needed between the two?
Both needs access to Kinect and voice data.
It'll be a massive waste to have it be replicated across two memory pools.
What I failed to add were the points made by others about how this increases cost substantially without really offering any guarenteed benefits. Think about it as an upsell proposition it's hard to as $100 or more for 'up to' 70% faster, particularly to the majority of folks buying it as an item of consumer electronics rather than as a computer. If I pay $100 more for model A over model B it had damn well better give me a guaranteed boost or else I'm going to feel cheated particularly if game X is 'only' 20% and that game is Madden or CoD. Too much cost for too little gain.
Of course until there are any official specs released I have my crow in the deep freeze, just in case
- Status
Similar threads
- Locked
