Unlocking NV12 textures is incredibly slow on Intel GPUs

dxvkclosed intel anvd3d9

doitsujin/dxvk#3340 · opened 2023-04-07 by etang-cw · updated 2023-04-11 · 4 comments · github

Eetang-cw 2023-04-07 github

To reproduce, run the following program (includes both source and an x64 windows binary): NV12Bench.zip

The test program repeatedly locks and unlocks a 1080p NV12 D3D9 texture, to imitate wine's mfplat dll (which does the same thing when decoding video). On Windows and Wine with wined3d, this takes 100us per lock/unlock. On DXVK on most GPUs, this takes around 1ms, which is a bit slower but not going to lag anyone's video playback. On Intel GPUs, this seems to take much longer, taking around 40ms on my i5-1135G7. Most of the time seems to be here (in the memcpy), so I'm guessing the driver mapped one of the buffers as uncached or something. Not sure if that's considered a bug in DXVK or the Intel driver, so I'm reporting it here for now.
https://github.com/doitsujin/dxvk/blob/d9a6b40ae399f190fc41c7aa2806d56a64bec5f9/src/d3d9/d3d9_device.cpp#L4670-L4672

Note: This seems to be worst on Mesa. On Windows + Intel, the test runs at around 10-15ms per run.

Software information

The attached zip reproduces the issue, but this also affects running games like Persona 5 Strikers in proton, which plays back cutscenes at <1fps because of it (the game seems to drop frames if they don't arrive in time).

System information

GPU: Intel Core i5-1135G7 iGPU (Intel Xe), also tested Intel Core i7-7700 iGPU (HD 630)
Driver: Mesa 22.3.7
Wine version: Tested on 8.4-staging and a local build based off 67c67703311f75540896f29ec576fb8fac427121
DXVK version: 2.1 (Binary downloaded from GitHub release)

Log files

NV12Bench.log
perf flame graph

KK0bin maintainer 2023-04-07 github

    VkMemoryPropertyFlags memType = VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
                                  | VK_MEMORY_PROPERTY_HOST_COHERENT_BIT
                                  | VK_MEMORY_PROPERTY_HOST_CACHED_BIT;

    m_buffer = m_device->GetDXVKDevice()->createBuffer(info, memType);

This should never be in uncached memory unless the driver doesn't support CACHED | COHERENT.

Eetang-cw 2023-04-07 github

My iGPU reports a single memory type that's device local, host visible, host coherent, and host cached

I'll mess around with it in vulkan a bit and see if I can reproduce the slow reads on it.

Eetang-cw 2023-04-10 github

Can confirm, Intel's HOST_CACHED memory looks very not-cached

Test program: vkmemtest.zip
Output:

malloc memset: 104us
malloc memcpy: 191us
malloc load:   1063us
Intel(R) Xe Graphics (TGL GT2) memory 0 flags: DEVICE_LOCAL, HOST_VISIBLE, HOST_COHERENT, HOST_CACHED
Intel(R) Xe Graphics (TGL GT2) memory 0 memset: 84us
Intel(R) Xe Graphics (TGL GT2) memory 0 memcpy: 15853us
Intel(R) Xe Graphics (TGL GT2) memory 0 load:   505893us
llvmpipe (LLVM 15.0.7, 256 bits) memory 0 flags: DEVICE_LOCAL, HOST_VISIBLE, HOST_COHERENT, HOST_CACHED
llvmpipe (LLVM 15.0.7, 256 bits) memory 0 memset: 109us
llvmpipe (LLVM 15.0.7, 256 bits) memory 0 memcpy: 219us
llvmpipe (LLVM 15.0.7, 256 bits) memory 0 load:   1110us

Made a mesa issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8809

KK0bin maintainer 2023-04-11 github

I'll close this.

It's not our bug and apparently already fixed in Mesa too.

Nothing extracted yet.