Since I wrote my original "Relieving the bottleneck" post, I have come across another post here ("Why is Present so slow?") which discusses similar issues to those I addressed.
The basic problem occurs with, and only applies to, a combination of a fast CPU but a slow GPU. The CPU is sending data and commands faster than the GPU can handle, and from time to time the GPU needs to stall in order to catch up.
The theory is to deliberately slow down the rate at which the CPU sends data and commands so as to remove, or at least reduce, the need to stall.
As I said in my previous post, this is a feature that is off by default, but that can be enabled if you are experiencing symptoms. It's not a magical cure all as stalls could be coming from many other potential sources, but it might help.
One (related) thing that needs attention drawn to it is that there is an untruth in the Wikipedia Comparison of OpenGL and Direct3D article. This makes mention of a mode transition (user mode to kernel mode and back) which it intimates (but rather cleverly so, and without saying it directly) occurs with every API call. This is not the case, it actually occurs when the command buffer is full and needs to be emptied.
This article has been noted as being biased in the past. Beware.
4 comments:
See if you cant rewrite it! ;)
Afterall it's a wiki, and you are someone who knows better.
Sounds a lot like gl_finish to me.. Maybe you should call it that in DirectQ, for compatibility sake ;)
Not really, glFinish is different. glFinish forces the on-hardware command buffer to be fully flushed every frame, stalling until it is done; this slows down the rate at which commands go to the in-software command buffer (D3D maintains a buffer in software as well as the hardware one). Default D3D behaviour is like gl_finish 0 in Quake, and D3D doesn't actually have an equivalent of the glFinish function (you can write your own with queries though).
I see, well thanks for clarifying, learn something from reading your blog every time :D
Post a Comment