Support NeoGAF

[hellmonkey]

Unless there was a PS4 CPU upclock, XB1 has 10% more CPU performance.

Serious question, Do we know if the there is a dedicated chip for the ps4 OS? I know its been rumored it some spec sheets, but I don't know if it has been confirmed or not. If there is a dedicated chip for the OS, that would free up the CPU. So even though the xbone CPU is faster, it has dedicated functions so its free resources could be less than the ps4 CPU.

Again, this assumes there is a ps4 OS chip and no OS chip in the xbone. If that's not true, then my post is garbage.

 

[onQ123]

Serious question, Do we know if the there is a dedicated chip for the ps4 OS? I know its been rumored it some spec sheets, but I don't know if it has been confirmed or not. If there is a dedicated chip for the OS, that would free up the CPU. So even though the xbone CPU is faster, it has dedicated functions so its free resources could be less than the ps4 CPU.

Again, this assumes there is a ps4 OS chip and no OS chip in the xbone. If that's not true, then my post is garbage.

But we don't know everything that it does.

 

[dragonelite]

But we don't know everything that it does.

From what i gathered its used for io task

 

[ElTorro]

But we don't know everything that it does.

It probably only manages I/O-related security and acts as an online endpoint while the console is in hibernation. Probably it's some ARM like almost all those processors nowadays.

 

[Crisco]

Serious question, Do we know if the there is a dedicated chip for the ps4 OS? I know its been rumored it some spec sheets, but I don't know if it has been confirmed or not. If there is a dedicated chip for the OS, that would free up the CPU. So even though the xbone CPU is faster, it has dedicated functions so its free resources could be less than the ps4 CPU.

Again, this assumes there is a ps4 OS chip and no OS chip in the xbone. If that's not true, then my post is garbage.

Lol there is no "dedicated OS chip", that wouldn't even make sense to do from an architectural standpoint. There is dedicated hardware to manage background downloading, video encoding/decoding, and audio streaming though, which will make up the bulk of the OS services during gameplay. There is literally no benefit to actually running the kernel off a dedicated chip though.

 

[Naminator]

But we don't know everything that it does.

This was a while a go so I don't remember.

But wast he just simply talking about background downloading/updating?

 

[SenjutsuSage]

Tiling is nothing new in graphics cards, its been around for decades, if not longer, Microsoft likes to mention things that are standard though as if developers might not understand they are there otherwise.

I'm not referring to how new it might be, I'm referring to the fact that Microsoft has made customizations to the hardware that put dedicated hardware in place that is capable of handling common GPU tasks, and how this may aide the system.

In Microsoft's dev document from early last year, they point out that an implication of 1 of the shared move engines having jpeg and lz decoding capabilies is that resource files can be kept in compressed formats and unpacked in hardware. Know what that reminds me of, and why I think it could be more significant than it seems?

It reminds me of an important change AMD made when they went from Cayman to GCN.

http://www.anandtech.com/show/4455/amds-graphics-core-next-preview-amd-architects-for-compute/4

So what’s in a Compute Unit? Just as a Cayman SIMD was a collection of SPs, a Compute Unit starts with a collection of SIMDs. 4 SIMDs are in a CU, meaning that like a Cayman SIMD, a GCN CU can work on 4 instructions at once. Also in a Compute Unit is the control hardware & branch unit responsible for fetching, decoding, and scheduling wavefronts and their instructions. This is further augmented with a 64KB Local Data Store and 16KB of L1 data + texture cache. With GCN data and texture L1 are now one and the same, and texture pressure on the L1 cache has been reduced by the fact that AMD is now keeping compressed rather than uncompressed texels in the L1 cache. Rounding out the memory subsystem is access to the L2 cache and beyond. Finally there is a new unit: the scalar unit. We’ll get back to that in a bit.

I see Microsoft essentially taking that idea, or wherever they got the idea from, but it was one of the important changes in GCN to the L1 cache, and applying that concept in a way to the XB1 that I think is a net benefit to the system and for the 32MB of ESRAM. Remember, the size of the 32MB of ESRAM is a concern, because, well, it's only 32MB, right? But if AMD improved their 16KB L1 caches in GCN by only holding compressed data in there, then you could say applying that same concept to 32MB of ESRAM in some fashion doesn't seem like too bad an idea. You can imagine then how being able to keep data that's inside the ESRAM in a compressed format, which helps save space and will allow you to store more in there, only to then be able to unpack that compressed data directly for use by using fixed function hardware on the move engines specifically put in place to handle that responsibility, might be a very smart way to go about things. Because now you have a scenario where neither the GPU or the CPU specifically need to always handle this task themselves, leaving both to do other things. Now this may seem small to us, but it might prove a big deal to developers. As is well documented, developers do incredible work with very small amounts of memory, so these little bits of saved memory here or there, or spare cpu and gpu cycles can be more important than we think.

And that's all I'm saying. Microsoft clearly made some interesting customizations of their own that seem to expand quite a bit on certain hardware capabilities, just like sony did with their own hardware. If nothing else, Microsoft's own customizations are likely being ignored solely because XB1 isn't perceived as better competing with the PS4 on raw power and performance numbers. This is why I usually try to ignore the very basic comparison between the two systems, because we already know the numbers, but those numbers don't have to also mean that Microsoft's own efforts to aide developers in getting the most out of their system were useless, even if it takes some time for this all to fully click. All in all, it will be fun looking forward to what devs do on both systems. Man, I'm exhausted. Stayed up all night practically expecting to be called in to work, since I'm on call and was told to be on standby, and now I get a call saying I'm off for the day, which is awesome, but now I'm probably going to sleep the rest of the day

 

[Arkham]

What's an ACE?

(finger shooting) You, baby. (clickclick)

 

[KidBeta]

I see Microsoft essentially taking that idea, or wherever they got the idea from, but it was one of the important changes in GCN to the L1 cache, and applying that concept in a way to the XB1 that I think is a net benefit to the system and for the 32MB of ESRAM. Remember, the size of the 32MB of ESRAM is a concern, because, well, it's only 32MB, right? But if AMD improved their 16KB L1 caches in GCN by only holding compressed data in there, then you could say applying that same concept to 32MB of ESRAM in some fashion doesn't seem like too bad an idea. You can imagine then how being able to keep data that's inside the ESRAM in a compressed format, which helps save space and will allow you to store more in there, only to then be able to unpack that compressed data directly for use by using fixed function hardware on the move engines specifically put in place to handle that responsibility, might be a very smart way to go about things. Because now you have a scenario where neither the GPU or the CPU specifically need to always handle this task themselves, leaving both to do other things. Now this may seem small to us, but it might prove a big deal to developers. As is well documented, developers do incredible work with very small amounts of memory, so these little bits of saved memory here or there, or spare cpu and gpu cycles can be more important than we think.

Sure its a good idea, but just a side note here, why would they have native JPEG decompression when no one uses JPEG compressed textures for games? LZ makes sense as there are common formats that are LZ packed (and the PS4 has hardware LZ too), but JPEG doesn't really make sense. Not to mention it would be smarter to store it as a native texture compressed format (BC1-7 for example) that the GPU supports, therefore not blowing out your L2/Tex cache by using something the GPU can't read compressed.

 

[satam55]

But seeing that PS4 has been customized for running more GP code on it's GPGPU, Xbox CPU advantage seems to be lost.

This!!! That CPU upclock was always irrelevant.

 

[AmFreak]

I would still like to see any evidence or argument supporting the notion that Microsoft's architecture is more efficient than the raw numbers suggest. I have the impression that it is all just based on the assumption that "it just cannot be" that Microsoft let this performance gap happen.

The thing that baffles me the most, is that they (Microsoft) seem kind of suprised. I mean they must have known that a machine like this wouldn't get them the performance crown. The only thing in that console that is high-end or better said not easy to beat is the amount of ram.

 

[vpance]

The thing that baffles me the most, is that they (Microsoft) seem kind of suprised. I mean they must have known that a machine like this wouldn't get them the performance crown. The only thing in that console that is high-end or better said not easy to beat is the amount of ram.

Yes of course they know it's weaker, and have even during inception. That won't stop PR from spinning though.

 

[SenjutsuSage]

Sure its a good idea, but just a side note here, why would they have native JPEG decompression when no one uses JPEG compressed textures for games? LZ makes sense as there are common formats that are LZ packed (and the PS4 has hardware LZ too), but JPEG doesn't really make sense. Not to mention it would be smarter to store it as a native texture compressed format (BC1-7 for example) that the GPU supports, therefore not blowing out your L2/Tex cache by using something the GPU can't read compressed.

I imagine they wouldn't have put it in there if it wasn't somehow useful for games, as I don't think the engineers would make such a silly mistake. On second thought, the mistake seems to be on my end, and your post helped me spot it. This doesn't seem to be jpeg decompression, but jpeg decoding. I guess it turns it into something that can then be used directly by the GPU for games.

This is what I got from the Move Engine article on vgleaks.

The move engine takes as input an entire JPEG stream, including the JFIF file header. It returns as output an 8-bit luma (Y or brightness) channel and two 8-bit subsampled chroma (CbCr or color) channels. The title must convert (if desired) from YCbCr to RGB using shader instructions.

The same move engine that supports LZ decoding also supports JPEG decoding. Just as with LZ, JPEG decoding operates as an extension on top of the standard DMA modes. For instance, a title may decode from main RAM directly into a sub-rectangle of a tiled texture in ESRAM.

The thing that baffles me the most, is that they (Microsoft) seem kind of suprised. I mean they must have known that a machine like this wouldn't get them the performance crown. The only thing in that console that is high-end or better said not easy to beat is the amount of ram.

That's the thing, though. Should they have been after some performance crown in the first place? Or should they simply worry more about building a system that can make significantly better looking games than what was ever possible on the Xbox 360? Would anyone disagree that they did that much? I'd argue that's all they really needed to do. They don't need to be stronger than the PS4, or even closer performance wise than they already are. For example, look how impressive Ryse looks at launch. Can you imagine the possibility that we may eventually look at Ryse graphically and not be all that impressed? If Crytek can pull that off at launch, then surely power shouldn't be too big a concern, I would think.

 

[Neuromancer]

This was a while a go so I don't remember.

But wast he just simply talking about background downloading/updating?

That was my understanding.

Maybe it can be used for other OS stuff like party chat.

 

[onQ123]

From what i gathered its used for io task

It probably only manages I/O-related security and acts as an online endpoint while the console is in hibernation. Probably it's some ARM like almost all those processors nowadays.

This was a while a go so I don't remember.

But wast he just simply talking about background downloading/updating?

Yeah but it's a few less things for the CPU to have to deal with in the OS. also the Video/Audio chips are also helping with the OS for things like Video/Audio Chat & game streaming & remote play.

 

[KidBeta]

I imagine they wouldn't have put it in there if it wasn't somehow useful for games, as I don't think the engineers would make such a silly mistake. On second thought, the mistake seems to be on my end, and your post helped me spot it. This doesn't seem to be jpeg decompression, but jpeg decoding. I guess it turns it into something that can then be used directly by the GPU for games.

This is what I got from the Move Engine article on vgleaks.

As vgleaks says it decodes the compression and the game must use GPU cycles to convert it to RGB if it wants it in RGB space. Another should be made that JPEG is rather cheap once you have LZ, so don't think just because it was included theres some hidden efficiency meaning it would be retarded to encode textures in JPEG, BC1-7 would probably get 2-4x the compression level whilst looking better and also staying compressed in the GPU's cache, so being even better for performance.

Also note that the JPEG and LZ decompression aren't exactly the fast things in the world with the DME's.

For JPEG your looking at 373MB/s at the most, to break that down per frame for you, at 30FPS thats. 12.4MB/frame, you couldn't even fill up the entire eSRAM with it.

LZ decode is 200MB/s and encode is 150-200MB/s.

 

[AmFreak]

Yes of course they know it's weaker, and have even during inception. That won't stop PR from spinning though.

Ya, but even their PR with pennelo posting in a forum / on twitter and major nelson taking an enternity to prepare a "hardware analysis" seems everything besides being prepared.

 

[gruenel]

The thing that baffles me the most, is that they (Microsoft) seem kind of suprised. I mean they must have known that a machine like this wouldn't get them the performance crown. The only thing in that console that is high-end or better said not easy to beat is the amount of ram.

I'm pretty sure they knew they would lose the performance battle with this machine, they just didn't expect the public to care that much. Just like they didn't expect the huge backlash after the DRM fiasco.

They really underestimated how passionate the hardcore gaming crowd is about their hobby.

 

[Kazuma Kiryu]

Maybe they talk to developers who are working on both and listen to their responses and also get a glimpse of side by side comparisons? The you have somebody like John Carmack who knows all about coding suggest they are very alike as well.

We will never get a fair assessment of both consoles. For that we would need true spec sheets, not PR releases with fuzzy math (what ALWAYS happens when new consoels launch), detailing the hardware.
Any comparison Microsoft wants to make is, even without seeing it, completely pointless. You really believe a company will make a tech analysis that ends up with "yeah, we're weaker"? The same goes for Sony, there's still some stuff we don't know about their console, and they would never say "yeah, we're weak".
Microsoft doesn't know Sony's hardware, and Sony doesn't know Microsoft's hardware.
There's no way any comparison Albert cooks up won't be biased, just like it would be if Cerny did one.
It's a pointless endeavour, but it's pretty clear they're scraping the bottom of the barrel trying to salvage their image.

 

[Crimson_Fate]

We will never get a fair assessment of both consoles. For that we would need true spec sheets, not PR releases with fuzzy math (what ALWAYS happens when new consoels launch), detailing the hardware.
.

I think we will get a decent comparison as soon as MS allows Indies to publish.
We should get some fair and honest comparison at that point at least from a benchmark point of view.

 

[SenjutsuSage]

As vgleaks says it decodes the compression and the game must use GPU cycles to convert it to RGB if it wants it in RGB space. Another should be made that JPEG is rather cheap once you have LZ, so don't think just because it was included theres some hidden efficiency meaning it would be retarded to encode textures in JPEG, BC1-7 would probably get 2-4x the compression level whilst looking better and also staying compressed in the GPU's cache, so being even better for performance.

Also note that the JPEG and LZ decompression aren't exactly the fast things in the world with the DME's.

For JPEG your looking at 373MB/s at the most, to break that down per frame for you, at 30FPS thats. 12.4MB/frame, you couldn't even fill up the entire eSRAM with it.

LZ decode is 200MB/s and encode is 150-200MB/s.

I know the speeds, but I really don't think their of much issue when you're dealing with 32MB worth of ESRAM. 12.4MB per frame sounds more than good enough when you're dealing with such a small size It really doesn't seem that you would require much faster than that, and you most likely have no need to be able to fill the entire thing in one go through jpeg decoding since important data is more than likely to already be stored in ESRAM anyway even before the JPEG decoding. And, looking at it another way, why necessarily look at it as "filling" ESRAM? Maybe all the necessary data is there already, and the only thing the jpeg decoding is doing is converting data already resident in ESRAM in a way that the GPU can make use of. In this scenario you're simply working with data already in ESRAM, but not with an intent to "fill it up" with anything.

On both LZ decompression and JPEG decoding, I think for what they're being used for, and what it would take from either CPU or GPU to perform the tasks themselves, the move engine speeds are more than acceptable, because in both the case of LZ decompression and JPEG decoding, I think their speeds are a perfect fit for the ESRAM size, even though they won't exclusively be used for data in ESRAM. I think they considered the size of ESRAM thoroughly into their calculations when deciding how fast the decoding hardware needed to be on that shared move engine..

Oh man, I'm ready to pass out now. Going to sleep.

 

[KidBeta]

I know the speeds, but I really don't think their of much issue when you're dealing with 32MB worth of ESRAM. 12.4MB per frame sounds more than good enough when you're dealing with such a small size It really doesn't seem that you would require much faster than that, and you most likely have no need to be able to fill the entire thing in one go through jpeg decoding since important data is more than likely to already be stored in ESRAM anyway even before the JPEG decoding. And, looking at it another way, why necessarily look at it as "filling" ESRAM? Maybe all the necessary data is there already, and the only thing the jpeg decoding is doing is converting data already resident in ESRAM in a way that the GPU can make use of. In this scenario you're simply working with data already in ESRAM, but not with an intent to "fill it up" with anything.

On both LZ decompression and JPEG decoding, I think for what they're being used for, and what it would take from either CPU or GPU to perform the tasks themselves, the move engine speeds are more than acceptable, because in both the case of LZ decompression and JPEG decoding, I think their speeds are a perfect fit for the ESRAM size, even though they won't exclusively be used for data in ESRAM. I think they considered the size of ESRAM thoroughly into their calculations when deciding how fast the decoding hardware needed to be on that shared move engine..

Oh man, I'm ready to pass out now. Going to sleep.

I'm sorry but you would be insane to rely heavily on JPEG's for anything in game theres just no reason to as I mentioned in my past 3 posts the main problem is you blow out your cache, I cannot think of a single reason for having a JPEG decoder except for maybe doing PiP or something similar, but thats not related to games at all.

 

[Knuf]

That's the thing, though. Should they have been after some performance crown in the first place? Or should they simply worry more about building a system that can make significantly better looking games than what was ever possible on the Xbox 360? Would anyone disagree that they did that much? I'd argue that's all they really needed to do. They don't need to be stronger than the PS4, or even closer performance wise than they already are. For example, look how impressive Ryse looks at launch. Can you imagine the possibility that we may eventually look at Ryse graphically and not be all that impressed? If Crytek can pull that off at launch, then surely power shouldn't be too big a concern, I would think.

You keep saying that if exclusives look that impressive, the Xbone is surely powerful enough, yet you are failing to see the flipside of the whole power gap discussion: MS 1st parties are by far weaker than Sony's or Nintendo's.
Last gen, the 360 was the favourite console for 3rd party games simply because most of them run better there. Next gen it will be the opposite, and when 3rd party games run 50% or even 10% better on PS4, the Xbone will have huge problems finding the same market share among gamers, considering a) the weaker hardware, b) the weaker 1st party output (and you know that now that Bungie left, Halo is not that killer app anymore) and c) the higher price.
I think MS realized this and are now so worried about the power gap, they will use every smoke and mirror they can trying to hide it, but it's as real as it can get.

 

[twobear]

It could to some extent, but it would require a lot of micromanagement of your rendering and you'd probably still never get utilization as good as with a unified architecture.

Thanks for the clarification.

 

[Sword Of Doom]

Serious question, Do we know if the there is a dedicated chip for the ps4 OS? I know its been rumored it some spec sheets, but I don't know if it has been confirmed or not. If there is a dedicated chip for the OS, that would free up the CPU. So even though the xbone CPU is faster, it has dedicated functions so its free resources could be less than the ps4 CPU.

Again, this assumes there is a ps4 OS chip and no OS chip in the xbone. If that's not true, then my post is garbage.

I don't have a link but I remember hearing Cerny talk about a secondary chip in the ps4 to help with multi-tasking. I don't know if that's the same "OS chip" you're referring to.

 

[onQ123]

Posted yet?


"albertpenello Director of Product Planning
Sorry no intent to tease. I promised we'd let our architects speak about our system, and we should have something to share soon. Don't expect a bomb, but it should explain in depth our architecture and how the paper specs don't tell the full story. Again, I just spent time at TGS looking at both platforms - after E3, Gamescom, and PAX and I still insist our games look awesome."

http://www.reddit.com/r/xboxone/comments/1msxoy/according_to_albert_penello_more_xbox_one/

 

[KidBeta]

Posted yet?


"albertpenello Director of Product Planning
Sorry no intent to tease. I promised we'd let our architects speak about our system, and we should have something to share soon. Don't expect a bomb, but it should explain in depth our architecture and how the paper specs don't tell the full story. Again, I just spent time at TGS looking at both platforms - after E3, Gamescom, and PAX and I still insist our games look awesome."

http://www.reddit.com/r/xboxone/comments/1msxoy/according_to_albert_penello_more_xbox_one/

I expect tech details but also a lot of PR fluff.

 

[artist]

Posted yet?


"albertpenello Director of Product Planning
Sorry no intent to tease. I promised we'd let our architects speak about our system, and we should have something to share soon. Don't expect a bomb, but it should explain in depth our architecture and how the paper specs don't tell the full story. Again, I just spent time at TGS looking at both platforms - after E3, Gamescom, and PAX and I still insist our games look awesome."

http://www.reddit.com/r/xboxone/comments/1msxoy/according_to_albert_penello_more_xbox_one/

How soon before Penello adopts the "who looks at graphics anymore, it's gameplay that matters" approach?

 

[SwiftDeath]

How soon before Penello adopts the "who looks at graphics anymore, it's gameplay that matters" approach?

You mean the "let games speak for themselves" approach?

Because he's already used that one

I guess it'd be nice to see MS PR go full circle

 

[LittleJohnny]

The 50% number seems to be overall performance, not just GPU. It's probably also factoring in RAM benefits, API ease of use, and OS reserves.

Didn't the talk of 50% come before MS increased the clocks? Now the difference is 40% on paper.

 

[cchum]

How soon before Penello adopts the "who looks at graphics anymore, it's gameplay that matters" approach?

Launch day

 

[onQ123]

Didn't the talk of 50% come before MS increased the clocks? Now the difference is 40% on paper.

I don't think so because in the same article they talk about one of the devs saying that the clock boosted didn't change much.

 

[LittleJohnny]

I expect tech details but also a lot of PR fluff.

But don't we get that from both sides? How can one confidently assume one side has zero PR fluff? I'm really looking forward to detailed info from the architects.

 

[artist]

You mean the "let games speak for themselves" approach?

Because he's already used that one

I guess it'd be nice to see MS PR go full circle

Well he's insisting on comparing the IQ of the games on both systems and limiting them to launch only, probably going to limit it to exclusives as well.

Launch day

Are you expecting IQ difference in launch multi-plats between Xbone and PS4?

 

[cchum]

Are you expecting IQ difference in launch multi-plats between Xbone and PS4?

On a few: yes

 

[LittleJohnny]

I don't think so because in the same article they talk about one of the devs saying that the clock boosted didn't change much.

Right, but what I got from reading was basically that they were disappointed with the results (Results already mentioned) and MS responded by increasing the clock, which they think will not really help much but something is better than nothing. This doesn't mean they already have updated dev kits and the comments are referring to before MS' reaction.

 

[SwiftDeath]

Well he's insisting on comparing the IQ of the games on both systems and limiting them to launch only, probably going to limit it to exclusives as well.

Not sure how good a comparision that would be then

Multiplats offer the best comparison imo

 

[szaromir]

On a few: yes

I think all games will have better IQ. It's the easiest and best way to use the extra power in my opinion.

 

[shinra-bansho]

I expect tech details but also a lot of PR fluff.

Maybe it will be in the form of an informative chart, like that one for the localisation/voice command details.

...

 

[Nightengale]

The only thing I'm hoping for from Penello is revelations regarding Sony's architecture used as points for comparison. ( I'm assuming they're comparing... since that's what Penello has been doing before backing off )

The whole 'deep-dive to explain that there's more to the system than specs' + a bit of PR is par-for-course for all major technology companies. The only interesting thing is what kind of story they'll put Sony's system as a benchmark for comparison.

 

[user8503492]

I wish I understood .000001% of what you guys are talking about :/

All I know is I go between GAF and a XBox One Forum and I don't understand what exactly is going on except over their they bash GAF in every other post saying you guys are "Sony Fanboys" and you guys twist and spin suff to make MS look bad and the One look weak.

I honestly have no idea, but I put more faith in what you guys say then a random Xbox forum with a handful of members.

Wish thier was a cliffs notes attached to every post lol
I feel like I grasped the PS3/Cell vs. 360 arguement better last gen now I'm completely lost..

 

[Klocker]

I expect tech details but also a lot of PR fluff.

so we ae gong to assume they are lying already?

ok got it.

 

[Nightengale]

so we ae gong to assume they are lying already?

ok got it.

PR fluff aren't lies, they're beautified truth*.

*in the best circumstances

And Sony does PR fluff too. Remember the whole 'LCD is not inferior to OLED' comment?

Which wasn't a lie, but it's only true in a few metrics. Overall the perception is that the old OLED is still better, but inferior in some respects.

 

[Klocker]

PR fluff aren't lies, they're beautified truth*.

*in the best circumstances

And Sony does PR fluff too.

perhaps but if this is actually "GAF's technical crew" upon whom we all rely to get to the bottom of the technical specs (as they claim to know) then I would hope that they would actually want to hear what they don't yet know about the system that may now be revealed and might allow then to form different conclusions.

prejudicing the evidence before it's heard does not sound like the way to do that imo


not to mention far from scientific

 

[Finalizer]

The thing that baffles me the most, is that they (Microsoft) seem kind of suprised.

Sums up my perspective as well, and on a much more broad level than just performance. Seemed MS believed that either Sony would be totally asleep at the wheel or that they themselves could throw out whatever device they wanted and the masses would lap it up thanks to the Xbox brand. I wonder if higher-ups at MS thought they had a chance at becoming the Apple of the living room and failed to notice they totally missed their mark.

Didn't the talk of 50% come before MS increased the clocks? Now the difference is 40% on paper.

Seems the Xbone reserves ~10% of its GPU power for OS functions, so we're still suck on 50%.

Wee numbers~

so we ae gong to assume they are lying already?

Wouldn't be the first time.

 

[neohwa]

ps3 is more powerful than x360 too but does it really matter?

in fact a lot of ps3 ports is worse than x360. so I hope next gen will be different.

 

[Metfanant]

ps3 is more powerful than x360 too but does it really matter?

in fact a lot of ps3 ports is worse than x360. so I hope next gen will be different.

and how many times does it need to be explained that this is completely irrelevant to the current generation?

 

[SwiftDeath]

ps3 is more powerful than x360 too but does it really matter?

in fact a lot of ps3 ports is worse than x360. so I hope next gen will be different.

Matters far more this time as the architectures are worlds more similar

Cell was a PITA to develop for

No one would argue that but it appears this time round the PS console is the one easier to develop for so that extra power will unlikely go to waste

 

[KidBeta]

so we ae gong to assume they are lying already?

ok got it.

I expect them to gloss over some important details, because they don't want to be compared directly officially.

 

[Finalizer]

ps3 is more powerful than x360 too but does it really matter?

in fact a lot of ps3 ports is worse than x360. so I hope next gen will be different.

For the umpteenth time, wildly different architectures, particularly the PS3 is much more difficult to work with and really leverage its potential. Totally different compared to PS4 vs Xbone, where you've got AMD APUs powering both machines.