diff options
| author | Alyssa Rosenzweig <alyssa@rosenzweig.io> | 2022-06-09 08:50:44 -0400 |
|---|---|---|
| committer | Alyssa Rosenzweig <alyssa@collabora.com> | 2022-10-29 12:04:41 -0400 |
| commit | db8ab5244770a1ccd4ba06ca7ef00c5175eb1f9d (patch) | |
| tree | 68721be8311de10d88917bddc48d49f3a93f0cdf /meson.build | |
| parent | 27c8cddec1ab456fc69ba22d686071207a07204a (diff) | |
| download | mesa-db8ab5244770a1ccd4ba06ca7ef00c5175eb1f9d.tar.gz mesa-db8ab5244770a1ccd4ba06ca7ef00c5175eb1f9d.tar.bz2 mesa-db8ab5244770a1ccd4ba06ca7ef00c5175eb1f9d.zip | |
gallium: Stub support for Asahi + DRM
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>
Diffstat (limited to 'meson.build')
| -rw-r--r-- | meson.build | 6 |
1 files changed, 5 insertions, 1 deletions
diff --git a/meson.build b/meson.build index f70188fc7b3..7f86a0ec985 100644 --- a/meson.build +++ b/meson.build @@ -234,7 +234,11 @@ foreach gallium_driver : gallium_drivers endforeach with_gallium = gallium_drivers.length() != 0 -with_gallium_kmsro = with_gallium_v3d or with_gallium_vc4 or with_gallium_etnaviv or with_gallium_panfrost or with_gallium_lima or with_gallium_freedreno +with_gallium_kmsro = with_gallium_v3d or with_gallium_vc4 or with_gallium_etnaviv or with_gallium_panfrost or with_gallium_lima or with_gallium_freedreno or with_gallium_asahi + +if not system_has_kms_drm + with_gallium_kmsro = false +endif with_dri = false if with_gallium and system_has_kms_drm |