On Tue, 20 Nov 2018 at 18:57, Paul Gofman gofmanp@gmail.com wrote:
On 11/20/18 18:08, Henri Verbeet wrote:
The case I was thinking of above is when the map binding location is current because the application is actually mapping the texture, rather than because it ends up being the same as the default location. We can't really distinguish those two cases right now.
I thought there is download_count texture variable meant for this purpose. It currently makes wined3d_texture_evict_sysmem() do nothing if the application effectively requested to download the texture to sysmem over 50 times. This counter could help to sort out default location case or to ignore just a few application requested mappings during some initialization. Still I suppose more accurate statistics might be ideally required for texture blit. E. g., what if application mapped and downloaded the texture 51 times over the run time for some specific purposes, but other 10000 times did StretchBlt without mapping anything? Maybe just count of total texture blits in addition to download count could help?
Very generically, yes, more accurate statistics would allow us to make better decisions. There's a bigger picture as well though. Transferring resources between the GPU and CPU is really only supposed to be a consideration for D3DPOOL_MANAGED resources. At the same time, for d3d9, the general advice is that if you're doing anything remotely performance sensitive, it's best to avoid managed resources. D3DPOOL_SYSTEMMEM resources should stay on the CPU, D3DPOOL_DEFAULT resources should stay on the GPU. There are a few exceptions to that, mainly dynamic resources, lockable render targets, and offscreen plain surfaces. For lockable render targets, mapping them is expected to be slow; I'm not sure we tested it, but the documentation seems to suggest they're downloaded from the GPU each time they're locked. Dynamic resources are effectively read-only for the GPU. I.e., D3DUSAGE_DYNAMIC is mutually exclusive with D3DUSAGE_RENDERTARGET or D3DUSAGE_DEPTHSTENCIL. (Note also that StrectRect() doesn't allow blitting to regular textures.) While it may be possible for the CPU to read from dynamic resources, there should never be a reason to, and doing so is not expected to be fast. And then there's offscreen plain surfaces. Those can't really be used as texture or rendertarget either, but they can be used as StretchRect() destination when blitting from another offscreen plain surface.