Anyway, I am curious: why should I expect a driver to run into trouble when you pass an overly generous vertex range.
I mean, besides, "you never know" ...
Passing a vertex range that is too limited will cause trouble, if the driver actually uses this information, sure

Yeah I agree, a overly generous range seems like it should be safe, and practice tells us that it is safe (so far )

For curiosity, the only hypothetical situation I can think of is:
Let's assume we're only using D3DPT_TRIANGLELIST and DrawIndexedPrimitive.
The driver is emulating vertex processing, but it's done by a worker thread. The PrimitiveCount param is summed over a whole frame, and the sum multiplied by 3 to calculate the maximum number of verts required. To allow maximum latency, a whole-frame vertex buffer is constructed of the previously calculated max size. At the end of a frame (after this buffer's been created) the worker thread is alowed to start.
For each DrawIndexedPrimitive call, the worker thread reserves a portion of the whole-frame vertex-buffer equal to the draw-call's NumVertices value (the number of unique verts to be processed). With a generous NumVertices value, the whole-frame vertex-buffer will be depleted before all draw-calls have been processed, which will result in either: GPU-readable vertex allocation to extend a ring-buffer, complex CPU/GPU ring-buffer stalling routines, or when those fail or aren't implemented: simply aborting the draw-call in (silent) error...

Anyway, I am curious: why should I expect a driver to run into trouble when you pass an overly generous vertex range.
I mean, besides, "you never know" ...
Passing a vertex range that is too limited will cause trouble, if the driver actually uses this information, sure

Yeah I agree, a overly generous range seems like it should be safe, and practice tells us that it is safe (so far )

For curiosity, the only hypothetical situation I can think of is:
Let's assume we're only using D3DPT_TRIANGLELIST and DrawIndexedPrimitive.
The driver is emulating vertex processing, but it's done by a worker thread. The PrimitiveCount param is summed over a whole frame, and the sum multiplied by 3 to calculate the maximum number of verts required. To allow maximum latency, a whole-frame vertex buffer is constructed of the previously calculated max size. At the end of a frame (after this buffer's been created) the worker thread is alowed to start.
For each DrawIndexedPrimitive call, the worker thread reserves a portion of the whole-frame vertex-buffer equal to the draw-call's NumVertices value (the number of unique verts to be processed). With a generous NumVertices value, the whole-frame vertex-buffer will be depleted before all draw-calls have been processed, which will result in either: GPU-readable vertex allocation to extend a ring-buffer, complex CPU/GPU ring-buffer stalling routines, or simply aborting the draw-call in (silent) error...

Anyway, I am curious: why should I expect a driver to run into trouble when you pass an overly generous vertex range.
I mean, besides, "you never know" ...
Passing a vertex range that is too limited will cause trouble, if the driver actually uses this information, sure

Yeah I agree, a overly generous range seems like it should be safe, and practice tells us that it is safe (so far )

For curiosity, the only hypothetical situation I can think of is:
Let's assume we're only using D3DPT_TRIANGLELIST and DrawIndexedPrimitive.
The driver is emulating vertex processing, but it's done by a worker thread. The PrimitiveCount param is summed over a whole frame, and the sum multiplied by 3 to calculate the maximum number of verts required. To allow maximum latency, a whole-frame vertex buffer is constructed of the previously calculated max size. At the end of a frame (after this buffer's been created) the worker thread is alowed to start.
For each DrawIndexedPrimitive call, the worker thread reserves a portion of the whole-frame vertex-buffer equal to the draw-call's NumVertices value (the number of unique verts to be processed). With a generous NumVertices value, the whole-frame vertex-buffer will be depleted before all draw-calls have been processed, which will result in either complex CPU/GPU ring-buffer stalling routines, or simply aborting the draw-call in (silent) error...

Anyway, I am curious: why should I expect a driver to run into trouble when you pass an overly generous vertex range.
I mean, besides, "you never know" ...
Passing a vertex range that is too limited will cause trouble, if the driver actually uses this information, sure

Yeah I agree, a overly generous range seems like it should be safe, and practice tells us that it is safe.

For curiosity, the only hypothetical situation I can think of is:
Let's assume we're only using D3DPT_TRIANGLELIST and DrawIndexedPrimitive.
The driver is emulating vertex processing, but it's done by a worker thread. The PrimitiveCount param is summed over a whole frame, and the sum divided by 3 to calculate the maximum number of verts required. To allow maximum latency, a whole-frame vertex buffer is constructed of the previously calculated max size. At the end of a frame (after this buffer's been created) the worker thread is alowed to start.
For each DrawIndexedPrimitive call, the worker thread reserves a portion of the whole-frame vertex-buffer equal to the draw-call's NumVertices value (the number of unique verts to be processed). With a generous NumVertices value, the whole-frame vertex-buffer will be depleted before all draw-calls have been processed, which will result in either complex CPU/GPU ring-buffer stalling routines, or simply aborting the draw-call in (silent) error...