Jump to content
jen

Thread Safe LE

Recommended Posts

Need LE thread safe. Huge potential for performance improvement. I tried but too unstable, got 80fps with threading from 30 FPS on single thread before application crashes.

Share this post


Link to post

This is my second thread code:

 

void App::RemoteUpdate(){
while(true){
if( nFrame == 3 &&
!nMenuEnabled &&
!nOpenBuyMenu){

playerDirX = Math::Curve(nWindow->GetMousePosition().x - Math::Round(nContext->GetWidth() / 2), playerDirX, 3);
playerDirZ = Math::Curve(nWindow->GetMousePosition().y - Math::Round(nContext->GetHeight() / 2), playerDirZ, 3);
camRotX = Math::Clamp(camRotX + playerDirZ / ((1 + nMouseSensitivity) * 2), -90, 90) - (recoilRotX / 3);
camRotY = camRotY + (playerDirX / ((1 + nMouseSensitivity) * 2) * (isAttacking == true ? Math::Random(Weapons[currentWeapon].Controllability) : 1));
//SET MOUSEBACK
nWindow->SetMousePosition(nContext->GetWidth() / 2, nContext->GetHeight() / 2);
nCamera->SetRotation(camRotX + (recoilRotX / 3), 0, 0);
}
}
}

 

nCamera->SetRotation(x,x,x) crashes the game.

 

I want nCamera->SetRotation() and

 

playerCharacter->SetInput to be thread safe.

 

Those 2 functions are very costly and aren't suitable to be placed in the main thread.

 

Don't really have to make all functions thread safe, just those two and we get fps boost.

Share this post


Link to post

I think there's a fundamental problem with making SetRotation work on multiple threads.

 

If I had to guess calling SetRotation would pass the data to OpenGL's uniforms directly. The problem is that OpenGL isn't multi-threaded by nature. You have to explicitly share the OpenGL context across both threads. See here for an example code with OpenGL threading. https://www.khronos.org/opengl/wiki/OpenGL_and_multithreading

 

Also if SetRotation crashes, how do you know it provides a speed boost?

 

If you comment out SetRotation, your game is just rendering a static image which the bottlekneck might not be the rendering performance but the bandwidth to the graphics card itself. By changing SetRotation you might be re-sending all your vertex buffers to your graphics card. Depending on how clipping is implemented and how LE implements OpenGL.

Share this post


Link to post

I have a little widget on the corner that tells me fps count. It's 63 in the pic because its only drawing 2d. When nCamera->SetRotation is removed from main thread it would spike up to 80+ fps.

 

My game always floats at 30-40 fps. For FPS game its really bad. I try on 970 GTX and still 30-40 fps. It's a programming issue definitely. And thats only with a very simple scene with 12 point lights and few boxes.

 

So it just a matter of swapping single lines of codes to check for performance difference. I tried it multiple times and the difference is very apparent. nCamera->SetRotaton, SetPosition, and Player Character SetInput are the ones costing so much fps drop.

 

 

zDg4SEN.png

 

 

I know everyone claims Leadwerks is just for "hobbyist" and that these extreme features aren't needed for "hobbyist" type of games (simple and low resource) but no hobbyist would want to spend $200 just to get software I wouldn't think.

 

Without these critical features Leadwerks is really kind of useless to commercial game developers who want to create serious games.

Share this post


Link to post

Make a small project with 2 maps showing this difference and package it up and make a bug report. Maybe something is going on that josh can take a look at.

Share this post


Link to post

Perhaps when SetInput does not receive non-zero values, the function skips every type of calculation, except acceleration and deceleration and this would result in the saving of the CPU for all those entities that do not move.

 

This is what I think, but it's up to Josh the last word

Share this post


Link to post

It is not possible to make the engine so you can call any command at any time from multiple threads. The only way would be to lock all threads every single time any command was called, which would not give you any performance increase.

 

Many times people have showed me projects and I showed them how to gain massive performance increases. You've really got to test by commenting out some parts of the code and you may be surprised what you find.

 

There are also other possibilities I have avoided, like only updating shadows and animation every few frames. This may introduce perceptable jitter to rendering but will relieve some of the biggest bottlenecks in the renderer. Can't say any more than that right now.

Share this post


Link to post

Really large number of characters running fast:

 

 

I'm actually shocked how fast the second video is. It's amazing how fast optimized C++ can be when you get rid of all memory allocations, etc. That's a single thread handling all those animations, and they are all unique, so it's updating tens of thousands of bones.

 

This is very encouraging. Valve had to do some heavy multithreading to get numbers of zombies like that running in Left 4 Dead and our code seems to be running a lot faster given that this is all on a single thread.

Share this post


Link to post

Really large number of characters running fast:

 

can we get the executable of this demo? i want to test on my pc.

Share this post


Link to post

All I did was drop the default prefab into the scene. The animation test just uses the model with the animation script.

Share this post


Link to post

An update is available on the beta branch that will improve performance, especially with a lot of point and spot lights, Windows/Lua only right now.

 

I based this off of A Demon's Game and my own test levels. No one in this thread posted a map for me to test, so I don't know if this will affect your game.

 

Many games in the game launcher get a big performance increase when using the new executable. Many other games will crash because it is unstable right now and needs more testing.

Share this post


Link to post

Here's a nice easy to understand presentation from Nvidia:

https://developer.nvidia.com/sites/default/files/akamai/gameworks/blog/munich/mschott_vulkan_multi_threading.pdf

 

Vulkan handles multithreading very well, but there is absolutely no reason to try to write a multithreaded OpenGL renderer because it would not run any faster. It makes the most sense to focus on optimizing our single-threaded renderer and wait for Vulkan to gain more industry support.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...