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.
Bottom line is, 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.
This turns the job into a nightly as David suggested to get it out of the
premerge path until someone is committed to supporting it and does the work to
make it happen.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9721
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24943>
projects / platform / upstream / mesa.git / commitdiff