Vulkan Performance Issues in Hot Shots Golf Open Tee - UCUS98614

[Passingby1]

What happens?

When you take a shot the bottom power bar fills, at that moment there is severe slowdown in the Vulkan driver, slowdown which is not present in the OpenGL and D3D11 backends. Furthermore, when you are inside the green, besides the the slowdown (on Vulkan) there is also severe flickering in all three mentioned backends.

This is also present in the Android version of the emulator.

What should happen?

No slowdown on Vulkan as it is on the other two backends, plus no flickering when inside the green.

What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues.

PC:
Windows 10pro 1903
PPSSPP 1.9 (also present in 1.8 and 1.7)
Nvidia 1080ti with various drivers.

Mobile:
Android 9
Chipset | Hisilicon Kirin 710 (12 nm)
CPU | Octa-core (4x2.2 GHz Cortex-A73 & 4x1.7 GHz Cortex-A53)
GPU | Mali-G51 MP4

EDIT
The second game, Hot Shots Golf Open Tee 2 - UCUS98693, also suffers from exactly the same issues.

[unknownbrackets]

This does a lot of block transfers (RAM -> VRAM via memcpy), 272 of them per frame to be exact.

Memcpy fbo upload 08bc6b00 -> 04000000 (s: 000003c0)
Memcpy fbo upload 08bc6ec0 -> 04000400 (s: 000003c0)
Memcpy fbo upload 08bc7280 -> 04000800 (s: 000003c0)
Memcpy fbo upload 08bc7640 -> 04000c00 (s: 000003c0)
...
Memcpy fbo upload 08c06340 -> 04043c00 (s: 000003c0)

Each copy is 480 times 16 bits long, and it skips the stride. The source image is tightly packed, so it's essentially doing this (based on the log):

for (int y = 0; y < 272; ++y) {
    memcpy(dst16 + y * 512, src16 + y * 480, 480 * sizeof(uint16_t));
}

Using an allocator for drawPixelsTex_ seems to help immensely... although it complains about a double-free if I just toss it in quickly.

On the green, I do get some slight flicker when trying to shoot. In software rendering, the elements that flicker are simply not visible. We seem to be missing every other frame's uploads, based on memcpy upload logs (it's doing the thing I mentioned above.)

This happens because we somehow detect the second framebuffer as 481 pixels wide (not 480), and therefore deem it a dangerous guess at a framebuffer copy.

-[Unknown]

[hrydgard]

Got this game now (well, Everybody's Golf). Yeah I think using an allocator is the way to go here for sure. In fact I believe not using one might have lost us performance in other games too, as our VulkanTexture without an allocator will simply have to make its own allocation and that's super expensive on some drivers.

I got it working without any nasty double-frees, so I'm just gonna commit that first at least after testing a little on Android. Ideally we should detect and combine these, but it's not easy to do in this case.

[unknownbrackets]

Lending to my "maybe texture replacement slowness is mainly allocation" concern, heh.

Thanks, forgot about this one.

-[Unknown]