On macOS, we don't have DRM or any real WSI, so Asahi has to pretend to be a
software rasterizer to load. On Linux, we do have DRM and proper WSI, so we
don't want that. For faking Asahi devices on Linux, we should use drm-shim
instead. This makes sure we don't accidentally load Asahi on non-M1 Linux.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15940>
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>
After a great deal of spec lawyering in #dri-devel, I am convinced this
is probably okay for the same reasons as v3d and freedreno. The batch
reordering and flush deferral optimizations are seemingly still ok. The
requirement that writes are visible "immediately" in the spec actually
means "in the subsequent [OpenGL] command" for the CPU -> GPU direction,
which avoids pitfalls where PERSISTENT|COHERENT could be used as a
"doorbell". With that understanding, the extension doesn't actually
require anything special for tilers other than coherency at GPU submit
boundaries, which is true for any driver that does not use a sync ioctl.
After this commit, the remaining drivers that don't set the CAP are
d3d12, softpipe, etnaviv, and i915g. I am unsure about d3d12, but the
latter 3 could probbaly enable it trivially for the same reason.
v2: Don't use copy_resource path for persistent mappings (Emma). Emma
explained on GitLab:
I don't think you should have the copy_resource path taken for
PIPE_RESOURCE_FLAG_MAP_PERSISTENT BOs. Imagine the user has a
general-purpose BO they're streaming stuff into and doing draws that
they keep persistently mapped until wrapping. They call some GL
function on the same buffer that does a fallback write map on the BO
(u_default_buffer_subdata, util_resource_copy_region, whatever) -- the
buffer is in use, copy triggers, allocates a new BO. Whoops, the user's
pointer for streaming writes is now freed.
Closes: #7570
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19351>
The LLVM backend does this when lowering ordered_xfb_counter_add_amd. I
guess there is some missing dependency checking or something.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19345>
Both code paths already do this handling, so no need to this again in
iris_bo_wait().
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19359>
Some drivers have minimum buffer size or alignment requirements. When a
buffer is created using pb_cache_manager_create_buffer, the cache is
first checked for a compatible buffer to return instead. If the
requested buffer size is less than
(minimum buffer size) / (mgr->size_factor), no buffer in the cache
is _ever_ applicable.
The alignment is used to determine the true allocation size when
evaluating against cached buffers.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19082>
All the generations want maxx/maxy to be inclusive rather than
exclusive, so shift the subtract-one nonsense to bind time rather
than emit time.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19236>
We can just bake this into the program state, rather than making it a
shader variant. Turnip had already switched to this approach so it will
let us drop ir3 lowering for this.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19236>
tgsi_to_nir doesn't support these, and we long ago removed support for
consuming TGSI without tgsi_to_nir. So don't claim to support this.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19236>
In RadeonSI, they are packed but not in RADV, so don't rely on driver
locations.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19343>
NGG streamout lowering creates some idiv instructions that need to be
lowered.
No fossil-db results because it's currently broken.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19364>
I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS needs to set otherwise
i915 will ignore the extensions.
Fixes: 57a1d13279 ("iris: enable protected contexts")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19373>
This is the legacy way of doing synchronisation and is no longer necessary now
that the DMA_BUF_IOCTL_EXPORT_SYNC_FILE / DMA_BUF_IOCTL_IMPORT_SYNC_FILE ioctls
exist, which the wsi code is already making use of.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19293>
Pass float64.glsl into nir_lower_doubles() resolves the problem on
ICL/TGL when the shader uses float64, but the device doesn't support
that type.
Signed-off-by: Mykhailo Skorokhodov <mykhailo.skorokhodov@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18854>