fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2026-05-09 06:48:06 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

docs/pvr: fix some typos and wording

Browse source 
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Suggested-by: Michael Green <michael.green@imgtec.com>
Reviewed-by: Simon Perretta <simon.perretta@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39486>
This commit is contained in:
Frank Binns 2026-01-23 12:58:51 +00:00 • committed by Marge Bot
parent 353bc835b8
commit 861e62e9a9
1 changed files with 12 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
docs/drivers/powervr.rst
View file

@ -69,13 +69,13 @@ support Vulkan and therefore cannot be supported by this driver.
Multi-Architecture support
--------------------------
In order to support multiple distinct hardware generations without too much
spaghetti-code, ther PowerVR compiles a few files multiple times (once per
hardware architecture), and uses a system of macros and aliases to be able
to refer to the different versions.
To support multiple distinct hardware generations without too much
spaghetti-code, the PowerVR build compiles a few files multiple times (once
per hardware architecture) and uses a system of macros and aliases to be
able to refer to the different versions.
The files that gets compiled multiple times are those named
:file:`pvr_arch_*.c`. These files contains definitions of functions prefixed
The files that get compiled multiple times are those named
:file:`pvr_arch_*.c`. These files contain definitions of functions prefixed
with ``pvr_arch_`` (instead of the normal ``pvr_``-prefix). The ``arch``-bit
of that function is a placeholder, which gets replaced at compile-time, thanks
to a system of defines in the corresponding header file, supported by a set
@ -83,16 +83,16 @@ of macros defined in :file:`pvr_macros.h`.
The intention is that these functions are mostly called from architecture
specific entrypoints, that are handled by the common vulkan dispatch-table
code. This means that a architecture specific function can easily call either
code. This means that an architecture specific function can easily call either
architecture specific or architecture agnostic code.
The tricky bit comes when architecture agnostic calls architecture specific
code. In that case, we have the ``PVR_ARCH_DISPATCH`` and
``PVR_ARCH_DISPATCH_RET`` macros. These are a bit error-prone to use, because
they need to see definition for all architecture versions of each entrypoint,
The tricky bit comes when architecture agnostic code calls architecture
specific code. In that case, we have the ``PVR_ARCH_DISPATCH`` and
``PVR_ARCH_DISPATCH_RET`` macros. These are a bit error-prone to use because
they need to see definitions for all architecture versions of each entrypoint,
which isn't something we have available. To work around this, we define a
``PER_ARCH_FUNCS(arch)`` macro in each source-file that needs to use these
dispatch macros, and make sure to instantiate it once per architecture.
dispatch macros and make sure to instantiate it once per architecture.
To avoid confusion, please do not add functions that are prefixed with
``pvr_arch_`` if they are not part of the system described here.