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.

I am sure that the glprogs folder takes precedence but if you want another point of confirmation please try unpacking the tdm_base01.pk4 then overwrite the glprogs folder inside it and repack to see whether things improve.

For the 10211 results, did you restart TDM between setting changes? What happens with r_shadows 0 in 10211 ?

I believe @stgatilov was asking that you provide comparisons of the basics: 1) Hard Stencil beta vs svn 2) Hard Maps beta vs svn 3) Soft Stencil beta vs svn 4) Soft Maps beta vs svn That should triangulate the affected area. On review of the code change, in theory it "should" perform much better since the blur operations are done on the GPU (thus freeing the CPU for other work) but I guess there may be a pathological GPU pattern that looks good on paper but the hardware or compiler doesn't execute well.

Nvidia here... I lose about 5 to 15% performance with this change. Since the problem is with AMD on Windows, perhaps a shader branch for Linux in general ( AMD on Linux supposedly gets worse with this change too ) ? Not too catastrophic but is gonna be a little tough to explain in a 2.11 release article. It would be cool to know what happens on Nvidia + Windows though...

Rant:

I think your performance concerns are different than those seen by lowenz. That said, there is probably an argument to be made for using a slider in the GUI. One thing I've noticed is that some quality levels have better looking gradation patterns ( more evenly distributed, no banding between gradients ) thus setting 15 can look even better than one of the built-in settings like 26 ( 25 actually looks better than 26 and many of the higher values ). I only have a 1080P resolution display so I can't confirm whether this behavior holds true for other resolutions but it does seem to hold true for variations in renderscale.

Sorry if this sounds redundant but does changing r_softShadowsQuality change performance at all? ( Eg. Does r_softShadowsQuality 6 perform better than 12, 26, etc or do they all offer equally low performance ? )

I would remove that line. It was probably added out of caution to ensure that the correct area is referenced.

Here is an updated deftdm_cubeLights.mtr

script.zip Here is the latest script folder

This can potentially cause performance degradation if there are too many entities in a scene. We probably don't have up to date cost vs benefits metrics on this one so please test elsewhere and report your comparison findings. Edit: r_useEntityScissors is broken: https://bugs.thedarkmod.com/view.php?id=6099 These should still work but there may be some performance regressions due to scissor changes in 2.11. You are not seeing any benefits from either? This theoretically would improve cache coherency for multi-core rendering. @stgatilov evaluated it compared to our own design and considers the benefit to be dubious since we already have better VBO and SIMD accelerated portal optimizations that vanilla Doom 3 and BFG lack.

The only new performance impacting cvars are listed here: r_modelBvh* --- configures all BVH-related optimizations. r_modelBvhBuild is the "kill switch". r_softShadowsMipmaps --- enables the new bandwidth optimization for soft stencil shadows. For at least one AMD user, setting r_useDebugGroups 0 improved performance so that will be the default in the next build. To my knowledge, the multidraw options don't help much if you don't also have bindless textures ( removed in 2.11 due to AMD driver bugs ). Otherwise look here for options: https://wiki.thedarkmod.com/index.php?title=Performance_Tweaks I would suggest that: tdm_lg_interleave 6 tdm_lg_interleave_min 3 or some variant thereof might help. The trick is to try and tune it so that it roughly matches your game modelling tics and refresh rate. Usually values between 2 and 7 ( whatever feels the smoothest ) Just be aware that it may cause lag in the changes to light level shown in the lightgem. Also, if you enable Frontend Acceleration and want to handoff work to more cores, try experimenting with: jobs_numThreads

A few big changes occurred there. It looks like we didn't commit any binaries to SVN between these releases. Are you able to compile from source? If so, can you try compiling 10037 ( big shadow change )?

Psst! In the latest dev build try setting: r_useDebugGroups 0 This was set to 1 in dev16617-10107

I know it will be spammy but what do you get when you set r_debugGLSL 1 ?

Thanks! Please try Dev Build dev16599-10071

Hmm Try: float lcolmax = max(lightColor.r , max(lightColor.g , lightColor.b)) ; float diffusemax = max(params[var_DrawId].diffuseColor.r, max(params[var_DrawId].diffuseColor.g, params[var_DrawId].diffuseColor.b)); FragColor = min((vec4(lightColor * ssao * interactionColor.rgb, interactionColor.a)), ( lcolmax * diffusemax )); FragColor = max(FragColor, vec4(0));

Sure, but it never hurts to keep outputs clean. Presuming you are using r_useNewBackend 1 go to glprogs/stages/interaction/ interaction.ambient.fs.glsl and try replacing the FragColor line with: float lcolmax = max(lightColor.r , max(lightColor.g , lightColor.b)) ; float diffusemax = max(params[var_DrawId].diffuseColor.r, max(params[var_DrawId].diffuseColor.g, params[var_DrawId].diffuseColor.b)); FragColor = min((vec4(lightColor * ssao * interactionColor.rgb, interactionColor.a)), ( lcolmax * diffusemax ));

Probably need to clamp the shader output values somewhere.

Look below the "dev" section, there should be a beta section.

2.11 beta 01 is currently in the installer list. The thread about it will be out soon but you can test it now. That said, we need to bisect your performance problem by having you test older builds starting with 2.08

See: https://bugs.thedarkmod.com/view.php?id=6090 for the new definition design

@lowenz is that result from 2.08, 2.10 or 2.11 ? stgatilov wanted to see whether the same issue impacts 2.08 for comparison.