I am using the following model for drawing using VAR. For each frame:
Finish fence
Update vertices
Draw
Set fence
Finish fence
Update vertices
Draw
Set fence
SwapBuffers
Why is the first FinishFence required? I would have though that the second drawing would have been completed by swapbuffers, rather than by the first fence of the next frame.
If I remove the first fence, my FPS goes from 68 to 90, but I see problems on objects which move position between frames.
Maybe you should do it this way:
Update vertices
Draw
Set fence
Finish fence
Update vertices
Draw
Set fence
Finish fence
SwapBuffers
Because you want the model to be finished BEFORE you show the image on the screen, don´t you?
Hope that works.
Jan.
That’s the thing. Your way works, and my way works.
The fact that finishing the fence AFTER the swapbuffers works makes me wonder why it is needed at all.
[This message has been edited by bakery2k (edited 02-01-2003).]
Another question:
Is there a faster way than using the VC++ memcpy to transfer my data to AGP memory?
[This message has been edited by bakery2k (edited 02-01-2003).]
Swapbuffers flushes all drawing commands before actually flipping the buffers. So you are correct in thinking that it’s silly to set a fence before a swapbuffer and to finish it after the swapbuffer because any drawing operations will have finished by then anyway.
Fences are only useful if you’re going to change some vertex data more than once per frame.
Nah, SwapBuffers doesn’t force the rendering to be finished, at least not if you have vsync disabled. In that case, SwapBuffers merely acts as a glFlush command.
I fail to see why you’d need to finish any fence. Use double (or more) buffers, and allocate your vertices into a pool where the GPU is not reading from, just by testing your fences.
Y.
I hate to be contrary, but I believe it does cause a finish for all drawing operations in the thread that calls swapbuffers. You have to explicitly flush other threads drawing commands before swapping.
I can draw stuff with opengl into a window, call swapbuffers, then proceed to read a pixel from that window using the GDI and get the correct colour. Otherwise what’s the point in naming the function SwapBuffers ? It’s called ->Present in d3d8.
Swapbuffers is an implicit flush on Windows systems and it suppose to return immediatly.
I’m not 100% sure, but that should be behavior v-sync or not.
glReadPixels is like a implicit glFinish, but knack, you get correct pixels with GDI? Curious…
Originally posted by bakery2k:
Another question:
Is there a faster way than using the VC++ memcpy to transfer my data to AGP memory?
You can try MMX. 64 bit transfers.
SwapBuffers flushes, but does NOT finish. It is very possible to be rendering the next frame (after the swapbuffers call), while the GPU is still pulling data related to the previous frame, because it hasn’t yet gotten to the SwapBuffers call you queued.
In general, though, you don’t want to be finishing fences that you set in the same frame; you want to set fences one frame, and finish them the next frame. If you put names on your faces in your pseudo-code, it’d be possible to tell whether you’re already doing this or not.
No, I am currently using the same fence on both occasions. I will try using more than one.
I believe the behaviour for glSwapBuffers is that it flushes but not finishes UNLESS there is another swapbuffers pending. Then it blocks on the earlier swapbuffers (still not strictly a finish).
i.e. a second swapbuffers will block on any earlier swapbuffers limiting the number of swaps that may be queued and limiting latency without excessive stalling of the pipeline. Just what you need for most games.
[This message has been edited by dorbie (edited 02-02-2003).]