From c9378106ed989a668302b69a52079af32facf894 Mon Sep 17 00:00:00 2001 From: Harri Nieminen Date: Mon, 27 Mar 2023 22:13:06 +0300 Subject: [PATCH] docs/gallium: Fix typos Found by codespell Part-of: --- docs/gallium/context.rst | 4 ++-- docs/gallium/cso/rasterizer.rst | 2 +- docs/gallium/screen.rst | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/gallium/context.rst b/docs/gallium/context.rst index 0b1630d..8ebbd84 100644 --- a/docs/gallium/context.rst +++ b/docs/gallium/context.rst @@ -357,7 +357,7 @@ buffer. In indexed draw, ``min_index`` and ``max_index`` respectively provide a lower and upper bound of the indices contained in the index buffer inside the range between ``start`` to ``start``+``count``-1. This allows the driver to -determine which subset of vertices will be referenced during te draw call +determine which subset of vertices will be referenced during the draw call without having to scan the index buffer. Providing a over-estimation of the the true bounds, for example, a ``min_index`` and ``max_index`` of 0 and 0xffffffff respectively, must give exactly the same rendering, albeit with less @@ -561,7 +561,7 @@ has completed, drawing will be predicated on the outcome of the query. If ``mode`` is PIPE_RENDER_COND_BY_REGION_WAIT or PIPE_RENDER_COND_BY_REGION_NO_WAIT rendering will be predicated as above for the non-REGION modes but in the case that an occlusion query returns -a non-zero result, regions which were occluded may be ommitted by subsequent +a non-zero result, regions which were occluded may be omitted by subsequent drawing commands. This can result in better performance with some GPUs. Normally, if the occlusion query returned a non-zero result subsequent drawing happens normally so fragments may be generated, shaded and diff --git a/docs/gallium/cso/rasterizer.rst b/docs/gallium/cso/rasterizer.rst index 822ebeb..88394c8 100644 --- a/docs/gallium/cso/rasterizer.rst +++ b/docs/gallium/cso/rasterizer.rst @@ -251,7 +251,7 @@ half_pixel_center 1 +-----+ When false, the rasterizer should use (0, 0) pixel centers for determining - pixel ownership (e.g., D3D9 or ealier):: + pixel ownership (e.g., D3D9 or earlier):: -0.5 0 0.5 -0.5 +-----+ diff --git a/docs/gallium/screen.rst b/docs/gallium/screen.rst index 2ef0c97..53efdc3 100644 --- a/docs/gallium/screen.rst +++ b/docs/gallium/screen.rst @@ -367,7 +367,7 @@ The integer capabilities: * ``PIPE_CAP_FRAMEBUFFER_NO_ATTACHMENT``: If non-zero, rendering to framebuffers with no surface attachments is supported. The context->is_format_supported function will be expected - to be implemented with PIPE_FORMAT_NONE yeilding the MSAA modes the hardware + to be implemented with PIPE_FORMAT_NONE yielding the MSAA modes the hardware supports. N.B., The maximum number of layers supported for rasterizing a primitive on a layer is obtained from ``PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS`` even though it can be larger than the number of layers supported by either -- 2.7.4