优化资料
Let me see if I can explain things a bit for you...
Ideally none of your graphics calls should block the CPU, except for GraphicsDevice.Present (I'll explain this in a bit). The specifics vary a bit depending on your platform/hardware/driver arrangement, but in general calling a DrawPrimitive function doesn't mean "draw all these primitives right now", instead it means "queue up a command to draw primitives from this index buffer, and execute it later". This is what allows the CPU and GPU to be parallel: the CPU can issue a bunch of draw commands, then work on AI and game logic while the GPU is busy rendering stuff. (The situation is actually a little more complicated than this, but for now this should give you a good enough idea).
Now Present is special function, it's actually that function you were looking for but couldn't find (I think it is called automatically if you use the Game framework, IE you inherit from the Game class). What it does is it will swap your backbuffer and frontbuffer, presenting it to the screen. This function can block your app for one of two reasons:
1) VSYNC is enabled, in which case the function blocks until it can synch up with the next refresh
2) Your CPU is too far ahead of the GPU. In Direct3D9 your app can only get a set amount of frames ahead of the GPU (I think it's 2), to prevent your app from getting further and further ahead of the GPU in the event that the CPU can complete a frame much quicker than the GPU (AKA, you're GPU-bound).
Now notice the CPU doesn't have to wait for the GPU to resolve any surfaces, which will happen if the backbuffer is multi-sampled (the front-buffer is never multi-sampled). The same applies to a render-target that you're resolving to a texture: the CPU doesn't need to wait around for the GPU to do its work, because all of the data is in GPU memory. The CPU just says "do this operation later", and the GPU does it whenever it catches up to the CPU.
Now this brings me to an important point: you will stall the pipeline if you do something where the CPU and GPU need to synchronize, such as locking a vertex buffer. In these cases the GPU will stall and break parallelization, so they're to be avoided at all costs.
If you want to see a visual representation of your app's CPU and GPU usage, run it through PIX. It will actually display a graph showing you how long it takes the CPU and GPU to render a frame, so you can see whether you're CPU-bound or GPU-bound.
Ideally none of your graphics calls should block the CPU, except for GraphicsDevice.Present (I'll explain this in a bit). The specifics vary a bit depending on your platform/hardware/driver arrangement, but in general calling a DrawPrimitive function doesn't mean "draw all these primitives right now", instead it means "queue up a command to draw primitives from this index buffer, and execute it later". This is what allows the CPU and GPU to be parallel: the CPU can issue a bunch of draw commands, then work on AI and game logic while the GPU is busy rendering stuff. (The situation is actually a little more complicated than this, but for now this should give you a good enough idea).
Now Present is special function, it's actually that function you were looking for but couldn't find (I think it is called automatically if you use the Game framework, IE you inherit from the Game class). What it does is it will swap your backbuffer and frontbuffer, presenting it to the screen. This function can block your app for one of two reasons:
1) VSYNC is enabled, in which case the function blocks until it can synch up with the next refresh
2) Your CPU is too far ahead of the GPU. In Direct3D9 your app can only get a set amount of frames ahead of the GPU (I think it's 2), to prevent your app from getting further and further ahead of the GPU in the event that the CPU can complete a frame much quicker than the GPU (AKA, you're GPU-bound).
Now notice the CPU doesn't have to wait for the GPU to resolve any surfaces, which will happen if the backbuffer is multi-sampled (the front-buffer is never multi-sampled). The same applies to a render-target that you're resolving to a texture: the CPU doesn't need to wait around for the GPU to do its work, because all of the data is in GPU memory. The CPU just says "do this operation later", and the GPU does it whenever it catches up to the CPU.
Now this brings me to an important point: you will stall the pipeline if you do something where the CPU and GPU need to synchronize, such as locking a vertex buffer. In these cases the GPU will stall and break parallelization, so they're to be avoided at all costs.
If you want to see a visual representation of your app's CPU and GPU usage, run it through PIX. It will actually display a graph showing you how long it takes the CPU and GPU to render a frame, so you can see whether you're CPU-bound or GPU-bound.
浙公网安备 33010602011771号