   ColorFill alternatives that permit D3DPOOL_MANAGED?
  I've got a surface that, for various reasons, has to be allocated as D3DPOOL_MANAGED. The precise situation is complicated and to be honest I haven't fully figured it out myself - but let's just assume that there is no choice to change that.Now, I also need the ability to do rectangle fills of a given color on this surface. Normally I'd go for IDirect3DDevice9::ColorFill, but that won't take the surface unless it's been allocated as D3DPOOL_DEFAULT, which I can't do. Is there some alternative call I can make to accomplish the same basic result?For a bit of background, the current solution is to manually fill the bits using a couple of nested loops. This, however, is very gross and is a bit of a performance bottleneck; I'm hoping that there's a faster way to do this. If I still have to manually set the bits myself, does anyone have some reasonably fast code for the job?   
  I'm doubting this is even possible. Since the managed resource is located both in system memory and in one of the GPU controlled memories, you need to modify both in order to get both to change. This is normally done by locking the system memory from the CPU and then modifying the data, and then letting the Managed resource stream itself up to update the GPU version of the resource.I'm not aware of any ability to pull the GPU version and update the system memory one. This is mostly why Managed Resources can't be render targets. I suppose even if you could, the bandwidth going from the GPU to the CPU would literally kill performance.Add to this that any effective way of modifying the texture can really only affect the GPU resource, and you're pretty much stuck :).I would try locking just a part of the resource. Theres a mild chance the driver might not need to update the whole surface if you only lock part of it. This would possibly work a bit faster.Other than that, I'd seriously consider letting go of the Managed Pool for the resource. If you need to be able to access the data quickly from both the CPU and the GPU, try just duplicating the resource. You could pretty much write your own version of a managed resource. When you do a color fill, you can use on of the GPU commands to update the resource in the Default pool, and then lock and modify the system memory resource. The latter would be pretty quick, because it wouldn't need to propogate changes to the GPU.If theres some other reason you've got to use the Managed Pool, look for alternatives, IMO :).Hope this helps.   ;  Right... I was afraid of that.The code already locks the minimal portion of the surface via LockRect(), and updates the bits returned from that call manually. The main ugliness is in the handling of multiple possible bit depths, which I would assume D3D can handle better internally.Oh well... there are other areas of performance to worry about. This was just a piece of particularly low-hanging fruit I was hoping to trim up a bit. In any case I've double-checked the profile results and the real speed problem is from the locking and streaming back to the GPU, and not the actual fill loop itself.Thanks anyways [smile]   ;Quote:Original post by ApochPiQThe main ugliness is in the handling of multiple possible bit depths, which I would assume D3D can handle better internally.Have you considered using D3DXFillTexture() or D3DXFillTextureTX()? I'm not sure they'll handle sub-rects of the textures (but you could emulate that via bounds checking) but it makes for MUCH cleaner code - no messing with loops, strides or bit formats [grin]Quote:Original post by ApochPiQthe real speed problem is from the locking and streaming back to the GPUDoesn't surprise me unfortunately - seems to be an unavoidable characteristic of the AGP/PCI-E buses kicking around...hthJack   ;  At the moment I'm working against a render target surface which is not a texture; I have to be honest and say that I haven't done enough personally with D3D to know what the implications of that are (i.e. what would be involved in promoting the surface to a full texture).Even with that aside, though, D3DXFillTexture() probably won't cut it; the problem is mainly performance (cleanliness is a secondary concern for things like blit logic, frankly [wink]) and there's no way in heck that a function call and four conditionals (bounds checking) is going to outperform two nested loops with a simple pointer increment/memory write.Now, D3DXFillTextureTX() would be perfect - if I only needed to manipulate the surface in GPU memory. In that case the shader ability, while hackish, could be exploited to at least offload some work time. Unfortunately, because the surface is then read back into system memory for other purposes, I'm afraid that the locking and readback would slaughter any benefits from offloading the actual fill.Ta anyways [smile]   