OpenHarmony/third_party_mesa3d
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: hw -> HW

Browse Source 
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19191>
This commit is contained in:
Erik Faye-Lund
2022-10-19 15:30:44 +02:00
committed by Marge Bot
parent 672fc2527b
commit f2e688f042
5 changed files with 12 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/drivers/freedreno/ir3-notes.rst
View File

@@ -32,7 +32,7 @@ External Structure
generated.
``ir3_shader_variant``
The actual hw shader generated based on input TGSI and shader key.
The actual HW shader generated based on input TGSI and shader key.
``ir3_compiler``
Compiler frontend which generates ir3 and runs the various backend

2
docs/drivers/freedreno/isaspec.rst
View File

@@ -39,7 +39,7 @@ Bitsets
The fundamental concept of matching a bit-pattern to an instruction
decoding/encoding is the concept of a hierarchical tree of bitsets.
This is intended to match how the hw decodes instructions, where certain
This is intended to match how the HW decodes instructions, where certain
bits describe the instruction (and sub-encoding, and so on), and other
bits describe various operands to the instruction.

4
docs/gallium/context.rst
View File

@@ -180,7 +180,7 @@ to the array index which is used for sampling.
Hardware Atomic buffers
^^^^^^^^^^^^^^^^^^^^^^^
Buffers containing hw atomics are required to support the feature
Buffers containing HW atomics are required to support the feature
on some drivers.
Drivers that require this need to fill the ``set_hw_atomic_buffers`` method.
@@ -269,7 +269,7 @@ Clearing
^^^^^^^^
Clear is one of the most difficult concepts to nail down to a single
interface (due to both different requirements from APIs and also driver/hw
interface (due to both different requirements from APIs and also driver/HW
specific differences).
``clear`` initializes some or all of the surfaces currently bound to

12
docs/gallium/screen.rst
View File

@@ -124,20 +124,20 @@ The integer capabilities:
* ``PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION``: Whether quads adhere to
the flatshade_first setting in ``pipe_rasterizer_state``.
* ``PIPE_CAP_USER_VERTEX_BUFFERS``: Whether the driver supports user vertex
buffers. If not, gallium frontends must upload all data which is not in hw
buffers. If not, gallium frontends must upload all data which is not in HW
resources. If user-space buffers are supported, the driver must also still
accept HW resource buffers.
* ``PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY``: This CAP describes a hw
* ``PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY``: This CAP describes a HW
limitation. If true, pipe_vertex_buffer::buffer_offset must always be aligned
to 4. If false, there are no restrictions on the offset.
* ``PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY``: This CAP describes a hw
* ``PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY``: This CAP describes a HW
limitation. If true, pipe_vertex_buffer::stride must always be aligned to 4.
If false, there are no restrictions on the stride.
* ``PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY``: This CAP describes
a hw limitation. If true, pipe_vertex_element::src_offset must always be
a HW limitation. If true, pipe_vertex_element::src_offset must always be
aligned to 4. If false, there are no restrictions on src_offset.
* ``PIPE_CAP_VERTEX_ATTRIB_ELEMENT_ALIGNED_ONLY``: This CAP describes
a hw limitation. If true, the sum of
a HW limitation. If true, the sum of
``pipe_vertex_element::src_offset + pipe_vertex_buffer::buffer_offset + pipe_vertex_buffer::stride``
must always be aligned to the component size for the vertex attributes
which access that buffer. If false, there are no restrictions on these values.
@@ -165,7 +165,7 @@ The integer capabilities:
supports R, RG, RGB and RGBA formats for PIPE_BUFFER sampler views.
When this is the case it should be assumed that the swizzle parameters
in the sampler view have no effect.
* ``PIPE_CAP_TGSI_TEXCOORD``: This CAP describes a hw limitation.
* ``PIPE_CAP_TGSI_TEXCOORD``: This CAP describes a HW limitation.
If true, the hardware cannot replace arbitrary shader inputs with sprite
coordinates and hence the inputs that are desired to be replaceable must
be declared with TGSI_SEMANTIC_TEXCOORD instead of TGSI_SEMANTIC_GENERIC.

4
docs/gallium/tgsi.rst
View File

@@ -964,7 +964,7 @@ XXX doesn't look like most of the opcodes really belong here.
PIPE_CAP_TEXTURE_SM5 enhances this instruction to support shadow per-sample
depth compares, single component selection, and a non-constant offset. It
doesn't allow support for the GL independent offset to get i0,j0. This would
require another CAP is hw can do it natively. For now we lower that before
require another CAP is HW can do it natively. For now we lower that before
TGSI.
PIPE_CAP_TGSI_TG4_COMPONENT_IN_SWIZZLE changes the encoding so that component
@@ -2699,7 +2699,7 @@ location is guaranteed to be performed strictly before or after the
entire execution of the atomic operation. The resource may be a BUFFER,
IMAGE, HWATOMIC, or MEMORY. In the case of an image, the offset works
the same as for ``LOAD`` and ``STORE``, specified above. For atomic
counters, the offset is an immediate index to the base hw atomic
counters, the offset is an immediate index to the base HW atomic
counter for this operation.
These atomic operations may only be used with 32-bit integer image formats.