Very low performance on AMD GPU

[MirceaKitsune]

29 minutes ago, stgatilov said:

Perhaps you should add -DCMAKE_BUILD_TYPE="Release", since it is not clear whether build would be optimized or not otherwise.

Also, you can try Tracy profiler to record a performance profile.
Set "com_enableTracing 1", then download Tracy viewer of appropriate version.
More details on wiki page.

With Tracy, you can see a lot of things immediately, e.g. whether it is GPU or CPU which is slow, which parts are slow, etc.

And now I'm concerned if I wasted everyone's time and should feel bad. Did another "svn update" to 10212, completely deleted the build directory, recompiled with the -DCMAKE_BUILD_TYPE="Release" flag: Now performance is back to normal levels, loading times are also lightning fast by comparison. I don't know if the new rev fixed something or "make clean" wasn't enough or that release flag makes such a difference... if it was local all along sorry for that

But yes, everything is working like before for me now that this is solved. No performance improvement on AMD Linux... the issue lowenz reported may have been specific to Windows AMD after all, my low FPS may just be the best that is possible. Glad I can at least confirm everything seems to be well for everyone now.

[nbohr1more]

No worries.

I experienced a noticeable performance downgrade ( not as extreme ) so I will test again this evening and get hard numbers if anything is off.

[stgatilov]

24 minutes ago, nbohr1more said:

I experienced a noticeable performance downgrade ( not as extreme ) so I will test again this evening and get hard numbers if anything is off.

Yeah, I guess you are the only one remaining.

27 minutes ago, MirceaKitsune said:

Did another "svn update" to 10212, completely deleted the build directory, recompiled with the -DCMAKE_BUILD_TYPE="Release" flag: Now performance is back to normal levels

I have blocked CMake build on GCC without specifying CMAKE_BUILD_TYPE to avoid such confusion in future.

7 hours ago, AluminumHaste said:

Wait, @stgatilov what did you do? I'm getting incredible performance now on Iris!
I was lucky to get 120 fps in this area a few days ago!

Hmm... I guess you feel like in this joke:

Spoiler

A Jew comes to Rabbi and starts complaining about his life:
- Rabbi, my life is so hard and I'm so tired. What should I do?
- Buy a goat.
- What? I have a wife and seven kids and we all live in a small apartment and there is no possibility to keep a goat there…
- Just follow my advise.
In a week the Jew comes to Rabbi again and starts complaining about his life even more:
- Rabbi, I followed your advice and now my life is much harder than before: the goat stinks and makes more noise than my wife and seven kids! What should I do?
- Sell the goat.

 

[AluminumHaste]

13 minutes ago, stgatilov said:

Yeah, I guess you are the only one remaining.

I have blocked CMake build on GCC without specifying CMAKE_BUILD_TYPE to avoid such confusion in future.

Hmm... I guess you feel like in this joke:

  Hide contents

A Jew comes to Rabbi and starts complaining about his life:
- Rabbi, my life is so hard and I'm so tired. What should I do?
- Buy a goat.
- What? I have a wife and seven kids and we all live in a small apartment and there is no possibility to keep a goat there…
- Just follow my advise.
In a week the Jew comes to Rabbi again and starts complaining about his life even more:
- Rabbi, I followed your advice and now my life is much harder than before: the goat stinks and makes more noise than my wife and seven kids! What should I do?
- Sell the goat.

 

I don't get it, sorry this stuff goes over my head.

I wasn't complaining about extra performance.....I was ecstatic

[stgatilov]

5 minutes ago, AluminumHaste said:

I wasn't complaining about extra performance.....I was ecstatic

Yeah, but mainly because we have just sold the goat

[Daft Mugi]

@MirceaKitsune Glad to hear -DCMAKE_BUILD_TYPE="Release" fixed it for you.

Your build is fixed, the dev team has one less thing to do, and @stgatilov added a check for CMAKE_BUILD_TYPE. It's a win-win-win.

[nbohr1more]

1 hour ago, stgatilov said:

Yeah, I guess you are the only one remaining.

Yep. Not sure what was happening but a new compile and compared to 2.11 beta 2 shows matching performance.

No issues here anymore. Performance is great.

Side note, when I want to get fancy with compiles, I add a flag for my own CPU arch:

cmake -DCMAKE_BUILD_TYPE="Release" .. -DGAME_DIR=/home/user/darkmod -DCMAKE_C_COMPILER=gcc-11 -DCMAKE_CXX_COMPILER=g++-11 -DCMAKE_CXX_FLAGS=-march=ivybridge

https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

( doubtful that much is gained at all )

[stgatilov]

7 hours ago, nbohr1more said:

Side note, when I want to get fancy with compiles, I add a flag for my own CPU arch:

cmake -DCMAKE_BUILD_TYPE="Release" .. -DGAME_DIR=/home/user/darkmod -DCMAKE_C_COMPILER=gcc-11 -DCMAKE_CXX_COMPILER=g++-11 -DCMAKE_CXX_FLAGS=-march=ivybridge

Yeah, I don't think it helps much either.
Compiler can use more instructions, but it can rarely help... maybe BMI could make a difference.

By the way, usually people write -march=native to compile for their CPU.

[MirceaKitsune]

Manjaro seems to have gcc-12 so it's nice to know I compiled and tested with that. Wonder how much the compiler usually makes a difference in performance.

Also curious how much running TDM on Wayland over X11 will help with any extra FPS (not expecting more). KDE / Plasma has been slow to become stable on WL but it seems in recent months they finally got there for the most part: If my drawing tablet is also detected by Gimp and power saving works and all, I plan to give it another try soon. IIRC the engine now uses SDL which should already be Wayland native so any potential improvements should be supported.

[MirceaKitsune]

Oh, one more thing now that the main issue has been resolved and this thread can hopefully be a bit generic.

When enabling r_useEntityScissors some ents will be cut off across visportals and not only. You can see it with a volume light here and the skybox leaving trails, sometimes the tops of guards helmets disappear into the void instead. Is this known and can anything be done to improve it? Are entity scissors possible to optimize to work for everyone in general?

I took note of this one as for me it greatly improves FPS, by more than 10 in some places! It feels sad to let it go to waste. I think the other critique was it might decrease performance if too many entities are present... wonder if a triage can be made to avoid that like making it adaptive, to be able to default it as on with maximum efficiency.

Also what was the driver issue with bindless textures and them blocking multidraw from working? IIRC multidraw was also a huge improvement as the GPU could work with copies of the same data. Is there a setting to re-enable bindless textures in case your driver does support them?

Edited December 13, 2022 by MirceaKitsune

[stgatilov]

Regarding scissors: it will be fixed in 6099, but after 2.11.
If you see some other problems (aside from cut headtops), you can leave a comment there.

Regarding bindless textures, I hope they'll never be restored.
Because in OpenGL they are completely unmanageable: you cannot debug it in any tool, and any error can crash the whole application (or driver). I've heard in Vulkan they did it in less barbaric way, so the their bindless textures are handled by various tools.

Also you understand multidraw incorrectly.
Rendering several copies of same geometry is called "instancing", and can only help when you know objects are the same... which is pretty rare I guess.

[lowenz]

Instancing was introduced back in 2004 to better handle vegetation

Edited December 13, 2022 by lowenz

[MirceaKitsune]

Oh: My thought on instancing was that you're using a single geometry reference for all static and animated models alike. For animated ones of course you deform each one independently, but I imagined the geometry data stored on the GPU is common. Obviously even static meshes are rendered from different angles and lighting.

So say you have 3 guards of the same type rendered in view: The GPU only stores the model for one guard... one might be standing (idle animation) another one moving (walk animation) but they're both rendered from the same geometry / texture cache so common aspects are only processed once. Actually wasn't that called VBO which we already have?

Glad to hear scissors will get improvements! I should mention the volume light issue there as well later. For now I'm happy I could confirm it makes a good difference on some maps so fixing entity scissors is worth it

[stgatilov]

2 hours ago, MirceaKitsune said:

Oh: My thought on instancing was that you're using a single geometry reference for all static and animated models alike. For animated ones of course you deform each one independently, but I imagined the geometry data stored on the GPU is common. Obviously even static meshes are rendered from different angles and lighting.

Models and textures are of course rendered from the same data.
But draw calls are made individually for every instance --- we don't use instancing.

What's the point of instancing?
Ask yourself: how often you see many objects with exactly the same model in one view?
Mappers try to make some variation, otherwise it looks weird.

Also, the engine does animation on CPU, so animated models don't share the geometry being rendered.

[HMart]

On 12/13/2022 at 9:51 PM, stgatilov said:

What's the point of instancing?
Ask yourself: how often you see many objects with exactly the same model in one view?

Instancing may not be necessary for TDM dark and relative small spaces, but afaik, before UE5 nanite tech, was the only way using conventional polygon rasterization, to be able to render large open scenes. Scenes filled with large amounts of vegetation and other stuff, ala Crysis and others, those games are filled with cloned/instanced geometry all over the place and personally, I don't remember people strongly complaining about them felling very repetitive.

That's because there's ways to break the repetition and make the scene feel more unique/varied, even if they are just rendering hundreds or millions of the same geometry/model. 

Just look at this IMO fantastic in-game forests scenes, in the medieval simulator game, Kingdom Come Deliverance. These are made in Cryengine 3.x, using instanced geometry and Imposters.

 

[AluminumHaste]

https://learnopengl.com/Advanced-OpenGL/Instancing

Seems pretty useful in any map that uses lots of the same model.
Seed system was added to get around this problem. By batching all the same models in a given space into one draw call (I think).

I used it in my cathedral map that had over 200 pews, I gained another 20 fps with Seed back in 2010 ish, which was huge back then. Same with the forest and the pine trees.

EDIT: For example, we're looking at about 1800 trees.

 

I could probably get another 100 FPS by using SEED volumes to combine the models into a dozen draw calls instead of 1800

 

 

[MirceaKitsune]

It definitely sounds like instancing would help on outdoor maps with lots of trees / bushes / rocks. We don't have many of them at the moment, likely because performance is already a concern given the difficulty of vis-portaling huge open spaces: This could perhaps help improve that, since if an open field only has trees and rocks repeating the same mesh this might reduce the impact of large portal rooms enough to make it bearable.

Of course lighting would remain a concern since instancing doesn't save you from the need to calculate each object and shadows in their own draw call, you'd need to add just a few torches to such a place. Other things might still tank performance in this scenario, but still it's a nice thought: I'm sure I'm not the only one who imagined what giant nature spaces might look like in a TDM FM.

Edited December 18, 2022 by MirceaKitsune

[stgatilov]

Yeah, instancing takes less memory bandwidth than simply copying geometry withint the same model.

You absolutely need good-made LODs in outdoor areas.
On top of that, you probably want to have a few different tree models to create a forest.
So it would be more like 10-15 variations, with 100-200 instances each.

[MirceaKitsune]

2 hours ago, stgatilov said:

Yeah, instancing takes less memory bandwidth than simply copying geometry withint the same model.

You absolutely need good-made LODs in outdoor areas.
On top of that, you probably want to have a few different tree models to create a forest.
So it would be more like 10-15 variations, with 100-200 instances each.

This is a case where supporting bug-free model scaling might have been useful: You could create the illusion of more different trees and rocks by randomly giving each a slightly different scale, including in the Z axis to make some plants shorter or taller while they remain as thick. I figure it's not that big of a difference but would help with an added illusion of randomness.

Random rotation helps the most and that I believe we have. Both a different spin so you always see the same trees from different sides, as well as slight angling. I think seed brushes randomize at least the Z axis, but I forgot if grass and trees also follow the rotation of the patch surface they spawn on so a diagonal slopes have a chance of spawning a diagonal tree.