Will next gen consoles finally put an end to ugly low res textures?

[TheChefO]

am I still going to see ugly low res stuff when I walk up to the wall in Modern Warfare 5?

You may...

They are making a killing financially on this franchise, but that doesn't mean resources are unlimited, nor does it guarantee that they will reinvest proportionately into the franchise.

Having said that, I doubt that there is a technical reason that you would be forced to see a blurry mess due to a hardware limitation....

 

[blip]

Why would it cause "reinvestment" ?

its simple a matter of doing less texture compression when making the final product that will run on consumer hardware?

no increase in man hours or budget necessary... im sure the current Modern Warfare games have high-res textures sitting on a disc somewhere... just not the console versions.

in fact, it seems like it would take more man hours to make a modern game fit on outdated hardware. "oh... we're going to have to compress these textures some more..." etc...

 

[sebbbi]

It wasn't the only test we ran, there were many, including larger portions of existing code.

I have 2 points here, one is to note that that for none vector workloads, any concept that 360's CPU or the PPU on a PS3 were competitive with existing x86 CPU's at the time is simply not true.

The second is although you could get good performance out of them it took a lot of work, work that in general doesn't get done to every line of a 3 M+ line codebase, and at some level means work not getting done elsewhere.

Agreed. You need to get rid of all the LHS stalls, include plenty of manual cache hints and finetune your time critical inner loops by hand to make generic x86 code run properly. Surely we would have seen better launch titles if the console was instead based on top of the line x86 CPU at the time (2 GHz dual core Athlon). All previous consoles were basically single threaded (except for some specialized vector hardware) and first dual core PC CPUs were released in the same year. No game developer had prior knowledge of creating scalable multithreaded technology, and suddenly you had to utilize six threads to reach acceptable performance, and in addition to that vector instructions were promoted to be more important than ever. Surely not an easy change, but that decision seems to the correct one when looking at things from todays perspective. Dual core Athlon wouldn't have aged as well.

I would consider poor single threaded performance to be amongst the bigger problems with both processors.

I don't think that's a huge problem on XBox 360, since you got six threads (capable of running general purpose code). I haven't developed on PS3, but I assume it might be a bigger problem for it, as it has only one general purpose PPC core (2 threads). SPUs aren't as general purpose as the PPC cores (and cannot be efficiently harnessed by using generic object oriented C++).

I would say the biggest "problem" is the extra optimization/profiling effort in-order PPC cores require to perform well. You need lots of talented technology oriented (low level) programmers to analyze and optimize the code produced by C++ game programmers. As both time and resources are always limited, (as you said) this of course reduces the resources that could be spent to improve things elsewhere.

"Driver writers spend >50% of their time bodging around broken apps. Then apps bodge around the bodges. Repeat until bloodshed."

PC debugging, profiling and validation tools need to be improved to match the console tools... However I wonder how many developers even run their code though DirectX debug layer (maximum validation and output). It detects a huge majority of the problems in accessing the API. DX10/11 also made things much better since it removed the caps and all the API hacks (DX9 was notorious for all the hacks to access extra features). The problem also is that customers are demanding API hacks (control panel adjustable filtering and antialiasing overrides) and these features easily break the programs (deferred shading is really popular currently and it isn't compatible with driver forced MSAA, and virtual texturing is becoming more popular as well, and it isn't compatible with driver forced filtering modes).

 

[french toast]

HOBO;

If by "when they were designed" you meant two years before the launch then maybe. During launch 512M of system+vram was definitely midrange at best when compared versus PCs. I can agree with that amount being as good as they could have managed but I wouldn't say it was excellent.

Jesus, we have gone through this already, even on private message, in MAY 2005 512mb gddr3 was very high end, and that was on single graphics cards costing as much as a 360, the 360 was twice as powerfull graphics wise as a SLI setup in MAY 2005.
Also taking into consideration xbox had many other technologies that cost $$.
Where you get 'midrange' from i have no idea, i think you are referring to 2007 or something.

Unified memory has got nothing to do with bandwidth, having a split pool does not equal more bandwidth by default, as someone else pointed out you need 2 seperate controllers, which pushes up the costs alot, and makes it complicated for developers.

xdr2 is twice the bandwidth of gddr5 at 30% lower power, but it hasn't been used yet, and dont know the expense of it.

 

[almighty]

xdr2 is twice the bandwidth of gddr5 at 30% lower power, but it hasn't been used yet, and dont know the expense of it.

But at what cost?

Is a single 256bit bus running XDR2 in a UMA design going to provide more bandwidth at roughly the same price as...

256bit running GDDR5?

It's OK saying its twice the bandwidth as GDDR5 ( What speed GDDR5? ) but what about the cost?

If it's quite a bit more expensive it meens there could be less memory as a result.

 

[tunafish]

No game developer had prior knowledge of creating scalable multithreaded technology, and suddenly you had to utilize six threads to reach acceptable performance,

They didn't.

I would consider poor single threaded performance to be amongst the bigger problems with both processors.

I don't think that's a huge problem on XBox 360, since you got six threads

I don't think you understand just how horrible the state of the art in multicore programming still is.

Most games released in the past half a decade do not properly utilize 6 threads. In fact, every project I have intimate knowledge of essentially pushed all the parts that are easy to split off (like sound) into their own threads, and ran the actual game engine in a single thread. Yes, they knew they were wasting most of their available cpu resources. They just didn't have the expertise and the engineering resources to do anything else. For bonus points, this meant easy portability across the two consoles -- since the code didn't actually really utilize more than two threads, they could run it as is on both sides of the fence.

Having 6 threads capable of running c++ does not mean that you can run c++ across 6 threads. In fact, the traditional OoO design paradigm is essentially impossible to properly multithread. When all your code is touching mutable objects, any way to split it off into separate threads will kill your performance with the synch. There are approaches to fix this, but they are still pretty much pathfinder projects.

Just think of all the PC versions of the popular cross-platform titles. How many of them can efficiently utilize more than two cores? How many gain *anything at all* from adding a third one?

 

[almighty]

Just think of all the PC versions of the popular cross-platform titles. How many of them can efficiently utilize more than two cores? How many gain *anything at all* from adding a third one?

As a PC gamer that had a 6 core CPU, Lets just say I now have a Quad-Core...

Off the top of my head :

GTA4
Battlefield Bad Company 2
Lost Plant 2
Metro 2033
Call Of Duty games released after Modern Warfare
Crysis 2

There's around 20 or more so games around but most produce the same frame rates with 3 cores as they do with 4.

You only really start to see benefits from 4 cores or more when you have 2 or more graphics cards running.

 

[function]

Just think of all the PC versions of the popular cross-platform titles. How many of them can efficiently utilize more than two cores? How many gain *anything at all* from adding a third one?

Anything at all? A couple of years ago PCGH looked for games that could show a benefit from six cores compared to just four:

http://www.pcgameshardware.com/aid,...already-benefit-from-six-cores-CPUs/Practice/

Quite few, and some of the gains were pretty big. A number of 360 ports in there too. I'd hope the situation in general is better now in early 2012 than in early 2010, but I know most people are just playing browser games and 1.1 core WoW.

 

[sebbbi]

Having 6 threads capable of running c++ does not mean that you can run c++ across 6 threads. In fact, the traditional OoO design paradigm is essentially impossible to properly multithread. When all your code is touching mutable objects, any way to split it off into separate threads will kill your performance with the synch. There are approaches to fix this, but they are still pretty much pathfinder projects.

I don't see the problem in running well designed C++ code across multiple threads. You don't have to synchronize every object. For example we have several structures that are designed to be read only during frame processing, and are only updated between frames (light weight updates that are have all calculations done in advance). Thus all our threads can read these structures without any synchronization. We also have structures that are designated for a single thread use only (no other thread is allowed to access these). For example our physics processing always occurs inside the same thread, and so the physics structures need no synchronization. We use double buffering in many instances to generate next frame data simultaneously as we are consuming (for example rendering) the current data (double buffered pointers are swapped between frames, so no synchronization is required). We also have many thread safe structures (for example queues) that are implemented with atomic operations instead of locks. I see no problems in writing good multithreaded object oriented C++ (as long as the technical design is done properly).

Just think of all the PC versions of the popular cross-platform titles. How many of them can efficiently utilize more than two cores? How many gain *anything at all* from adding a third one?

This is mainly because a single modern x86 core can be around four times as fast as a single console core. A single core can finish four software threads in the allocated time. Thus the six threaded XB360 game often doesn't require more than 1.5 modern cores (at console 30 fps) or 3 modern cores (at doubled 60 fps).

However if you are running modern console ports using a lesser CPU, such as a dual core ATOM (four threads with HT) or a dual core CULV Sandy Bridge i5 (1.6 GHz, 17W, four threads with HT), you will see nice gains when you enable Hyperthreading (2 -> 4 threads). And you will see even bigger gains if you compare a single core (2 thread) ATOM against a similar dual core (4 thread) ATOM in games. And in more CPU heavy games you see scaling up to 6 cores (on a Phenom II) in some benchmarks.

I don't believe the limited scaling at the high end CPUs is because the games haven't been threaded properly, I believe it's because the games are designed to run on 7 year old hardware, and thus the CPU isn't often the bottleneck.

 

[mikiex]

Why would it cause "reinvestment" ?

its simple a matter of doing less texture compression when making the final product that will run on consumer hardware?

no increase in man hours or budget necessary... im sure the current Modern Warfare games have high-res textures sitting on a disc somewhere... just not the console versions.

in fact, it seems like it would take more man hours to make a modern game fit on outdated hardware. "oh... we're going to have to compress these textures some more..." etc...

This is very true, often higher res assets are availble, probably not on the disc as such.

Currently it requires more time investment trying to fit it into memory on the PS3, less so on the Xbox, but then that has a limitation with optical media size being DVD based.

If you look at the performance texture bandwidth on the GPU is generally under utilised on consoles, meaning that bigger textures could be used if more memory was available without too much of a hit (if any)

 

[MJP]

Just think of all the PC versions of the popular cross-platform titles. How many of them can efficiently utilize more than two cores? How many gain *anything at all* from adding a third one?

How many of those games are bottlenecked by D3D9 submission overhead, something that you can't spread out across multiple threads?

 

[Fafalada]

I don't believe the limited scaling at the high end CPUs is because the games haven't been threaded properly

Oh you'd be be surprised... :/

Though the other part is true - high-end CPUs don't need to be efficient at burning through such codebases as they are targeted at lower CPU budget. This kinda adds to what I said earlier about there being little point in serious optimization on PC.

 

[almighty]

Are we talking about textures or CPU ability?

I'm confused?

 

[french toast]

But at what cost?

Is a single 256bit bus running XDR2 in a UMA design going to provide more bandwidth at roughly the same price as...

256bit running GDDR5?

It's OK saying its twice the bandwidth as GDDR5 ( What speed GDDR5? ) but what about the cost?

If it's quite a bit more expensive it meens there could be less memory as a result.

Valid questions, im not very knowledgeable on the subject, but here is a graph from the rambus website, it suggests higher density ram available, (less number of chips/cheaper) and less pins (less cost, shrinkage).

I have no idea about how much this stuff would cost, and how they would implement this into a console, especially with something like edram as an option.
The ps3 remember has 256mb xdr...so move things on 6/7 year, smaller process and lessons learned = certainly feasible....
There was also rumours about amd using this in there future GCN architecture..agian i don't know this..take with a pinch of salt.

If you are intersted, take a proper look at the website...if you migrate over to the left you have some options to show different details on the page.
http://www.rambus.com/us/technology/solutions/xdr2/xdr2_vs_gddr5.html

 

[Shifty Geezer]

Those XDR2 pages really are old news around here, and we've all seen them. Sadly all we have for XDR2 is paper specs. There are no chips in a device showing it works. Now the case was pretty much the same for XDR, and that worked out, so I'm hopeful, but we can't compare XDR2 to other options when there's no way to evaluate cost. Heck, for ages we've had talk of bus width adding to board costs etc., but noone's ever presented actual number so we know how much by! Less chips means squat for lower costs in the license fees are sky high, or you can only get one supplier and they are adding a hefty margin for your niche component. There's no way to compare XDR2 to GDDR5 regards cost/performance.

 

[almighty]

By the looks of it the top end GDDR5 ( 6Ghz effective, 7970 memory can overclock beyond that ) can keep up with the lower end XDR2 it would all depend on

1. The price difference between GDDR5 and XDR2
2. The price difference between the fastest and the slowest XDR2.

1500Mhz GDDR5 on a 256bit bus will generate ~192Gb/s which to me would or should sustain a next generation console. Overclocking the 7970 its GDDR5 can hit 1700Mhz ( 6800Mhz effective ) would generate ~217Gb/s

Top end XDR2 ( 12800Mhz ) on a 256bit memory interface would generate ~409Gb/s!!

Say top end is too expensive so they use mid speeds of say 9500Mhz you're still talking of ~304Gb/s

 

[TheChefO]

By the looks of it the top end GDDR5 ( 6Ghz effective, 7970 memory can overclock beyond that ) can keep up with the lower end XDR2 it would all depend on

1. The price difference between GDDR5 and XDR2
2. The price difference between the fastest and the slowest XDR2.

1500Mhz GDDR5 on a 256bit bus will generate ~192Gb/s which to me would or should sustain a next generation console. Overclocking the 7970 its GDDR5 can hit 1700Mhz ( 6800Mhz effective ) would generate ~217Gb/s

Top end XDR2 ( 12800Mhz ) on a 256bit memory interface would generate ~409Gb/s!!

Say top end is too expensive so they use mid speeds of say 9500Mhz you're still talking of ~304Gb/s

...or XDR2 ( 12800Mhz ) on a 128bit memory interface would generate ~200Gb/s.

This would be the reason to invest in XDR2. Save costs on board traces and reduced size on chip mem controller pinout for future die size reduction.

 

[hoho]

I wonder what kind of memory subsystem was NV planning for the theoretical/research chip in their paper that was supposed to get 50Gbps per-pin or 1.6TB/s with 256 bit interface. XDR2 graphs seem to go flat at several times lower speeds.

 

[MarkoIt]

I wonder what kind of memory subsystem was NV planning for the theoretical/research chip in their paper that was supposed to get 50Gbps per-pin or 1.6TB/s with 256 bit interface. XDR2 graphs seem to go flat at several times lower speeds.

Hybrid Memory Cube or some other form of stacked RAM, which are still years away.

 

[hoho]

Hybrid Memory Cube or some other form of stacked RAM, which are still years away.

They did talk about that kind of architecture/specs being reasonable in 2017 or in 5 years. Would that be enough time to make something working?