Mesa (main): panvk: Drop support for Midgard

Wed Jun 8 18:59:23 UTC 2022

Module: Mesa
Branch: main
Commit: c0d65398279db02f68b5acc23c3afbf1c34a5204
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=c0d65398279db02f68b5acc23c3afbf1c34a5204

Author: Alyssa Rosenzweig <alyssa at collabora.com>
Date:   Tue Jun  7 12:02:58 2022 -0400

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 at collabora.com>
Acked-by: Jason Ekstrand <jason.ekstrand at collabora.com>
Acked-by: Boris Brezillon <boris.brezillon at collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16915>

---

 src/panfrost/vulkan/meson.build               |   4 +-
 src/panfrost/vulkan/panvk_device.c            |   4 -
 src/panfrost/vulkan/panvk_private.h           |  13 +--
 src/panfrost/vulkan/panvk_vX_cmd_buffer.c     | 153 ++------------------------
 src/panfrost/vulkan/panvk_vX_cmd_buffer.h     |   7 --
 src/panfrost/vulkan/panvk_vX_cs.c             | 107 +-----------------
 src/panfrost/vulkan/panvk_vX_descriptor_set.c |  20 +---
 src/panfrost/vulkan/panvk_vX_device.c         |   9 --
 src/panfrost/vulkan/panvk_vX_image.c          |  30 +----
 src/panfrost/vulkan/panvk_vX_meta_blit.c      |   5 -
 src/panfrost/vulkan/panvk_vX_meta_clear.c     |  30 +----
 src/panfrost/vulkan/panvk_vX_meta_copy.c      |  77 ++-----------
 src/panfrost/vulkan/panvk_vX_pipeline.c       |  14 +--
 src/panfrost/vulkan/panvk_vX_shader.c         | 109 ------------------
 src/panfrost/vulkan/panvk_varyings.h          |  37 +------
 15 files changed, 43 insertions(+), 576 deletions(-)

Diff:   http://cgit.freedesktop.org/mesa/mesa/diff/?id=c0d65398279db02f68b5acc23c3afbf1c34a5204