Release 14.2 and multithreading

[cc9cii]

Hello,

It's been 4 years already since I was here last, trying out Ogre 2.x (but I somehow got worse performance than Ogre 1.9 and couldn't solve the issue). This time I am keen to try out 14.2 see if I do any better.

I see in the Changelog that D3D11 is supported by release 14.2. However I also see in the wiki that Ogre is not thread-safe. Does this mean the multi-thread support of D3D11 is not used in 14.2 and we should be calling Ogre from a single thread only?

Many thanks in advance

[rpgplayerrobin]

It's been 4 years already since I was here last, trying out Ogre 2.x (but I somehow got worse performance than Ogre 1.9 and couldn't solve the issue).

I have the same issue with Ogre 2.x, it does have lower performance for me as well because its shaders are more advanced. But it might have much better performance on computers with better GPUs though.
But if you use advanced shaders in non-Ogre 2.x, the performance might not be as good since Ogre 2.x has automatic instancing and such.

I see in the Changelog that D3D11 is supported by release 14.2. However I also see in the wiki that Ogre is not thread-safe. Does this mean the multi-thread support of D3D11 is not used in 14.2 and we should be calling Ogre from a single thread only?

What kind of threads are you planning to use?
If you are thinking about putting renderOneFrame in a thread, you can not do that while doing other stuff at the same time.
But you could multithread a lot of other different stuff, like your own specific codes and calculations that has nothing to do with Ogre.
You can also use multithreading to compile shaders (which greatly reduces the time taken, in my game from around 20 seconds down to 5 on startup, viewtopic.php?p=552949#p552949).

What kind of multithreading do you actually need in your application? In what way would you need multithreading support of D3D11?

[cc9cii]

What kind of multithreading do you actually need in your application? In what way would you need multithreading support of D3D11?

That is a very good question and in terms of D3D11 I don't have any plans mainly because I don't know much about D3D11 other than some superficial things.

Multithreading other parts of the engine, though, would be very useful. For example loading cell assets in the background as the player character moves towards a cell boundary, computing pathgrid/navmesh, dialogue rules filtering, etc. There are lots of areas where multithreading can provide a more pleasant experience.

I am hoping that I can call Ogre's resource manager from any thread since background cell loading would be the most noticeable gain for me.

[rpgplayerrobin]

For example loading cell assets in the background as the player character moves towards a cell boundary

That can be done, it is called background loading when it comes to resource groups. That is a multithreaded resource group that you can request, and then when it is finished you can actually create the assets needed.
Check here: viewtopic.php?p=552956#p552956

computing pathgrid/navmesh

That has nothing to do with the engine, since that is your own code, which means that you can easily multithread it.

dialogue rules filtering

I have no idea what that is, but does it have anything to do with the engine? Otherwise you can multithread it.

[paroj]

see this why Ogre is deliberately not thread-safe:
viewtopic.php?f=4&t=52863

when you look at the new Task API, you can immediately see why locking is not needed for the proposed usage:
https://github.com/OGRECave/ogre/blob/m ... -workqueue

the Response is always sent via addMainThreadTask.

[cc9cii]

Thank you. I am quite keen (and excited!) to try out the new work queue system.

My main concern is that I am forced to interact with the assets stored with Ogre resource manager - to dynamically modify face mesh and textures (for FaceGen), to analyze lip sync data, to play voice/music/sound files, etc. I guess they have to be accessed via the work queue system.

Are there any examples or working projects that I can see?

[cc9cii]

For example loading cell assets in the background as the player character moves towards a cell boundary

That can be done, it is called background loading when it comes to resource groups. That is a multithreaded resource group that you can request, and then when it is finished you can actually create the assets needed.
Check here: viewtopic.php?p=552956#p552956

Thanks, I will read the posts carefully.

Edit:

I have the same issue with Ogre 2.x, it does have lower performance for me as well because its shaders are more advanced. But it might have much better performance on computers with better GPUs though.
But if you use advanced shaders in non-Ogre 2.x, the performance might not be as good since Ogre 2.x has automatic instancing and such.

I'm quite interested in your experiences. I'll try to search the forum but if you have a link handy it will be much appreciated. In my case I found some strange results. e.g. NSight results indicating 25%-50% of frame time spent on drawing MyGUI widgets and wildly different performance depending on whether I'm using iGpu or dGpu

dialogue rules filtering

I have no idea what that is, but does it have anything to do with the engine? Otherwise you can multithread it.

The assets I've got include thousands and thousands of dialogue lines and responses that have to be filtered based on the talking parties' race, gender, factions, ownership of items, cell location, etc, etc. Additionally the filter has to take into account of quests completed (and stages of completion), any script variables that were set, and so on. There are 100+ different functions that do these checks.

But as you say these wouldn't have anything to do with Ogre and should be safe, unlike my concerns with mesh/textures.

[paroj]

Thank you. I am quite keen (and excited!) to try out the new work queue system.

My main concern is that I am forced to interact with the assets stored with Ogre resource manager - to dynamically modify face mesh and textures (for FaceGen), to analyze lip sync data, to play voice/music/sound files, etc. I guess they have to be accessed via the work queue system.

note that "not threadsafe" does not mean you cannot access the resources from a background thread. It merely means that you must lock the access yourself if you try to access the resource from multiple threads.
This is implicitly done if you use the work queue system as the queue is locked internally.

Are there any examples or working projects that I can see?

ResourceBackgroundQueue would be a prime example:
https://github.com/OGRECave/ogre/blob/c ... ue.cpp#L90