Possible Performance Gain

[Springheel]

There's a line in doomconfig.cfg: seta tdm_lg_interleave "1"

 

The higher the number, the less often a rendershot is taken for lightgem calculations. That also reduces processing considerably. Someone recently reported a 10 FPS gain by setting it to "3".

 

When we first set up the lightgem 5 years ago, some people experienced side effects from setting this higher--possibly visual stuttering or flickering particles.

 

Personally, my memory is a bit hazy on this, and it seems like it would be worth re-testing this. Maybe not all systems will suffer side-effects, or something we've done in the past 5 years has negated the effect. You never know. A gain of 10 FPS is definitely worth a look.

 

Anyone who feels like it could easily replace that value in their doomconfig.cfg file with a number higher than 1, and let us know what the results are--FPS gain, and any side-effects.

 

This might be a perfect fit for people who have had to give up on missions that are particularly taxing...pump your value up to 5 and see if they're playable.

[Tels]

The results are a bit inconclusive on my system - the FPS differ from 30...60 on my system and swerve rapidly even without doing anything. So changing the tdm_lg_interleave did not have a real observable effect except that I *think* that values above 1 make it faster, values like 5 dramatically and even values like 10 seem to work in that I could not observe a wrong lg value.

 

Funnily enough, I did run into the "AI freeze" issue because the AAS was not uptodate on SL, in this case the AI freeze with their hammer over their head and the console gets spammed with:

 

Destination unreachable...
Destination unreachable...
Destination unreachable...
Destination unreachable...
...

 

In these cases I also get 7..12 FPS (and tdm_lg_interleave seems to bring a lot of FPS in that situation, but then, it swerves wildly again).

[Fidcal]

Just had time for a quick test set at 5. I don't see any problem with the light gem. Works normally.

 

Framerates seem good outside in my FM but inconclusive as they do vary. I'd need to do a better specific test. Inside near the main stair they looked much better than I'd ever seen. From 25-30 up to 45-55fps. But don't rely on that. Maybe more AI were elsewhere by chance. I'm leaving it on 5 for now and try to do more testing tomorrow.

[Springheel]

The number apparently sets how often the rendershot is taken, in frames. A value of 1 means every frame (technically every other frame, since the shot takes a top-down shot one frame and a bottom-up shot the next). There are 60 frames a second, so theoretically you could set this value as high as 30 (do we need the lightgem to be accurate to more than half-a-second?)

 

There's got to be some problem though...I can't believe we've been sitting on a performance enhancement like this. The thing to test is particle effects (shoot some water and gas arrows) and water effects. See if there is any flickering. That's what used to be reported:

 

Also, the reason you probably see more flickering with tdm_lg_interleave > 1 (or is it > 2?) is that there are frames in that with absolutely no render shot, whereas tdm_lg_interleave of 1 means there's always a render shot (either one or both of them, depending on tdm_lg_split). So it really emphasizes what is different in the case of no lightgem render shot and with lightgem render shots.

 

I never tested it with interleave other then 1. Now I tried and it seems to be related to this. In fact it doesn't behave correct with 1 as well, but there the effect doesn't seem so noticable. When I switch to interleave 0 then I can also fire water arrows at the floor and they behave correct. I have to test this a bit.

 

http://forums.thedarkmod.com/index.php?showtopic=2961&view=findpost&p=79392

[New Horizon]

When we first set up the lightgem 5 years ago, some people experienced side effects from setting this higher--possibly visual stuttering or flickering particles.

 

There was some internal testing more recent than that though, just a few months ago. It was around the time JC introduced the fade time to the light gem transition. I'll try again to see what happens, but I remember the frame rate getting extremely choppy above 1 in Somewhere above the City.

[fllood]

Briefly tested 'Too Late' on my rather low-mid range PC with lightgem interleave set to 5.

Extinguished a few torches and some bonfire, did a swim (doubleVision disabled) and a quicktaff through the little mission. I only had the time for a very quick test so far but didn't noticed striking flicker at first glance. With much increased nervous fps display amplitude the map has a much significant fps gain on my machine of about 20-40% (depending on the area). Really Amazing !!

[New Horizon]

Briefly tested 'Too Late' on my rather low-mid range PC with lightgem interleave set to 5.

Extinguished a few torches and some bonfire, did a swim (doubleVision disabled) and a quicktaff through the little mission. I only had the time for a very quick test so far but didn't noticed striking flicker at first glance. With much increased nervous fps display amplitude the map has a much significant fps gain on my machine of about 20-40% (depending on the area). Really Amazing !!

 

So your movement wasn't choppy at all?

 

On my system, I'm finding that anything above 1 causes my movement to stutter. I wanted to capture this, but when I enable fraps...guess what happens...the movement smooths out. Go figure. lol Any idea what might cause that to happen?

[nbohr1more]

Are you ATI or Nvidia...

 

(That sounds like an affinity issue: eg Threaded Optimizations ?)

 

Specs please?

[rebb]

Doesn't Fraps cap the Frame-Rate of the Game when recording ?

 

Maybe the choppy movement is due to the high FPS fluctuation others are seeing, and the Fraps cap causes the fluctuation to not be as large as before.

[Aprilsister]

Well, my experience tells me that if you are aware of the fact that you were previously aware (at least twice it appears this has been previously fiddled with) of the manipulation and you dropped it... that there was a good reason. And knowing you lot, the thing probably got a thorough pros-and-cons session or two.

 

What is strange is that with all the tech we have these days we still manage to mislay things. It would seem almost impossible that you couldn't just do a serach in a few relevant places for "tdm_lg_interleave" and find out the what and the why. Maddening isn't it?

[nbohr1more]

Vsync to the rescue?

[New Horizon]

Are you ATI or Nvidia...

 

(That sounds like an affinity issue: eg Threaded Optimizations ?)

 

Specs please?

I am using Nvidia.

 

I tried vsync, but no change.

[Springheel]

I tried a value of 15 and got quite a performance boost.

 

Interestingly, I got *better* particle effects. Gas arrows shot down at the floor normally disappear for me after a couple frames. With interleave set to 15 they display normally, though with a faint flicker.

 

Unfortunately, the skybox flickers faintly, but noticeably, which I wouldn't want to live with. I'll try a lower value and see if it still happens.

 

Still might be a valuable tweak for someone who otherwise couldn't run a mission, however.

 

edit: set to "2", the sky flickering is even worse, and even regular lights flicker now.

[Serpentine]

Anything from having free multiple cores to having a long flip-queue could make this choppy. I'd try enabling triple buffering for OpenGL and see if that changes anything. Also look for STiFU's thread on micro-stutters, might be something handy in there

[nbohr1more]

I am using Nvidia.

 

I tried vsync, but no change.

 

Try running in Windowed mode and changing the CPU affinity in task manager (or disable cores?) Also try running it in low priority. I've seen some more modern titles require these types of adjustments...

 

(I am presuming that you have disabled Threaded Optimizations.)

[New Horizon]

(I am presuming that you have disabled Threaded Optimizations.)

 

I have done so.

 

I think it might be something that would require a fix on our end to smooth things out. I've tried every setting I could throw at it.

[nbohr1more]

Well... as a last resort some Doom 3 studders have been fixed by the notorious com_fixedTic 1 "uncapping" cvar. Try at your own risk...

[Springheel]

Interestingly, I tried a value of "30" and noticed the following results:

 

1. Skybox no longer flickered as it did at 2 and 15.

 

2. Gas arrows still behaved better than they did at 1.

 

3. There was a noticable, half-second lag in the lightgem, but I doubt it would have any gameplay implications.

 

4. I got a gain of at least 20 FPS.

 

 

I'm going to test this a bit more.

[New Horizon]

Interestingly, I tried a value of "30" and noticed the following results:

 

1. Skybox no longer flickered as it did at 2 and 15.

 

2. Gas arrows still behaved better than they did at 1.

 

3. There was a noticable, half-second lag in the lightgem, but I doubt it would have any gameplay implications.

 

4. I got a gain of at least 20 FPS.

 

I'll have to test it further, but this might actually be doable.

 

Funny thing is, i don't see any particle flicker or skybox flicker...regardless of my settings. Doesn't seem like it's a very reliable tweak yet in its current form.

[Bikerdude]

Try running in Windowed mode and changing the CPU affinity in task manager (or disable cores?) Also try running it in low priority. I've seen some more modern titles require these types of adjustments...

Jesus!

 

tried a value of 30 and got a 5-16fps increase at the start area(39 upto 55), the lower end was due to 2 Ai being in the players view. I didnt notice any weirdness or things not working as they should.

Edited January 21, 2011 by Bikerdude

[nbohr1more]

(Sorry for the OT)

 

This might be premature but...

 

Since the new RTTC now appears to have a performance hit again, is there any chance that you guys would make the first "performance breakthrough" version of the otherwise original RTTC available for the low-enders?

 

I know it's not as glitzy as the as the major overhaul you guys have done but some of the kids would still be interested in seeing what the original would be like if it were playable for them.

 

(Not sure if the new map is now more GPU limited verses the CPU limited original... looking forward to finding out ).

[Tels]

The number apparently sets how often the rendershot is taken, in frames. A value of 1 means every frame (technically every other frame, since the shot takes a top-down shot one frame and a bottom-up shot the next). There are 60 frames a second, so theoretically you could set this value as high as 30 (do we need the lightgem to be accurate to more than half-a-second?)

 

A: Is the Lightgem really done every other "thinking frame" (e.g. always 60/s) or every other render frame? Because if there is a low FPS (e.g. a lot to render), the lg will only be taken every 30th frame (not every 0.5s), so if you have only 10 FPS, it will be taken every 3 seconds.

B: If you go higher than 1/10s for the shot, the lightgem will no longer flicker with the lights, f.i. torch lights.

 

Also there is the law of dimishing returns, a value of 2 vs. 1 will bring big improvements (half of the shots taken), a value of 3 less so (only 1/3 of the shots taken, but 1/3 is not that smaller than 1/4) and a value of 4 even less (1/2 of the shots taken). In other words, values above 5 will bring less and less improvement, but make the result worse and worse.

 

Edit: Springheel, in your case the flickering can be an artefact of the lightgem shots, and if you set the value really high, it is gone because the lightgem shots almost never happen and if you set it to 1, it doesn't flicker due to uh ah well because I say so. Maybe it is having things better cached when it is set to 1. Back to the drawing board...

[STiFU]

Hmn, that flickering is really weird. I mean the LG rendershot is not loaded into the framebuffer, right? So basically, the only effect the rendershot should have on the resulting image output, is possibly small delays, which should theoretically be smoothed out by triple buffering, unless the delay is too long compared to the frame endurance, which apparently seems to be the case in my experiments. Of course, raising the interleave value improves overall performance a lot, but when that lg rendershot is taken, the fps very briefly drop again, which results in the perceived stutter. With low interleave values, you won't perceive this stutter, because there are no transitions between smooth and jittery visuals.

 

Tels, you've got valid points there. I just tried to set max fps to a low value to proof your theory, but apparently there is no way to set max fps in D3. You supposedly can do it via the following cvars:

seta com_fixedTic "-1" // Remove frame limit

seta r_displayRefresh "100" // Refresh rate

But those cvars didn't do anything for me. So I fired up the good old unoptimized version of RTTC in windowed mode. With lg_interleave at 30 I searched for a position with very low fps and a hard shadow / light transition. When looking at the floor (=60 fps), the lg delay was hardly noticeable, but with the lower fps, the lg delay got stronger, so Tels assumption A is correct and we will have to be careful here.

[OrbWeaver]

I think we speculated the the particle flicker was due to the billboarding of particles: each particle polygon is rotated to face the camera, and with the light gem there are two extra "cameras" being used. There could be any number of other issues in the Doom 3 renderer that could cause artifacts though; it was just never designed to be used in this way.

[stgatilov]

Why guessing how it works if we have the code?

 

The lightgem render is done every k-th frame where k is the value of tdm_cg_interleave parameter. So if processing a frame without lightgem takes A time and lightgem itself takes B time, then you need A + B/k time per frame on average. The so-called "law of diminishing results" for FPS is obvious from this formula, isn't it?

 

Of course this time per frame is average. To be strict, there are k-1 frames with A full processing time and one frame with A+B processing time. So there is indeed a small stutter every k-th frame. Do not set interleave to high values - 3-5 should be enough to lower the influence of lightgem on the average FPS.

 

Also the interleaving depends on FPS. So interleave 10 with 60 FPS is 166 msec lag, while with 10 FPS it becomes 1 sec lag. Again: do not set high values of it and you won't have trouble. By the way, I suppose that there are a lot of important gameplay things that depend on your FPS.

 

I'm sure that the information from this thread should be added to wiki article "Performance tweaks" even if it is unreliable because it gives noticable boost to some people (me included).

 

The bugs of interleaved lightgem rendering are very interesting. Maybe there can be fixed? Right now I can't understand most of the problems... Maybe someone can capture the video?