Since Xbox runs a stripped down Win8, can it be hacked?

[Sohaltang]

Do you have an actual source on MS saying that? I haven't seen anything about them claiming anything of the sort.

Sorry speculation I guess.. It was not MS who made the claim I read this earlier

http://blogs.barrons.com/techtrader...didate-says-nomura/?mod=yahoobarrons&ru=yahoo

 

[mmntech]

It it has a computer in it, you can hack it. Though getting it to run a full version of Windows 8 is doubtful. A custom Linux distro might be possible though. However, it would likely require some sort of hard mod, which would probably get it banned from XBL. I doubt you could get it to dual boot like you used to be able to do on the PS3, and even the original Xbox.

 

[Aikouka]

Fair enough. So you think this 40$ AMD dual core CPU will perform equal to the 8 core CPU that is in the Xbone?

I'd have to look at the CPU architectures in question, but it also depends on what you're doing. Anyway, I wrote my response to your comment which I assumed was based on someone choosing a Haswell i5 (a quad-core CPU) for their build.

 

[smackababy]

Sorry speculation I guess.. It was not MS who made the claim I read this earlier

http://blogs.barrons.com/techtrader...didate-says-nomura/?mod=yahoobarrons&ru=yahoo

Okay, first of all, they are morons if they actually think they are going to be able to put out 4.3 million units in the December quarter. Second, the Xbox BOM is estimated around $331; which is more than MS is paying for that volume. R&D will take awhile to get the total unit profitable, but losing $1 billion after selling that many units is pretty iditoic to believe.

Also, take into account the licensing fee on EVERY SINGLE GAME SOLD for the console. MS isn't losing money on the Xbox One.

 

[Sohaltang]

Okay, first of all, they are morons if they actually think they are going to be able to put out 4.3 million units in the December quarter. Second, the Xbox BOM is estimated around $331; which is more than MS is paying for that volume. R&D will take awhile to get the total unit profitable, but losing $1 billion after selling that many units is pretty iditoic to believe.

Also, take into account the licensing fee on EVERY SINGLE GAME SOLD for the console. MS isn't losing money on the Xbox One.

Im pretty sure "december quarter" means launch to end of February.

Anyhow as smart as any of us are, Rick Sherlund has a huge history of financial research and 20 years focusing mainly on just M$. His opinion trumps anything you I or the rest of us can speculate. Dude is getting paid the serious big bucks to make the projections. Get back to me after you spend 24 years at Goldman Sachs :biggrin:

 

[smackababy]

Im pretty sure "december quarter" means launch to end of February.

Anyhow as smart as any of us are, Rick Sherlund has a huge history of financial research and 20 years focusing mainly on just M$. His opinion trumps anything you I or the rest of us can speculate. Dude is getting paid the serious big bucks to make the projections. Get back to me after you spend 24 years at Goldman Sachs :biggrin:

His speculation is to buy MS. Him speculating their to be 4.2 million Xbox One units available by February pretty much goes against every hardware launch in history. Plus, him calculating MS' losses makes little sense given the cost of the console. I highly doubt R&D costs around $2 billion (factoring in the sale of the Xbox Ones minus BOM is a profit of over $700 million for that many consoles sold). Now, the Xbox division profits were down recently due to R&D costs, but not by some huge number.

If MS sells 4.2 million consoles in the holiday quarter, they will not lose a billion dollars.

 

[Rakehellion]

Ehh, a 7790 + Haswell i5 is going to run BF4 at 1080p smoothly with settings all to high, with 2x MSAA. That's hands down better than the XB1 port.

Battlefield is a game that can run on the Xbox 360. When games are released that take advantage of the unique hardware of the next gen systems, there won't be a comparison.

Sharing memory is to SAVE MONEY and have a simpler system to manufacture. At the expense of performance.

110% false. Unified memory removes the step of copying memory between CPU and GPU space, an enormous performance advantage.

They have a price point to hit, so you get the shared memory. This is the same dealio with 95%+ of PCs as well. You get shared memory because it's cheap and 'good enough'.

An integrated GPU on a regular PC does not have unified memory. You still have to copy memory back and forth even though they're sharing the same physical chips.

 

[Arkaign]

Battlefield is a game that can run on the Xbox 360. When games are released that take advantage of the unique hardware of the next gen systems, there won't be a comparison.



110% false. Unified memory removes the step of copying memory between CPU and GPU space, an enormous performance advantage.



An integrated GPU on a regular PC does not have unified memory. You still have to copy memory back and forth even though they're sharing the same physical chips.

An enormous performance advantage?

Compare :

GPU memory assets loaded into dedicated memory for the GPU to operate from at GDDR5 speeds

vs.

GPU memory assets loaded into dedicated memory for the GPU to operate from at DDR3 speeds.

In PC terms, every single example you can find of same GPU, same bus, same clock speeds MASSIVELY favors the GDDR5 variant. So we start with that.

Now 'unified' memory doesn't mean jack squat. Why? Because memory for video functions HAS NO USE from an OS/Game engine standpoint once it's loaded and ready to use for video (texture, frame buffer, etc).

THERE IS NO PERFORMANCE VALUE TO SHARING MEMORY WITH CPU AND GPU

THERE IS NO PERFORMANCE VALUE TO SHARING MEMORY WITH CPU AND GPU

THERE IS NO PERFORMANCE VALUE TO SHARING MEMORY WITH CPU AND GPU

THERE IS NO PERFORMANCE VALUE TO SHARING MEMORY WITH CPU AND GPU

Why? Because the actual time it takes to transfer texture and other GPU-needed data to the video memory is laughably irrelevant in terms of an issue worth worrying about. Particularly at 1080p. When even slow DDR3 can transfer as many dozens of gigabytes per second on antiquated bus setups, what makes you think there is any value whatsoever for the CPU and GPU to be able to access the same information? And once you exhaust what's already in system memory, well then you're talking about accessing a glacially slow mechanical HDD or optical disc.

The fact, no matter how much spin anybody can put on this, is that sharing memory between the GPU and CPU/OS is worthless other than for saving money. The game resources and OS resources are utterly different than the kind of data that a GPU needs to work with.

 

[Arkaign]

To put a bullet on it : with a unified/shared memory setup, your total bandwidth must be divided by cpu and gpu access. If you start with 100% bandwidth available, and keeping your gpu fed for a game is taking 60% of that value, then only 40% remains for non gpu functions. This is an intractable limitation of that design. It's there for cost savings and design simplification, period. No educated person on the subject exists that can rationally argue with that, because it's the simple truth.

Beware idiot marketing which tries to sell things which are baloney.

 

[Sohaltang]

So MS and sony spend an untold of fortune to develop a console that a couple of joes blows can improve upon with 400$ and newegg in less than 15 minutes...? Sure. If you could really build a comparable machine for 400$ with off the shelf parts they would have built it. Those two companies could buy those parts for half what we can. The ps4 retails 18$ lmore than production cost. Not counting the r/d. Maybe sony and MS should have hired a couple techies from this forum To build them a superior gaming machine for less.

This subject was beaten to death before the launch on the gpu forum. Pretty much everyone agreed that the only PC that could compete would cost 700$+

 

[Rakehellion]

In PC terms, every single example you can find of same GPU, same bus, same clock speeds MASSIVELY favors the GDDR5 variant. So we start with that.

Now 'unified' memory doesn't mean jack squat. Why? Because memory for video functions HAS NO USE from an OS/Game engine standpoint once it's loaded and ready to use for video (texture, frame buffer, etc).

Because current generation games (Battlefield 4) are designed around the fact that you have a slow bus separating CPU and GPU memory so they make fewer attempts to copy data back and forth.

Why? Because the actual time it takes to transfer texture and other GPU-needed data to the video memory is laughably irrelevant in terms of an issue worth worrying about.

If it weren't for the unified memory space, it would be impossible for the Xbox One and PS4 to record video in realtime without a framerate hit. Your PC can't do that.

The game resources and OS resources are utterly different than the kind of data that a GPU needs to work with.

This line doesn't even make sense.

Have you ever written a 3D game engine? I have. Every single resource that the GPU gets is created and fed by the CPU at some point down the line.

To put a bullet on it : with a unified/shared memory setup, your total bandwidth must be divided by cpu and gpu access.

This also makes no sense. If you're not transferring data between the CPU and GPU space, what are you doing with that bandwidth? Processing it? Your data should take longer to process than to transfer, so your bottleneck is latency, and for that case DDR3 kicks the crap out of GDDR5.

 

[Arkaign]

You have a deeply flawed understanding of how GPUs and CPUs work with their memory.

Why is it that a GDDR5 video card blows the doors off a DDR3 video card, even if both are installed in a system with DDR2-800 memory? Ah yeah, because main system memory doesn't have all that much to do with the GPU once the level/resources/textures have been loaded.

It's ALSO why you see a HUGE HUGE difference in GPU performance based on the most important metrics : shaders/GPU clock/GPU Memory bandwidth, and why PCI Express X16 2.0 vs. 3.0 is almost meaningless even on GPUs that are of staggeringly higher performance compared to the 77xx-78xx class stuff in the new consoles.

Let me explain things more simply :

Process A : Loading. Level gets loaded, OS/AI/game engine/sound/etc get sorted and ready to play. 3D resources for the GPU get loaded, plus textures/etc, that gets moved to where the GPU can get to it most quickly (in a GDDR5 PC, this is an order of magnitude faster than DDR3 system memory).

Process B : Executing. The CPU works on tasks it's given by the OS and game engine. Various threads are streaming along taking care of AI, logic, various tasks that are primarily non-graphical. For the GPU side of this, the GPU must reflect changes in the game world VERY quickly, and 99% of what it's doing is moving around stuff that is ALREADY in video memory. What would happen otherwise? A system with DDR2 would suddenly crawl to a complete bog despite having a stout video card.

But you know what happens in the real world? That statistic (CPU to GPU memory access) is of only the most minor importance. Proof? Go compare a 7970 running on a 4770K on PCI Express X16 2.0 vs. 3.0. That's a ludicrously huge gap in bandwidth, but it doesn't affect in-game framerate. Why? Once again, once the game data is loaded and ready to go, there's not a bunch of garbage going to and from the GPU's memory. It ALREADY HAS THE DATA FOR THE LEVEL LOADED, with only the most minor swapping in and out of data along the way. The actual changes, and why the card is constantly chewing through massive amounts of local GPU memory bandwidth, is because you need very fast frame by frame presentations of the SAME visual data already there, just recalculated by the GPU and moved around.

And a final question for you that should completely blow your mind :

If you run a game, lets say Witcher 2, on a PC with 8GB of memory and a 3GB 7970, what do you think happens when the game loads and runs? Oh yeah, it loads the appropriate game resources into system memory, and into GPU memory as the levels load each time.

So, once you run the game, want to hazard how much memory is being used by the Witcher game executables? Ah yes, about 2GB! Oh, and look! A level has loaded completely and you are playing! How much GPU memory for 1080p with high details? Ah, about 1GB! Hard drive access? Ah, almost nothing until the next loading point!

Now, with DDR3 video memory having lower latency as you note, and with only 2GB of game data loaded into system memory at any given time anyway, why would any GPU need GDDR5? After all, transferring 2GB of data over an 80GB/sec bus would be nearly instant, right? And then the low latency would enable a great framerate? Ah, but it doesn't work that way. A DDR3 video card would suck for TW2. Hell they suck for 1080P gaming period.

I can't seriously believe you actually believe that sharing limited memory bandwidth between CPU and GPU is useful. You have to be trolling us. The *only* way it would be useful is if GPGPU got very very well utilized for performing functions normally provided by the CPU. Even then, gaming is typically not CPU bound for games typically played on consoles, and performing GPGPU calculations on your GPU doesn't come 'free'. It uses portions of the GPU which could potentially be used instead for traditional 3d video calculations.

Otherwise, we're down to the same formula :

Faster dedicated buses of non-shared memory will always trump slower non-dedicated buses of shared UMA/nUMA/hUMA design.

The shared memory is there because it's cheaper. If XB1 GPU had it's own GDDR5 4GB, it would be tremendously faster than sharing 8GB with everything else.

And if you can't explain why a GPU goes absolutely bananas with memory usage while playing a game session, even though almost nothing happens requiring new data to be written to that memory during the session, then you have failed to make your case. By the time one minute goes by, a card like a 7970 will have turned over many tens of thousands of gigabytes of memory arrangements from the same loaded ~1-2GB of information initially loaded for the level.

In an analogy, it's a lot like my giving a camera and a box of GI joes and other toys to a particularly helpful person. Let's call him the GPU. Lets call the Gi Joes and the other toys the video data that gets transferred to the video memory when the level loads. Level loaded, good let's go :

As the CPU, I tell the guy to arrange them this way and that way, and to change the perspective on the camera, and to swap out this character or that character out of that box he was given earlier. He does this as fast as he can.

Bah, anyway, don't rely on my word, as you obviously need to do some research. Go find me ONE SINGLE LINK that says that UMA/hUMA/etc is of particular value outside of hypothetical uses for GPGPU?

Better yet, find me ONE SINGLE EXAMPLE where an otherwise identical CPU/GPU combo works better with LESS memory bandwidth in totality.

 

[Arkaign]

The closest I can find is this incredibly vague piece :

http://www.extremetech.com/gaming/1...re-to-pound-xbox-one-into-the-dust-eventually

It even admits : "AMD’s description of HSAIL emphasizes that HSAIL is “focused purely on compute and does not expose graphics-specific instructions.” In other words, most of the publicly available data on expected HSA implementations doesn’t apply to gaming in particular."

And it doesn't begin to address the shortcomings of a shared system vs. a dedicated one.

 

[EightySix Four]

Can we go back on topic?

 

[Rakehellion]

Why is it that a GDDR5 video card blows the doors off a DDR3 video card, even if both are installed in a system with DDR2-800 memory? Ah yeah, because main system memory doesn't have all that much to do with the GPU once the level/resources/textures have been loaded.

Because software is designed to not to stress that bottleneck. With unified memory, this needn't be the case.

It's ALSO why you see a HUGE HUGE difference in GPU performance based on the most important metrics : shaders/GPU clock/GPU Memory bandwidth, and why PCI Express X16 2.0 vs. 3.0 is almost meaningless even on GPUs that are of staggeringly higher performance compared to the 77xx-78xx class stuff in the new consoles.

Because software is designed to not to stress that bottleneck. With unified memory, this needn't be the case.

When you're designing a game engine, you don't know if the user has 8x PCIe 2.0 or 16x PCIe 4.0, so you have to program for the lowest common denominator. The ideal scenario is when your framerate is limited only by your GPU speed. If your bus is saturated with memory fetches, then your processor is doing NO work and NO frames are being rendered. This is a bad thing.

Process A : Loading. Level gets loaded, OS/AI/game engine/sound/etc get sorted and ready to play. 3D resources for the GPU get loaded, plus textures/etc, that gets moved to where the GPU can get to it most quickly (in a GDDR5 PC, this is an order of magnitude faster than DDR3 system memory).

If you run a game, lets say Witcher 2, on a PC with 8GB of memory and a 3GB 7970, what do you think happens when the game loads and runs? Oh yeah, it loads the appropriate game resources into system memory, and into GPU memory as the levels load each time.

If you have an open-world game, data is being sent to the GPU pretty much nonstop. Or if you're recoding video, you have enormous textures being sent back to the CPU. Physics and AI calculations. You want to copy those back and forth every frame?

Why don't you see much of this today? Because it was impossible before.

Now, with DDR3 video memory having lower latency as you note

This completely misses my point and ignores my question. I wasn't arguing for DDR3 as it's obviously worse for games.

Bah, anyway, don't rely on my word, as you obviously need to do some research. Go find me ONE SINGLE LINK that says that UMA/hUMA/etc is of particular value outside of hypothetical uses for GPGPU?

I'd say the burden of proof is on you, sport.

 

[Arkaign]

Nope, I'm not the one making ludicrously insane claims. Cost savings yes. Simpler design yes. gpgpu yes. Good for gaming, nope.

 

[Rakehellion]

Nope, I'm not the one making ludicrously insane claims. Cost savings yes. Simpler design yes. gpgpu yes. Good for gaming, nope.

So...

If you have an open-world game, data is being sent to the GPU pretty much nonstop. Or if you're recoding video, you have enormous textures being sent back to the CPU. Physics and AI calculations. You want to copy those back and forth every frame?

Games don't do any of those things at all?

Yes, having one type of memory simplifies design, but the one point that's going over your head is that the CPU can read the GPU's memory space and vice versa, which is something a console and certainly a PC has never been able to do before.

I guess you could open up compiler, write a graphics program, and try some of these things for yourself, but I guess reading tech blogs all day and pretending you know what you're talking about it the same thing.

So I guess we're done here.

 

[Arkaign]

You haven't proven anything other than you're a dedicated blowhard that can't come up with any shred of proof to support what you're saying.

I understand that CPU and GPU can read the shared memory, derp. The point remains is that code written for the CPU to execute is not code that the GPU can directly execute and vice versa. You know this if you know anything about x86 and GCN. There are some limited scenarios where it might yield minor benefits, but they are pretty hard to balance as positives with the loss of total bandwidth compared to dual dedicated solutions. AI calculations have nothing to do with the GPU unless you invent some new way to do it via GPGPU. Physics can be, but it seems that most variants of Physics models use the CPU instead. With limited GPU power + limited CPU power + lots of weak CPU cores, it's more likely that devs on XB1 and PS4 would prefer utilizing more of the dormant cores for those kinds of calculations. Either way, once again, Physics calculations at the CPU level are utterly different than those written to run on GPUs.

The fact is that in non-shared/UMA/hUMA situations, it's trivial to load the assets at the beginning of a level, or to stream in a small amount of content in and out as an open-world game progresses. Of course, too small a memory space for either main memory or video memory, and you get hitching.

Fact : a gaming unit with a 256-bit 2400Mhz DDR3 system memory AND a 256-bit 2400Mhz DDR3 video memory bus would simply outperform a unit with a shared/unified single 256-bit 2400Mhz DDR3 bus, with the Caveat that you would have to have enough memory for each resource. Remember the PS3 ran into this problem frequently with only 256 + 256. The 360 with shared 512mb had a lot less trouble as it was more flexible. If the PS3 had 512 + 512, it would have been insanely better.

When you get to much larger memory sizes like the 8GB in the new consoles, you start to imagine that perhaps 4GB + 4GB would be pretty much plenty. Or better yet, 8GB + 4GB (system/video memory).

The bottom line is that if you have a single memory setup of 68GB/sec for CPU+GPU, that is inherently weaker than giving the CPU 68GB/sec of it's own memory, and then giving the GPU another set of memory with a 68GB/sec bandwidth as well. Regardless of what anyone tries to say, you are bound by limitations either way, but there are fewer limitations with dedicated setups.

 

[Rakehellion]

The point remains is that code written for the CPU to execute is not code that the GPU can directly execute and vice versa.

Why the hell would a CPU need to read shaders? They don't need to read each other's code, they read each other's resources.

Answer me this: Is a modelview matrix a uniform variable or an attribute?

A more difficult question: If you have one million vertices on screen that you need to animate at 60 frames per second, how would you go about doing that computationally?

 

[Rakehellion]

The bottom line is that if you have a single memory setup of 68GB/sec for CPU+GPU, that is inherently weaker than giving the CPU 68GB/sec of it's own memory

Another imaginary problem. If you have a computer that's made completely from custom parts like the Xbox One, then you make the bus wider to suit your needs.

 

[Arkaign]

Why the hell would a CPU need to read shaders? They don't need to read each other's code, they read each other's resources.

Answer me this: Is a modelview matrix a uniform variable or an attribute?

A more difficult question: If you have one million vertices on screen that you need to animate at 60 frames per second, how would you go about doing that computationally?

They don't need to read each other's resources on any massive level. That's why PCI Express improvements over time only affect ultra high end setups, usually with multi-card builds. As you constantly dodge the facts and questions presented, I am not going to bother with your utterly irrelevant questions.

Another imaginary problem. If you have a computer that's made completely from custom parts like the Xbox One, then you make the bus wider to suit your needs.

Ah, so you admit that bandwidth is a limitation that needs to be addressed. A wide bus is one way of getting there, you also need fast memory as well.

Now : fact or fiction, with a 68GB/sec peak bandwidth, will a CPU and GPU utilizing a 'unified' memory bus be able to simultaneously access the memory at 68GB/sec EACH? No? Aha.

Now compare to a system where the CPU and GPU BOTH HAVE 68GB/sec DEDICATED BUS to their OWN MEMORY.

Which will offer superior performance?

 

[Rakehellion]

As you constantly dodge the facts and questions presented, I am not going to bother with your utterly irrelevant questions.

From someone who ignored both of my questions, as well as the four other very specific examples I provided. If you don't know the answers, look it up.

 

[Rakehellion]

Now compare to a system where the CPU and GPU BOTH HAVE 68GB/sec DEDICATED BUS to their OWN MEMORY.

Which will offer superior performance?

http://forums.anandtech.com/showpost.php?p=35780430&postcount=40

 

[Arkaign]

That's purely hypothetical unless you can find some concrete examples of better performance being achieved with a halving of total bandwidth available to the CPU and GPU. Am I to understand that your answer is something like 'it might be possible'? Or 'it should show benefits'?

It defies logic that sharing memory bandwidth rather than having dedicated buses that are independent of each other would be an overall advantage outside of very rare and largely unimportant situations. Even the 'open world' example falls apart quickly with next-gen assets and the ~5GB or so of memory left available for the game + video assets after the OS/background stuff grabs it. Because 5GB is obviously not going to be enough to have everything already in memory anyway, requiring streaming in of data from the HDD and/or BD game disc, either of which are an order of magnitude slower than even generic DDR3.

The 'advantages' of sharing the memory seem like a bad trade when you're talking about losing half or more of the total bandwidth from a dedicated setup.

I can respect an alternate view/opinion, but if you're going to claim that I'm wrong in my initial statement that shared memory setups are inferior to dedicated memory setups (all other things being equal of course), then you have to have something to back that up.

I maintain that the reason unified/shared memory was chosen for PS4/XB1 is because :

(A)- It's 'good enough' to feed the relatively midrange GPUs in the console.

(B)- It's cheaper than having two independent buses and two banks of memory.

(C)- It's simpler to manufacture.

Is there a (D) in the future where it shows some massive increases that can be traced to having the GPU and CPU able to both access memory without sending it over a bus to get there once loaded? I don't know. Perhaps. Will that increase be enough to equal what a dedicated setup already starts out with (namely, DOUBLE the total bandwidth and lower latency due to neither getting in the way of the other for that bandwidth)? I sincerely doubt it.

 

[Rakehellion]

It defies logic that sharing memory bandwidth rather than having dedicated buses that are independent

I never said that shared bandwidth is advantageous. That's another straw man argument like the DDR3 thing.

And you completely ignored my counterargument that the hardware is customized and they can make the bus as big as they want, which is what they did with the PS3.

Shared memory space is a good thing, and in the grand scheme, a shared bus is irrelevant. And if you want to talk about bandwidth, PCI-express is the slowest part of your system by a long shot.

Some questions you dodged:

Have you ever written a 3D game engine?

And:

If you have one million vertices on screen that you need to animate at 60 frames per second, how would you go about doing that computationally?