From b1874a26952a2201c2743c31321f9727005c0de5 Mon Sep 17 00:00:00 2001 From: Erik Faye-Lund Date: Mon, 28 Sep 2020 17:53:58 +0200 Subject: [PATCH 1/7] docs: clippping -> clipping Reviewed-by: Eric Anholt Part-of: --- docs/versions.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/versions.rst b/docs/versions.rst index 67a816a01829..0541120d4996 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 -- GitLab From 6ec9a7ec57e94ca3f38737f2b6502e4c3ca0658c Mon Sep 17 00:00:00 2001 From: Erik Faye-Lund Date: Mon, 28 Sep 2020 17:56:22 +0200 Subject: [PATCH 2/7] docs: consistantly -> consistently Reviewed-by: Eric Anholt Part-of: --- docs/gallium/cso/sampler.rst | 2 +- docs/versions.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/gallium/cso/sampler.rst b/docs/gallium/cso/sampler.rst index 2cccad5aa92a..aa544a87705a 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/versions.rst b/docs/versions.rst index 0541120d4996..a5bad3479eb0 100644 --- a/docs/versions.rst +++ b/docs/versions.rst @@ -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 -- GitLab From 915d4e280687f7dbeae9075c07412f8b02a68c9f Mon Sep 17 00:00:00 2001 From: Erik Faye-Lund Date: Mon, 28 Sep 2020 13:31:43 +0200 Subject: [PATCH 3/7] docs: stabilisation -> stabilization We generally prefer US English in the docs over UK English. Reviewed-by: Eric Anholt Part-of: --- docs/releasing.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/releasing.rst b/docs/releasing.rst index 39db085f7590..ee41dd4a4625 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:: -- GitLab From 40cb54270cd749585b0089a95e528288a14ec907 Mon Sep 17 00:00:00 2001 From: Erik Faye-Lund Date: Mon, 28 Sep 2020 13:37:20 +0200 Subject: [PATCH 4/7] docs: flavours -> flavors We generally prefer US English over UK English in the docs. Reviewed-by: Eric Anholt Part-of: --- docs/gallium/context.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/gallium/context.rst b/docs/gallium/context.rst index 8cf1f4fba25f..c0667f8d2965 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. -- GitLab From 8a5eebd40906d9b5e5333890be9989b95dda8d9f Mon Sep 17 00:00:00 2001 From: Erik Faye-Lund Date: Mon, 28 Sep 2020 12:22:11 +0200 Subject: [PATCH 5/7] docs: debian -> Debian Reviewed-by: Eric Anholt Part-of: --- docs/ci/docker.rst | 2 +- docs/ci/index.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/ci/docker.rst b/docs/ci/docker.rst index 29bc17186b79..7f6dd101013b 100644 --- a/docs/ci/docker.rst +++ b/docs/ci/docker.rst @@ -49,7 +49,7 @@ on Mesa developers working on other drivers. * 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 +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 diff --git a/docs/ci/index.rst b/docs/ci/index.rst index ee3f4564d394..fa51e25c1241 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 -- GitLab From 9d34c99f39af4c018eadef0cf206a688c9bdfa3b Mon Sep 17 00:00:00 2001 From: Erik Faye-Lund Date: Mon, 28 Sep 2020 12:29:28 +0200 Subject: [PATCH 6/7] docs: docker -> Docker Reviewed-by: Eric Anholt Part-of: --- docs/ci/LAVA.rst | 8 ++++---- docs/ci/bare-metal.rst | 4 ++-- docs/ci/docker.rst | 16 ++++++++-------- docs/ci/index.rst | 6 +++--- 4 files changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/ci/LAVA.rst b/docs/ci/LAVA.rst index dbb206d708f4..206e1013244b 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 78c6f4249734..0af32b3ba445 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 7f6dd101013b..bca1da4c0ffa 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, +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 fa51e25c1241..d5ec47364c0d 100644 --- a/docs/ci/index.rst +++ b/docs/ci/index.rst @@ -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 -- GitLab From 8f24a14175b7175b73c3c5f91c7700163c75f484 Mon Sep 17 00:00:00 2001 From: Erik Faye-Lund Date: Mon, 28 Sep 2020 13:49:20 +0200 Subject: [PATCH 7/7] docs: gallium -> Gallium Reviewed-by: Eric Anholt Part-of: --- docs/codingstyle.rst | 2 +- docs/index.rst | 4 ++-- docs/osmesa.rst | 2 +- docs/sourcetree.rst | 2 +- docs/viewperf.rst | 2 +- docs/vmware-guest.rst | 4 ++-- 6 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/codingstyle.rst b/docs/codingstyle.rst index 198289aadece..ab479e2e1c49 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/index.rst b/docs/index.rst index ba8e1da70234..1278199c65b8 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 0232aec03a01..48bf65e8ba24 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/sourcetree.rst b/docs/sourcetree.rst index dd6fe43785c2..a9d752a0c0e9 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/viewperf.rst b/docs/viewperf.rst index 30957cb7eed9..ae3c4e48793b 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 d738f2be74e8..ba713a73e1d1 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 -- GitLab