panvk: Drop support for Midgard
We've discussed this at length and have agreed that Midgard + Vulkan is DOA, but have let the code linger. Now it's getting in the way of forward progress for PanVK... That means it's time to drop the code paths and commit t to not supporting it.
Midgard is only barely Vulkan 1.0 capable, Arm's driver was mainly experimental. Today, there are no known workloads today for hardware of that class, given the relatively weak CPU and GPU, Linux, and arm64. Even with a perfect Vulkan driver, FEX + DXVK on RK3399 won't be performant.
There is a risk here: in the future, 2D workloads (like desktop compositors) might hard depend on Vulkan. It seems this is bound to happen but about a decade out. I worry about contributing to hardware obsolescence due to missing Vulkan drivers, however such a change would obsolete far more than Midgard v5... There's plenty of GL2 hardware that's still alive and well, for one. It doesn't look like Utgard will be going anywhere, even then.
For the record: I think depending on Vulkan for 2D workloads is a bad idea. It's unfortunately on brand for some compositors.
Getting conformant Vulkan 1.0 on Midgard would be a massive amount of work on top of conformant Bifrost/Valhall PanVK, and the performance would make it useless for interesting 3D workloads -- especially by 2025 standards.
If there's a retrocomputing urge in the future to build a Midgard + Vulkan driver, that could happen later. But it would be a lot more work than reverting this commit. The compiler would need significant work to be appropriate for anything newer than OpenGL ES 3.0, even dEQP-GLES31 tortures it pretty bad. Support for non-32bit types is lacklustre. Piles of basic shader features in Vulkan 1.0 are missing or broken in the Midgard compiler. Even if you got everything working, basic extensions like subgroup ops are architecturally impossible to implement.
On the core driver side, we would need support for indirect draws -- on Vulkan, stalling and doing it on the CPU is a nonoption. In fact, the indirect draw code is needed for plain indexed draws in Vulkan, meaning Zink + PanVK can be expected to have terrible performance on anything older than Valhall. (As far as workloads to justify building a Vulkan driver, Zink/ANGLE are the worst examples. The existing GL driver works well and is not much work to maintain. If it were, sticking it in Amber branch would still be less work than trying to build a competent Vulkan driver for that hardware.)
Where does PanVK fit in? Android, for one. High end Valhall devices might run FEX + DXVK acceptably. For whatever it's worth, Valhall is the first Mali hardware that can support Vulkan properly, even Bifrost Vulkan is a slow mess that you wouldn't want to use for anything if you had another option.
In theory Arm ships Vulkan drivers for this class of hardware. In practice, Arm's drivers have long sucked on Linux, assuming you could get your hands on a build. It didn't take much for Panfrost to win the Linux/Mali market.
The highest end Midgard getting wide use with Panfrost is the RK3399 with the Mali-T860, as in the Pinebook Pro. Even by today's standards, RK3399 is showing its limits. It seems unlikely that its users in 10 years from now will also be using Vulkan-required 2030 desktop environment eye candy. Graphically, the nicest experience on RK3399 is sway or weston, with GLES2 renderers. Realistically, sway won't go Vulkan-only for a long-time.
Making ourselves crazy trying to support Midgard poorly in PanVK seems like letting perfect (Vulkan support) be the enemy of good (Vulkan support). In that light, future developers making core 2D software Vulkan-only (forcing software rasterization instead of using the hardware OpenGL) are doing a lot more e-wasting than us simply not providing Midgard Vulkan drivers because we don't have the resources to do so, and keeping the broken code in-tree will just get in the way of forward progress for shipping PanVK at all.
There are good reasons, after all, that turnip starts with a6xx.
(If proper Vulkan support only began with Valhall, will we support Bifrost long term? Unclear. There are some good arguments on both sides here.)
Signed-off-by: Alyssa Rosenzweig alyssa@collabora.com