Does zdoom suppot multiple cores?

[iVoid]

Title says it all.

[Blzut3]

Not really. Sound processing is done on a separate thread, but other than that no.

[iVoid]

Do you know if it is a planned feature?

[Gez]

No and it would be mostly pointless. The Doom engine wasn't written with parallelization in mind. There are exceedingly few parts of it that could be multithreaded without breaking everything. At the very least, you'd kill demo and netplay if you parallelized worldsim routines. Some parts of the renderer can be paralleled, but the performance gain isn't that impressive when you remember that it's only just one part of the overall step. Maes over on Doomworld made some experiments with that in Mocha Doom, so you can try to find his threads over there.

[Graf Zahl]

Even having a separate core just for sound processing and system background tasks will free the main core from a lot of work that can now be used by the main engine.

[iVoid]

I see. Is there any performance improvement feature coming in the foreseeable future?

[Blzut3]

Is there a reason you're obsessing over ZDoom's performance? Given that I can play the normal IWADs on my Pentium 2 266 and hold 35fps (this is Doom's temporal resolution, everything above it is basically eye candy), I would think all but the most extreme wads should be playable on any dual core processor.

ZDoom may not be the most optimized engine, but it's certainly not slow.

[iVoid]

I'm not obsessed mate, just asking simple questions.

Yes, the performance is pretty good. I just wanted to know if those "most extreme wads" will ever run smoother, is there a problem in asking? Relax.

[GooberMan]

But you guise! I herd that cores let you do two things at once! So make the cores do one line of code each at the same time! It'll run like four times as fast!!1.



The only real benefit from trying to multicore Doom's code (outside of the sound/system tasks mentioned) is the rendering. And it'd be pretty minor at least while introducing lag. Each update frame would generate a draw list from which another thread can operate (ie pretty much how consoles have been doing it since the PS2 days). The net effect is that one frame is rendering while another frame is updating - introducing a frame of lag in to the user's input, as they'll have one frame less to react to whatever has happened in the world.

I haven't seen a single mod that warrants that kind of work.

I'd imagine a prime target for any optimisation work would be ACS and Decorate, as they're fairly extensively used. And they're fairly sequential in nature, so multithreading them would be needlessly difficult and not needed.

[Blzut3]

Relax.

Sorry if my post came of as irritated. I was just curious since you've made 2 threads regarding performance and I've never really thought of ZDoom having a performance problem.

Given the restrictions of the architecture that is the Doom engine. There's only so much that can be done to handle multiple cores. You could get a few extra frames by multithreading the renderer (as shown by MochaDoom), but It's probably not worth the work. I would be kind of curious if portal rendering (portals are done by basically restarting the rendering processing) could be done in multiple threads (especially when you have both a floor and ceiling portal in view), but that may require a significant code cleanup and there are more important things to do. Maybe if we ever support split-screen the issue could be more important (no there's no plans to support split-screen).

GooberMan, ACS would be prime target for multi-threading since each script is essentially a thread. The problem is, once you start putting them on real threads some guarantees that mod authors depend on would be broken and ACS would then need all the fun synchronization primitives. With that said, it would be possible to improve the VM to do run time optimizations, but for the most part ACS isn't compute heavy.

[Edward-san]

if I'd try to parallelize something, I would try to do it for the actors, ie the actors in a map could be separated in groups, each one managed by a different thread... but maybe there are so many actor variables that the thread cache couldn't contain everything...?

[Gez]

if I'd try to parallelize something, I would try to do it for the actors, ie the actors in a map could be separated in groups, each one managed by a different thread...

I can only see that leading to network and demo desyncs. What happens if you have an actor that's in Group 1 on a dual core, group 3 on a quadcore, and group 0 on a monocore, and they are all in the same netgame?

[Edward-san]

if I'd try to parallelize something, I would try to do it for the actors, ie the actors in a map could be separated in groups, each one managed by a different thread...

I can only see that leading to network and demo desyncs. What happens if you have an actor that's in Group 1 on a dual core, group 3 on a quadcore, and group 0 on a monocore, and they are all in the same netgame?

the main thread could have a list of all the actors references in the central memory, independently on the thread configuration....

[GooberMan]

Um. No.

Paralellising actors isn't as simple as just saying "actor on this thread, actor on that thread." If you want any kind of synchronisation, actors need to be not thought of as actors but as discreet tasks that can be batched. AI, movement, collision, projectile spawning, etc would all want a separate task pool, and they'd all want to be done in explicit stages if you expect any kind of synchronisation.

And it still won't be worth the efort.

but for the most part ACS isn't compute heavy

I wouldn't expect it to be. But I would expect cache/branch predition issues. Especially if the VM hasn't been touched up too much since the Hexen source code release. That code wouldn't have had the latency issues modern CPUs have.

[Gez]

the main thread could have a list of all the actors references in the central memory, independently on the thread configuration....

Let's say you have two zombiemen, one in group A and the other in group B. They are infighting and already hurt. They just happen to both be shooting during the same tic. Zombie A kills zombie B, zombie B kills zombie A.

Normally, they'd be treated sequentially and one of them would kill the other "before" it shoots even if it's on the same tic. But here, you have a race condition. Depending on which thread reaches the critical point where it runs the attack hitscan for its zombie, either A or B will die, and you cannot guarantee that it'll always be A or always be B. You've got desync.

Having a central reference doesn't change anything to that. The only failsafe plan is to have all the actors in the same thread. Same deal with ACS, really. You can get scripts modifying the same thing in different way, and which one gets the last word (or, depending on what they do, the first word) isn't guaranteed to be consistent if they aren't always executed in the exact same sequence. You think that's unlikely? ZDoom has had to get a compatibility option for the ways scripts are enqueued to be played, because the vanilla Hexen VM did it in the other way around than Randy's original reverse-engineered VM, and some vanilla Hexen maps were found that were broken and made unplayable if the vanilla Hexen order wasn't used. With parallel ACS, you basically make the script execution order random. Sometimes these maps will work; sometimes they won't. Oh, and it's Hexen, so you might not notice the map is broken until for two hours and six other visited levels. Fun!

What you can do is have different threads for independent subsystems -- video rendering, sound rendering, input management, worldsim -- and this is already partly done. The video rendering can be split into parallel threads as found by Maes, but that didn't yield extremely exciting results because even if you halve the time spent drawing columns, it is but a tiny part of the general worldsim + rendering loop.

Especially if the VM hasn't been touched up too much since the Hexen source code release. That code wouldn't have had the latency issues modern CPUs have.

ZDoom's VM is older than the Hexen source release because Randy wrote it himself.