Support for Quad and Six core processors & hyperthreading

[Tes96]

Every modern computer nowadays uses dual, quad or six cores.... and some may even use eight. The 4960X is a six core processor, for example. With Gamebryo being single-threaded, it will only ever use up to 100% of one processor, making it run shitty in densely populated areas even on powerful rigs. Will the OpenMW engine be able to utilize all four or six processors and take advantage of hyperthreading? Or better yet, have OpenMW utilize most of cores 2,3,4 and leave core 1 for running the operating system in the background and other such tasks.

[Zini]

It doesn't work that way. Well behaved software doesn't deal in cores most of the time and certainly not in hyperthreading. Software has threads. The scheduler (a component of the host operating system) then assigned these threads to cores. An intelligent scheduler will do that efficiently enough that no manual fiddling around with thread-to-core matching (affinity) is required. And the number of threads doesn't need to match the number of cores either. While is is possible to kill performance with too many threads per core (because switching between threads takes some time), that is in practice rarely a problem.

So the question really is into how many threads can OpenMW split up its workload. That isn't as simple as just adjusting a numeric value. If this split is done naively, the application will spend more time with synchronising between threads than doing actual work. It is easily possible to reduce performance by utilising more threads.

We need to identify tasks that can be moved into separate threads without requiring a large amount of synchronising. That has already happened in the case of the sound system and terrain loading. We will certainly find more in the future, but until then we can't really say how many threads we will run concurrently.

[Tes96]

It is easily possible to reduce performance by utilising more threads.

Did you mean "increase" performance by utilizing more threads?

[scrawl]

Ogre 2.0 has a multithreaded scene graph and by default spawns as many threads as you have CPU cores.

[Tes96]

Ogre 2.0 has a multithreaded scene graph and by default spawns as many threads as you have CPU cores.

Is that something that could also be used when working in OpenCS? With the distance slider at full and viewing large landmass with tons of objects, it becomes super hard to work because the computer is processing thousands of objects at once and everything is slowed way down.

[Zini]

Did you mean "increase" performance by utilizing more threads?

No.

Ogre 2.0 has a multithreaded scene graph and by default spawns as many threads as you have CPU cores.

Of course, since we using a number of 3rd party components, any progress made by these in regards to utilising more threads are semi-automatically passed on to OpenMW.

I haven't yet looked into what the OGRE team is doing there. But it sounds like they are splitting the scene graph up into separate parts and let each be handled by a separate thread. That is kinda the optimal case in regards to multi-threading. It is also a kinda rare case, unfortunately.

[Tes96]

By the time OpenMW version 1.0 is released, there will be something completely new for Ogre that can be used for this situation. So I probably shouldn't even worry about it for now.

[Zini]

Ogre 2.0 has a multithreaded scene graph and by default spawns as many threads as you have CPU cores.

Is that something that could also be used when working in OpenCS? With the distance slider at full and viewing large landmass with tons of objects, it becomes super hard to work because the computer is processing thousands of objects at once and everything is slowed way down.

Remember OpenCS isn't TES-CS. There is no distance slider. And you have way better options at filtering. But yes, any scene graph multi-threading utilised in OGRE should translate equally into OpenMW and OpenCS.

[Zini]

By the time OpenMW version 1.0 is released, there will be something completely new for Ogre that can be used for this situation. So I probably shouldn't even worry about it for now.

We are only months away from OpenMW 1.0 (at least from the beginning of the beta phase). OGRE 2.0 (and the multi-threading stuff) will definitely not be available by then.

[Tes96]

Remember OpenCS isn't TES-CS. There is no distance slider. And you have way better options at filtering. But yes, any scene graph multi-threading utilised in OGRE should translate equally into OpenMW and OpenCS.

Yeah, I'm confused on how to use OpenCS. It's new to me so it will take some time. I only skimmed through the user manual. I love the way you guys have redesigned the whole ESM/ESP format. Makes more sense. One thing I loved was how incredibly easy OpenMW was to install. Cheers to you guys. I hope OpenCS will have a more aesthetically pleasing interface and icon and all that.

Will you guys allow for the headers to be interchangeable? In some modern programs, you can juxtapose or switch around the columns in different orders. Nothing paramount but it would be a nice little feature.

We are only months away from OpenMW 1.0 (at least from the beginning of the beta phase). OGRE 2.0 (and the multi-threading stuff) will definitely not be available by then.

No way! You guys are that close? That's amazing! But how? You've only just released version 0.29.