docs: behaviour -> behavior

Most of our documentation is US English, so let's stick to that.

Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6864>

docs/envvars.rst

@@ -39,7 +39,7 @@ Core Mesa environment variables
    if set, disables Intel SSE optimizations
 ``MESA_NO_ERROR``
    if set to 1, error checking is disabled as per ``KHR_no_error``. This
-   will result in undefined behaviour for invalid use of the api, but
+   will result in undefined behavior for invalid use of the api, but
    can reduce CPU use for apps that are known to be error free.
 ``MESA_DEBUG``
    if set, error messages are printed to stderr. For example, if the
@@ -48,7 +48,7 @@ Core Mesa environment variables
    will be printed to stderr. For release builds, ``MESA_DEBUG``
    defaults to off (no debug output). ``MESA_DEBUG`` accepts the
    following comma-separated list of named flags, which adds extra
-   behaviour to just set ``MESA_DEBUG=1``:
+   behavior to just set ``MESA_DEBUG=1``:
 
    ``silent``
       turn off debug messages. Only useful for debug builds.
@@ -185,7 +185,7 @@ NIR passes environment variables
 --------------------------------
 
 The following are only applicable for drivers that uses NIR, as they
-modify the behaviour for the common NIR_PASS and NIR_PASS_V macros, that
+modify the behavior for the common NIR_PASS and NIR_PASS_V macros, that
 wrap calls to NIR lowering/optimizations.
 
 ``NIR_PRINT``

docs/gallium/context.rst

@@ -605,10 +605,10 @@ is forever considered to be signaled.
 Once a re-usable ``pipe_fence_handle`` becomes signaled, it can be reset
 back into an unsignaled state. The ``pipe_fence_handle`` will be reset to
 the unsignaled state by performing a wait operation on said object, i.e.
-``fence_server_sync``. As a corollary to this behaviour, a re-usable
+``fence_server_sync``. As a corollary to this behavior, a re-usable
 ``pipe_fence_handle`` can only have one waiter.
 
-This behaviour is useful in producer <-> consumer chains. It helps avoid
+This behavior is useful in producer <-> consumer chains. It helps avoid
 unnecessarily sharing a new ``pipe_fence_handle`` each time a new frame is
 ready. Instead, the fences are exchanged once ahead of time, and access is synchronized
 through GPU signaling instead of direct producer <-> consumer communication.

docs/gallium/cso/rasterizer.rst

@@ -129,8 +129,8 @@ offset_units
     Specifies the polygon offset bias
 offset_units_unscaled
     Specifies the unit of the polygon offset bias. If false, use the
-    GL/D3D1X behaviour. If true, offset_units is a floating point offset
-    which isn't scaled (D3D9). Note that GL/D3D1X behaviour has different
+    GL/D3D1X behavior. If true, offset_units is a floating point offset
+    which isn't scaled (D3D9). Note that GL/D3D1X behavior has different
     formula whether the depth buffer is unorm or float, which is not
     the case for D3D9.
 offset_scale
@@ -235,7 +235,7 @@ point_smooth
     points into circles or ovals.
 point_size_per_vertex
     Whether the vertex shader is expected to have a point size output.
-    Undefined behaviour is permitted if there is disagreement between
+    Undefined behavior is permitted if there is disagreement between
     this flag and the actual bound shader.
 point_size
     The size of points, if not specified per-vertex.

docs/gallium/cso/sampler.rst

@@ -30,7 +30,7 @@ The wrap modes are:
   scaling to the texture size.  This corresponds to the legacy OpenGL GL_CLAMP
   texture wrap mode.  Historically, this mode hasn't acted consistantly across
   all graphics hardware.  It sometimes acts like CLAMP_TO_EDGE or
-  CLAMP_TO_BORDER.  The behaviour may also vary depending on linear vs.
+  CLAMP_TO_BORDER.  The behavior may also vary depending on linear vs.
   nearest sampling mode.
 * ``PIPE_TEX_WRAP_MIRROR_REPEAT``: If the integer part of the coordinate
   is odd, the coord becomes (1 - coord).  Then, normal texture REPEAT is