Pref::Video::killFramesAhead
by Eric Preisz · in Torque Game Engine Advanced · 09/08/2007 (5:48 am) · 3 replies
So I found this (read got bit by this) recently. I don't remember ever setting this flag and I think it's turned on by default. Setting this flag kills performance in a couple ways.
1) This flag causes a back buffer lock after present. This is pretty much the same as doing a flush in OpenGL. This will first cause the CPU to stall while the DirectX command buffer clears. Since the GPU lags behind the CPU, this buffer could (and should) be quite full.
2) Once the buffer is empty, you will then pay a GPU hit while the command buffer fills back up. It's hard to use your GPU at 100% if the command buffer isn't full.
3) Creating a lockable backbuffer may turn off some optimizations within your graphics pipeline. I'm not positvie about this one, and it's probably driver specific.
A tripple wammy. There are only really a few cases where you would need to perform the functionality provided by this flag. In fact, I wouldn't even make it a pref variable. Just leave the code there and comment it. Those who understand when they need it will find it since they will assume they need to implement it.
Oh, and also, this implementation of "flush" already exists in Dx9. Look up the query interface. (IDirect3DQuery9)
1) This flag causes a back buffer lock after present. This is pretty much the same as doing a flush in OpenGL. This will first cause the CPU to stall while the DirectX command buffer clears. Since the GPU lags behind the CPU, this buffer could (and should) be quite full.
2) Once the buffer is empty, you will then pay a GPU hit while the command buffer fills back up. It's hard to use your GPU at 100% if the command buffer isn't full.
3) Creating a lockable backbuffer may turn off some optimizations within your graphics pipeline. I'm not positvie about this one, and it's probably driver specific.
A tripple wammy. There are only really a few cases where you would need to perform the functionality provided by this flag. In fact, I wouldn't even make it a pref variable. Just leave the code there and comment it. Those who understand when they need it will find it since they will assume they need to implement it.
Oh, and also, this implementation of "flush" already exists in Dx9. Look up the query interface. (IDirect3DQuery9)
About the author
Manager, Programmer, Author, Professor, Small Business Owner, and Marketer.
#2
But it still doesn't seem right to me for performance. It must not be that bad because the command buffer might not be that full. If the performance doesn't change, chances are that the game is CPU limited. When a game is overly CPU limited you will only see a small difference from one GPU to the next. Since GPUs are growing in performance faster than CPUs, that's bad.
Of course this is only an issue for bleeding edge type stuff. That's not usually a requirement for the average hobbiest.
09/08/2007 (1:06 pm)
I could see how it would solve the mouse issue. Since without it, your mouse would render up to two frames or so (driver dependent) behind the cpu's input.But it still doesn't seem right to me for performance. It must not be that bad because the command buffer might not be that full. If the performance doesn't change, chances are that the game is CPU limited. When a game is overly CPU limited you will only see a small difference from one GPU to the next. Since GPUs are growing in performance faster than CPUs, that's bad.
Of course this is only an issue for bleeding edge type stuff. That's not usually a requirement for the average hobbiest.
#3
09/08/2007 (2:47 pm)
It's a factor for SLI (not sure about crossfire). All methods of SLI rendering require at least 1 allowed frame ahead (split-screen included, it does a merger). 
Torque Owner Stefan Lundmark
In any case, the pref is useful when the mouse input is lagging and you want it smooth. I haven't seen much performance loss with it, to be honest.