PDA

View Full Version : NV_fence question



bakery2k
02-01-2003, 11:44 AM
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.

Jan
02-01-2003, 11:57 AM
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.

bakery2k
02-01-2003, 12:38 PM
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).]

bakery2k
02-01-2003, 05:52 PM
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).]

knackered
02-02-2003, 03:20 AM
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.

Ysaneya
02-02-2003, 04:12 AM
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.

knackered
02-02-2003, 06:22 AM
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.

V-man
02-02-2003, 06:37 AM
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.

jwatte
02-02-2003, 10:21 AM
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.

bakery2k
02-02-2003, 12:29 PM
No, I am currently using the same fence on both occasions. I will try using more than one.

dorbie
02-02-2003, 06:22 PM
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).]