diff --git a/docs/ci/LAVA.rst b/docs/ci/LAVA.rst index dbb206d708f4cc5454236466c1fed238d0f63918..206e1013244b3d5aace16e7f83d603230ba9a72e 100644 --- a/docs/ci/LAVA.rst +++ b/docs/ci/LAVA.rst @@ -15,7 +15,7 @@ Mesa-LAVA software architecture The gitlab-runner will run on some host that has access to the LAVA lab, with tags like "lava-mesa-boardname" to control only taking in jobs for the hardware that the LAVA lab contains. The gitlab-runner -spawns a docker container with lava-cli in it, and connects to the +spawns a Docker container with lava-cli in it, and connects to the LAVA lab using a predefined token to submit jobs under a specific device type. @@ -50,12 +50,12 @@ runner *must* have a tag (like "mesa-lava-db410c") to restrict the jobs it takes or it will grab random jobs from tasks across fd.o, and your runner isn't ready for that. -The runner will be running an ARM docker image (we haven't done any +The runner will be running an ARM Docker image (we haven't done any x86 LAVA yet, so that isn't documented). If your host for the gitlab-runner is x86, then you'll need to install qemu-user-static and the binfmt support. -The docker image will need access to the lava instance. If it's on a +The Docker image will need access to the lava instance. If it's on a public network it should be fine. If you're running the LAVA instance on localhost, you'll need to set ``network_mode="host"`` in ``/etc/gitlab-runner/config.toml`` so it can access localhost. Create a @@ -71,7 +71,7 @@ the web interface, and create an API token. Copy that into a username: gitlab-runner Add a volume mount of that ``lavacli.yaml`` to -``/etc/gitlab-runner/config.toml`` so that the docker container can +``/etc/gitlab-runner/config.toml`` so that the Docker container can access it. You probably have a ``volumes = ["/cache"]`` already, so now it would be:: volumes = ["/home/anholt/lava-config/lavacli.yaml:/root/.config/lavacli.yaml", "/cache"] diff --git a/docs/ci/bare-metal.rst b/docs/ci/bare-metal.rst index 78c6f42497346b5fe910ca4d16e519f6eb59517d..0af32b3ba4456ef2b10ecae72a685a51fdf526a3 100644 --- a/docs/ci/bare-metal.rst +++ b/docs/ci/bare-metal.rst @@ -1,7 +1,7 @@ Bare-metal CI ============= -The bare-metal scripts run on a system with gitlab-runner and docker, +The bare-metal scripts run on a system with gitlab-runner and Docker, connected to potentially multiple bare-metal boards that run tests of Mesa. Currently only "fastboot" and "ChromeOS Servo" devices are supported. @@ -120,7 +120,7 @@ required by your bare-metal script, something like:: If you want to collect the results for fastboot you need to add the following two board-specific environment variables ``BM_WEBDAV_IP`` and ``BM_WEBDAV_PORT``. -These represent the IP address of the docker host and the board specific port number +These represent the IP address of the Docker host and the board specific port number that gets used to start a nginx server. Once you've updated your runners' configs, restart with ``sudo service diff --git a/docs/ci/docker.rst b/docs/ci/docker.rst index 29bc17186b7976ce504b8152910f12e82acb48cd..bca1da4c0ffa51a77e008f94f58261beb796d726 100644 --- a/docs/ci/docker.rst +++ b/docs/ci/docker.rst @@ -8,7 +8,7 @@ VK-GL-CTS, on the shared GitLab runners provided by `freedesktop Software architecture --------------------- -The docker containers are rebuilt from the debian-install.sh script +The Docker containers are rebuilt from the debian-install.sh script when DEBIAN\_TAG is changed in .gitlab-ci.yml, and debian-test-install.sh when DEBIAN\_ARM64\_TAG is changed in .gitlab-ci.yml. The resulting images are around 500MB, and are @@ -36,7 +36,7 @@ DUT requirements ---------------- In addition to the general :ref:`CI-farm-expectations`, using -docker requires: +Docker requires: * DUTs must have a stable kernel and GPU reset (if applicable). @@ -46,25 +46,25 @@ reliably reset the GPU on failure, bugs in one MR may leak into spurious failures in another MR. This would be an unacceptable impact on Mesa developers working on other drivers. -* DUTs must be able to run docker +* DUTs must be able to run Docker -The Mesa gitlab-runner based test architecture is built around docker, -so that we can cache the debian package installation and CTS build +The Mesa gitlab-runner based test architecture is built around Docker, +so that we can cache the Debian package installation and CTS build step across multiple test runs. Since the images are large and change approximately weekly, the DUTs also need to be running some script to -prune stale docker images periodically in order to not run out of disk +prune stale Docker images periodically in order to not run out of disk space as we rev those containers (perhaps `this script `_). -Note that docker doesn't allow containers to be stored on NFS, and -doesn't allow multiple docker daemons to interact with the same +Note that Docker doesn't allow containers to be stored on NFS, and +doesn't allow multiple Docker daemons to interact with the same network block device, so you will probably need some sort of physical storage on your DUTs. * DUTs must be public By including your device in .gitlab-ci.yml, you're effectively letting -anyone on the internet run code on your device. docker containers may +anyone on the internet run code on your device. Docker containers may provide some limited protection, but how much you trust that and what you do to mitigate hostile access is up to you. diff --git a/docs/ci/index.rst b/docs/ci/index.rst index ee3f4564d394523d9d104c77afe85f5229c19488..d5ec47364c0dd4dfaf95021679c9697a85ebf6d7 100644 --- a/docs/ci/index.rst +++ b/docs/ci/index.rst @@ -133,7 +133,7 @@ Mesa's CI is currently run primarily on packet.net's m1xlarge nodes (2.2Ghz Sandybridge), with each job getting 8 cores allocated. You can speed up your personal CI builds (and marge-bot merges) by using a faster personal machine as a runner. You can find the gitlab-runner -package in debian, or use GitLab's own builds. +package in Debian, or use GitLab's own builds. To do so, follow `GitLab's instructions `__ to @@ -151,13 +151,13 @@ lines in ``/etc/gitlab-runner/config.toml``, for example:: Docker caching -------------- -The CI system uses docker images extensively to cache +The CI system uses Docker images extensively to cache infrequently-updated build content like the CTS. The `freedesktop.org CI templates `_ help us manage the building of the images to reduce how frequently rebuilds happen, and trim down the images (stripping out manpages, cleaning the -apt cache, and other such common pitfalls of building docker images). +apt cache, and other such common pitfalls of building Docker images). When running a container job, the templates will look for an existing build of that image in the container registry under @@ -170,7 +170,7 @@ string related to your branch (so that if you rebase on someone else's container update from the same day, you will get a git conflict instead of silently reusing their container) -When developing a given change to your docker image, you would have to +When developing a given change to your Docker image, you would have to bump the tag on each ``git commit --amend`` to your development branch, which can get tedious. Instead, you can navigate to the `container registry diff --git a/docs/codingstyle.rst b/docs/codingstyle.rst index 198289aadecee3f02afb9e0d1fa7781b625ac799..ab479e2e1c49c2b99f47294ec14da6bdfa4ef1d7 100644 --- a/docs/codingstyle.rst +++ b/docs/codingstyle.rst @@ -112,7 +112,7 @@ Basic formatting guidelines - Constants, macros and enum names are ``ALL_UPPERCASE``, with \_ between words. - Mesa usually uses camel case for local variables (Ex: - ``localVarname``) while gallium typically uses underscores (Ex: + ``localVarname``) while Gallium typically uses underscores (Ex: ``local_var_name``). - Global variables are almost never used because Mesa should be thread-safe. diff --git a/docs/gallium/context.rst b/docs/gallium/context.rst index 8cf1f4fba25fa6eca63df75723293351e87e379f..c0667f8d2965ea8f0333207dcc73f4ae79996c49 100644 --- a/docs/gallium/context.rst +++ b/docs/gallium/context.rst @@ -40,7 +40,7 @@ CSO objects handled by the context object: Resource Binding State ^^^^^^^^^^^^^^^^^^^^^^ -This state describes how resources in various flavours (textures, +This state describes how resources in various flavors (textures, buffers, surfaces) are bound to the driver. diff --git a/docs/gallium/cso/sampler.rst b/docs/gallium/cso/sampler.rst index 2cccad5aa92a8b55247b6e12df7ad61999a5c8ad..aa544a87705aea62c6660edcd496d2028a897766 100644 --- a/docs/gallium/cso/sampler.rst +++ b/docs/gallium/cso/sampler.rst @@ -28,7 +28,7 @@ The wrap modes are: border color is sampled when coords go outside the range [0,1]. * ``PIPE_TEX_WRAP_CLAMP``: The coord is clamped to the range [0,1] before scaling to the texture size. This corresponds to the legacy OpenGL GL_CLAMP - texture wrap mode. Historically, this mode hasn't acted consistantly across + texture wrap mode. Historically, this mode hasn't acted consistently across all graphics hardware. It sometimes acts like CLAMP_TO_EDGE or CLAMP_TO_BORDER. The behavior may also vary depending on linear vs. nearest sampling mode. diff --git a/docs/index.rst b/docs/index.rst index ba8e1da70234df87fcc889989c5fe3f4f536f301..1278199c65b8475c22ec570ff51c5b8dfda614cf 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -108,13 +108,13 @@ February 2012: Mesa 8.0 is released, implementing the OpenGL 3.0 specification and version 1.30 of the OpenGL Shading Language. July 2016: Mesa 12.0 is released, including OpenGL 4.3 support and -initial support for Vulkan for Intel GPUs. Plus, there's another gallium +initial support for Vulkan for Intel GPUs. Plus, there's another Gallium software driver ("swr") based on LLVM and developed by Intel. Ongoing: Mesa is the OpenGL implementation for devices designed by Intel, AMD, NVIDIA, Qualcomm, Broadcom, Vivante, plus the VMware and VirGL virtual GPUs. There's also several software-based renderers: -swrast (the legacy Mesa rasterizer), softpipe (a gallium reference +swrast (the legacy Mesa rasterizer), softpipe (a Gallium reference driver), llvmpipe (LLVM/JIT-based high-speed rasterizer) and swr (another LLVM-based driver). diff --git a/docs/osmesa.rst b/docs/osmesa.rst index 0232aec03a0178832ddb5db38fe8682ed152ae13..48bf65e8ba24a15701227a7f63b1f8ae4df89fb3 100644 --- a/docs/osmesa.rst +++ b/docs/osmesa.rst @@ -37,7 +37,7 @@ When the build is complete you should find: :: $PWD/builddir/install/lib/libOSMesa.so (swrast-based OSMesa) - $PWD/builddir/install/lib/gallium/libOSMsea.so (gallium-based OSMesa) + $PWD/builddir/install/lib/gallium/libOSMsea.so (Gallium-based OSMesa) Set your LD_LIBRARY_PATH to point to $PWD/builddir/install to use the libraries diff --git a/docs/releasing.rst b/docs/releasing.rst index 39db085f7590d5843c39d198c620e585b3803a48..ee41dd4a4625e7eff0e25bfc9447b77dae7c58ed 100644 --- a/docs/releasing.rst +++ b/docs/releasing.rst @@ -165,7 +165,7 @@ Making a branchpoint -------------------- A branchpoint is made such that new development can continue in parallel -to stabilisation and bugfixing. +to stabilization and bugfixing. .. note:: diff --git a/docs/sourcetree.rst b/docs/sourcetree.rst index dd6fe43785c2a3c0fe4794698256cbce6051a845..a9d752a0c0e9530175ca0c38d6ebaa465521557a 100644 --- a/docs/sourcetree.rst +++ b/docs/sourcetree.rst @@ -195,7 +195,7 @@ each directory. - **d3dadapter9** - d3dadapter9.so for Wine - **dri** - libgallium_dri.so loaded by libGL.so - - **graw** - raw gallium interface without a frontend + - **graw** - raw Gallium interface without a frontend - XXX more - **glx** - The GLX library code for building libGL.so using DRI diff --git a/docs/versions.rst b/docs/versions.rst index 67a816a01829a8cfd09905579055d1157b9134a5..a5bad3479eb0a55b5fd4bdcbebced30219d39b81 100644 --- a/docs/versions.rst +++ b/docs/versions.rst @@ -160,7 +160,7 @@ Bug fixes: - glGet*(GL_DEPTH_BITS) returned bytes, not bits - point, line, and bitmap rasterization suffered from roundoff errors -- fixed a division by zero error in line clippping +- fixed a division by zero error in line clipping - occasional wrong default background color really fixed! - glDepthFunc(GL_ALWAYS) with glDepthMask(GL_FALSE) didn't work - gluBuild2DMipmaps malloc problem fixed @@ -435,7 +435,7 @@ Bug fixes: - linear interpolation of mipmap levels was incorrectly weighted - readpix.c didn't compile on Macintosh - GL_INVERT and related logic ops didn't work right -- glTexImage[12]D() didn't check its parameters consistantly +- glTexImage[12]D() didn't check its parameters consistently - fixed a memory leak in glTexImage[12]D() - kludged around a SunOS 5.x/GCC compiler bug in the feedback code - glReadPixels aborted instead of normally catching some errors diff --git a/docs/viewperf.rst b/docs/viewperf.rst index 30957cb7eed9f70c70ea2b27953b6d8e8879b1df..ae3c4e48793bd370b023569fc8c9d9a0322043b3 100644 --- a/docs/viewperf.rst +++ b/docs/viewperf.rst @@ -185,7 +185,7 @@ If either of the two passes happen to use a software fallback of some sort, the Z values of fragments may be different between the two passes. This leads to incorrect rendering. -For example, the VMware SVGA gallium driver uses a special semi-fallback +For example, the VMware SVGA Gallium driver uses a special semi-fallback path for drawing with polygon stipple. Since the two passes are rendered with different vertex transformation implementations, the rendering doesn't appear as expected. Setting the SVGA_FORCE_SWTNL environment diff --git a/docs/vmware-guest.rst b/docs/vmware-guest.rst index d738f2be74e8280e996bf109b87be8cd95f073fe..ba713a73e1d1029dac7afe74a43a9f4a37d99b50 100644 --- a/docs/vmware-guest.rst +++ b/docs/vmware-guest.rst @@ -15,7 +15,7 @@ supported in the guest. This requires: - The host OS, GPU and graphics driver supports DX11 (Windows) or OpenGL 4.0 (Linux, Mac) - On Linux, the vmwgfx kernel module must be version 2.9.0 or later. -- A recent version of Mesa with the updated svga gallium driver. +- A recent version of Mesa with the updated svga Gallium driver. Otherwise, OpenGL 2.1 is supported. @@ -58,7 +58,7 @@ The components involved in this include: - Linux kernel module: vmwgfx - X server 2D driver: xf86-video-vmware - User-space libdrm library -- Mesa/gallium OpenGL driver: "svga" +- Mesa/Gallium OpenGL driver: "svga" All of these components reside in the guest Linux virtual machine. On the host, all you're doing is running VMware