Will DNF be Multithreaded?

[Yatta]

I searched this forum and couldn't find an answer, so I'd like to know if there are any plans for the game to support dual core processors. I heard UT 07 may be multithreaded, and that gives me some hope. Thanks.

[Tim. Just Tim.]

I asked this exact question, but i cant find the thread. It wasnt long ago. I also asked if it would be/support/take advantage of 64 bit.
Got no answer.
Asking about this is illegal I think, although I dont see why couldnt tell us, assuming they even know yet...

[Micki!]

How does Dual core work anyways..?
Just curious... http://forums.3drealms.com/ubbthreads/images/graemlins/redface.gif

[FireFly]

Well a developer might split the renderer off into a separate thread, so it would be running on one core and the rest of the game would be running on another. Or it might split the physics off, or the A.I.

[roryok]

Micki! said:
How does Dual core work anyways..?
Just curious... http://forums.3drealms.com/ubbthreads/images/graemlins/redface.gif



my understanding of it is, basically you've got two CPUs instead of one. Either one can run all the background windows crap, and the other can run the game, or if the game is designed to split the processing between two CPUs, then each CPU can take one part of the processing, and everything gets done faster.

what I'm curious about, is how difficult is it to make your game multithreaded in the first place? Could it be done this late in the project, or would it need to be something implemented from the very beginning of coding?

[Rider]

even if it IS supported, 3DR wouldn't tell any of us.

That sorta stuff has to be saved for the near-release hype.

[brabee]

Rider said:
That sorta stuff has to be saved for the near-release hype.



http://forums.3drealms.com/ubbthreads/images/graemlins/confused.gif
Why??? This is an engine feature, not a game feature...

[Cerberus_e]

Yatta said:
I searched this forum and couldn't find an answer, so I'd like to know if there are any plans for the game to support dual core processors. I heard UT 07 may be multithreaded, and that gives me some hope. Thanks.



Well, you can run non-dual core games as well with dual core. I have a processor that supports hyperthreading and the 1.0.5 dualcore beta patch for Quake 4 didn't improve a whole lot.

[Rider]

brabee said:

Rider said:
That sorta stuff has to be saved for the near-release hype.



http://forums.3drealms.com/ubbthreads/images/graemlins/confused.gif
Why??? This is an engine feature, not a game feature...



in this particular case, that's completely irrelevant.

[DudeMiester]

I almost certainly is imho, but it may not be anything significant. Windows and DirectX can spawn threads in the background for things like I/O or the Win32 GUI. Audio libraries also often have their own threads too. Usually for I/O as well, so the audio buffers are streamed in and out without blips.

[hell-angel]

It doesn't really matter IMO, mostly since if it doesn't support it then windows will let the game run on the other processor/core so you will benefit from it none the less. http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

[chitown]

This question use to get asked a lot in the years past on this board and the posts would often get turned into a CPU hardware discussion and then the mods come along and move the thread over to the hardware boards.

Since I seen this type of question asked in the past, I am pretty sure that 3DR is well aware of the multiple cpu operation of multitasking, handling multithreaded data, SMP as this technology has been around for more than a decade now in most dual processor setups and has been getting attention again lately in the form of dual core cpu systems. Duke Nukem Forever having multi-threaded support will rely on if 3DR has listened to our requests made for that feature in the past years.

So hopefully it will utilize it.

[hell-angel]

chitown said:
This question use to get asked a lot in the years past on this board and the posts would often get turned into a CPU hardware discussion and then the mods come along and move the thread over to the hardware boards.

Since I seen this type of question asked in the past, I am pretty sure that 3DR is well aware of the multiple cpu operation of multitasking, handling multithreaded data, SMP as this technology has been around for more than a decade now in most dual processor setups and has been getting attention again lately in the form of dual core cpu systems. Duke Nukem Forever having multi-threaded support will rely on if 3DR has listened to our requests made for that feature in the past years.

So hopefully it will utilize it.



Hopefully yes, but don't forget that synchronizing threads is very difficult and can cause a lot of problems. So unless they have been using multithreading from the start (i.e. last engine restart in 2002) I doubt they will use it since it is a pain to implement it even on a small scale, let alone a big scale like DNF.

[roryok]

hell-angel said:
Hopefully yes, but don't forget that synchronizing threads is very difficult and can cause a lot of problems. So unless they have been using multithreading from the start (i.e. last engine restart in 2002) I doubt they will use it since it is a pain to implement it even on a small scale, let alone a big scale like DNF.



Well, Prey seems to be multithreaded...


1up.com said:
Prey will proudly support dual-core setups and more.

[hell-angel]

roryok said:

hell-angel said:
Hopefully yes, but don't forget that synchronizing threads is very difficult and can cause a lot of problems. So unless they have been using multithreading from the start (i.e. last engine restart in 2002) I doubt they will use it since it is a pain to implement it even on a small scale, let alone a big scale like DNF.



Well, Prey seems to be multithreaded...


1up.com said:
Prey will proudly support dual-core setups and more.





Well, supporting it and being it 100% are 2 different things. Besides, I didn't say it was impossible, just very complicated. http://forums.3drealms.com/ubbthreads/images/graemlins/wink.gif

[Mach10]

Doubt it. Writing for dual processing is more complicated. I know for a fact that the Unreal engine won't do it.

I'm not so sure Prey did either, although there might have been support for SLi video. I've heard tell that writing for SLi is a little nicer than SMP, since you can use built-in calls to the nVidia drivers... But beyond that, there isn't a whole lot of incentive to do so:

Hyperthreading is useless since at best it slightly optimizes running code. The "virtual processor" that it creates gives you maybe a 5% boost in speed simply due to the fact that it can access two memory channels at once. It doesn't process anything faster. Just gives running threads slightly better access to the memory bus.

With dual-core processors, the improvement is marked, but you're still looking at only a 30% increase due to the overhead of managing both processes.

Multi-threaded games are on the horizon, but at this point, it's something of a paradigm shift in coding from the base level. I can't see it becoming seriously mainstream until we start running into a brick wall from the switching speed limitations of Silicon based processors. And at that point, I think the limitation will probably be in memory access times rather than number crunching ability.

In short, I'd say no, since it would have had to have been multithreaded from the beginning. As I understand it, It's not really something you can just add in later.

[Tim. Just Tim.]

I highly suspect they do have support for dual core cpus.

With all the engine switching and rewriting, Im sure they've learned a thing or two about writing engines. And its no secret that 64bit dual cores are here to stay.

I hope they managed to pack up the meqon physics stuff into a separte thread so that it could run on cpu#2.

I dont think its actually that hard to take advantage of the dual-core-ness, since the OS does a lot of the work. You just need to divide your engine into appropriate threaded subsystems and worry about some sync issues.

Keep in mind though, that 2 cpus doesnt mean twice as fast. You probably have to really really know what your doing to even get a 20% performance boost. OTOH, getting 5% is probably easy as pie.

Im sure theyve got some really talented software engineers and architects onboard, who are already making the engine very robust and object oriented and multithreaded and load balanced and efficient. They have to, for the amout of interactivity and sheer # of objects that I am expecting in the game.

Being able to take advantage of dual core processors will just be a side-effect of their good software design.

[Mach10]

Right, the kernel is taking care of most of the requests... But only at the HAL layer. Remember, windows is a protected-mode operating system. It does NOT allow any direct communication between hardware and software. All requests go through the Hardware Abstraction Layer. And the HAL does not (at this point) discriminate between multiple CPUs unless specifically asked to.

But the problem is that every operation in a dual-core program has to be split off and flagged so that the OS knows what to send, and where. There isn't any real method in place to "load-balance" between CPUs, which is what the assumption most people make when they think "Dual Core," or "Parallel Processing."

The other core isn't there when you need it. It has to be addressed specifically. And to do that within the game code requires that you break it all up. Easier said than done when you are dealing with what, 750,000 lines of code? SMP has been around since the old UNIX dumb-terminals (mmm... anyone remember thread forking?), but it's only been in the last year or so that it's actually started to make any kind of consumer market penetration.

Which is why ATI Cross-Fire looks so goddamn awesome when compared to SLi. Video cards themselves break up the processing load, and create the closest thing to load-balancing between devices that the gaming industry has ever seen since 3dFX's SLi. The new SLi is cool, but the game specifically has to reference certain driver calls to take advantage of it (not like the old 3dFX SLi. BOO!). CrossFire, on the other hand lets you have 3 methods of load-sharing between the cards, which in theory gives the user much more flexibility. It's not quite as fast as SLi (but the tiling mode comes damn close) but the advantage is that the support is built into the driver, and does not necessarily require special coding or driver calls to take advantage.

Honestly, I don't see multi-CPU as being that much of an issue in gaming. For a while now, the video card has been the limiting factor, since the data-point resolution required for gaming is far greater in the visual aspect, rather than the back-end encoding. (i.e., there's more datapoints to crunch when creating reflections for example, vs. colision detection between objects). Of course, as the processing power goes up, the back-ends will become more sophisticated, requiring more processing power (ad nauseum)....

[Kristian Joensen]

I'm not so sure Prey did either,



Prey DOES support multi-core processors.


. Easier said than done when you are dealing with what, 750,000 lines of code?



DNF is 1 Million + lines of code.

[Mach10]

Forgive me for being ignorant on the subject, but IIRC, Prey was based off a modified Doom3HD engine, correct? I know it had enhancements that did SLi for sure... and it seems to support dual cores... But I can't find any benchmarks to suggest that it is doing true multi-threaded operations?

Anyone have any links to the effect?

[Micki!]

Mach10 said:
Forgive me for being ignorant on the subject, but IIRC, Prey was based off a modified Doom3HD engine, correct? I know it had enhancements that did SLi for sure... and it seems to support dual cores... But I can't find any benchmarks to suggest that it is doing true multi-threaded operations?

Anyone have any links to the effect?



Well, it was stated in the Prey thread somewhere... I think that was before you registered...

I can't remember where it was mentioned exactly, anyone else who can provide a link to the thread..? http://forums.3drealms.com/ubbthreads/images/graemlins/confused.gif

[FireFly]

http://forums.3drealms.com/ubbthreads/sh...part=2&vc=1 (http://forums.3drealms.com/ubbthreads/showflat.php?Cat=0&Number=1031710&page=0&fpart=2&vc=1)
http://www.1up.com/do/feature?pager.offset=1&cId=3147653

[LeadBullet]

Don't they already do it though? For a long time games have used the system CPU and then the CPU on a video card for graphical things.

Couldn't they just do the same thing but break it off some more? Like stick physics and AI on the second core or something. Maybe the load wouldn't be completely split, but at least two things that can be complicated and add up quickly would have their own core to work off of and maybe even have a little room to work for situations where maybe theres suddenly a lot of active NPCs on the screen who get blown up so theres no huge slowdown when it has to do their AI and then finally calculate the physics for all their bodies or body parts.

[Tim. Just Tim.]

While in Computer Graphics grad school in Univ, I was doing some really interesting stuff with the GPU on video cards. I was working with a prototype shader language that was way ahead of its time. Doing GP (General Purpose) GPU programming, - meaning that we were doing all sorts of calculations on the card, not just graphics stuff. At one point I had a particle system with millions of particles running at decent framerates. The Data, update code and graphics code was entirely on the gpu, allowing for super fast execution. Most people dont realize it, but because of the parallel nature of GPUs, they are many many times faster than the fastest CPU, when used for the 'right applications'. And if programmed correctly, just about anything can become 'the right application'. I also had a closeup look at a very impressive realtime raytracer, among other things. Really neat stuff.