db8ab52447
Copy-paste a pile of winsys code from panfrost and find-and-replace the name to asahi. This should contain all the glue code needed for asahi+kmsro. The kernel driver is under way (led by Asahi Lina, not me), but it's not wred up here. My goal was rather to run shader-db, which expects a render node, which means drm-shim, which means DRM loader support. With this patch and a trivial drm-shim, shader-db runs. In general I am reticent to touch UABI related code when the UABI hasn't been finalized upstream, or started design at all, hence the RFC. Realistically this patch assumes the following about the future UABI: 0. It will be a DRM driver. This is nonnegotiable. 1. The render node will be named "asahi". The other reasonable name would be "apple", which I'm using for the display controller (not yet upstream, but getting close). 2. Display and rendering will be split in the kernel, requiring kmsro in userspace, as agreed in past discussions. The 3D accelerator (AGX) and the display controller (DCP) are completely orthogonal blocks with separate lineages. True, Apple A14 (~= M1) has AGX and DCP together, and it seems like all the chips that will get upstream support will have this for the forseeable future. Nevertheless, it's a historical coincidence. Apple A12 had an AGX block with a pre-DCP Apple display controller, which would use a completely different display driver. Older SoCs had a PowerVR block with an Apple shader core, with a pre-DCP Apple display controller. Even older SoCs had a pure PowerVR block (+ Apple display). The AGX and DCP kernel drivers are not expected to share any nontrivial code. We don't gain anything by bundling them together. Likewise, the many codec blocks are completely orthogonal. This is all standard practice for Arm SoCs. It is true that AGX has never been used with a non-Apple display controller; it is highly unlikely this would change (either by AGX licensing out or something like Mali-DP getting licensed in). But an extra kmsro user doesn't actually add more complexity to Mesa, so shrug. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Eric Engestrom <eric@igalia.com> [meson, ack on gallium] Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15940>
`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.