DX10, 64bit games, more cores -- which is gonna help the most?

[robains]

I've been reading many articles about how DX10 Games (current Betas) aren't living up to the hype -- slightly better visuals (as compared to DX9) but at a 50% frame rate hit.

For example the Crysis beta looks great in DX10, but it looks great in DX9 also only in DX9 you don't get a massive performance hit like you do in DX10.

So the question is which of these three items will provide the best performance:

1. DX10
2. true 64 bit games
3. true multi-core thread games that are fully scalable

 

[ViRGE]

3
1
2

 

[robains]

Agree on the 3, but I may put it 2 and then 1 last. From what info I can gather, higher resolution textures take up a huge chunk of memory, beyond the 2GB thread size limit of 32bit applications. I think to obtain the higher texture levels 64bit games will be a must.

Rob.

 

[Piuc2020]

Not really sure about that Rob but I still say 3, 2, 1. Simply because DirectX10 is not really meant as a performance feature which is what many people don't seem to understand.

 

[jkresh]

robains I haven't seen anything on crysis and dx9 vs dx10 but on the games that were designed for dx9 and patched for 10, 10 has not been particularly useful (ie not a lot more in terms of visuals and much slower). That being said a new dx is not likely to increase speed (it might if features are kept the same but the added features means speed will stay the same or get slower), 64bit is about 10% for most games though it may eventually increase. Proper multicore design can be much bigger (even if its just 1 core for ai, 1 for physics, 1 for sound, 1 for everything else).

 

[0roo0roo]

Originally posted by: Piuc2020
Not really sure about that Rob but I still say 3, 2, 1. Simply because DirectX10 is not really meant as a performance feature which is what many people don't seem to understand.

true but from all reports the current improvement is very minor with a massive frame rate hit. not ready for primetime. so don't worry about dx10 for now

 

[Rebel44]

2 32bit sucks
3 multicore will allow better physics without PPU
1 some improvement but it will take some time to tweak it properly (to have better effects without performance hit)

 

[robains]

DX10 does have some performance improvements:

1. Texture arrays - swapping that doesn't require CPU cycles (all in GPU)
2. Predicated Rendering
3. Instancing 2.0

Not seeing anything in DX10.1 that would help performance.

I'd certainly like to seem more 64bit games -- with two 2900XT 1GB cards there is 2GB memory map space right there (which would consume all of a 32bit OS's single thread limit with just the mapping of video memory alone - so I would assume it would be a waste to have 2GB VRAM on a 32bit OS). Using mapped VRAM is a huge performance gain over system RAM.

Correct me if I'm wrong, but I was surprised to find out that many titles are still coded for DX7 and DX8 support where many of the extended methods available in DX9 are not being fully utilized. It seems game developers are just now catching up with all the features available in DX9 (or is it they waited for better hardware)? I suppose this means it could be another 2-3 years before developers figure out how to effectively use DX10.

It seems today's DX10 video cards are really just better DX9 cards and there is much left on the table for true DX10 hardware accelerated performance -- or it is really all up to the game developers and we currently have all the hardware we need?

I agree multi-core can be used to improve AI -- but coding multi-thread/multi-core games is definitely a challenge -- I would guess that such coding efforts would introduce higher rate of bugs which would make for a longer development cycle.

Rob.

 

[Snooper]

Programmers don't really have a choice. They MUST get to the bottom of all this multi-threading programming. The old days where an old program could be dropped onto new hardware for an instant performance shot in the arm are long gone.

It all started when Intel started adding all these new instruction sets to the X86. They spent a LOT of time making the new microcode run very, very quickly, but it was in specialized applications and you had to use the correct instruction for it to work. Old programs just didn't work much (if any) faster on the latest and greatest processor than they did on the old iron. About the only performance increase they could see was simply due to pure increases in clock speed and (to a lesser degree) improvements in general architecture efficiencies.

With the introduction of a very leaky 90nm process, the ability to just keep cranking up clock speeds with shrinking feature sizes pretty much came to a screeching halt. The heat from the leakage current would burn out the CPUs well before they hit the physical limitations of the NetBurst architecture.

Which led to the dual (and more) core world. Now, programmers can not longer take a lot of things for granted. They can not even be sure WHICH core the code is going to be running on at any particular instant. When they do start adding in multi-thread code, now they have to worry about the fact that their loops are running on two physically independent (or more) cores. There are not physical limitations that will force code to finish in the right order, so they have to add a lot of additional code to keep things synchronized. Not easy and it is completely different than what most of these programmers have been doing for the last several years.

We have some great hardware. But if we want to be able to take advantage of more than 25% to 50% of it, the programmers will have to cross over that learning curve. Until then, you might have the latest, greatest quad core CPU sitting in your hot little computer, but most of it is sitting around taking a nap while you play your games.

 

[0roo0roo]

eh, if microsoft would allow people with 32bit o/s to upgrade to 64bit with minimal fee it would ease transition. but i guess we aren't going to be moving past that 3gb barrier anytime soon at this rate.

 

[robains]

I'm a programmer/developer also -- not a game developer (well not officially). I think you'll find that most developers are more than willing to work multi-threaded applications, but with that comes complexity and hence increased delivery time. Key being increased delivery time, this is where the project managers get involved and have to either find the funding and justification. OR, tell the developer not to implement -- and it is NOT a easy sell to fund these projects/games. Doing a well threaded game starts from ground up, it rarely is something you can just "add" or change your mind on midway thru the development process.

Threaded programming isn't "new" -- has been used and abused for a long time now. It's only come to light because of the limitations of the hardware -- the Ghz wall was hit earlier than expected by CPU manufacturers (or at least the ability to realistically regulate the heat & power consumption which as you pointed out is the real wall). So now we have multi-core chips cause CPU manufacturers haven't been able to work around this wall (yet). I still think the Ghz/heat wall will be solved, but til them the only marketable path is going with multiple cores -- at least it is giving time for chipsets and memory and motherboard designs to "catch up".

The developer CAN select a specific core to execute their thread (or threads). A common example of this is Prime95 testing program used by overclockers to estabilish the stability of the overclock across multiple cores -- Prime95 has specific core assignments (if it didn't, you wouldn't have any real test). When instantiating a thread the developer can either let the OS allocate as needed, or the developer can specifically allocate to a known core (as the number of cores will be known thru basic hardware discovery routines).

The OS and Development tools are the primary areas that have been lacking in good support for multi-thread CPU specific code. Mostly on the debugging side using Microsoft's Visual Studio platform. Think about it, if you have 4 threads running at the same time and you need to stop one thread to step thru the code line by line to see where a problem might be in that one thread path -- those 3 other threads keep running and are not entirely independant of the thread your currently suspending. There are tricks and solutions around this, but as you can see the process becomes considerably more complicated and time consuming especially when dealing with a "simulated" environment. I've done some threading on business level applications to provide a more responsive application, but threading multi-core business applications are almost trivial when compared to the complexity of 3D gaming applications trying to simulate an experience.

So what I'm trying to suggest, is that the developer tools provided by Microsoft are the current weakest links for gaming. Of course my assumption is that game houses use Microsoft's tools for the core, which may not be the case. But good multi-core code happens in the engine -- ironically John Carmack was one of the 1st to implement this in Quake -- a then OpenGL title.

My 2 cents, Rob.

 

[robains]

OrooOroo,

The Vista Home upgrade is only $72.99 at NewEgg:
http://www.newegg.com/Product/...x?Item=N82E16832116153

Not that I'm suggesting you get it, but my WinXP upgrade from WinME cost me $99.99 and that was 5 years ago. So if you factor inflation, the upgrade price is actually not that bad at all.

I think the costs you will need to save up for are the GPU and the extra RAM you'll need (and of course the CPU/motherboard if you currently don't have a 64bit CPU) -- that's where you be spending the money. I recently built a complete DX10 capable system with Vista OS for $800 (tax and shipping included) that scored 5.7 on the Vista performance index (AMD based).

3GB is not a "stable" limit -- the 32bit OS (Vista also) can only allocate max of 2GB to any thread -- that's the key issue. You can have many threads but none may exceed 2GB. The 3GB switch is risky because many apps are compile under the assumption of 2GB limit so it is very code dependant switch and the only apps I know that might take advantage are FSX SP1 and Adobe Photoshop. Also, if you have SLI or Crossfire video cards they may still prevent the 3GB boot.ini switch from really working.

Rob.

 

[Snooper]

Originally posted by: robainsI still think the Ghz/heat wall will be solved, but til them the only marketable path is going with multiple cores

I wouldn't hold my breath on this one. While there are still tricks that they can play (the 45nm process from Intel is VERY interesting) to decrease the the leakage current during switching (from on to off and visa verso), there are still fundamental physics in the way. Things like capacitance and resistance that just get worse and worse as things get smaller and smaller.

I would actually expect to see things go the OTHER direction: More and more cores AND more and more DIFFERENT types of cores.

Right now, we have CPUs with multiple general purpose CPUs on it. They are all the same.

Eventually, they will have to start building special purpose cores on there as well. Image a CPU with two GP cores, one graphics core, one media core, and a handful of other, simpler cores for "other" tasks.

Silicon for silicon, the specialized cores (aka: GPU) are faster than a general purpose CPU. With the slow consolidation of the entire platform onto a single IC, it is just a question of time before they start building more specialized cores directly into the CPU. They almost have to.

And you are definitely right in saying that current development packages are lacking! No argument from me on that. Hopefully, the new multi-threaded development package that Intel is working on will help address this and make multi-threaded programming simpler.

 

[robains]

You might be right, but there are some interesting new transistors and other optical technologies that could be viable but not necessarily measured in Ghz. But I agree, not holding my breath, but I'm optimistic there will be a solution within the next 5 years.

For the immediate future I agree, more cores, but only because there aren't any other real options. I'd prefer to see a balance of more Ghz and a few more cores -- for example a dual core 4Ghz rather than a quad core 3.5 Ghz unit.

The problem I have with a GPU core on the main CPU is the path to large chunks of memory -- VRAM is faster (especially the DDR4 stuff) and you can't put 2GB of VRAM in a core so you have to go thru the still horribly slow front side bus. Hmmm...maybe a serialized optical front side bus could do better??

I hope Intel come thru, don't get me wrong, I like VS 2008 Beta 2 (hate VS 2005 SP1) but still not easy to debug multi-core threads -- in some cases I have to resort to the 30 year method of streaming output to file so I can try to see any timing/contention issues (but even the process of streaming to a file in itself can squew the results).

But I do have the highest respect of game developers taking on the challenge of multi-core threads and do understand the problems associated around it.

Rob