[PATCH] wined3d: Don't pull _ACCESS_GPU textures to system memory in texture2d_blt().

[Henri Verbeet]

On Tue, 20 Nov 2018 at 18:57, Paul Gofman <gofmanp at 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.