I was wondering if there was a DirectX equivalent of the GL_NV_fence extension, and if, generally speaking, GPU fences were available on ATI, or had become mainstream and "standard". or if they had died completely and were left out in the archives of GPU evolution? I couldn't find much information on google, apart from the GL_NV_fence specification (perhaps it is now named differently from "*fence*" ?) basically, I have a vertex buffer pool. that's filled each frame with lots of small batches that might change randomly from one frame to another, and are like 12-20 vertices each, so I don't have much choice but dynamically rebuild the whole thing each frame. and GPU fences would come in handy to know when one of the vertex buffers has been rendered and may be safely filled again without triggering a flush of the command buffer, and stall the CPU. the very basic idea would be to set a fence after each render using a vertex buffer in the pool. when the pool is asked to provide another vertex buffer, it would look through its elements for "available" buffers, checking the fence status. excluding fences, is there any other form of standard GPU/CPU synchronization tools that could be used to achieve this goal?

I don't quite understand your design. Your 'pool' is a set of VBs? Or a single VB containing a set of independent geometry?

If it's a set of VBs, and you want to use fences to make sure you always return a free one for locking, why don't you just rotate through them? You can be reasonably sure that the very first one you returned the last time will be the first one to be free next time, then the second, and so on.

Anyhow, to answer your first question, yes all GPUs have synchronization methods, though not necessarily fences in the command stream, and not always exposed to the client API. If the driver is sensible and you return a VB that is still in use your attempted lock should only block until the buffer is free, not until the entire command buffer has been flushed, so you get the behavior you want without worrying about the fencing yourself.

I'm sure most drivers do exactly what you proposed: submit a fence after every draw call and associate it with all the buffers and textures that the draw call referenced.

Direct3D allows you to create a buffer as DYNAMIC, and then to lock them with the DISCARD flag. If such a buffer with such a lock is still in use, a new buffer is returned so that the CPU does not stall.

outRider> well, yes, it's a list of VBs, but the thing is the actual VB size used may vary widely from one VB to another (one might use 50000 vertices, another one only 500, and so-on, if there was a rotation process going on, the VBs would either have to be dynamically resized/recreated, and would all tend to having the size of the largest batch (if there is one batch with 50000 vertices, and 10 batches with less than a thousand, and 8 VBs in the pool, all 8 will eventually be resized to 50000 vertices). the thing was to avoid eating-up too much resources for these, and choosing the smallest available VB where the desired data would fit. this means, looking through the list, and selecting the VB according to its size, and its current 'in use' state. selecting the VB according to its size doesn't really allow a smooth rotation through the list.

of course, It could also just be brute-forced, and have as many VBs as necessary allocated for a given frame, thus eliminating the need for the whole selection process.

Quote:Anyhow, to answer your first question, yes all GPUs have synchronization methods, though not necessarily fences in the command stream, and not always exposed to the client API.

ok, so it's as if they had none. if they are not exposed, we can't use them. damned :/

crowley9> hm interesting.. I'll look into that, thanks.

Since you mention that you have very unpredictable vertex array lengths, I should add that there is also a NOOVERWRITE lock flag, that allows you to lock a VB while it is still in use, allowing you to append vertex data, without causing a sync and without creating new VBs. When it is full, you can do a DISCARD lock and start again.