a861501632
While all Panfrost-supported Mali GPUs support all the compressed texture formats architecturally, the system integrator decides which formats will actually be wired up in the production system-on-chip. In the past there may have been legal considerations, I'm neither a lawyer nor a system integrator so couldn't say. It's useful for users to know which compressed texture formats are supported by their hardware, to understand its performance characteristics (and perhaps to buy systems that support their needs, especially if they need BCn formats which are omitted in many Mali implementations). To help with that, this commit adds a small standalone tool that prints which formats are supported. It is tested so far on Mali-T860 and Mali-G57. Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com> Tested-by: Chris Healy <healych@amazon.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20086>
178 lines
8.3 KiB
ReStructuredText
178 lines
8.3 KiB
ReStructuredText
Panfrost
|
|
========
|
|
|
|
The Panfrost driver stack includes an OpenGL ES implementation for Arm Mali
|
|
GPUs based on the Midgard and Bifrost microarchitectures. It is **conformant**
|
|
on Mali-G52 and Mali-G57 but **non-conformant** on other GPUs. The following
|
|
hardware is currently supported:
|
|
|
|
========= ============ ============ =======
|
|
Product Architecture OpenGL ES OpenGL
|
|
========= ============ ============ =======
|
|
Mali T620 Midgard (v4) 2.0 2.1
|
|
Mali T720 Midgard (v4) 2.0 2.1
|
|
Mali T760 Midgard (v5) 3.1 3.1
|
|
Mali T820 Midgard (v5) 3.1 3.1
|
|
Mali T830 Midgard (v5) 3.1 3.1
|
|
Mali T860 Midgard (v5) 3.1 3.1
|
|
Mali T880 Midgard (v5) 3.1 3.1
|
|
Mali G72 Bifrost (v6) 3.1 3.1
|
|
Mali G31 Bifrost (v7) 3.1 3.1
|
|
Mali G51 Bifrost (v7) 3.1 3.1
|
|
Mali G52 Bifrost (v7) 3.1 3.1
|
|
Mali G76 Bifrost (v7) 3.1 3.1
|
|
Mali G57 Valhall (v9) 3.1 3.1
|
|
========= ============ ============ =======
|
|
|
|
Other Midgard and Bifrost chips (T604, G71) are not yet supported.
|
|
|
|
Older Mali chips based on the Utgard architecture (Mali 400, Mali 450) are
|
|
supported in the Lima driver, not Panfrost. Lima is also available in Mesa.
|
|
|
|
Other graphics APIs (Vulkan, OpenCL) are not supported at this time.
|
|
|
|
Building
|
|
--------
|
|
|
|
Panfrost's OpenGL support is a Gallium driver. Since Mali GPUs are 3D-only and
|
|
do not include a display controller, Mesa uses kmsro to support display
|
|
controllers paired with Mali GPUs. If your board with a Panfrost supported GPU
|
|
has a display controller with mainline Linux support not supported by kmsro,
|
|
it's easy to add support, see the commit ``cff7de4bb597e9`` as an example.
|
|
|
|
LLVM is *not* required by Panfrost's compilers. LLVM support in Mesa can
|
|
safely be disabled for most OpenGL ES users with Panfrost.
|
|
|
|
Build like ``meson . build/ -Dvulkan-drivers=
|
|
-Dgallium-drivers=panfrost -Dllvm=disabled`` for a build directory
|
|
``build``.
|
|
|
|
For general information on building Mesa, read :doc:`the install documentation
|
|
<../install>`.
|
|
|
|
Chat
|
|
----
|
|
|
|
Panfrost developers and users hang out on IRC at ``#panfrost`` on OFTC. Note
|
|
that registering and authenticating with ``NickServ`` is required to prevent
|
|
spam. `Join the chat. <https://webchat.oftc.net/?channels=panfrost>`_
|
|
|
|
Compressed texture support
|
|
--------------------------
|
|
|
|
In the driver, Panfrost supports ASTC, ETC, and all BCn formats (e.g. RGTC,
|
|
S3TC, etc.) However, Panfrost depends on the hardware to support these formats
|
|
efficiently. All supported Mali architectures support these formats, but not
|
|
every system-on-chip with a Mali GPU support all these formats. Many lower-end
|
|
systems lack support for some BCn formats, which can cause problems when playing
|
|
desktop games with Panfrost. To check whether this issue applies to your
|
|
system-on-chip, Panfrost includes a ``panfrost_texfeatures`` tool to query
|
|
supported formats.
|
|
|
|
To use this tool, include the option ``-Dtools=panfrost`` when configuring Mesa.
|
|
Then inside your Mesa build directory, the tool is located at
|
|
``src/panfrost/tools/panfrost_texfeatures``. Copy it to your target device,
|
|
set as executable as necessary, and run on the target device. A table of
|
|
supported formats will be printed to standard output.
|
|
|
|
drm-shim
|
|
--------
|
|
|
|
Panfrost implements ``drm-shim``, stubbing out the Panfrost kernel interface.
|
|
Use cases for this functionality include:
|
|
|
|
- Future hardware bring up
|
|
- Running shader-db on non-Mali workstations
|
|
- Reproducing compiler (and some driver) bugs without Mali hardware
|
|
|
|
Although Mali hardware is usually paired with an Arm CPU, Panfrost is portable C
|
|
code and should work on any Linux machine. In particular, you can test the
|
|
compiler on shader-db on an Intel desktop.
|
|
|
|
To build Mesa with Panfrost drm-shim, configure Meson with
|
|
``-Dgallium-drivers=panfrost`` and ``-Dtools=drm-shim``. See the above
|
|
building section for a full invocation. The drm-shim binary will be built to
|
|
``build/src/panfrost/drm-shim/libpanfrost_noop_drm_shim.so``.
|
|
|
|
To use, set the ``LD_PRELOAD`` environment variable to the drm-shim binary. It
|
|
may also be necessary to set ``LIBGL_DRIVERS_PATH`` to the location where Mesa
|
|
was installed.
|
|
|
|
By default, drm-shim mocks a Mali-G52 system. To select a specific Mali GPU,
|
|
set the ``PAN_GPU_ID`` environment variable to the desired GPU ID:
|
|
|
|
========= ============ =======
|
|
Product Architecture GPU ID
|
|
========= ============ =======
|
|
Mali-T720 Midgard (v4) 720
|
|
Mali-T860 Midgard (v5) 860
|
|
Mali-G72 Bifrost (v6) 6221
|
|
Mali-G52 Bifrost (v7) 7212
|
|
Mali-G57 Valhall (v9) 9093
|
|
========= ============ =======
|
|
|
|
Additional GPU IDs are enumerated in the ``panfrost_model_list`` list in
|
|
``src/panfrost/lib/pan_props.c``.
|
|
|
|
As an example: assuming Mesa is installed to a local path ``~/lib`` and Mesa's
|
|
build directory is ``~/mesa/build``, a shader can be compiled for Mali-G52 as::
|
|
|
|
~/shader-db$ BIFROST_MESA_DEBUG=shaders LIBGL_DRIVERS_PATH=~/lib/dri/ LD_PRELOAD=~/mesa/build/src/panfrost/drm-shim/libpanfrost_noop_drm_shim.so PAN_GPU_ID=7212 ./run shaders/glmark/1-1.shader_test
|
|
|
|
The same shader can be compiled for Mali-T720 as::
|
|
|
|
~/shader-db$ MIDGARD_MESA_DEBUG=shaders LIBGL_DRIVERS_PATH=~/lib/dri/ LD_PRELOAD=~/mesa/build/src/panfrost/drm-shim/libpanfrost_noop_drm_shim.so PAN_GPU_ID=720 ./run shaders/glmark/1-1.shader_test
|
|
|
|
These examples set the compilers' ``shaders`` debug flags to dump the optimized
|
|
NIR, backend IR after instruction selection, backend IR after register
|
|
allocation and scheduling, and a disassembly of the final compiled binary.
|
|
|
|
As another example, this invocation runs a single dEQP test "on" Mali-G52,
|
|
pretty-printing GPU data structures and disassembling all shaders
|
|
(``PAN_MESA_DEBUG=trace``) as well as dumping raw GPU memory
|
|
(``PAN_MESA_DEBUG=dump``). The ``EGL_PLATFORM=surfaceless`` environment variable
|
|
and various flags to dEQP mimic the surfaceless environment that our
|
|
continuous integration (CI) uses. This eliminates window system dependencies,
|
|
although it requires a specially built CTS::
|
|
|
|
~/VK-GL-CTS/build/external/openglcts/modules$ PAN_MESA_DEBUG=trace,dump LIBGL_DRIVERS_PATH=~/lib/dri/ LD_PRELOAD=~/mesa/build/src/panfrost/drm-shim/libpanfrost_noop_drm_shim.so PAN_GPU_ID=7212 EGL_PLATFORM=surfaceless ./glcts --deqp-surface-type=pbuffer --deqp-gl-config-name=rgba8888d24s8ms0 --deqp-surface-width=256 --deqp-surface-height=256 -n dEQP-GLES31.functional.shaders.builtin_functions.common.abs.float_highp_compute
|
|
|
|
U-interleaved tiling
|
|
---------------------
|
|
|
|
Panfrost supports u-interleaved tiling. U-interleaved tiling is
|
|
indicated by the ``DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED`` modifier.
|
|
|
|
The tiling reorders whole pixels (blocks). It does not compress or modify the
|
|
pixels themselves, so it can be used for any image format. Internally, images
|
|
are divided into tiles. Tiles occur in source order, but pixels (blocks) within
|
|
each tile are reordered according to a space-filling curve.
|
|
|
|
For regular formats, 16x16 tiles are used. This harmonizes with the default tile
|
|
size for binning and CRCs (transaction elimination). It also means a single line
|
|
(16 pixels) at 4 bytes per pixel equals a single 64-byte cache line.
|
|
|
|
For formats that are already block compressed (S3TC, RGTC, etc), 4x4 tiles are
|
|
used, where entire blocks are reorder. Most of these formats compress 4x4
|
|
blocks, so this gives an effective 16x16 tiling. This justifies the tile size
|
|
intuitively, though it's not a rule: ASTC may uses larger blocks.
|
|
|
|
Within a tile, the X and Y bits are interleaved (like Morton order), but with a
|
|
twist: adjacent bit pairs are XORed. The reason to add XORs is not obvious.
|
|
Visually, addresses take the form::
|
|
|
|
| y3 | (x3 ^ y3) | y2 | (y2 ^ x2) | y1 | (y1 ^ x1) | y0 | (y0 ^ x0) |
|
|
|
|
Reference routines to encode/decode u-interleaved images are available in
|
|
``src/panfrost/shared/test/test-tiling.cpp``, which documents the space-filling
|
|
curve. This reference implementation is used to unit test the optimized
|
|
implementation used in production. The optimized implementation is available in
|
|
``src/panfrost/shared/pan_tiling.c``.
|
|
|
|
Although these routines are part of Panfrost, they are also used by Lima, as Arm
|
|
introduced the format with Utgard. It is the only tiling supported on Utgard. On
|
|
Mali-T760 and newer, Arm Framebuffer Compression (AFBC) is more efficient and
|
|
should be used instead where possible. However, not all formats are
|
|
compressible, so u-interleaved tiling remains an important fallback on Panfrost.
|
|
|