   why does GetRenderTargetData() cost 0.2 second?
  I just SetRenderTarget to a POOL_DEFAULT texture,render it,and use GetRenderTargetData() to download it to a POOL_SYSTEMMEM texture.The downloading costs me 0.2 second.But in another program where I downloaded using this function, but from a texture not set as rendertarget, it cost just quite a little time.And the LockRect() of a POOL_MANAGED texture together with copy just cost 0.002 second.What should I do?
  A MANAGED texture has a copy in system memory, so it doesn''t have to involve the graphics card when you lock it.Locking a texture set as a rendertarget requires that all rendering be completed so the texture is in sync.  This has a pretty nasty performance hit.In general, reading anything back from the video card is VERY slow.  So unless you really need to, don''t do it. Stay Casual,KenDrunken Hyena;  This has to do with data direction conflicts trying to move across your AGP slot.  You're trying to download video memory to system memory (which is the opposite direction as most data is flowing), so the bus has to be flushed and the data moved, which takes more time then simply keeping a cached copy of the texture in system memory (like in POOL_MANAGED) and downloading that to another place in system memory (doesn't require a bus flush)  Hope that helps.   EDIT:beaten by one minute...Chris PergrossiMy Realm | "Good Morning, Dave"   [edited by - c t o a n on February 3, 2004 9:02:22 PM];  But in another program where I changed from the dx sample - vmr9 allocator, and downloaded the surface of current video frame fed by vmr9 from graphics card to a D3DPOOL_SYSTEMMEM surface.the time for GetRenderTargetData() is only 0.0043s in that program.the surface in the card in this 0.0043s program isX8R8G8B8D3DRTYPE_SURFACED3DUSAGE_RENDERTARGETpool_defaultD3DMULTISAMPLE_NONEsamplequality 0and the one in the 0.2s program is the same, except that it has been SetRenderTarget().but I can stretchrect it to another in-card surface which is not set as rendertarget, then download using getrendertargetdata.but this two-copy way is still slow, although the first copy takes only 0.00008s. ;  A lock operation that follows a lock operation costs very, very little, but a lock operation after GPU oriented operations costs quite a lot. StretchRect is Graphics Card-to-Graphics Card, where as the GetRenderTargetData is obviously Graphics Card-to-System. You want to minimize Graphics Card-to-System and System-To-Graphics Card. If you can replace a Card-To-System with a Card-To-Card (or even a few Card-To-Card if you have to) you really, really should do that. ;quote:Original post by Erzengeldeslichtes  A lock operation that follows a lock operation costs very, very little, but a lock operation after GPU oriented operations costs quite a lot.quote]Do you mean that in the first program where i download the surface provided by vmr, the surface in the card is already locked before i lock again and download, so it costs a little?And in the second one I''m trying to lock for the first time, so it''s slow?It''s a pitty that I can''t avoid downloading. ;  What''s wrong with using D3DPOOL_MANAGED in this case? If you find yourself in a situation where you absolutely must read back what you''ve rendered, then you should choose a pool that lets you read from system memory. Reading from video memory is always a bad idea when performance matters. The overhead of writing to a managed pool is miniscule compared to reading from video memory.;  I don't know how that program works, I just know that if you do a lock operation on, say, a surface after you've rendered something to that surface (or done something else that's pure Graphics Card), then it takes a long time while the CPU waits for the card to finish everything that it needs to do before sending the info. If you follow this lock request with another lock request on another surface or VB the lock takes no time at all because the card is already synched. How much time it takes is dependant upon how much work the graphics card has to do before being 'done'. So in all likelyhood the program you're talking about is about synched with the card when it calls the lock, either by having just locked something else or by somehow using the time until the graphics processor is done on other things before doing the lock operation (if (s)he did this, then I really want to see the code for the program to know how (s)he did that)Dave Hunt:A render target is required to be D3DPOOL_DEFAULT.   [edited by - Erzengeldeslichtes on February 5, 2004 1:47:04 PM];quote:Original post by Erzengeldeslichtes  Dave Hunt:A render target is required to be D3DPOOL_DEFAULT.   Doh! This is me shutting up.;  Got the solution:Use CreateRenderTarget instead of CreateTexture with USAGE_RENDERTARGET tag.It's much faster: 0.008s compared to 0.2sAlthough it's still much slower compared to the 0.0016s upload speed, it's acceptable for me.Thanks.   [edited by - softimage on February 6, 2004 2:16:53 AM]