ci: Disable known broken Bifrost Vulkan job
Until someone does the work to eliminate faults, PanVK will be inherently flaky and should not be in CI. deqp-runner can eat a lot of flakes, and then retrying the whole job eats more flakes, but neither is a substitute for not testing known broken (and hence flaky) code and both increase runtime unacceptably. the g52-vk job earned 2 spots on the latest leaderboard for slowest jobs, I clicked on https://gitlab.freedesktop.org/mesa/mesa/-/jobs/48142375 to see a jawdropping 54 flakes reported by deqp-runner.
If people insist on keeping the job, then panfrost-g52-vk needs to be demoted to manual until after someone fixes all these bugs on the driver side. If that's not going to happen, then there's no point in it being in CI at all. It's broken code. After a buggy MR, it'll still be broken code. CI doesn't matter if we're ok with it being broken.
Please do the right thing and remove this job. Please don't make me ask a fourth time.
If people genuinely want me to submit an MR deleting Bifrost PanVK, at this point I will. There were silly political reasons why we didn't want to send that MR, but life's too short for me to factor silly politics into my decision making. I genuinely don't see the value of Vulkan support for anything older than v9, given the poor performance relative to GLES and the utter lack of Linux + Vulkan content that would actually run on Bifrost. DXVK/VKD3D are both out due to geometry shaders, which are in turn out due to layered rendering, which is added in v9 and presumably nobody will do the painful painful thing of emulating on Bifrost for the sake of running games slowly. Casual Android stuff will be happy with GLES3.2, I suspect. Zink/ANGLE aren't relevant here because the GLES driver will get better performance on Bifrost (the usual indexed/indirect nonsense). Most Vulkan content that would run will also have a GL/ES renderer, which again we expect to perform better given that Bifrost is actively hostile to adult drivers. I'm just genuinely unsure what people expect to do with Bifrost + VK. Maybe some Big Corp(TM) embedded application that's Vulkan-only because some tech lead somewhere decided that Vulkan is the future even though Bifrost is the present? If they want to fund bifrost+panvk, be my guest, I don't even mind leaving the code in tree for them to hack on, but it'll be a lot cheaper to bisect whatever regressions happen between now and that bizarro future than to actually make Bifrost + PanVK productizable.
I've heard from an ex-Intel developer that she regrets Haswell Vulkan support ... never conformant, never performant, and never can be deleted now that people use it. I suppose that's me & Bifrost.
My skepticism aside, I'm refraining from submitting that MR out of respect for the team working on Valhall PanVK, since I expect it would complicate their rebase. Regardless, we can't be running known broken code in CI (bugs = faults = flakes = unhappy developers), at least for non-robust stacks (panfrost.ko included). This needs to be policy if it isn't already. Merging this single character change deals with the hot problem without any fanfare or adverse effects. We can talk about the 10,000 line change at XDC.