System memory buffers
Author
I've been looking around, but can't find much related information. Any insight into any of the following questions would be helpful.
1. When is it a good idea to use system memory for vertex or index buffers to render meshes?
2. What performance advantages and/or disadvantages do they have, compared to static video buffers?
3. How do system memory buffers compare to dynamic buffers?
4. How exactly do system buffers work? Do they get transferred to video memory at some point? I'm guessing yes. If so, when do they get transferred, and how is that transfer better or worse than locking a static or dynamic buffer?
5. It seems possible to create dynamic buffers in system memory. What does that mean, and does it have any purpose?
Help is appreciated!
I think the only way you can render from a system memory vb/ib is to use software vertex processing. Basically, the only reason you create a system memory vb/ib is for ProcessVertices or software vertex processing. ProcessVertices is not designed to be fast. Software vertex processing is never as fast as hardware vertex processing. Basically you should use the managed pool for vb/ibs unless you have a specific reason not to.
Author
That doesn't seem to be true. I've created system memory vertex buffers and rendered them with hardware processing (D3DDEVTYPE_HAL, D3DCREATE_HARDWARE_VERTEXPROCESSING | D3DCREATE_PUREDEVICE). I've been using the code for a while now for my particle engine, and it worked on my Radeon 8500, as well as my current GeForce 7300 card.
Quote:Original post by Kest
That doesn't seem to be true. I've created system memory vertex buffers and rendered them with hardware processing (D3DDEVTYPE_HAL, D3DCREATE_HARDWARE_VERTEXPROCESSING | D3DCREATE_PUREDEVICE). I've been using the code for a while now for my particle engine, and it worked on my Radeon 8500, as well as my current GeForce 7300 card.
That sounds to me like the driver "fixing" your mistake by moving the system memory vb/ib to device memory.
Did you try it with REF? Did you check all HRESULTs? Did the debug runtime issue no warnings or other spew?
Author
Quote:Original post by legalize
That sounds to me like the driver "fixing" your mistake by moving the system memory vb/ib to device memory.
It's possible, but how and when could it do that? If it did so on the buffer creation, it would make it impossible to create a system buffer.
Quote:Did you try it with REF?
I'm not sure what you mean.
Quote:Did you check all HRESULTs?
Yes, there's no problems.
Quote:Did the debug runtime issue no warnings or other spew?
Nope. With full debug output, I get only a few redundant state change warnings when it starts up.
D3DDEVTYPE_REF is the reference rasterizer; it checks more things that HAL doesn't check.
I suspect that the driver is moving/creating your buffer in AGP accessible memory. This memory is accessible by the CPU and by the GPU but is still not as fast as device memory. The driver may move your buffer to AGP memory as soon as you attempt to render with it.
I suspect that the driver is moving/creating your buffer in AGP accessible memory. This memory is accessible by the CPU and by the GPU but is still not as fast as device memory. The driver may move your buffer to AGP memory as soon as you attempt to render with it.
Author
Quote:Original post by legalize
D3DDEVTYPE_REF is the reference rasterizer; it checks more things that HAL doesn't check.
Wow, it's painfully slow. I was able to make a pot of coffee by the time the player character armed his weapon. I still only get a few state change warnings about SetSamplerState and SetTextureStageState. Nothing about creating or rendering the buffers.
Quote:I suspect that the driver is moving/creating your buffer in AGP accessible memory. This memory is accessible by the CPU and by the GPU but is still not as fast as device memory. The driver may move your buffer to AGP memory as soon as you attempt to render with it.
Is there any way to verify it?
Author
There's at least some type of difference between rendering from a system buffer and rendering from a dynamic buffer. Rendering from the dynamic buffer is slightly faster (test was 10.5 milliseconds per frame compared to 10.3 milliseconds per frame, rendering 2000 particles).
There was also a difference between the performance gains of accessing memory many small times, versus a large memory copy operation. The system buffer actually lost performance on the memory copy version, which would make sense if the buffer was really in system memory.
There was also a difference between the performance gains of accessing memory many small times, versus a large memory copy operation. The system buffer actually lost performance on the memory copy version, which would make sense if the buffer was really in system memory.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
