Compositing a bitmap overlay (cursor or subtitle) onto the Vulkan swapchain surface on GFX1200 triggers a GPU hang for Thunderbolt 5(!!) eGPUs

[Aqua1ung]

In order to reproduce this issue you will need a Linux system with a Thunderbolt 5(!) Navi 44 eGPU (9060, 9070 etc.). Here are the steps to reproduce:

1. run mpv --vulkan-device=help, and harvest the UUIDs of both your non-Navi 44 iGPU (say <non_navi_44_gpu_uuid>), and your Navi 44 Thunderbolt eGPU (say <navi_44_gpu_uuid>)
2. run mpv --no-config --gpu-api=vulkan --vulkan-device=<non_navi_44_gpu_uuid> <some_video_file_on_your_hard_drive>; hopefully this will run just fine, mpv should play the file with no crashes
3. run mpv --no-config --gpu-api=vulkan --vulkan-device=<navi_44_gpu_uuid> <some_video_file_on_your_hard_drive> and then move the mouse cursor onto the mpv window: this should immediately crash mpv, and very likely your entire graphics module, such that a hard reboot may be required

Please reply if you've managed to replicate this issue. Note, again, that this only happens with AMD Thunderbolt 5(!) eGPUs with Navi 44 architecture (9060, 9070 etc.): in non-Thunderbolt 5 scenarios this does not happen! Linux kernel doesn't really matter as long as it's newer than 6.18, say. This happens to me in both GNOME and KDE-Plasma. Also note that this crash does not(!) happen if I swap the 9060 XT for my Arc B580 eGPU.

[Aqua1ung]

Major discovery! Upon input from @nu_ninja in the eGPU forums, I swapped my Thunderbolt 5 enclosure for an older AG02 I had lying around, and I noticed that this crash does NOT happen anymore! I am thus comfortable asserting that the aberrant behavior only happens with Thunderbolt 5 enclosures on Navi 44-based AMD eGPUs in Vulkan rendering.

The issue remains, and it should be fixed, as Thunderbolt 5 enclosures have become very common.