[Resolved] Dev build, fewer FPS in some scenes using stencil shadows

[Daft Mugi]

@stgatilov In Written in Stone at 308 -1768 123 -13.7 68.3 0 (noclip) using stencil shadows (r10166), the FPS drops from 60 to 45-50. There is no FPS drop with r9853/2.10; it's 60 fps.

I found that enabling Frontend Acceleration improved the situation and FPS was a steady 60 fps.

Summarized:

• Frontend Acceleration enabled
  • r10166 stencil 60 fps
• Frontend Acceleration disabled
  • r10166 stencil 45-50 fps
  • r10166 maps 60 fps
  • r9853 stencil 60 fps

I thought you might want to investigate this scene. Maybe there's an optimization that can be done.

Edited November 30, 2022 by Daft Mugi

[stgatilov]

What about "r_softShadowsMipmaps 0"?

[Daft Mugi]

5 minutes ago, stgatilov said:

What about "r_softShadowsMipmaps 0"?

No difference.

[stgatilov]

What about "r_modelBvhBuild 0" before starting mission?

This cvar is non-archivable, and it takes effect on loading models.

[Daft Mugi]

4 hours ago, stgatilov said:

What about "r_modelBvhBuild 0" before starting mission?

That made the FPS a steady 60 fps.

So, what does that tell us?

[nbohr1more]

1 hour ago, Daft Mugi said:

That made the FPS a steady 60 fps.

So, what does that tell us?

The BVH optimization that splits models might be doing too much work in that scene.

What might be informative is if you uncap FPS ( com_fixedTic 1 ) and try setting r_modelBvhBuild back to the default setting. It may be that it doesn't properly work with capped FPS for some reason? Also see what happens with Frontend Accelleration enabled and uncapped FPS when you toggle r_modelBvhBuild to different modes.

[stgatilov]

"Frontend acceleration" causes this work to be done on separate threads, where it no longer matters how long it takes (unless you have a 2-core CPU).

[Daft Mugi]

42 minutes ago, nbohr1more said:

What might be informative is if you uncap FPS ( com_fixedTic 1 )

For the results so far, my settings have been com_fixedTic 1 and com_maxFPS 60.

On Linux with an AMD GPU, com_fixedTic 0 has a low, erratic FPS. So, I don't use com_fixedTic 0.

 

@stgatilov Compared to r9853/2.10, I know recent dev builds have a different and improved implementation of stencil shadows. So, what has changed in the new implementation that would cause this particular scene and view angle to have worse performance even though other scenes have better performance?

Edited November 20, 2022 by Daft Mugi

[stgatilov]

10 minutes ago, Daft Mugi said:

Compared to r9853/2.10, I know recent dev builds have a different and improved implementation of stencil shadows. So, what has changed in the new implementation that would cause this particular scene and view angle to have worse performance even though other scenes have better performance?

It uses BVH culling, which is way faster on large meshes:

 

[nbohr1more]

26 minutes ago, Daft Mugi said:

For the results so far, my settings have been com_fixedTic 1 and com_maxFPS 60.

On Linux with an AMD GPU, com_fixedTic 0 has a low, erratic FPS. So, I don't use com_fixedTic 0.

To determine if there is any further bvh bottle-necking in accelerated mode we will need you to set com_maxFPS to something high enough to show a difference, maybe 120 ?

[Daft Mugi]

9 minutes ago, nbohr1more said:

To determine if there is any further bvh bottle-necking in accelerated mode we will need you to set com_maxFPS to something high enough to show a difference, maybe 120 ?

I tried setting max FPS to 120 and vsync off, but my FPS is still 60 fps. I wonder why that is.

[nbohr1more]

6 minutes ago, Daft Mugi said:

I tried setting max FPS to 120 and vsync off, but my FPS is still 60 fps. I wonder why that is.

Could be forced vsync in your video driver, forced vsync in your desktop composite solution, etc?

You have TDM set to Windowed, Fullscreen, or Borderless Windowed ?

[Daft Mugi]

24 minutes ago, nbohr1more said:

Could be forced vsync in your video driver, forced vsync in your desktop composite solution, etc?

I thought the same at first, so I tested a few other games. I'm able to run Quake (Ironwail) with an uncapped framerate. I even got over 3800 fps on the start map. That was just for this test, though. I usually cap it at 60.

47 minutes ago, nbohr1more said:

You have TDM set to Windowed, Fullscreen, or Borderless Windowed ?

Fullscreen

[datiswous]

14 hours ago, Daft Mugi said:

I tried setting max FPS to 120 and vsync off, but my FPS is still 60 fps. I wonder why that is.

Maybe related: If I (in Linux) start the nVidia config software, quit and then start TDM, I get high fps. If I don't start the nVidia software first, fps is capped at 60fps.

[nbohr1more]

As a general proviso, I would caution against using well optimized missions like "Written in Stone" for evaluating this BVH feature. While it might be desirable that the heuristic detect when a mapper has done considerable work with visportals and culling to evade the necessity of BVH culling evaluations and disable them, it's entirely unclear whether any such heuristic is even feasible. The BVH feature is for very poorly optimized missions. It should have negligible impact on optimized missions while drastically improving poorly optimized ones. I'll try to replicate locally but I would not expect too much more work to improve things here. I guess it might be cool if there were an entity flag to bypass BVH for mappers who are experts at optimization? ( LOD \ SEED flags already bypass it in the latest builds as I recall )

[stgatilov]

Map authors are not the authority to decide on optimizations to enable, unless it is behavior-specific

We can try to tweak BVH, but I think the results will be scene-specific.
It is possible to change leaf size.
Also, it might be worthwhile to disable BVH for small meshes.

 

[nbohr1more]

Probably not all that useful but in my testing "r_modelBvhBuild 0" did not make the above scene any faster,

only Frontend Acceleration helped with performance.

I probably have different bottle-necks with a GTX 1050 and an i7-3xxx CPU.

[stgatilov]

13 hours ago, nbohr1more said:

Probably not all that useful but in my testing "r_modelBvhBuild 0" did not make the above scene any faster,

I hope you did set the cvar before starting mission?
Just to make sure... because otherise it did not apply.

Anyway, it is indeed possible.

Locally, I don't see much difference, but I see that shadow computation takes too much, and it seems to take about 1 ms less (out of 14ms) without BVH. I think I'll make BVH shadow computations more coarse, and hopefully it will help.

[nbohr1more]

Yes, I set it before running the mission.

I guess I should do my homework about setting up tracy profiling rather than eyeballing FPS.

( I still think the home-grown performance tool in 2.08 was very cool. )

[stgatilov]

I added cvars for tuning BVH code in runtime:

• modelBvhShadowsGranularity
• modelBvhLightTrisGranularity

Meshes with size less than X are now processed using the old non-BVH algorithm, so if you set it to huge value, you'll get non-BVH performance (well, almost). Also it limits how much BVH traversal recurses into its subnodes.

However, I did not get much difference from tuning them.

Also, I have optimized the shadow volume generation algorithm with BVH.
Now it should be somewhat faster than before.

However, don't expect it to reach full non-BVH speed.
The non-BVH algorithm is much simpler (thus less overhead) than BVH-using algorithm, and also it can avoid computing some quantities several times thanks to the fact it always processes all triangles + vertices.
So, some slowdown here is the price to pay.

[Daft Mugi]

@stgatilov I tried out r10174 and tested that scene, and it's now a steady 60 fps with Frontend Acceleration disabled. Great job!

I read through your code changes, and my jaw dropped. It's really impressive work!

When I originally posted about the drop in FPS, I thought maybe a few basic tweaks could be made. You went above and beyond that. I appreciate that you used several different techniques to improve performance.