mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-05-05 20:28:04 +02:00
read-only mirror of https://gitlab.freedesktop.org/mesa/mesa
c0d6539827
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> Acked-by: Jason Ekstrand <jason.ekstrand@collabora.com> Acked-by: Boris Brezillon <boris.brezillon@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16915> |
||
|---|---|---|
| .gitlab/issue_templates | ||
| .gitlab-ci | ||
| android | ||
| bin | ||
| build-support | ||
| docs | ||
| include | ||
| src | ||
| subprojects | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .mailmap | ||
| .travis.yml | ||
| CODEOWNERS | ||
| meson.build | ||
| meson_options.txt | ||
| README.rst | ||
| VERSION | ||
`Mesa <https://mesa3d.org>`_ - The 3D Graphics Library ====================================================== Source ------ This repository lives at https://gitlab.freedesktop.org/mesa/mesa. Other repositories are likely forks, and code found there is not supported. Build & install --------------- You can find more information in our documentation (`docs/install.rst <https://mesa3d.org/install.html>`_), but the recommended way is to use Meson (`docs/meson.rst <https://mesa3d.org/meson.html>`_): .. code-block:: sh $ mkdir build $ cd build $ meson .. $ sudo ninja install Support ------- Many Mesa devs hang on IRC; if you're not sure which channel is appropriate, you should ask your question on `OFTC's #dri-devel <irc://irc.oftc.net/dri-devel>`_, someone will redirect you if necessary. Remember that not everyone is in the same timezone as you, so it might take a while before someone qualified sees your question. To figure out who you're talking to, or which nick to ping for your question, check out `Who's Who on IRC <https://dri.freedesktop.org/wiki/WhosWho/>`_. The next best option is to ask your question in an email to the mailing lists: `mesa-dev\@lists.freedesktop.org <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>`_ Bug reports ----------- If you think something isn't working properly, please file a bug report (`docs/bugs.rst <https://mesa3d.org/bugs.html>`_). Contributing ------------ Contributions are welcome, and step-by-step instructions can be found in our documentation (`docs/submittingpatches.rst <https://mesa3d.org/submittingpatches.html>`_). Note that Mesa uses gitlab for patches submission, review and discussions.