diff --git a/docs/drivers/freedreno/ir3-notes.rst b/docs/drivers/freedreno/ir3-notes.rst index 093d7c5bd2a..2b244411891 100644 --- a/docs/drivers/freedreno/ir3-notes.rst +++ b/docs/drivers/freedreno/ir3-notes.rst @@ -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 diff --git a/docs/drivers/freedreno/isaspec.rst b/docs/drivers/freedreno/isaspec.rst index cd228983c62..1d5606ce59f 100644 --- a/docs/drivers/freedreno/isaspec.rst +++ b/docs/drivers/freedreno/isaspec.rst @@ -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. diff --git a/docs/gallium/context.rst b/docs/gallium/context.rst index 6b35a981d9b..e317057b545 100644 --- a/docs/gallium/context.rst +++ b/docs/gallium/context.rst @@ -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 diff --git a/docs/gallium/screen.rst b/docs/gallium/screen.rst index 9890af9bce2..d6dedd5ad50 100644 --- a/docs/gallium/screen.rst +++ b/docs/gallium/screen.rst @@ -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. diff --git a/docs/gallium/tgsi.rst b/docs/gallium/tgsi.rst index 9fcc1b70a54..3b419568220 100644 --- a/docs/gallium/tgsi.rst +++ b/docs/gallium/tgsi.rst @@ -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.